cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: samples
Date Tue, 27 Jul 2010 21:26:37 GMT
On Monday 26 July 2010 5:08:51 pm Benson Margulies wrote:
> On Mon, Jul 26, 2010 at 3:21 PM, Daniel Kulp <dkulp@apache.org> wrote:
> > On Monday 26 July 2010 1:23:09 pm Benson Margulies wrote:
> >> How about, in that case:
> >> 
> >> 1: samples have an aggregating parent.
> >> 2: build creates that parent by filtering from template, sticking in
> >> the right versions.
> >> 3: invoker used to launch the whole boiling lot of them via the
> >> aggregate, so as to get parallelism.
> > 
> > This could be achieved now just by adding:
> > <module>distribution/src/main/release/samples</module>
> 
> Here's my point of disagreement. It is valuable for the samples to
> look reasonably legible and self-contained when they land in the
> distro. If all of their POMs reference the main CXF Parent, that is
> lost, since the main CXF Parent (for Eclipse reasons alone) is far
> from simple and legible.

Would you be ok with using a Maven import scope to just import the 
dependencyManagement sections to resolve the versions?

I've just committed that to let you see it.    Basically, the samples 
aggregator pom doesn't have a parent now.    It import scopes the cxf-parent 
just to pull in the versions, nothing else. 

That said, there is only about 1/2 dozen or so versions that are defined 
explicitely in the samples poms and not pulled in via deps.   Definitely less 
than I thought there were.   I might be OK with defining those versions in the 
aggregator pom since there aren't many of them.

Anyway, let me know if that looks better.     :-)

Dan
   


> 
> > to the top level pom.   That said, if we went this route, I'd probably
> > move the sample dir from distribution/src/main/release to a top level
> > dir and update the assemblies.  Thus, they aren't hidden down deep
> > inside the distribution stuff.
> > 
> > In either case, with them running (well, building) as part of the
> > "deploy"builds now (due to -Peverything used there), they are at least
> > built in hudson now.   That's a start.
> > 
> > Dan
> > 
> >> In my opinion, busting the samples should be a *big deal*, and making
> >> all builds run them is thus higher on my list than some of the more
> >> obscure system tests. But I can see the argument the other way around.
> >> 
> >> On Mon, Jul 26, 2010 at 11:41 AM, Daniel Kulp <dkulp@apache.org> wrote:
> >> > On Monday 26 July 2010 11:10:25 am Benson Margulies wrote:
> >> >> Dan,
> >> >> 
> >> >> I see you implemented another plan from my invoker trick.
> >> >> 
> >> >> Do you want to flush that altogether? I originally thought that it
> >> >> was a good idea because it ran the samples in a 'clean' (user-like)
> >> >> invocation of maven, but for all I know you've arranged the same
> >> >> value by careful (non)use of parents.
> >> > 
> >> > I'm undecided about the invoker thing right now.    I basically wanted
> >> > a solution that would also address:
> >> > 
> >> > https://issues.apache.org/jira/browse/CXF-2848
> >> > 
> >> > which requires real version numbers in the poms and have those poms in
> >> > the reactor as part of the release process so those version numbers
> >> > would get updated.
> >> > 
> >> > 
> >> > Doing it this way also address a couple other things:
> >> > 
> >> > 1) With maven 3, having it invoked directly as part of the reactor
> >> > allows the parallel mode to work with it.   With 25+ poms, that can
> >> > speed things up quite a bit.
> >> > 
> >> > 2) I also didn't really want it as part of the everyday developer
> >> > builds at this point.  Builds take long enough as is.
> >> > 
> >> > That said, I did let it inherit from the CXF parent pom.   Since all
> >> > the demos depend on some cxf thing, the parent pom will be needed
> >> > anyway. The main thing I kind of wanted to do though was to make sure
> >> > the versions that the demos use are the same as what the runtime uses
> >> > and we test with.    For example, several of the demos were actually
> >> > still using jsr311 0.8 even though we haven't used that since the 2.1
> >> > branch. Making it inherit the versions from the cxf-parent pom at
> >> > least makes sure the versions are the same and keeps the versions in
> >> > a single place.
> >> > 
> >> > 
> >> > --
> >> > Daniel Kulp
> >> > dkulp@apache.org
> >> > http://dankulp.com/blog
> > 
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message