[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
[JBoss JIRA] Created: (JBIDE-9688) Add JBoss public repository to list of default repositories in Eclipse
by Rob Cernich (JIRA)
Add JBoss public repository to list of default repositories in Eclipse
----------------------------------------------------------------------
Key: JBIDE-9688
URL: https://issues.jboss.org/browse/JBIDE-9688
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: maven
Reporter: Rob Cernich
Assignee: Fred Bricon
Priority: Minor
M2e exposes an extension point, which allows plugins to contribute repositories to be indexed. Automatically registering the JBoss repository seems like a sensible thing for JBoss Tools. This would allow the user to access the JBoss public repository from the tooling (e.g. add dependency) without requiring them to add the JBoss public repository to their settings.xml file. Of course, the user would still need to ensure that the repository was correctly configured within their pom so the project will build correctly.
The following is all that is required (in plugin.xml):
<extension
point="org.eclipse.m2e.core.indexes">
<index
indexId="JBOSS_NEXUS"
isShort="true"
repositoryUrl="http://repository.jboss.org/nexus/content/groups/public">
</index>
</extension>
--
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] (JBDS-2030) Disabled modal usage dialogs from extras plugins by default
by Jiri Peterka (JIRA)
Jiri Peterka created JBDS-2030:
----------------------------------
Summary: Disabled modal usage dialogs from extras plugins by default
Key: JBDS-2030
URL: https://issues.jboss.org/browse/JBDS-2030
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Build, updatesite
Affects Versions: 5.0.0.M5
Environment: JBDS 5.0.0.M5
Reporter: Jiri Peterka
Assignee: Nick Boldt
Fix For: 5.0.0.Beta1
Usage analysis modal dialogs from extras plugins are quire annoying. Mainly in situations when there is more then one and the one with focus is hidden behind the other. It would be nice if appearing of these dialogs could be disabled by default in JBDS.
Namely these:
* subclipse usage
* atlasian connector
--
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-10702) Editor for JCR Compact Node Definition (CND) files
by Randall Hauch (JIRA)
Randall Hauch created JBIDE-10702:
-------------------------------------
Summary: Editor for JCR Compact Node Definition (CND) files
Key: JBIDE-10702
URL: https://issues.jboss.org/browse/JBIDE-10702
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: modeshape
Reporter: Randall Hauch
Assignee: Dan Florian
JSR-283 (aka, JCR 2.0) includes a standard format called 'Compact Node Definition' that is used to declare node types, property definitions, and child node definitions.
*Resources*
The official grammar of the CND format is defined in [Section 25.2|http://www.day.com/specs/jcr/2.0/25_Appendix.html#25.2%20Compact%20N...] of the JCR 2.0 specification. The ModeShape project has in its documentation a [tutorial|https://docs.jboss.org/author/display/MODE/Defining+custom+node+...] for working with CND files. The
ModeShape project also has code to parse a CND file, and it's probably better to simply copy this code and simplify/customize it to the editor's needs rather than have the editor depend on the ModeShape project for just these classes (which probably aren't perfectly usable as is for the editor).
There are also example CNDs in the ModeShape codebase.
*Requirements*
# Edit any .cnd file in the workspace _(Priority 1)_
# View the file source, with support for select/copy _(Priority 1)_
# Edit the file source, with support for paste _(Priority 3)_
# Syntax highlighting (color keywords, quoted strings, comments) of file source would be a nice-to-have _(Priority 2)_
# Problem markers (in file source, Problems view) would be a nice-to-have _(Priority 3)_
# Form-based editor:
## view/edit/add/remove namespace declarations _(Priority 1)_
## view/edit/add/remove node type and its attributes and supertypes _(Priority 1)_
## view/edit/add/remove property definition (and its attributes) for a selected node type _(Priority 1)_
## view/edit/add/remove child node definition (and its attributes) for a selected node type _(Priority 1)_
# Preferences for
## using long, medium, or short forms of attributes (e.g., "abstract" vs "abs" vs "a") _(Priority 2, start out w/ long)_
*Other ideas*
# It would be nice if the user doesn't have to scroll in the form editor when working on a node type.
# Is it possible to optionally see the both inherited and explicit property definitions and child node definitions? Perhaps the inherited definitions might be grey-ed out and non-editable. One issue might be how to know which node type it came from (without cluttering up the UI).
--
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-11207) Error logged from Forge Plugin:
by Burr Sutter (JIRA)
Burr Sutter created JBIDE-11207:
-----------------------------------
Summary: Error logged from Forge Plugin:
Key: JBIDE-11207
URL: https://issues.jboss.org/browse/JBIDE-11207
Project: Tools (JBoss Tools)
Issue Type: Bug
Reporter: Burr Sutter
I pasted in the following chunk into the Forge window:
entity --named Customer --package ~.domain;
field string --named firstName;
field string --named lastName;
field temporal --type DATE --named birthDate;
and the result was
Java Model Exception: Java Model Status [DATE birthDate [in Customer [in [Working copy] Customer.java [in com.burrsutter.testforge1.domain [in src/main/java [in testforge1]]]]] does not exist]
at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:495)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:529)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
at org.eclipse.jdt.internal.core.SourceRefElement.getSourceRange(SourceRefElement.java:218)
at org.jboss.tools.forge.ui.console.FieldPostProcessor.postProcess(FieldPostProcessor.java:36)
at org.jboss.tools.forge.ui.console.ForgeCommandProcessor$1.run(ForgeCommandProcessor.java:55)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
--
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