On Monday 26 July 2010 5:08:51 pm Benson Margulies wrote: > On Mon, Jul 26, 2010 at 3:21 PM, Daniel Kulp <[email protected]> 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 <[email protected]> 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 > >> > [email protected] > >> > http://dankulp.com/blog > > > > -- > > Daniel Kulp > > [email protected] > > http://dankulp.com/blog -- Daniel Kulp [email protected] http://dankulp.com/blog
