It can go to central, we just need to setup the sync. Regarding the parent, Oleg if you don't want the maven parent then you should use the apache parent and copy some defaults from the maven parent.
-----Original Message----- From: Jesse McConnell [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2008 5:18 PM To: Maven Developers List Subject: Re: Mercury status and roadmap 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] > >
