[SDM-SPA] Re: [kepler-dev] moving edu.ncsu to org.sdm.spa

David Buttler buttler1 at llnl.gov
Wed Apr 7 14:29:58 PDT 2004


Hi,

I don't see any problem with keeping the source files around in a 
separate third-part directory,  if you foresee a need to modify them in 
the future.  I would like to throw my two cents in and suggest that 
third-party code not be in the same source directory as the code Kepler 
develops.  At the very least, there could be different licenses 
associated with each bit of external code, and that might have to be 
managed in some way.  I have read a lot and I still am not sure how GPL 
and BSD-style licenses interact. [of course, even putting GPL code into 
a JAR file may not solve that problem]

We could go overboard in the source direction and start to include 
Xerces src, Axis source, WSIF source, and Ptolemy source in the CVS 
repository. I would say that if there is any reasonable chance that we 
might modify the source we should keep it in the repository, otherwise 
it would be more convenient to keep a known version of the associated 
JAR file.

One final pair of pennies: my understanding of the Java naming 
convention is that packages follow a globally unique naming convention.  
So if there is a 'top-level' or cross-project shared set of sources it 
should have a name such as 'org.kepler.util' rather than just the name 
'util' Hmm.. I don't like that name either since we don't own 
www.kepler.org. 'org.ecoinformatics.util' would solve that problem, but 
it focuses on eco-informatics instead of a generic scientific data 
management name.

Dave

Matt Jones wrote:

> Hi,
>
> Why do you want to take source code in a perfectly good, 
> version-friendly text file and put it in a binary file?  Not only 
> would we have to unjar the file to compile or make changes, but the 
> jar file would also not be amenable to using "cvs diff" to track 
> differences becaue the jar is binary.  I think it is far better to 
> store all source in their regular source code format, and then build 
> any needed jars on the fly as part of the build process.  This reduces 
> download time, increases transparency of the source, and facilitiates 
> version comparisons.
>
> Because the source you refer to is from a 3rd party, we may want to 
> separate it out into anothern directory tree to differentiate it, but 
> I think the the package name alone should be sufficient to keep it in 
> a separate tree.
>
> In general I think we should strive to limit and reduce the number of 
> binary files, including jar files, that are checked into the repository.
>
> Just my $.02.
>
> Matt
>
> Xiaowen Xin wrote:
>
>> Hi Efrat,
>>
>> Ok, I think jar'ing UUIDGen.java may be the best way to do it, though it
>> feels a bit silly to have a single file in a jar library =)
>>
>> What we could do in the future is to jar up all the third party source
>> files, such as this, that don't come in a jar already, into one single
>> jar in lib/ called say thirdparty.jar.
>>
>>
>> Xiaowen
>>
>>
>> On Tue, 2004-04-06 at 22:40, Efrat Jaeger wrote:
>>
>>> The XSLT should probably go under spa as it was contributed by 
>>> Ilkay. As for
>>> the UUID, it is neither GEON nor SPA, so it should either go under a 
>>> generic
>>> utilities folder as Ilkay suggested or I can jar it and put it under 
>>> lib.
>>>
>>> - Efrat
>>>
>>>
>>>> Efrat: you're listed as the author for
>>>> src/org/geon/OpenDBConnection.java, which is the only non-spa file I
>>>> could find that uses the code in util/.  Would it be okay for me to 
>>>> move
>>>> what's now in src/util into org/sdm/spa/util/?  Alternatively, we 
>>>> could
>>>> move those two files into org/geon/util/.
>>>
>>>
>>>
>>
>> _______________________________________________
>> kepler-dev mailing list
>> kepler-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>
>



More information about the Kepler-dev mailing list