Community
Participate
Working Groups
Installing Xtext M7 from the Update Site gives both com.google.collect 1.0.0 from Orbit com.google.collect 0.8.0 from somewhere Various Xtext manifests have bounds [0.8.0,1.0.0) thereby excluding the Orbit version. Orbit does not provide a 0.8.0. This may be preventing an MDT/OCL build using latest repositories since Hudson expects things to be pedantically right without transitive resolution.
Clarification: M7 Xtext Update would not install until I extracted orbit-S20100423142122.zip to dropins. The double com.google.collect then appeared in the Installed Plugins list. My precise actions were. Until M7 Win32 Pltaform. Install all of EMF-XSD M7 except RAP from downloaded Update. Restart. Install all of UML2 M7 from downloaded Update. Restart. Install all of MWE M7 from downloaded Update. Restart. Install some of Xpand M6 (no M7 available) from downloaded Update. Restart. Attempt to install all of Xtext M7 from downloaded Update.
(In reply to comment #1) > Clarification: > > M7 Xtext Update would not install until I extracted orbit-S20100423142122.zip > to dropins. The double com.google.collect then appeared in the Installed > Plugins list. Install xtext M7 using the update site http://download.eclipse.org/modeling/tmf/updates/milestones/ All dependencies will be installed automatically. Regards, Dennis.
Using the anonymous http://download.eclipse.org/modeling/tmf/updates/milestones/ is fine interactively, but a Hudson build should refer to an explicit release such as http://download.eclipse.org/modeling/tmf/xtext/downloads/drops/1.0.0/S201005041135/tmf-xtext-Update-1.0.0M7.zip. Sebastian pointed me at a build to copy so that I was able to get the MDT/OCL build working. That was great fopr perhaps a week. But the build suddenly failed last night, and still fails after unrolling all CVS changes. Somehow M7 xpand appears despite an M6 build.properties reference (Bug 311658). Trying to understand the opaque Hudson diagnostics wa fruitless so I tried the interactive install to se if it shed any light on the appearent failure to resolve com.google.inject. The mismatching version bounds appeared. I think an adequate workaround for me would be to know the exact identity of some update site that provides the variant of com.google.* that actually works for p2. Hopefully RC1 will have consistent version numbers throught itemis and orbit.
(In reply to comment #2) > Install xtext M7 using the update site > http://download.eclipse.org/modeling/tmf/updates/milestones/ > All dependencies will be installed automatically. This does not work. I unzipped M7 WIN32 platform. Did Install New Software for the above in an empty workspace. I get: Cannot complete the install because one or more required items could not be found. Software being installed: Xtext SDK 1.0.0.v201005041135 (org.eclipse.xtext.sdk.feature.group 1.0.0.v201005041135) Missing requirement: Xtext Common Types 1.0.0.v201005041135 (org.eclipse.xtext.common.types 1.0.0.v201005041135) requires 'bundle com.google.inject 2.0.0' but it could not be found Cannot satisfy dependency: From: Xtext Runtime 1.0.0.v201005041135 (org.eclipse.xtext.runtime.feature.group 1.0.0.v201005041135) To: org.eclipse.xtext.common.types [1.0.0.v201005041135] Cannot satisfy dependency: From: Xtext SDK 1.0.0.v201005041135 (org.eclipse.xtext.sdk.feature.group 1.0.0.v201005041135) To: org.eclipse.xtext.runtime.feature.group [1.0.0.v201005041135] ---- This is much the same useless message as Hudson gives. When it says com.google.inject 2.0.0 cannot be found, it means that some transitive dependency of com.google.inject 2.0.0 failed and so com.google.inject 2.0.0 is disabled and as an explicitly mentioned requirement, it com.google.inject that gets diagnosed. So I strongly suspect that it's the [0.8.0,1.0.0) bound on com.google.collect that is the problem. ---- Actually the Hudson message is slightly better. Now that Xpand M7 is available, I'm able to do a 100% M7 build and get: [p2.dir] Installing org.eclipse.emf.feature.group 2.6.0.v20100503-1751. [p2.dir] Installing org.eclipse.xsd.feature.group 2.6.0.v20100429-1251. [p2.dir] Installing org.eclipse.uml2.feature.group 3.1.0.v201005031530. [p2.dir] Installing org.eclipse.xpand.feature.group 1.0.0.v201005041053. [p2.dir] Installing org.eclipse.xtend.feature.group 1.0.0.v201005041053. [p2.dir] Installing org.eclipse.xtext.runtime.feature.group 1.0.0.v201005041135. [p2.dir] Installing org.eclipse.xtext.ui.feature.group 1.0.0.v201005041135. [p2.dir] Installation failed. [p2.dir] [p2.dir] Cannot complete the install because one or more required items could not be found. [p2.dir] !ENTRY org.eclipse.equinox.p2.director 4 1 2010-05-05 11:54:40.987 [p2.dir] Software being installed: Xtext UI 1.0.0.v201005041135 (org.eclipse.xtext.ui.feature.group 1.0.0.v201005041135) [p2.dir] !MESSAGE Cannot complete the install because one or more required items could not be found. [p2.dir] !SUBENTRY 1 org.eclipse.equinox.p2.director 4 0 2010-05-05 11:54:40.987 [p2.dir] Missing requirement: Xtext Utility 1.0.0.v201005041135 (org.eclipse.xtext.util 1.0.0.v201005041135) requires 'bundle com.google.collect [0.8.0,1.0.0)' but it could not be found [p2.dir] !MESSAGE Software being installed: Xtext UI 1.0.0.v201005041135 (org.eclipse.xtext.ui.feature.group 1.0.0.v201005041135) [p2.dir] Cannot satisfy dependency: [p2.dir] !SUBENTRY 1 org.eclipse.equinox.p2.director 4 0 2010-05-05 11:54:40.987 [p2.dir] From: Xtext UI Core 1.0.0.v201005041135 (org.eclipse.xtext.ui 1.0.0.v201005041135) [p2.dir] !MESSAGE Missing requirement: Xtext Utility 1.0.0.v201005041135 (org.eclipse.xtext.util 1.0.0.v201005041135) requires 'bundle com.google.collect [0.8.0,1.0.0)' but it could not be found [p2.dir] To: bundle org.eclipse.xtext.util 0.0.0 [p2.dir] Cannot satisfy dependency: [p2.dir] !SUBENTRY 1 org.eclipse.equinox.p2.director 4 1 2010-05-05 11:54:40.988 [p2.dir] !MESSAGE Cannot satisfy dependency: [p2.dir] From: Xtext UI 1.0.0.v201005041135 (org.eclipse.xtext.ui.feature.group 1.0.0.v201005041135) [p2.dir] !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2010-05-05 11:54:40.988 [p2.dir] To: org.eclipse.xtext.xtext.ui [1.0.0.v201005041135] [p2.dir] !MESSAGE From: Xtext UI Core 1.0.0.v201005041135 (org.eclipse.xtext.ui 1.0.0.v201005041135) [p2.dir] Cannot satisfy dependency: [p2.dir] !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2010-05-05 11:54:40.988 [p2.dir] !MESSAGE To: bundle org.eclipse.xtext.util 0.0.0 [p2.dir] From: Xtext Xtext UI 1.0.0.v201005041135 (org.eclipse.xtext.xtext.ui 1.0.0.v201005041135) [p2.dir] To: bundle org.eclipse.xtext.ui 1.0.0 [p2.dir] !SUBENTRY 1 org.eclipse.equinox.p2.director 4 1 2010-05-05 11:54:40.988 [p2.dir] !MESSAGE Cannot satisfy dependency: [p2.dir] Application failed, log file location: /opt/users/hudsonbuild/.hudson/jobs/cbi-mdt-ocl-3.0/workspace/build/N201005051153/eclipse/configuration/1273074866346.log [p2.dir] !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2010-05-05 11:54:40.989 [p2.dir] !MESSAGE From: Xtext UI 1.0.0.v201005041135 (org.eclipse.xtext.ui.feature.group 1.0.0.v201005041135) [p2.dir] !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2010-05-05 11:54:40.989 [p2.dir] !MESSAGE To: org.eclipse.xtext.xtext.ui [1.0.0.v201005041135] [p2.dir] !SUBENTRY 1 org.eclipse.equinox.p2.director 4 1 2010-05-05 11:54:40.989 [p2.dir] !MESSAGE Cannot satisfy dependency: [p2.dir] !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2010-05-05 11:54:40.989 [p2.dir] !MESSAGE From: Xtext Xtext UI 1.0.0.v201005041135 (org.eclipse.xtext.xtext.ui 1.0.0.v201005041135) [p2.dir] !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2010-05-05 11:54:40.989 [p2.dir] !MESSAGE To: bundle org.eclipse.xtext.ui 1.0.0 [for] org.eclipse.emf+org.eclipse.xsd+org.eclipse.uml2+org.eclipse.xpand+org.eclipse.xtend+org.eclipse.xtext.runtime+org.eclipse.xtext.ui: The following error occurred while executing this line: [for] /opt/users/hudsonbuild/.hudson/jobs/cbi-mdt-ocl-3.0/workspace/build/org.eclipse.dash.common.releng/builder/all/customTargets.xml:257: The following error occurred while executing this line: [for] /opt/users/hudsonbuild/.hudson/jobs/cbi-mdt-ocl-3.0/workspace/build/org.eclipse.dash.common.releng/tools/scripts/buildAllHelper.xml:1569: Java returned: 13 [for] featureIDsToInstall: The following error occurred while executing this line: [for] /opt/users/hudsonbuild/.hudson/jobs/cbi-mdt-ocl-3.0/workspace/build/org.eclipse.dash.common.releng/builder/all/customTargets.xml:230: Keepgoing execution: 1 of 1 iterations failed.
It's org.aopalliance which is missing in the feature. We'll bundle that one in the future. The problem is, that it is actually not missing in the feature as the guice.jar contains an inlined version of org.aopalliance. A workaround is to bundle org.aopalliance even if it is not required. In the mid-term we should update the Manifest of google.inject. Sorry for any inconvenience.
aopalliance seems plausible, though I am worried about the [0.8.0,1.0.0)s too. It would be really helpful if you could spin an M7a (or a strange name) just to provide something that my Hudson build can reference within repositoryURLs=\ http://download.eclipse.org/modeling/tmf/xtext/downloads/drops/1.0.0/S201005041135/tmf-xtext-Update-1.0.0M7.zip,\ http://download.eclipse.org/modeling/m2t/xpand/downloads/drops/1.0.0/S201005041053/m2t-xpand-Update-1.0.0M7.zip,\ http://download.eclipse.org/modeling/emft/mwe/downloads/drops/1.0.0/S201005040954/emft-mwe-Update-1.0.0M7.zip,\ http://download.eclipse.org/modeling/mdt/uml2/downloads/drops/3.1.0/S201005031632/mdt-uml2-Update-3.1.0M7.zip, \ http://download.eclipse.org/modeling/emf/emf/downloads/drops/2.6.0/S201005031457/emf-xsd-Update-2.6.0M7.zip featureIDsToInstall=org.eclipse.emf+org.eclipse.xsd+org.eclipse.uml2+org.eclipse.xpand+org.eclipse.xtend+org.eclipse.xtext.runtime+org.eclipse.xtext.ui so that we can resolve this before the shortening RC timescales are upon us. Actually since Xtext M7 is not installable by the direct route, perhaps you need an M7a anyway.
I think we have two or three different problems here. 1) In order to follow the instructions of comment #2 I must drop in _all_ of: org.aopalliance 1.0.0 com.google.collect 1.0.0 com.google.inject 2.0.0 from the Orbit bundle. You need to bundle all three of these in Xtext. 2) After installing as above with com.google.collect 1.0.0 as a dropin, the result of the update is that I also have a com.google.collect 0.8.0 as a non-dropin. So something is providing com.google.collect 0.8.0 to satisfy the [0.8.0,1.0.0) mismatch. 3) My Hudson build has Orbit as a (? potential) dropin, but because nothing is avilable to resolve the [0.8.0,1.0.0) mismatch, it can't resolve com.google.collect and so doesn't resolve any of the above. [You also have a few license texts to replace in MWE, XPAND and XTEND].
Hi Ed, I just installed Xtext successfully into a fresh Eclipse 3.6M7 from http://download.itemis.com/updates/milestones so I guess that an M7a is not necessary. Btw: This is how we successfully built MWE2 against Xtext M7: dependencyURLs=${eclipse-platform},\ ${downloadMirror}/modeling/emf/emf/downloads/drops/2.5.0/R200906151043/emf-xsd-SDK-2.5.0.zip,\ ${hudsonJobsPath}/cbi-tmf-xtext-0.7-integration/lastSuccessfulBuild/artifact/snapshot/tmf-xtext-SDK-S-Snapshot.zip,\ ${hudsonJobsPath}/cbi-emft-mwe2-runtime/lastSuccessfulBuild/artifact/snapshot/emft-mwe2-SDK-S-Snapshot.zip repositoryURLs=http://download.eclipse.org/tools/orbit/downloads/drops/S20100423142122/updateSite pluginIDsToInstall=org.apache.commons.cli+org.apache.commons.lang+org.apache.commons.logging+com.google.inject see org.eclipse.emf.mwe.releng/build-mwe2lang.properties Regards, Sebastian
Hi guys, I'm having same issue this time effecting building, so moving from the dash-dev to here. Below is what I get, and yes it looks like AOP is proximal issue. I'm using: http://download.eclipse.org/tools/orbit/downloads/drops/S20100120144102 Should I use a newer one? Sebastian, I really don't want to be dependent on snapshot build, I'd rather use M but if that is what works that is what I'll use for now. Can you recommend an M7 based configuration that should work? thanks, Miles This is a good representative build: https://build.eclipse.org/hudson/job/cbi-amp-nightly/408/ [p2.dir] !ENTRY org.eclipse.equinox.p2.director 4 1 2010-05-04 15:20:15.748 [p2.dir] !MESSAGE Cannot complete the install because one or more required items could not be found. [p2.dir] !SUBENTRY 1 org.eclipse.equinox.p2.director 4 0 2010-05-04 15:20:15.748 [p2.dir] !MESSAGE Software being installed: Xtext Runtime 1.0.0.v201005041135 (org.eclipse.xtext.runtime.feature.group 1.0.0.v201005041135) [p2.dir] !SUBENTRY 1 org.eclipse.equinox.p2.director 4 0 2010-05-04 15:20:15.748 [p2.dir] !MESSAGE Missing requirement: Google Guice 2.0.0.v201003051000 (com.google.inject 2.0.0.v201003051000) requires 'package org.aopalliance.aop 1.0.0' but it could not be found [p2.dir] !SUBENTRY 1 org.eclipse.equinox.p2.director 4 1 2010-05-04 15:20:15.749 [p2.dir] !MESSAGE Cannot satisfy dependency: [p2.dir] !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2010-05-04 15:20:15.749 [p2.dir] !MESSAGE From: Xtext Runtime 1.0.0.v201005041135 (org.eclipse.xtext.runtime.feature.group 1.0.0.v201005041135) [p2.dir] !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2010-05-04 15:20:15.749 [p2.dir] !MESSAGE To: org.eclipse.xtext.util [1.0.0.v201005041135] [p2.dir] !SUBENTRY 1 org.eclipse.equinox.p2.director 4 1 2010-05-04 15:20:15.749 [p2.dir] !MESSAGE Cannot satisfy dependency: [p2.dir] !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2010-05-04 15:20:15.750 [p2.dir] !MESSAGE From: Xtext Utility 1.0.0.v201005041135 (org.eclipse.xtext.util 1.0.0.v201005041135) [p2.dir] !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2010-05-04 15:20:15.750 [p2.dir] !MESSAGE To: bundle com.google.inject 2.0.0 [p2.dir] Cannot complete the install because one or more required items could not be found. [p2.dir] Software being installed: Xtext Runtime 1.0.0.v201005041135 (org.eclipse.xtext.runtime.feature.group 1.0.0.v201005041135) [p2.dir] Missing requirement: Google Guice 2.0.0.v201003051000 (com.google.inject 2.0.0.v201003051000) requires 'package org.aopalliance.aop 1.0.0' but it could not be found [p2.dir] Cannot satisfy dependency: [p2.dir] From: Xtext Runtime 1.0.0.v201005041135 (org.eclipse.xtext.runtime.feature.group 1.0.0.v201005041135) [p2.dir] To: org.eclipse.xtext.util [1.0.0.v201005041135] [p2.dir] Cannot satisfy dependency: [p2.dir] From: Xtext Utility 1.0.0.v201005041135 (org.eclipse.xtext.util 1.0.0.v201005041135) [p2.dir] To: bundle com.google.inject 2.0.0
Note that I am using a features based install, not plugin based. This works very well and of course I'm reluctant to change it..:) featureIDsToInstall=org.eclipse.emf+org.eclipse.xsd+org.eclipse.gef+org.eclipse.zest+org.eclipse.xpand+org.eclipse.xtend+org.eclipse.xtext.runtime+org.eclipse.xtext.ui
Miles: please clarify your comment. MDT/OCL does exactly the same, so I'm not sure what your point is. --- The com.google.collect 0.8.0 qualifier matches mwe2 runtime, which also provides a com.google.guice. The download pages for MWE show threee rival 1.0.0M7 promotions only one with an Update Site that doesn't match what the Xtext install finds. The MWE Update does not include mwe2 runtime, and the MWE2 runtime Update contains only notice files.!
(In reply to comment #11) > Miles: please clarify your comment. MDT/OCL does exactly the same, so I'm not > sure what your point is. My point is in response to Sebastian's comment re: the MWE2 build. Neglected to quote.
We rely on (at least) this version of the orbit repositoryURLs=http://download.eclipse.org/tools/orbit/downloads/drops/S20100423142122/updateSite pluginIDsToInstall=org.apache.commons.cli+org.apache.commons.lang+org.apache.commons.logging+com.google.inject As the orbit zip contains binary dependency cylces, we list the required plugins explicitly.
(In reply to comment #9) > > Sebastian, I really don't want to be dependent on snapshot build, I'd rather > use M but if that is what works that is what I'll use for now. Can you > recommend an M7 based configuration that should work? > > thanks, > > Miles Yes, you should use a newer version of the orbit. The snapshot builds that I listed in a previous comment are actually the ones that have been promoted so it should work if you use the right version from the orbit. Please keep in mind that it is important to not consume com.google.collect from the orbit zip as it will confuse everything (as Ed already pointed out).
(In reply to comment #14) > (In reply to comment #9) > Yes, you should use a newer version of the orbit. The snapshot builds that I > listed in a previous comment are actually the ones that have been promoted so > it should work if you use the right version from the orbit. Please keep in mind > that it is important to not consume com.google.collect from the orbit zip as it > will confuse everything (as Ed already pointed out). OK, its still broken with S20100423142122. https://build.eclipse.org/hudson/job/cbi-amp-nightly/414/console I don't have any dependencies on com.google.collect -- they're all in XText. So how can I prevent consuming com.google.collect while still using Orbit? Are you saying that I need to explicitly setup the Xtext plugin dependencies? As an aside, I wonder if for Dash builds it wouldn't make sense not to blow away the prior M builds (I think it is the default behavior to replace) as that would give consumers the option of determining when to tackle a change in the integration point.
(In reply to comment #15) > I don't have any dependencies on com.google.collect -- they're all in XText. So > how can I prevent consuming com.google.collect while still using Orbit? Are you > saying that I need to explicitly setup the Xtext plugin dependencies? > No, I said that you should handle the orbit plugins that you want to consume explicitly: repositoryURLs=http://download.eclipse.org/tools/orbit/downloads/drops/S20100423142122/updateSite pluginIDsToInstall=org.apache.commons.cli+org.apache.commons.lang+org.apache.commons.logging+com.google.inject Isn't that possible while still using featureIDsToInstall for xtext, xpand and the like?
(In reply to comment #8) > I just installed Xtext successfully into a fresh Eclipse 3.6M7 from > http://download.itemis.com/updates/milestones so I guess that an M7a is not > necessary. This is not what Dennis recommended in comment #2, which led me to believe that Xtext was now shipping an Eclipse-only build. What is the point in providing an Xtext M7 on Eclipse if it cannot be used? It just slows the rest of us down trying to make it work. Clearly you are doing something good at itemis that needs to be provided on the Eclipse Update site too. Can you explain why the com.google.collect in Orbit is bad? Can you explain why there is the [0.8.0,1.0.0) anomally please?
Hi Ed, (In reply to comment #17) > (In reply to comment #8) > > I just installed Xtext successfully into a fresh Eclipse 3.6M7 from > > http://download.itemis.com/updates/milestones so I guess that an M7a is not > > necessary. > > This is not what Dennis recommended in comment #2, which led me to believe that > Xtext was now shipping an Eclipse-only build. What is the point in providing an > Xtext M7 on Eclipse if it cannot be used? It just slows the rest of us down > trying to make it work. Clearly you are doing something good at itemis that > needs to be provided on the Eclipse Update site too. > sorry, I did not want to confuse you. The milestone update site at download.itemis.com is a composite update site that points to the right milestone update sites of xtext, xpand and mwe at download.eclipse.org > Can you explain why the com.google.collect in Orbit is bad? com.google.collect in the orbit is not bad but it's just the 1.0 version which is not compatible to 0.8. However, Xtext relies on 0.8 as we currently use APIs that are no longer available in 1.0. That's where the version constraint in the mainfests comes from. > > Can you explain why there is the [0.8.0,1.0.0) anomally please? This was the first idea to solve some build problems that we had on fridays after using the latest stable orbit release. Unfortunately it was not possible to convince the build infrastructure to use 0.8 when an 1.0 is available in the dropins. That's why we had to migrate to a selection of plugins that we consume from the orbit. com.google.collect 0.8 is part of mwe. Hope that clarifies a bit.
Thanks that makes things a bit clearer. Will you be fixing the APIs before RC1? Yes. Installing from the itemis download is a breeze. And the installing feature hierarchy may give me the clues as to what extra needs to go in the Hudson build.properties. No. Using the pluginIDsToInstall doesn't work because the features are installed unsuccessfully, then the plugins are installed successfully, and then the build fails because of the feature installation problem. [And all the licenses are correct, so clearly what comes from the Eclipse Update Site is not the same as comes from the itemis site.]
(In reply to comment #19) > Yes. Installing from the itemis download is a breeze. And the installing > feature hierarchy may give me the clues as to what extra needs to go in the > Hudson build.properties. > > No. Using the pluginIDsToInstall doesn't work because the features are > installed unsuccessfully, then the plugins are installed successfully, and then > the build fails because of the feature installation problem. Yes, exactly. I can install from Itemis update site, but I cannot *consume* it for XText build. Which is what I need. :( https://build.eclipse.org/hudson/job/cbi-amp-nightly/415/changes Needless to say, we should be able to consume the build without making these kinds of changes. Sebastian, would it be possible to put M6 zipped update site back up there until this issue gets resolved? My builds are stuck w/o it. Or I guess I could find the M6 build somewhere and put it up as a dependency URL. BTW, this issue with multiple versions is not unique to XText. It comes up all of the time in builds and installs. This is why I guess that Orbit recommends using Import-Package for common things like org.apache.lang. The problem with that is that if *no* plugins happen to actually have Require-Bundle then you don't get it installed into the build at all. :( The whole thing is fundamentally broken, IMHO. If the build system (and I mean PDE build not just Athena) can't handle dependencies on different versions, then what the hell is the point of allowing them to be specified?! Even the Runtime launcher can't handle that case well. Rant off..
Oops, hang on I have a mispelling :# there so it is still possible it will work. I'll update soon.
OK, Joy. It appears that you *can* in fact mix plugin and features and that the plugins will override the feature ids. Big kudos to Nick for apparently anticipating everything. This is what works for me. (Or at least seems to -- I've got some issues with xtext build as my local machine is still on M6 but they look pretty simple.) pluginIDsToInstall=org.apache.commons.cli+org.apache.commons.lang+org.apache.commons.logging+com.google.inject featureIDsToInstall=org.eclipse.emf+org.eclipse.xsd+org.eclipse.gef+org.eclipse.zest+org.eclipse.xpand+org.eclipse.xtend+org.eclipse.xtext.runtime+org.eclipse.xtext.ui
Hi Miles, this sounds great. We are sorry for any inconvenience that we caused by the recent changes in our required dependencies. Ed, could you please confirm whether this setup works for you on the Athena server? I'ld like to close this bug afterwards.
(In reply to comment #23) > Ed, could you please confirm whether this setup works for you on the Athena > server? I'ld like to close this bug afterwards. Miles's lines are almost identical to what I tried, in both plugin then feature and in feature then plugin order withiout success. AMP has not moved on to Xpand M7 or MWE 1.0.0M7, which probably explains the difference.
(In reply to comment #24) > (In reply to comment #23) > > Ed, could you please confirm whether this setup works for you on the Athena > > server? I'ld like to close this bug afterwards. > > Miles's lines are almost identical to what I tried, in both plugin then feature > and in feature then plugin order withiout success. > > AMP has not moved on to Xpand M7 or MWE 1.0.0M7, which probably explains the > difference. Yeah, that's right -- I didn't think they were even available yet as they didn't show up on the downloads page when I checked a couple of days ago.
(In reply to comment #8) > I just installed Xtext successfully into a fresh Eclipse 3.6M7 from > http://download.itemis.com/updates/milestones so I guess that an M7a is not > necessary. BTW, it usually (and in this case did) works to uninstall the old version and then reinstall it the new one. Saves having to put together a new Eclipse.
I backed up to emulate AMP. No luck. Very odd. AMP has an NPE just before its feature install succeeds. AMP #416 requested Xpand M6, but uses M7. ? Bug 311658 ? OCL #210 requests Xpand M6 and indeed uses M6 .... Good night. May be tomorrow will be a better day.
OK, my build is completely working. And, yes there is of course still some weirdness here. Because of changes in bug 311787, to get XText M7 to build I need to regenerate, but to do *that* I need MWE2 / XPand M7, or I get the error below. So I need to use MWE2 M7 locally and the MWE/XPand M6 build on Hudson! It's a funny kind of circular dependency, as it involves code generation, not binaries. And unavoidable of course if we are really eating our own dog food.. 0 [Thread-0] ERROR mf.mwe2.launch.runtime.Mwe2Launcher - com.google.inject.internal.ComputationException: java.lang.NoClassDefFoundError: org/eclipse/xtext/parsetree/reconstr/IInstanceDescription com.google.inject.internal.ComputationException: com.google.inject.internal.ComputationException: java.lang.NoClassDefFoundError: org/eclipse/xtext/parsetree/reconstr/IInstanceDescription at com.google.inject.internal.MapMaker$StrategyImpl.compute(MapMaker.java:553) at com.google.inject.internal.MapMaker$StrategyImpl.compute(MapMaker.java:419)
(In reply to comment #28) > Because of changes in > bug 311787, to get XText M7 to build I need to regenerate, but to do *that* I > need MWE2 / XPand M7, or I get the error below. So I need to use MWE2 M7 > locally and the MWE/XPand M6 build on Hudson! It's a funny kind of circular > dependency, as it involves code generation, not binaries. And unavoidable of > course if we are really eating our own dog food.. The M7 build shouldn't need M6. I presume you are running MWE2 during the build. Generally it is much more convenient for users (and builders) to fetch all auto-generated Java from CVS, otherwise users have to install all the build tools. Certainly EMF models have ?alwyas been expanded in CVS. MDT/OCL puts src-gen in CVS, which has some size and exact rrgenerability issues, but solvces the build order problem.
(In reply to comment #4) > (In reply to comment #2) > > > Install xtext M7 using the update site > > http://download.eclipse.org/modeling/tmf/updates/milestones/ > > All dependencies will be installed automatically. > > This does not work. > > I unzipped M7 WIN32 platform. > Did Install New Software for the above in an empty workspace. I have cracked this. In order to install from just Eclipse web sites and get just M7 contributions: Unzip M7 win32 platform Install MWE2 Install MWE Install XPAND Install XTEXT one at a time. MWE2 provides all the awkward com.google bits. It seems that the preferred dependencies are wrong: Xtext alone doesn't see MWE2 and prefers MWE M6 and XPAND M6. This is therefore an outstanding issue to be addressed by this bug, or deferred to a new one truncating the confusing discussions. The non-visibility of MWE/MWE2 updates on Download pages may be associated with this lack of Install visibility. I'm fairly hopeful that once Hudson stops 500-ing I can use this insight to fix the build.
(In reply to comment #29) > The M7 build shouldn't need M6. I presume you are running MWE2 during the > build. You presume wrong. :) It's not a blocker, just an oddity.
Build success; well now the build fails only through M6/M7 API changes. It's easy once you don't have a misleading wildcard repo being helpful. The tip on orbit/updateSite was useful thanks. The relevant lines from MDT/OCL are: dependencyURLs=http://download.eclipse.org/eclipse/downloads/drops/S-3.6M7-201004291549/eclipse-SDK-3.6M7-linux-gtk-ppc.tar.gz repositoryURLs=\ http://download.eclipse.org/modeling/tmf/xtext/downloads/drops/1.0.0/S201005041135/tmf-xtext-Update-1.0.0M7.zip,\ http://download.eclipse.org/modeling/m2t/xpand/downloads/drops/1.0.0/S201005041053/m2t-xpand-Update-1.0.0M7.zip,\ http://download.eclipse.org/modeling/emft/mwe/downloads/drops/1.0.0/S201005040922/emft-mwe2-Update-1.0.0M7.zip,\ http://download.eclipse.org/modeling/emft/mwe/downloads/drops/1.0.0/S201005040954/emft-mwe-Update-1.0.0M7.zip,\ http://download.eclipse.org/modeling/mdt/uml2/downloads/drops/3.1.0/S201005031632/mdt-uml2-Update-3.1.0M7.zip, \ http://download.eclipse.org/modeling/emf/emf/downloads/drops/2.6.0/S201005031457/emf-xsd-Update-2.6.0M7.zip,\ http://download.eclipse.org/tools/orbit/downloads/drops/S20100423142122/updateSite pluginIDsToInstall=org.apache.commons.cli+org.apache.commons.lang+org.apache.commons.logging+com.google.inject featureIDsToInstall=org.eclipse.emf+org.eclipse.xsd+org.eclipse.uml2+org.eclipse.emf.mwe.ui+org.eclipse.emf.mwe2.runtime.sdk+org.eclipse.xpand+org.eclipse.xtend+org.eclipse.xtext.runtime+org.eclipse.xtext.ui allowBinaryCycles=true (I'm not sure how many of the explicit plugin/feature IDsToInstall are really necessary).
can we close this one?
(In reply to comment #33) > can we close this one? Certainly with respect to the reported issue. Interactive and Hudson build problems have been understood. Just one further observation and a query. Transiently there is an installation issue that installing MDT/OCL M7a Update in isolation succeeds but running the editors crashes, because the staging area provided M6 Xtext; that will presumably be solved shortly. I was unable to create an interactive environment to upgrade the OCL Xtext editors from M6 to M7 using exclusively Eclipse plugins (other than de.antlr); MWE2-lang must be added to the above list to have an MWE launcher. Using the itemis site downloads the upgrade was easy. Carefully comparing the Eclipse-derived and itemis-derived workspaces showed no obvious differences in the plugin versions, so not a problem of a missing plugin, although there could be problem from an 'extra' plugin. The problem with the Eclipse-derived workspace was a complaint that no logger could be found; please configure log4j correctly. Any clues?
If the discussion contains an issue which has not yet been addressed, please open a new bugzilla for it exclusively.
Closing bug which were set to RESOLVED before Eclipse Neon.0.
