I brought up the integration testing dependency earlier as well...imo if the artifact is not going into the central repo then the pom needs to link to a repository that will bring it in...
people ought to be able to checkout any maven project and build it using strictly a stock maven install, no repo manager, etc.. and packaging ought to be org.apache.maven as well :) imo at least jesse -- jesse mcconnell [EMAIL PROTECTED] On Tue, Nov 11, 2008 at 4:07 PM, Olivier Lamy <[EMAIL PROTECTED]> wrote: > 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] > >
