June 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBDS-3955) add more obvious license terms to jbdevstudio-product project in github

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3955?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-3955: ----------------------------- Fix Version/s: 10.0.1.S116 > add more obvious license terms to jbdevstudio-product project in github > ----------------------------------------------------------------------- > > Key: JBDS-3955 > URL: https://issues.jboss.org/browse/JBDS-3955 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Bug > Components: build > Affects Versions: 10.0.0.GA > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 10.0.1.S116 > > > In order to adhere to https://trello.com/c/b3T54vn5/98-remove-jbds-sources-zip-from-list-of-del... we probably need to fluff up the license terms in the devstudio product repo in github so it's more obvious that the license is EPL. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3955) add more obvious license terms to jbdevstudio-product project in github

by CDW Engine (JIRA)

[ https://issues.jboss.org/browse/JBDS-3955?page=com.atlassian.jira.plugin.... ] CDW Engine updated JBDS-3955: ----------------------------- > add more obvious license terms to jbdevstudio-product project in github > ----------------------------------------------------------------------- > > Key: JBDS-3955 > URL: https://issues.jboss.org/browse/JBDS-3955 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Bug > Components: build > Affects Versions: 10.0.0.GA > Reporter: Nick Boldt > Assignee: Nick Boldt > > In order to adhere to https://trello.com/c/b3T54vn5/98-remove-jbds-sources-zip-from-list-of-del... we probably need to fluff up the license terms in the devstudio product repo in github so it's more obvious that the license is EPL. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3955) add more obvious license terms to jbdevstudio-product project in github

by Nick Boldt (JIRA)

Nick Boldt created JBDS-3955: -------------------------------- Summary: add more obvious license terms to jbdevstudio-product project in github Key: JBDS-3955 URL: https://issues.jboss.org/browse/JBDS-3955 Project: Red Hat JBoss Developer Studio (devstudio) Issue Type: Bug Components: build Affects Versions: 10.0.0.GA Reporter: Nick Boldt Assignee: Nick Boldt In order to adhere to https://trello.com/c/b3T54vn5/98-remove-jbds-sources-zip-from-list-of-del... we probably need to fluff up the license terms in the devstudio product repo in github so it's more obvious that the license is EPL. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22578) Publishing sometimes recursively deletes parent to deploy directory

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22578?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-22578: -------------------------------- Priority: Blocker (was: Critical) > Publishing sometimes recursively deletes parent to deploy directory > ------------------------------------------------------------------- > > Key: JBIDE-22578 > URL: https://issues.jboss.org/browse/JBIDE-22578 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.3.1.Final > Environment: Eclipse Mars.2 Release (4.5.2) > Java 1.8.0_91 > Windows 7 64-bit > JBoss EAP 6.4.0 > Reporter: Daniel Atallah > Assignee: Rob Stryker > Priority: Blocker > Fix For: 4.4.1.S116 > > Attachments: jboss_deployment.jpg, servers.xml > > > For a number of weeks we've had a number of occurrences where a eclipse workspace will get corrupted due to the deletion of all files in it. > It seems to have started happening at the time we updated to the 4.3.1 JBoss Tools from the 4.3.0 JBoss Tools. > We've been able to track the process doing the deleting to the Eclipse process by using Sysinternals Process Monitor tool (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx). > Our workspaces are structured as follows: > {noformat} > WORKSPACEROOT=$DEVROOT\workspacename > # Custom deploy folder (as specified in the "Deployment" settings for the configured "Red Hat JBoss Enterprise Application Platform 6.1+") Server > $WORKSPACEROOT\deploy > # Version Control (Mercurial) working directory containing various Eclipse projects that get published to the Server by the tooling > $WORKSPACEROOT\src > # value specified as a "jboss.server.data.dir" property in the Server launch configuration VM arguments > $WORKSPACEROOT/server/data > # value specified as a "jboss.server.temp.dir" property in the Server launch configuration VM arguments > $WORKSPACEROOT/server/tmp > {noformat} > The Server is configured to "Automatically publish when resources change". > What we're seeing is that occasionally when the Server is running and the Mercurial working copy receives updates, the Incremental Publishing that results from these updates somehow tries to recursively delete $WORKSPACEROOT. > The eclipse log includes the following: > {noformat} > !ENTRY org.eclipse.core.resources 4 1 2016-06-07 16:05:57.795 > !MESSAGE Problems occurred refreshing resources > !SUBENTRY 1 org.eclipse.core.resources 4 1 2016-06-07 16:05:57.795 > !MESSAGE Problem finding next change, code: 5 > !ENTRY org.jboss.ide.eclipse.as.core 4 1644298244 2016-06-07 16:06:09.207 > !MESSAGE Incremental publish failed for module $MODULENAME > !SUBENTRY 1 org.jboss.ide.eclipse.as.wtp.core 4 1644298251 2016-06-07 16:06:09.207 > !MESSAGE Could not delete $WORKSPACEROOT. May be locked by another process. > {noformat} > Any idea what might be happening? > Is there some debug logging we can enable to get better visibility to what's going on? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-22619: ------------------------------------ Sprint details are hardly internal. Check this out: https://issues.jboss.org/projects/JBIDE?selectedItem=com.atlassian.jira.j... (note the releases have start/end dates, which align with sprint start/end dates). Or here: https://issues.jboss.org/secure/RapidBoard.jspa?projectKey=JBIDE&rapidVie... where the sprint start/end dates have been added (by me) into the sprint NAMES so they're easier to use, particularly if you're adding backlog items to future sprints. Also, since EVERY sprint == a new release, 4.4.1.S116 is just as meaningful as 4.4.1.Alpha1, but one implies quality while the other simply states when it was released. "I rather see the Alpha/Beta/CR... as an indicator of when it's shipped, not about quality." How is Alpha an indicator of WHEN, but not of quality? > Decide strategy for fixversion targets in JIRA > ---------------------------------------------- > > Key: JBIDE-22619 > URL: https://issues.jboss.org/browse/JBIDE-22619 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.4.1.S116 > Reporter: Nick Boldt > Assignee: Alexey Kazakov > Fix For: 4.4.1.S116 > > > We need to decide the strategy for milestones / fixversions in JIRA. > One suggestion has been to align fixversions w/ sprint numbers, thus: > * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...? > instead of > * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ? > Questions/concerns: > * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies? > * whatever schema we adopt has to work with bzira and jiralint > * any other systems that parse JIRA for integration purposes? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-22619: ---------------------------------------- {quote}And for JBDS issues, we also have a Target version (the GA release in which the JIRA will be done, even if fixed in an earlier milestone). So that's THREE places we're setting the same information.{quote} Is it really the same information? As far as I understood, sprints are internal information, Alpha/Beta are public and user facing ones. {quote}So now the parent pom doesn't have to contain an Alpha/Beta quality-descriptor - {quote} Step by step, let's just first have the jgit build timestamps, then we'll consider removing versions from parent pom. IMO discussing about parent pom release and so on should be postponed after we move to jgit timestamps as it's going to be a major change. {quote}we only care about WHEN it's being built, not HOW GOOD it is.{quote} I rather see the Alpha/Beta/CR... as an indicator of when it's shipped, not about quality. > Decide strategy for fixversion targets in JIRA > ---------------------------------------------- > > Key: JBIDE-22619 > URL: https://issues.jboss.org/browse/JBIDE-22619 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.4.1.S116 > Reporter: Nick Boldt > Assignee: Alexey Kazakov > Fix For: 4.4.1.S116 > > > We need to decide the strategy for milestones / fixversions in JIRA. > One suggestion has been to align fixversions w/ sprint numbers, thus: > * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...? > instead of > * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ? > Questions/concerns: > * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies? > * whatever schema we adopt has to work with bzira and jiralint > * any other systems that parse JIRA for integration purposes? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22578) Publishing sometimes recursively deletes parent to deploy directory

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22578?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-22578: ------------------------------------- [~datallah] Hi Daniel: I just tested the instructions I provided. These instructions do not add further output to the log file, or to the error log view. Instead, it just prints extra output to the console. So you may need to launch eclipse from a terminal. =/ Hope this helps. Let me know if it doesn't work. > Publishing sometimes recursively deletes parent to deploy directory > ------------------------------------------------------------------- > > Key: JBIDE-22578 > URL: https://issues.jboss.org/browse/JBIDE-22578 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.3.1.Final > Environment: Eclipse Mars.2 Release (4.5.2) > Java 1.8.0_91 > Windows 7 64-bit > JBoss EAP 6.4.0 > Reporter: Daniel Atallah > Assignee: Rob Stryker > Priority: Critical > Fix For: 4.4.1.S116 > > Attachments: jboss_deployment.jpg, servers.xml > > > For a number of weeks we've had a number of occurrences where a eclipse workspace will get corrupted due to the deletion of all files in it. > It seems to have started happening at the time we updated to the 4.3.1 JBoss Tools from the 4.3.0 JBoss Tools. > We've been able to track the process doing the deleting to the Eclipse process by using Sysinternals Process Monitor tool (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx). > Our workspaces are structured as follows: > {noformat} > WORKSPACEROOT=$DEVROOT\workspacename > # Custom deploy folder (as specified in the "Deployment" settings for the configured "Red Hat JBoss Enterprise Application Platform 6.1+") Server > $WORKSPACEROOT\deploy > # Version Control (Mercurial) working directory containing various Eclipse projects that get published to the Server by the tooling > $WORKSPACEROOT\src > # value specified as a "jboss.server.data.dir" property in the Server launch configuration VM arguments > $WORKSPACEROOT/server/data > # value specified as a "jboss.server.temp.dir" property in the Server launch configuration VM arguments > $WORKSPACEROOT/server/tmp > {noformat} > The Server is configured to "Automatically publish when resources change". > What we're seeing is that occasionally when the Server is running and the Mercurial working copy receives updates, the Incremental Publishing that results from these updates somehow tries to recursively delete $WORKSPACEROOT. > The eclipse log includes the following: > {noformat} > !ENTRY org.eclipse.core.resources 4 1 2016-06-07 16:05:57.795 > !MESSAGE Problems occurred refreshing resources > !SUBENTRY 1 org.eclipse.core.resources 4 1 2016-06-07 16:05:57.795 > !MESSAGE Problem finding next change, code: 5 > !ENTRY org.jboss.ide.eclipse.as.core 4 1644298244 2016-06-07 16:06:09.207 > !MESSAGE Incremental publish failed for module $MODULENAME > !SUBENTRY 1 org.jboss.ide.eclipse.as.wtp.core 4 1644298251 2016-06-07 16:06:09.207 > !MESSAGE Could not delete $WORKSPACEROOT. May be locked by another process. > {noformat} > Any idea what might be happening? > Is there some debug logging we can enable to get better visibility to what's going on? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22621) Server adapter wizard: should be able to import projects to my workspace

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22621?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22621: ------------------------------------- Attachment: no-workspace-project-exists.png > Server adapter wizard: should be able to import projects to my workspace > ------------------------------------------------------------------------ > > Key: JBIDE-22621 > URL: https://issues.jboss.org/browse/JBIDE-22621 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.0.Final > Reporter: Andre Dietisheim > Labels: openshift_v3, server_adapter_wizard > Fix For: 4.4.x > > Attachments: no-workspace-project-exists.png > > > steps to reproduce: > # ASSERT: have empty workspace > # ASSERT: have at least 1 service in OpenShift > # EXEC: in OpenShift explorer: launch server adapter wizard from context menu of your service > Result: > The Eclipse project text field is erroring and nothing to select, since you have no project in your workspace yet. > !no-workspace-project-exists.png! > There's no way for the user to import a project from OpenShift to the workspace in this wizard. One has to close the wizard and head over to the import wizard first and get back. > Expected result: > I should have a link to the right of "Browse.." which allows me to import a project. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-22619: ------------------------------------ Purpose here as Max states is to make overhead less. We're now setting a fixversion AND a sprint #, which mean the same thing but require two steps / two labels. So why do we need both? And for JBDS issues, we also have a Target version (the GA release in which the JIRA will be done, even if fixed in an earlier milestone). So that's THREE places we're setting the same information. Then, when we move shortly to use jgit timestamps (JBIDE-13671), we eliminate the need for BUILD_ALIAS (for everything except the 2 plugins used to define the "version" of JBT/devstudio in ide-config.properties). So now the parent pom doesn't have to contain an Alpha/Beta quality-descriptor - we only care about WHEN it's being built, not HOW GOOD it is. Otherwise we will end up concocting arbitrary (and probably wrong) qualifiers like Alpha1, Alpha2, Alpha3 in JIRA just so as to differentiate between sprint releases. Does everyone remember when we were building toward Alpha3 and it was suddenly renamed to Final because we needed to make it a GA release ? Ah, good (confusing) times. > Decide strategy for fixversion targets in JIRA > ---------------------------------------------- > > Key: JBIDE-22619 > URL: https://issues.jboss.org/browse/JBIDE-22619 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Affects Versions: 4.4.1.S116 > Reporter: Nick Boldt > Assignee: Alexey Kazakov > Fix For: 4.4.1.S116 > > > We need to decide the strategy for milestones / fixversions in JIRA. > One suggestion has been to align fixversions w/ sprint numbers, thus: > * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...? > instead of > * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ? > Questions/concerns: > * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies? > * whatever schema we adopt has to work with bzira and jiralint > * any other systems that parse JIRA for integration purposes? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22621) Server adapter wizard: should be able to import projects to my workspace

by Andre Dietisheim (JIRA)

Andre Dietisheim created JBIDE-22621: ---------------------------------------- Summary: Server adapter wizard: should be able to import projects to my workspace Key: JBIDE-22621 URL: https://issues.jboss.org/browse/JBIDE-22621 Project: Tools (JBoss Tools) Issue Type: Enhancement Components: openshift Affects Versions: 4.4.0.Final Reporter: Andre Dietisheim steps to reproduce: # ASSERT: have empty workspace # ASSERT: have at least 1 service in OpenShift # EXEC: in OpenShift explorer: launch server adapter wizard from context menu of your service Result: The Eclipse project text field is erroring and nothing to select, since you have no project in your workspace yet. !no-workspace-project-exists.png! There's no way for the user to import a project from OpenShift to the workspace in this wizard. One has to close the wizard and head over to the import wizard first and get back. Expected result: I should have a link to the right of "Browse.." which allows me to import a project. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 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 June 2016