December 2014 - jbosstools-issues

[JBoss JIRA] (TOOLSDOC-557) Servers How To: Deploy Apps to Local Servers from the IDE

by Michelle Murray (JIRA)

[ https://issues.jboss.org/browse/TOOLSDOC-557?page=com.atlassian.jira.plug... ] Michelle Murray commented on TOOLSDOC-557: ------------------------------------------ [~aakanksha_writer], peer review complete from me. > Servers How To: Deploy Apps to Local Servers from the IDE > --------------------------------------------------------- > > Key: TOOLSDOC-557 > URL: https://issues.jboss.org/browse/TOOLSDOC-557 > Project: Documentation for JBoss Tools and Developer Studio > Issue Type: Task > Reporter: Michelle Murray > Assignee: Aakanksha Singh > Fix For: 4.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18527) "rm -rf project" in Forge Console doesn't delete project

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18527?page=com.atlassian.jira.plugi... ] Koen Aers commented on JBIDE-18527: ----------------------------------- [~fbricon] I agree that this would be the best solution but as I explained in the PR, there is currently no API to retrieve that information from the issued command. I think that the solution is better than leaving the user with a project that is in a ugly state. Also, normally there should never be any orphaned project so I'm not sure whether this is very harmful. > "rm -rf project" in Forge Console doesn't delete project > -------------------------------------------------------- > > Key: JBIDE-18527 > URL: https://issues.jboss.org/browse/JBIDE-18527 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: forge > Affects Versions: 4.2.0.CR2 > Reporter: Pavol Srna > Assignee: Koen Aers > Priority: Critical > Fix For: 4.2.1.Final, 4.3.0.Alpha1 > > > {code} > org.eclipse.core.internal.resources.ResourceException: Errors occurred while refreshing resources with the local file system. > at org.eclipse.core.internal.localstore.FileSystemResourceManager.refreshResource(FileSystemResourceManager.java:923) > at org.eclipse.core.internal.localstore.FileSystemResourceManager.refresh(FileSystemResourceManager.java:904) > at org.eclipse.core.internal.localstore.FileSystemResourceManager.refreshRoot(FileSystemResourceManager.java:951) > at org.eclipse.core.internal.localstore.FileSystemResourceManager.refresh(FileSystemResourceManager.java:897) > at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1705) > at org.jboss.tools.forge.ui.internal.cli.CommandLineListener.refreshResource(CommandLineListener.java:315) > at org.jboss.tools.forge.ui.internal.cli.CommandLineListener.refresh(CommandLineListener.java:129) > at org.jboss.tools.forge.ui.internal.cli.CommandLineListener.access$2(CommandLineListener.java:126) > at org.jboss.tools.forge.ui.internal.cli.CommandLineListener$1.run(CommandLineListener.java:86) > at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) > at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136) > at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3774) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3412) > at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151) > at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) > at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032) > at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148) > at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636) > at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) > at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) > at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135) > at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) > at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) > at org.eclipse.equinox.launcher.Main.run(Main.java:1465) > at org.eclipse.equinox.launcher.Main.main(Main.java:1438) > Contains: The project description file (.project) for 'jboss-as-kitchensink-html5-mobile' is missing. This file contains important information about the project. The project will not function properly until this file is restored. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-358) Use wrapper features to simplify the install and clean up the Marketplace UI?

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBTIS-358?page=com.atlassian.jira.plugin.... ] Mickael Istria commented on JBTIS-358: -------------------------------------- Do we want those features to be categorized in some p2 repositories? Overall, I think it's good if we have such features because it turns the marketplace entries into something that we can define/build/test more easily. However, I'm afraid that using requires instead of includes makes that updating this feature wouldn't automatically update it's referenced bundles/features unless we constrain the version range strictly enough. But constraining the version range of a require would more or less produce the same issues than using includes. I'm concerned about the multiplication of features being a potential cause for installation conflicts, rather than a solution. > Use wrapper features to simplify the install and clean up the Marketplace UI? > ----------------------------------------------------------------------------- > > Key: JBTIS-358 > URL: https://issues.jboss.org/browse/JBTIS-358 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: distribution > Affects Versions: 7.0.3.GA > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 7.1.0.GA-JBDSIS > > Attachments: is-marketplace1.png, is-marketplace2.png > > > For 7.1.0, could consider having wrapper features to simplify the install and clean up the Marketplace UI. Doing so would mean instead of a laundry list of features in the UI, we could list only 3 features. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18869) migrate Thym from TP to being an aggregated component

by Nick Boldt (JIRA)

Nick Boldt created JBIDE-18869: ---------------------------------- Summary: migrate Thym from TP to being an aggregated component Key: JBIDE-18869 URL: https://issues.jboss.org/browse/JBIDE-18869 Project: Tools (JBoss Tools) Issue Type: Bug Components: aerogear-hybrid, build, target-platform, updatesite Affects Versions: 4.2.0.Final Reporter: Nick Boldt Because Thym changes frequently, and because Gorkem runs the project, we should treat it like a JBT project, not part of the TP. This would allow it to be incorporated into builds more easily and would avoid TP churn. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18869) migrate Thym from TP to being an aggregated component

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18869?page=com.atlassian.jira.plugi... ] Nick Boldt reassigned JBIDE-18869: ---------------------------------- Assignee: Nick Boldt > migrate Thym from TP to being an aggregated component > ----------------------------------------------------- > > Key: JBIDE-18869 > URL: https://issues.jboss.org/browse/JBIDE-18869 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, build, target-platform, updatesite > Affects Versions: 4.2.0.Final > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > Because Thym changes frequently, and because Gorkem runs the project, we should treat it like a JBT project, not part of the TP. > This would allow it to be incorporated into builds more easily and would avoid TP churn. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18869) migrate Thym from TP to being an aggregated component

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18869?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-18869: ------------------------------- Fix Version/s: 4.2.2.Final 4.3.0.Alpha1 > migrate Thym from TP to being an aggregated component > ----------------------------------------------------- > > Key: JBIDE-18869 > URL: https://issues.jboss.org/browse/JBIDE-18869 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, build, target-platform, updatesite > Affects Versions: 4.2.0.Final > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > Because Thym changes frequently, and because Gorkem runs the project, we should treat it like a JBT project, not part of the TP. > This would allow it to be incorporated into builds more easily and would avoid TP churn. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18869) migrate Thym from TP to being an aggregated component

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18869?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-18869: ------------------------------- Description: Because Thym changes frequently, and because Gorkem runs the project, we should treat it like a JBT project, not part of the TP. This would allow it to be incorporated into builds more easily and would avoid TP churn. This should be fixed in master then backported for 4.2.2 (or 4.2.3). was: Because Thym changes frequently, and because Gorkem runs the project, we should treat it like a JBT project, not part of the TP. This would allow it to be incorporated into builds more easily and would avoid TP churn. > migrate Thym from TP to being an aggregated component > ----------------------------------------------------- > > Key: JBIDE-18869 > URL: https://issues.jboss.org/browse/JBIDE-18869 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, build, target-platform, updatesite > Affects Versions: 4.2.0.Final > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > Because Thym changes frequently, and because Gorkem runs the project, we should treat it like a JBT project, not part of the TP. > This would allow it to be incorporated into builds more easily and would avoid TP churn. > This should be fixed in master then backported for 4.2.2 (or 4.2.3). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3208) reorg/refactor directories for consistency across JBT/JBDS

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBDS-3208: ---------------------------------- I don't understand. Where should /targetplatforms/ be located? Under /updates/ ? > reorg/refactor directories for consistency across JBT/JBDS > ---------------------------------------------------------- > > Key: JBDS-3208 > URL: https://issues.jboss.org/browse/JBDS-3208 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: build > Affects Versions: 9.0.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 9.0.0.Alpha1 > > > Be it resolved - we should reorg directories for consistency across JBT/JBDS: > {code} > download.jboss.org > <earlyaccess,updates,discovery>/mars > /snapshots [replace nightly] > /staging [rename content for QE, moves to development when approved] > /development > /stable (updates/mars/stable is a pointer back into updates/mars) > drop /integration (not used) > builds/<jobname>/<buildid> > builds/<jobname>/composite*.xml for last 2 builds > targetplatforms/<type>/<version> > {code} > and > {code} > devstudio.redhat.com > <earlyaccess,updates,discovery>/9.0 > /snapshots > /staging > /development > /stable (updates/9.0/stable is a pointer back into updates/9.0) > builds/<jobname>/<buildid> > builds/<jobname>/composite*.xml for last 2 builds > targetplatforms/<type>/<version> > {code} > Further discussion in http://ether-man.rhcloud.com/p/build.next.20141112 > This would remove the idea of the composite staging site [1] and the composite install job [2], today used to determine when it's time to run the aggregate builds, in favour of a new p2diff mechanism for determining if aggregates should be published. See JBIDE-18742 and JBIDE-16970. > [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.2.... > [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-358) Use wrapper features to simplify the install and clean up the Marketplace UI?

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBTIS-358?page=com.atlassian.jira.plugin.... ] Nick Boldt edited comment on JBTIS-358 at 12/3/14 8:48 PM: ----------------------------------------------------------- So here's another approach to managing these wrapper features: generating the feature.xml (a simple list of contained features) from the <connectorDescriptor> in the discovery plugin.xml file. https://github.com/jbosstools/jbosstools-integration-stack/pull/255 What this does: * creates a boilerplate feature.xml that can then be committed to github What this does not do: * pull the connector name or description (though that could be done easily) and insert that into the feature.xml * generate feature.properties (using values from the plugin.xml) * generate pom.xml (using values from the plugin.xml) * generate generic build.properties, license.html * merge in a static list of other required features (ie., JBDS/JBT/Eclipse dependencies) let me know if any of the above additional features are of value, or if simply having the list of features is enough. I believe this simple tool would allow us to commit features to github (eg., similar to those in https://github.com/jbosstools/jbosstools-integration-stack/pull/249 ), then update them as needed should new ones be added to the Discovery plugin or the contents of existing ones change. But we could make it more complicated and snazzy if needed. :) Feedback welcome, [~maxandersen] [~pleacu]. Also, if [~mickael_istria] knows a way to call the same build plugin N times (to generate N feature.xml files from the same maven reactor) I'd love to know how to do that. Played with the iterator plugin ( http://khmarbaise.github.io/iterator-maven-plugin/ ) but it didn't work for me - didn't understand what a transformationSet was. was (Author: nickboldt): So here's another approach to managing these wrapper features: generating the feature.xml (a simple list of contained features) from the <connectorDescriptor> in the discovery plugin.xml file. https://github.com/jbosstools/jbosstools-integration-stack/pull/255 What this does: * creates a boilerplate feature.xml that can then be committed to github What this does not do: * pull the connector name or description (though that could be done easily) and insert that into the feature.xml * generate feature.properties (using values from the plugin.xml) * generate pom.xml (using values from the plugin.xml) * generate generic build.properties, license.html * merge in a static list of other required features (ie., JBDS/JBT/Eclipse dependencies) let me know if any of the above additional features are of value, or if simply having the list of features is enough. I believe this simple tool would allow us to commit features to github, then update them as needed should new ones be added to the Discovery plugin or the contents of existing ones change. But we could make it more complicated and snazzy if needed. :) Feedback welcome, [~maxandersen] [~pleacu]. Also, if [~mickael_istria] knows a way to call the same build plugin N times (to generate N feature.xml files from the same maven reactor) I'd love to know how to do that. Played with the iterator plugin ( http://khmarbaise.github.io/iterator-maven-plugin/ ) but it didn't work for me - didn't understand what a transformationSet was. > Use wrapper features to simplify the install and clean up the Marketplace UI? > ----------------------------------------------------------------------------- > > Key: JBTIS-358 > URL: https://issues.jboss.org/browse/JBTIS-358 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: distribution > Affects Versions: 7.0.3.GA > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 7.1.0.GA-JBDSIS > > Attachments: is-marketplace1.png, is-marketplace2.png > > > For 7.1.0, could consider having wrapper features to simplify the install and clean up the Marketplace UI. Doing so would mean instead of a laundry list of features in the UI, we could list only 3 features. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-358) Use wrapper features to simplify the install and clean up the Marketplace UI?

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBTIS-358?page=com.atlassian.jira.plugin.... ] Nick Boldt edited comment on JBTIS-358 at 12/3/14 8:46 PM: ----------------------------------------------------------- So here's another approach to managing these wrapper features: generating the feature.xml (a simple list of contained features) from the <connectorDescriptor> in the discovery plugin.xml file. https://github.com/jbosstools/jbosstools-integration-stack/pull/255 What this does: * creates a boilerplate feature.xml that can then be committed to github What this does not do: * pull the connector name or description (though that could be done easily) and insert that into the feature.xml * generate feature.properties (using values from the plugin.xml) * generate pom.xml (using values from the plugin.xml) * generate generic build.properties, license.html * merge in a static list of other required features (ie., JBDS/JBT/Eclipse dependencies) let me know if any of the above additional features are of value, or if simply having the list of features is enough. I believe this simple tool would allow us to commit features to github, then update them as needed should new ones be added to the Discovery plugin or the contents of existing ones change. But we could make it more complicated and snazzy if needed. :) Feedback welcome, [~maxandersen] [~pleacu]. Also, if [~mickael_istria] knows a way to call the same build plugin N times (to generate N feature.xml files from the same maven reactor) I'd love to know how to do that. Played with the iterator plugin ( http://khmarbaise.github.io/iterator-maven-plugin/ ) but it didn't work for me - didn't understand what a transformationSet was. was (Author: nickboldt): So here's another approach to managing these wrapper features: generating the feature.xml (a simple list of contained features) from the <connectorDescriptor> in the discovery plugin.xml file. https://github.com/jbosstools/jbosstools-integration-stack/pull/255 What this does: * creates a boilerplate feature.xml that can then be committed to github What this does not do: * pull the connector name or description (though that could be done easily) and insert that into the feature.xml * generate feature.properties (using values from the plugin.xml) * generate pom.xml (using values from the plugin.xml) * generate generic build.properties, license.html * merge in a static list of other required features (ie., JBDS/JBT/Eclipse dependencies) let me know if any of the above additional features are of value, or if simply having the list of features is enough. I believe this simple tool would allow us to commit features to github, then update them as needed should new ones be added to the Discovery plugin or the contents of existing ones change. But we could make it more complicated and snazzy if needed. :) > Use wrapper features to simplify the install and clean up the Marketplace UI? > ----------------------------------------------------------------------------- > > Key: JBTIS-358 > URL: https://issues.jboss.org/browse/JBTIS-358 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: distribution > Affects Versions: 7.0.3.GA > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 7.1.0.GA-JBDSIS > > Attachments: is-marketplace1.png, is-marketplace2.png > > > For 7.1.0, could consider having wrapper features to simplify the install and clean up the Marketplace UI. Doing so would mean instead of a laundry list of features in the UI, we could list only 3 features. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues December 2014