You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Casey <jd...@commonjava.org> on 2008/03/11 23:15:20 UTC
Development process (was: Controlling extension-exported classes)
That's completely true. I've implemented a new extension mechanism
with little or no documentation in the wiki or on the developers'
list. I was just about the only one committing on trunk at the time,
I was pretty careful to avoid bugs with this new implementation (and
made it number one priority to fix any issues that came up), and I
talked to almost anyone who would listen about this new extensions
mechanism (and the related work to allow multiple plugin versions in
the same build), including you on multiple occasions. All of my
commits have been done in public view, and there has been ample
opportunity to object to the direction I've been pursuing.
Over the past year, I've talked quite a bit about feature branches.
Some of this came as a result of some nasty surprises on trunk,
including some unilaterally deleted code to handle error messaging
that I wound up replacing with two new successive implementations
myself, because the original code was too complex (not my words). The
current implementation which I'm guessing is not overly complex - I
haven't floated a design doc on this either yet - is based on
AspectJ, which I know some people are uneasy about, but which is
still the best solution I've found (I had a functionality gap to
plug, remember). I talked about feature branches because that's a key
part of the process that we all agreed to early last year.
If any of the Maven committers is uncomfortable with the work I've
done on trunk, I'll pull it out onto a feature branch and we can vote
on it. I'd much prefer that there were some viable alternative to
fill the functionality vacuum, but we'll deal with this as it comes.
I still have a TODO to write up the design docs for the extension
mechanism, along with one for the error reporting, and Brett's
mentioned the importance of the branch-doc-vote-merge process in
helping those with limited time to keep up with the pace of
development. If we're all fine with slowing things down on trunk, I'm
fine with pulling these changes out, separating them into individual
design chunks, voting on them, and putting them back in. We can
simply roll back to 2.0.x functionality with trunk in the meantime.
I'm not going to try to be an exception to the rules here, if we can
all agree to follow them. I'm no more entitled than any of us to make
unilateral decisions about Maven code. I've been hypocritical in
these cases, and I'm perfectly willing to make it right.
Unfortunately, that's the best I can offer.
-john
On Mar 11, 2008, at 1:22 PM, Jason van Zyl wrote:
> Which you basically added without much discussion, no proposal and
> Milos' rightly nailed me the last time I tried that and that's
> perfectly valid. You're doing much the same thing and it's you
> yourself that asked that everything be done on a feature branch.
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
RE: Development process (was: Controlling extension-exported classes)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I for one would like to see some design docs on the various changes so
we can grok them. I'm not sure rolling everything out is really what we
need at this point.
-----Original Message-----
From: John Casey [mailto:jdcasey@commonjava.org]
Sent: Tuesday, March 11, 2008 6:15 PM
To: Maven Developers List
Subject: Development process (was: Controlling extension-exported
classes)
That's completely true. I've implemented a new extension mechanism
with little or no documentation in the wiki or on the developers'
list. I was just about the only one committing on trunk at the time,
I was pretty careful to avoid bugs with this new implementation (and
made it number one priority to fix any issues that came up), and I
talked to almost anyone who would listen about this new extensions
mechanism (and the related work to allow multiple plugin versions in
the same build), including you on multiple occasions. All of my
commits have been done in public view, and there has been ample
opportunity to object to the direction I've been pursuing.
Over the past year, I've talked quite a bit about feature branches.
Some of this came as a result of some nasty surprises on trunk,
including some unilaterally deleted code to handle error messaging
that I wound up replacing with two new successive implementations
myself, because the original code was too complex (not my words). The
current implementation which I'm guessing is not overly complex - I
haven't floated a design doc on this either yet - is based on
AspectJ, which I know some people are uneasy about, but which is
still the best solution I've found (I had a functionality gap to
plug, remember). I talked about feature branches because that's a key
part of the process that we all agreed to early last year.
If any of the Maven committers is uncomfortable with the work I've
done on trunk, I'll pull it out onto a feature branch and we can vote
on it. I'd much prefer that there were some viable alternative to
fill the functionality vacuum, but we'll deal with this as it comes.
I still have a TODO to write up the design docs for the extension
mechanism, along with one for the error reporting, and Brett's
mentioned the importance of the branch-doc-vote-merge process in
helping those with limited time to keep up with the pace of
development. If we're all fine with slowing things down on trunk, I'm
fine with pulling these changes out, separating them into individual
design chunks, voting on them, and putting them back in. We can
simply roll back to 2.0.x functionality with trunk in the meantime.
I'm not going to try to be an exception to the rules here, if we can
all agree to follow them. I'm no more entitled than any of us to make
unilateral decisions about Maven code. I've been hypocritical in
these cases, and I'm perfectly willing to make it right.
Unfortunately, that's the best I can offer.
-john
On Mar 11, 2008, at 1:22 PM, Jason van Zyl wrote:
> Which you basically added without much discussion, no proposal and
> Milos' rightly nailed me the last time I tried that and that's
> perfectly valid. You're doing much the same thing and it's you
> yourself that asked that everything be done on a feature branch.
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org