January 2014 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBDS-2492) JBDS Icon problems in Gnome 3.6 Application Switcher

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBDS-2492?page=com.atlassian.jira.plugin.... ] Denis Golovin updated JBDS-2492: -------------------------------- Attachment: appnamefixed.png App name fixed > JBDS Icon problems in Gnome 3.6 Application Switcher > ---------------------------------------------------- > > Key: JBDS-2492 > URL: https://issues.jboss.org/browse/JBDS-2492 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: ui/branding > Affects Versions: 6.0.1.GA > Environment: Ubuntu Linux x86_64 > Gnome 3.6.0 > Reporter: Denis Golovin > Assignee: Denis Golovin > Priority: Minor > Fix For: 8.0.0.Alpha2 > > Attachments: app-switcher.png, appnamefixed.png, appnamexfce.png > > > Problems are: > # Icon Resolution is to low > # No application name under icon > !app-switcher.png! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-2635) Installation sometimes fail with bundle was not found on Windows

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBDS-2635?page=com.atlassian.jira.plugin.... ] Denis Golovin commented on JBDS-2635: ------------------------------------- {quote}Okey, but we would need similar mechanisms that izpack provides. splashscreen, legal text, panels etc.{quote} Current solution is a hack into IzPack which runs p2Director app as external process, reads process output, analyze it and reports progress in IzPack panel. It also checks process return code to see if it is finished correctly or failed. All this is working fine in most cases but: 1. It is slower than just running installation process inside the same JVM 2. It doesn't support Unicode names for target folder under windows (see JBDS-2260) 3. It is a hack done in forked class that needs migration every time we migrate to new IzPack. Why Eclipse RCP? Because we know how eclipse works and can match every feature IzPack has like: 1. Multi-platform support 2. Panels are just wizards steps 3. What is going to be installed should be provided as p2repository instead of IzPack packs (additional files can be delivered as root file features (?)) 4. UI translation do different languages (can be done, but we're not using it) 5. Splashscreen What is missing in eclipse (n): 1. Support for creating Groups and Launchers in menu under windows and linux 2. Native installers (but we don't use it) 3. Launching eclipse RCP from jar file {quote}Just trying to understand what the value we get by reimplementing these ?{quote} We would have everything eclipse based, even installer (y) Installation would be faster (y) Installer would be smaller if packed pack200 (y) > Installation sometimes fail with bundle was not found on Windows > ---------------------------------------------------------------- > > Key: JBDS-2635 > URL: https://issues.jboss.org/browse/JBDS-2635 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: installer > Affects Versions: 7.0.0.Beta1 > Environment: JBDS 7.0.0.Beta1, W8_64, Java 1.7.0_07 > Reporter: Jiri Peterka > Assignee: Denis Golovin > Fix For: 8.0.0.Alpha2 > > Attachments: 1369261136479.log, 1372203584223.log, 1372203590931.bak_0.log, 1372203590931.bak_1.log, 1372203590931.bak_2.log, 1372203590931.log, 1372355790692.log > > > For the first time JBDS 7.0.0.Beta1 failed on windows8: > {code} > An error occurred while installing the items > session context was:(profile=jbds, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null --> [R]org.eclipse.jst.common.frameworks 1.1.601.v201208160700, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). > The artifact file for osgi.bundle,org.eclipse.jst.common.frameworks,1.1.601.v201208160700 was not found. > Application failed, log file location: C:\vw\jbds-7.0.0-beta1\studio\p2\director\configuration\1369261136579.log > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-2880) com.jboss.jbds.product.EclipseGenerator application failure in isntaller

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBDS-2880?page=com.atlassian.jira.plugin.... ] Denis Golovin commented on JBDS-2880: ------------------------------------- EclipseGenerator is empty application, it does nothing just starts and exits, but calling this application triggers initialization for eclipse platform. For example OSGi cache is filled and so on (I didn't really look into other details). Next time eclipse starts faster, because initialization is done at installation time. You can try on any eclipse package: # Unpack eclipse # Start it and watch delay between two events: splash is shown and workspace location dialog is shown # Hit Cancel # Start eclipse again and you see delay between splash and workspace location dialog is shorter. Delay at (2) was really long in eclipse at some point, so we had to do that tick. Now it is much faster but still noticeable. > com.jboss.jbds.product.EclipseGenerator application failure in isntaller > ------------------------------------------------------------------------ > > Key: JBDS-2880 > URL: https://issues.jboss.org/browse/JBDS-2880 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: installer > Affects Versions: 7.1.0.GA > Reporter: Denis Golovin > Assignee: Denis Golovin > Fix For: 8.0.0.Alpha2 > > > {code}!SESSION 2014-01-16 16:34:55.784 ----------------------------------------------- > eclipse.buildId=unknown > java.version=1.7.0_51 > java.vendor=Oracle Corporation > BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US > Framework arguments: -application com.jboss.jbds.product.EclipseGenerator > Command-line arguments: -application com.jboss.jbds.product.EclipseGenerator -clean > !ENTRY org.eclipse.osgi 4 0 2014-01-16 16:34:57.716 > !MESSAGE Application error > !STACK 1 > java.lang.RuntimeException: Application "com.jboss.jbds.product.EclipseGenerator" could not be found in the registry. The applications available are: com.jboss.jbds.p2.director, org.eclipse.equinox.app.error, org.eclipse.equinox.p2.director, org.eclipse.equinox.p2.garbagecollector.application, org.eclipse.equinox.p2.publisher.InstallPublisher, org.eclipse.equinox.p2.publisher.EclipseGenerator, org.eclipse.equinox.p2.publisher.ProductPublisher, org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher, org.eclipse.equinox.p2.repository.repo2runnable, org.eclipse.equinox.p2.repository.metadataverifier, org.eclipse.equinox.p2.artifact.repository.mirrorApplication, org.eclipse.equinox.p2.metadata.repository.mirrorApplication. > at org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:248) > at org.eclipse.equinox.internal.app.MainApplicationLauncher.run(MainApplicationLauncher.java:29) > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) > at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) > at org.eclipse.equinox.launcher.Main.run(Main.java:1450) > at org.eclipse.equinox.launcher.Main.main(Main.java:1426){code} > Installer could not run this application becasue it is trying to start it inside p2 director, just installed product should be used instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16303) Maven Pop-up should enable/expose mvn clean package

by Jim Tyrrell (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16303?page=com.atlassian.jira.plugi... ] Jim Tyrrell commented on JBIDE-16303: ------------------------------------- It may be available, in another menu, but it should be front and center as it in my experience is needed almost every time I do something new with maven on a challenged network. > Maven Pop-up should enable/expose mvn clean package > --------------------------------------------------- > > Key: JBIDE-16303 > URL: https://issues.jboss.org/browse/JBIDE-16303 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: maven > Reporter: Jim Tyrrell > Assignee: Fred Bricon > Attachments: mavenclean.png, Screen shot 2013-12-13 at 6.16.55 AM.png > > > When building and importing projects, every so often something goes sideways in the import/building of a project. I have to jump to the mvn command line and often I need to run mvn clean package to execute a "build" that re-sets whatever went sideways. Generally if the network goes away the above command will enable it to work. > If you know of other commands that should be exposed please let me know. > I wonder if Update Project should execute this command? I don't know enough about maven to know if this makes sense. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15332) why are skipRequirements controlling download of normal maven dependencies ?

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15332?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-15332: --------------------------------------------- Yes, I don't understand why we still have this global flag locked in. [~mickael_istria] could you work on getting this fixed/aligned ? having skip false is counter intuitive. it should be the tests fetches that is marked with skipTest reference instead. > why are skipRequirements controlling download of normal maven dependencies ? > ---------------------------------------------------------------------------- > > Key: JBIDE-15332 > URL: https://issues.jboss.org/browse/JBIDE-15332 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Reporter: Max Rydahl Andersen > Assignee: Mickael Istria > > I stumbled on [~dgolovin]'s patch for livreload at https://github.com/jbosstools/jbosstools-livereload/pull/54/files > This is not the first time i've seen skip having to be enabled for plain normal mvn dependencies. > skipRequirements are supposed to only cover big downloads (like EAP, jboss etc.) - things done via non-maven download mechanism. > Why is this applied to mvn dependency downloads ? > The culprit for needing this line is at: > https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml... > and a bugzilla (*not* jira?!) is referenced as the reason for this back in 2012: https://github.com/jbosstools/jbosstools-build/commit/2e18baaf88e0cd73b3b... > I understand why the explicit google download plugin (why is there two versions used btw?) but why is skipTests controlling normal mvn dependency download ? Which requirements are using this for download ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-2857) Add OS X Mavericks to the support matrix

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBDS-2857?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBDS-2857: ------------------------------------------- I'm fine for simply adding it to the supported list for our kepler based releases. > Add OS X Mavericks to the support matrix > ---------------------------------------- > > Key: JBDS-2857 > URL: https://issues.jboss.org/browse/JBDS-2857 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: requirements > Affects Versions: 7.1.0.CR1 > Reporter: Martin Malina > Assignee: Len DiMaggio > Fix For: 7.1.1.GA, 8.0.0.Alpha2 > > > I know this comes very late, so you may want to just push this to 8.0.0 immediately. > However, we've already been testing on Mavericks (I use it every day myself) since it was introduced on October 22, 2013 and have never seen any problem specific to it. > I only realized we still don't have Mavericks in the matrix today when I checked Michelle's Supported Configurations document. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-2669) rename/refactor JBDS product .feature / plugin / .product to have less confusing names

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-2669?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBDS-2669: ---------------------------------- Cleaned out archived p2 metadata as per https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/faq....: {code} rm -f rm ~/.m2/repository/.meta/p2* {code} Then built using -U flag to force update, using instructions in the root pom.xml (all the extra flags are unnecessary but will control if eap bundles are built and how things are named): {code:title=https://github.com/nickboldt/jbdevstudio-product/blob/00d21efcfa5ee377d1de8a925ad3fa657a6c7242/pom.xml#L108} mvn clean install -P hudson,eap,pack200 -Dtpc.version=4.40.0.Alpha2-SNAPSHOT -DBUILD_NUMBER=440002 -DJOB_NAME=devstudio.product_master -Dupdate.site.description="Development Milestone" -U {code} You can also build with just this, but you won't get an EAP bundle: {code} mvn clean install {code} > rename/refactor JBDS product .feature / plugin / .product to have less confusing names > -------------------------------------------------------------------------------------- > > Key: JBDS-2669 > URL: https://issues.jboss.org/browse/JBDS-2669 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: build, installer, updatesite > Affects Versions: 7.0.0.GA > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Critical > Fix For: 8.0.0.Alpha2 > > Attachments: update-product-manually-with-refactoring-full-featureset-review.png, update-product-manually-with-refactoring-full-featureset.png, update-product-manually-with-refactoring.png > > > We should consider some better names for these artifacts so they collide less and are more obvious which is which. > 1. https://github.com/jbdevstudio/jbdevstudio-product/blob/master/features/c... > ** featureName=JBoss Developer Studio (Core Features) / BYOE category in update site > 2. https://github.com/jbdevstudio/jbdevstudio-product/blob/master/plugins/co... and https://github.com/jbdevstudio/jbdevstudio-product/blob/master/plugins/co... > ** Bundle-SymbolicName: com.jboss.jbds.product;singleton:=true > 3. https://github.com/jbdevstudio/jbdevstudio-product/blob/master/site/com.j... > ** name="JBoss Developer Studio (Branded Product)" uid="com.jboss.jbds.all" id="com.jboss.jbds.product.product" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16376) Disabled "fetch-zips" on aggregate

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16376?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-16376: ------------------------------------ Workaround: https://github.com/jbosstools/jbosstools-build-ci/pull/70 (until we can build a better solution, this just saves the build from failing for a missing file) Verification build: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/devstudio.product_ma... >=1628 > Disabled "fetch-zips" on aggregate > ---------------------------------- > > Key: JBIDE-16376 > URL: https://issues.jboss.org/browse/JBIDE-16376 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.2.0.Alpha2 > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.2.0.Alpha2 > > > As a consequence of changes for JBIDE-16309, the Maven mojo which fetches zip from aggregate files doesn't work any more. > So I disabled it (added fetch-zips-for-aggregate.skip=true ). We should decide whether to keep this or not. It seems to me that so far, the individual zips have not been used often, so we may be able to get rid of it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16376) Disabled "fetch-zips" on aggregate

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16376?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-16376: ---------------------------------------- As a reminder, the git refspec can be found in every bundle. And for release, we do tag stuff to easily find it. > Disabled "fetch-zips" on aggregate > ---------------------------------- > > Key: JBIDE-16376 > URL: https://issues.jboss.org/browse/JBIDE-16376 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.2.0.Alpha2 > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.2.0.Alpha2 > > > As a consequence of changes for JBIDE-16309, the Maven mojo which fetches zip from aggregate files doesn't work any more. > So I disabled it (added fetch-zips-for-aggregate.skip=true ). We should decide whether to keep this or not. It seems to me that so far, the individual zips have not been used often, so we may be able to get rid of it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16376) Disabled "fetch-zips" on aggregate

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16376?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-16376 at 1/24/14 10:39 AM: -------------------------------------------------------------- A consequence of disabling the collection of zips is that we are also no longer collecting all the github revisions used in the build. Compare: http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site... (no ALL_REVISIONS.txt file) vs. http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site... We will therefore need to script a new approach to collecting this metadata in https://github.com/jbosstools/jbosstools-build-ci/blob/master/publish/pub... Otherwise, when the JBDS build looks for this file, it will fail and the job will be red. was (Author: nickboldt): A consequence of disabling the collection of zips is that we are also no longer collecting all the github revisions used in the build. Compare: http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site... (no ALL_REVISIONS.txt file) vs. http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site... We will therefore need to script a new approach to collecting this metadata in https://github.com/jbosstools/jbosstools-build-ci/blob/master/publish/pub... > Disabled "fetch-zips" on aggregate > ---------------------------------- > > Key: JBIDE-16376 > URL: https://issues.jboss.org/browse/JBIDE-16376 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.2.0.Alpha2 > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.2.0.Alpha2 > > > As a consequence of changes for JBIDE-16309, the Maven mojo which fetches zip from aggregate files doesn't work any more. > So I disabled it (added fetch-zips-for-aggregate.skip=true ). We should decide whether to keep this or not. It seems to me that so far, the individual zips have not been used often, so we may be able to get rid of it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 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 2014