Community
Participate
Working Groups
Our MDT/OCL p2 repository generated from buckminster-based build distributes a third party bundle: lpg.runtime.java. Both lpg.runtime.java and lpg.runtime.java.source bundles are present in the target platform used by buckminster. However, only the binary bundle is included in the generated p2 repository. You may find more information in the buckminster forum: http://www.eclipse.org/forums/index.php?t=msg&th=201971&start=0&S=b19a799edb96ebdc69b900b74b0c5d91 I also provide more updated links regarding our build: Target Platform: https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.1-nightly/ws/buildroot/target.platform Generated P2 repo: https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.1-nightly/ws/MDT-OCL.p2.repository/ Regards, Adolfo.
The vanishing fix for Bug 320977 might be the same problem.
The problem was that source bundles that already existed were not fed to the source feature generator. It was only setup to deal with generated source features and source bundles. A fix for this was checked in to helios-maintenance branch, rev 11672. I did a local build of the mdt-ocl and verified that the lpg.runtime.java.source now is included.
Thomas, Thanks for facing on this. How could we have the new buckminster version available in Eclipse hudson servers?. Best Regards, Adolfo.
(In reply to comment #3) > > How could we have the new buckminster version available in Eclipse hudson > servers?. > Thomas, I would like to do some tests in Eclipse Servers prior to M6+1 next week. I'm not sure if I can help in somehow. Regards, Adolfo.
Thommas, I checked that hudson is now using the new version of buckminster, since the last successful build (https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.1-nightly/311/artifact/MDT-OCL.p2.repository/plugins/) now produces p2 repository with the lpg.runtime.java.source bundle. Furthermore, our org.eclipse.ocl.source feature also includes/refers to said source bundle. Thanks a lot !!!!! I also want to make you (any reader) know a side-effect I experimented in my build, just as a reference just in case somebody else experiments this issue. We needed to materialize the org.eclipse.uml2.uml.resource plugin (it's not a plugin distributed by our project MDT/OCL) in the buckminster's workspace since it was required to be there for one of our junit launch configuration (to launch some test cases). The new buckminter version didn't manage to materialize said plugin in the workspace, and the build failed. The error was that in our ocl.rmap file, the Search Path used to resolve said org.eclipse.uml2.uml.resource by the means of a CVS provider which set the "source" attribute to "false". Removing that attribute-value assignment (I understand the default = true), buckminster understands that it has to materialize the plugin into the workspace. The build started to work again... The point is that this behaviour has (intentional or unintentional) been changed. Best Regards, Adolfo.
(In reply to comment #5) > The point is that this behaviour has (intentional or unintentional) been > changed. > If source="false", the default behavior is to materialize to the target platform. It has been that way for some time now. What version of Buckminster did you use before?
Thomas, I'm simply using Eclipse Hudson UI (executing buckminster commands via Headless Buckminster 3.6), I don't know which version exactly corresponds to. Maybe we have have been using an old version since time ago. Actually I'm not sure how is the process to "update" the buckminster which is used by Eclipse hudson.... Have you done anything to make this happen ? Regards, Adolfo.
(In reply to comment #7) > Have you done anything to make this happen ? > No, but I think my college, Michal did. And it might well be that the previous one was quite old, so that would explain it.
(In reply to comment #2) > The problem was that source bundles that already existed were not fed to the > source feature generator. It was only setup to deal with generated source > features and source bundles. > > A fix for this was checked in to helios-maintenance branch, rev 11672. > > I did a local build of the mdt-ocl and verified that the > lpg.runtime.java.source now is included. I have a different scenario where I want to build a p2 site for features/plugins that are already installed in the target. Currently (with Indigo), buckminster seems to give priority to resolving the source features/plugins to the target instead of generating them from the features/plugins projects in the workspace. Is there a way to flip this priority around? That is, I want to make sure that if a feature F or a plugin P is built from the workspace into a P2 site, then F.source or P.source should always be generated from F or P respectively. I've tried to do this based on the p2 site example in the book without success: http://www.eclipse.org/forums/index.php/t/368675/ - Nicolas.
