[JBoss JIRA] (JBTIS-94) Creating BPMN2 process throws NPE
by Andrej Podhradsky (JIRA)
Andrej Podhradsky created JBTIS-94:
--------------------------------------
Summary: Creating BPMN2 process throws NPE
Key: JBTIS-94
URL: https://issues.jboss.org/browse/JBTIS-94
Project: JBoss Tools Integration Stack
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: BPMN2
Affects Versions: 4.0.1
Reporter: Andrej Podhradsky
Priority: Blocker
Creating BPMN2 process throws NullPointerException, see the attachments.
--
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
12 years, 10 months
[JBoss JIRA] (TOOLSDOC-345) NeedInfo: Distinction between Eclipse and JBDS/JBT Server Tools
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-345?page=com.atlassian.jira.plug... ]
Rob Stryker commented on TOOLSDOC-345:
--------------------------------------
A "runtime" is an in-eclipse representation of a locally installed Application Server. In our case, a runtime includes some specific configuration elements, like what VM it uses, or what the configuration is.
You may have multiple runtimes pointing to the same install location, but with different configuration choices, such as "all" instead of "default" for application server versions < 7. For AS >= 7, that option is replaced with what configuration file to use (standalone.xml, standalone-ha.xml, etc).
A server represents a way to launch, publish to, and communicate with, a runtime. A server in the local mode represents a server communicating with a server running on the same machine. Many servers may use the same runtime but with different configuration items. These configuration items may include different launch arguments, different default publish locations, and other things of that nature.
So for example, you may have Server1 backed by runtime Runtime1, which may pass in -DcustomSystemProperty=true, while Server2 (also backed by Runtime1) does not pass in such a property.
So the server adapter indicates how eclipse should interact with the backing server that is launched.
> 4. The new server wizard creates both the server instance and server adapter for local servers.
The new server wizard will create a runtime if none has been created yet. So if it's your first time using the new server wizard, the 2nd page will be the runtime details, and the 3rd page will be the server configuration. If you've already created a server of the same type before, then a runtime already exists. Page1 of the new server wizard will include a combo box where you may select which existing runtime to use, or, you may click a hyperlink to the left "Add..." which allows you to create a new runtime for the given server type.
> 5. Server adapters are listed in the servers tab. But for the main part local server instances and their adapters can be considered as one within the IDE.
I suppose this is true, but the language confuses me a bit. Deleting a server from the servers view will not delete the server from your computer. It only deletes the in-eclipse representation of the server. You should think of a server adapter as a bunch of settings, launch arguments, etc, which help your IDE's server adapter know how to launch and communicate with the actual server.
> 8. To create a server adapter for a remote server, the server runtime environment of the remote system must be installed on the local system where the IDE is running. [Basically so they can share a common language/API/instruction set.]
A local installation with the same setting files as the remote server is required locally, to ensure that when the IDE tries to figure out what ports to use to communicate with the remote server, it does not get faulty data. If your remote server's standalone.xml clearly says to use port 8080, but the local installation says to use 8181, then the IDE will attempt to communicate with the remote on 8181, and will fail. And, yes, you are right, that we do load jars from the local instance to use when *actually* communicating with the remote, so the common api and remote communication methods must match.
> 9. The new server wizard only creates the server adapter for remote servers.
Again, if its your first time using the new server wizard and you are in a clean workspace, the new server wizard will create a runtime which represents your local installation of JBoss, and a server which represents your remote server. The server adapter (which represents the remote instance) still requires a runtime, and so it uses the one representing the local appserver, assuming that it is equivilent to the remote. The rest of the settings are available either in the server editor or the launch configuration.
You'll note that when in local mode, you do not need to set your configuration name / file in the server editor. When using a local-mode server adapter, it pulls this data from the runtime, where it already exists. When using a server set to remote-mode, the server editor will request you re-declare the server home directory, configuration name / file, etc. This is because it cannot be 100% assumed the user has everything 100% equal to the remote instance, specifically the home directory. Your local version might be in /home/mmurray/dev/jboss/etc, but your remote instance might live in /some/production/jboss/root. For our cases, having the same installation is close enough, so long as the user takes care that the ports match up and settings in the server editor make sense.
> 10. Again the server adapter is listed in the servers view
Yep.
> NeedInfo: Distinction between Eclipse and JBDS/JBT Server Tools
> ---------------------------------------------------------------
>
> Key: TOOLSDOC-345
> URL: https://issues.jboss.org/browse/TOOLSDOC-345
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: User Guide - JBoss Server Tools
> Affects Versions: 4.1.0
> Reporter: Michelle Murray
> Assignee: Rob Stryker
> Fix For: 4.1.0
>
>
> I am trying to distinguish which features are provided by Eclipse and which are provided by JBoss Server Tools so that I can accurately document JBoss Server Tools.
> The unique JBoss Server Tools features I have are:
> * automatic runtime detection
> * ability to download and install a JBoss runtime
> * JBoss Server Editor - lots of the panes in the overview tab are unique and * the deployment tab is completely unique
> * set a default server icon
> * set default filesets
> * set default classpath entries
> * create new server wizard also seems different for JBoss enterprise and community servers than in the wizard in Eclipse alone
> What have I missed?
--
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
12 years, 10 months
[JBoss JIRA] (TOOLSDOC-336) NeedInfo: What is the current situation with cheat sheet?
by Michelle Murray (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-336?page=com.atlassian.jira.plug... ]
Michelle Murray resolved TOOLSDOC-336.
--------------------------------------
Resolution: Done
> NeedInfo: What is the current situation with cheat sheet?
> ---------------------------------------------------------
>
> Key: TOOLSDOC-336
> URL: https://issues.jboss.org/browse/TOOLSDOC-336
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Task
> Components: User Guide - JBoss Central & JBoss Perspective
> Affects Versions: 4.1.0
> Reporter: Michelle Murray
> Assignee: Michelle Murray
> Fix For: 4.1.0
>
>
> JBDS-2557, JBDS-2558, and JBIDE-14331 are all about cheet sheets.
> I get the general gist of cheat sheets from looking at the examples that come with Eclipse - so a tutorial stepping a user through creating a project.
> What is the current situation with JBDS/JBT cheat sheets?
> If this feature is working, can someone please give me a workflow so that I can have a play? I have no idea how to get started with this.
--
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
12 years, 10 months
[JBoss JIRA] (JBIDE-14325) Remove UI dependencies from o.j.t.common.core
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14325?page=com.atlassian.jira.plugi... ]
Alexey Kazakov resolved JBIDE-14325.
------------------------------------
Resolution: Done
> Remove UI dependencies from o.j.t.common.core
> ---------------------------------------------
>
> Key: JBIDE-14325
> URL: https://issues.jboss.org/browse/JBIDE-14325
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core
> Affects Versions: 4.1.0.Alpha2
> Reporter: Rob Stryker
> Assignee: Alexey Kazakov
> Fix For: 4.1.0.Beta2
>
>
> One class is polluting o.j.t.common.core with a guaranteed UI class reference. The class in question is org.jboss.tools.common.text.TextProposal. This class should not be in a core plugin at all.
> This class USED to live in org.jboss.tools.common, but was mistakenly moved to org.jboss.tools.common.core. The package name was NOT changed, so consumers of this class almost 100% did not change their dependencies or depend on teh new LOCATION at all.
> Moving this class *BACK* to where it was before, while technically an API change, is almost assuredly very very low risk. There is a danger that *NEW* consumers have appeared, and that risk should be considered, but not exaggerated.
> One other class depends on two jeetools packages which are very large and have a sprawling dependency list. I can not say with certainty whether any UI is pulled in via this reference, but, i feel it is safest to remove it if it can be done in a safe manner.
--
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
12 years, 10 months
[JBoss JIRA] (JBIDE-13882) Allow users to easily "binary deploy"
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13882?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-13882 at 6/11/13 6:37 PM:
-------------------------------------------------------------------
we discussed where to put the UI to allow to create the "skip_maven_project" marker for existing projects. We decided that the OpenShift Explorer is not the right place since its focused on the OpenShift server, the remote part. We add the marker in the local clone/project the Explorer would therefore have to look for a matching project for a given/selected OpenShift application. We opted for a context menu in 2 places:
* Project Explorer: context menu for projects with a .openshift folder: OpenShift->Configure Markers... (and will popup some dialog that allows you to check/uncheck the skip maven build marker)
* Servers view: context menu: OpenShift->Configure Markers...
was (Author: adietish):
we discussed where to put the UI to allow to create the "skip_maven_project" marker for existing projects. We decided that the OpenShift Explorer is not the right place since its focused on the OpenShift server, the remote part. We add the marker in the local clone/project the Explorer would therefore have to look for a matching project for a given/selected OpenShift application. We opted for a context menu in 2 places:
* Project Explorer: context menu for projects with a .openshift folder: OpenShift->Skip Maven Build
* Servers view: context menu: OpenShift->Configure Markers... (and will popup some dialog that allows you to check/uncheck the skip maven build marker)
> Allow users to easily "binary deploy"
> -------------------------------------
>
> Key: JBIDE-13882
> URL: https://issues.jboss.org/browse/JBIDE-13882
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.1.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Max Rydahl Andersen
> Labels: new_and_noteworthy
> Fix For: 4.1.0.Beta2
>
> Attachments: 2013-05-29 13.33.bmml, 2013-05-29 13.33.bmml, 2013-05-29 13.33.bmml, 2013-05-29 13.33.png
>
>
> We should have an option in the wizard that allows easy "binary only" deployment
> {quote}
> 'binary deployment only' option which will go disable the the build marker...but what do we do about the existing project content - just leave it in place I would say.{quote}
--
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
12 years, 10 months
[JBoss JIRA] (JBIDE-13882) Allow users to easily "binary deploy"
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13882?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-13882 at 6/11/13 6:32 PM:
-------------------------------------------------------------------
we discussed where to put the UI to allow to create the "skip_maven_project" marker for existing projects. We decided that the OpenShift Explorer is not the right place since its focused on the OpenShift server, the remote part. We add the marker in the local clone/project the Explorer would therefore have to look for a matching project for a given/selected OpenShift application. We opted for a context menu in 2 places:
* Project Explorer: context menu for projects with a .openshift folder: OpenShift->Skip Maven Build
* Servers view: context menu: OpenShift->Configure Markers... (and will popup some dialog that allows you to check/uncheck the skip maven build marker)
was (Author: adietish):
we discussed where to put the UI to allow to create the "skip_maven_project" marker for existing projects. We decided that the OpenShift Explorer is not the right place since its focused on the OpenShift server, the remote part. We add the marker in the local clone/project the Explorer would therefore have to look for a matching project for a given/selected OpenShift application. We opted for a context menu in 2 places:
* Project Explorer: context menu for projects with a .openshift folder: OpenShift->Skip Maven Build
* Servers view: context menu: OpenShift->Markers->Skip Maven Build
> Allow users to easily "binary deploy"
> -------------------------------------
>
> Key: JBIDE-13882
> URL: https://issues.jboss.org/browse/JBIDE-13882
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.1.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Max Rydahl Andersen
> Labels: new_and_noteworthy
> Fix For: 4.1.0.Beta2
>
> Attachments: 2013-05-29 13.33.bmml, 2013-05-29 13.33.bmml, 2013-05-29 13.33.bmml, 2013-05-29 13.33.png
>
>
> We should have an option in the wizard that allows easy "binary only" deployment
> {quote}
> 'binary deployment only' option which will go disable the the build marker...but what do we do about the existing project content - just leave it in place I would say.{quote}
--
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
12 years, 10 months