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?
- 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.
Good point about people discovering it though. We need to do something
about it.
- 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
