Having worked with Aether yesterday in some test code, and after sleeping on it last night, I'll withdraw my objections for now.

This looks like a good way forward in terms of code. I'm still concerned about volatility in terms of writing plugins that need to resolve X or Y artifact at runtime, but I agree that we need something better than we currently have.

I say go ahead and integrate it, and let's see what happens.

As for the Guice stuff, I never had much objection to that.

On 8/4/10 2:36 PM, John Casey wrote:
I want it to be clear that the _only_ thing I asked for was that the
Aether API/SPI _specification_ be hosted in a neutral location where
Maven committers can contribute to the design.

Let me emphasize that: API/SPI only, and in a neutral location. The
Maven project is not what I'd call "neutral" here.

If, as you claim, the API is set, then we're only talking about the
future here. We're talking about having open discussions where people
can have a real vote on new features in the API/SPI.



I believe I'm sufficiently grateful to Benjamin, Kristian, and the
others for implementing this. From what I can see, it looks like a
really good way to go, and I have no doubt the code is excellent. And,
the implementation can live in Timbuktu as far as I'm concerned. I have
no doubt that you'll publish it so others can use it...as you say,
that's the whole point.

The _only_ thing I want for my vote to integrate is that we can make
this API/SPI a standard set of interfaces by making it its own project
somewhere that Maven committers can get automatic access...and then
leaving it there. If that's not ASF, I have no problem with that. But I
think Maven committers should have the automatic ability to participate
in shaping the Maven's contract with the repository into the future.

This is a critical piece to Maven, and TBH _not_ having this access may
be part of why projects like Ivy won't use the Maven repository
code...they aren't represented in the decision-making process.

On 8/4/10 12:57 PM, Jason van Zyl wrote:

On Aug 4, 2010, at 11:54 AM, John Casey wrote:



Having a stable set of specifications define their interaction with
Maven would make plugin development and embedding MUCH better. In
fact, I think establishing this practice might be the single best
contribution we can make to Maven in the near term.


All due respect, but that dodges the question of separating and
standardizing the API from the implementation. It also dodges the
discussion about who sets the design of the repository format and the
API spec used to access it.


To me that's sounds like a bunch of busy work without much value. It
works, and it's going to evolve by having people use it. The ultimate
API will never be arrived at without lots of integrators. That's how
everything evolves.

You're asking the Maven community to give up one of its greatest
creations - the repository format that has become a de facto standard
- and become completely dependent on a project whose future may be
uncertain. It's easy to talk about companies as these fixtures in the
market, but the fact is we're talking about giving complete control
over the Maven repository API / format to a start-up.

I can't make you, or anyone else, do anything you don't want to do.
Vote against it, implement your own library, I'm not putting a gun to
your head. I've done what I feel is best, I've laid out what I think
is best. You can disagree and take action accordingly.

Start-ups are not known for their stability. Then, the company in
control _may_ decide (unilaterally) to move the whole shebang to
Eclipse. There's absolutely no role for Maven developers in this
model, unless they go out and re-establish their merit on a new project.


First, the code is ASL so if we rolled over tomorrow then take it.
That's really not a problem. Second, yes we created it so if we want
to take it to Eclipse we can do that. People who do the work get to
make choices like that. Eclipse is solid place to do OSS work.

I'm tired of the endless debates about infrastructure, release
process, using git, and I honestly think Aether not being here is the
best thing for getting others involved.

I'm not talking about the merit to contribute implementation details
- though the ASF concept of non-expiring merit argues strongly
against losing access to that. What I'm talking about is the right to
contribute to the design of the repository format, API, and SPI (now
that I notice that's separate from the API). The language we use to
share artifacts and metadata should not be under the sole control of
a private entity.

That honestly has nothing to do with where the code is. If we shut
everyone out, we'd just be shooting ourselves in the face and ruin any
reputation we have of being meaningful contributors to the Maven
ecosystem. That doesn't do Sonatype any good. The argument that the
only place that can be done is simply not true.


Sure, there haven't been too many contributors to Maven 3. But how
much of that has to do with the velocity of work done and paid for by
Sonatype,

It has a great deal to do with that. No one can keep up with full-time
people but that doesn't mean contributions should fall off to zero
which is what's pretty much happened. Kristian and Olivier being the
exceptions.

the dramatic and repeated shift in direction by those paid
contributions (mercury for example),

That was not a dramatic shift at all. We attempted to make an artifact
resolution API and the first attempt failed. No shift, a second more
successful attempt.

the need to chase code from SVN to GitHub, to still other GitHub
repositories, and the lack of discussion of the design of any of it?

It was not developed here, you do not have to accept it. I posit we
would have been in endless debate, no one would have contributed and
we'd be in the same boat. My conjecture possibly, but no different
then your view which is also conjecture. The fact is right now we have
a working library and a way forward. Anyone here who feels I'm limited
their choice can blame themselves for not participating previously.
Yes, I felt it would be more expedient to just do it because this
project needs to get on the rails again and I believe this is one of
the critical steps. Aether was implemented in a very short period of
time. There's code there, it works and now people can provide
feedback. I honestly feel that works better. Yes I told some people
about it and not others and that was purely a judgement I made based
on what people have been contributing lately. That's why I didn't
develop here because that mode of operation is looked dimly upon here
so I didn't do it here. And I want
the velocity to continue, and that just is not going to happen here
based on my cumulative experience of over 10 years here. I wanted to try
something different and this is the result. You may not like it, you
don't have to agree, but you can't make me do what you feel is right.


It makes me uneasy to see how much this has become a skunkworks type
of project, where much of the development takes place behind closed
doors and then gets dumped on the Maven community.

You're entitled to your point of view. I'm interested at this point in
the efficacy of execution and the survival of the project. Not whether
everyone has the warm fuzzies. Apart from the Maven 1.x to Maven 2.x
I've tried not to fuck users and doing so now wouldn't serve my
commercial or non-commercial efforts.


Maven contributors established the foundational concepts (and code,
from what I can tell) for Aether; Aether is a refactoring of that
essential design and format. If you expect Maven to use Aether, then
the Maven community deserves some say in the future of the format and
API. That's my opinion.


Just because the code base is not here does not stop you from
participating. I think that's just something you're going to have to
reconcile yourself to. I believe the code needs a chance to live
outside these walls. And Aether is a very different design, sure it
borrows things from all over the place including here but it's
definitely not a refactoring.

There isn't just the Apache Way and nothing else. As I've stated
before Maven 3.0 is an effort at backward compatibility with a way
forward. We have not gone and secretly and radically changed Maven and
dropped Maven 4 in your laps. We made a library, yes an important one,
but it's a library nonetheless. I've said that all new features
developed in the core and that's not going to change. And guess what?
There are no new features and we've basically be doing the shit work
of writing tests for 2 years that no one has helped with. We made
Aether and made it compatible, turfed Plexus to be more sensitive to
users being confronted with my one-off IoC and made it work with all
existing code. I don't think anyone understands how much work that
was. The project would never move forward and it would be in a "good
enough" state which would leave it to be trampled by the competition.
I'm just not going to let that happen. Some work like what we've done
is just never going to happen h
ere, and it's definitely not going to happen without millions of dollars
of concerted effort. Which is where Sonatype is at this point. I love
that I've been fortunate enough to provide the work that's been done. It
was the exact same thing with Maven 2.x. If I hadn't start Mergere do
you think Maven 2.x would exist? I honestly doubt it. I try to balance
what I think is necessary, and what I can reasonably do at Apache and
when what I think needs to be done falls outside of those parameters I
opt out instead of trying to force my opinions on everyone here.

There are things I believe work best here, like when we start
discussion outward facing features for Maven 3.1. I don't think that
can happen any place but here with a lot of discussion as painful as I
think that's going to be this is the right place to do that. For the
bits that are really, really hard require dedicated people, talking on
the phone 5 times a day and pretty much every other violation of what
would be considered the Apache Way. Every commercial company involved
here probably does lots of things like we do but they don't attempt to
contribute it back. I don't want a disparity in my working life where
the OSS stuff I work on is good enough and then I have to build around
it to make something great on the commercial side. I want Maven to be
great and this is how I approach it.

I'm doing what I think is best for Maven users. If you disagree I'm
not going to fault you, and I encourage you to do what you think is
right. I wouldn't ask anything less of anyone involved here.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

-- Thoreau





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to