Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dash-dev] Maven Repository at Eclipse

I am on the dash-dev mailing list. I'm not sure what help I'll be, but
I'm there.

Wayne

On 03/11/2011 04:30 AM, Alex Blewitt 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
>
> * 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 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
>


Back to the top