[kepler-users] More questions on configuration

[Matt Jones]

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-users/attachments/20081105/88c1f5a6/attachment-0001.html>