Herve,
There is another piece you can help with if you don't mind.
I used unit tests to shape up the functionality, but they can sure use
an independent eye. Plus writing more tests will help you to better
understand the code and then modify it.
Can you look into mercury-repo-virtual and write more unit tests for it?
Try to pound it with version ranges/LATEST/RELEASE/SNAPSHOT
combinations, combinations of several readable/writable local
repositories, remote repos.
Don't hesitate to mail me directly any time to discuss it. May be we
also should chat on the phone.
Thanks,
Oleg
Hervé BOUTEMY wrote:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
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]
