On 23 May 07, at 7:02 PM 23 May 07, Brett Porter wrote:
On 24/05/2007, at 2:53 AM, Jason van Zyl wrote:
I've only ever vetoed code I as working on that someone interfered
with and didn't ask. I've not ever vetoed against the majority on
project decisions. It's Raphael's decision really, and my only
point is that people should accept when they understand what it
actually means to be a part of this project, or ask when they
think they are ready. They can always ask the advice of anyone on
the project if in doubt. It's not like anyone has to jump into a
fire.
That's why I asked him first.
Yah, I don't see the big deal until the point that everyone's
happy and comfortable.
This is where I'm getting lost. Everyone seems happy and
comfortable that this is the code we should be using. I can't
understand why it shouldn't be here.
If you have specific objections about the code from your review of
it, please let's hear them.
1. For the archetypes we are going to provide we need to use our own
mechanism for creating the archetypes and make sure that works. We
need to go through the process of taking a normal project and
packaging it up as an archetype and creating an attached artifact
which is a piece of metadata that describes the archetype. This
metadata can be searched for in a repository to create the archetype
registry. The process we must get working correctly.
2. The interactivity in creating the archetype for the first time is
too much. Just look for a properties file and validate it has the
correct entries. If the right properties aren't present then just
fail. I found the interactivity for creating an archetype overly
confusing.
3. We need to perfect the project to archetype process so the
descriptor can be forever abstracted. Having that exposed is a
liability. We should never need a manual explaining how to make an
archetype by hand.
The rest of the behavior we can work through the list that you have
made, and those can be put in JIRA so they can be tracked easily I'll
put mine there and have start NG-1.0-alpha-1 as the version. Then
there are several components/classes that are close to or over 1000
lines long which will be a barrier to understanding the code. I don't
think it will take long too long to fix and then I would be all for
moving it here.
People can apply patches to the archetypes all they want, they
have to continue to work. The core is totally different so you
can't apply them twice so I don't see the problem there either.
If I fix something or add something on trunk now, I need to make
sure it still exists in the future code. That's the double work,
and it's a disincentive to do anything.
No one has worked at all on trunk, and I doubt anyone will in the
next few weeks. And as I already said the code bases are entirely
divergent so it's not practical to do it in two places. So do it in
NG, it's not double the work.
It's really more a matter of Raphael feeling it's worth moving
forward with in conjunction with coming here as a committer which
I feel is often taken too lightly.
I don't know yet whether we should just proceed anyway, but there
is another option on the table: what if we bring the code into the
incubator?
It will be here soon enough. I don't think is anything really worth
worry about by the time a CLA is processed for either the incubator
or bringing it here directly that will be a week or two, then it
probably won't be long after that it can be brought over.
It doesn't solve all aspects (we still have to maintain two
branches), but it does clear up everything else. Is that an
acceptable option?
- Brett
---------------------------------------------------------------------
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]
