maven-project-builder was a refactoring and moving of certain key classes and interfaces from maven-project, specifically for Mercury's requirement of not being dependent on largely portions of Maven trunk. As it stands, the maven-project-builder doesn't have any dependencies on the rest of maven trunk. But, as Brett pointed out, maven-project-builder code-base is not yet stable (meaning it will undergo a lot of future code changes), creating a tight coupling between it and trunk. We end up having to do a release of maven-project-builder before Maven everytime.
Once we get maven-project-builder stable, moving it out of trunk becomes a much more viable option, giving us a place to build out the specification tests and to incorporate and test all sorts of extensions: Mercury, OSGi, C# Project Files. As for moving maven-mercury to it's own project, we will encounter the same problem as above; as in Maven 3.0 alpha-2+, we are integrating Mercury, meaning maven-mercury is also likely to undergo a lot of changes with every Maven release. So the key question for me is where does maven-mercury reside for now? In Maven trunk? Or in Mercury? If Mercury has a firm requirement of not being dependent on trunk, then we need to discuss the logistics of how we do releases to mitigate the pain of doing this, given the code-bases are not yet stable. Shane On Mon, Dec 1, 2008 at 5:58 AM, Brett Porter <[EMAIL PROTECTED]> wrote: > On 01/12/2008, at 8:12 AM, Oleg Gusakov wrote: > > >> >> Jason van Zyl wrote: >> >>> Oleg, >>> >>> Shane and I were chatting and I think the maven-mercury module in trunk >>> can actually go into Mercury itself, there is nothing trunk specific in >>> there and almost makes you trunk free. >>> >> This kind of beats the purpose of externalizing dependency processing. >> Mercury defines an interface that any dependency reader should implement, >> maven-mercury is the maven POM specific implementation. >> >> Why would we stick specific implementation with a generic interface? It >> would make sense if we also externalize POM processing from the trunk and >> make it into a component (see below). In this case implementation will be an >> adapter, that will not depend on the trunk. >> > > I agree, Mercury should not have any trunk dependencies. > > >> >>> We're trying to figure out what to do with the project builder which only >>> relies on maven-shared-model. Once alpha-1 is release I don't want the >>> external dependency structure changing, or the layout of the modules >>> changing in trunk so if you can move that back to Mercury that would be >>> cool. >>> >> That's a hard one. Original idea of Mercury was to make it a >> Maven-independent library. Well - because Mercury provides access to M2 >> repositories - it has to read POMs, so some kind of Maven dependency is a >> must. I think that POM processing should be externalized into independent >> component, so that shared-model + pom-interpreter are a low level libraries >> that Mercury and project builder can depend on. Is that even possible? >> >> Shane, it is possible to make POM reader into a component? How clear are >> it's interfaces? >> > > It looks possible, but I would think that is one abstraction too far. It > would be confusing in terms of release cycle and bug reporting to track a > different version of the project builder to that of trunk. While the shared > model is reasonably stable in terms of changes (though still is taking > changes), the project builder won't be for some time. > > I think the current scenario is perfectly reasonable. If a user of Mercury > wants Maven POM processing, they depend on o.a.m.mercury:* 1.0-alpha-2 and > o.a.m:maven-mercury 3.0-alpha-1 (probably a better name). They are free to > choose different versions of each as long as the external APIs remain > compatible (which would only need to be enforced after 1.0). If for some > reason they choose to use Mercury without Maven, they don't depend on it and > that component is not available to them. Mercury will still work. > > Cheers, > Brett > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
