[kepler-users] More questions on configuration

Matt Jones jones at nceas.ucsb.edu
Thu Nov 6 10:23:18 PST 2008 

Hi,

By add, I assume you mean to add it to the tree.  To do this, you'll need to
create the actor metadata file and the compiled java code and import these
to Kepler. There are several ways you can do this.   One way is to create
the Java code for the actor, compile it, and put it on your classpath, then
use 'Instantiate Actor' on the Workflow menu to add the actor to the
canvas.  Then you can use the documentation editor and semantic annotation
tool in Kepler to add documentation to the actor, then use the add to
library function to add the actor to the library.  An alternative approach
is to create a KAR file manually that contains the actor metadata files and
the jar dependencies, which you can then bring into Kepler using the 'Import
KAR File...' menu command.  Examples of the actor metadata are in the
src/actors tree.  There are many other variants on how this could be done.

Matt

On Thu, Nov 6, 2008 at 2:09 AM, tog <guillaume.alleon at gmail.com> wrote:

> Hi Matt
>
> Thanks for the quick answer.
> So what is the correct process to add a new actor and its multiple
> jars dependency (assuming there is no collision - or that I have
> successfully streamlined the version)
>
> Guillaume
>
> On Thu, Nov 6, 2008 at 9:15 AM, Matt Jones <jones at nceas.ucsb.edu> wrote:
> > Hi Guillaume,
> >
> > Technically its possible to run a substantially streamlined version of
> > Kepler that omits all or most of the actors and their supporting jar
> files.
> > However, there are many relatively hidden dependencies that may be hard
> to
> > resolve, and we do not currently have a mechanism for supporting a
> trimmed
> > down version like this -- but we will as the modularization work I
> described
> > earlier matures.  That said, you can probably exclude most of the jar
> files
> > in lib/jar as long as you include the lib/jar/base-jars set (which are
> > required by the core) and omit all of the java code for actors from your
> > build.  You'll have to configure this manually at this point, which means
> > tracking down all of the actor code which is spread across many java
> > packages, but I know it has been done in the past.  I would expect the
> > process to be time consuming until we finish the modularization process
> and
> > clarify all of the dependencies in the code.  Hope this helps you out,
> >
> > Matt
> >
> > On Wed, Nov 5, 2008 at 1:23 PM, tog <guillaume.alleon at gmail.com> wrote:
> >>
> >> Hi Matt
> >>
> >> Thanks for your quick answer.
> >> I will try this new build system in a day or two.
> >>
> >> Could in the meantime someone comment on how to be able to have a
> >> custom Kepler with only my actor i.e. removing existing actors and how
> >> to add a new actor and its third-party jars.
> >>
> >> Thanks and Best Regards
> >>
> >> Guillaume
> >>
> >>
> >> On Thu, Nov 6, 2008 at 2:17 AM, Matt Jones <jones at nceas.ucsb.edu>
> wrote:
> >> > Hi,
> >> >
> >> > On Wed, Nov 5, 2008 at 8:43 AM, tog <guillaume.alleon at gmail.com>
> wrote:
> >> >>
> >> >> Dear all,
> >> >>
> >> >> Sorry for asking again some more questions :)
> >> >>
> >> >> I have an actor that is using plenty of third-party jars (a lot of
> >> >> them may collide some existing ones). For example my actor is using
> >> >> jaxb with a different version than the one located in
> >> >> /Applications/Kepler-1.0.0/Kepler.app/Kepler/lib/jar/
> >> >>
> >> >> I am therefore wondering if there is a way to isolate the loading of
> >> >> dependencies on a per actor basis ?
> >> >
> >> > We're working on such a mechanism now.  We've recognized this
> >> > conflicting
> >> > jar problem for a while, and now we are working on a new, modular
> system
> >> > in
> >> > which actors or packages of actors are created in independent modules
> >> > and
> >> > can specify their own jar dependencies, even if they have conflicting
> >> > version requirements for a particular jar file.  This is being
> >> > accomplished
> >> > through the use of independent ClassLoaders for each of the modules.
> >> > Unfortunately, we are not done with this work yet and so it is not yet
> >> > in
> >> > the default build for kepler.
> >> >
> >> > However, if you want to experiment with our new build system, you
> could
> >> > try
> >> > the alternate build which handles these module dependency conflicts.
>  It
> >> > is
> >> > a work in progress and is likely to still change substantially --
> we're
> >> > actively working on it -- so be prepared for problems if you try this
> >> > system.  Nevertheless, you might find it useful.  To see the alternate
> >> > build
> >> > instructions, visit this page:
> >> >
> >> >
> https://dev.kepler-project.org/developers/teams/build/documentation/the-new-build-system
> >> > Feedback on how that system works for you would be appreciated.
> >> >
> >> >
> >> >>
> >> >> I have then noticed this file .classpath.default. My understanding is
> >> >> that this file is containing all the (existing) jars required for the
> >> >> existing actors.
> >> >> Does that mean that removing all  these files + the actors definition
> >> >> located in /Applications/Kepler-1.0.0/Kepler.app/Kepler/kar/actors/
> >> >> will lead to  a kind of "empty" Kepler ?
> >> >>
> >> >> Therefore adding an actor is just:
> >> >>  - creating a kar file putting in
> >> >> /Applications/Kepler-1.0.0/Kepler.app/Kepler/kar/actors/
> >> >>  - adding the adequate dependencies in
> >> >> /Applications/Kepler-1.0.0/Kepler.app/Kepler/lib/jar
> >> >>  - modifying accordingly the .classpath.default file
> >> >>
> >> >> Am I right ?
> >> >
> >> > No, the .classpath.default file is only used for the eclipse build.
> >> > Modifying it will not really affect how the ant build works.
> >> >
> >> >>
> >> >>
> >> >> There is then still this issue of being able to use different jars of
> >> >> the same tools for different actors ?
> >> >
> >> > Right -- having the build and runtime system support actors that
> require
> >> > conflicting jar files is a major requirement of the new build and
> >> > runtime
> >> > system.  We'll get it worked out as soon as possible.
> >> >
> >> > Matt
> >> >
> >> > --
> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> > Matthew B. Jones
> >> > Director of Informatics Research and Development
> >> > National Center for Ecological Analysis and Synthesis (NCEAS)
> >> > UC Santa Barbara
> >> > jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
> >> > http://www.nceas.ucsb.edu/ecoinfo
> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> >
> >>
> >>
> >>
> >> --
> >> PGP KeyID:C1A0A73F  FingerPrint:A4A2 73C0 E7D4 6437 8185  D05E ECF2
> >> AD84 C1A0 A73F
> >> http://cheztog.blogspot.com
> >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Matthew B. Jones
> > Director of Informatics Research and Development
> > National Center for Ecological Analysis and Synthesis (NCEAS)
> > UC Santa Barbara
> > jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
> > http://www.nceas.ucsb.edu/ecoinfo
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
>
>
>
> --
> PGP KeyID:C1A0A73F  FingerPrint:A4A2 73C0 E7D4 6437 8185  D05E ECF2
> AD84 C1A0 A73F
> http://cheztog.blogspot.com
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20081106/57b1f2de/attachment.html>

More information about the Kepler-users mailing list