maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: Mercury status and roadmap
Date Tue, 11 Nov 2008 22:36:57 GMT
Le mardi 11 novembre 2008, Oleg Gusakov a écrit :
> Hervé BOUTEMY wrote:
> > Hi Oleg,
> >
> > I had a look at the code, and I have some questions:
> >
> > - I can't compile the actual trunk since there is an artifact missing in
> > plexus-mercury: org.sonatype.nexus:nexus-webapp:zip:bundle:1.0.1 and
> > org.sonatype.appbooter:plexus-forked-app-booter:jar:1.4
> > Will these artifacts be copied in Central? Or is there a specific entry
> > to put in my settings.xml?
>
> These artifacts are dependencies of mercury-it project - integration
> tests, and should not be anywhere else. Are you sure it's a dependency
> in mercury-plexus?
>
> BTW - plexus-mercury has been renamed into mercury-plexus last week and
> it definitely does not have those dependencies, are you using the trunk?
sorry, it is mercury-wagon that has the problematic dependencies


>
> > - can the main pom.xml inherit from org.apache.maven:maven-parent:pom:9,
> > like every other Maven subproject? This would improve
> > dependencyManagement, reporting (publishing the site would help people
> > discover mercury), and so on.
>
> Mercury is a standalone library that could be used outside of Maven,
> that is why I need tight control over it's dependencies.
inheriting from parent won't add any dependencies to the code. And if 
dependencyManagements values don't fit your need, no problem to override 
them. I don't see what we loose with this parent, but we win a lot of things. 
Or we'll need to improve mercury-pom with configuration that is missing, 
copying/pasting from maven-parent when necessary...

>
> Good point about people discovering it though. We need to do something
> about it.
I'll add site.xml and work on reporting, if you're ok.

>
> > - about Benjamin's remarks at the beginning of the month: I can take some
> > time to help and fix some issues, like I just did with svn properties.
> > But I don't want to interfere with your work on the code: are you ok if I
> > fix licenses headers? tabs? indentation? general coding style?
>
> The best help now will be to try using it - artifact resolver,
> repositories and record any issues in jira -
> http://jira.codehaus.org/browse/MERCURY; mercury-plexus might be a good
> start point.
>
> Coding and headers - please don't change as now it will only create
> sync. problems - this is later.
>
> Thanks,
> Oleg
>
> > regards,
> >
> > Hervé
> >
> > Le lundi 10 novembre 2008, Oleg Gusakov a écrit :
> >> It has been a while since I started working on Mercury, and I think it's
> >> time to update the community on where it is and where it is going.
> >>
> >> Short history: mercury was conceived as a green field implementation of
> >> Artifact resolver plus Jetty based transactional transport. Those two
> >> goals naturally mandated that Repository implementation be also changed
> >> to better match the two above mentioned component changes.
> >>
> >> Where is Mercury today:
> >>
> >> * DependencyTreeBuilder buils a classic Java dependency tree and
> >> resolves conflicts in it using sat4j based resolver
> >>   ** the road is clear to implement other types of dependency data
> >> storage besides POMs
> >>   ** it is also possible to implement other types of dependency
> >> resolution - like OSGi
> >>
> >> * Artifact is split into a sequence of objects:
> >>   ** ArtifactBasicMetadata - glorified artifact coordinates + lots of
> >> utility code
> >>   ** ArtifactMetadata - is ArtifactBasicMetadata with dependencies
> >>   ** DefaultArtifact - ArtifactMetadata plus File pointer to the
> >> artifact binary + pomBlob in the form of byte []. DefaultArtifact
> >> implements Artifact interface
> >>   ** OSGi-like version ranges are fully supported with one exception:
> >> 1.2.3 means what it does now in Maven. OSGi spec x >= 1.2.3 is supported
> >> by supplying a system property option
> >>
> >> * Jetty-based transactional transport is introduced
> >>   * serves http/https/dav/davs protocols
> >>   * I wrote a wagon implementation and have been successfully using it
> >> for over a month in a branch of 2.1-SN replacing standard providers
> >>
> >> * Repository abstraction is modified to work with only GAV-based APIs in
> >> the form of ArtifactBasicMetadata, so inside storage is up for
> >> implementation.
> >>   ** Read and Write operations are separated. Repositories can be
> >> independently readable and writable.
> >>   ** code quality range per repository is introduced
> >>
> >> * Local and Remote M2 repositories are implemented for the new APIs
> >>   ** all defaults are configured to match current repository behavior
> >>
> >> * POM interpretation for these repositories defaults to maven-mercury
> >> component in a branch of maven-3.0-SN that in turn uses ProjectBuilder
> >> to do it
> >>
> >> * All these new components are made accessible as one plexus component
> >> with static API methods to create Repository objects, read, write and
> >> resolve Artifacts
> >>
> >>
> >> What is on the radar:
> >>
> >> 1. prove the correctness of the new resolver by running it side by side
> >> with current resolver and comparing results
> >>
> >> 2. switch several plugins to use mercury for resolution
> >>   2.1 dependency plugin
> >>   ?? .. open for suggestions
> >>
> >> 3. Beef up mercury-plexus component
> >>
> >> 3. Infuse mercury into maven-3.0
> >>
> >> This week I am working on the comparison code - [1.] and will publish
> >> results as I get them. I will also tackle 2.1 as it closely relates to
> >> this work.
> >>
> >> All the current progress is/will be published in Mercury jira -
> >> http://jira.codehaus.org/browse/MERCURY
> >>
> >> Thanks,
> >> Oleg
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message