Hi
I disagree.
If OCL exposes org.eclipse.uml2.uml.Class in an API, it certainly is
tightly coupled to the existence of that class but to not a
particular version of Eclipse UML. The referenced
org.eclipse.uml2.uml.Class has been available in all versions of
Eclipse UML so provided OCL is built consistently it can run against
whichever Eclipse UML version is externally available. Hence Luna
Eclipse OCL is installable on Juno (Eclipse UML 4) and Luna (Eclipse
UML 5).
Regards
Ed Willink
On 22/01/2015 15:08, Christian W. Damus
wrote:
Hi, Ed,
Exposing another bundle’s types in the export API of your
bundle is tight coupling. That’s what re-export is for. If
OCL’s API is a superset of a UML API that has breaking
changes, then of course OCL’s API has breaking changes that
require a major version increment. Why wouldn’t it?
I agree that the bundle is not the right granularity for
versioning and re-exporting: we might employ “uses”
directives instead, but that would require that Papyrus employ
Package-Import instead of Require-Bundle.
In the end, I
don’t see how anybody could actually build a product that
extends Papyrus and expect ever to be able to update it
after it has been deployed. Not until we get our API and
dependencies story straight, which is actually a
requirement for 1.0 graduation that we didn’t meet.
Christian
On
Thursday, Jan 22, 2015 at 10:01, Ed Willink <ed@xxxxxxxxxxxxx>, wrote:
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
_______________________________________________
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
|