You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2007/10/29 18:47:11 UTC
trunk and the super POM?
Hi,
I noticed that the super POM has changed on trunk (the removal of the
release profile), but the version hasn't yet - it's still 4.0.0.
Also, IT 51 is excluded which checks the release profile.
For reasons of reproducibility, shouldn't POMs with the current
modelVersion retain the same behaviour, and POMs with a newer version
not receive the profile? Any objections to this being changed back?
Thanks,
Brett
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
Re: trunk and the super POM?
Posted by Brett Porter <br...@apache.org>.
Jason,
I don't entirely agree with all your points below, but agree with the
move out of the super POM by a final 2.1 release so don't feel the
need to go into it any further.
Just two questions remain unanswered:
- are the changes written down anywhere? As I said, I can't find the
page in the wiki that I'm sure used to exist. If not, I will start it.
- I'm also interested in the question Wendy asked about whether the
Clearcase/Perforce issues are already in JIRA?
Thanks,
Brett
On 30/10/2007, at 5:10 PM, Jason van Zyl wrote:
>
> On 29 Oct 07, at 10:42 PM 29 Oct 07, Wendy Smoak wrote:
>
>> On 10/29/07, Jason van Zyl <ja...@maven.org> wrote:
>>
>>> I doubt that given my visitation of production environments. But
>>> that
>>> said the portion from our own POM provides the same
>>> functionality, or
>>> it would even be preferable in subsequent versions of the release
>>> plugin to make these goals default. The problem therein is selecting
>>> the right version. Ultimately any sane group of developers wants to
>>> see this information in their face. What is being used to produce
>>> the
>>> release and what version of any tools/plugins being used.
>>
>> Of course explicit configuration is better, but it's been in the
>> super
>> pom for a long time now.
>
> It's been out of the Super POM for quite a while now.
>
>> I think all Brett is asking is "How are we
>> going to help people transition from 2.0 to 2.1?"
>>
>
> To use what's in our own project POM as a working example of a best
> practice.
>
>> I agree that the release profile shouldn't be in the super pom, but
>> having it just disappear will be a shock. Is there any way to
>> "deprecate" this behavior in 2.0, maybe by printing a message when
>> the
>> release profile is activated?
>
> Sure, in subsequent versions of the release plugin you can put a
> warning saying not to rely on the magic. We are not using it
> ourselves anymore, it is explicit in our POMs and has been for the
> last few releases.
>
>>
>>
>> I'm happily using the Continuum release functionality (but I think
>> it's the same code) and have used the release plugin for an Archiva
>> release. It works fine. (Yes, with Subversion.)
>
> It's consistently crapped out for me with the last three releases
> of Maven itself. I think the problem is that the bugs fixed are
> primarily for Continuum and Archiva. I had to run it several times
> and then just reverted to the beta-5 release to get it to work. I
> reported the issues and had new ones with the 2.0.7 release, then
> had more where it let me go all the way and then died on an SVN
> discrepancy. Brian reported and fixed another critical one of late.
>
>> Are the issues you
>> mentioned with Perforce and Clearcase entered in JIRA?
>
>
>>
>>
>> --
>> Wendy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: trunk and the super POM?
Posted by Jason van Zyl <ja...@maven.org>.
On 29 Oct 07, at 10:42 PM 29 Oct 07, Wendy Smoak wrote:
> On 10/29/07, Jason van Zyl <ja...@maven.org> wrote:
>
>> I doubt that given my visitation of production environments. But that
>> said the portion from our own POM provides the same functionality, or
>> it would even be preferable in subsequent versions of the release
>> plugin to make these goals default. The problem therein is selecting
>> the right version. Ultimately any sane group of developers wants to
>> see this information in their face. What is being used to produce the
>> release and what version of any tools/plugins being used.
>
> Of course explicit configuration is better, but it's been in the super
> pom for a long time now.
It's been out of the Super POM for quite a while now.
> I think all Brett is asking is "How are we
> going to help people transition from 2.0 to 2.1?"
>
To use what's in our own project POM as a working example of a best
practice.
> I agree that the release profile shouldn't be in the super pom, but
> having it just disappear will be a shock. Is there any way to
> "deprecate" this behavior in 2.0, maybe by printing a message when the
> release profile is activated?
Sure, in subsequent versions of the release plugin you can put a
warning saying not to rely on the magic. We are not using it ourselves
anymore, it is explicit in our POMs and has been for the last few
releases.
>
>
> I'm happily using the Continuum release functionality (but I think
> it's the same code) and have used the release plugin for an Archiva
> release. It works fine. (Yes, with Subversion.)
It's consistently crapped out for me with the last three releases of
Maven itself. I think the problem is that the bugs fixed are primarily
for Continuum and Archiva. I had to run it several times and then just
reverted to the beta-5 release to get it to work. I reported the
issues and had new ones with the 2.0.7 release, then had more where it
let me go all the way and then died on an SVN discrepancy. Brian
reported and fixed another critical one of late.
> Are the issues you
> mentioned with Perforce and Clearcase entered in JIRA?
>
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: trunk and the super POM?
Posted by Wendy Smoak <ws...@gmail.com>.
On 10/29/07, Jason van Zyl <ja...@maven.org> wrote:
> I doubt that given my visitation of production environments. But that
> said the portion from our own POM provides the same functionality, or
> it would even be preferable in subsequent versions of the release
> plugin to make these goals default. The problem therein is selecting
> the right version. Ultimately any sane group of developers wants to
> see this information in their face. What is being used to produce the
> release and what version of any tools/plugins being used.
Of course explicit configuration is better, but it's been in the super
pom for a long time now. I think all Brett is asking is "How are we
going to help people transition from 2.0 to 2.1?"
I agree that the release profile shouldn't be in the super pom, but
having it just disappear will be a shock. Is there any way to
"deprecate" this behavior in 2.0, maybe by printing a message when the
release profile is activated?
I'm happily using the Continuum release functionality (but I think
it's the same code) and have used the release plugin for an Archiva
release. It works fine. (Yes, with Subversion.) Are the issues you
mentioned with Perforce and Clearcase entered in JIRA?
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: trunk and the super POM?
Posted by Jason van Zyl <ja...@maven.org>.
On 29 Oct 07, at 9:35 PM 29 Oct 07, William Ferguson wrote:
>
>> From: Jason van Zyl [mailto:jason@maven.org]
>
>>> Yes, I know we discussed it briefly at the time, but I
>>> wanted to look at the actual implications for 2.0.x users now.
>
>> There are none, they aren't using it. And it's only
>> implication is in conjunction with the release plugin and the
>> release plugin should not be tied to any information in the
>> super POM. That's just wrong.
>
>> If anyone expects the same
>> behavior that then can put that chunk of the POM in theirs.
>> As of right now there are zero people affected and the
>> release plugins is pretty much useless to anyone who is not
>> using subversion. It's useless for Clearcase users and
>> useless for Perforce users which is a large part of the
>> enterprise environment so overall the clean up is the right
>> thing to do as it simply should not be in the Super POM and I
>> really doubt anyone can rely on it for production use. It's
>> just too flaky.
>
>
> Jason, I agree that the release-plugin shouldn't be tied to any
> information in the super POM.
>
> But I think you'll find that there are *lots* of teams using the
> release
> plugin in production environments.
I doubt that given my visitation of production environments. But that
said the portion from our own POM provides the same functionality, or
it would even be preferable in subsequent versions of the release
plugin to make these goals default. The problem therein is selecting
the right version. Ultimately any sane group of developers wants to
see this information in their face. What is being used to produce the
release and what version of any tools/plugins being used.
> Its not perfect, the inability to
> bind Mojos to its life-cycles is almost crippling, but it's the only
> thing that remotely guarantees a consistent release process.
This will not change the way binaries are produced and released. The
sources/javadocs not being release would affect IDE usage, but easier
remedied with a snippet of our POM in the release plugin documentation.
> So if this involves a large behaviour change for existing 2.0.x users
> then there's going to need to be a suitable warning with an easy to
> implement mitigation strategy.
>
> William
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: trunk and the super POM?
Posted by William Ferguson <Wi...@yarris.com>.
> From: Jason van Zyl [mailto:jason@maven.org]
> > Yes, I know we discussed it briefly at the time, but I
> > wanted to look at the actual implications for 2.0.x users now.
> There are none, they aren't using it. And it's only
> implication is in conjunction with the release plugin and the
> release plugin should not be tied to any information in the
> super POM. That's just wrong.
> If anyone expects the same
> behavior that then can put that chunk of the POM in theirs.
> As of right now there are zero people affected and the
> release plugins is pretty much useless to anyone who is not
> using subversion. It's useless for Clearcase users and
> useless for Perforce users which is a large part of the
> enterprise environment so overall the clean up is the right
> thing to do as it simply should not be in the Super POM and I
> really doubt anyone can rely on it for production use. It's
> just too flaky.
Jason, I agree that the release-plugin shouldn't be tied to any
information in the super POM.
But I think you'll find that there are *lots* of teams using the release
plugin in production environments. Its not perfect, the inability to
bind Mojos to its life-cycles is almost crippling, but it's the only
thing that remotely guarantees a consistent release process.
So if this involves a large behaviour change for existing 2.0.x users
then there's going to need to be a suitable warning with an easy to
implement mitigation strategy.
William
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: trunk and the super POM?
Posted by Jason van Zyl <ja...@maven.org>.
On 29 Oct 07, at 8:24 PM 29 Oct 07, Brett Porter wrote:
>
> On 30/10/2007, at 7:48 AM, Jason van Zyl wrote:
>
>>
>> On 29 Oct 07, at 10:47 AM 29 Oct 07, Brett Porter wrote:
>>
>>> Hi,
>>>
>>> I noticed that the super POM has changed on trunk (the removal of
>>> the release profile)
>>
>> Long long time ago.
>
> Yes, I know we discussed it briefly at the time, but I wanted to
> look at the actual implications for 2.0.x users now.
There are none, they aren't using it. And it's only implication is in
conjunction with the release plugin and the release plugin should not
be tied to any information in the super POM. That's just wrong. If
anyone expects the same behavior that then can put that chunk of the
POM in theirs. As of right now there are zero people affected and the
release plugins is pretty much useless to anyone who is not using
subversion. It's useless for Clearcase users and useless for Perforce
users which is a large part of the enterprise environment so overall
the clean up is the right thing to do as it simply should not be in
the Super POM and I really doubt anyone can rely on it for production
use. It's just too flaky.
>
>
>>
>>> , but the version hasn't yet - it's still 4.0.0. Also, IT 51 is
>>> excluded which checks the release profile.
>>>
>>> For reasons of reproducibility, shouldn't POMs with the current
>>> modelVersion retain the same behaviour, and POMs with a newer
>>> version not receive the profile? Any objections to this being
>>> changed back?
>>>
>>
>> Yes, don't put the release profile back. It's the completely wrong
>> place for it.
>>
>> You also don't change the model version didn't change the content
>> did. The Super POM currently has no version itself which is what
>> changes when content changes.
>>
>> Leave it the way it is. It's been like that for a while. Putting
>> the release information in there was a mistake.
>
> Mistake as it may be, all I'm looking for is a solution that sees
> builds made with 2.0.x (that's everything up until today and for
> some time yet) build the same way with 2.1 when someone adds the
> flags for these that their now tagged projects expect.
It's not going away in the 2.0.x branch.
>
>
> What alternative are you proposing? Is it simply going to be
> documented in the release notes as something like "you will no
> longer get source and javadoc when you build using the release
> profile and will need to add them to the build yourself"?
The alternative is like what we have in our own POM which defines
everything literally and defines things where they are visible. So our
POM would serve as an example for sure. I don't think foisting what we
have in the Super POM on people is of any value. 2.1 is a major
version change so it's the time to make the right corrections. If
people move forward they live with the changes. I think this change is
preferable as it's simply more visible and removes another element of
black magic where a specific plugin pulls values from the Super POM. A
typical user would have zero chance of figuring out how the release
plugin actually works. They all presume it's controlled in some way in
the plugin and the chances of someone finding that information in the
Super POM are zero. It's not said where that information comes from at
all in the documentation.
If they use the profile we have then they will get Javadocs, and
sources but they might not want that so it means they can get whatever
they want.
>
>
> Thanks,
> Brett
>
> --
> Brett Porter - brett@apache.org
> Blog: http://www.devzuz.org/blogs/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: trunk and the super POM?
Posted by Brett Porter <br...@apache.org>.
On 30/10/2007, at 7:48 AM, Jason van Zyl wrote:
>
> On 29 Oct 07, at 10:47 AM 29 Oct 07, Brett Porter wrote:
>
>> Hi,
>>
>> I noticed that the super POM has changed on trunk (the removal of
>> the release profile)
>
> Long long time ago.
Yes, I know we discussed it briefly at the time, but I wanted to look
at the actual implications for 2.0.x users now.
>
>> , but the version hasn't yet - it's still 4.0.0. Also, IT 51 is
>> excluded which checks the release profile.
>>
>> For reasons of reproducibility, shouldn't POMs with the current
>> modelVersion retain the same behaviour, and POMs with a newer
>> version not receive the profile? Any objections to this being
>> changed back?
>>
>
> Yes, don't put the release profile back. It's the completely wrong
> place for it.
>
> You also don't change the model version didn't change the content
> did. The Super POM currently has no version itself which is what
> changes when content changes.
>
> Leave it the way it is. It's been like that for a while. Putting
> the release information in there was a mistake.
Mistake as it may be, all I'm looking for is a solution that sees
builds made with 2.0.x (that's everything up until today and for some
time yet) build the same way with 2.1 when someone adds the flags for
these that their now tagged projects expect.
What alternative are you proposing? Is it simply going to be
documented in the release notes as something like "you will no longer
get source and javadoc when you build using the release profile and
will need to add them to the build yourself"?
Thanks,
Brett
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: trunk and the super POM?
Posted by Jason van Zyl <ja...@maven.org>.
On 29 Oct 07, at 10:47 AM 29 Oct 07, Brett Porter wrote:
> Hi,
>
> I noticed that the super POM has changed on trunk (the removal of
> the release profile)
Long long time ago.
> , but the version hasn't yet - it's still 4.0.0. Also, IT 51 is
> excluded which checks the release profile.
>
> For reasons of reproducibility, shouldn't POMs with the current
> modelVersion retain the same behaviour, and POMs with a newer
> version not receive the profile? Any objections to this being
> changed back?
>
Yes, don't put the release profile back. It's the completely wrong
place for it.
You also don't change the model version didn't change the content did.
The Super POM currently has no version itself which is what changes
when content changes.
Leave it the way it is. It's been like that for a while. Putting the
release information in there was a mistake.
> Thanks,
> Brett
>
> --
> Brett Porter - brett@apache.org
> Blog: http://www.devzuz.org/blogs/bporter/
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org