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

It is VERY VERY undesirable to re-export dependencies, since any major version change mandates a downstream major version change. Re-export means very tightly coupled.

This has been a significant problem for OCL that has had three major version changes imposed on it by UML2, even though the Ecore functionality is unaffected. In the latest OCL major version change, the UML re-exports are retracted so that in future OCL may further expand its UML [4.0.0,6.0.0) dependency without further major version changes.

Certainly a re-export should not be introduced just for an irritating build failure. Just occasionally extra dependencies need to be added. That's why we have practice builds. Perhaps an equivalent JUnit might detect the missing indirect imports.

    Regards

        Ed Willink

On 22/01/2015 14:34, Christian W. Damus wrote:
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




_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5645 / Virus Database: 4260/8975 - Release Date: 01/22/15



Back to the top