You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2010/07/26 17:10:25 UTC
samples
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.
--benson
Re: samples
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 26 July 2010 5:08:51 pm Benson Margulies wrote:
> On Mon, Jul 26, 2010 at 3:21 PM, Daniel Kulp <dk...@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 <dk...@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
Re: samples
Posted by Benson Margulies <bi...@gmail.com>.
On Mon, Jul 26, 2010 at 3:21 PM, Daniel Kulp <dk...@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 <dk...@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
>
Re: samples
Posted by Daniel Kulp <dk...@apache.org>.
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>
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 <dk...@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
Re: samples
Posted by Benson Margulies <bi...@gmail.com>.
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.
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 <dk...@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
>
Re: samples
Posted by Daniel Kulp <dk...@apache.org>.
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