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

Christopher James Tuot christopher.tuot at dfki.de
Thu Jun 26 10:53:50 PDT 2008


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/9d53feb8/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080626/9d53feb8/attachment.bin 


More information about the Kepler-dev mailing list