You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <jv...@sonatype.com> on 2008/11/30 18:19:26 UTC
maven-mercury
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.
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.
Might you also take a look and verify that Mercury builds with trunk
and close the issue for 3.0-alpha-1 if it works.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-mercury
Posted by Brett Porter <br...@apache.org>.
On 02/12/2008, at 8:38 AM, Oleg Gusakov wrote:
> 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.
My normal thought here would be that the ITs are in the wrong place.
If they are testing the integration between maven-mercury and the rest
of mercury they probably belong where maven-mercury (so, in Maven's
Core ITs at the moment). If they are testing the integration of the
various Mercury components in it's trunk then the current place makes
sense without the dep on maven-mercury.
So, I'd consider moving them, but if that's inconvenient they can
probably stay where they are until things stabilise. ISTR the IT's
wouldn't be part of the release anyway.
>
>
> 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.
This is just a test dependency and would think that it doesn't need to
be there. If the unit tests rely on a particular implementation they
are probably over-reaching.
I agreed with everything Shane said, and I think it's a clear
indication the current structure is the best for now.
Thanks,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-mercury
Posted by Oleg Gusakov <ol...@gmail.com>.
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 <br...@apache.org> 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
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>
>
Re: maven-mercury
Posted by Shane Isbell <sh...@gmail.com>.
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 <br...@apache.org> 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
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: maven-mercury
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-mercury
Posted by Oleg Gusakov <ol...@gmail.com>.
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.
>
> 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?
>
> Might you also take a look and verify that Mercury builds with trunk
> and close the issue for 3.0-alpha-1 if it works.
Trying, trunk did not compile for me yesterday. I will update jira as
soon as everything works together.
Thanks,
Oleg
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org