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 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