cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: samples
Date Mon, 26 Jul 2010 21:08:51 GMT
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.



>
> 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
>

Mime
View raw message