On 07/08/2010, at 2:05 AM, Jason van Zyl wrote: > > On Aug 6, 2010, at 11:54 AM, Brett Porter wrote: > >> >> On 07/08/2010, at 1:22 AM, Brian Fox wrote: >> >>> I'm not so concerned about confusing users with a beta2 and then a >>> beta3, that can be mitigated easily in the announcement. More releases >>> won't hurt anyone. >>> >>> Let those working on it decide what to do and when presented with a >>> vote, I'll test, verify and vote accordingly, regardless of if it's >>> beta2 with or without Aether/Guice. I would just rather see one >>> sooner rather then later. We too often have a tendency of waiting for >>> everything to be perfect. They are betas, pick one and stage it I say. >> >> +1 to that >> >> Not to extend the thread too much further, but I'd still like to see someone >> answer my questions about the impact of changing the project's scope by >> moving the artifact implementation to Aether before that lands anyway. We've >> had a lot more time to ponder Guice. >> >> 1) is there any alternative that would keep what we have today - the Maven >> implementation and API for Maven plugin developers - within the Maven >> project, while still allowing Jason's desire to involve more people in an >> expanded effort? >> > > The current Plugin API is not changed at all. We didn't change any of the > plugin code. No impact on plugin developers. A new API is a different story > and that will be far more powerful with JSR330 and Aether.
Sorry, I wasn't clear. When I say "plugin developers", let's say someone was writing the Dependency plugin anew against Maven 3. What artifact resolution APIs would they use? I didn't spot any examples of this in Benjamin's fork of Maven. Essentially the same question as https://issues.sonatype.org/browse/AETHER-5. > > No one is going to work on the Maven implementation, that is clear from the > sheer lack of neglect over the last 3 years. No one is magically going to > start working on this. That much is clear. I want to be clear that I'm not talking about continuing to work on the existing code - I'm talking about working on the new code that covers the existing scope of Maven. I thought this was the point of the repository system in trunk up until now - compatibility but more flexible and extensible so that improvements can happen both here and things built on top of it elsewhere. As for lack of activity over recent years, well it's carts and horses as John said before. I had a working PGP implementation that was shot down because Mercury had already "solved" it, even though it wasn't integrated to trunk. Other new features have been stalled waiting for a 2.1/3.0 release so that we can change the POM to properly utilise them. Any attempt to fix bugs would have been fruitless because there was always another thing out there that was going to replace the current code - in fact I've been trying to get you to open up your declared plans on artifact handling since we met at JavaOne in 2007. I can think of a handful of committers here that had a crack at Mercury and ultimately had their time wasted on a moving target. I had to promise myself not to get involved until 3.0 was out because I had burned so much time on dead ends. I thought in December last year we were getting there (http://markmail.org/message/4w46ioimp4vrssx3), but apparently "I think we're done" was a bit more of your endless optimism :) My endless optimism is that if Maven 3.0 comes out, or even looks like coming out, you'll see activity here lift to meet the challenge. I certainly empathise with your point about folks making demands and then not following through with the help. I would much rather be helping on making this happen than getting bogged down in these discussions. I agree it's best to ensure the changes to the architecture get into Maven 3.0 so that we're not shifting the target significantly again in the near future. But based on what I've seen so far, and my experience in the past, I remain reluctant to see development of Maven repository APIs move outside of this project. It is not an easily reversible step, and I want to ensure that anyone that wants to get an improvement into Maven doesn't have to navigate the different controls and infrastructure of another project. I lived through the worst of it in Maven 2.0/Plexus/Modello/etc. and it drove me crazy. But most of all, I want to see the shortest (but still correct) path to a 3.0 release - we need the unification it would bring. I may learn different from your answer to the above, but at this point it still seems like an evolving Aether poses a risk to that. I'll still do what limited things I can to help see Maven 3.0 ship, if we can get some agreement here about what that really means. Thanks, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
