maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@sonatype.com>
Subject Re: resolve dependencies with mercury
Date Tue, 02 Mar 2010 14:14:37 GMT

On Mar 2, 2010, at 7:43 AM, Tobias Gierke wrote:

> Hi,
>> Mercury it's current form is not released, maybe not ever be integrated with Maven
3.x  as it is today and may not be released. It's an experiment we had hoped to be successful
but hasn't made it into Maven 3.x.
>>  
> Just out of curiosity  - what exactly happened to Mercury ? To me it seemed like a very
good way of tackling the dependency resolution problem.

It is a good idea. This particular attempt just didn't work in time for 3.0. But between Pascal,
Benjamin and myself we'll make another attempt. It's not that Mercury did not work in its
own right. Oleg did some cool stuff, but it needs to exactly mimic 2.0 behavior.

>> We have started taking a different approach with Maven 3.x but it's unlikely we'll
have time to integrate it into 3.0.
>>  
> Is there any information on the net about how this 'different approach' will look like
 ? Googling 'Maven 3 dependency resolution' turns up only pages that talk about Mercury.
> 

No, just been busy with making 3.0 solid from the CLI perspective and Tycho, Maven, and Nexus.
Post 3.0 we'll return to the resolution API and committing to publicly supporting it. It will
still be called Mercury but the implementation might change slightly. We may also decide that
it's too much work to try and get SAT4J to work for the old resolution mechanism and just
keep two sets of components in the system: one for the old and one for the new.

Pascal and I are currently talking with Daniel Le Berre about doing a research project through
National Center for Scientific Research in France related to SAT4J in Maven. The goal being
that we would like to merge Maven and P2 resolution mechanisms. The start of this on the Maven
side is a branch that Benjamin has been working on, and from the P2 side Pascal is looking
at making any necessary changes. So it's not trivial work and we want one sound solution that
will work for a long time into the future so we're in no dire rush to push something in.

> Regards,
> 
> Tobias
>> Pascal, the P2 lead, now works for Sonatype so we're trying to set some time aside
for him to think about and try merging the models of Maven and P2 together but this is not
trivial and this may also never work.
>> 
>> We've reverted to creating a composite component in Maven 3.0 called the RepositorySystem.
This component is working, but has not been separated out into a separate library because
our focus for 3.0 was complete backward compatibility at the CLI level for users. I don't
know when it will be separated, I don't know when/if it will be released separately and there
is no documentation. So if you want to use it you'll have to surf through the tests.
>> 
>> We will take the Mercury builds off the grid
>> On Feb 26, 2010, at 8:27 AM, Mr Márton Elek wrote:
>> 
>>  
>>> Hi,
>>> 
>>> I would like to use Mercury to resolve (transitive) dependencies from a Java
SE application.
>>> 
>>> I checked out the latest Maven 3 and Mercury source code and it works well except
resolving transitive dependencies.
>>> 
>>> When I try to use org.apache.maven.mercury.MavenDependencyProcessor I get an
exception:
>>> 
>>> java.lang.NoClassDefFoundError: org/apache/maven/model/PomClassicDomainModel
>>> 
>>> I get the same exception when I run mvn test on the mercury-it project
>>> 
>>> It seems that the Mercury project on the sonatype hudons is live:
>>> https://grid.sonatype.org/ci/job/mercury-1.6/
>>> But it doesn't seem a real maven job.
>>> 
>>> Probably somewhere exists a newer org.apache.maven:maven-mercury artifact which
not depends on PomClassicDomainModel but I can't find the source of maven-mercury project.
>>> 
>>> My questions:
>>> 1. Where can I find the source of maven-mercury project?
>>> 2. Is the Mercury is an active project? It seems even the maven3 trunk doesn't
use it?
>>> 3. What is the recommended method to resolve maven dependencies from Java application?
>>> 
>>> Regards
>>> mart
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> 
>>>    
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>> 
>> 
>>  
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message