January 2015 - jbosstools-issues - Jboss List Archives

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

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15332?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-15332: ------------------------------------ Seems reasonable but we also have another property for controlling download of runtimes in Server (as set in parent pom): <skipITests>false</skipITests> (Then used in jbosstools-server/as/itests/pom.xml ) What do we do with that property? Does skipTestRequirements replace skipITests? cc: [~rob.stryker] > 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: Enhancement > Components: build > Affects Versions: 4.2.0.Beta1 > Reporter: Max Rydahl Andersen > Assignee: Mickael Istria > Priority: Minor > Labels: f2f2014 > Fix For: 4.3.0.Alpha1 > > > 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 was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19081) Use simpler Surefire include/exclude pattern in parent pom

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19081?page=com.atlassian.jira.plugi... ] Nick Boldt reassigned JBIDE-19081: ---------------------------------- Assignee: Nick Boldt > Use simpler Surefire include/exclude pattern in parent pom > ---------------------------------------------------------- > > Key: JBIDE-19081 > URL: https://issues.jboss.org/browse/JBIDE-19081 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > 1. In JBDS9, use these new default patterns for Surefire to define which test classes to run/exclude: > {code} > include = *Test*, *Test, *TestCase > exclude = *Abstract* > {code} > 2. If that causes test failures because running incorrectly named > abstract stuff, they can refactor, add their own root pom overrides, use > a TestSuite, or use @Ignore in test classes. > 3. If the count of tests run suddenly DROPS because the pattern isn't > running the correct # of tests, they can add their own root pom > overrides, or use a TestSuite. > Ref: http://lists.jboss.org/pipermail/jbosstools-dev/2015-January/009688.html -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19081) Use simpler Surefire include/exclude pattern in parent pom

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19081?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-19081: ------------------------------- Fix Version/s: 4.3.0.Alpha1 > Use simpler Surefire include/exclude pattern in parent pom > ---------------------------------------------------------- > > Key: JBIDE-19081 > URL: https://issues.jboss.org/browse/JBIDE-19081 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > 1. In JBDS9, use these new default patterns for Surefire to define which test classes to run/exclude: > {code} > include = *Test*, *Test, *TestCase > exclude = *Abstract* > {code} > 2. If that causes test failures because running incorrectly named > abstract stuff, they can refactor, add their own root pom overrides, use > a TestSuite, or use @Ignore in test classes. > 3. If the count of tests run suddenly DROPS because the pattern isn't > running the correct # of tests, they can add their own root pom > overrides, or use a TestSuite. > Ref: http://lists.jboss.org/pipermail/jbosstools-dev/2015-January/009688.html -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19081) Use simpler Surefire include/exclude pattern in parent pom

by Nick Boldt (JIRA)

Nick Boldt created JBIDE-19081: ---------------------------------- Summary: Use simpler Surefire include/exclude pattern in parent pom Key: JBIDE-19081 URL: https://issues.jboss.org/browse/JBIDE-19081 Project: Tools (JBoss Tools) Issue Type: Bug Components: build Affects Versions: 4.3.0.Alpha1 Reporter: Nick Boldt 1. In JBDS9, use these new default patterns for Surefire to define which test classes to run/exclude: {code} include = *Test*, *Test, *TestCase exclude = *Abstract* {code} 2. If that causes test failures because running incorrectly named abstract stuff, they can refactor, add their own root pom overrides, use a TestSuite, or use @Ignore in test classes. 3. If the count of tests run suddenly DROPS because the pattern isn't running the correct # of tests, they can add their own root pom overrides, or use a TestSuite. Ref: http://lists.jboss.org/pipermail/jbosstools-dev/2015-January/009688.html -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19049) Enable JBoss servers to run with java 9

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19049?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-19049: ------------------------------------- tl;dr: Mars is missing functionality for properly using Java 9. Because it's missing this functionality, the Java 9 jre/jdk is not marked as compatible with the minimum execution environment for the server, and cannot be used. If you go to window -> Preferences and type "Execution Environment" you will see that there is no JavaSE-1.9 execution environment. Theoretically, java 9 should also show up as valid for a j7 or j8 execution environment, but it's not. Tracing through when adding the jre/jdk to "Installed JREs", I see: {code} EnvironmentsManager.analyze(IVMInstall, IProgressMonitor) line: 342 EnvironmentsManager.vmAdded(IVMInstall) line: 380 JavaRuntime.fireVMAdded(IVMInstall) line: 2387 {code} I see the following code: {code} Analyzer[] analyzers = getAnalyzers(); for (int i = 0; i < analyzers.length; i++) { Analyzer analyzer = analyzers[i]; try { CompatibleEnvironment[] environments = analyzer.analyze(vm, monitor); {code} There is only 1 "analyzer", and there are 0 compatible environments for the given jdk / jre. Looking in ExecutionEnvironmentAnalyzer, we see the following code: {code} if (javaVersion.startsWith("1.8")) //$NON-NLS-1$ types = getTypes(JavaSE_1_8); else if (javaVersion.startsWith("1.7")) //$NON-NLS-1$ types = getTypes(JavaSE_1_7); else if (javaVersion.startsWith("1.6")) //$NON-NLS-1$ types = getTypes(JavaSE_1_6); else if (javaVersion.startsWith("1.5")) //$NON-NLS-1$ types = getTypes(J2SE_1_5); else if (javaVersion.startsWith("1.4")) //$NON-NLS-1$ types = getTypes(J2SE_1_4); else if (javaVersion.startsWith("1.3")) //$NON-NLS-1$ types = getTypes(J2SE_1_3); else if (javaVersion.startsWith("1.2")) //$NON-NLS-1$ types = getTypes(J2SE_1_2); else if (javaVersion.startsWith("1.1")) { //$NON-NLS-1$ if ((vm instanceof IVMInstall3) && isFoundation1_1((IVMInstall3) vm)) types = getTypes(CDC_FOUNDATION_1_1); else types = getTypes(JRE_1_1); } else if (javaVersion.startsWith("1.0")) { //$NON-NLS-1$ if ((vm instanceof IVMInstall3) && isFoundation1_0((IVMInstall3) vm)) types = getTypes(CDC_FOUNDATION_1_0); } {code} So basically, they're missing an if-statement for java9 as well as a constant for it etc. > Enable JBoss servers to run with java 9 > --------------------------------------- > > Key: JBIDE-19049 > URL: https://issues.jboss.org/browse/JBIDE-19049 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Affects Versions: 4.2.2.Final > Reporter: Martin Malina > Assignee: Rob Stryker > Fix For: 4.3.0.Alpha1 > > > I briefly tried to use java 9 for our tooling and to run servers. > I downloaded it from here: > https://jdk9.java.net/download/ > {code} > nattura:8.0.2 rasp$ java -version > java version "1.9.0-ea" > Java(TM) SE Runtime Environment (build 1.9.0-ea-b45) > Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b45, mixed mode) > {code} > I use OS X 10.10 Yosemite. > There are a couple of problems: > 1. When I add a WildFly 8.2 server into JBDS 8.0.2, I cannot change the runtime to use java 9 - it seems we restrict that. > 2. Even if I could, we need to make sure -XX:MaxPermSize is not used in the server launch command. When I tried to run WildFly 8.2 from the terminal, it wouldn't work unless I removed the max perm size argument. Apparently java 9 does not just ignore this parameter (as java 8 did), but it does not allow it at all. > {code} > nattura:bin rasp$ ./standalone.sh > ========================================================================= > JBoss Bootstrap Environment > JBOSS_HOME: /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final > JAVA: /Library/Java/JavaVirtualMachines/jdk1.9.0.jdk/Contents/Home/bin/java > JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true > ========================================================================= > Unrecognized VM option 'MaxPermSize=256m' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > {code} > Of course it's questionable if we should allow java 9 for current servers at all as they don't support it officially. But I would say there is no need to restrict it if it works. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-15135: ------------------------------------ +1 to merge and start using in master branch. Time permitting we could roll it into 8.1.0 too. > Attach metadata during assembly instead of publish time > ------------------------------------------------------- > > Key: JBIDE-15135 > URL: https://issues.jboss.org/browse/JBIDE-15135 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.3.0.Alpha1 > > > In order to make it easier to deal with Nexus and to have an homogeneous way to access build metadata (commit id), it would be interesting to move creation of metadata at assembly time (same time as when we create index and so on), and put it directly into the site. > Then whether we use Nexus or a home-made publication, we are sure that we can access metadata whenever we can access the binaries. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3310) 3rd party certification for JBDS 8.0.2.GA

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3310?page=com.atlassian.jira.plugin.... ] Nick Boldt closed JBDS-3310. ---------------------------- Resolution: Done 8.0.2 is released, so I suppose we can close this. [~mmurray] I assume the security fix will be in the release notes, right? > 3rd party certification for JBDS 8.0.2.GA > ----------------------------------------- > > Key: JBDS-3310 > URL: https://issues.jboss.org/browse/JBDS-3310 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Feature Request > Components: 3rd-party-certification, 3rd-party-dependencies, requirements, target-platform > Affects Versions: 8.0.0.GA > Reporter: Nick Boldt > Assignee: Len DiMaggio > Priority: Blocker > Fix For: 8.0.2.GA > > > For JBDS 8.0.2.GA, track changes since JBDS-3215 (8.0.1.GA release). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18985) provide tool to audit BUILD_ALIAS in feature qualifiers when aggregated

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18985?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-18985: ------------------------------- Fix Version/s: 4.3.0.Alpha2 > provide tool to audit BUILD_ALIAS in feature qualifiers when aggregated > ----------------------------------------------------------------------- > > Key: JBIDE-18985 > URL: https://issues.jboss.org/browse/JBIDE-18985 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Fix For: 4.3.0.Alpha2 > > > Based on discussion {quote}Do you have a test for "expected BUILD_ALIAS value in feature qualifiers" ?{quote} > Some tests we can run (forgive this pseudocode): > {code} > // for builds up to a x.y.0 release > if ((BUILD_ALIAS in (Alpha*, Beta*, CR*) and jbosstools.version endsWith(".0")) { > // make sure all features end in the same BUILD_ALIAS, or Final > // if anything doesn't match WARN (want a build to be yellow, not red) > } > {code} > {code} > // for GA builds and followup maintenance > if ((BUILD_ALIAS in (Final, GA)) { > // make sure all com.* features end in GA, and all others end in Final > // if anything doesn't match FAIL (want a build to be red) > } > {code} > Once we have that coded, perhaps into a maven enforcer plugin?, we can fine tune it for cases like where Freemarker does an update in Alpha and then does nothing for 4 months, waiting for CR/GA. > Should they have to keep updating their root pom just so the BUILD_ALIAS matches and they're building against the correct target platform? > Or, should their code remain dormant, but their job's config.xml be updated to override the BUILD_ALIAS & TARGET_PLATFORM values to the correct versions? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18869) migrate Thym from TP to being an aggregated component

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18869?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-18869: ------------------------------------ This is ready to be resolved in 4.3.0.Alpha1. [~gercan] [~maxandersen] Should we backport this change to 4.2.3 too? > migrate Thym from TP to being an aggregated component > ----------------------------------------------------- > > Key: JBIDE-18869 > URL: https://issues.jboss.org/browse/JBIDE-18869 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: aerogear-hybrid, build, target-platform, updatesite > Affects Versions: 4.2.0.Final > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.2.3.Final, 4.3.0.Alpha1 > > > Because Thym changes frequently, and because Gorkem runs the project, we should treat it like a JBT project, not part of the TP. > This would allow it to be incorporated into builds more easily and would avoid TP churn. > This should be fixed in master then backported for 4.2.2 (or 4.2.3). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19039) Window size shouldn't be computed proportionally to 'display' size but rather aligned with the components

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19039?page=com.atlassian.jira.plugi... ] Snjezana Peco updated JBIDE-19039: ---------------------------------- Component/s: upstream > Window size shouldn't be computed proportionally to 'display' size but rather aligned with the components > --------------------------------------------------------------------------------------------------------- > > Key: JBIDE-19039 > URL: https://issues.jboss.org/browse/JBIDE-19039 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: forge, upstream > Affects Versions: 4.2.2.Final > Reporter: Pavol Srna > Assignee: Snjezana Peco > Fix For: LATER > > Attachments: forge-scaffold-window.png, other-wizard.png > > > Wizard window size shouldn't be computed proportionally to 'display' size. But instead it should be aligned with the components that are in the wizard. > You can see on the screenshots how it looks when you have your monitor in portrait orientation. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 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 2015