openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-364) maven build order is incorrect
Date Tue, 18 Sep 2007 21:27:44 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528572
] 

Michael Dick commented on OPENJPA-364:
--------------------------------------

In a JSE environment they will need the spec jars, or a copy of j2ee.jar from an app server.


The main reason I didn't include the spec jars as "normal" dependencies is that they're rather
tough to remove. If another maven project depends on OpenJPA we would always add the Geronimo
spec jars to the classpath. If for some reason that project didn't want the Geronimo implementation
they'd have to manipulate maven so that a different version is loaded first. Theoretically
this is as simple as listing the other dependency first, but that might depend on the maven
dependency resolver. If the user wants to use the Geronimo spec jars then they don't have
to do anything. 

The way it currently works the user has to provide their own version of the spec jars (or
j2ee.jar). They can add whichever dependency(ies) they want into pom.xml and won't have to
worry about the order on the classpath. The only reason I can think of for doing this is if
you're running the app in JSE to test it prior to deploying on an app server and you want
to use the same version of the spec jars that are part of the app server. This is probably
a corner case, but I can be persuaded otherwise. 

All that being said I'd prefer to include the spec jars as "normal" dependencies. I think
that the Geronimo implementation is TCK compliant and there shouldn't be any difference between
vendors in the spec jars. Unless there are other reasons to leave them out I'll go ahead and
put them back in. 


> maven build order is incorrect
> ------------------------------
>
>                 Key: OPENJPA-364
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-364
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: build / infrastructure
>    Affects Versions: 1.1.0
>            Reporter: Kevin Sutter
>             Fix For: 1.1.0
>
>         Attachments: OPENJPA-364-3.patch, OPENJPA-364.patch, OPENJPA-364.patch
>
>
> From the dev mailing list. (http://www.nabble.com/order-of-build-modules-isn%27t-quite-right-tf4416976.html).
> In short, we are building the aggregate jar before we have built the 1.5 modules.  Details
follow...  BTW, this only seems to apply to the trunk (1.1.0 snapshot).  
> ============================================================
> > Yes, that sounds about right.  This just recently started to happen...
> Maybe if we create two profiles, one for 1.4 only and one for 5.0, and
> just enable the appropriate one of them? This would increase
> repetition (we could address that with XML entities, of course), but
> might get things to run right.
> - Hide quoted text -
> -Patrick
> On 9/10/07, Kevin Sutter <kwsutter@gmail.com> wrote:
> > On 9/10/07, Patrick Linskey <plinskey@gmail.com> wrote:
> > >
> > > > So, I'm not sure what has to change in our pom.xml files to allow one
to
> > > > build, package, and install our aggregrate jar on the first try.  Any
> > > maven
> > > > experts that can help with this?
> > >
> > > Sadly, Marc probably knows the most, and he's on top of Mt Kilimanjaro
> > > or thereabouts right now.
> >
> >
> > Yep, and my resident build expert (Mike) is on vacation this week as well..
> > :-)
> >
> > Might this have started happening with the recent move from how the
> > > dependencies are set up, for the purposes of keeping our mvn
> > > dependencies clean?
> >
> >
> > Yes, that sounds about right.  This just recently started to happen...
> >
> > Kevin
> >
> > -Patrick
> > >
> > > On 9/10/07, Kevin Sutter <kwsutter@gmail.com> wrote:
> > > > Hi,
> > > > I'm the first to admit that I'm not a maven build expert, so I'm not
> > > exactly
> > > > sure what needs to be changed.  But, here's the problem...
> > > >
> > > > If I only want to build the artifacts and install them into my maven
> > > > repository, I issue the following maven command.  (BTW, this only
> > > happens on
> > > > a truly clean environment.  Either just pull the contents from svn or
do
> > > a
> > > > separate "mvn clean" first like I demonstrate below.)
> > > >
> > > > > mvn clean
> > > > > mvn install
> > > >
> > > > But, when I do this, I get the following build report.  Although
> > > everything
> > > > builds okay, look at the order of the modules getting built.  We are
> > > > building the aggregrate jar and distribution jars before we build kernel
> > > 1.5,
> > > > jpa, and jpa jdbc.  Thus, the aggregrate jar that we build does not have
> > > all
> > > > of the required contents (because I have a clean environment to start
> > > with).
> > > >
> > > > [INFO]
> > > > ------------------------------------------------------------------------
> > > > [INFO] Reactor Summary:
> > > > [INFO]
> > > > ------------------------------------------------------------------------
> > > > [INFO] OpenJPA ............................................... SUCCESS
[
> > > > 1.328s]
> > > > [INFO] OpenJPA Utilities ..................................... SUCCESS
[
> > > > 12.265s]
> > > >
> > > > [INFO] OpenJPA Kernel ........................................ SUCCESS
[
> > > > 17.703s]
> > > >
> > > > [INFO] OpenJPA JDBC .......................................... SUCCESS
[
> > > > 10.063s]
> > > >
> > > > [INFO] OpenJPA XML Store ..................................... SUCCESS
[
> > > > 0.969s]
> > > > [INFO] OpenJPA Aggregate Jar ................................. SUCCESS
[
> > > > 17.218s]
> > > >
> > > > [INFO] OpenJPA Distribution .................................. SUCCESS
[
> > > > 19.860s]
> > > >
> > > > [INFO] OpenJPA Integration Tests ............................. SUCCESS
[
> > > > 0.015s]
> > > > [INFO] OpenJPA Examples Integration Tests .................... SUCCESS
[
> > > > 0.016s]
> > > > [INFO] OpenJPA JPA TCK Integration Tests ..................... SUCCESS
[
> > > > 0.016s]
> > > > [INFO] OpenJPA Kernel 1.5 .................................... SUCCESS
[
> > > > 0.718s]
> > > > [INFO] OpenJPA JPA ........................................... SUCCESS
[
> > > > 4.719s]
> > > > [INFO] OpenJPA JDBC 1.5 ...................................... SUCCESS
[
> > > > 0.625s]
> > > > [INFO] OpenJPA JPA JDBC ...................................... SUCCESS
[
> > > > 17.437s]
> > > >
> > > > [INFO] OpenJPA Persistence Examples .......................... SUCCESS
[
> > > > 0.547s]
> > > > [INFO]
> > > > ------------------------------------------------------------------------
> > > > [INFO]
> > > > ------------------------------------------------------------------------
> > > >
> > > > I looked at our pom.xml at our root level of trunk and I see the
> > > following
> > > > <module> listing, which maps to the order of the build above:
> > > >
> > > >     <modules>
> > > >         <module>openjpa-lib</module>
> > > >         <module>openjpa-kernel</module>
> > > >         <module>openjpa-jdbc</module>
> > > >         <module>openjpa-xmlstore</module>
> > > >         <module>openjpa-all</module>
> > > >         <module>openjpa-project</module>
> > > >         <module>openjpa-integration</module>
> > > >     </modules>
> > > >
> > > > The rest of our modules are listed under the jdk1.5 profile and don't
> > > get
> > > > built until after these 1.4 modules are built.  If I re-run the exact
> > > same
> > > > invocation (without starting from scratch with the "mvn clean"), then
> > > > everything works since the 1.5 modules are all built and pulled into the
> > > > aggregrate jar.
> > > >
> > > > So, I'm not sure what has to change in our pom.xml files to allow one
to
> > > > build, package, and install our aggregrate jar on the first try.  Any
> > > maven
> > > > experts that can help with this?
> > > >
> > > > Thanks,
> > > > Kevin
> > > >
> > >
> > >
> > > --
> > > Patrick Linskey
> > > 202 669 5907
> > >
> >

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message