On 4 Sep 07, at 2:03 AM 4 Sep 07, Brett Porter wrote:
Forgot to add my 2c :)
for the record - I'm in favour.
Two things I want to ensure happen, though:
- I'd like to see scope limited to just improving the API,
packaging and usage (as was proposed) - many of the comments touch
on how to change/improve/fix the resolution mechanism itself. That
is a different proposal.
That's all that's happened thus far. The required refactoring is
another proposal. As far as general improvements like making the core
not fail-fast is a general improvement in behavior regardless of any
other internal changes.
- I would like to see changes done entirely within the artifact
trunk in a self-contained way, and Maven updated as it stabilises -
not a constant chasing of snapshots (or even alphas),
You can see whatever you like if you do the work.
Alphas are perfectly fine in something that is alpha. As 2.1 becomes
beta then we are feature complete and the consumption of snapshots or
alphas stop as a part of that. Work that I plan in 2.1 will require
changes in Maven Artifact. Arbitrarily not allowing alphas while
something is itself in alpha is not reasonable. For betas and above
that's a perfect sane tact.
especially with the troubles we've seen with the similar plexus
changes recently. We should expect to see a stable, tested,
documented release of artifact 3.0 as a result of this proposal
well in advance of Maven 2.1.
It's alpha, that's life. I'm fine with the policy of releases post
beta but things are going to change before that. Maven is a driver
for the changes, I can't know everything up front so alphas will be
used I'm sure.
What really matters?
What really matters in maven-artifact is that we retain backward
compatibility so that we don't screw anyone. We also need to improve
the tests in maven-artifact as there isn't much there and given these
two things we can move forward safely. If we manage to get maven-
artifact to work in 2.0.x then I believe we will be reasonably sure
everything works if all the tests and ITs work correctly.
(added to the page as well)
Cheers,
Brett
On 04/08/2007, at 1:17 AM, John Casey wrote:
+1, I'll add my (few) comments to the page.
-john
On Aug 2, 2007, at 11:13 PM, Jason van Zyl wrote:
Hi,
I have put the text of the proposal here so that it doesn't get
lost:
http://docs.codehaus.org/display/MAVEN/Decoupling+of+Maven+Artifact
But I would like to decouple the artifact handling code from
Maven in an attempt to improve it and make it easier for people
to use.
This is also how I see making proposals work going forward. Put
them in the wiki, bring it up here, if there is concern we can
discuss it, otherwise after a reasonable period of time (3 days)
the person who made the proposal can just do it if there is no
conflict. So if you agree and don't have to comment if you don't
want to. What's important is the proposal be visible (initial
mailing list and wiki) and remain visible (the wiki in the
proposals section). I also added a date to the proposal item so
that you can see when it started. So we can cull stuff from the
active list if it sits there forever without any ongoing effort.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
--
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 and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
