Bugzilla – Full Text Bug Listing
| Summary: | [releng] OCL 3.1.0 M4 is missing lpg.runtime.java | ||
|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Anthony Hunter <ahunter.eclipse> |
| Component: | Core | Assignee: | Adolfo Sanchez-Barbudo Herrera <adolfosbh> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ed |
| Version: | 3.1.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Anthony Hunter
Hi Anthony, Unexpected, but you are right. Besides I've checked that it's also missed in the M3 zips... More info: - All-In-One Update Site contains the bundle (otherwise, indigo's runAggregator build would have failed since M3). - As I have been commented in the mdt/ocl dev list since time ago, the source bundle of lpg.runtime.java is not included. Neither in the All-In-One update site. - Strangely, the zips contain the proper features, but due to an unknown reason the Orbit's lpg.runtime.java bundle is not included I need to look into the bucky build to figure out why while including the correct features, the lpg.runtimejava plugin is not included in the zip files :\. I'll also try to definitely make the lpg.runtime.java sources be included in every zip. Cheers, Adolfo. The M4 zips on the download site can to be patched by getting the bundle from the OCL update site. I have patched an M4 that I can use for the modeling builds on modeling.eclipse.org for now. For 3.1 we should perhaps maintain the packaging, but is this really right? The MDT/OCL zip does not repackage EMF or UML2, so why does it repackage LPG which is in Orbit? If another project, perhaps IMP, also repackages, perhaps a different LPG version, and is used in conjunction with MDT/OCL, then there will be a conflict. Surely fetching from Orbit is the responsibility of a build/install system that uses MDT/OCL zips? MDT/OCL should only distribute its own contributions. Indigo is a major build migration to Buckminster. If Buckminster did it differently perhaps it did it better. Doing it the Buckminster way is a justification for a packaging change. Adolfo: I'm inclined to wait for further comments and perhaps cross-project-dev discussion before deciding to fix this. (In reply to comment #3) > Surely fetching from Orbit is the responsibility of a build/install system that > uses MDT/OCL zips? MDT/OCL should only distribute its own contributions. There is no orbit download, the bundles are distributed with the projects. That is why the lpg.runtime.java is listed in the org.eclipse.ocl feature. I don't understand your comment. Surely you have a build that does perhaps EMF+UML+OCL+EMFt, for which you reference a ZIP each. For convenience LPG saved you finding LPG. I'm suggesting that this is a poor packaging practice and that you should do EMF+UML+OCL+EMFt+LPG. For instance when using Xtext, we have to track down all the Xtenm, Xpand, Mwe, Mwe2 hidden dependencies. A good read : http://www.eclipse.org/orbit/overview.php (In reply to comment #6) > A good read : http://www.eclipse.org/orbit/overview.php This doesn't help me. It doesn't recommend that Orbit bundles should or should not be repackaged. It merely discusses availability. Looking for an example: In Xtext, Xtend, mwe, mwe2, I can find 3 identical versions of log4j, so I guess Orbit is ensuring that we can have identical versions. I'll email David Williams to see whether he'd like to add "The consistent Orbit names ensure that projects can package the Orbit bundles they use in their own ZIPs and avoid the conflicts that could otherwise arise from non-identical copies." to the second paragraph. Since some builds ago the lpg.runtime.java is included in the generated artifacts. The lpg.runtime.java.source bundle is also included in the zips, excepting the Update zip, in which I haven't been able to include it I've not closed this bug since I firstly wanted to also complete the correct packaging of the Update zip. However, my help request in dev-cross-project list and buckminster forums (http://www.eclipse.org/forums/index.php?t=msg&th=201971&start=0&S=823ed1040c0319f5bf27e3db26f783b9 ) have not received any response.... Anyway, instead of closing this and open a new one.... I'll leave the bug open for tracking until it's finally solved... Anthony the last I-build contains (and M5 will) your request, all right ? (In reply to comment #2) > The M4 zips on the download site can to be patched by getting the bundle from > the OCL update site. > > I have patched an M4 that I can use for the modeling builds on > modeling.eclipse.org for now. I'm not sure what you refer...did you mean your M4 zips ?, which kind of patch ? could you explain for my information ? Cheers, Adolfo. Our build on modeling.eclipse.org downloads its dependencies and does not download them again each build. So I have patched the downloaded mdt-ocl-SDK-3.1.0M4.zip by adding the missing lpg.runtime.java. After checking that the following bugzilla fix Bug 338803, we are finally distributing lpg.runtime.java.source bundle in the our P2 repository and the corresponding mdt.ocl-Update.zip. Resolving as fixed. Closing |