On Aug 6, 2010, at 10:08 PM, Brett Porter wrote: > > 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. >
Ideally there should be no API leakage from Aether. As part of the plugin API we should provide access to whatever resolution functionality we feel is necessary to expose and hide Aether. Initially a few attempts are likely needed and I might try using the Aether API directly. I honestly don't think using Aether APIs directly would be a great idea and really I think we exposed way too much previously. It boils down to answering the question: what do plugin developers actually need? Walk the dirty tree, walk the resolved graph, filter, I don't know yet. Maybe I'm wrong and this might just end up being the complete replication of the Aether API at which point I don't know if it makes sense to try and hide it. This is why we preserved the use of the old API because this stuff just takes a while to figure out. Even us working full-tilt it's taken a while. I would like to limit drastically what's in the plugin API for dealing with artifact resolution. >> >> 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. That bit of Mercury actually works. We use it in Nexus and we'll likely backport that bit to Aether. > 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. Sorry, but I think that's nonsense. Oleg was not locked in a vault. If someone actually worked faster then us and implemented something we stated we were going to do I would have been fine with it. But I don't think anyone actually understands how much work it is. I don't know how exactly things are going to look ultimately but in the case of Aether we just went nuts for 8 weeks. The sequence of events was probably required. I didn't know how hard it would be and it proved to be hard. I honestly don't think design by committee works for this stuff. Much like parallel builds, it just drops out from a couple people doing a lot of work and then there's something to look at. Dan dropped in the first implementation and he just did it. No one much batted an eyelash. Kristian then picked it up. After looking at Aether I think people will agree it's the best starting place we've had. Nothing is perfect, but I think it's a good place to start. > 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 :) Someone has to be an optimist. > > 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 hope you're right. > 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. They are not, all the bits that are Maven specific are in Benjamin's branch. Aether has absolutely no dependency on Maven and knows nothing about Maven. The ArtifactDescriptorReader for POMs everyone will have access to. > 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. Unavoidable. We're not going to bring in everyone other dependency and any developer worth their salt can figure out how to pull in sources for dependent projects. Aether is all JIRA and Confluence it's not a big leap for anyone here. The barrier is not and never will be the infrastructure, it's people's time and willingness to contribute. > I lived through the worst of it in Maven 2.0/Plexus/Modello/etc. and it drove > me crazy. It's no different now. We still have Modello and now Guice which none of you have any control over. We are very fortunate to have Stuart working with us at Sonatype who is a committer but by your measure this is worse. Totally different infrastructure and no access. > 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. Aside from the memory issue that needs to be resolved Aether is the only viable way forward with respect to artifact resolution. Kristian has looked at it here, Brian and I are familiar with it and internally at Sonatype Tamas done an initial pass at integrating it into Nexus and Alin has it working in our p2-based runtime assembler (part of Proviso) so we already have some very skilled people who have it working in other systems. I have no doubt it will be picked up by some of the other build tools as well. > > 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- We all have problems. How we deal with them is a measure of our worth. -- Unknown
