[JBoss JIRA] (JBIDE-11476) JAX-RS Tools, Maven JAX-RS Configurator and WebServices cannot be installed on juno
by Denis Golovin (JIRA)
Denis Golovin created JBIDE-11476:
-------------------------------------
Summary: JAX-RS Tools, Maven JAX-RS Configurator and WebServices cannot be installed on juno
Key: JBIDE-11476
URL: https://issues.jboss.org/browse/JBIDE-11476
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: SOA Tooling, Webservices
Reporter: Denis Golovin
Assignee: Douglas Palmer
{code}Cannot complete the install because of a conflicting dependency.
Software being installed: JBoss WebServices Tools 1.2.2.v20120323-1522-H83-Beta2 (org.jboss.tools.ws.feature.feature.group 1.2.2.v20120323-1522-H83-Beta2)
Software currently installed: Eclipse SDK 4.2.0.I20120127-1145 (org.eclipse.sdk.ide 4.2.0.I20120127-1145)
Only one of the following can be installed at once:
Core Resource Management 3.6.0.v20100526-0737 (org.eclipse.core.resources 3.6.0.v20100526-0737)
Core Resource Management 3.8.0.v20120229-1128 (org.eclipse.core.resources 3.8.0.v20120229-1128)
Core Resource Management 3.8.0.v20120120-1053 (org.eclipse.core.resources 3.8.0.v20120120-1053)
Core Resource Management 3.6.1.R36x_v20110131-1630 (org.eclipse.core.resources 3.6.1.R36x_v20110131-1630)
Core Resource Management 3.7.101.v20120125-1505 (org.eclipse.core.resources 3.7.101.v20120125-1505)
Core Resource Management 3.6.0.R36x_v20100825-0600 (org.eclipse.core.resources 3.6.0.R36x_v20100825-0600)
Core Resource Management 3.7.100.v20110510-0712 (org.eclipse.core.resources 3.7.100.v20110510-0712)
Cannot satisfy dependency:
From: Eclipse Platform 4.2.0.v20120112-2236-9IF7FH9EFwCXK_YKFP1XVz-xAsGJFz0QMKdek4UHk9aCo (org.eclipse.platform.feature.group 4.2.0.v20120112-2236-9IF7FH9EFwCXK_YKFP1XVz-xAsGJFz0QMKdek4UHk9aCo)
To: org.eclipse.core.resources [3.8.0.v20120120-1053]
Cannot satisfy dependency:
From: Eclipse Project SDK 4.2.0.v20120109-2249-7T7mA7F8Yw_bnhbk55x4C6D3D7TtTxFPcwnkjP2xF9RDp (org.eclipse.sdk.feature.group 4.2.0.v20120109-2249-7T7mA7F8Yw_bnhbk55x4C6D3D7TtTxFPcwnkjP2xF9RDp)
To: org.eclipse.platform.feature.group [4.2.0.v20120112-2236-9IF7FH9EFwCXK_YKFP1XVz-xAsGJFz0QMKdek4UHk9aCo]
Cannot satisfy dependency:
From: Eclipse SDK 4.2.0.I20120127-1145 (org.eclipse.sdk.ide 4.2.0.I20120127-1145)
To: org.eclipse.sdk.feature.group [4.2.0.v20120109-2249-7T7mA7F8Yw_bnhbk55x4C6D3D7TtTxFPcwnkjP2xF9RDp]
Cannot satisfy dependency:
From: JBossWS Core 1.2.2.v20120323-1522-H83-Beta2 (org.jboss.tools.ws.core 1.2.2.v20120323-1522-H83-Beta2)
To: bundle org.eclipse.core.resources [3.7.0,3.8.0)
Cannot satisfy dependency:
From: JBoss WebServices Tools 1.2.2.v20120323-1522-H83-Beta2 (org.jboss.tools.ws.feature.feature.group 1.2.2.v20120323-1522-H83-Beta2)
To: org.jboss.tools.ws.core [1.2.2.v20120323-1522-H83-Beta2]{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (JBIDE-9309) Easily adding full JBoss AS source
by arjan tijms (JIRA)
Easily adding full JBoss AS source
----------------------------------
Key: JBIDE-9309
URL: https://issues.jboss.org/browse/JBIDE-9309
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: JBossAS
Reporter: arjan tijms
Assignee: Rob Stryker
The JBoss AS server runtime from JBoss tools adds a library container to the classpath of an Eclipse project. This container provides a large amount of jar files that make up JBoss AS itself and the Java EE services it offers.
Attaching the source code for this is notoriously difficult. Because it concerns a large amount of jar files, attaching source code for each jar is a rather tedious job.
For JBoss AS 5, the fact that the location of jars in the source archive was completely different from the structure exposed in Eclipse or the binary build of JBoss AS, made it very hard to actually locate the correct source jar. Sometimes even names were different, making it even harder.
For JBoss AS 6, the source archive does not even contain the source for the majority of the JBoss AS artifacts. Source for 'core functionality' (from the point of view of the Java EE developer), like Servlet and JSF is missing. The user has to hunt the Internet to find the correct source for the correct version that JBoss AS 6 uses. This makes an already tedious job even more tedious.
I would like to request functionality where the user can point to a single _jboss-src.xyz_ file that contains all sources. JBoss tools should then automatically attach the right source from the archive to the right jar from the library container. Alternatively the user could point to a maven repository (but this should not make the Eclipse project dependent on maven).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JBIDE-11154) In Beta1c, publish to openshift is non-functional
by Burr Sutter (JIRA)
Burr Sutter created JBIDE-11154:
-----------------------------------
Summary: In Beta1c, publish to openshift is non-functional
Key: JBIDE-11154
URL: https://issues.jboss.org/browse/JBIDE-11154
Project: Tools (JBoss Tools)
Issue Type: Bug
Environment: MacOSX Lion - 32-bit installation of JBDS 5 Beta1c on 64-bit OS
Reporter: Burr Sutter
Assignee: Andre Dietisheim
Steps to reproduce:
1) click on HTML5, SpringMVC or RichFaces archetype, name the project "poh5", "springmvc" or "richfaces-demo"
2) deploy to localhost:8080 (AS 7.1) to see that the application runs correctly
3) Using the OpenShift Application wizard in JBoss Central - built a new application, and select one of the existing projects.
4) Using the browser, login into the openshift express console. If you hit the URL for your openshift app, you should see the default application - index.html and health.jsp
5) Right click on the openshift app in the Servers tab and select Publish, now revisit the URL for the application, nothing shows up.
The last few lines in the console look like the following:
[WARNING] The requested profile "openshift" could not be activated because it does not exist.
Emptying tmp dir: /var/lib/libra/e1744a38d9c9410e99fd9ecadec2fa64/spring/jbossas-7.0/standalone/tmp/vfs
Emptying tmp dir: /var/lib/libra/e1744a38d9c9410e99fd9ecadec2fa64/spring/jbossas-7.0/standalone/tmp/work
Starting application...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JBIDE-11166) Supporting multi-module projects in OpenShift Deployment
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBIDE-11166:
-------------------------------------------
Summary: Supporting multi-module projects in OpenShift Deployment
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift, JBossAS/Servers
Reporter: Max Rydahl Andersen
Assignee: Andre Dietisheim
Priority: Critical
Fix For: 3.3.0.Beta1, 3.3.0.Beta2
POH5 archetype recently got updated and became the first project layout that requires support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and "B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator project.
And this is the kind of layout we would need to support, and I see the following things we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by default
C) Import of OpenShift Application should be sure it will actually import a multimodule project.
D) Import of OpenShift App when using existing App would need to do some validity checks *and* somehow ensure the child projects gets available if they aren't imported (maybe a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP then dont deploy. i.e. /Users/max/ap is parent for project A stored in /Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months