On 09/08/2010 1:25 PM, Jason van Zyl wrote:
On Aug 9, 2010, at 12:57 PM, Haszlakiewicz, Eric wrote:
-----Original Message-----
From: Jason van Zyl [mailto:ja...@sonatype.com]
The nut of the problem is that if we had to support every optional
behavior
for a particular subset of the community the code base would likely be
unmaintainable. No one here is going to implement anything toward what
you're specifically asking for because Maven was specifically designed
not
to work for what you want. It probably would not be hard to do what you
ask
for, but just because something is possible doesn't mean it's a good
idea
to do it.
I understand that including every potential optional feature is not
reasonable, and I'm not expecting that someone immediately go implement
this for me just because I'm asking. However, I was hoping that it
wouldn't get immediately dismissed without apparently considering the
usefulness of it (especially since it seems like sometime similar is
already done for snapshots), and I was hoping to perhaps even get a
pointer of the sort of "we don't have the time to do it, but if you
really want to work on this look at X".
But, oh well, I guess I'll try to figure it out on my own.
Now what you're asking for here sounds particularly disastrous. If
across
your organization a release does not actually mean a release in the
Maven
Again, you're missing my point. I AM NOT ASKING TO ALLOW RELEASES TO
CHANGE!
I think a few steps down the road, and what you are asking for makes that very
possible. I'm just cognizant of the thin end of the wedge, and one small change
opens up all sorts of unexpected results.
I just want a way to detect that something has become
inconsistent when someone makes a mistake, and fail the build. If you
think detecting problems is disastrous, well I don't really know what to
say to that.
That is an erroneous logical extension of what I described. Any movement toward
and supporting mutable releases is disastrous. Detecting problems is far to
general a category to assign us not caring about.
Preventing this problem by not allowing releases to change is better
than detecting them afterwards.
You might also want to consider the approach that we took.
We eliminated 90% of the dependency references in individual POMs by
using aggregating POMs that define the dependency on whole sets of
individual artifacts so that application POMs only refer to a few (5 or
so) aggregations to get 60-70 individual artifacts into the application
jars and wars.
This makes it easy to fix the kind of problem that you encountered since
I only have to fix and rerelease 1 SNAPSHOT to get everyone back on the
same page if we are in the SNAPSHOT phase of a release or fix and update
the minor release of the aggregation if it is released.
If we are actually preparing a release, people do have to be told to
update their dependencies but at least it is easy to find since you only
have 5 to look through and you know you have it because almost every
project POM has it.
I suspect that the kind of error that you hit, would always occur in a
SNAPSHOT phase and never in the release phase of an application since
the error would jump out at you as soon as you tried to use the badly
named artifacts.
You could write your own metadata on deploy, and use the enforcer plugin to
verify the state as you wish, react accordingly.
eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
