[JBoss JIRA] (JBDS-2753) Merge "Google Plugin + Web Toolkit" + "Google Web Toolkit Designer"
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2753?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-2753:
-------------------------------------------
I recalled it more like GWT + Window Designer was a much bigger dependency set, but otherwise I don't think there is a enduser reason to keep the split.
There is though the need to ensure that any quickstarts/archetypes that declare they need GWT still has that connector id available.
[~fbricon] I can see the "Gwt Web PRoject" archetype suggest it needs Google Eclipse plugin - which connector id is that using ?
> Merge "Google Plugin + Web Toolkit" + "Google Web Toolkit Designer"
> -------------------------------------------------------------------
>
> Key: JBDS-2753
> URL: https://issues.jboss.org/browse/JBDS-2753
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: build
> Reporter: Burr Sutter
> Attachments: 2013-09-04_1215.png
>
>
> See screenshot.
> Do we need to keep the two Google Web Toolkit options separate? They were separated because they came in at different intervals, now it is unclear to me if they need to remain separate.
--
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-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:
-------------------------------------
> Don't you need to know the list of module path that are to be loaded too for AS >= 7
Currently we load specific hand-chosen folders for as >= 7, and we do not use any configuration information to discover these.
I've been adjusting my patch to allow for an additional entry point with a Map<String, String> where things such as the configuration folder may be passed in. We usually get this from the runtime object, but in the case of just a server home, this isn't possible, and so we will depend on a map of string properties passed in to override or default these values.
> 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] (JBDS-2734) Forge 2 in JBDS
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2734?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-2734:
-------------------------------------------
about hotkeys etc. the optimal would be if this hotkey could detect what the current project/selection is using and if not possible show the option for forge 1 or 2 and allow user to remember that choice.
The beauty of that is projects using forge 1 would trigger forge 1 even if forge 2 is the default.
But not sure you have a way to consistently know these ?
Another aspect is the current Forge1 exposed wizards - should these stay (preventing having some that uses latest forge2) or is it possible to implement equivalent/better for forge 2 by November ?
> Forge 2 in JBDS
> ---------------
>
> Key: JBDS-2734
> URL: https://issues.jboss.org/browse/JBDS-2734
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: forge
> Reporter: Burr Sutter
>
> Is Forge 2 ready to be included in JBDS ?
--
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-15433) mvn/tycho does not bump version in site/category.xml
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15433?page=com.atlassian.jira.plugi... ]
Xavier Coulon commented on JBIDE-15433:
---------------------------------------
[~mickael_istria]
category.xml contained explicitely version 1.1.0 for the feature:
https://github.com/jbosstools/jbosstools-livereload/commit/6561e1d4a84ac0...
> mvn/tycho does not bump version in site/category.xml
> ----------------------------------------------------
>
> Key: JBIDE-15433
> URL: https://issues.jboss.org/browse/JBIDE-15433
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Xavier Coulon
>
> After running the following command on the livereload component:
> {code}
> mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=1.2.0-SNAPSHOT
> {code}
> I could see that all pom.xml, feature.xml and MANIFEST.xml were updated, but not the site/category.xml which I had to edit myself (mvn clean verify failed)
> {code}
> <site>
> <feature url="features/org.jboss.tools.livereload.feature_1.2.0.qualifier.jar" id="org.jboss.tools.livereload.feature" version="1.2.0.qualifier"/>
> <feature url="features/org.jboss.tools.livereload.feature.source_1.2.0.qualifier.jar" id="org.jboss.tools.livereload.feature.source" version="1.2.0.qualifier"/>
> </site>
> {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
12 years, 7 months
[JBoss JIRA] (JBIDE-15433) mvn/tycho does not bump version in site/category.xml
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15433?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-15433:
----------------------------------------
It depends on what was written in the category.xml file...
[~xcoulon] Did it actually happen that versions in category.xml were different from version in feature.xml ?
> mvn/tycho does not bump version in site/category.xml
> ----------------------------------------------------
>
> Key: JBIDE-15433
> URL: https://issues.jboss.org/browse/JBIDE-15433
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Xavier Coulon
>
> After running the following command on the livereload component:
> {code}
> mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=1.2.0-SNAPSHOT
> {code}
> I could see that all pom.xml, feature.xml and MANIFEST.xml were updated, but not the site/category.xml which I had to edit myself (mvn clean verify failed)
> {code}
> <site>
> <feature url="features/org.jboss.tools.livereload.feature_1.2.0.qualifier.jar" id="org.jboss.tools.livereload.feature" version="1.2.0.qualifier"/>
> <feature url="features/org.jboss.tools.livereload.feature.source_1.2.0.qualifier.jar" id="org.jboss.tools.livereload.feature.source" version="1.2.0.qualifier"/>
> </site>
> {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
12 years, 7 months