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 
Zitat von Alex Blewitt <alex.blewitt@xxxxxxxxx>:
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)
As we speak, I'm also struggling with some odd issues in Nexus 1.9 (can't download artifacts which exist in remote repo but not in the index of the remote repo; can't download stuff that I manually moved into the work directory of Nexus even though the indexer sees it). 

So, yes, I lean to towards 1.8.x, too.
* What set of repositories to create, for example 'milestones', 'nightly', 'release' 

Good question. Here are my 2 cents:
This depends on the mapping between Eclipse and Maven version numbers. There are several options:
1. We can keep the qualifier as is. This is how the last guy did it who uploaded Eclipse into Maven central. Example: http://repo1.maven.org/maven2/org/eclipse/core/org.eclipse.core.resources/ 

+ Least amount of work
- Hard to use for humans
- Doesn't fit the Maven versioning scheme

2. We can strip the qualifier.

+ Good for humans
+ Fits the Maven versioning scheme
- If the Eclipse guys bring in two builds (same version, different qualifiers), we can't map that. Not a big problem with releases but how about milestones or even nightly builds? 

3. We could do both

+ Everyone can do as they please
- If everyone can do as they please - confusion ensues
- Waste of disk space - unless we use hard links. What will Nexus think?

More points to consider:
* Nightly builds could be handled like SNAPSHOTS. Maven saves the files with a unique ID in the repository and maps the last of those IDs (as per metadata.xml) to "SNAPSHOT". It should be possible to map one qualifier to SNAPSHOT this way.
* Not all Eclipse projects can be used "as is". In the MANIFEST.MF, Eclipse plugins often say: give me any version or "version 1.0+" (for plugins that come with Eclipse 3.6).
In the Maven lore, versions should be fixed (i.e. no version ranges). This means we need to map versions from the MANIFEST.MF to the versions in our POMs (at least until we can convince everyone to add a Maven build step, or to use fixed versions ... which won't happen).
* Some autogenerated POMs have bugs. I don't have an example handy but I had to fix a couple of generated POMs from the Xtext project. This means we need: a) a way to manage patches, b) a quality step before we publish artifacts, c) a way to publish fixes (with a new version?) when we fail, d) a way to tell the world that a fix has been published, so they can update their dependencies.
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
Maybe. It would be nice to nail down the versions of all artifacts in a Eclipse release. But I never needed it.
* 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.
Yes. It may seem stupid to repeat the version name but it's necessary. Otherwise, we would end up with 20-30 "ui-3.6.0.jar".
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. 

Agreed.
* 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
I was thinking in a similar way. Using snapshots for the milestones doesn't work. Creating a new repo for each milestone doesn't scale. My objection with "M01"..."RELEASE" is the sort order.
Tools like the version tool of Maven should offer the latest version. If you run it today, I get "20030203.000129" as the latest version of "commons-lang" (instead of 2.6). 

So M1..REL would work but mixing that with I and N builds wouldn't.

Which gives me an idea: How about we use the artifactId?

org.eclipse.core - Releases
org.eclipse.core-I - Integration builds
org.eclipse.core-N - Nightly builds
org.eclipse.core-M - Milestone builds

People could use a property to switch all artifacts at once.

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/                   http://blog.pdark.de/

Back to the top