[JBoss JIRA] (JBIDE-13824) groovy environment variable hack no longer works in install-grinder jobs
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13824?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-13824:
----------------------------------------
This does not affect tests using the "Install Grinder" (SWT-based) as we improved the engine to support semi-colon separated lists of URLs as well as spece-separated (the space-separated lists in matrix jobs were the root cause of the issue).
So is there still something I need to do on this topic?
> groovy environment variable hack no longer works in install-grinder jobs
> ------------------------------------------------------------------------
>
> Key: JBIDE-13824
> URL: https://issues.jboss.org/browse/JBIDE-13824
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng, testing-tools
> Affects Versions: 4.0.1.Final, 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Mickael Istria
>
> {code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_6.0.juno/job/jbosstools-4.0_stable_branch.upgrade-tests.matrix/7/console}
> Started by user nboldt(a)REDHAT.COM
> [EnvInject] - Loading node environment variables.
> [EnvInject] - Preparing an environment for the build.
> [EnvInject] - Keeping Jenkins system variables.
> [EnvInject] - Keeping Jenkins build variables.
> [EnvInject] - Adding build parameters as variables.
> [EnvInject] - Evaluation the following Groovy script content:
> // Horrible hack to set PRODUCT !
> import hudson.model.*
> def thr = Thread.currentThread()
> def build = thr?.executable
> def resolver = build.buildVariableResolver
> def url = resolver.resolve("INSTALL_URL")
> String product = url.contains("devstudio") ? "devstudio" : "jbosstools"
> String proto = url.contains("devstudio.jboss.com") ? "https" : "http"
> [PRODUCT: product, PROTO: proto]
> [EnvInject] - [ERROR] - SEVERE ERROR occurs: No such property: executable for class: hudson.model.OneOffExecutor
> Notifying upstream projects of job completion
> Finished: FAILURE
> {code}
> Similar problem (which I worked around by removing the check on url and just hardcoding the values of product and proto):
> {code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_6.0.juno/job/jbosstools-4.0_stable_branch.install-tests.matrix/77/console}
> Started by user nboldt(a)REDHAT.COM
> [EnvInject] - Loading node environment variables.
> [EnvInject] - Preparing an environment for the build.
> [EnvInject] - Keeping Jenkins system variables.
> [EnvInject] - Keeping Jenkins build variables.
> [EnvInject] - Adding build parameters as variables.
> [EnvInject] - Evaluation the following Groovy script content:
> // Horrible hack to set PRODUCT !
> import hudson.model.*
> def thr = Thread.currentThread()
> def build = thr?.getCurrentExecutable()
> def resolver = build.buildVariableResolver
> def url = resolver.resolve("INSTALL_URL")
> String product = url.contains("devstudio") ? "devstudio" : "jbosstools"
> String proto = url.contains("devstudio.jboss.com") ? "https" : "http"
> [PRODUCT: product, PROTO: proto]
> [EnvInject] - [ERROR] - SEVERE ERROR occurs: Cannot invoke method contains() on null object
> Notifying upstream projects of job completion
> Finished: FAILURE{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
13 years
[JBoss JIRA] (JBIDE-13821) CI runs tests against minimum instead of maximum
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13821?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-13821.
---------------------------------
This fix is applied in both branches. Closing.
> CI runs tests against minimum instead of maximum
> ------------------------------------------------
>
> Key: JBIDE-13821
> URL: https://issues.jboss.org/browse/JBIDE-13821
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Affects Versions: 4.0.x, 4.1.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Priority: Critical
> Fix For: 4.0.1.Final, 4.1.0.Alpha2
>
>
> As Maven executions set a value for the TARGET_PLATFORM_VERSION value, this property is not overriden by the maximum profile.
> Maven order to set properties is
> # look a -D... to set property, if not found
> # look at active profiles to set property, if not found
> # look at default value of property to set it
> This makes that in mvn execution for tests, the TARGET_PLATFORM_VERSION is set to minimal is CI jobs, whereas with using the -Pmaximun profile, we expect maximum.
> This is a critical issue since it caused hours of confusions to debug on 4.0.x branch.
--
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
13 years
[JBoss JIRA] (JBIDE-13048) Move the Maven Java EE-related configurators over to m2e-wtp
by Rastislav Wagner (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13048?page=com.atlassian.jira.plugi... ]
Rastislav Wagner closed JBIDE-13048.
------------------------------------
Verified in JBDS 7.0.0.Alpha1c v20130306-0101-B124
> Move the Maven Java EE-related configurators over to m2e-wtp
> ------------------------------------------------------------
>
> Key: JBIDE-13048
> URL: https://issues.jboss.org/browse/JBIDE-13048
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven
> Affects Versions: 4.0.0.Beta1
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Labels: f2f2012
> Fix For: 4.1.0.Alpha1
>
>
> We decided to contribute the JavaEE Maven configurators back to m2e-wtp. This includes :
> * JPA configurator
> * JAX-RS configurator
> * JSF configurator
> Things to do :
> * We must make sure the code doesn't depend on any JBT dependencies
> * change namespace to org.eclipse.m2e.wtp.*
> * new Contribution CQ must be created @ eclipse.org
> * We need to make the current JBT plugins aware of their new org.eclipse.m2e.wtp counterparts and make the transition as smooth as possible for users (disable JBT plugins if m2e-wtp ones are found, or make the upgrade possible between those plugins)
--
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
13 years
[JBoss JIRA] (JBIDE-13811) SeamTests are filing with exception in setUp method when new semRuntime is created
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13811?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-13811.
---------------------------------
Tests passing, closing.
> SeamTests are filing with exception in setUp method when new semRuntime is created
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-13811
> URL: https://issues.jboss.org/browse/JBIDE-13811
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: Seam 2
> Affects Versions: 4.0.1.Final
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Fix For: 4.0.1.Final
>
>
> Usually happens when projects cannot be deleted from workspace in tearDown method. It means there are opened projects with seam feature but without seam preferences. It leads to exception below:
> {code}java.lang.IllegalStateException: Preference node "org.jboss.tools.seam.core" has been removed.
> at org.eclipse.core.internal.preferences.EclipsePreferences.checkRemoved(EclipsePreferences.java:200)
> at org.eclipse.core.internal.preferences.EclipsePreferences.internalGet(EclipsePreferences.java:630)
> at org.eclipse.core.internal.preferences.EclipsePreferences.get(EclipsePreferences.java:477)
> at org.jboss.tools.seam.internal.core.SeamProject.getRuntimeName(SeamProject.java:161)
> at org.jboss.tools.seam.core.project.facet.SeamRuntimeManager.updateProjectsForRuntime(SeamRuntimeManager.java:228)
> at org.jboss.tools.seam.core.project.facet.SeamRuntimeManager.addRuntime(SeamRuntimeManager.java:170)
> at org.jboss.tools.seam.core.project.facet.SeamRuntimeManager.addRuntime(SeamRuntimeManager.java:193)
> at org.jboss.tools.seam.core.test.project.facet.AbstractSeamFacetTest.setUp(AbstractSeamFacetTest.java:93)
> {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
13 years
[JBoss JIRA] (JBIDE-13690) Detect future EAP 6 based server like SOA-P
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13690?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-13690:
---------------------------------------
Verified in JBDS 6.0.1.CR1 B354. Will close once verified in JBDS 7.0.0.Alpha2
> Detect future EAP 6 based server like SOA-P
> -------------------------------------------
>
> Key: JBIDE-13690
> URL: https://issues.jboss.org/browse/JBIDE-13690
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: JBossAS/Servers, runtime-detection
> Reporter: Max Rydahl Andersen
> Assignee: Len DiMaggio
> Priority: Blocker
> Labels: new_and_noteworthy, respin-a
> Fix For: 4.0.1.Final, 4.1.0.Alpha2
>
>
> To be sure future AS7/EAP 6 based servers such as SOA-P 6 can be detected and started as an EAP 6 we need to provide a fallback for this instead of the currrent hardcoding of eap slots.
--
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
13 years
[JBoss JIRA] (JBIDE-9830) Option to handle deployment directories manually
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-9830?page=com.atlassian.jira.plugin... ]
Rob Stryker commented on JBIDE-9830:
------------------------------------
> When using the custom deploy directory, the Prefix deployment scanner doesn't seem to be used. I'm more than happy to setup the scanner myself, but then the AS tries deploying the items twice. Once for my scanner, and then another for the actions of JBoss Tools.
I believe this specific situation has been solved, as it now polls the remote server for a list of currently scanned locations before adding, so as not to add a duplicate.
However, there should be a way to override this behavior if possible. I'll look into adding one.
> Option to handle deployment directories manually
> ------------------------------------------------
>
> Key: JBIDE-9830
> URL: https://issues.jboss.org/browse/JBIDE-9830
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: JBossAS/Servers
> Affects Versions: 3.3.0.M3
> Environment: Eclipse Indigo Release, Windows 7
> Reporter: Kevin Formsma
> Assignee: Rob Stryker
> Fix For: 4.0.x
>
>
> Currently, JBoss Tools adds the deployment folder to the scanner list. When using custom deploy folders, an option to disable the automatic deployment of the folder and have the user manually configure the JBoss AS instance to scan the custom directory would be great. This option would by default, not be enabled to preserve existing behavior.
> The use case for this is my team uses the JBoss AS 4.2 Prefix deployment scanner to deploy items in a predetermined order. When using the custom deploy directory, the Prefix deployment scanner doesn't seem to be used. I'm more than happy to setup the scanner myself, but then the AS tries deploying the items twice. Once for my scanner, and then another for the actions of JBoss Tools.
--
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
13 years
[JBoss JIRA] (JBIDE-13825) Workspace metadata deployment is not activated without a server restart
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13825?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-13825:
-------------------------------------
> If you're gonna say that I shouldn't change the deployment settings on a running server, then I will say that the changes are enabled so it should work
You are completely correct ;) Either it should be disabled, or it should work ;)
> Workspace metadata deployment is not activated without a server restart
> -----------------------------------------------------------------------
>
> Key: JBIDE-13825
> URL: https://issues.jboss.org/browse/JBIDE-13825
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: JBossAS/Servers
> Affects Versions: 4.0.1.Final
> Environment: JBDS 6.0.1.CR1 B354
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.0.2.Final, 4.1.0.Alpha2
>
>
> When you start an AS7 (I used EAP 6.0.1) server and then change deployment to workspace metadata and save it on the fly, you will notice that the server gets synchronized, so I would assume that the change is applied (and new deployment scanner is created), but when you then deploy something, it isn't deployed.
> After restart the new deployment scanner is added to the server.
> A side issue: Of course the .dodeploy marker stays in the deploy location, because the server doesn't pick it up (the deployment scanner is not set up), but when I delete the module from the server, at least then the .dodeploy should be removed if it's still there - currently it stays there.
--
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
13 years
[JBoss JIRA] (JBIDE-13831) Add 'Edit' to possible actions in 'configure maven repositories'
by Michelle Murray (JIRA)
Michelle Murray created JBIDE-13831:
---------------------------------------
Summary: Add 'Edit' to possible actions in 'configure maven repositories'
Key: JBIDE-13831
URL: https://issues.jboss.org/browse/JBIDE-13831
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: maven
Affects Versions: 4.0.0.Final
Reporter: Michelle Murray
Assignee: Fred Bricon
In Windows > Preferences > JBoss Tools > JBoss Maven Integration, there is configure maven repositories.
This has options to 'remove', 'remove all', and 'add repository'. Is it possible to add an 'edit' option?
For example, I have jboss eap 6.0.0 and I want to update it to 6.0.1. Or what if I use the 'add repository' option and make a small mistake - I would have to remove the repo and start again. I realize there are workarounds for both of these examples but 'Edit' would be useful from a user perspective.
--
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
13 years