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]
