You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by David Jencks <da...@yahoo.com> on 2011/11/15 19:50:31 UTC
Re: svn commit: r1202350 - in /aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml
-1 to the <relative-path>s
We should not be embedding assumptions about how much of the project you checked out in the poms. You're basically expected to check out one module and build it. What problem are you trying to solve? I had no problem building the all-in-one after I built the parents and the eba-maven-plugin.
These paths are going to be completely wrong in a release tag.
This is not a technical veto since apparently both ways work, but I feel pretty strongly about this.
thanks
david jencks
On Nov 15, 2011, at 10:16 AM, dkulp@apache.org wrote:
> Author: dkulp
> Date: Tue Nov 15 18:16:00 2011
> New Revision: 1202350
>
> URL: http://svn.apache.org/viewvc?rev=1202350&view=rev
> Log:
> More maven 3 fixes and snapshot deploy fix
>
> Modified:
> aries/trunk/application/application-modeller/pom.xml
> aries/trunk/quiesce/pom.xml
>
> Modified: aries/trunk/application/application-modeller/pom.xml
> URL: http://svn.apache.org/viewvc/aries/trunk/application/application-modeller/pom.xml?rev=1202350&r1=1202349&r2=1202350&view=diff
> ==============================================================================
> --- aries/trunk/application/application-modeller/pom.xml (original)
> +++ aries/trunk/application/application-modeller/pom.xml Tue Nov 15 18:16:00 2011
> @@ -22,7 +22,7 @@
> <groupId>org.apache.aries</groupId>
> <artifactId>java5-parent</artifactId>
> <version>0.5-SNAPSHOT</version>
> - <relativePath />
> + <relativePath>../../parent/default-parent/java5-parent</relativePath>
> </parent>
>
> <groupId>org.apache.aries.application</groupId>
>
> Modified: aries/trunk/quiesce/pom.xml
> URL: http://svn.apache.org/viewvc/aries/trunk/quiesce/pom.xml?rev=1202350&r1=1202349&r2=1202350&view=diff
> ==============================================================================
> --- aries/trunk/quiesce/pom.xml (original)
> +++ aries/trunk/quiesce/pom.xml Tue Nov 15 18:16:00 2011
> @@ -19,7 +19,7 @@
> <parent>
> <groupId>org.apache.aries</groupId>
> <artifactId>java5-parent</artifactId>
> - <version>0.4</version>
> + <version>0.5-SNAPSHOT</version>
> <relativePath>../parent/default-parent/java5-parent</relativePath>
> </parent>
>
> @@ -28,6 +28,7 @@
> <artifactId>quiesce</artifactId>
> <name>Apache Aries Quiesce</name>
> <packaging>pom</packaging>
> + <version>0.3.1-SNAPSHOT</version>
>
> <description>
> Quiesce support for Aries - reactor pom
>
>
Re: relativePath thing..... was Re: svn commit: r1202350 - in
/aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml
Posted by Jeremy Hughes <hu...@apache.org>.
On 16 November 2011 16:15, Daniel Kulp <dk...@apache.org> wrote:
> On Wednesday, November 16, 2011 3:40:22 PM Jeremy Hughes wrote:
>> On 16 November 2011 01:49, Daniel Kulp <dk...@apache.org> wrote:
>>
>> > tackling the first part. :-) I also *prefer* that it work behind a
>> > reasonably setup proxy/firewall (read: no snapshot deps not part of the
>> > build), but that is definitely tertiary.
>>
>> I'm afraid I can't help here much as I don't have these proxy/firewall
>> restrictions. What do you suggest when a new feature / bug fix depends
>> on a bug fix to a dependency outside Aries? A snapshot dependency is
>> often needed for this until the dependency project is released.
>
> Like I said, kind of tertiary at this point. Call it a stretch goal. :-)
> In general, I discourage use of SNAPSHOTS unless we know a release of said
> snapshot is imminent (community is in final preparations or similar). If
> it's a snapshot of another Apache project, I'm also usually a little more
> lenient as anyone behind said firewall at least be able to get those sources
> and build it if they can get the Aries sources.
>
>
>> > On a side note: it *really* bothers me that there is work that has been
>> > done on a branch that is not reflected on trunk. IMO, trunk should
>> > always reflect the most up-to-date status of the code.
>>
>> If you're referring to the oct-2011-release branch, sorry I'm getting
>> to it. I need to release 0.4.1 of blueprint-core, blueprint-cm,
>> blueprint-bundle and blueprint-itests. Either I can merge the branch
>> into trunk then create a new branch for the release, or I can do the
>> release from the existing branch then merge. In fact I'm minded to do
>> the former. Thoughts?
>
> Doesn't really matter to me. I've already started porting back all the
> changes to trunk and getting version numbers updated and such. It's NOT an
> easy port back so it's taking a little time. I should have it done in a few
> hours though. Once we released 0.4 of things, Nexus wiped out the 0.4-
> SNAPSHOT's from the snapshot repo so I need to go through all the poms and
> make sure they use the 0.4 release version and such. Not a big deal, but it
> takes time.
>
> One more point though: on any branch that a developer is expected to run "mvn
> install", the version number in the pom should ALWAYS be a SNAPSHOT version,
> never a release version. The oct branch violates that in several places,
> but I'm not sure if anyone would consider that branch a branch for developers.
Right, the oct-2011-release was intended as a release manager only branch.
>
> Dan
>
>
>
>
>
>> > Anyway, if anyone else has any input into this, feel free to add their
>> > thoughts!
>>
>> Thanks for bringing all this up. I certainly wasn't aware of some of this.
>>
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org
>> > http://dankulp.com/blog
>> > Talend - http://www.talend.com
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
Re: relativePath thing..... was Re: svn commit: r1202350 - in /aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday, November 16, 2011 3:40:22 PM Jeremy Hughes wrote:
> On 16 November 2011 01:49, Daniel Kulp <dk...@apache.org> wrote:
>
> > tackling the first part. :-) I also *prefer* that it work behind a
> > reasonably setup proxy/firewall (read: no snapshot deps not part of the
> > build), but that is definitely tertiary.
>
> I'm afraid I can't help here much as I don't have these proxy/firewall
> restrictions. What do you suggest when a new feature / bug fix depends
> on a bug fix to a dependency outside Aries? A snapshot dependency is
> often needed for this until the dependency project is released.
Like I said, kind of tertiary at this point. Call it a stretch goal. :-)
In general, I discourage use of SNAPSHOTS unless we know a release of said
snapshot is imminent (community is in final preparations or similar). If
it's a snapshot of another Apache project, I'm also usually a little more
lenient as anyone behind said firewall at least be able to get those sources
and build it if they can get the Aries sources.
> > On a side note: it *really* bothers me that there is work that has been
> > done on a branch that is not reflected on trunk. IMO, trunk should
> > always reflect the most up-to-date status of the code.
>
> If you're referring to the oct-2011-release branch, sorry I'm getting
> to it. I need to release 0.4.1 of blueprint-core, blueprint-cm,
> blueprint-bundle and blueprint-itests. Either I can merge the branch
> into trunk then create a new branch for the release, or I can do the
> release from the existing branch then merge. In fact I'm minded to do
> the former. Thoughts?
Doesn't really matter to me. I've already started porting back all the
changes to trunk and getting version numbers updated and such. It's NOT an
easy port back so it's taking a little time. I should have it done in a few
hours though. Once we released 0.4 of things, Nexus wiped out the 0.4-
SNAPSHOT's from the snapshot repo so I need to go through all the poms and
make sure they use the 0.4 release version and such. Not a big deal, but it
takes time.
One more point though: on any branch that a developer is expected to run "mvn
install", the version number in the pom should ALWAYS be a SNAPSHOT version,
never a release version. The oct branch violates that in several places,
but I'm not sure if anyone would consider that branch a branch for developers.
Dan
> > Anyway, if anyone else has any input into this, feel free to add their
> > thoughts!
>
> Thanks for bringing all this up. I certainly wasn't aware of some of this.
>
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
> > Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: relativePath thing..... was Re: svn commit: r1202350 - in
/aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml
Posted by Alasdair Nottingham <no...@apache.org>.
I agree, I think trunk should be the latest, although I wasn't following
the release closely enough to know why this wasn't the case.
On 16 November 2011 01:54, David Jencks <da...@yahoo.com> wrote:
> I think this reflects what we discussed. Many thanks to Dan for putting
> up with my argumentative nature, working hard to fix the problem,
> explaining it to me :-) and documenting everything here :-D
>
> thanks
> david jencks
>
> On Nov 15, 2011, at 5:49 PM, Daniel Kulp wrote:
>
> >
> > On Tuesday, November 15, 2011 2:36:01 PM David Jencks wrote:
> >> On Nov 15, 2011, at 10:59 AM, Daniel Kulp wrote:
> >>> On Tuesday, November 15, 2011 10:50:31 AM David Jencks wrote:
> >>>> -1 to the <relative-path>s
> >>>>
> > ....
> >
> >>> I feel pretty strong that they SHOULD be there. IMO, we need to be
> >>> able to just checkout trunk and run "mvn install" and have it build
> >>> and test and such. That's how maven projects work. Having it work
> >>> properly "out of the box" for new users, IMO, trumps aesthetics of a
> >>> release tag where the relativePath would be ignore anyway. Without
> >>> them, you get all kinds of warnings (if they work at all).
> >>
> >> Since you are proposing the change, can you explain exactly what the
> problem
> >> you are trying to solve is and how to reproduce it? I haven't
> encountered
> >> _any_ problems that this change would solve so it seems like a bad idea
> >> with no redeeming features. Also, what are the warnings you are
> referring
> >> to?
> >
> > David and I had a chat on IRC. Log at:
> >
> >
> http://irclogs.dankulp.com/logs/irclogger_log/apache-aries?date=2011-11-16,Wed
> >
> > to discuss this and clear the air a bit. Here is my summary:
> (actually,I
> > think this summary is longer than the original IRC log) David, please
> > correct anything I got wrong or missed.
> >
> > Basically, IMO, any potential developer should be able to checkout Aries
> trunk
> > (or ANY other Maven based project) and run "mvn install" and have it just
> > work. They should not need to go to some web site or README or anything
> to
> > figure out how to build the project. That's the whole point of Maven.
> > Conventions. If it doesn't work, you are doing something wrong.
> *THAT* is
> > important to me and is the basic problem I'm trying to solve. I also
> believe
> > that the resulting build should be SUCCESSFUL and should also be error
> and
> > warning free as much as is possible. That is secondary though. Still
> > tackling the first part. :-) I also *prefer* that it work behind a
> > reasonably setup proxy/firewall (read: no snapshot deps not part of the
> > build), but that is definitely tertiary.
> >
> > In our specific case, we failed miserably. Due to the snapshot parents,
> > maven could not resolve the parents without first going to the web site
> to
> > find out we need to build parents first, which is wrong. David and I
> > discussed 4 possible options:
> >
> > 1) Add relativePath entries to all the poms. This was simple for me to
> do
> > which is what I did. It's also consistent with what other projects I'm
> > involved in have done (CXF, Camel, Maven, etc...) which I why I didn't
> think
> > it would be a big deal. Heck, if the Maven folks themselves recommend
> using
> > it and are using it for their plugins and such, I would think it would
> be OK.
> > Apparently not. :-)
> >
> > 2) Do NOT use SNAPSHOT parents - if the parents are in Central, not a
> problem.
> > I didn't realize the 0.5 versions were released, otherwise I think I
> would
> > have gone this route. Even easier.
> >
> > 3) Combination of 1 and 2 - don't use SNAPSHOT parents unless you REALLY
> have
> > to, in which case use a relativePath until the parent is released.
> >
> > 4) For poms that have a snapshot parent, add a <repositories> entry to
> add the
> > apache.snapshot repo in it so it can resolve the parent. Again, when
> parent
> > is released, the repositories entry can be removed.
> >
> >
> > Since 0.5 is released, I'll go back tomorrow and flip to #2. However,
> this
> > does mean that if we need a 0.6 version, when we create the SNAPSHOTS,
> we'll
> > need to remember to do either #3 or #4 until released.
> >
> > On a side note: it *really* bothers me that there is work that has been
> done
> > on a branch that is not reflected on trunk. IMO, trunk should always
> reflect
> > the most up-to-date status of the code.
> >
> > Anyway, if anyone else has any input into this, feel free to add their
> > thoughts!
> >
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
> > Talend - http://www.talend.com
>
>
--
Alasdair Nottingham
not@apache.org
Re: relativePath thing..... was Re: svn commit: r1202350 - in /aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml
Posted by David Jencks <da...@yahoo.com>.
I think this reflects what we discussed. Many thanks to Dan for putting up with my argumentative nature, working hard to fix the problem, explaining it to me :-) and documenting everything here :-D
thanks
david jencks
On Nov 15, 2011, at 5:49 PM, Daniel Kulp wrote:
>
> On Tuesday, November 15, 2011 2:36:01 PM David Jencks wrote:
>> On Nov 15, 2011, at 10:59 AM, Daniel Kulp wrote:
>>> On Tuesday, November 15, 2011 10:50:31 AM David Jencks wrote:
>>>> -1 to the <relative-path>s
>>>>
> ....
>
>>> I feel pretty strong that they SHOULD be there. IMO, we need to be
>>> able to just checkout trunk and run "mvn install" and have it build
>>> and test and such. That's how maven projects work. Having it work
>>> properly "out of the box" for new users, IMO, trumps aesthetics of a
>>> release tag where the relativePath would be ignore anyway. Without
>>> them, you get all kinds of warnings (if they work at all).
>>
>> Since you are proposing the change, can you explain exactly what the problem
>> you are trying to solve is and how to reproduce it? I haven't encountered
>> _any_ problems that this change would solve so it seems like a bad idea
>> with no redeeming features. Also, what are the warnings you are referring
>> to?
>
> David and I had a chat on IRC. Log at:
>
> http://irclogs.dankulp.com/logs/irclogger_log/apache-aries?date=2011-11-16,Wed
>
> to discuss this and clear the air a bit. Here is my summary: (actually,I
> think this summary is longer than the original IRC log) David, please
> correct anything I got wrong or missed.
>
> Basically, IMO, any potential developer should be able to checkout Aries trunk
> (or ANY other Maven based project) and run "mvn install" and have it just
> work. They should not need to go to some web site or README or anything to
> figure out how to build the project. That's the whole point of Maven.
> Conventions. If it doesn't work, you are doing something wrong. *THAT* is
> important to me and is the basic problem I'm trying to solve. I also believe
> that the resulting build should be SUCCESSFUL and should also be error and
> warning free as much as is possible. That is secondary though. Still
> tackling the first part. :-) I also *prefer* that it work behind a
> reasonably setup proxy/firewall (read: no snapshot deps not part of the
> build), but that is definitely tertiary.
>
> In our specific case, we failed miserably. Due to the snapshot parents,
> maven could not resolve the parents without first going to the web site to
> find out we need to build parents first, which is wrong. David and I
> discussed 4 possible options:
>
> 1) Add relativePath entries to all the poms. This was simple for me to do
> which is what I did. It's also consistent with what other projects I'm
> involved in have done (CXF, Camel, Maven, etc...) which I why I didn't think
> it would be a big deal. Heck, if the Maven folks themselves recommend using
> it and are using it for their plugins and such, I would think it would be OK.
> Apparently not. :-)
>
> 2) Do NOT use SNAPSHOT parents - if the parents are in Central, not a problem.
> I didn't realize the 0.5 versions were released, otherwise I think I would
> have gone this route. Even easier.
>
> 3) Combination of 1 and 2 - don't use SNAPSHOT parents unless you REALLY have
> to, in which case use a relativePath until the parent is released.
>
> 4) For poms that have a snapshot parent, add a <repositories> entry to add the
> apache.snapshot repo in it so it can resolve the parent. Again, when parent
> is released, the repositories entry can be removed.
>
>
> Since 0.5 is released, I'll go back tomorrow and flip to #2. However, this
> does mean that if we need a 0.6 version, when we create the SNAPSHOTS, we'll
> need to remember to do either #3 or #4 until released.
>
> On a side note: it *really* bothers me that there is work that has been done
> on a branch that is not reflected on trunk. IMO, trunk should always reflect
> the most up-to-date status of the code.
>
> Anyway, if anyone else has any input into this, feel free to add their
> thoughts!
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
Re: relativePath thing..... was Re: svn commit: r1202350 - in
/aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml
Posted by Jeremy Hughes <hu...@apache.org>.
On 16 November 2011 01:49, Daniel Kulp <dk...@apache.org> wrote:
>
> On Tuesday, November 15, 2011 2:36:01 PM David Jencks wrote:
>> On Nov 15, 2011, at 10:59 AM, Daniel Kulp wrote:
>> > On Tuesday, November 15, 2011 10:50:31 AM David Jencks wrote:
>> >> -1 to the <relative-path>s
>> >>
> ....
>
>> > I feel pretty strong that they SHOULD be there. IMO, we need to be
>> > able to just checkout trunk and run "mvn install" and have it build
>> > and test and such. That's how maven projects work. Having it work
>> > properly "out of the box" for new users, IMO, trumps aesthetics of a
>> > release tag where the relativePath would be ignore anyway. Without
>> > them, you get all kinds of warnings (if they work at all).
>>
>> Since you are proposing the change, can you explain exactly what the problem
>> you are trying to solve is and how to reproduce it? I haven't encountered
>> _any_ problems that this change would solve so it seems like a bad idea
>> with no redeeming features. Also, what are the warnings you are referring
>> to?
>
> David and I had a chat on IRC. Log at:
>
> http://irclogs.dankulp.com/logs/irclogger_log/apache-aries?date=2011-11-16,Wed
>
> to discuss this and clear the air a bit. Here is my summary: (actually,I
> think this summary is longer than the original IRC log) David, please
> correct anything I got wrong or missed.
>
> Basically, IMO, any potential developer should be able to checkout Aries trunk
> (or ANY other Maven based project) and run "mvn install" and have it just
> work. They should not need to go to some web site or README or anything to
> figure out how to build the project. That's the whole point of Maven.
+1 I totally agree. The recent release caused some instability (not
the only cause, but the one I feel responsible for) and I moved it off
into a branch when I realised that was the only feasible option.
> Conventions. If it doesn't work, you are doing something wrong. *THAT* is
> important to me and is the basic problem I'm trying to solve. I also believe
> that the resulting build should be SUCCESSFUL and should also be error and
> warning free as much as is possible. That is secondary though. Still
+1 to that too ... it's becomes a case of people opening JIRAs /
submitting patches etc when they see problems.
> tackling the first part. :-) I also *prefer* that it work behind a
> reasonably setup proxy/firewall (read: no snapshot deps not part of the
> build), but that is definitely tertiary.
I'm afraid I can't help here much as I don't have these proxy/firewall
restrictions. What do you suggest when a new feature / bug fix depends
on a bug fix to a dependency outside Aries? A snapshot dependency is
often needed for this until the dependency project is released.
>
> In our specific case, we failed miserably. Due to the snapshot parents,
> maven could not resolve the parents without first going to the web site to
> find out we need to build parents first, which is wrong. David and I
> discussed 4 possible options:
>
> 1) Add relativePath entries to all the poms. This was simple for me to do
> which is what I did. It's also consistent with what other projects I'm
> involved in have done (CXF, Camel, Maven, etc...) which I why I didn't think
> it would be a big deal. Heck, if the Maven folks themselves recommend using
> it and are using it for their plugins and such, I would think it would be OK.
> Apparently not. :-)
I don't think we've dismissed this. I didn't realise it was a problem
and didn't know this was a solution :-)
>
> 2) Do NOT use SNAPSHOT parents - if the parents are in Central, not a problem.
> I didn't realize the 0.5 versions were released, otherwise I think I would
> have gone this route. Even easier.
>
> 3) Combination of 1 and 2 - don't use SNAPSHOT parents unless you REALLY have
> to, in which case use a relativePath until the parent is released.
>
> 4) For poms that have a snapshot parent, add a <repositories> entry to add the
> apache.snapshot repo in it so it can resolve the parent. Again, when parent
> is released, the repositories entry can be removed.
>
>
> Since 0.5 is released, I'll go back tomorrow and flip to #2. However, this
> does mean that if we need a 0.6 version, when we create the SNAPSHOTS, we'll
> need to remember to do either #3 or #4 until released.
>
> On a side note: it *really* bothers me that there is work that has been done
> on a branch that is not reflected on trunk. IMO, trunk should always reflect
> the most up-to-date status of the code.
If you're referring to the oct-2011-release branch, sorry I'm getting
to it. I need to release 0.4.1 of blueprint-core, blueprint-cm,
blueprint-bundle and blueprint-itests. Either I can merge the branch
into trunk then create a new branch for the release, or I can do the
release from the existing branch then merge. In fact I'm minded to do
the former. Thoughts?
>
> Anyway, if anyone else has any input into this, feel free to add their
> thoughts!
Thanks for bringing all this up. I certainly wasn't aware of some of this.
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
relativePath thing..... was Re: svn commit: r1202350 - in /aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, November 15, 2011 2:36:01 PM David Jencks wrote:
> On Nov 15, 2011, at 10:59 AM, Daniel Kulp wrote:
> > On Tuesday, November 15, 2011 10:50:31 AM David Jencks wrote:
> >> -1 to the <relative-path>s
> >>
....
> > I feel pretty strong that they SHOULD be there. IMO, we need to be
> > able to just checkout trunk and run "mvn install" and have it build
> > and test and such. That's how maven projects work. Having it work
> > properly "out of the box" for new users, IMO, trumps aesthetics of a
> > release tag where the relativePath would be ignore anyway. Without
> > them, you get all kinds of warnings (if they work at all).
>
> Since you are proposing the change, can you explain exactly what the problem
> you are trying to solve is and how to reproduce it? I haven't encountered
> _any_ problems that this change would solve so it seems like a bad idea
> with no redeeming features. Also, what are the warnings you are referring
> to?
David and I had a chat on IRC. Log at:
http://irclogs.dankulp.com/logs/irclogger_log/apache-aries?date=2011-11-16,Wed
to discuss this and clear the air a bit. Here is my summary: (actually,I
think this summary is longer than the original IRC log) David, please
correct anything I got wrong or missed.
Basically, IMO, any potential developer should be able to checkout Aries trunk
(or ANY other Maven based project) and run "mvn install" and have it just
work. They should not need to go to some web site or README or anything to
figure out how to build the project. That's the whole point of Maven.
Conventions. If it doesn't work, you are doing something wrong. *THAT* is
important to me and is the basic problem I'm trying to solve. I also believe
that the resulting build should be SUCCESSFUL and should also be error and
warning free as much as is possible. That is secondary though. Still
tackling the first part. :-) I also *prefer* that it work behind a
reasonably setup proxy/firewall (read: no snapshot deps not part of the
build), but that is definitely tertiary.
In our specific case, we failed miserably. Due to the snapshot parents,
maven could not resolve the parents without first going to the web site to
find out we need to build parents first, which is wrong. David and I
discussed 4 possible options:
1) Add relativePath entries to all the poms. This was simple for me to do
which is what I did. It's also consistent with what other projects I'm
involved in have done (CXF, Camel, Maven, etc...) which I why I didn't think
it would be a big deal. Heck, if the Maven folks themselves recommend using
it and are using it for their plugins and such, I would think it would be OK.
Apparently not. :-)
2) Do NOT use SNAPSHOT parents - if the parents are in Central, not a problem.
I didn't realize the 0.5 versions were released, otherwise I think I would
have gone this route. Even easier.
3) Combination of 1 and 2 - don't use SNAPSHOT parents unless you REALLY have
to, in which case use a relativePath until the parent is released.
4) For poms that have a snapshot parent, add a <repositories> entry to add the
apache.snapshot repo in it so it can resolve the parent. Again, when parent
is released, the repositories entry can be removed.
Since 0.5 is released, I'll go back tomorrow and flip to #2. However, this
does mean that if we need a 0.6 version, when we create the SNAPSHOTS, we'll
need to remember to do either #3 or #4 until released.
On a side note: it *really* bothers me that there is work that has been done
on a branch that is not reflected on trunk. IMO, trunk should always reflect
the most up-to-date status of the code.
Anyway, if anyone else has any input into this, feel free to add their
thoughts!
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: svn commit: r1202350 - in /aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml
Posted by David Jencks <da...@yahoo.com>.
On Nov 15, 2011, at 10:59 AM, Daniel Kulp wrote:
> On Tuesday, November 15, 2011 10:50:31 AM David Jencks wrote:
>> -1 to the <relative-path>s
>>
>> We should not be embedding assumptions about how much of the project you
>> checked out in the poms. You're basically expected to check out one module
>> and build it. What problem are you trying to solve? I had no problem
>> building the all-in-one after I built the parents and the eba-maven-plugin.
>>
>> These paths are going to be completely wrong in a release tag.
>>
>> This is not a technical veto since apparently both ways work, but I feel
>> pretty strongly about this.
>
> I feel pretty strong that they SHOULD be there. IMO, we need to be able to
> just checkout trunk and run "mvn install" and have it build and test and
> such. That's how maven projects work. Having it work properly "out of the
> box" for new users, IMO, trumps aesthetics of a release tag where the
> relativePath would be ignore anyway. Without them, you get all kinds of
> warnings (if they work at all).
Since you are proposing the change, can you explain exactly what the problem you are trying to solve is and how to reproduce it? I haven't encountered _any_ problems that this change would solve so it seems like a bad idea with no redeeming features. Also, what are the warnings you are referring to?
thanks
david jencks
>
> Dan
>
>
>
>>
>> thanks
>> david jencks
>>
>> On Nov 15, 2011, at 10:16 AM, dkulp@apache.org wrote:
>>> Author: dkulp
>>> Date: Tue Nov 15 18:16:00 2011
>>> New Revision: 1202350
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1202350&view=rev
>>> Log:
>>> More maven 3 fixes and snapshot deploy fix
>>>
>>> Modified:
>>> aries/trunk/application/application-modeller/pom.xml
>>> aries/trunk/quiesce/pom.xml
>>>
>>> Modified: aries/trunk/application/application-modeller/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/aries/trunk/application/application-modell
>>> er/pom.xml?rev=1202350&r1=1202349&r2=1202350&view=diff
>>> =======================================================================
>>> ======= --- aries/trunk/application/application-modeller/pom.xml
>>> (original) +++ aries/trunk/application/application-modeller/pom.xml Tue
>>> Nov 15 18:16:00 2011 @@ -22,7 +22,7 @@
>>>
>>> <groupId>org.apache.aries</groupId>
>>> <artifactId>java5-parent</artifactId>
>>> <version>0.5-SNAPSHOT</version>
>>>
>>> - <relativePath />
>>> +
>>> <relativePath>../../parent/default-parent/java5-parent</relativePath>>
>>> </parent>
>>>
>>> <groupId>org.apache.aries.application</groupId>
>>>
>>> Modified: aries/trunk/quiesce/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/aries/trunk/quiesce/pom.xml?rev=1202350&r1
>>> =1202349&r2=1202350&view=diff
>>> =======================================================================
>>> ======= --- aries/trunk/quiesce/pom.xml (original)
>>> +++ aries/trunk/quiesce/pom.xml Tue Nov 15 18:16:00 2011
>>> @@ -19,7 +19,7 @@
>>>
>>> <parent>
>>>
>>> <groupId>org.apache.aries</groupId>
>>> <artifactId>java5-parent</artifactId>
>>>
>>> - <version>0.4</version>
>>> + <version>0.5-SNAPSHOT</version>
>>>
>>> <relativePath>../parent/default-parent/java5-parent</rel
>>> ativePath>>
>>> </parent>
>>>
>>> @@ -28,6 +28,7 @@
>>>
>>> <artifactId>quiesce</artifactId>
>>> <name>Apache Aries Quiesce</name>
>>> <packaging>pom</packaging>
>>>
>>> + <version>0.3.1-SNAPSHOT</version>
>>>
>>> <description>
>>>
>>> Quiesce support for Aries - reactor pom
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
Re: svn commit: r1202350 - in /aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, November 15, 2011 10:50:31 AM David Jencks wrote:
> -1 to the <relative-path>s
>
> We should not be embedding assumptions about how much of the project you
> checked out in the poms. You're basically expected to check out one module
> and build it. What problem are you trying to solve? I had no problem
> building the all-in-one after I built the parents and the eba-maven-plugin.
>
> These paths are going to be completely wrong in a release tag.
>
> This is not a technical veto since apparently both ways work, but I feel
> pretty strongly about this.
I feel pretty strong that they SHOULD be there. IMO, we need to be able to
just checkout trunk and run "mvn install" and have it build and test and
such. That's how maven projects work. Having it work properly "out of the
box" for new users, IMO, trumps aesthetics of a release tag where the
relativePath would be ignore anyway. Without them, you get all kinds of
warnings (if they work at all).
Dan
>
> thanks
> david jencks
>
> On Nov 15, 2011, at 10:16 AM, dkulp@apache.org wrote:
> > Author: dkulp
> > Date: Tue Nov 15 18:16:00 2011
> > New Revision: 1202350
> >
> > URL: http://svn.apache.org/viewvc?rev=1202350&view=rev
> > Log:
> > More maven 3 fixes and snapshot deploy fix
> >
> > Modified:
> > aries/trunk/application/application-modeller/pom.xml
> > aries/trunk/quiesce/pom.xml
> >
> > Modified: aries/trunk/application/application-modeller/pom.xml
> > URL:
> > http://svn.apache.org/viewvc/aries/trunk/application/application-modell
> > er/pom.xml?rev=1202350&r1=1202349&r2=1202350&view=diff
> > =======================================================================
> > ======= --- aries/trunk/application/application-modeller/pom.xml
> > (original) +++ aries/trunk/application/application-modeller/pom.xml Tue
> > Nov 15 18:16:00 2011 @@ -22,7 +22,7 @@
> >
> > <groupId>org.apache.aries</groupId>
> > <artifactId>java5-parent</artifactId>
> > <version>0.5-SNAPSHOT</version>
> >
> > - <relativePath />
> > +
> > <relativePath>../../parent/default-parent/java5-parent</relativePath>>
> > </parent>
> >
> > <groupId>org.apache.aries.application</groupId>
> >
> > Modified: aries/trunk/quiesce/pom.xml
> > URL:
> > http://svn.apache.org/viewvc/aries/trunk/quiesce/pom.xml?rev=1202350&r1
> > =1202349&r2=1202350&view=diff
> > =======================================================================
> > ======= --- aries/trunk/quiesce/pom.xml (original)
> > +++ aries/trunk/quiesce/pom.xml Tue Nov 15 18:16:00 2011
> > @@ -19,7 +19,7 @@
> >
> > <parent>
> >
> > <groupId>org.apache.aries</groupId>
> > <artifactId>java5-parent</artifactId>
> >
> > - <version>0.4</version>
> > + <version>0.5-SNAPSHOT</version>
> >
> > <relativePath>../parent/default-parent/java5-parent</rel
> > ativePath>>
> > </parent>
> >
> > @@ -28,6 +28,7 @@
> >
> > <artifactId>quiesce</artifactId>
> > <name>Apache Aries Quiesce</name>
> > <packaging>pom</packaging>
> >
> > + <version>0.3.1-SNAPSHOT</version>
> >
> > <description>
> >
> > Quiesce support for Aries - reactor pom
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com