January 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (LOCUS-15) Set version on exported packages

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/LOCUS-15?page=com.atlassian.jira.plugin.s... ] Nick Boldt commented on LOCUS-15: --------------------------------- Slip to 1.5 > Set version on exported packages > -------------------------------- > > Key: LOCUS-15 > URL: https://issues.jboss.org/browse/LOCUS-15 > Project: JBoss Tools Locus > Issue Type: Enhancement > Affects Versions: 1.1.0 > Reporter: Mickael Istria > Priority: Minor > Fix For: 1.5.0 > > > Locus bundles don't specify version for their exports, so they cannot be consumed by other bundles that use Import-Package with a version. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOCUS-47) Locus plug-ins have errors after importing into workspace

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/LOCUS-47?page=com.atlassian.jira.plugin.s... ] Nick Boldt commented on LOCUS-47: --------------------------------- Slip to 1.5 > Locus plug-ins have errors after importing into workspace > --------------------------------------------------------- > > Key: LOCUS-47 > URL: https://issues.jboss.org/browse/LOCUS-47 > Project: JBoss Tools Locus > Issue Type: Enhancement > Reporter: Denis Golovin > Assignee: Denis Golovin > Fix For: 1.5.0 > > > There are several problems with locus plrojects after importing them into workspace as maven projects: > 1. plugins/pom.xml appears in workspace with name "plugins" and it could conflict with other imported modules because we have the same names all over jbosstools; > 2. org.jboss.tools.locus.mockito uses restricted API and JDT reports it as Error; > 3. org.jboss.tools.locus.dmr export packages that created during maven build and reported as missing in eclipse. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOCUS-47) Locus plug-ins have errors after importing into workspace

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/LOCUS-47?page=com.atlassian.jira.plugin.s... ] Nick Boldt updated LOCUS-47: ---------------------------- Fix Version/s: 1.5.0 (was: 1.3.0) > Locus plug-ins have errors after importing into workspace > --------------------------------------------------------- > > Key: LOCUS-47 > URL: https://issues.jboss.org/browse/LOCUS-47 > Project: JBoss Tools Locus > Issue Type: Enhancement > Reporter: Denis Golovin > Assignee: Denis Golovin > Fix For: 1.5.0 > > > There are several problems with locus plrojects after importing them into workspace as maven projects: > 1. plugins/pom.xml appears in workspace with name "plugins" and it could conflict with other imported modules because we have the same names all over jbosstools; > 2. org.jboss.tools.locus.mockito uses restricted API and JDT reports it as Error; > 3. org.jboss.tools.locus.dmr export packages that created during maven build and reported as missing in eclipse. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOCUS-15) Set version on exported packages

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/LOCUS-15?page=com.atlassian.jira.plugin.s... ] Nick Boldt updated LOCUS-15: ---------------------------- Fix Version/s: 1.5.0 (was: 1.3.0) > Set version on exported packages > -------------------------------- > > Key: LOCUS-15 > URL: https://issues.jboss.org/browse/LOCUS-15 > Project: JBoss Tools Locus > Issue Type: Enhancement > Affects Versions: 1.1.0 > Reporter: Mickael Istria > Priority: Minor > Fix For: 1.5.0 > > > Locus bundles don't specify version for their exports, so they cannot be consumed by other bundles that use Import-Package with a version. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOCUS-46) refactor update site zip to new name for consistency with other JBoss artifacts

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/LOCUS-46?page=com.atlassian.jira.plugin.s... ] Nick Boldt commented on LOCUS-46: --------------------------------- [~mickael_istria] Got a preference between these? * jbosstools-1.5.0-<version>-updatesite-locus.zip (current PR) * jbosstools-locus-1.5.0-<version>-updatesite.zip (possibly a better name?) > refactor update site zip to new name for consistency with other JBoss artifacts > ------------------------------------------------------------------------------- > > Key: LOCUS-46 > URL: https://issues.jboss.org/browse/LOCUS-46 > Project: JBoss Tools Locus > Issue Type: Feature Request > Affects Versions: 1.3.0 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 1.5.0 > > > There was a question raised about what to call the update site zip. > It's called *update.site-1.3.0-SNAPSHOT.zip* today [1]. > [1] https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/lo... > If we want a different artifact name / classifier, I can easily do that. Got a preference? > We could do: > * update.site-1.3.0-SNAPSHOT.zip (no change) > * org.jboss.tools.locus-1.3.0-SNAPSHOT-update.site.zip > * jboss-tools-locus-1.3.0-SNAPSHOT-updatesite.zip (consistent w/ JBDS) > * jbosstools-1.3.0-SNAPSHOT-updatesite-locus.zip (consistent w/ JBT) > * ...? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOCUS-46) refactor update site zip to new name for consistency with other JBoss artifacts

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/LOCUS-46?page=com.atlassian.jira.plugin.s... ] Nick Boldt updated LOCUS-46: ---------------------------- Fix Version/s: 1.5.0 (was: 1.3.0) > refactor update site zip to new name for consistency with other JBoss artifacts > ------------------------------------------------------------------------------- > > Key: LOCUS-46 > URL: https://issues.jboss.org/browse/LOCUS-46 > Project: JBoss Tools Locus > Issue Type: Feature Request > Affects Versions: 1.3.0 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 1.5.0 > > > There was a question raised about what to call the update site zip. > It's called *update.site-1.3.0-SNAPSHOT.zip* today [1]. > [1] https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/lo... > If we want a different artifact name / classifier, I can easily do that. Got a preference? > We could do: > * update.site-1.3.0-SNAPSHOT.zip (no change) > * org.jboss.tools.locus-1.3.0-SNAPSHOT-update.site.zip > * jboss-tools-locus-1.3.0-SNAPSHOT-updatesite.zip (consistent w/ JBDS) > * jbosstools-1.3.0-SNAPSHOT-updatesite-locus.zip (consistent w/ JBT) > * ...? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20485) create python script to generate JIRA+email for release steps

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20485?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-20485: ------------------------------------ Do we still want this? Seems to have been replaced by JBIDE-20152 and https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/u... > create python script to generate JIRA+email for release steps > ------------------------------------------------------------- > > Key: JBIDE-20485 > URL: https://issues.jboss.org/browse/JBIDE-20485 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.0.Beta2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Minor > Fix For: 4.3.x > > > In https://github.com/jbdevstudio/jbdevstudio-ci/tree/master/bin we have scripts that generate MULTIPLE JIRAs or generate COMPLICATED JIRAs, but Max and Alexey has requested that we have a script to generate SINGLE Task JIRAs, assigned to project lead so it can be triaged and tracked instead of being lost in mail to individuals / mailing lists. > Create task JIRA to track tagging operation as part of release of JBT; assign to project lead (Alexey) & add watchers (Nick, Mickael, Fred, Max, Denis); send FYI email to jbosstools-dev@ list -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21428) Server adapter: cannot publish, cannot find "oc" executable

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21428?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich commented on JBIDE-21428: ----------------------------------------------- Also, we have to change OpenShiftPreferencePage.performDefaults() because now it changes InstanceScope, but it should refresh (if needed) DefaultScope and then just call super.performDefaults(). I will dare to prepare a pull request. > Server adapter: cannot publish, cannot find "oc" executable > ----------------------------------------------------------- > > Key: JBIDE-21428 > URL: https://issues.jboss.org/browse/JBIDE-21428 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.Beta1 > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Priority: Blocker > Fix For: 4.3.1.Beta2 > > Attachments: could-not-sync-error.png, oc-binary-preferences.png > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21428) Server adapter: cannot publish, cannot find "oc" executable

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21428?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich commented on JBIDE-21428: ----------------------------------------------- It seems I see what is the matter. OpenShiftCorePreferences.INSTANCE.getOCBinaryLocation() looks only into InstanceScope, but initializer puts default value into DefaultScope. Initializer is called at each Eclipse start, so default preference has actual value from $PATH (unless user changes $PATH while Eclipse is open), and anyway default value never finds its way to InstanceScope. If logic of server adapter getting oc binary path should be as you described, then OpenShiftCorePreferences.INSTANCE.getOCBinaryLocation() may look like this {code} public String getOCBinaryLocation() { String result = ocBinaryLocation.get(); if(StringUtils.isEmpty(result)) { result = OCBinaryName.getInstance().getLocation(); } return result; } {code} [~adietish], do you think it may solve the problem? > Server adapter: cannot publish, cannot find "oc" executable > ----------------------------------------------------------- > > Key: JBIDE-21428 > URL: https://issues.jboss.org/browse/JBIDE-21428 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.Beta1 > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Priority: Blocker > Fix For: 4.3.1.Beta2 > > Attachments: could-not-sync-error.png, oc-binary-preferences.png > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21172) CDK server in Starting state and cannot be stopped with wrong path to vagrant (or any other errors)

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21172?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-21172: -------------------------------- Summary: CDK server in Starting state and cannot be stopped with wrong path to vagrant (or any other errors) (was: CDK server in Starting state and cannot be stopped ) > CDK server in Starting state and cannot be stopped with wrong path to vagrant (or any other errors) > --------------------------------------------------------------------------------------------------- > > Key: JBIDE-21172 > URL: https://issues.jboss.org/browse/JBIDE-21172 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.1.Beta1 > Reporter: Martin Malina > Assignee: Rob Stryker > Fix For: 4.3.1.Beta2 > > > When I first set up a CDK 2 Beta3 server adapter in Eclipse, it had the launch config set up with the wrong path to vagrant - /usr/bin/vagrant instead of /usr/local/bin/vagrant which is the default location on OS X - I didn't notice this and just tried to start the adapter. > Obviously it failed, but I was left in a state where the server was Starting and I couldn't stop it unless I restarted the IDE. > I think it should fail more gracefully. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 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 January 2016