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