2008/11/11 Oleg Gusakov <[EMAIL PROTECTED]>: > > > 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?
pom in mercury-wagon has these dependency. I cant' build it too. And IMHO all maven (more globally Apache) projects must be build with artifacts available in central repo. >> >> - 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. -1 : here it's a maven project. IMHO All maven projects must use same parent. And same coding convention/style. Same comments concerning package org.sonatype ! > > 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] >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
