Community
Participate
Working Groups
The testing repository [1] contains artifacts which have been converted from p2 artifacts (apparently by using the tool described here [2]). While these converted artifacts may be useful, it is very important that the converted artifacts don't clash with "native" artifacts produced by Maven builds running at Eclipse. It is possible to convert Maven artifacts into p2 artifacts (e.g. with the Felix bundle plugin and Tycho), and it must be possible to distinguish the original Maven artifacts from the re-mavenized artifact produced by Dash. I am not sure if you are planning to continue the mavenization of p2 repositories, but if you do, please find a solution to this problem first. A simple solution would be to use a groupId which identifies the Dash-converted artifacts, e.g. something like "org.eclipse.p2-converted" or "org.eclipse.mavenized" [1] http://maven.eclipse.org/nexus/content/repositories/testing/ [2] http://wiki.eclipse.org/Maven_Tools_4_Eclipse
I agree with you. Some thoughts: 1) We could put that into the classifier which means we'd use the same group and artifact ID. From the abstraction perspective, this seems to be the most clean solution but I have a feeling that it's brittle (but that might be because I rarely use classifiers) 2) We could use a different group ID like org.eclipse.<project>.dash or org.eclipse.<project>.mavenized. I'm uneasy about this because it doesn't clearly communicate intent. 3) We could put these into different repositories with the same group/artifact ID. I fear this solution would make it too simple to pollute your local repo or proxy with artifacts that you don't want and that you can't easily clean. It also would make it impossible to build projects on a single machine that use both. So 3) is clearly not an option. Two left. The classifier is less intrusive and a little bit easier to automate. Both solutions are certainly viable. So what do we want this for? My main concerns right now are these: a) Make it easy to get the dependencies that you want b) I want people to be able to build Maven projects based on Eclipse artifacts with confidence. If it's in the repo, it should be usable without doing research. c) If possible, it would be great to be able to mix converted and native artifacts. The crux: The dependencies. I wonder if I can tune the POM to allow users to control something like "Take native Xtext but the converted EMF" The problem here: In the beginning, the native repo will be missing 99% of the artifacts. Over time, we'll get maybe 2-4% of all artifacts in native format: It's extra effort and the automatic converted artifacts are good enough for many scenarios. So most projects won't do it. This means we'll get things like: - Native artifacts that depend on converted ones (most common case in the beginning: Many core packages won't be available natively) - Converted artifacts that depend on native ones (because my simple patching tool maybe can't cover all the bases - wrapped JARs come to mind) - Native and converted artifacts depending on patched artifacts (like org.apache.batik.pdf where we'll have to rip out commons logging) After writing, I'm not 100% convinced anymore that splitting is such a great idea after all. You can easily see which POMs are converted by looking into them (and I can add a comment if you want to make it even more obvious). For one, I don't have the manpower to maintain so many repos. My personal prime goal is a single repo that contains everything for building Maven projects that depend on Eclipse artifacts. I don't care about PDE/Tycho/OSGi/p2 based builds. This is my main focus. I build Java apps and I avoid OSGi and p2 whenever I can because they don't offer me anything I need. Conclusion: Right now, it's a nice to have. Need some more thought.
Aaron, please see Bug #371475 regarding the change of 'groupId' / 'classifier' and its consequences.
maven.eclipse.org was decommissioned via bug 405750 and replaced with repo.eclipse.org. See: https://wiki.eclipse.org/Services/Nexus
