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 - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
