Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Dependency re-export policy

Hi, Camille,

Thanks for the quick response.

The reason why the re-export became necessary is because the new API methods added the DependencyManagementHelper class added the EditingDomain type to that class’s API.  Previously, the EditingDomain was only used internally; it was not exposed to clients.

Re-export isn’t important for bundles that are singletons, but for non-singletons it is vital to ensuring that OSGi can provide a consistent classpath.  If plug-in A uses API from B that exposes types from C, then A must be wired to the same version of C as B is.  If C is not a singleton, then re-exports are required to ensure correct wiring.

Anyways, there is tooling that can help with managing all these dependencies:  the PDE API tooling.  And Oomph provides additional capabilities for stuff that PDE doesn’t cover.  I actually went through the exercise of configuring the API tooling builder on the Papyrus plug-in projects and it turned up hordes of problems that are worth fixing.  In any case, we needn’t re-export all dependencies.  Just those dependencies that contribute types to the API signatures that the plug-in exports.

And is it not disturbing that our build system evidently builds stuff so very differently than our developer workbenches … ?

cW


On Thursday, Jan 22, 2015 at 09:51, LETAVERNIER Camille <camille.letavernier@xxxxxx>, wrote:

Hi Christian,

 

 

The no-reexport policy has been initially enforced to help the Papyrus Refactoring in Juno. The dependencies at this time were a complete mess, and since some core plug-ins reexported everything (Including GEF, GMF, UML, ...), it was absolutely impossible to know which plug-in required what.

 

The dependency management is now a little bit more complicated, but at least we know when we depend on something we shouldn’t need.

 

In this case, the “indirect” dependency already existed (DependencyManagementHelper has always had EditingDomain in its signature). However, the OneFile plug-in only calls a single method from this class (3-args updateDependencies()), and none of the 3-args updateDependencies methods needed an EditingDomain. The latest commit introduced two new methods (3-args updateDependencies), with an EditingDomain as the last argument, which caused the error. So, interestingly, renaming the method fixes the error just as well as adding a dependency in infra.onefile. Buckminster and PDE failed on this issue, but not Maven/Tycho.

 

So, regarding the reexport policy: the API management is still chaotic, since we barely ever use the “internal” conventions; today everything is API. I doubt we simply want to reexport everything, and I suspect this would cause more harm than good. I don’t have a good solution for that.

 

 

Camille

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : jeudi 22 janvier 2015 15:34
À : Papyrus Project list
Objet : [mdt-papyrus.dev] Dependency re-export policy

 

Hi, team,

 

Once again, there is a compilation error in the master branch of this kind:

 

  The type org.eclipse.emf.edit.domain.EditingDomain cannot be resolved. It is indirectly referenced from required .class files

 

This is occurring because a class in the oep.infra.onefile plug-in calls an API (the DependencyManagementHelper) in the oep.infra.emf that has now added an indirect dependency on API from org.eclipse.emf.edit, which the oep.infra.onefile bundle does not import.  The dependent bundle has no changes but now fails to compile because of unrelated changes in its dependency.

 

This would not have been a problem if the oep.infra.emf bundle had re-exported the org.eclipse.emf.edit which contributes to the API signatures that it exports, itself.  That is the purpose of re-export.

 

So, I have some questions:

 

  • why do we have a policy against dependency re-exports? (we even have a JUnit test, currently disabled, that would enforce it)

  • can we revisit that policy?

  • why does this compilation error not break the nightly build?

 

Personally, I find it wrong that an error like this has to be fixed by updating the oep.infra.onefile bundle to add a new dependency because now the oep.infra.emf bundle has added types to its exported API that the former doesn’t even use.

 

Thanks,

 

Christian

 


Back to the top