[JBoss JIRA] (JBIDE-15392) Add api in server needed for source lookup
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15392?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-15392:
-------------------------------------
The API in my as.classpath code which I am making 100% requires a IRuntime. This is because for servers < 7, we MUST know what configuration they are using. We cannot simply use 'default' as that doesn't make sense if the runtime is customized to 'all' or 'myconfig'.
In AS7, as well, in the future there will be more customizations, and the ability to know what jars are applicable to the server will evolve. It would make no sense to perform these tasks without knowing what IRuntime they apply to.
> Add api in server needed for source lookup
> ------------------------------------------
>
> Key: JBIDE-15392
> URL: https://issues.jboss.org/browse/JBIDE-15392
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven, server
> Reporter: Max Rydahl Andersen
> Assignee: Rob Stryker
>
> As uncovered in https://github.com/jbosstools/jbosstools-central/pull/128/files#L5L120 we got a problem with source lookup code always having to play catchup with server changes.
> We need to define a stable api that can be used here.
> lets outline what api is actually needed and then subjiras for the specifics.
> For me it looks like server lookup needs a few things:
> 0. know exact version of server
> 1. know the file structure of a certain server
> 2. get dir or directories that contain jar that is the "runtime"
> My guess is that #2 might just be sufficient for source code lookup.
> Any comments ?
--
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, 7 months
[JBoss JIRA] (JBIDE-11987) IDE frozen sometimes when jbpm3 process is being deployed on SOA-P 5.3.ER3
by Koen Aers (JIRA)
[ https://issues.jboss.org/browse/JBIDE-11987?page=com.atlassian.jira.plugi... ]
Koen Aers resolved JBIDE-11987.
-------------------------------
Resolution: Out of Date
As there hasn't been any action for this issue and no additional complaints I'm going to resolve this as out-of-date. Feel free to reopen if the issue is still present and stays important after all.
> IDE frozen sometimes when jbpm3 process is being deployed on SOA-P 5.3.ER3
> ---------------------------------------------------------------------------
>
> Key: JBIDE-11987
> URL: https://issues.jboss.org/browse/JBIDE-11987
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jbpm
> Affects Versions: 3.3.0.Beta2-SOA
> Environment: JBDS 5.0.0.Beta3 + SOA-P tooling 5.0.0.Beta2, JDK 1.6.u31, L64
> Reporter: Jiri Peterka
> Assignee: Koen Aers
> Priority: Critical
> Fix For: 4.0.0.Alpha1-SOA
>
> Attachments: ide-td.txt, soap-td.txt
>
>
> During deploying project on SOA-P 5.3.ER3 IDE is unresponsive state for some time and seems unstable. Server seems to be in some not sufficient state sometimes, cannot be stopped correctly. Threaddumps attached. General SOA-P tooling beta2 instability observed. After several tries, server was successfully started and process deployed. After all it doesn't seems very reliable.
--
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, 7 months
[JBoss JIRA] (JBIDE-15368) jbosstools-server has API Compatibility problem
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15368?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-15368:
-------------------------------------
> Now API Tooling complains that classes from org.jboss.ide.eclipse.as.rse.core package are not in public API.
Where is it complaining this? Classes in org.jboss.ide.eclipse.as.rse.core are NOT intended to be public API. Nothing in that package should be used by any other plugin. It is only exported via x-friends to the test plugin. The entire plugin is essentially private.
> jbosstools-server has API Compatibility problem
> -----------------------------------------------
>
> Key: JBIDE-15368
> URL: https://issues.jboss.org/browse/JBIDE-15368
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.1.1.Alpha1
> Reporter: Denis Golovin
> Priority: Blocker
> Labels: api-compatibility
> Fix For: 4.1.1.Alpha1
>
>
> Latest version from jbosstools-server/jbosstools-4.1.x branch has API Compatibility problem:
> "The field org.jboss.ide.eclipse.as.core.util.IJBossToolingConstants.WILDFLY8_MANAGEMENT_PORT_DEFAULT_PORT in an interface that is intended to be implemented or extended has been added".
> According to http://wiki.eclipse.org/Evolving_Java-based_APIs_2
> || Interface change || Conditions || Compatibility ||
> |Add API field|If interface not implementable by Clients | Binary compatible|
> |Add API field|If interface implementable by Clients| Breaks compatibility (2)|
> (2) Adding an API field to an API interface that is implemented by Clients (e.g., a callback, listener, or visitor interface) breaks binary compatibility in a different way. A field added to a superinterface of C may hide an instance field inherited from a superclass of C, causing linking errors to be detected. Because of this fact, it is important to distinguish between API interfaces that Clients should implement from those that Clients should merely use. API interfaces that Clients should implement should not include fields.
--
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, 7 months
[JBoss JIRA] (JBIDE-15368) jbosstools-server has API Compatibility problem
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15368?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-15368:
---------------------------------------
found one more problem with https://github.com/jbosstools/jbosstools-server/blob/jbosstools-4.1.x/as/.... Now API Tooling complains that classes from org.jboss.ide.eclipse.as.rse.core package are not in public API.
> jbosstools-server has API Compatibility problem
> -----------------------------------------------
>
> Key: JBIDE-15368
> URL: https://issues.jboss.org/browse/JBIDE-15368
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.1.1.Alpha1
> Reporter: Denis Golovin
> Priority: Blocker
> Labels: api-compatibility
> Fix For: 4.1.1.Alpha1
>
>
> Latest version from jbosstools-server/jbosstools-4.1.x branch has API Compatibility problem:
> "The field org.jboss.ide.eclipse.as.core.util.IJBossToolingConstants.WILDFLY8_MANAGEMENT_PORT_DEFAULT_PORT in an interface that is intended to be implemented or extended has been added".
> According to http://wiki.eclipse.org/Evolving_Java-based_APIs_2
> || Interface change || Conditions || Compatibility ||
> |Add API field|If interface not implementable by Clients | Binary compatible|
> |Add API field|If interface implementable by Clients| Breaks compatibility (2)|
> (2) Adding an API field to an API interface that is implemented by Clients (e.g., a callback, listener, or visitor interface) breaks binary compatibility in a different way. A field added to a superinterface of C may hide an instance field inherited from a superclass of C, causing linking errors to be detected. Because of this fact, it is important to distinguish between API interfaces that Clients should implement from those that Clients should merely use. API interfaces that Clients should implement should not include fields.
--
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, 7 months
[JBoss JIRA] (JBIDE-14855) p2.mirrorsURL are kept in site metadata after mirroring with format attribute
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14855?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-14855:
----------------------------------------
Unfortunately, I mirrored some of the sites (namely Kepler and webtools) from an older commit of the repository which did not contain the "format" trick. So Kepler SR1 RC1 target-platforms is not a good candidate to verify this fix, and JBT 4.1.1.Alpha1 won't be neither.
This will have to wait for 4.1.1.Alpha2 or 4.2.0.Alpha1.
> p2.mirrorsURL are kept in site metadata after mirroring with format attribute
> -----------------------------------------------------------------------------
>
> Key: JBIDE-14855
> URL: https://issues.jboss.org/browse/JBIDE-14855
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: target-platform
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Fix For: 4.1.1.Alpha2, 4.2.0.Alpha1
>
>
> When we mirror sites using the "format" argument (to keep the original repository layout with .pack.gz as siblings) it also keep the p2.mirrorsURL attribute. This is not bad per se, but since the mirrors are often not correctly sync'd with the Eclipse repositories/our mirrors, it leads to build failure.
> Current workaround is to remove them by end in content.jar and artifact.jar.
> We should think about removing this, for example as part of the remove-references script.
--
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, 7 months
[JBoss JIRA] (JBIDE-14855) p2.mirrorsURL are kept in site metadata after mirroring with format attribute
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14855?page=com.atlassian.jira.plugi... ]
Mickael Istria reassigned JBIDE-14855:
--------------------------------------
Assignee: Mickael Istria (was: Nick Boldt)
> p2.mirrorsURL are kept in site metadata after mirroring with format attribute
> -----------------------------------------------------------------------------
>
> Key: JBIDE-14855
> URL: https://issues.jboss.org/browse/JBIDE-14855
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: target-platform
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.1.1.Alpha2, 4.2.0.Alpha1
>
>
> When we mirror sites using the "format" argument (to keep the original repository layout with .pack.gz as siblings) it also keep the p2.mirrorsURL attribute. This is not bad per se, but since the mirrors are often not correctly sync'd with the Eclipse repositories/our mirrors, it leads to build failure.
> Current workaround is to remove them by end in content.jar and artifact.jar.
> We should think about removing this, for example as part of the remove-references script.
--
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, 7 months
[JBoss JIRA] (JBIDE-14855) p2.mirrorsURL are kept in site metadata after mirroring with format attribute
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14855?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-14855:
-----------------------------------
Fix Version/s: 4.1.1.Alpha2
(was: 4.1.1.Alpha1)
> p2.mirrorsURL are kept in site metadata after mirroring with format attribute
> -----------------------------------------------------------------------------
>
> Key: JBIDE-14855
> URL: https://issues.jboss.org/browse/JBIDE-14855
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: target-platform
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Fix For: 4.1.1.Alpha2, 4.2.0.Alpha1
>
>
> When we mirror sites using the "format" argument (to keep the original repository layout with .pack.gz as siblings) it also keep the p2.mirrorsURL attribute. This is not bad per se, but since the mirrors are often not correctly sync'd with the Eclipse repositories/our mirrors, it leads to build failure.
> Current workaround is to remove them by end in content.jar and artifact.jar.
> We should think about removing this, for example as part of the remove-references script.
--
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, 7 months
[JBoss JIRA] (JBDS-2727) Cheatsheets for JBoss Central archetypes
by Michelle Murray (JIRA)
[ https://issues.jboss.org/browse/JBDS-2727?page=com.atlassian.jira.plugin.... ]
Michelle Murray commented on JBDS-2727:
---------------------------------------
[~maxandersen], the impact on docs of cheat sheets accompanying all JBoss Central archetypes is as follows:
* Any procedures that detail using an archetype wizard will need an extra comment that the cheat sheet opens at the end
* Getting Started Guide = 5.3 Create a Java EE Web Project, add note about cheat sheet opening
* User Guide, JBoss Central chapter =
** 2.1.1 About JBoss Central - add note that project wizards have cheat sheets
** 2.2.3 Access Project Wizards in JBoss Central - add note that projects accompanied by cheat sheet which auto opens in Cheat Sheet tab when wizard completes
** 2.2.8 View Cheat Sheets - add that some/all archetypes in JBoss Central are accompanied by cheat sheets and cheat sheet automatically opens when wizard completes; change example in screen captures to be for a JBoss Central archetype
*** Figure 2.13. Cheat Sheet Open in Cheat Sheets Tab
*** Figure 2.14. Open In Cheat Sheets View Menu Option
> Cheatsheets for JBoss Central archetypes
> ----------------------------------------
>
> Key: JBDS-2727
> URL: https://issues.jboss.org/browse/JBDS-2727
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: central
> Reporter: Burr Sutter
>
> Our archetypes should have cheatsheets when imported/opened into eclipse.
> Priority
> 1) HTML5 - cheatsheet should focus the end-user's attention on index.html, editable in the VPE, with the jQuery Mobile Palette, it should also describe LiveReload setup and BrowserSim
> 2) Java EE Web - cheatsheet should focus the end-user's attention on index.xhtml, editable in the VPE, with the JSF/RichFaces Palette. It should describe the JPA Member.java, the relationship between MemberController.java and index.xhtml, the purpose of MemberResourceRESTService.java and JaxRsActivator.java
> Basically walk the user through the flow of events (from the UI to the backend) in the application
> 3) RichFaces - cheatsheet should focus the end-user's attention on index.xhtml, editable in the VPE, with the JSF/RichFaces Palette. It should also describe resources/components/memberForm.xhtml and its use of <rich:validator/> and that tag's relationship with the JPA beanvalidations
--
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, 7 months