Bugzilla – Full Text Bug Listing
| Summary: | Mapping Rules should expand additional properties | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Johannes Utzig <jutzig.dev> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | henrik.lindberg, thomas |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
The schemas are not API by design. The idea is to provide an implementation of a Repository. BTW, have you looked at the b3 aggregator? It is capable of reading and writing p2 metadata (using EMF models) and can read and write maven style repos as well. Hi Henrik (In reply to comment #1) > The schemas are not API by design. The idea is to provide an implementation of > a Repository. > Ok, I see. I have a reverse engineered version of a schema now (probably not complete) to derrive an EMF model from it if anybody wants it... > BTW, have you looked at the b3 aggregator? It is capable of reading and writing > p2 metadata (using EMF models) and can read and write maven style repos as > well. Yes, I know the b3 aggregator, but I do not think it is the right tool for me. I did not want to use it to read and write the p2 metadata since I want to minimize dependencies. If it's just EMF though, I should have done that instead... As for the reading and writing maven repositories and p2 repositories, I am aware of the capabilities. It is a great tool, but it's not exactly what I'm trying to do. b3 creates an aggregated repository from several other repositores. What I try to do is more an incremental approach without actually copying any artifacts. I want to write a plugin for the apache archiva maven repository (hence minimizing external dependencies) that incrementally updates the 'virtual' p2 repository content.jar and artifacts.jar whenever a new artifact is deployed to archiva. I naturally have no control over the placement of artifacts within archiva, so the p2 layout of plugins/ID_VERSION.jar does not work for me. So, as far as I can tell, the only way to implement this without referencing arbitrary artifact properties is to create thousands of mapping rules. One for each artifact. (In reply to comment #2) > b3 creates an aggregated repository from several other repositores. > What I try to do is more an incremental approach without actually copying any > artifacts. Please note that the b3 aggregator will avoid copying artifacts when mapped repositories are marked with mirroring = false. It will then just create a composite artifact repository that references the incoming sources. (In reply to comment #2) > Hi Henrik > Yes, I know the b3 aggregator, but I do not think it is the right tool for me. > I did not want to use it to read and write the p2 metadata since I want to > minimize dependencies. If it's just EMF though, I should have done that > instead... I have used the aggregator's EMF model of p2 in other applications to read/write/translate repositories. It is basically EMF and p2 that is required. That is, if what you want is not already supported by doing a composite with non-mirrored maven repo as thomas suggests. (In reply to comment #3) > > Please note that the b3 aggregator will avoid copying artifacts when mapped > repositories are marked with mirroring = false. It will then just create a > composite artifact repository that references the incoming sources. Thank you, that sounds close to what I want, but to my understanding it would still need to crawl the whole repository every time something changes. Since this is meant as an archiva plugin, I actually do get an event every time an artifact is added, so I only need to process a few known files at a time and add those to the content.xml and artfiacts.xml. But I was curious how b3 the artifacts.xml produced by b3 would look like with 'mirroring=false' and gave it a try. Unfortunately it failed for our company repository as well as for all others I tried: http://download.java.net/maven/1/ http://download.java.net/maven/2/ http://google-maven-repository.googlecode.com/svn/repository/ http://repo1.maven.org/maven2 https://repository.jboss.org/nexus/content/repositories/ Except for maven central, it's always the same exception: java.lang.NullPointerException at org.eclipse.b3.p2.maven.loader.Maven2RepositoryLoader.getTransport(Maven2RepositoryLoader.java:709) at org.eclipse.b3.p2.maven.loader.Maven2RepositoryLoader.load(Maven2RepositoryLoader.java:866) at org.eclipse.b3.p2.maven.loader.Maven2RepositoryLoader.reload(Maven2RepositoryLoader.java:268) at org.eclipse.b3.aggregator.p2.util.MetadataRepositoryResourceImpl$RepositoryLoaderJob.run(MetadataRepositoryResourceImpl.java:476) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) PS: I was using eclipse 3.7 and a freshly installed b3 from the update site (In reply to comment #4) > I have used the aggregator's EMF model of p2 in other applications to > read/write/translate repositories. It is basically EMF and p2 that is required. > That is, if what you want is not already supported by doing a composite with > non-mirrored maven repo as thomas suggests. Thank you, I will have a look at the aggregators EMF model and hopefully replace my own model with the b3 one. Thankfully EMF's derrived features safe you at least from bothering with things like that redundant 'size' attribute in most multi-valued elements :-) Given that the b3 model is feature complete, how about exporting it to XSD and putting it in the wiki? Might save other people the hassle of reverse engineering... This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag. |
I am currently trying to create a 'virtual' p2 repository as a view on a maven repository. So far I managed to create a valid content.jar and artifacts.jar by processing bundle jars and features jars contained in the maven repository. On an unrelated note, this would have been a lot easier if I would have found some documentation or better yet an XSD for the XML structure. Is something like that available somewhere and I simply didn't find it? The goal is to only link to the files already available in the maven repository, not copy them to a new location, so I thought I could do that with the mapping rules. To be able to do that, I attached additional properties to each artifact: <artifact classifier="osgi.bundle" id="org.eclipse.equinox.p2.garbagecollector" version="1.0.200.v20110510"> <properties size="5"> <property name="artifact.size" value="24987"/> <property name="download.size" value="24987"/> <property name="maven.location" value="../org.eclipse/org.eclipse.equinox.p2.garbagecollector/1.0.200/org.eclipse.equinox.p2.garbagecollector_1.0.200.v20110510.jar"/> <property name="maven.groupId" value="org.eclipse"/> <property name="maven.artifactId" value="org.eclipse.equinox.p2.garbagecollector"/> </properties> </artifact> The property maven.location contains the relative path from ${repoUrl}. For the Mapping Rule I defined: <rule filter="(& (classifier=osgi.bundle))" output="${repoUrl}/${maven.location}"/> This does not work however. The property is simply ignored. After searching through the code I noticed that the mapper class only replaces well-known property values, namely: REPOURL,CLASSIFIER, ID, VERSION and FORMAT. Unless I am missing something, I guess the only way to solve my problem would be to create a specific mapping rule for each and every artifact? In my opinion it would be more flexible if generic properties of an artifact could also be used within the mapping rule. I would also be willing to work on a patch if this addition would be considered.