May 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-11371) Move JBoss Quickstarts from developers workspace in svn somewhere else (maybe download.jboss.org/jbosstools/examples)

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-11371?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-11371: -------------------------------- Fix Version/s: LATER (was: 4.4.x) > Move JBoss Quickstarts from developers workspace in svn somewhere else (maybe download.jboss.org/jbosstools/examples) > --------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-11371 > URL: https://issues.jboss.org/browse/JBIDE-11371 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: central, project-examples > Affects Versions: 3.3.0.Beta1 > Reporter: Radim Hopp > Assignee: Fred Bricon > Priority: Critical > Fix For: LATER > > > Now, quicksarts are being downloaded from http://anonsvn.jboss.org/repos/jbosstools/workspace/snjeza/jbossas7-examp.... Wouldn't be better to have them somewhere else? > Maybe put the quickstarts to https://svn.jboss.org/repos/jbosstools/trunk/download.jboss.org/jbosstool... for automatic push to download.jboss.org? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18925) Choose a default target server runtime as the latest available

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18925?page=com.atlassian.jira.plugi... ] Fred Bricon reassigned JBIDE-18925: ----------------------------------- Assignee: (was: Fred Bricon) > Choose a default target server runtime as the latest available > -------------------------------------------------------------- > > Key: JBIDE-18925 > URL: https://issues.jboss.org/browse/JBIDE-18925 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: central, project-examples > Reporter: Marek Novotny > Fix For: 4.4.x > > > This suggestion for enhancement distilled from JBDS-3240 comments. > The creating of new project from Maven archetype (Start from Scratch in JBoss Central) is the starting point. > Could a runtime in the Target runtime field be set by default (the latest is the best) from available runtimes ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-10120) find a way to display a project example once when several versions targeted for different runtimes exist

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-10120?page=com.atlassian.jira.plugi... ] Fred Bricon reassigned JBIDE-10120: ----------------------------------- Assignee: (was: Fred Bricon) > find a way to display a project example once when several versions targeted for different runtimes exist > -------------------------------------------------------------------------------------------------------- > > Key: JBIDE-10120 > URL: https://issues.jboss.org/browse/JBIDE-10120 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: project-examples > Affects Versions: 3.3.0.M3 > Reporter: Fred Bricon > Labels: eap6-ux > Fix For: 4.4.x > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Given the upcoming (40+) new quickstart projects, we'll most likely have duplicates between the community and enterprise versions. > In order to reduce the amount of quickstarts in the Project Examples UI, in addtion to adding a Runtime filter (JBIDE-10119), > we could also regroup similar projects under one entry. So, for example, instead of seeing 2 entries for kitchensink (community) and kitchensink (eap6) > We could display only one kitchensink entry in the UI, and upon selection, choose the actual version / target runtime we want to create. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22278) Explorer: should be made visible when a new Connection is created

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22278?page=com.atlassian.jira.plugi... ] Fred Bricon reassigned JBIDE-22278: ----------------------------------- Assignee: Fred Bricon > Explorer: should be made visible when a new Connection is created > ----------------------------------------------------------------- > > Key: JBIDE-22278 > URL: https://issues.jboss.org/browse/JBIDE-22278 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: openshift > Affects Versions: 4.4.0.Alpha1 > Reporter: Fred Bricon > Assignee: Fred Bricon > Labels: connection_wizard, explorer, openshift_v3 > Fix For: 4.4.0.Alpha2 > > > OpenShift Explorer should be made visible when a new Connection is created. This is particularly useful when the CDK Server creates an OpenShift Connection and the OpenShift Explorer is not visible. > Could be done through a connection listener in the UI activator -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22278) Explorer: should be made visible when a new Connection is created

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22278?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-22278: -------------------------------- Fix Version/s: 4.4.0.Alpha2 (was: 4.4.x) > Explorer: should be made visible when a new Connection is created > ----------------------------------------------------------------- > > Key: JBIDE-22278 > URL: https://issues.jboss.org/browse/JBIDE-22278 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: openshift > Affects Versions: 4.4.0.Alpha1 > Reporter: Fred Bricon > Assignee: Fred Bricon > Labels: connection_wizard, explorer, openshift_v3 > Fix For: 4.4.0.Alpha2 > > > OpenShift Explorer should be made visible when a new Connection is created. This is particularly useful when the CDK Server creates an OpenShift Connection and the OpenShift Explorer is not visible. > Could be done through a connection listener in the UI activator -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22278) Explorer: should be made visible when a new Connection is created

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22278?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-22278: -------------------------------- Sprint: devex #114 May 2017 > Explorer: should be made visible when a new Connection is created > ----------------------------------------------------------------- > > Key: JBIDE-22278 > URL: https://issues.jboss.org/browse/JBIDE-22278 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: openshift > Affects Versions: 4.4.0.Alpha1 > Reporter: Fred Bricon > Assignee: Fred Bricon > Labels: connection_wizard, explorer, openshift_v3 > Fix For: 4.4.0.Alpha2 > > > OpenShift Explorer should be made visible when a new Connection is created. This is particularly useful when the CDK Server creates an OpenShift Connection and the OpenShift Explorer is not visible. > Could be done through a connection listener in the UI activator -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22288) VPE crashes studio with JRE fatal error on Fedora 23

by Pavol Srna (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22288?page=com.atlassian.jira.plugi... ] Pavol Srna commented on JBIDE-22288: ------------------------------------ [~wjmcdermott], I'm unable to reproduce with jboss-devstudio-9.1.0.GA. You refer in the forum that you've used jboss-devstudio-9.0.1.GA can you please try again with 9.1.0.GA? > VPE crashes studio with JRE fatal error on Fedora 23 > ---------------------------------------------------- > > Key: JBIDE-22288 > URL: https://issues.jboss.org/browse/JBIDE-22288 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: visual-page-editor-core > Affects Versions: 4.3.1.Final > Reporter: Ilya Buziuk > Assignee: Ilya Buziuk > Priority: Critical > Fix For: 4.4.0.Alpha1 > > Attachments: hs_err_pid2276.log.zip > > > Using VPE on Fedora ends up Studio crash > Works fine on Windows 10, Ubuntu 16.04 > More details can be found here - https://developer.jboss.org/message/955490 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22288) VPE crashes studio with JRE fatal error on Fedora 23

by Pavol Srna (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22288?page=com.atlassian.jira.plugi... ] Pavol Srna updated JBIDE-22288: ------------------------------- Steps to Reproduce: 1. Download and install latest JBoss Developer Studio 9.1.0.GA on Fedora 23 2. Install GTK 2 libs (yum install webkitgtk) 3. Run studio against GTK 2 (EXPORT SWT_GTK3=0) 4. Change VPE web engine from HTML5 to JSF - https://snag.gy/EosP9g.jpg 5. ERROR: studio crashes with JRE fatal errror (@see error log) was: 1. Download and install latest JBoss Developer Studio 9.1.0.GA on Fedora 23 2. Install GTK 2 libs (yum install webkitgtk) 3. Run studio against GTK 2 (EXPORT SWT-GTK3=0) 4. Change VPE web engine from HTML5 to JSF - https://snag.gy/EosP9g.jpg 5. ERROR: studio crashes with JRE fatal errror (@see error log) > VPE crashes studio with JRE fatal error on Fedora 23 > ---------------------------------------------------- > > Key: JBIDE-22288 > URL: https://issues.jboss.org/browse/JBIDE-22288 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: visual-page-editor-core > Affects Versions: 4.3.1.Final > Reporter: Ilya Buziuk > Assignee: Ilya Buziuk > Priority: Critical > Fix For: 4.4.0.Alpha1 > > Attachments: hs_err_pid2276.log.zip > > > Using VPE on Fedora ends up Studio crash > Works fine on Windows 10, Ubuntu 16.04 > More details can be found here - https://developer.jboss.org/message/955490 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13671) Replace build timestamp in qualifier by last-mod-timestamp from git

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-13671: --------------------------------------------- {quote} "generating identical filenames for different content" Just because the upstream has changed doesn't mean the downstream is actually different. Sure, it might be built with something different upstream, but if it compiles and all the tests pass, isn't it effectively the same bits? If not, other than the addition of a buildID or newer timestamp, how would you KNOW it's different? Would it really BEHAVE differently? {quote} If you use a different TP that affects the feature.xml resolution of what the 0.0.0 refers to does it not ? Thus it will behave differently since the content is actually different. {quote} "How do we know which binary users actually have when their name is the same ?" Of course there's the buildinfo.json to tell you which versions of upstream were used for a given build or aggregate, but that won't flow through to the end user. The only way the end user will know which version of the otherwise identical build is by the BUILD_ALIAS, which will, once a milestone, force everything to be "new" again, even if the timestamp and commit SHA is the same. (This is what we did for JBDS 9.1 – bump the parent pom, bump the ALIAS, and force users to install EVERYTHING all over again even when the bits were basically identical for may projects' plugins.) OTOH, if we trash the BUILD_ALIAS and just use timestamps (which is a valid option in https://developer.jboss.org/wiki/JBossProjectVersioning ) then there's no way for a user to know if the bits they have installed are the Alpha, Beta, CR, or Final/GA ones. All they can know is from which SHA in github came the source for the plugin/feature. {quote} It is a valid option in JBossrojectVersoining assuming you don't release two under same name. {quote} But then they can do INCREMENTAL upgrades. Each version of JBT or DS is smaller compared to the previous one. So it's a win in that updating ever 3 or 6 weeks (after every 1 or 2 sprints drop a new release) will be much faster and more user friendly. {quote} Yes, this part of getting incremental updates is a *good* thing, but can't we get there withuot having duplicate copies of the same things ? If they really are so much teh same as you want them to be, why don't we delete the new duplicates ? {quote} "Also Locus does not have branches" If we're moving to a model of Being More Agile, then perhaps we don't need to use branches at all - just as Locus does. We would of course still tag after a release is done, based on the SHAs used to produce that release (as we did for JBDS 9.x). The only time branches need be used is for feature work that's not ready to be included in the master stream. Then project leads can cherry-pick those topic branches back into master when they're ready to be included. {quote} I'm not sure what your point is - how are you going to support not having a maintanence branch and product branch for developer studio ? I know how it is done for locus - simply by us not changing things and have multiple versions in there. But that can't be applied for something as bing as developer studio afaics. {quote} I'd also like to move to a model of "release every week" (even if that's only to /staging/, not /development/). In that workflow, having incremental updates for users is all the more important. And for QE too, so it's easier to see which plugins have actually changed week over week. Related: http://www.infoq.com/presentations/Facebook-Release-Process {quote} Yes, this is what I want too - but with the above you are no longer sure you get the same bits when testing/installing/updated. If you installed early you get the old build of freemarker, if you installed month later you get the new one, but if you update you stay on the old build. > Replace build timestamp in qualifier by last-mod-timestamp from git > ------------------------------------------------------------------- > > Key: JBIDE-13671 > URL: https://issues.jboss.org/browse/JBIDE-13671 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.1.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Optional > Fix For: 4.4.0.Alpha2 > > Attachments: jbide13671-before-and-after.png > > > This needs to be added to master parent pom: > {code} > <plugin> > <groupId>org.eclipse.tycho</groupId> > <artifactId>tycho-packaging-plugin</artifactId> > <version>${tycho.version}</version> > <dependencies> > <dependency> > <groupId>org.eclipse.tycho.extras</groupId> > <artifactId>tycho-buildtimestamp-jgit</artifactId> > <version>${tycho-extras.version}</version> > </dependency> > </dependencies> > <configuration> > <strictBinIncludes>false</strictBinIncludes> > <format>'v'yyyyMMdd-HHmm</format> > <timestampProvider>jgit</timestampProvider> > <jgit.ignore> > </jgit.ignore> > </configuration> > </plugin> > {code} > Ref: http://pweclipse.blogspot.ch/2012_09_01_archive.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13671) Replace build timestamp in qualifier by last-mod-timestamp from git

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-13671: ------------------------------------ "generating identical filenames for different content" Just because the upstream has changed doesn't mean the downstream is actually different. Sure, it might be built with something different upstream, but if it compiles and all the tests pass, isn't it effectively the same bits? If not, other than the addition of a buildID or newer timestamp, how would you KNOW it's different? Would it really BEHAVE differently? "How do we know which binary users actually have when their name is the same ?" Of course there's the buildinfo.json to tell you which versions of upstream were used for a given build or aggregate, but that won't flow through to the end user. The only way the end user will know which version of the otherwise identical build is by the BUILD_ALIAS, which will, once a milestone, force everything to be "new" again, even if the timestamp and commit SHA is the same. (This is what we did for JBDS 9.1 -- bump the parent pom, bump the ALIAS, and force users to install EVERYTHING all over again even when the bits were basically identical for may projects' plugins.) OTOH, if we trash the BUILD_ALIAS and just use timestamps (which is a valid option in https://developer.jboss.org/wiki/JBossProjectVersioning ) then there's no way for a user to know if the bits they have installed are the Alpha, Beta, CR, or Final/GA ones. All they can know is from which SHA in github came the source for the plugin/feature. But then they can do INCREMENTAL upgrades. Each version of JBT or DS is smaller compared to the previous one. So it's a win in that updating ever 3 or 6 weeks (after every 1 or 2 sprints drop a new release) will be much faster and more user friendly. "Also Locus does not have branches" If we're moving to a model of Being More Agile, then perhaps we don't need to use branches at all - just as Locus does. We would of course still tag after a release is done, based on the SHAs used to produce that release (as we did for JBDS 9.x). The only time branches need be used is for feature work that's not ready to be included in the master stream. Then project leads can cherry-pick those topic branches back into master when they're ready to be included. I'd also like to move to a model of "release every week" (even if that's only to /staging/, not /development/). In that workflow, having incremental updates for users is all the more important. And for QE too, so it's easier to see which plugins have actually changed week over week. Related: http://www.infoq.com/presentations/Facebook-Release-Process > Replace build timestamp in qualifier by last-mod-timestamp from git > ------------------------------------------------------------------- > > Key: JBIDE-13671 > URL: https://issues.jboss.org/browse/JBIDE-13671 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.1.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Optional > Fix For: 4.4.0.Alpha2 > > Attachments: jbide13671-before-and-after.png > > > This needs to be added to master parent pom: > {code} > <plugin> > <groupId>org.eclipse.tycho</groupId> > <artifactId>tycho-packaging-plugin</artifactId> > <version>${tycho.version}</version> > <dependencies> > <dependency> > <groupId>org.eclipse.tycho.extras</groupId> > <artifactId>tycho-buildtimestamp-jgit</artifactId> > <version>${tycho-extras.version}</version> > </dependency> > </dependencies> > <configuration> > <strictBinIncludes>false</strictBinIncludes> > <format>'v'yyyyMMdd-HHmm</format> > <timestampProvider>jgit</timestampProvider> > <jgit.ignore> > </jgit.ignore> > </configuration> > </plugin> > {code} > Ref: http://pweclipse.blogspot.ch/2012_09_01_archive.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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