It's hard to reply to a particular phrase in this thread, so I will
write a generic paragraph or two to add to Shane's comment.
Mercury was written without Maven dependencies - it exposes
DependencyProcessor interface and relies on the injected implementation
to supply dependencies - being it property file or a hierarchy of POMs.
Later on - when it came to testing M2 repository implementations, I
wrote a primitive POM reader that is fine for artificially simple POMs,
but that was not good testing and that is why ITs pulled in the
maven-mercury project as a dependency for reading POMs.
Then we implemented a plexus component to wrap Mercury, and it became
apparent that calling M2 repository and configuring it with a
maven-mercury POM reader is - well - not natural. I doubt we'll have
another implementation of POM reader, so it is natural for M2 repo to
use maven-mercury inside, not asking client for an implementation.
So those are the only two places in the Mercury codebase that depend on
the trunk and those could be mitigated by injecting an implementation
and not using maven-mercury.
We'll try to resolve this dependency problem as soon as possible, but
now this is the issue that prevents the release of Mercury.
Thanks,
Oleg
Shane Isbell wrote:
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]
