Bugzilla – Full Text Bug Listing
| Summary: | Resolving dependencies from Project Orbit | ||
|---|---|---|---|
| Product: | [Technology] Dash | Reporter: | Aaron Digulla <digulla> |
| Component: | Website | Assignee: | Project Dash Incoming bugs <dash-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | alex.blewitt, d_a_carver, jugalps, nicolas.werlein, pwebster |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 394792 | ||
|
Description
Aaron Digulla
As I see it, we have three options: 1. Keep the dependencies as is. 2. Replace Orbit dependencies with Maven Central dependencies 3. Allow users to switch dependencies with a profile Comments: Option #1 is the most simple to implement - that's how it works today. The main reason to change it is that consumers of the bundles probably need them in the context of a larger project. As soon as they mix our artifacts with ones from Maven Central, there will be trouble: Dependencies will appear twice in the classpath. That means this solution forces consumers to be aware of this issue and they need to sprinkle their POMs with exclusions. Option #2 means that we need to patch the POM files when they are created with the Dash m4e Tools. That's some work. Writing the tool itself isn't that complicated but someone has to maintain the mapping. There will always be a gap between the the mapping file and what Orbit publishes. This isn't necessarily a problem - the mapping file could be part of the tool download so users can add new entries as necessary. My concern is mistakes: How do we fix wrong mappings? But that should probably be the topic of another bug. Another question is IP: Is it OK from a legal point of view to replace one download with another? As I understand, packages from Orbit are IP cleaned (http://www.eclipse.org/orbit/overview.php). Does that option #2 is "illegal"? Option #3 would take most work but would give consumers most freedom. With a Maven profile, they could chose which dependency to use (Orbit or Maven Central). Unless ... the dependency is not from Maven Central. How should I handle that? 2 things to keep in mind: 1) a very small number of the Orbit bundles are subsets that we were able to get IP approval for (where we could not that library if we used the normally provided jar for that project) 2) most of the Orbit jars had to be converted into bundles ... a lot of the projects don't generate OSGi manifests. PW (In reply to comment #2) > 2 things to keep in mind: > > 1) a very small number of the Orbit bundles are subsets that we were able to > get IP approval for (where we could not that library if we used the normally > provided jar for that project) "where we could not that"? I assume you mean "could not *use*": That is what I thought. What does it mean when you could get IP approval? Does that allow you to use the bundle in any Eclipse project without further examination by the lawyers? How can I see whether a bundle has IP approval? What about the other bundles? What does it mean when I mix Eclipse bundles and the ones from Maven Central? Is that an issue for Project Dash or just for the user who types "mvn compile" and hits ENTER (or rather the result of such a build)? Note: The goal of my project is to make it easier to use Eclipse bundles *outside* the Eclipse workspace. So if the resulting files can't be used safely in Eclipse projects, I couldn't care less: In Eclipse projects, you can use PDE and plug-in dependencies, the automatic plug-in classpath. > 2) most of the Orbit jars had to be converted into bundles ... a lot of the > projects don't generate OSGi manifests. Since Maven projects don't need OSGi manifests, this should not be an issue. (In reply to comment #3) > I assume you mean "could not *use*": That is what I thought. Yes, sorry. > What does it mean > when you could get IP approval? Does that allow you to use the bundle in any > Eclipse project without further examination by the lawyers? AFAIK our IP approval is for specific projects. But once approved, it's easy to get it approved for another project (piggyback). > > How can I see whether a bundle has IP approval? All of our Orbit bundles should be approved. On any one of the Orbit release pages there should be a CQ link that captures EF approval. > > > 2) most of the Orbit jars had to be converted into bundles ... a lot of the > > projects don't generate OSGi manifests. > > Since Maven projects don't need OSGi manifests, this should not be an issue. Sorry, I thought we were talking about eclipse projects that are plugins? If they don't have access to an OSGi bundle from somewhere (we stash them in orbit now) won't that plugin be un-deployable? Or is this considering only eclipse projects that run as normal java projects outside of OSGi? PW (In reply to comment #4) > > How can I see whether a bundle has IP approval? > All of our Orbit bundles should be approved. On any one of the Orbit release > pages there should be a CQ link that captures EF approval. Now, I'm confused. First you said "a very small number of the Orbit bundles are subsets that we were able to get IP approval" and now, you say "All of our Orbit bundles". Does this mean: All projects are approved. There were projects where it was impossible to get approval for the whole project, but you were able to isolate some classes of the project and you could get IP approval for these classes? > > > 2) most of the Orbit jars had to be converted into bundles ... a lot of the > > > projects don't generate OSGi manifests. > > > > Since Maven projects don't need OSGi manifests, this should not be an issue. > > Sorry, I thought we were talking about eclipse projects that are plugins? If > they don't have access to an OSGi bundle from somewhere (we stash them in orbit > now) won't that plugin be un-deployable? > > Or is this considering only eclipse projects that run as normal java projects > outside of OSGi? I'm working on a fix for Bug 283745 - Provide Maven repositories of stuff built at Eclipse Maven is a dependency management system like Ivy or OSGi+p2. My problem right now: Many of the Orbit bundles are copies of external (non-Eclipse) projects. Say you use Hibernate in your project. And you want to use GEF. Both load a logging framework but Hibernate loads commons-logging while GEF wants org.apache.commons-logging. Which leads to the problem above and the three options I described in comment #1. (In reply to comment #5) > Does this mean: All projects are approved. There were projects where it was > impossible to get approval for the whole project, but you were able to isolate > some classes of the project and you could get IP approval for these classes? Sorry once again :-) We have to get approval to add anything in Orbit. Most projects get reviewed and simply get OSGi MANIFESTS added. For a few libs that contain source that we couldn't approve, we took a subset of their source that we could get approval for, and added that to Orbit. > > I'm working on a fix for Bug 283745 - Provide Maven repositories of stuff built > at Eclipse > > Maven is a dependency management system like Ivy or OSGi+p2. > > My problem right now: Many of the Orbit bundles are copies of external > (non-Eclipse) projects. Say you use Hibernate in your project. And you want to > use GEF. Both load a logging framework but Hibernate loads commons-logging > while GEF wants org.apache.commons-logging. The difference between them would be that GEF depends on a version of commons-logging with an OSGi MANIFEST. AFAIK that's the Orbit version, not the maven central one. But maybe one of Alex or Dave could chime in (my distinction is important for running GEF but might not be important for this part of your project). PW Aaron, some projects don't get all the dependencies that third party project uses approved. An example would be anything that has an optional depdency on say Saxon. XMLBeans is an example of this, only a subset of the project is approved (those pieces that don't depend on Saxon). So in this case, we need to take the orbit binary jars, and create POMs for them. I would put these dependencies under a org.eclipse.orbit group id, and then the artifact id as normal. IP is a fun thing at eclipse, it causes us all sorts of headaches as developers, but it makes adopters happier. Dave, please see Bug #371475 regarding your suggestion to change the Maven artifact's 'groupId'. (In reply to comment #7) > So in this case, we need to take the orbit binary jars, and create POMs for > them. I would put these dependencies under a org.eclipse.orbit group id, > and then the artifact id as normal. As I explained in Bug #371475 and the FAQ, just changing the group ID isn't enought because Maven uses only the artifact ID to create the JAR filename. Without prefixing the artifact ID with "orbit.", there is a (small) chance that you might end up with a (non-OSGi) classpath that contains two JARs with the same name. This will cause problems when you build non-OSGi web applications with Maven, for example. I understand that such thoughts are of no concern in the Eclipse world but maven.eclipse.org supplied Maven artifacts and they are rarely used in OSGi environments. Note that SpringSource has created a maven-like repository for their EBR, and uses an 'com.springsource' prefix for their bundles. http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.slf4j.api&version=1.6.1 <dependency> <groupId>org.slf4j</groupId> <artifactId>com.springsource.slf4j.api</artifactId> <version>1.6.1</version> </dependency> They rename the artifact as well as the group when they repackage it. They also adjust the bundle's symbolic name. The artifact has a com.springsoruce.slf4j.api name, and the bundle symbolic name is com.springsource.slf4j.api I would argue their only mistake is to use a group id of org.slf4j, instead of com.springsource.ebr or something under that pattern. (Well, that and their over-reliance of the require-bundle but that's a different story ...) So I'd suggest something like: <dependency> <groupId>org.eclipse.orbit</groupId> <artifactId>org.eclipse.orbit.slf4j.api</artifactId> <version>1.6.1</version> </dependency> This has the advantage that all the bundles will be under an org/eclipse/orbit/ namespace in the Eclipse maven repository, and there will be a clear notation that the artifact comes from Eclipse instead of the upstream SLF4J API. As a side note, when Orbit started there was a requirement that the bundles be repackaged. However, many of the upstream components now natively support OSGi, including SLF4J. It is really necessary to wrap all bundles in an Orbit namespace if they are unmodified? The orbit repository could easily store the SLF4J bundle in an unmodified state in its original co-ordinates. <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.6.1</version> </dependency> Harmonising on just one bundle without modification would be an ideal goal, but if we need to modify it, then put it under the org.eclipse.orbit.* namespace to disambiguate. At least that way, if other consumers wish to ignore the org.eclipse.orbit dependencies they can do so. (In reply to comment #10) > As a side note, when Orbit started there was a requirement that the bundles > be repackaged. However, many of the upstream components now natively support > OSGi, including SLF4J. It is really necessary to wrap all bundles in an > Orbit namespace if they are unmodified? The orbit repository could easily > store the SLF4J bundle in an unmodified state in its original co-ordinates. My converter can handle this but I need a simple & reliable way to tell whether Orbit has tampered with the bundle *in any way*. If Orbit changes a single bit of the original archive, it *must* be moved. This includes transparent changes like signing the bundle because Java doesn't allow to add additional classes to signed packages, so this can break existing code. |