[JBoss JIRA] (JBIDE-13599) externalize Central site URL into a commandline property so that testing or mirroring is easier
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13599?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-13599:
---------------------------------------------
Wow - I did not realize you were using dmr code directly.
This explains why you rely on system properties since that is what dmr does - not what we need.
I can also see that DMR would throw an exception if something wrong is resolved - is that the behavior we need: https://github.com/jbossas/jboss-dmr/blob/master/src/test/java/org/jboss/... ? (it might be but not seeing the code handling this.
DMR actually does seem to handle multiple values, i.e. https://github.com/jbossas/jboss-dmr/blob/master/src/test/java/org/jboss/...
It's just a different syntax.
I can also see the default replacement seem to treat file seperators and path seperators as a special case and return different results based on OS values - how does that
affect us ? (https://github.com/jbossas/jboss-dmr/blob/master/src/main/java/org/jboss/...)
But why we want to add a direct dependency on this library for this simple functionality I do not grok.
We should just copy the code and adjust it for what we need (looks like no changes needed except a few for the above issues) - note, this is tough LGPL so need to adjust for that.
> externalize Central site URL into a commandline property so that testing or mirroring is easier
> -----------------------------------------------------------------------------------------------
>
> Key: JBIDE-13599
> URL: https://issues.jboss.org/browse/JBIDE-13599
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Snjezana Peco
> Fix For: 4.1.0.Alpha2
>
>
> As discussed in https://issues.jboss.org/browse/JBDS-2469?focusedCommentId=12755106&page=... testing Central is tricky if it's not properly bootstrapped, and bootstrapping is hard when we're on an early Alpha and don't want bits to be public before they've passed QE.
> A better approach than having the update site URL used in Central's discovery plugin.xml hardcoded into that file would be to have it read from a Preference in Eclipse or JBDS. This would allow it to be overwritten/overridden should a user want to test installation from a different URL than the default value.
> This might even make it possible to have the same discovery plugin used for JBT and JBDS (assuming the list of connectors were the same, and certification was to appear for both instances) simply by having the preference changed to a different default URL when installing JBT or JBDS BYOE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JBIDE-13671) parent pom should use last-mod-timestamp from git for a plugin/feature instead of current timestamp when building
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-13671:
----------------------------------------
> You mean if you got asserver-1.0.2-24234234234 and asserver-1.0.2-werwer it should assume they are the same ?
Yes, it would compare them and replace the new one with the one from baseline if they are the same. Of course, one could disable this behaviour.
> What would it use for "Same content" ?
Default p2 JarComparator looks at actual content: MANIFEST fields, class files and so on. https://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.ecli...
We could think in making it able to do this comparison but ignore the qualifier.
> parent pom should use last-mod-timestamp from git for a plugin/feature instead of current timestamp when building
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13671
> URL: https://issues.jboss.org/browse/JBIDE-13671
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.x
>
> Attachments: jbide13671-before-and-after.png
>
>
> This needs to be added to master parent pom:
> {code}
> <plugin>
> <groupId>org.eclipse.tycho</groupId>
> <artifactId>tycho-packaging-plugin</artifactId>
> <version>${tycho.version}</version>
> <dependencies>
> <dependency>
> <groupId>org.eclipse.tycho.extras</groupId>
> <artifactId>tycho-buildtimestamp-jgit</artifactId>
> <version>${tycho-extras.version}</version>
> </dependency>
> </dependencies>
> <configuration>
> <strictBinIncludes>false</strictBinIncludes>
> <format>'v'yyyyMMdd-HHmm</format>
> <timestampProvider>jgit</timestampProvider>
> <jgit.ignore>
> </jgit.ignore>
> </configuration>
> </plugin>
> {code}
> Ref: http://pweclipse.blogspot.ch/2012_09_01_archive.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JBIDE-11495) Improve ability to configure dependent hudson jobs and provide accessable documentation
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-11495?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-11495:
---------------------------------------------
I think this is part of rethinking how we build the various stacks (big and small). The suggested notes above is following the model of "lets just use the latest and hope for best" approach; its great because all the latest greatest build together but the downside is that you never spot if you actually broke anyone and you are most likely rebuilding unnecessarily.
JBTIS doesn't even do any of this - they choose a fixed version of JBT core to use and use that for release.
I would say issue is about making it easy to setup hudson builds for your component builds and document which jobs to use.
> Improve ability to configure dependent hudson jobs and provide accessable documentation
> ---------------------------------------------------------------------------------------
>
> Key: JBIDE-11495
> URL: https://issues.jboss.org/browse/JBIDE-11495
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: Build/Releng
> Reporter: Barry LaFond
> Assignee: Douglas Palmer
> Fix For: 4.0.x
>
>
> SOA decoupling has elevated the need to have more configurable control over upstream and downstream dependencies.
> Notes from Nick:
> * a number of jobs are now set to build only when triggered by upstream, but SOA stuff is not as well handled
> * ideally you'd want: a) check svn every N hours (usually 6) and b) upstream should use Parameterized Trigger to cause downstream to fire
> * you can also ensure that you're building against a stable aggregate using an override like the one I've set up for SOA Tooling aggregate...
> * in your maven invocation, under Properties, you can do this: # use latest upstream nightly Core update site instead of "wild components" in the composite staging site jbosstools-nightly-staging-composite=http://download.jboss.org/jbosstools...
> * that way you pull from the aggregate (updates weekly) instead of the composite (updates every time a component respins)
> * means if you depended on something like tests/common/jst/vpe/jsf/seam/maven/central/usage stack, you wouldn't need to worry about getting incompatible pieces
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JBIDE-13459) 64 test failures in org.jboss.tools.as.test.core since switching to build w/ Kepler M4 target platform
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13459?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-13459.
---------------------------------
There were no failures in at least one build after this, so closing this JIRA. But there are now two new failures - I created JBIDE-13750 for that.
> 64 test failures in org.jboss.tools.as.test.core since switching to build w/ Kepler M4 target platform
> -------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13459
> URL: https://issues.jboss.org/browse/JBIDE-13459
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: JBossAS/Servers
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Rob Stryker
> Fix For: 4.1.0.Alpha1
>
>
> {code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-4.1_trunk.component--server/165/testReport/}
> Failing for 6 builds (age = 6):
> Test Name Duration Age
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[60] 3.3 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[61] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[62] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[63] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[64] 2.3 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[65] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[66] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[67] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[68] 2.3 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[69] 2.9 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[70] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[71] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[72] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[73] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[74] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[75] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[76] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[77] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[78] 2.3 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[79] 2.3 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[80] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[81] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[82] 2.3 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[83] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[84] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[85] 2.9 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[86] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[87] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[88] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFileTest.testSingleDeployableFullPublish[89] 2.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[60] 3.4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[61] 4.2 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[62] 3.5 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[63] 4.2 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[64] 3.6 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[65] 3.5 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[66] 4.1 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[67] 3.5 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[68] 3.5 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[69] 4.7 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[70] 3.6 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[71] 3.5 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[72] 4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[73] 4.2 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[74] 4.2 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[75] 4.1 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[76] 3.6 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[77] 3.6 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[78] 3.6 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[79] 4 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[80] 3.6 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[81] 3.6 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[82] 3.6 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[83] 3.5 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[84] 3.5 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[85] 3.6 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[86] 4.2 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[87] 3.6 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[88] 4.2 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.publishing.SingleDeployableFolderTest.testSingleDeployableFolder[89] 3.7 sec 6
> >>> org.jboss.tools.as.test.core.parametized.server.XPathModelTest.serverTestImpl[0] 15 ms 6
> >>> org.jboss.tools.as.test.core.launch.MockArgsTests.initializationError 2 ms 6
> >>> org.jboss.tools.as.test.core.launch.MockArgsTests.initializationError 1 ms 6
> >>> org.jboss.tools.as.test.core.classpath.EJB3SupportVerifierTest.testEJB30Support[11] 20 ms 6
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JBDS-2401) remove old version of installer code & refactor new stuff to remove "pde" from the name
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2401?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-2401:
-------------------------------------------
\O/
> remove old version of installer code & refactor new stuff to remove "pde" from the name
> ---------------------------------------------------------------------------------------
>
> Key: JBDS-2401
> URL: https://issues.jboss.org/browse/JBDS-2401
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 7.0.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 7.0.0.Alpha1
>
> Attachments: jbds2401.patch.txt
>
>
> Many moons ago, we forked the inpack installer code so that we now have these files:
> {code:title=https://svn.jboss.org/repos/devstudio/trunk/product/installer}
> ./build-pde.xml
> ./src/config/install-pde.xml
> ./src/config/resources/default_shortcut_specification_pde.xml
> ./src/config/resources/p2-meta-gen-action-pde.xml
> ./src/config/resources/p2-meta-gen-script-pde.xml
> ./src/config/resources/readme-pde.txt
> ./src/config/resources/unix_shortcut_specification_pde.xml
> and
> ./build.xml
> ./src/config/install.xml
> ./src/config/resources/default_shortcut_specification.xml
> ./src/config/resources/p2-meta-gen-action.xml
> ./src/config/resources/p2-meta-gen-script.xml
> ./src/config/resources/readme.txt
> ./src/config/resources/unix_shortcut_specification.xml
> {code}
> The old code should be removed from trunk, and the new stuff refactored so that there's no longer a "-pde" or "_pde" marker in it, since we don't build w/ PDE anymore.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JBIDE-13671) parent pom should use last-mod-timestamp from git for a plugin/feature instead of current timestamp when building
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-13671:
---------------------------------------------
okey - then i'm just lacking:
"Ideally, we would like to achieve a similar behaviour that would ignore qualifiers, so we won't have to brainstorm about what's the best qualifier to implement this, Tycho would take an already built bundle if the content are the same, except qualifier."
You mean if you got asserver-1.0.2-24234234234 and asserver-1.0.2-werwer it should assume they are the same ?
What would it use for "Same content" ? MD5 doesn't work since the qualifier is also inside the archive; and the SHA1 would be the same if built from same commit at least.
> parent pom should use last-mod-timestamp from git for a plugin/feature instead of current timestamp when building
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13671
> URL: https://issues.jboss.org/browse/JBIDE-13671
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.x
>
> Attachments: jbide13671-before-and-after.png
>
>
> This needs to be added to master parent pom:
> {code}
> <plugin>
> <groupId>org.eclipse.tycho</groupId>
> <artifactId>tycho-packaging-plugin</artifactId>
> <version>${tycho.version}</version>
> <dependencies>
> <dependency>
> <groupId>org.eclipse.tycho.extras</groupId>
> <artifactId>tycho-buildtimestamp-jgit</artifactId>
> <version>${tycho-extras.version}</version>
> </dependency>
> </dependencies>
> <configuration>
> <strictBinIncludes>false</strictBinIncludes>
> <format>'v'yyyyMMdd-HHmm</format>
> <timestampProvider>jgit</timestampProvider>
> <jgit.ignore>
> </jgit.ignore>
> </configuration>
> </plugin>
> {code}
> Ref: http://pweclipse.blogspot.ch/2012_09_01_archive.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JBDS-2494) Cannot install GWT Designer - missing org.eclipse.wb.core.xml
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBDS-2494?page=com.atlassian.jira.plugin.... ]
Martin Malina commented on JBDS-2494:
-------------------------------------
ok, this seems like a duplicate of JBIDE-13706. but that one is fixed - I am able to install GWT Designer from JBT central in JBT 4.1.0.Alpha1c. but not in JBDS 7.0.0.Alpha1c using the update sites above. should I use some other sites?
> Cannot install GWT Designer - missing org.eclipse.wb.core.xml
> -------------------------------------------------------------
>
> Key: JBDS-2494
> URL: https://issues.jboss.org/browse/JBDS-2494
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: 3rdPartyDependencies, Build
> Affects Versions: 7.0.0.Alpha1
> Environment: JBDS 7.0.0.Alpha1c
> Reporter: Martin Malina
> Assignee: Nick Boldt
> Fix For: 7.0.0.Alpha2
>
>
> I am unable to install GWT plugins including GWT Designer.
> Because of JBDS-2469 I am trying to use normal update sites and not JBoss Central.
> I have these update sites added:
> http://www.qa.jboss.com/binaries/RHDS/targetplatforms/jbdevstudiotarget/4...
> http://www.qa.jboss.com/binaries/RHDS/updates/development/7.0.0.Alpha1c.c...
> https://devstudio.jboss.com/updates/7.0-staging/extras/
> Then I go to Help -> Install New Software... and select the extras update site.
> I uncheck "Group items by category" and manually select all Google/GWT and Window Builder (which is needed for Google Designer).
> Then I am given this error:
> {code}
> Cannot complete the install because one or more required items could not be found.
> Software being installed: WindowBuilder XML Core (requires Eclipse WTP/WST) 1.5.2.r42x201302111919 (org.eclipse.wb.core.xml.feature.feature.group 1.5.2.r42x201302111919)
> Missing requirement: WindowBuilder Core for XML GUI's 1.5.2.r42x201302111919 (org.eclipse.wb.core.xml 1.5.2.r42x201302111919) requires 'bundle org.eclipse.wb.core.java 0.0.0' but it could not be found
> Cannot satisfy dependency:
> From: WindowBuilder XML Core (requires Eclipse WTP/WST) 1.5.2.r42x201302111919 (org.eclipse.wb.core.xml.feature.feature.group 1.5.2.r42x201302111919)
> To: org.eclipse.wb.core.xml [1.5.2.r42x201302111919]
> {code}
> So the missing dependency is org.eclipse.wb.core.xml. Shouldn't that be on the target platform? Am I doing something wrong?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month