[kepler-dev] Re: [SDM-SPA] RFC new directory structure

[Edward A Lee]

This is again something that can be easily dealt with by using a 
"configuration".
We have, for example, a separate release of HyVisual that presents just the
hybrid system modeling capabilities.  You could do the same for SPA, but
still use a completely shared development tree.

You can grab the HyVisual release off the Ptolemy website if you want to
take it for a spin:

http://ptolemy.eecs.berkeley.edu/hyvisual/

A "configuration" is actually a Ptolemy II model...
We typically build one by editing the XML files directly, but it wouldn't
be hard to adapt Vergil to create a good "configuration editor"...

Edward


At 09:17 AM 3/18/2004 -0800, Terence Critchlow wrote:
>Hi Chad,
>
>It is a requirement that we (SPA) are able to create a release for the 
>work done under the funding we receive. Simply participating in the 
>collaboration is not sufficient. And pointing to the Kepler release and 
>indicating we contributed to it is also not sufficient. I would expect the 
>Kepler release to include this code as well, and I see that as one of the 
>major advantages of sharing the CVS repository. From my perspective, the 
>goal of participating in the collaboration is to efficiently leverage 
>expertise and code across projects - it is not to loose the project identity.
>
>Terence
>
>At 08:59 AM 3/18/2004 -0800, Chad Berkley wrote:
>>I don't really like the idea of chopping kepler up into smaller pieces 
>>for releases.  I can see doing this if there is some gigantic jar file 
>>that's used for only one pipeline or something like that, but in general, 
>>I would like to see Kepler packaged and distributed as one product.  I 
>>think we run the risk of having a "seek kepler" and a "spa kepler" and a 
>>whatever else kepler which is exactly what we were trying to avoid with 
>>the collaboration in the first place.  So unless there is a really good 
>>reason for doing so, I would like to propose there there only b e one 
>>version of kepler per release and that it includes everyones 
>>contributions whether they are relevant to everyone who might use kepler 
>>or not.
>>
>>chad
>>
>>
>>>>
>>>>Regarding jar files in lib/, yes you're right, we didn't discuss
>>>>dividing that up by subproject.  Do you see a need to?
>>>We may want to since not all projects may want to have all lib code on 
>>>all occasions.
>>>Specail
>
>_______________________________________________
>kepler-dev mailing list
>kepler-dev at ecoinformatics.org
>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev

------------
Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal