Re Wayne's blog about an Eclipse.org Maven Repo:
EMF has had an undocumented/unmarketed Maven2 repo for about 4 years now.
All you need is to take an update site zip, unpack it, rearrange the folder structure, and rename the jars. Then you create little XML files called .poms to describe the jars in the tree, and Maven-aware tools can read the tree. It's fairly trivial. http://download.eclipse.org/modeling/emf/emf/maven2/ is the URL, IIRC. About once every 2 years someone asks about our providing such a repo, and I give out the URL. Clearly not a huge demand for it.
One might argue that creation of such a folder structure is in the purview of Athena's publishing scripts, which today eases the process of copying your bits to download.eclipse.org, then unpacks your Update site so it can be scanned by p2 rather than downloaded as a single archive. It too is fairly trivial. I would not be adverse to converting my existing shell script for the EMF repo creation into a generic Ant script for use by Athena users.
Frankly though, I think it would be more valuable if the m2eclipse folks added support for reading/converting p2 repos. Publishing yet another file format would require another release-train-like workflow (we already have two: EPP and buckybuilder for Galileo) and more people maintain it. Even if every project published their own maven repo, we'd want for the sake of ease of use to aggregate them into a central place for easier navigation and discovery by maven tools. So, like with Ganymede, we'd have each project's bits copied to two places on disk for each build. (Galileo used composite repos to POINT at project repos rather than copying them saving tons of disk space and CPU cycles. AFAIK, Maven does not support this concept, but I could be wrong.)
There's also another benefit to having tooling to support converting from p2 repo to maven2 repo: the aggregate repo could be housed at apache.org and suck THEIR bandwidth and support resources instead. Thus just as Eclipse.org is upstream from Fedora's Eclipse project .rpms (which are upstream from Debian/Ubuntu's .debs), Eclipse.org p2 repos could be upstream from Apache's Maven repo(s). After all, Apache already collects maven artifacts for non-apache.org projects to facilitate the use and adoption of maven, so this is entirely in line with their standard operating procedures.
Thoughts?
Posted from Blackberry using Opera Mini, by the side of Shawnigan Lake, Vancouver Island, BC
13 comments:
One strategy is to have p2 emit the simple repository in such a fashion that could be read by Maven repos... so both parties win. Or enhance the p2 mirroring tool to mirror a p2 repo as a maven repo. That's one thing we can provide for our user community.
It's hard to ignore Maven though.
You don't need aggregation with Maven, you publish to the repo, period. There is no project repo duplication.
I don't see a compelling reason why the world should bend to p2, rather than having Eclipse adopt Maven.
I agree, Nick. Every Eclipse project is already understaffed and the infrastructure is a big expense as-is.
m2eclipse already counts among its advertised features "Resolving Maven dependencies from the Eclipse workspace without installing to local Maven repository." It does seem reasonable that they could do something similar for p2 repos.
I believe the commercial version of Nexus (sonatype's product) allows for exposing a maven repo as a p2 repo - not sure if they can expose a p2 as a maven repo..but that would be a natural extension.
Providing a maven repo makes life much easier and opens the door to a simplied build process (athena might be cool, but is yet another handcrafter script, and buckminster can already consume maven repositories).
Providing a repository is simple (there are commercial tools which map p2 repos as maven repos) and also allows discovering new releases automatically by your build tools (should you need it).
As a note, maven can aggregate artifacts from many places. It is considered good practice to have a corporate proxy/repository which does that job (it is configured with as many remote repositories as needed), so publishing a repository per project is possible. I would risk saying that this is a lot more mature than aggregating p2 repositories.
Regarding the use of custom scripts to generate a maven repository... yes, it is possible and simple. But repository managers are better than custom scripts, since they easily keep history of available versions... and you do not need to use maven to publish to them (although, if you do, is just an step in your build process).
Looking at the future, I can see maven replacing athena and (headless) eclipse builds becoming really simple (because the knowledge is encapsulated on maven plugins) and able to generate tons of information almost effortless (I am thinking about maven reports, sonar quality dashboard, automated unit and integration testing...). There is still work to be done on the maven plumbing, but work has already started and an official repository will be important to enable adoption.
Finally, I would like to think that having a maven repository will also increase the use of the non-ide components, such as EMF.
On the URL http://download.eclipse.org/modeling/emf/emf/maven2/ I get:
---
404 File not found
We're sorry, the page you requested cannot be found. Below are some links that may be useful.
* Try this link on the Archive site: http://archive.eclipse.org/modeling/emf/emf/maven2/
...
but that URL doesn't work either.
incze
I believe that the Sonatype guys (who makes m2eclipse, Maven itself and many other Maven tools) have discussed supporting other repository types.
The conclusion is, as I recall, that the current Maven architecture supports this very poorly. And that it is something they want to improve in Maven 3.
But when M3 is released is a question they have so far not been willing to discuss.
I am all for pushing artifacts to maven central and consuming from there...the issue is with eclipse foundation policy of trust and whether they will trust my building and releasing of a distribution from an eclipse.org website with artifacts I am pulling from maven central. Seems simple to me but is non-trivial to build that level of trust.
If we can cross that hurdle, great!
the other fundamental issue is where to place artifacts in the maven central repository, what groupId and artifactId does the special eclipse sanctioned servlet 2.5 bundle go under? eclipse is repackaging fundamental dependencies with new metadata and then signing those artifacts, should eclipse's special javax.servlet 2.5 version go under javax/servlet or under org/eclipse/#### something.
anyway, we need this sort of repository with artifacts which have good metadata for transitive dependencies and it will be interesting to see how it all comes together.
cheers
jesse
The recent proposals on the bug itself have nothing to do with copying or moving files around. We're suggesting to translate the files on the fly into whatever format is needed.
What would it help a netbeans user if m2eclipse can read such a p2 repository?
Making p2 repositories readable by maven, isn't that what Tycho is doing?
Jesse, you have a point on those groupIds and artifactIds conventions. I believe we should file a bug for those. What do you think ?
We (Sonatype) do have tools like Nexus that can support this with on the fly conversions, see my comments on the eclipse bug for more details about how that could work for everyone, not just M2eclipse users.
Post a Comment