[kepler-dev] where do actor packages meant to work with Kepler 1.0 go in the repository?

Timothy McPhillips tmcphillips at mac.com
Thu Jun 26 14:53:39 PDT 2008


Hi Christopher,

Thanks for your comments!

It definitely sounds like no one likes the idea of a huge, growing  
branch for each Kepler release, or the idea of lots of branches.

My understanding is that you favor an approach like S2, based on an  
actor SDK, but where the complex dependencies are managed  
automatically.  I do like that!  I'm looking forward to hearing how  
your work with Maven goes.

All -- So far it seems that everyone favors having (actor package and  
library) extensions stored in some place distinct from the core  
Kepler code, i.e. not scattered throughout the Kepler source tree.   
For those of us who want share the sources for their extensions via  
the Kepler repository, is there anyone who does not like Chad's  
proposal of having an 'extension' directory under which these  
extensions could reside (e.g. extensions/ppod, extensions/comad, etc)?

Thanks!

Tim

On Jun 26, 2008, at 10:53 AM, Christopher James Tuot wrote:

> Hi Tim,
>
> Please find my comments below:
>
>> *** Solutions? ***
>>
>> S1.  On the surface this problem sounds like one that could be  
>> solved with branches.  And I believe it possibly could, and that  
>> branches likely will be involved in some way (for example, we will  
>> still want to provide bug fixes to the 1.0-compatible version of  
>> the pPOD actors when we're working on the 1.1-compatible release).
>
> If I understood you correctly, the implementation of the pPOD  
> actors did not require any change to the Kepler code meaning that  
> this is not really a parallel implementation to the Kepler trunk.  
> Therefore, I believe a branch would not really be the solution.  
> Moreover, what about other groups developing actors, creating a  
> branch for pPOD would logically imply to create a branch for each  
> group or project developing new actors for Kepler.  This sound like  
> chaos to me.
>
>> However, is this how we want to treat the Kepler 1.0 release  
>> branch in the repository?  Do we want to be checking hundreds of  
>> source files into the Kepler 1.0 release branch indefinitely, and  
>> almost certainly introducing new bugs and instabilities there?
>
> In my opinion, definitively no.
>
>>
>> S2.  An alternative would be to create a separate source tree for  
>> pPOD in the svn repository (as a peer to kepler, for example).   
>> The build system would not include this 'extension' when compiling  
>> the Kepler java sources.  Instead, we might build the pPOD package  
>> against the Kepler 1.0 release jar itself.  This approach might  
>> scale better and enable everyone providing their users 1.0- 
>> compatible actors to share their work with the community through  
>> the Kepler repository without requiring that their code work with  
>> the current revision of Kepler.
>>
>> The problem with this second approach is that it might not be so  
>> easy to build against the current revision of Kepler, should one  
>> choose to do so (and as we likely will between releases of the  
>> pPOD package).  At least, not without building the Kepler jar each  
>> time.
>
> This is exactly what what my group at DFKI has been doing up to now  
> and I strongly advice not to go in that direction. By doing this,  
> we have run into the common Java JAR hell. Further more, updating  
> to a new version of Kepler almost always implied spending an  
> incredible amount of time.
>
>> S3.  A variant of S2 would be to enable developers to tell the  
>> build system to optionally include extensions in the build.  With  
>> the extensions stored as peers to the kepler directory in the  
>> repository, developers could choose which extensions to check out,  
>> and specify different branches or tags for Kepler and for each  
>> extension checked out.
>>
>> This final approach is the one we currently use at UCD.  We store  
>> our Kepler extensions in our own repository at UCD and use a  
>> tweaked version of Kepler's standard build.xml file that supports  
>> extensions in this way. One nice feature of this approach is that  
>> it does not require all extensions to be stored in the same  
>> repository.  The problem with our current approach is that it is  
>> harder for us to share our extensions with the rest of the  
>> community.  We'd much rather use the Kepler repository, but at the  
>> moment we can't as explained above.  In short...
>
> I think there is definitively the need for a new Build system.  
> However I think this is still for development involving  
> modifications in the "core" of the Kepler engine. II already  
> discussed the topic with some guys here at UC Davis and also with  
> Tristan King and we liked the idea of trying to develop some sort  
> of Kepler Actor SDK to support efficient Kepler actor developing  
> without having to compile every time the whole code.
>
> My group at DFKI is currently trying to go in that direction using  
> Maven. Tim, this goes in the direction of solution S2 but  
> preventing to run in the JAR hell. With Maven, dependencies are  
> clear meaning that you know exactly against which version of Kepler  
> you are compiling. Compiling against another version only requires  
> to change one dependency line specifying which version of Kepler  
> you want to use. I will let you know when we have more concrete  
> results.
>
> Best regards,
>
> Christopher Tuot
>
> --
> ______________________________________________________________
> Dipl.-Ing. Christopher Tuot
> DFKI GmbH (German Research Center for Artificial Intelligence)
> Knowledge Management Department
> POBox 2080, 67608 Kaiserslautern, Germany
> fon:   +49(0)631 / 20575 - 127
> fax:   +49(0)631 / 20575 - 103
> mail:  christopher.tuot at dfki.de
> web:   http://www.dfki.de
> ______________________________________________________________
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern
>
> Geschaeftsfuehrung:
> Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr.  
> Walter Olthoff
>
> Vorsitzender des Aufsichtsrats:
> Prof. Dr. h.c. Hans A. Aukes
>
> Amtsgericht Kaiserslautern, HRB 2313
> ______________________________________________________________
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080626/ce54bb04/attachment.htm 


More information about the Kepler-dev mailing list