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]
