You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "David Blevins (JIRA)" <ji...@apache.org> on 2006/08/22 04:19:13 UTC
[jira] Created: (OPENJPA-29) Create aggregate jars of OpenJPA
Create aggregate jars of OpenJPA
--------------------------------
Key: OPENJPA-29
URL: http://issues.apache.org/jira/browse/OPENJPA-29
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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-29) Create aggregate jars of OpenJPA
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-29?page=comments#action_12433406 ]
Kevin Sutter commented on OPENJPA-29:
-------------------------------------
Never mind. :-) I guess I missed the intent of the openjpa-project integration -- must have been done under another JIRA report. I see that we are producing a zip file (openjpa-0.9.0-incubating-SNAPSHOT.zip) that contains all of our individual modules along with our runtime dependencies. Thanks!
> Create aggregate jars of OpenJPA
> --------------------------------
>
> Key: OPENJPA-29
> URL: http://issues.apache.org/jira/browse/OPENJPA-29
> Project: OpenJPA
> Issue Type: Task
> Reporter: David Blevins
> Assigned To: Marc Prud'hommeaux
>
> 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-29) Create aggregate jars of OpenJPA
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-29?page=comments#action_12433394 ]
Kevin Sutter commented on OPENJPA-29:
-------------------------------------
Marc, thanks for providing this new openjpa-all module and associated maven and ant artifacts. This is goodness (and required). But, reading through the original description of this report, have we completely resolved the issue yet? The item that is still missing is the jar that would contain all of OpenJPA along with it's runtime dependencies. I think this would go a long ways with user acceptance of OpenJPA. Reading through Patrick's earlier comments, it sounds like this JIRA report changed from a packaging issue to a build issue. Do we need to (re)open another JIRA report for the packaging issue?
Kevin
> Create aggregate jars of OpenJPA
> --------------------------------
>
> Key: OPENJPA-29
> URL: http://issues.apache.org/jira/browse/OPENJPA-29
> Project: OpenJPA
> Issue Type: Task
> Reporter: David Blevins
> Assigned To: Marc Prud'hommeaux
>
> 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-29) Create aggregate jars of OpenJPA
Posted by "Marc Prud'hommeaux (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-29?page=comments#action_12433466 ]
Marc Prud'hommeaux commented on OPENJPA-29:
-------------------------------------------
I figured that building an openjpa-all.jar that was an aggregate of all the individual openjpa-*.jar files was the best we could do. While we could have merged in the other dependencies (commons-collections.jar, commons-lang.jar, serp.jar), I would worry that this could introduce problems with incompatible versions of the libraries, especially with the popular ones (like the commons jars) that are also used by many popular containers and appservers. Furthermore, we also rely on the JTA and JCA jars, and I don't know if it is legal and/or wise for us to re-package those into aq single monolithic jar.
I figured building a zip with includes all the dependencies included would be sufficient for providing an easy way to obtain the dependencies.
> Create aggregate jars of OpenJPA
> --------------------------------
>
> Key: OPENJPA-29
> URL: http://issues.apache.org/jira/browse/OPENJPA-29
> Project: OpenJPA
> Issue Type: Task
> Reporter: David Blevins
> Assigned To: Marc Prud'hommeaux
>
> 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-29) Create aggregate jars of OpenJPA
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-29?page=comments#action_12430689 ]
Craig Russell 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. I can see both sides, i.e. -full means only the JPA contents, and -nodep means no external dependencies are necessary. As well as -full means fully operational with all dependencies included and -nodep means no dependencies are included. Are there other projects that ship stuff like this?
> openjpa-0.9.0-nodep.jar would extract to:
> - org/apache/openjpa/*/**.class
> - META-INF/* ............ (we still need to resolve the 'merge multiple files of the same name and locations (eg.. ProductDerivations) problem for this)
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.
> openjpa-0.9.0-full.jar would extract to:
> - org/apache/openjpa/*/**.class
> - thirdPartyJars.jar (many of these)
> - META-INF/* .......... (same issue as above)
> Like I said, not sure this is actually correct. Would the openjpa-*.jar files be there instead of the unpacked classes? Can someone with a bit more classloading acuity speak to that?
Second whtat David Blevins said (I'll paraphrase to be sure). There would not be any .jar files contained in the "complete" jar; all third party content would be directly loadable by the class loader.
To me, the major "watch out" in this scenario is if the user's application uses some of the same third party libraries as OpenJPA does. Have we thought through this scenario? How do we resolve conflicts between, say, the user's application use of commons-logging and OpenJPA's use of commons-logging?
But I still think it has value for the user who just wants to write "Hello JPA" and have stuff work, without going through the hassle of either manually downloading all dependent jars or setting up mvn or maven for their project. Much easier if you can just have a single jar file and run.
> Should the names actually be openjpa-nodep-0.9.0-SNAPSHOT.jar and openjpa-full-0.9.0-SNAPSHOT.jar?
Modulo the actual partial names, I think so. That is, the -full- belongs right after the openjpa and before the version numbers.
> Create aggregate jars of OpenJPA
> --------------------------------
>
> Key: OPENJPA-29
> URL: http://issues.apache.org/jira/browse/OPENJPA-29
> 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-29) Create aggregate jars of OpenJPA
Posted by "Bryan Noll (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-29?page=comments#action_12430349 ]
Bryan Noll commented on OPENJPA-29:
-----------------------------------
Comments originally on the dev list:
from myself:
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
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...
openjpa-0.9.0-nodep.jar would extract to:
- org/apache/openjpa/*/**.class
- META-INF/* ............ (we still need to resolve the 'merge multiple files of the same name and locations (eg.. ProductDerivations) problem for this)
openjpa-0.9.0-full.jar would extract to:
- org/apache/openjpa/*/**.class
- thirdPartyJars.jar (many of these)
- META-INF/* .......... (same issue as above)
Like I said, not sure this is actually correct. Would the openjpa-*.jar files be there instead of the unpacked classes? Can someone with a bit more classloading acuity speak to that? Should the names actually be openjpa-nodep-0.9.0-SNAPSHOT.jar and openjpa-full-0.9.0-SNAPSHOT.jar?
>From David Blevins in response (was inline):
I very well could have them backwards. As I said, "There's a naming convention for this kind of thing, hope I've got it right."
The classes from the third party jars would also have been extracted into the jar.
That'd be possible. You'd have to have one maven module for each jar and poke at the assembly plugin setup to not use the default name of <artifactId>-<version>-<assemblyName>.<archiveType>. The maven guys may know a better way.
> Create aggregate jars of OpenJPA
> --------------------------------
>
> Key: OPENJPA-29
> URL: http://issues.apache.org/jira/browse/OPENJPA-29
> 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (OPENJPA-29) Create aggregate jars of OpenJPA
Posted by David Jencks <da...@yahoo.com>.
On Aug 27, 2006, at 1:02 AM, Patrick Linskey (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/OPENJPA-29?
> 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.
thanks
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: http://issues.apache.org/jira/browse/OPENJPA-29
>> 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: http://issues.apache.org/jira/secure/
> Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/
> software/jira
>
>
[jira] Commented: (OPENJPA-29) Create aggregate jars of OpenJPA
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-29?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.
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.
> 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: http://issues.apache.org/jira/browse/OPENJPA-29
> 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (OPENJPA-29) Create aggregate jars of OpenJPA
Posted by "Marc Prud'hommeaux (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-29?page=all ]
Marc Prud'hommeaux resolved OPENJPA-29.
---------------------------------------
Resolution: Fixed
Assignee: Marc Prud'hommeaux
I've added an "openjpa-all" module which will manually aggregate the jars using an embedded ant task (we can't use the built-in assembly plugin since it will overwrite same-named files, which will break the services/ files).
Running "ant package" should now yield the following file:
openjpa-all/target/openjpa-all-0.9.0-incubating-SNAPSHOT.jar
> Create aggregate jars of OpenJPA
> --------------------------------
>
> Key: OPENJPA-29
> URL: http://issues.apache.org/jira/browse/OPENJPA-29
> Project: OpenJPA
> Issue Type: Task
> Reporter: David Blevins
> Assigned To: Marc Prud'hommeaux
>
> 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira