Jason confirmed the issue with 1.9 below has been fixed in 1.9.0.2 Sent from my iPhone 4
On 11 Mar 2011, at 09:36, Alex Blewitt <alex.blew...@gmail.com> wrote: > I've added my SSH public key to ~/.ssh/authorized_keys in order to log on > without requiring a password, as described here: > > http://help.github.com/set-up-git-redirect/ > > I've also subscribed to the dash-dev list. Once we've confirmed we have all > joined that list, we should move discussions there. Presumably Denis and > Wayne are already on it? > > Some things we probably need to decide on: > > * What version of Nexus to use - I have heard of an issue with 1.9 and > indexes being incompatible with Maven 2 clients; it might be good to stick > with 1.8 for the time being > (http://blog.xebia.com/2011/02/25/how-nexus-1-9-ruined-my-day/ and > http://permalink.gmane.org/gmane.comp.apache.maven.nexus.user/4443) > > * What set of repositories to create, for example 'milestones', 'nightly', > 'release' > > After the initial set up is available, we probably want to also consider how > to structure the contents in the repository. At least initially, we probably > want to invite those generating Maven artefacts (ECF, JGit, EclipseLink, > Virgo, Gemini) to put their content in directly. I think we could have a good > interim milestone by making these available. > > Looking further ahead, we probably want to consider other things: > > * Should we create a top-level POM like Apache? > http://repo1.maven.org/maven2/org/apache/apache/9/apache-9.pom > > * Documentation of naming groups - a pre-existing Eclipse bug > (https://bugs.eclipse.org/bugs/show_bug.cgi?id=288644) suggested > org.eclipse.<nextlevel> as the groupId and the full name as artifact, so > org.eclipse.jdt.ui would be a GAV of > org.eclipse.jdt:org.eclipse.jdt.ui:1.2.3. The <nextlevel> would be a regex of > the existing name rather than any relation to the project, so > org.eclipse.osgi.* would have a group of org.eclipse.osgi rather than > attempting to line up with any project ownership like RT or Equinox. From a > permissioning perspective, there's probably a 1-1 mapping between project and > group id in most cases (ECF -> org.eclipse.ecf) though some groups > (Equinox/RT) may have multiple groupIds. > > * Version mapping - as well as the _ and - difference separating the name and > version, we probably ought to drop the build id. Virgo (and other > SpringSource components) use -M01, -M02, -M3 ... and .RELEASE as their > suffixes. This has the property that the versions are short, understandable, > and are lexicographically sorted so will work appropriately when deployed > into an OSGi runtime. > > http://www.eclipse.org/virgo/download/milestones.php > http://www.eclipse.org/virgo/download/ > > 2.1.0.M01 > 2.1.0.M02 > ... > 2.1.0.RELEASE > > We probably want to rename (or symlink?) the files produced by the build > process (rather than rebuilding) but changing the names only. As a result, we > could wait for (say) Indigo -M3 to spin up, then use the contents of the > repository to generate a <ver>.M03 Maven version number. > > Please let me know your thoughts and to confirm that we're all on the > dash-dev mailing list. > > Alex > _______________________________________________ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
