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

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



Back to the top