July 2014 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-17942) tycho-plugins 0.19-snapshot is missing

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17942?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-17942: ------------------------------------ Either way people will have to update their poms to move from 0.19.0-SNAPSHOT to 0.19.0 or 0.21.0-SNAPSHOT or 0.21.0. I would suggest we get 0.19.0 released, start a 0.21.0-SNAPSHOT, and get that new 0.21.0 released in a month or so, if nothing wacky happens. > tycho-plugins 0.19-snapshot is missing > -------------------------------------- > > Key: JBIDE-17942 > URL: https://issues.jboss.org/browse/JBIDE-17942 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.2.0.Beta3 > Reporter: Max Rydahl Andersen > Assignee: Mickael Istria > Fix For: 4.2.0.CR1 > > > this morning reports were coming in builds were failing because org.jboss.tools.tycho-plugins:repository-utils:0.19.0-SNAPSHOT was missing. > Turns out https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBo... failed to upload and then https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBo... ran but the machine running thought it was July 12th and not July 14th. > To fix it I respun the build and not the urgent issue is fixed but: > A) Why are we even using snapshots for this JBIDE-17941 > B) Why did the snapshot dissapear/why is jenkins build several days behind. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-17917) copy/paste of server stopped working

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17917?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-17917. --------------------------------- Fix Version/s: 4.2.0.Beta3 Resolution: Cannot Reproduce Bug not able to replicate > copy/paste of server stopped working > ------------------------------------ > > Key: JBIDE-17917 > URL: https://issues.jboss.org/browse/JBIDE-17917 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Reporter: Max Rydahl Andersen > Fix For: 4.2.0.Beta3 > > > create a wildfly 8 server. > Copy and then paste it > see new additional server created. > Assert: possible to start the second server. > Fail: errors at startup as if not all paramters are set. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-17905) Server Adapter: cannot publish commits (only) when there are local changes (can only commit and push)

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17905?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-17905: ------------------------------------------ this is how the new "Publish Changes"-dialog behaves: [^publish-dialog.ogv] > Server Adapter: cannot publish commits (only) when there are local changes (can only commit and push) > ----------------------------------------------------------------------------------------------------- > > Key: JBIDE-17905 > URL: https://issues.jboss.org/browse/JBIDE-17905 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Reporter: Max Rydahl Andersen > Assignee: Andre Dietisheim > Priority: Critical > Labels: server_adapter > Fix For: 4.2.0.CR1 > > Attachments: publish-dialog.ogv > > > # EXEC: Add file test.txt > # EXEC: Commit test.txt > # EXEC: Add file temporary.txt > # EXEC: go to openshift server and publish > # ASSERT: commit dialog shows up > # ASSERT: I can push the new commits without having to do something about temporary.txt > this worked in past, now the new commit dialog prevents me from doing this. > I can use egit push to workaround this but that kinda defeats the purpose of making the server interaction simple via just the "Publish" command. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-17905) Server Adapter: cannot publish commits (only) when there are local changes (can only commit and push)

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17905?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-17905: ------------------------------------- Git Pull Request: https://github.com/jbosstools/jbosstools-openshift/pull/456 (was: https://github.com/jbosstools/jbosstools-openshift/pull/453) > Server Adapter: cannot publish commits (only) when there are local changes (can only commit and push) > ----------------------------------------------------------------------------------------------------- > > Key: JBIDE-17905 > URL: https://issues.jboss.org/browse/JBIDE-17905 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Reporter: Max Rydahl Andersen > Assignee: Andre Dietisheim > Priority: Critical > Labels: server_adapter > Fix For: 4.2.0.CR1 > > Attachments: publish-dialog.ogv > > > # EXEC: Add file test.txt > # EXEC: Commit test.txt > # EXEC: Add file temporary.txt > # EXEC: go to openshift server and publish > # ASSERT: commit dialog shows up > # ASSERT: I can push the new commits without having to do something about temporary.txt > this worked in past, now the new commit dialog prevents me from doing this. > I can use egit push to workaround this but that kinda defeats the purpose of making the server interaction simple via just the "Publish" command. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-17905) Server Adapter: cannot publish commits (only) when there are local changes (can only commit and push)

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17905?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-17905: ------------------------------------- Attachment: publish-dialog.ogv > Server Adapter: cannot publish commits (only) when there are local changes (can only commit and push) > ----------------------------------------------------------------------------------------------------- > > Key: JBIDE-17905 > URL: https://issues.jboss.org/browse/JBIDE-17905 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Reporter: Max Rydahl Andersen > Assignee: Andre Dietisheim > Priority: Critical > Labels: server_adapter > Fix For: 4.2.0.CR1 > > Attachments: publish-dialog.ogv > > > # EXEC: Add file test.txt > # EXEC: Commit test.txt > # EXEC: Add file temporary.txt > # EXEC: go to openshift server and publish > # ASSERT: commit dialog shows up > # ASSERT: I can push the new commits without having to do something about temporary.txt > this worked in past, now the new commit dialog prevents me from doing this. > I can use egit push to workaround this but that kinda defeats the purpose of making the server interaction simple via just the "Publish" command. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-17905) Server Adapter: cannot publish commits (only) when there are local changes (can only commit and push)

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17905?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-17905 at 7/28/14 9:18 AM: ------------------------------------------------------------------- In JBIDE-17190 we started presenting the commit dialog in the initial import and stopped doing an automatic commit. The new dialog allowed people to inspect the changes that the import did and to choose to commit/not commit them before possibly pushing changes back to OpenShift. In the UX review it turned out that the commit dialog was unexpected to the newbie user, he did not understand why he would have to commit changes upon import. In a discussion with [~maxandersen] we now decided to not commit the changes upon import (we'll make them more clever though: JBIDE-17904). This implies that we wont push local changes back to OpenShift automatically (as we we started doing it with JBIDE-13075). I've filed this additional change to JBIDE-17984 was (Author: adietish): In JBIDE-17190 we started presenting the commit dialog in the initial import and stopped doing an automatic commit. The new dialog allowed people to inspect the changes that the import did and to choose to commit/not commit them before possibly pushing changes back to OpenShift. In the UX review it turned out that the commit dialog was unexpected to the newbie user, he did not understand why he would have to commit changes upon import. In a discussion with [~maxandersen] we now decided to not commit the changes upon import (we'll make them more clever though: JBIDE-17904). This implies that we wont push local changes back to OpenShift automatically (as we we started doing it with JBIDE-13075) > Server Adapter: cannot publish commits (only) when there are local changes (can only commit and push) > ----------------------------------------------------------------------------------------------------- > > Key: JBIDE-17905 > URL: https://issues.jboss.org/browse/JBIDE-17905 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Reporter: Max Rydahl Andersen > Assignee: Andre Dietisheim > Priority: Critical > Labels: server_adapter > Fix For: 4.2.0.CR1 > > > # EXEC: Add file test.txt > # EXEC: Commit test.txt > # EXEC: Add file temporary.txt > # EXEC: go to openshift server and publish > # ASSERT: commit dialog shows up > # ASSERT: I can push the new commits without having to do something about temporary.txt > this worked in past, now the new commit dialog prevents me from doing this. > I can use egit push to workaround this but that kinda defeats the purpose of making the server interaction simple via just the "Publish" command. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-17942) tycho-plugins 0.19-snapshot is missing

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17942?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-17942: --------------------------------------------- since 0.19 been used for *ages* would it be more sensible to release a tycho 0.21.0 instead since we moved tycho 0.21 anyway ? integration stack uses the snapshot too hence my worry on impact. > tycho-plugins 0.19-snapshot is missing > -------------------------------------- > > Key: JBIDE-17942 > URL: https://issues.jboss.org/browse/JBIDE-17942 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.2.0.Beta3 > Reporter: Max Rydahl Andersen > Assignee: Mickael Istria > Fix For: 4.2.0.CR1 > > > this morning reports were coming in builds were failing because org.jboss.tools.tycho-plugins:repository-utils:0.19.0-SNAPSHOT was missing. > Turns out https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBo... failed to upload and then https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBo... ran but the machine running thought it was July 12th and not July 14th. > To fix it I respun the build and not the urgent issue is fixed but: > A) Why are we even using snapshots for this JBIDE-17941 > B) Why did the snapshot dissapear/why is jenkins build several days behind. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-17984) Application wizard: dont commit nor push changes back to OpenShift

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17984?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-17984: ------------------------------------- Description: In JBIDE-10541 we added a "Publish Changes" dialog that shows the dirty changes for the local project, allows users to provide a commit msg and to commit/publish changes to OpenShift. This resulted in having a "Publish Changes" dialog popping up after the OpenShift application was imported (application wizard). UX tests revealed that this dialog is disturbing to users, it is pretty much unexpected for them. We could solve this via automatic commit as we did so far but this is very much opaque for the user (discussed it in length with [~maxandersen]). We therefore decided to fully drop any commit and push when doing the initial import. We just process our changes and keep the imported project dirty. The user can then push the changes back to OpenShift via the server adapter. was: In JBIDE-10541 we added a "Publish Changes" dialog that shows the dirty changes for the local project, allows users to provide a commit msg and to commit/publish those. With this in place the application wizard presents a commit dialog in the end and allows users to commit the changes that the import caused. UX tests revealed that this dialog is disturbing to users, it is pretty much unexpected. We also think (discussed it in length with [~maxandersen]) that an automatic commit is not a good thing, it's too much opaque. The logical conclusion is therefore that we process the changes but have no commit nor push back to OpenShift. > Application wizard: dont commit nor push changes back to OpenShift > ------------------------------------------------------------------ > > Key: JBIDE-17984 > URL: https://issues.jboss.org/browse/JBIDE-17984 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.2.0.Beta3 > Reporter: Andre Dietisheim > > In JBIDE-10541 we added a "Publish Changes" dialog that shows the dirty changes for the local project, allows users to provide a commit msg and to commit/publish changes to OpenShift. > This resulted in having a "Publish Changes" dialog popping up after the OpenShift application was imported (application wizard). UX tests revealed that this dialog is disturbing to users, it is pretty much unexpected for them. We could solve this via automatic commit as we did so far but this is very much opaque for the user (discussed it in length with [~maxandersen]). We therefore decided to fully drop any commit and push when doing the initial import. We just process our changes and keep the imported project dirty. The user can then push the changes back to OpenShift via the server adapter. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBDS-3014) On Mac Maverick JVM shared library points to wrong directory

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBDS-3014?page=com.atlassian.jira.plugin.... ] Martin Malina commented on JBDS-3014: ------------------------------------- OK, [~maxandersen], based on your suggestions, I created JBDS-3111 > On Mac Maverick JVM shared library points to wrong directory > ------------------------------------------------------------ > > Key: JBDS-3014 > URL: https://issues.jboss.org/browse/JBDS-3014 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: installer > Affects Versions: 8.0.0.Beta1 > Environment: Mac on Maverick > Reporter: Robb Greathouse > Assignee: Denis Golovin > Priority: Critical > Fix For: 8.0.0.Beta3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The JVM shared library "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/../lib/server/libjvm.dylib" > does not contain the JNI_CreateJavaVM symbol. > This prevents it from starting. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBDS-3111) Improve error for default java on OS X

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBDS-3111?page=com.atlassian.jira.plugin.... ] Martin Malina updated JBDS-3111: -------------------------------- Attachment: default-java.png > Improve error for default java on OS X > -------------------------------------- > > Key: JBDS-3111 > URL: https://issues.jboss.org/browse/JBDS-3111 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: installer > Affects Versions: 8.0.0.Beta3 > Reporter: Martin Malina > Assignee: Denis Golovin > Attachments: default-java.png > > > This is a follow up of JBDS-3014. > When you double click the installer in Finder on OS X, the default java located in /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home will now be rejected with an error because apparently that is just the JRE, not JDK. > But the error is a bit vague. > Max suggested this: > {quote} > Should say something like JDK does not work, need to be a full JDK Java 7 or higher or similar if user point to a broken jdk. > and if the folder does not contain anything it should not make it sound that a JDK is actually there > {quote} > Even better, we could find the location of real JDK and offer that first. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues July 2014