oleg, I used the codehaus dav to test against, it worked quite well....if you have a codehaus account you have a dav drive you can work with for it dav.codehaus.org/user/oleg I believe
catch me on irc and I can help jesse -- jesse mcconnell [EMAIL PROTECTED] On Tue, Nov 11, 2008 at 7:20 PM, Oleg Gusakov <[EMAIL PROTECTED]>wrote: > 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] >> >> >> >> >
