openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Russell (JIRA)" <>
Subject [jira] Commented: (OPENJPA-29) Create aggregate jars of OpenJPA
Date Sat, 26 Aug 2006 03:53:22 GMT
    [ ] 
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
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:
>             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:
For more information on JIRA, see:


View raw message