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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
