openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [jira] Commented: (OPENJPA-29) Create aggregate jars of OpenJPA
Date Sun, 27 Aug 2006 17:32:43 GMT

On Aug 27, 2006, at 1:02 AM, Patrick Linskey (JIRA) wrote:

>     [ 
> page=comments#action_12430819 ]
> Patrick Linskey commented on OPENJPA-29:
> ----------------------------------------
>>> Do you have your descriptions backwards or am I misunderstanding
>>> what you're saying? Seems like 'nodep' would mean "no dependencies
>>> for this project are bundled into this jar" to me.
>>> IIUC (which I'm not sure that I do, so please correct me) then...
>> I would like to have some other projects to look at for exemplars.

Usually (e.g. with cglib) "full" means you include all the code from  
your project but not the code from other peoples projects, so the  
resulting jar has external dependencies.  "nodep" means you've  
included all the external dependencies as well, so the resulting jar  
can be run all by itself with "no" other external "dep"endencies.

> I think that it's possible that we're conflating two different  
> concepts here. I think that a -full and -nodep concept is useful  
> for packaging the OpenJPA release distributions -- -full has  
> everything that OpenJPA depends on, and -nodep is just the Spring  
> classes. However, I think that this JIRA issue is to do with  
> creating a Java jar that can be used in the classpath, not a  
> distribution package.
> Which takes us to...
>>> openjpa-0.9.0-full.jar would extract to:
>>> - org/apache/openjpa/*/**.class
>>> - thirdPartyJars.jar (many of these)
>>> - META-INF/* .......... (same issue as above
> I do not think that we want to create a jar with third-party  
> classes / jars in it. Instead, I think that if we have a 'openjpa- 
> full-0.9.0.jar', it should contain only OpenJPA classes and resources.

That's the normal meaning of "full".  A "nodep" jar is going to have  
other third-party classes in it unless you have a remarkably self- 
contained project.

david jencks

>> Yes, the multiple files of the same name and location needs
>> to be resolved. I'd prefer that we have no such things, and  
>> perhaps we
>> need another thread to discuss this topic in more detail.
> I do not think that we'll be able to get away from resources with  
> the same name -- it's like that for a reason. But, I'd love to be  
> corrected. Feel free to start another thread to debate.
>> Create aggregate jars of OpenJPA
>> --------------------------------
>>                 Key: OPENJPA-29
>>                 URL:
>>             Project: OpenJPA
>>          Issue Type: Task
>>            Reporter: David Blevins
>> Right now, we have a ton of jars, most of which are needed to  
>> actually run OpenJPA. For real users, we should create aggregates  
>> of these jars, for example:
>> - *openjpa-0.9.0-full.jar* - contains all openjpa code, openjpa- 
>> *.jars merged |
>> - *openjpa-0.9.0-nodep.jar* - contains all openjpa code and all  
>> third party dependency jars |
> -- 
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the  
> administrators: 
> Administrators.jspa
> -
> For more information on JIRA, see: 
> software/jira

View raw message