May 2015 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-19750) Install grinder fails to run on RHEL7: No more handles!

by Konstantin Marmalyukov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19750?page=com.atlassian.jira.plugi... ] Konstantin Marmalyukov commented on JBIDE-19750: ------------------------------------------------ [~fbricon] this is not a good idea. Reasons: 1. There is no 64bit webkit for Windows 2. 32bit Webkit on Windows requres Safari to be installed. 3. When JSF mode in VPE will be turned on, there is a good chance for Eclipse to be crashed because of webkit and xulrunner conflict(if Webkit is installed and you use GTK2) I'd rather use the same approach we use for Visual Editor for HTML files or in preview in [HTML5 wizards in Palette|https://github.com/jbosstools/jbosstools-jst/blob/master/plugins/...]. We use default browser everywhere(SWT.NONE). On Mac it is Webkit, on Windows it is IE. On Linux GTK3 it is Webkit(using Webkit as a default browser for GTK3 is forced by VPE). On Linux GTK2 we add a dialog for VPE to choose between Webkit and XulRunner. The problem that you may have is when XulRunner is turned on on Linux GTK2. Your Central implementation looks beautiful, so I guess a lot of HTML5 features was used there, which unfortunately is not supported by XulRunner. Anyway, we should take a look how ugly Central will look with our XulRunner at first. > Install grinder fails to run on RHEL7: No more handles! > ------------------------------------------------------- > > Key: JBIDE-19750 > URL: https://issues.jboss.org/browse/JBIDE-19750 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.0.Beta1 > Reporter: Nick Boldt > Assignee: Mickael Istria > > {code} > 16:48:30 Installing org.eclipse.swtbot.eclipse.test.junit.feature.group 2.2.1.201402241301. > ... > 13:39:08 !MESSAGE Internal browser is not available: No more handles [Browser style SWT.MOZILLA and Java system property org.eclipse.swt.browser.DefaultType=mozilla are not supported with GTK 3 as XULRunner is not ported for GTK 3 yet] > 13:43:18 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 253.079 sec > 13:43:18 > 13:43:18 Testcase: testInstall took 252.166 sec > {code} - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... > I tried to run using `-Dorg.eclipse.swt.browser.DefaultType=webkit` as a script param for `testInstall.groovy` but it must not have passed through to the eclipse install process, as the above error suggests. > Wondering if ... > a) passing through a different *swt.browser.DefaultType*, &/or > b) using a newer SWTBot (which works with Luna [1] now?) > ... might help. > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=464619 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-418) Cannot install JBDS-IS from downloaded zip into JBDS when offline

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-418?page=com.atlassian.jira.plugin.... ] Paul Leacu resolved JBTIS-418. ------------------------------ Resolution: Done No longer reference the feature import of usage - replaced with the plugin variant. https://github.com/jbosstools/jbosstools-integration-stack/commit/e2c4ae4... > Cannot install JBDS-IS from downloaded zip into JBDS when offline > ----------------------------------------------------------------- > > Key: JBTIS-418 > URL: https://issues.jboss.org/browse/JBTIS-418 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: releng > Affects Versions: 8.0.0.GA > Environment: Linux x86_64 Open JDK 7 > JBDS 8.0.0.GA-v20141020-1042-B317 > JBDS IS 8.0.0.GA > Reporter: Denis Golovin > Assignee: Paul Leacu > Fix For: 8.0.2.CR1 > > > While was testing possible solutions for including JBDS IS into JBDS Installer I realized that there something missing in JBDS or IS zip. Offfline installation into JBDS 8.0.0.GA fails with > {code} > Cannot complete the install because one or more required items could not be found. > Software being installed: JBoss Data Virtualization Development (ModeShape, Teiid Designer) 8.0.0.201502201745 (com.jboss.devstudio.integration-stack.ds.feature.feature.group 8.0.0.201502201745) > Missing requirement: JBoss Data Virtualization Development (ModeShape, Teiid Designer) 8.0.0.201502201745 (com.jboss.devstudio.integration-stack.ds.feature.feature.group 8.0.0.201502201745) requires 'org.jboss.tools.usage.feature.feature.group 0.0.0' but it could not be found > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19744) jbosstools-build has both 4.2.x and 4.2.X and with different content

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19744?page=com.atlassian.jira.plugi... ] Nick Boldt closed JBIDE-19744. ------------------------------ Resolution: Done * Target platform is already so tagged: https://github.com/jbosstools/jbosstools-target-platforms/tree/4.42.0.Final * PR pushed to jbosstools-build 4.2.x branch (lowercase), AFTER the jbosstools-4.2.3.Final tag. * Branch jbosstools-4.2.X (uppercase) deleted: {code} $➔ git push origin :jbosstools-4.2.X To git@github.com:jbosstools/jbosstools-build.git - [deleted] jbosstools-4.2.X {code} Closing. > jbosstools-build has both 4.2.x and 4.2.X and with different content > -------------------------------------------------------------------- > > Key: JBIDE-19744 > URL: https://issues.jboss.org/browse/JBIDE-19744 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.2.3.Final > Reporter: Max Rydahl Andersen > Assignee: Nick Boldt > Priority: Critical > Fix For: 4.2.3.Final > > > Both https://github.com/jbosstools/jbosstools-build/tree/jbosstools-4.2.X and https://github.com/jbosstools/jbosstools-build/tree/jbosstools-4.2.x exist. > The difference is shown here: https://github.com/jbosstools/jbosstools-build/compare/jbosstools-4.2.x..... > indicating that 4.2.x builds are *not* using the released version of TP to build against - only snapshot (which should not be there if TP was released) > We should get the 4.2.X deleted, but before we do - what do we do about the missing commit on 4.2.x ? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOCUS-13) Build number in qualifier are against reproducible version qualifier

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/LOCUS-13?page=com.atlassian.jira.plugin.s... ] Nick Boldt commented on LOCUS-13: --------------------------------- Oops, yeah. Sorry, didn't scroll all the way down. +100 for merging this PR to remove both BUILD_ALIAS and BUILD_NUMBER. I see you also snuck in turning on pack200 by default. :D > Build number in qualifier are against reproducible version qualifier > -------------------------------------------------------------------- > > Key: LOCUS-13 > URL: https://issues.jboss.org/browse/LOCUS-13 > Project: JBoss Tools Locus > Issue Type: Enhancement > Reporter: Mickael Istria > Assignee: Mickael Istria > Priority: Critical > Fix For: 1.2.0 > > > We did set up git-based reproducible qualifiers but in the other end, we have the qualifier always changing because it contains the BUILD_NUMBER. > Those metadata should not be part of the qualifier, but should instead be in a future index.html, or attached to the Maven artifact. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19756) jbosstools-src.zip has incomplete/misleading version info in folder names/structure

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19756?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-19756: ------------------------------------ Adding json files will take more work as they're produced in a different mojo (GenerateRepositoryFacadeMojo.java, not FetchSourcesFromManifests.java), and I'm a bit hesitant to have one mojo depend on another. Do you want that the FetchSourcesFromManifests will also FetchJSONFromUpstreamLatestBuildsFolders (hoping that no respins have happened between the start of the aggregate job and the time when the fetch starts) ? Or should I just include target/fullSite/all/repo/buildinfo.json into target/fullSite/all/jbosstools-src.zip ? It's already included in the generated update site + update site zip, so I don't have a problem adding it to the src.zip too... except for the fact that we'll have cross-mojo dependencies. This will mean that the aggregate builds (JBT & JBDS) will depend on BOTH mojos, and that they can only be configured to run in a SPECIFIC order. Is that acceptable? > jbosstools-src.zip has incomplete/misleading version info in folder names/structure > ----------------------------------------------------------------------------------- > > Key: JBIDE-19756 > URL: https://issues.jboss.org/browse/JBIDE-19756 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Affects Versions: 4.3.0.Beta1 > Reporter: Max Rydahl Andersen > Assignee: Nick Boldt > Fix For: 4.3.0.Beta1 > > Attachments: jbide19756.png > > > Downloading latest jbosstools-src.zip from http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-bui... I see multiple files in root named: > <componentname>_<buildqualifier>_<sha1> > example: > jbosstools-javaee_Beta1-v20150501-0413-B767_149f9a46d5c676fd7119515e8b6aa796859955ad > A few issues with this: > a) it would have been nice unzipping would not create multiple root level folders. Maybe have a jbosstools-source folder as root ? > b) the buildqualifier is there but the version string for the component is not. Either put the full version string for that component (not overall jbosstools version) or just leave it as <component>-<sha> and have the root folder state the full version of jbosstools. since non-indulged user would not know this one had to do with 4.3.0.Beta1 or 4.2.3.Beta1 (for example). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19756) jbosstools-src.zip has incomplete/misleading version info in folder names/structure

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19756?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-19756: ------------------------------------ Two problems with your plan: a) zips are produced as snapshots, then later renamed ONLY if they're deemed QE-worthy. Your scheme would require *renaming the root folder inside the zip* as well as the zip itself. That would mean unpacking and repacking it as part of the "staging for QE" process. *-100* for that. That would mean changing the artifact between CI build and QE-stage, then again for release. Or, you'd have ALL the zips that lead up to 4.3.0.Final have the same root folder in them, whether they're Beta, CR, or Final. Are you OK with this? * jbosstools-<snapshot-qualifier>-src.zip!/jbosstools-4.3.0.Final-sources/ * jbosstools-4.3.0.Beta1-src.zip!/jbosstools-4.3.0.Final-sources/ * jbosstools-4.3.0.Beta1-src.zip!/jbosstools-4.3.0.Final-sources/ * jbosstools-4.3.0.CR1-src.zip!/jbosstools-4.3.0.Final-sources/ * jbosstools-4.3.0.Final-src.zip!/jbosstools-4.3.0.Final-sources/ I'm not, but you might prefer that to just having this: * jbosstools-4.3.0.CR1-src.zip!/jbosstools-sources/ b) for JBDS, you've selected a name that differs from the standard. Convention for JBDS (and other products) is to use *-src.zip*, not -sources.zip. Happy to provide examples if you need proof. > jbosstools-src.zip has incomplete/misleading version info in folder names/structure > ----------------------------------------------------------------------------------- > > Key: JBIDE-19756 > URL: https://issues.jboss.org/browse/JBIDE-19756 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Affects Versions: 4.3.0.Beta1 > Reporter: Max Rydahl Andersen > Assignee: Nick Boldt > Fix For: 4.3.0.Beta1 > > Attachments: jbide19756.png > > > Downloading latest jbosstools-src.zip from http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-bui... I see multiple files in root named: > <componentname>_<buildqualifier>_<sha1> > example: > jbosstools-javaee_Beta1-v20150501-0413-B767_149f9a46d5c676fd7119515e8b6aa796859955ad > A few issues with this: > a) it would have been nice unzipping would not create multiple root level folders. Maybe have a jbosstools-source folder as root ? > b) the buildqualifier is there but the version string for the component is not. Either put the full version string for that component (not overall jbosstools version) or just leave it as <component>-<sha> and have the root folder state the full version of jbosstools. since non-indulged user would not know this one had to do with 4.3.0.Beta1 or 4.2.3.Beta1 (for example). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOCUS-13) Build number in qualifier are against reproducible version qualifier

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/LOCUS-13?page=com.atlassian.jira.plugin.s... ] Mickael Istria commented on LOCUS-13: ------------------------------------- The PR also removes the hudson profiles, which was appending the BUILD_NUMBER. So it gives org.jboss.tools.locus.dmr_1.3.0.v20150430-1349.jar. > Build number in qualifier are against reproducible version qualifier > -------------------------------------------------------------------- > > Key: LOCUS-13 > URL: https://issues.jboss.org/browse/LOCUS-13 > Project: JBoss Tools Locus > Issue Type: Enhancement > Reporter: Mickael Istria > Assignee: Mickael Istria > Priority: Critical > Fix For: 1.2.0 > > > We did set up git-based reproducible qualifiers but in the other end, we have the qualifier always changing because it contains the BUILD_NUMBER. > Those metadata should not be part of the qualifier, but should instead be in a future index.html, or attached to the Maven artifact. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOCUS-13) Build number in qualifier are against reproducible version qualifier

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/LOCUS-13?page=com.atlassian.jira.plugin.s... ] Nick Boldt commented on LOCUS-13: --------------------------------- Removing BUILD_ALIAS won't remove the B## suffix. It will only remove the .Final part. Do you ALSO want to remove the BUILD_NUMBER? {quote}The action here would be simply be to configure tycho-packaging-plugin to remove reference to BUILD_NUMBER.{quote} Oh, I see you do. Or did. But don't now? Plugins in http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-loc... show names like org.jboss.tools.locus.dmr_1.3.0.Final-v20150430-1349-B77.jar But when we rebuild, even if we remove the .Final bit, we'll get org.jboss.tools.locus.dmr_1.3.0.v20150430-1349-B78.jar And then each build after that, assuming no code change to the plugin (so no timestamp change)... org.jboss.tools.locus.dmr_1.3.0.v20150430-1349-B79.jar org.jboss.tools.locus.dmr_1.3.0.v20150430-1349-B80.jar ... > Build number in qualifier are against reproducible version qualifier > -------------------------------------------------------------------- > > Key: LOCUS-13 > URL: https://issues.jboss.org/browse/LOCUS-13 > Project: JBoss Tools Locus > Issue Type: Enhancement > Reporter: Mickael Istria > Assignee: Mickael Istria > Priority: Critical > Fix For: 1.2.0 > > > We did set up git-based reproducible qualifiers but in the other end, we have the qualifier always changing because it contains the BUILD_NUMBER. > Those metadata should not be part of the qualifier, but should instead be in a future index.html, or attached to the Maven artifact. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19750) Install grinder fails to run on RHEL7: No more handles!

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19750?page=com.atlassian.jira.plugi... ] Fred Bricon commented on JBIDE-19750: ------------------------------------- Creating the browser in Central is pretty straightforward : https://github.com/jbosstools/jbosstools-central/commit/3e8814a705ffa0a3c... Maybe I'm doing something bad, but I have literally no idea about what is wrong here. I hope [~ibuziuk] or [~kmarmaliykov] can be of better help > Install grinder fails to run on RHEL7: No more handles! > ------------------------------------------------------- > > Key: JBIDE-19750 > URL: https://issues.jboss.org/browse/JBIDE-19750 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.0.Beta1 > Reporter: Nick Boldt > Assignee: Mickael Istria > > {code} > 16:48:30 Installing org.eclipse.swtbot.eclipse.test.junit.feature.group 2.2.1.201402241301. > ... > 13:39:08 !MESSAGE Internal browser is not available: No more handles [Browser style SWT.MOZILLA and Java system property org.eclipse.swt.browser.DefaultType=mozilla are not supported with GTK 3 as XULRunner is not ported for GTK 3 yet] > 13:43:18 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 253.079 sec > 13:43:18 > 13:43:18 Testcase: testInstall took 252.166 sec > {code} - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... > I tried to run using `-Dorg.eclipse.swt.browser.DefaultType=webkit` as a script param for `testInstall.groovy` but it must not have passed through to the eclipse install process, as the above error suggests. > Wondering if ... > a) passing through a different *swt.browser.DefaultType*, &/or > b) using a newer SWTBot (which works with Luna [1] now?) > ... might help. > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=464619 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3411) have installer build actually use M6 p2 product build

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3411?page=com.atlassian.jira.plugin.... ] Nick Boldt reassigned JBDS-3411: -------------------------------- Assignee: Len DiMaggio (was: Denis Golovin) > have installer build actually use M6 p2 product build > ----------------------------------------------------- > > Key: JBDS-3411 > URL: https://issues.jboss.org/browse/JBDS-3411 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: build, installer, updatesite > Reporter: Max Rydahl Andersen > Assignee: Len DiMaggio > Priority: Critical > Fix For: 9.0.0.Beta1 > > > talking with [~prapicault] I learned that since M6 the following changes are required for proper working p2 product/osx build: > {code} > <products> > <product> > ... > <rootFolders> > <macosx>MyProduct.app</macosx> > </rootFolders> > </product> > {code} > And to use tycho 0.23-snapshot -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 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 2015