Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of kwsutter@gmail.com designates
 209.85.134.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=t0JWSjbya4I73wlbKVbpuXrnrlJHFM4CJp0wsFc7Qkwl4dgdcYof690gJ2NsM9YNFIOhfkNrbsyfaHr5rndH5M2NwfnDKn6QLM5P/4y8dFOz6CQXYE/I2JMa6d1/cznnqpQIdGPFsV73kNrFzE38N5jjUuncQKZF78S+dWGz8Ac=
Message-ID: <89c0c52c0709111507n33327e05pc8cdcc1d617fe93@mail.gmail.com>
Date: Tue, 11 Sep 2007 17:07:44 -0500
From: "Kevin Sutter" <kwsutter@gmail.com>
To: dev@openjpa.apache.org
Subject: Re: [jira] Commented: (OPENJPA-364) maven build order is incorrect
In-Reply-To: <16846C49-7E5D-4013-A94D-D63460F2A801@SUN.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_26351_896924.1189548464354"
References: <851542.1189537112043.JavaMail.jira@brutus>
	 <8425438.1189546592041.JavaMail.jira@brutus>
	 <89c0c52c0709111446w46a839cbk80f96cd5851adaec@mail.gmail.com>
	 <16846C49-7E5D-4013-A94D-D63460F2A801@SUN.com>

------=_Part_26351_896924.1189548464354
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 9/11/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>
> Hi Kevin,
>
> On Sep 11, 2007, at 2:46 PM, Kevin Sutter wrote:
>
> > Craig,
> > Was this comment directed towards the Issue itself or Catalina's
> > proposed
> > patch?
>
> Both. The original change was very similar to Catalina's patch:
> removing dependency from one place in the pom.xml to another. I just
> want to make sure that before we change it again we satisfy both
> requirements.


Okay.  I haven't tried Catalina's patch yet, but I do know that given the
current maven build and install process, my reference to the aggregate jar
only brings down the aggregate jar (and not all of the other dependent
jars).  This is how we want it to work.  But, we just need this aggregate
jar to have everything in it...  :-)

Kevin

Craig
> >
> > Kevin
> >
> > On 9/11/07, Craig Russell (JIRA) <jira@apache.org> wrote:
> >>
> >>
> >>     [
> >> https://issues.apache.org/jira/browse/OPENJPA-364?
> >> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> >> tabpanel#action_12526613]
> >>
> >> Craig Russell commented on OPENJPA-364:
> >> ---------------------------------------
> >>
> >> IIRC, the reason we recently changed the build was to avoid having
> >> the
> >> aggregate jar declare dependencies at runtime on the other jars,
> >> which leads
> >> to the situation where a user downloads the aggregate jar which
> >> then causes
> >> all of the other jars to be downloaded and added to the path as well.
> >>
> >> So, can you verify that if you have a simple project that has a
> >> dependency
> >> on the aggregate jar, the only jar downloaded is the aggregate jar?
> >>
> >>> 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
> >>>         Attachments: 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.5modules.  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.
> >>
> >>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>

------=_Part_26351_896924.1189548464354--