From vrubezhny at exadel.com  Sun Feb  2 19:12:14 2014
From: vrubezhny at exadel.com (Victor Rubezhny)
Date: Mon, 03 Feb 2014 04:12:14 +0400
Subject: [jbosstools-dev] Fwd: Build failed in Jenkins:
	jbosstools-javaee_master #541
In-Reply-To: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>
Message-ID: <52EEDEDE.4040500@exadel.com>

Hi All!

Have a question regarding the timed out tests on Jenkins...

Is it possible to run something like:
> jstack -F <PID> | tee somedir/jstack.log
right before the killing process by time out?

In my local environment I'm facing a number of deadlocks/hang ups when 
running JUnit tests and I want to see if my situation is the same as 
what happening on Jenkins.

Thanks in advance,
Victor


-------- Original Message --------
Subject: 	Build failed in Jenkins: jbosstools-javaee_master #541
Date: 	Sun, 2 Feb 2014 06:55:43 -0500 (EST)
From: 	ci-builds at redhat.com
To: 	jbosstools-builds at lists.jboss.org, akazakov at exadel.com, 
mistria at redhat.com, vrubezhny at exadel.com, scabanovich at exadel.com, 
daniel at passos.me



See <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/541/>

------------------------------------------
[...truncated 17548 lines...]
[INFO] Pack200 packing jar <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/org.jboss.tools.runtime.seam.detector.test-3.5.0-SNAPSHOT.jar>
[INFO]
[INFO] --- tycho-p2-plugin:0.19.0:p2-metadata (attached-p2-metadata) @ org.jboss.tools.runtime.seam.detector.test ---
[INFO]
[INFO] --- tycho-p2-plugin:0.19.0:p2-metadata (p2-metadata) @ org.jboss.tools.runtime.seam.detector.test ---
[INFO]
[INFO] --- maven-dependency-plugin:2.4:unpack (install-as) @ org.jboss.tools.runtime.seam.detector.test ---
[INFO] Configured Artifact: org.jboss.jbossas:jboss-as-dist:4.2.3.GA:zip
> isMarkerOlder:
   artifact1 = <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/.repository/org/jboss/jbossas/jboss-as-dist/4.2.3.GA/jboss-as-dist-4.2.3.GA.zip>
   marker    = <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/dependency-maven-plugin-markers/org.jboss.jbossas-jboss-as-dist-zip-4.2.3.GA.marker>
     artifact1 lastModified: 1386367022000
     marker lastModified: 1386367022000
< false = marker older than artifact?
[INFO] Configured Artifact: org.jboss.as:jboss-as-dist:7.0.0.Final:zip
> isMarkerOlder:
   artifact1 = <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/.repository/org/jboss/as/jboss-as-dist/7.0.0.Final/jboss-as-dist-7.0.0.Final.zip>
   marker    = <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/dependency-maven-plugin-markers/org.jboss.as-jboss-as-dist-zip-7.0.0.Final.marker>
     artifact1 lastModified: 1386367259000
     marker lastModified: 1386367259000
< false = marker older than artifact?
[INFO] jboss-as-dist-4.2.3.GA.zip already unpacked.
[INFO] jboss-as-dist-7.0.0.Final.zip already unpacked.
[INFO]
[INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-as-5.1.0) @ org.jboss.tools.runtime.seam.detector.test ---
[INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-5.1.0.GA.zip
[INFO]
[INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-seam-2.0.1) @ org.jboss.tools.runtime.seam.detector.test ---
[INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-seam-2.0.1.GA.zip
[INFO]
[INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-seam-2.2.0) @ org.jboss.tools.runtime.seam.detector.test ---
[INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-seam-2.2.0.GA.zip
[INFO]
[INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-eap) @ org.jboss.tools.runtime.seam.detector.test ---
[INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-eap-noauth-4.3.0.GA_CP03.zip
[INFO]
[INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-eap-seam-gen) @ org.jboss.tools.runtime.seam.detector.test ---
[INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/rhds-seam-gen-patch.zip
[INFO]
[INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-eap-fp) @ org.jboss.tools.runtime.seam.detector.test ---
[INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-eap-fp-4.3.0.CP03-FP01.zip
[INFO]
[INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-seam-fp-patch) @ org.jboss.tools.runtime.seam.detector.test ---
[INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jbds-seamfp-patch.zip
[INFO]
[INFO] --- tycho-surefire-plugin:0.19.0:test (default-test) @ org.jboss.tools.runtime.seam.detector.test ---
[WARNING] The following locally built units have been used to resolve project dependencies:
[WARNING]   org.jboss.tools.seam.ui.pages/3.5.0.Alpha2-v20140202-0905-B541
[WARNING]   org.jboss.tools.runtime.seam.detector/3.5.0.Alpha2-v20140202-0905-B541
[WARNING]   org.jboss.tools.seam.text.ext/3.5.0.Alpha2-v20140202-0905-B541
[WARNING]   org.jboss.tools.seam.xml.ui/3.5.0.Alpha2-v20140202-0905-B541
[WARNING]   org.jboss.tools.seam.pages.xml/3.5.0.Alpha2-v20140202-0905-B541
[WARNING]   org.jboss.tools.seam.core/3.5.0.Alpha2-v20140202-0905-B541
[WARNING]   org.jboss.tools.seam.ui/3.5.0.Alpha2-v20140202-0905-B541
[WARNING]   org.jboss.tools.jsf.text.ext/3.6.0.Alpha2-v20140202-0905-B541
[WARNING]   org.jboss.tools.jsf.vpe.jsf/3.6.0.Alpha2-v20140202-0905-B541
[WARNING]   org.jboss.tools.seam.xml/3.5.0.Alpha2-v20140202-0905-B541
[WARNING]   org.jboss.tools.jsf/3.6.0.Alpha2-v20140202-0905-B541
[WARNING]   org.jboss.tools.jsf.vpe.seam/3.6.0.Alpha2-v20140202-0905-B541
[INFO] Expected eclipse log file: <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/541/artifact/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/work/data/.metadata/.log>
[INFO] Command line:
	/bin/sh -c cd <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test> && /qa/tools/opt/jdk1.6.0_45/jre/bin/java -Dosgi.noShutdown=false -Dosgi.os=linux -Dosgi.ws=gtk -Dosgi.arch=x86 '-javaagent:<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/.repository/org/jacoco/org.jacoco.agent/0.6.4.201312101107/org.jacoco.agent-0.6.4.201312101107-runtime.jar=destfile=/mnt/hudson_workspace/workspace/jbosstools-javaee_master/sources/seam/target/jacoco.exec,append=true,includes=org.jboss.tools.*'> -Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m -Djbosstools.test.jboss.home.4.2=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-4.2.3.GA> -Djbosstools.test.jboss.home.5.1=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-5.1.0.GA> -Djbosstools.test.seam.2.0.1.GA.home=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-seam-2.0.1.GA> -Djbosstools.test.seam.2.2.0.GA.home=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-seam-2.2.0.GA> -Djbosstools.test.eap.4.3.home=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-eap-4.3> -Dskip.runtime.scanner=true -Djbosstools.test.jboss.home.7.0=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-as-7.0.0.Final> -Dorg.jboss.tools.tests.skipPrivateRequirements=false -Dusage_reporting_enabled=false -Dorg.jboss.tools.tests.skipPrivateRequirements=false -Dorg.eclipse.ui.testsDisableWorkbenchAutoSave=true -Dosgi.clean=true -jar <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/.repository/p2/osgi/bundle/org.eclipse.equinox.launcher/1.3.0.v20130327-1440/org.eclipse.equinox.launcher-1.3.0.v20130327-1440.jar> -data <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/work/data> -install <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/work> -configuration <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/work/configuration> -application org.eclipse.tycho.surefire.osgibooter.uitest -testproperties <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/surefire.properties> -product org.jboss.tools.tests.product

-------------------------------------------------------
  T E S T S
-------------------------------------------------------
Running org.jboss.tools.runtime.seam.detector.test.SeamRuntimeDetectionAllTests
0
0
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.155 sec

Results :

Tests run: 8, Failures: 0, Errors: 0, Skipped: 0

[INFO] All tests passed!
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building javaee.all.tests 4.2.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- jacoco-maven-plugin:0.6.4.201312101107:prepare-agent (default) @ javaee.all.tests ---
[INFO] Skipping JaCoCo for project with packaging type 'pom'
[INFO]
[INFO] --- tycho-source-plugin:0.19.0:plugin-source (plugin-source) @ javaee.all.tests ---
[INFO]
[INFO] --- repository-utils:0.19.0-SNAPSHOT:generate-repository-facade (generate-facade) @ javaee.all.tests ---
[INFO]
[INFO] --- tycho-pack200a-plugin:0.19.0:normalize (pack200-normalize) @ javaee.all.tests ---
[INFO]
[INFO] --- exec-maven-plugin:1.2.1:exec (jarsign) @ javaee.all.tests ---
[INFO] skipping execute as per configuraion
[INFO]
[INFO] --- tycho-pack200b-plugin:0.19.0:pack (pack200-pack) @ javaee.all.tests ---
[INFO]
[INFO] --- tycho-p2-plugin:0.19.0:p2-metadata (attached-p2-metadata) @ javaee.all.tests ---
[INFO]
[INFO] --- tycho-p2-plugin:0.19.0:p2-metadata (p2-metadata) @ javaee.all.tests ---
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] cdi.tests ......................................... SUCCESS [0.482s]
[INFO] org.jboss.tools.cdi.core.test ..................... SUCCESS [6:20.054s]
[INFO] org.jboss.tools.cdi.extension.core.test ........... SUCCESS [27.036s]
[INFO] org.jboss.tools.cdi.seam.solder.core.test ......... SUCCESS [1:22.732s]
[INFO] org.jboss.tools.cdi.seam.config.core.test ......... SUCCESS [52.370s]
[INFO] org.jboss.tools.cdi.seam.config.ui.test ........... SUCCESS [34.175s]
[INFO] org.jboss.tools.cdi.seam.core.test ................ SUCCESS [42.391s]
[INFO] org.jboss.tools.cdi.seam.faces.core.test .......... SUCCESS [49.489s]
[INFO] org.jboss.tools.cdi.text.ext.test ................. SUCCESS [1:43.859s]
[INFO] org.jboss.tools.cdi.seam.text.ext.test ............ SUCCESS [1:10.852s]
[INFO] org.jboss.tools.cdi.ui.test ....................... SUCCESS [4:37.167s]
[INFO] org.jboss.tools.cdi.deltaspike.core.test .......... SUCCESS [29.392s]
[INFO] jsf.tests ......................................... SUCCESS [0.008s]
[INFO] org.jboss.tools.jsf.base.test ..................... SUCCESS [3.284s]
[INFO] org.jboss.tools.jsf.test .......................... SUCCESS [1:58.447s]
[INFO] org.jboss.tools.jsf.text.ext.test ................. SUCCESS [1:00.058s]
[INFO] org.jboss.tools.jsf.ui.test ....................... FAILURE [1:00:12.253s]
[INFO] org.jboss.tools.jsf.verification.test ............. SUCCESS [25.314s]
[INFO] org.jboss.tools.jsf.vpe.ajax4jsf.test ............. SUCCESS [42.422s]
[INFO] org.jboss.tools.jsf.vpe.facelets.test ............. SUCCESS [43.093s]
[INFO] org.jboss.tools.jsf.vpe.jbpm.test ................. SUCCESS [32.294s]
[INFO] org.jboss.tools.jsf.vpe.jsf.test .................. SUCCESS [4:49.452s]
[INFO] org.jboss.tools.jsf.vpe.jstl.test ................. SUCCESS [54.093s]
[INFO] org.jboss.tools.jsf.vpe.myfaces.test .............. SUCCESS [52.850s]
[INFO] org.jboss.tools.jsf.vpe.richfaces.test ............ SUCCESS [1:25.824s]
[INFO] org.jboss.tools.jsf.vpe.seam.test ................. SUCCESS [1:01.668s]
[INFO] seam.tests ........................................ SUCCESS [0.007s]
[INFO] org.jboss.tools.seam.base.test .................... SUCCESS [14.831s]
[INFO] org.jboss.tools.seam.core.test .................... SUCCESS [4:02.653s]
[INFO] org.jboss.tools.seam.pages.xml.test ............... SUCCESS [20.071s]
[INFO] org.jboss.tools.seam.ui.test ...................... FAILURE [31:07.334s]
[INFO] org.jboss.tools.seam.xml.test ..................... SUCCESS [16.786s]
[INFO] org.jboss.tools.seam121EAP.core.test .............. SUCCESS [1:22.502s]
[INFO] org.jboss.tools.seam121EAP.ui.test ................ SUCCESS [1:32.272s]
[INFO] org.jboss.tools.seam212GA.core.test ............... SUCCESS [2:07.441s]
[INFO] org.jboss.tools.seam212GA.ui.test ................. SUCCESS [1:45.919s]
[INFO] org.jboss.tools.seam221GA.core.test ............... SUCCESS [2:02.943s]
[INFO] org.jboss.tools.seam221GA.ui.test ................. SUCCESS [1:40.872s]
[INFO] org.jboss.tools.seam230.core.test ................. SUCCESS [1:48.679s]
[INFO] org.jboss.tools.seam230.ui.test ................... SUCCESS [1:20.472s]
[INFO] org.jboss.tools.seamfp.core.test .................. SUCCESS [2:03.157s]
[INFO] org.jboss.tools.seamfp.ui.test .................... SUCCESS [1:52.727s]
[INFO] org.jboss.tools.runtime.seam.detector.test ........ SUCCESS [1:44.302s]
[INFO] javaee.all.tests .................................. SUCCESS [0.017s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2:30:10.909s
[INFO] Finished at: Sun Feb 02 06:55:37 EST 2014
[INFO] Final Memory: 151M/677M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.19.0:test (default-test) on project org.jboss.tools.jsf.ui.test: Error while executing platform: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed. Process timeout out after 3600 seconds -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.19.0:test (default-test) on project org.jboss.tools.jsf.ui.test: Error while executing platform
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error while executing platform
	at org.eclipse.tycho.surefire.TestMojo.runTest(TestMojo.java:946)
	at org.eclipse.tycho.surefire.TestMojo.execute(TestMojo.java:668)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
	... 19 more
Caused by: org.eclipse.sisu.equinox.launching.EquinoxLaunchingException: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed.
	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:74)
	at org.eclipse.tycho.surefire.TestMojo.runTest(TestMojo.java:944)
	... 22 more
Caused by: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed.
	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:213)
	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:114)
	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:88)
	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:72)
	... 23 more
Caused by: java.lang.InterruptedException: Process timeout out after 3600 seconds
	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:186)
	... 26 more
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.19.0:test (default-test) on project org.jboss.tools.seam.ui.test: Error while executing platform: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed. Process timeout out after 1800 seconds -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.19.0:test (default-test) on project org.jboss.tools.seam.ui.test: Error while executing platform
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error while executing platform
	at org.eclipse.tycho.surefire.TestMojo.runTest(TestMojo.java:946)
	at org.eclipse.tycho.surefire.TestMojo.execute(TestMojo.java:668)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
	... 19 more
Caused by: org.eclipse.sisu.equinox.launching.EquinoxLaunchingException: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed.
	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:74)
	at org.eclipse.tycho.surefire.TestMojo.runTest(TestMojo.java:944)
	... 22 more
Caused by: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed.
	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:213)
	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:114)
	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:88)
	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:72)
	... 23 more
Caused by: java.lang.InterruptedException: Process timeout out after 1800 seconds
	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:186)
	... 26 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :org.jboss.tools.jsf.ui.test
Build step 'Invoke top-level Maven targets' marked build as failure
Terminating xvnc.
$ vncserver -kill :114
Killing Xvnc process ID 12309
Archiving artifacts
Recording test results
Description set:



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140203/e1d26260/attachment-0001.html 

From vrubezhny at exadel.com  Sun Feb  2 19:29:16 2014
From: vrubezhny at exadel.com (Victor Rubezhny)
Date: Mon, 03 Feb 2014 04:29:16 +0400
Subject: [jbosstools-dev] Fwd: Build failed in Jenkins:
 jbosstools-javaee_master #541
In-Reply-To: <52EEDEDE.4040500@exadel.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>
	<52EEDEDE.4040500@exadel.com>
Message-ID: <52EEE2DC.1010907@exadel.com>

Correction inside:

On 02/03/2014 04:12 AM, Victor Rubezhny wrote:
> Hi All!
>
> Have a question regarding the timed out tests on Jenkins...
>
> Is it possible to run something like:
>> jstack -F <PID> | tee somedir/jstack.log
probably it'll be better to use PID in log name too (due not to 
overwrite existing logs):

> jstack -F <PID> | tee somedir/jstack.<PID>.log
/Victor

> right before the killing process by time out?
>
> In my local environment I'm facing a number of deadlocks/hang ups when 
> running JUnit tests and I want to see if my situation is the same as 
> what happening on Jenkins.
>
> Thanks in advance,
> Victor
>
>
> -------- Original Message --------
> Subject: 	Build failed in Jenkins: jbosstools-javaee_master #541
> Date: 	Sun, 2 Feb 2014 06:55:43 -0500 (EST)
> From: 	ci-builds at redhat.com
> To: 	jbosstools-builds at lists.jboss.org, akazakov at exadel.com, 
> mistria at redhat.com, vrubezhny at exadel.com, scabanovich at exadel.com, 
> daniel at passos.me
>
>
>
> See<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/541/>
>
> ------------------------------------------
> [...truncated 17548 lines...]
> [INFO] Pack200 packing jar<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/org.jboss.tools.runtime.seam.detector.test-3.5.0-SNAPSHOT.jar>
> [INFO]
> [INFO] --- tycho-p2-plugin:0.19.0:p2-metadata (attached-p2-metadata) @ org.jboss.tools.runtime.seam.detector.test ---
> [INFO]
> [INFO] --- tycho-p2-plugin:0.19.0:p2-metadata (p2-metadata) @ org.jboss.tools.runtime.seam.detector.test ---
> [INFO]
> [INFO] --- maven-dependency-plugin:2.4:unpack (install-as) @ org.jboss.tools.runtime.seam.detector.test ---
> [INFO] Configured Artifact: org.jboss.jbossas:jboss-as-dist:4.2.3.GA:zip
> > isMarkerOlder:
>    artifact1 =<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/.repository/org/jboss/jbossas/jboss-as-dist/4.2.3.GA/jboss-as-dist-4.2.3.GA.zip>
>    marker    =<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/dependency-maven-plugin-markers/org.jboss.jbossas-jboss-as-dist-zip-4.2.3.GA.marker>
>      artifact1 lastModified: 1386367022000
>      marker lastModified: 1386367022000
> < false = marker older than artifact?
> [INFO] Configured Artifact: org.jboss.as:jboss-as-dist:7.0.0.Final:zip
> > isMarkerOlder:
>    artifact1 =<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/.repository/org/jboss/as/jboss-as-dist/7.0.0.Final/jboss-as-dist-7.0.0.Final.zip>
>    marker    =<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/dependency-maven-plugin-markers/org.jboss.as-jboss-as-dist-zip-7.0.0.Final.marker>
>      artifact1 lastModified: 1386367259000
>      marker lastModified: 1386367259000
> < false = marker older than artifact?
> [INFO] jboss-as-dist-4.2.3.GA.zip already unpacked.
> [INFO] jboss-as-dist-7.0.0.Final.zip already unpacked.
> [INFO]
> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-as-5.1.0) @ org.jboss.tools.runtime.seam.detector.test ---
> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-5.1.0.GA.zip
> [INFO]
> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-seam-2.0.1) @ org.jboss.tools.runtime.seam.detector.test ---
> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-seam-2.0.1.GA.zip
> [INFO]
> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-seam-2.2.0) @ org.jboss.tools.runtime.seam.detector.test ---
> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-seam-2.2.0.GA.zip
> [INFO]
> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-eap) @ org.jboss.tools.runtime.seam.detector.test ---
> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-eap-noauth-4.3.0.GA_CP03.zip
> [INFO]
> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-eap-seam-gen) @ org.jboss.tools.runtime.seam.detector.test ---
> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/rhds-seam-gen-patch.zip
> [INFO]
> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-eap-fp) @ org.jboss.tools.runtime.seam.detector.test ---
> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-eap-fp-4.3.0.CP03-FP01.zip
> [INFO]
> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-seam-fp-patch) @ org.jboss.tools.runtime.seam.detector.test ---
> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jbds-seamfp-patch.zip
> [INFO]
> [INFO] --- tycho-surefire-plugin:0.19.0:test (default-test) @ org.jboss.tools.runtime.seam.detector.test ---
> [WARNING] The following locally built units have been used to resolve project dependencies:
> [WARNING]   org.jboss.tools.seam.ui.pages/3.5.0.Alpha2-v20140202-0905-B541
> [WARNING]   org.jboss.tools.runtime.seam.detector/3.5.0.Alpha2-v20140202-0905-B541
> [WARNING]   org.jboss.tools.seam.text.ext/3.5.0.Alpha2-v20140202-0905-B541
> [WARNING]   org.jboss.tools.seam.xml.ui/3.5.0.Alpha2-v20140202-0905-B541
> [WARNING]   org.jboss.tools.seam.pages.xml/3.5.0.Alpha2-v20140202-0905-B541
> [WARNING]   org.jboss.tools.seam.core/3.5.0.Alpha2-v20140202-0905-B541
> [WARNING]   org.jboss.tools.seam.ui/3.5.0.Alpha2-v20140202-0905-B541
> [WARNING]   org.jboss.tools.jsf.text.ext/3.6.0.Alpha2-v20140202-0905-B541
> [WARNING]   org.jboss.tools.jsf.vpe.jsf/3.6.0.Alpha2-v20140202-0905-B541
> [WARNING]   org.jboss.tools.seam.xml/3.5.0.Alpha2-v20140202-0905-B541
> [WARNING]   org.jboss.tools.jsf/3.6.0.Alpha2-v20140202-0905-B541
> [WARNING]   org.jboss.tools.jsf.vpe.seam/3.6.0.Alpha2-v20140202-0905-B541
> [INFO] Expected eclipse log file:<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/541/artifact/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/work/data/.metadata/.log>
> [INFO] Command line:
> 	/bin/sh -c cd<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test>  && /qa/tools/opt/jdk1.6.0_45/jre/bin/java -Dosgi.noShutdown=false -Dosgi.os=linux -Dosgi.ws=gtk -Dosgi.arch=x86 '-javaagent:<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/.repository/org/jacoco/org.jacoco.agent/0.6.4.20131210110!
>   7/org.jaco
> co.agent-0.6.4.201312101107-runtime.jar=destfile=/mnt/hudson_workspace/workspace/jbosstools-javaee_master/sources/seam/target/jacoco.exec,append=true,includes=org.jboss.tools.*'>  -Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m -Djbosstools.test.jboss.home.4.2=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-4.2.3.GA>  -Djbosstools.test.jboss.home.5.1=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/!
>   jbosstools
> -javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-5.1.0.GA>  -Djbosstools.test.seam.2.0.1.GA.home=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-seam-2.0.1.GA>  -Djbosstools.test.seam.2.2.0.GA.home=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/r!
>   equirement
> s/jboss-seam-2.2.0.GA>  -Djbosstools.test.eap.4.3.home=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-eap-4.3>  -Dskip.runtime.scanner=true -Djbosstools.test.jboss.home.7.0=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-as-7.0.0.Final>  -Dorg.jboss.tools.tests.skipPrivateRequiremen!
>   ts=false -
> Dusage_reporting_enabled=false -Dorg.jboss.tools.tests.skipPrivateRequirements=false -Dorg.eclipse.ui.testsDisableWorkbenchAutoSave=true -Dosgi.clean=true -jar<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/.repository/p2/osgi/bundle/org.eclipse.equinox.launcher/1.3.0.v20130327-1440/org.eclipse.equinox.launcher-1.3.0.v20130327-1440.jar>  -data<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/targ!
>   et/work/da
> ta>  -install<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/work>  -configuration<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/work/configuration>  -application org.eclipse.tycho.surefire.osgibooter.uitest -testproperties<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/surefire.properties>  -product org.jboss.tools.tests.product
>
> -------------------------------------------------------
>   T E S T S
> -------------------------------------------------------
> Running org.jboss.tools.runtime.seam.detector.test.SeamRuntimeDetectionAllTests
> 0
> 0
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.155 sec
>
> Results :
>
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0
>
> [INFO] All tests passed!
> [INFO]
> [INFO] ------------------------------------------------------------------------
> [INFO] Building javaee.all.tests 4.2.0-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> [INFO]
> [INFO] --- jacoco-maven-plugin:0.6.4.201312101107:prepare-agent (default) @ javaee.all.tests ---
> [INFO] Skipping JaCoCo for project with packaging type 'pom'
> [INFO]
> [INFO] --- tycho-source-plugin:0.19.0:plugin-source (plugin-source) @ javaee.all.tests ---
> [INFO]
> [INFO] --- repository-utils:0.19.0-SNAPSHOT:generate-repository-facade (generate-facade) @ javaee.all.tests ---
> [INFO]
> [INFO] --- tycho-pack200a-plugin:0.19.0:normalize (pack200-normalize) @ javaee.all.tests ---
> [INFO]
> [INFO] --- exec-maven-plugin:1.2.1:exec (jarsign) @ javaee.all.tests ---
> [INFO] skipping execute as per configuraion
> [INFO]
> [INFO] --- tycho-pack200b-plugin:0.19.0:pack (pack200-pack) @ javaee.all.tests ---
> [INFO]
> [INFO] --- tycho-p2-plugin:0.19.0:p2-metadata (attached-p2-metadata) @ javaee.all.tests ---
> [INFO]
> [INFO] --- tycho-p2-plugin:0.19.0:p2-metadata (p2-metadata) @ javaee.all.tests ---
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] cdi.tests ......................................... SUCCESS [0.482s]
> [INFO] org.jboss.tools.cdi.core.test ..................... SUCCESS [6:20.054s]
> [INFO] org.jboss.tools.cdi.extension.core.test ........... SUCCESS [27.036s]
> [INFO] org.jboss.tools.cdi.seam.solder.core.test ......... SUCCESS [1:22.732s]
> [INFO] org.jboss.tools.cdi.seam.config.core.test ......... SUCCESS [52.370s]
> [INFO] org.jboss.tools.cdi.seam.config.ui.test ........... SUCCESS [34.175s]
> [INFO] org.jboss.tools.cdi.seam.core.test ................ SUCCESS [42.391s]
> [INFO] org.jboss.tools.cdi.seam.faces.core.test .......... SUCCESS [49.489s]
> [INFO] org.jboss.tools.cdi.text.ext.test ................. SUCCESS [1:43.859s]
> [INFO] org.jboss.tools.cdi.seam.text.ext.test ............ SUCCESS [1:10.852s]
> [INFO] org.jboss.tools.cdi.ui.test ....................... SUCCESS [4:37.167s]
> [INFO] org.jboss.tools.cdi.deltaspike.core.test .......... SUCCESS [29.392s]
> [INFO] jsf.tests ......................................... SUCCESS [0.008s]
> [INFO] org.jboss.tools.jsf.base.test ..................... SUCCESS [3.284s]
> [INFO] org.jboss.tools.jsf.test .......................... SUCCESS [1:58.447s]
> [INFO] org.jboss.tools.jsf.text.ext.test ................. SUCCESS [1:00.058s]
> [INFO] org.jboss.tools.jsf.ui.test ....................... FAILURE [1:00:12.253s]
> [INFO] org.jboss.tools.jsf.verification.test ............. SUCCESS [25.314s]
> [INFO] org.jboss.tools.jsf.vpe.ajax4jsf.test ............. SUCCESS [42.422s]
> [INFO] org.jboss.tools.jsf.vpe.facelets.test ............. SUCCESS [43.093s]
> [INFO] org.jboss.tools.jsf.vpe.jbpm.test ................. SUCCESS [32.294s]
> [INFO] org.jboss.tools.jsf.vpe.jsf.test .................. SUCCESS [4:49.452s]
> [INFO] org.jboss.tools.jsf.vpe.jstl.test ................. SUCCESS [54.093s]
> [INFO] org.jboss.tools.jsf.vpe.myfaces.test .............. SUCCESS [52.850s]
> [INFO] org.jboss.tools.jsf.vpe.richfaces.test ............ SUCCESS [1:25.824s]
> [INFO] org.jboss.tools.jsf.vpe.seam.test ................. SUCCESS [1:01.668s]
> [INFO] seam.tests ........................................ SUCCESS [0.007s]
> [INFO] org.jboss.tools.seam.base.test .................... SUCCESS [14.831s]
> [INFO] org.jboss.tools.seam.core.test .................... SUCCESS [4:02.653s]
> [INFO] org.jboss.tools.seam.pages.xml.test ............... SUCCESS [20.071s]
> [INFO] org.jboss.tools.seam.ui.test ...................... FAILURE [31:07.334s]
> [INFO] org.jboss.tools.seam.xml.test ..................... SUCCESS [16.786s]
> [INFO] org.jboss.tools.seam121EAP.core.test .............. SUCCESS [1:22.502s]
> [INFO] org.jboss.tools.seam121EAP.ui.test ................ SUCCESS [1:32.272s]
> [INFO] org.jboss.tools.seam212GA.core.test ............... SUCCESS [2:07.441s]
> [INFO] org.jboss.tools.seam212GA.ui.test ................. SUCCESS [1:45.919s]
> [INFO] org.jboss.tools.seam221GA.core.test ............... SUCCESS [2:02.943s]
> [INFO] org.jboss.tools.seam221GA.ui.test ................. SUCCESS [1:40.872s]
> [INFO] org.jboss.tools.seam230.core.test ................. SUCCESS [1:48.679s]
> [INFO] org.jboss.tools.seam230.ui.test ................... SUCCESS [1:20.472s]
> [INFO] org.jboss.tools.seamfp.core.test .................. SUCCESS [2:03.157s]
> [INFO] org.jboss.tools.seamfp.ui.test .................... SUCCESS [1:52.727s]
> [INFO] org.jboss.tools.runtime.seam.detector.test ........ SUCCESS [1:44.302s]
> [INFO] javaee.all.tests .................................. SUCCESS [0.017s]
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 2:30:10.909s
> [INFO] Finished at: Sun Feb 02 06:55:37 EST 2014
> [INFO] Final Memory: 151M/677M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.19.0:test (default-test) on project org.jboss.tools.jsf.ui.test: Error while executing platform: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed. Process timeout out after 3600 seconds -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.19.0:test (default-test) on project org.jboss.tools.jsf.ui.test: Error while executing platform
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error while executing platform
> 	at org.eclipse.tycho.surefire.TestMojo.runTest(TestMojo.java:946)
> 	at org.eclipse.tycho.surefire.TestMojo.execute(TestMojo.java:668)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 	... 19 more
> Caused by: org.eclipse.sisu.equinox.launching.EquinoxLaunchingException: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed.
> 	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:74)
> 	at org.eclipse.tycho.surefire.TestMojo.runTest(TestMojo.java:944)
> 	... 22 more
> Caused by: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed.
> 	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:213)
> 	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:114)
> 	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:88)
> 	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:72)
> 	... 23 more
> Caused by: java.lang.InterruptedException: Process timeout out after 3600 seconds
> 	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:186)
> 	... 26 more
> [ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.19.0:test (default-test) on project org.jboss.tools.seam.ui.test: Error while executing platform: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed. Process timeout out after 1800 seconds -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.19.0:test (default-test) on project org.jboss.tools.seam.ui.test: Error while executing platform
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error while executing platform
> 	at org.eclipse.tycho.surefire.TestMojo.runTest(TestMojo.java:946)
> 	at org.eclipse.tycho.surefire.TestMojo.execute(TestMojo.java:668)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 	... 19 more
> Caused by: org.eclipse.sisu.equinox.launching.EquinoxLaunchingException: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed.
> 	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:74)
> 	at org.eclipse.tycho.surefire.TestMojo.runTest(TestMojo.java:944)
> 	... 22 more
> Caused by: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed.
> 	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:213)
> 	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:114)
> 	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:88)
> 	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:72)
> 	... 23 more
> Caused by: java.lang.InterruptedException: Process timeout out after 1800 seconds
> 	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:186)
> 	... 26 more
> [ERROR]
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1]http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR]   mvn <goals> -rf :org.jboss.tools.jsf.ui.test
> Build step 'Invoke top-level Maven targets' marked build as failure
> Terminating xvnc.
> $ vncserver -kill :114
> Killing Xvnc process ID 12309
> Archiving artifacts
> Recording test results
> Description set:
>
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140203/ea0a0dc5/attachment-0001.html 

From mistria at redhat.com  Mon Feb  3 09:50:32 2014
From: mistria at redhat.com (Mickael Istria)
Date: Mon, 03 Feb 2014 15:50:32 +0100
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
 to Luna M5
In-Reply-To: <52EBD3D0.1010406@redhat.com>
References: <52EBD3D0.1010406@redhat.com>
Message-ID: <52EFACB8.8050504@redhat.com>

This target-platform have been updated.
Plan is to release it tomorrow.

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140203/f61c1723/attachment.html 

From dgolovin at exadel.com  Mon Feb  3 15:27:13 2014
From: dgolovin at exadel.com (Denis Golovin)
Date: Mon, 03 Feb 2014 12:27:13 -0800
Subject: [jbosstools-dev] Fwd: Build failed in Jenkins:
 jbosstools-javaee_master #541
In-Reply-To: <52EEE2DC.1010907@exadel.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>	<52EEDEDE.4040500@exadel.com>
	<52EEE2DC.1010907@exadel.com>
Message-ID: <52EFFBA1.8000508@exadel.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140203/2e9bfeaf/attachment-0001.html 

From vrubezhny at exadel.com  Mon Feb  3 17:19:15 2014
From: vrubezhny at exadel.com (Victor Rubezhny)
Date: Tue, 04 Feb 2014 02:19:15 +0400
Subject: [jbosstools-dev] Fwd: Build failed in Jenkins:
 jbosstools-javaee_master #541
In-Reply-To: <52EFFBA1.8000508@exadel.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>	<52EEDEDE.4040500@exadel.com>
	<52EEE2DC.1010907@exadel.com> <52EFFBA1.8000508@exadel.com>
Message-ID: <52F015E3.8020103@exadel.com>

Looks like we don't even need to run something like jstack...
When I'm doing "kill -3 <JVM PID>" I'm getting almost the same 
stacktrace in the JVM's console, and it looks that doing so at Jenkins 
will produce the same result in Job's console output.

Does somebody know how a process is killed in Jenkins because of 
timeout? Can we override or customize it?

/Victor

On 02/04/2014 12:27 AM, Denis Golovin wrote:
> Could you try to add java shutdown hook
>
> Runtime. addShutdownHook(Thread hook)
>
> then in hook get process id using
>
> ManagementFactory.getRuntimeMXBean().getName()
>
> and then exec external process $java.home+"/../bin/jstack $id" and 
> redirect this process std out to console.
>
> Not sure if Runtime.exec() would work inside hook thread.
>
> Denis
>
> On 02/02/2014 04:29 PM, Victor Rubezhny wrote:
>> Correction inside:
>>
>> On 02/03/2014 04:12 AM, Victor Rubezhny wrote:
>>> Hi All!
>>>
>>> Have a question regarding the timed out tests on Jenkins...
>>>
>>> Is it possible to run something like:
>>>> jstack -F <PID> | tee somedir/jstack.log
>> probably it'll be better to use PID in log name too (due not to 
>> overwrite existing logs):
>>
>>> jstack -F <PID> | tee somedir/jstack.<PID>.log
>> /Victor
>>
>>> right before the killing process by time out?
>>>
>>> In my local environment I'm facing a number of deadlocks/hang ups 
>>> when running JUnit tests and I want to see if my situation is the 
>>> same as what happening on Jenkins.
>>>
>>> Thanks in advance,
>>> Victor
>>>
>>>
>>> -------- Original Message --------
>>> Subject: 	Build failed in Jenkins: jbosstools-javaee_master #541
>>> Date: 	Sun, 2 Feb 2014 06:55:43 -0500 (EST)
>>> From: 	ci-builds at redhat.com
>>> To: 	jbosstools-builds at lists.jboss.org, akazakov at exadel.com, 
>>> mistria at redhat.com, vrubezhny at exadel.com, scabanovich at exadel.com, 
>>> daniel at passos.me
>>>
>>>
>>>
>>> See<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/541/>
>>>
>>> ------------------------------------------
>>> [...truncated 17548 lines...]
>>> [INFO] Pack200 packing jar<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/org.jboss.tools.runtime.seam.detector.test-3.5.0-SNAPSHOT.jar>
>>> [INFO]
>>> [INFO] --- tycho-p2-plugin:0.19.0:p2-metadata (attached-p2-metadata) @ org.jboss.tools.runtime.seam.detector.test ---
>>> [INFO]
>>> [INFO] --- tycho-p2-plugin:0.19.0:p2-metadata (p2-metadata) @ org.jboss.tools.runtime.seam.detector.test ---
>>> [INFO]
>>> [INFO] --- maven-dependency-plugin:2.4:unpack (install-as) @ org.jboss.tools.runtime.seam.detector.test ---
>>> [INFO] Configured Artifact: org.jboss.jbossas:jboss-as-dist:4.2.3.GA:zip
>>> > isMarkerOlder:
>>>    artifact1 =<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/.repository/org/jboss/jbossas/jboss-as-dist/4.2.3.GA/jboss-as-dist-4.2.3.GA.zip>
>>>    marker    =<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/dependency-maven-plugin-markers/org.jboss.jbossas-jboss-as-dist-zip-4.2.3.GA.marker>
>>>      artifact1 lastModified: 1386367022000
>>>      marker lastModified: 1386367022000
>>> < false = marker older than artifact?
>>> [INFO] Configured Artifact: org.jboss.as:jboss-as-dist:7.0.0.Final:zip
>>> > isMarkerOlder:
>>>    artifact1 =<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/.repository/org/jboss/as/jboss-as-dist/7.0.0.Final/jboss-as-dist-7.0.0.Final.zip>
>>>    marker    =<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/dependency-maven-plugin-markers/org.jboss.as-jboss-as-dist-zip-7.0.0.Final.marker>
>>>      artifact1 lastModified: 1386367259000
>>>      marker lastModified: 1386367259000
>>> < false = marker older than artifact?
>>> [INFO] jboss-as-dist-4.2.3.GA.zip already unpacked.
>>> [INFO] jboss-as-dist-7.0.0.Final.zip already unpacked.
>>> [INFO]
>>> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-as-5.1.0) @ org.jboss.tools.runtime.seam.detector.test ---
>>> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-5.1.0.GA.zip
>>> [INFO]
>>> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-seam-2.0.1) @ org.jboss.tools.runtime.seam.detector.test ---
>>> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-seam-2.0.1.GA.zip
>>> [INFO]
>>> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-seam-2.2.0) @ org.jboss.tools.runtime.seam.detector.test ---
>>> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-seam-2.2.0.GA.zip
>>> [INFO]
>>> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-eap) @ org.jboss.tools.runtime.seam.detector.test ---
>>> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-eap-noauth-4.3.0.GA_CP03.zip
>>> [INFO]
>>> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-eap-seam-gen) @ org.jboss.tools.runtime.seam.detector.test ---
>>> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/rhds-seam-gen-patch.zip
>>> [INFO]
>>> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-eap-fp) @ org.jboss.tools.runtime.seam.detector.test ---
>>> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jboss-eap-fp-4.3.0.CP03-FP01.zip
>>> [INFO]
>>> [INFO] --- download-maven-plugin:1.2.0-SNAPSHOT:wget (install-seam-fp-patch) @ org.jboss.tools.runtime.seam.detector.test ---
>>> [INFO] Got from cache: /home/hudson/static_build_env/jbds/download-cache/jbds-seamfp-patch.zip
>>> [INFO]
>>> [INFO] --- tycho-surefire-plugin:0.19.0:test (default-test) @ org.jboss.tools.runtime.seam.detector.test ---
>>> [WARNING] The following locally built units have been used to resolve project dependencies:
>>> [WARNING]   org.jboss.tools.seam.ui.pages/3.5.0.Alpha2-v20140202-0905-B541
>>> [WARNING]   org.jboss.tools.runtime.seam.detector/3.5.0.Alpha2-v20140202-0905-B541
>>> [WARNING]   org.jboss.tools.seam.text.ext/3.5.0.Alpha2-v20140202-0905-B541
>>> [WARNING]   org.jboss.tools.seam.xml.ui/3.5.0.Alpha2-v20140202-0905-B541
>>> [WARNING]   org.jboss.tools.seam.pages.xml/3.5.0.Alpha2-v20140202-0905-B541
>>> [WARNING]   org.jboss.tools.seam.core/3.5.0.Alpha2-v20140202-0905-B541
>>> [WARNING]   org.jboss.tools.seam.ui/3.5.0.Alpha2-v20140202-0905-B541
>>> [WARNING]   org.jboss.tools.jsf.text.ext/3.6.0.Alpha2-v20140202-0905-B541
>>> [WARNING]   org.jboss.tools.jsf.vpe.jsf/3.6.0.Alpha2-v20140202-0905-B541
>>> [WARNING]   org.jboss.tools.seam.xml/3.5.0.Alpha2-v20140202-0905-B541
>>> [WARNING]   org.jboss.tools.jsf/3.6.0.Alpha2-v20140202-0905-B541
>>> [WARNING]   org.jboss.tools.jsf.vpe.seam/3.6.0.Alpha2-v20140202-0905-B541
>>> [INFO] Expected eclipse log file:<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/541/artifact/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/work/data/.metadata/.log>
>>> [INFO] Command line:
>>> 	/bin/sh -c cd<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test>  && /qa/tools/opt/jdk1.6.0_45/jre/bin/java -Dosgi.noShutdown=false -Dosgi.os=linux -Dosgi.ws=gtk -Dosgi.arch=x86 '-javaagent:<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/.reposito!
>>>   ry/org/jac
>>> oco/org.jacoco.agent/0.6.4.20131210110!
>>>   7/org.jaco
>>> co.agent-0.6.4.201312101107-runtime.jar=destfile=/mnt/hudson_workspace/workspace/jbosstools-javaee_master/sources/seam/target/jacoco.exec,append=true,includes=org.jboss.tools.*'>  -Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m -Djbosstools.test.jboss.home.4.2=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-4.2.3.GA>  -Djbosstools.test.jboss.home.5.1=*MailScanner has detected a possible fraud attempt from "jenkins.mw.lab.eng.bos.redhat.com" claiming to be*  <http:/!
>>>   /jenkins.m
>>> w.lab.eng.bos.redhat.com/hudson/job/!
>>>   jbosstools
>>> -javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-5.1.0.GA>  -Djbosstools.test.seam.2.0.1.GA.home=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-seam-2.0.1.GA>  -Djbosstools.test.seam.2.2.0.GA.home=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.j!
>>>   boss.tools
>>> .runtime.seam.detector.test/target/r!
>>>   equirement
>>> s/jboss-seam-2.2.0.GA>  -Djbosstools.test.eap.4.3.home=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-eap-4.3>  -Dskip.runtime.scanner=true -Djbosstools.test.jboss.home.7.0=<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/requirements/jboss-as-7.0.0.Final>!
>>>    -Dorg.jbo
>>> ss.tools.tests.skipPrivateRequiremen!
>>>   ts=false -
>>> Dusage_reporting_enabled=false -Dorg.jboss.tools.tests.skipPrivateRequirements=false -Dorg.eclipse.ui.testsDisableWorkbenchAutoSave=true -Dosgi.clean=true -jar<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/.repository/p2/osgi/bundle/org.eclipse.equinox.launcher/1.3.0.v20130327-1440/org.eclipse.equinox.launcher-1.3.0.v20130327-1440.jar>  -data<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/o!
>>>   rg.jboss.t
>>> ools.runtime.seam.detector.test/targ!
>>>   et/work/da
>>> ta>  -install<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/work>  -configuration<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/work/configuration>  -application org.eclipse.tycho.surefire.osgibooter.uitest -testproperties*MailScanner has detected a possible fraud attempt from "jenkins.mw.lab.en!g.bos.redhat.com" claiming to be*  <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_master/ws/sources/seam/tests/org.jboss.tools.runtime.seam.detector.test/target/surefire.properties>  -product org.jboss.tools.tests.product
>>>
>>> -------------------------------------------------------
>>>   T E S T S
>>> -------------------------------------------------------
>>> Running org.jboss.tools.runtime.seam.detector.test.SeamRuntimeDetectionAllTests
>>> 0
>>> 0
>>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.155 sec
>>>
>>> Results :
>>>
>>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0
>>>
>>> [INFO] All tests passed!
>>> [INFO]
>>> [INFO] ------------------------------------------------------------------------
>>> [INFO] Building javaee.all.tests 4.2.0-SNAPSHOT
>>> [INFO] ------------------------------------------------------------------------
>>> [INFO]
>>> [INFO] --- jacoco-maven-plugin:0.6.4.201312101107:prepare-agent (default) @ javaee.all.tests ---
>>> [INFO] Skipping JaCoCo for project with packaging type 'pom'
>>> [INFO]
>>> [INFO] --- tycho-source-plugin:0.19.0:plugin-source (plugin-source) @ javaee.all.tests ---
>>> [INFO]
>>> [INFO] --- repository-utils:0.19.0-SNAPSHOT:generate-repository-facade (generate-facade) @ javaee.all.tests ---
>>> [INFO]
>>> [INFO] --- tycho-pack200a-plugin:0.19.0:normalize (pack200-normalize) @ javaee.all.tests ---
>>> [INFO]
>>> [INFO] --- exec-maven-plugin:1.2.1:exec (jarsign) @ javaee.all.tests ---
>>> [INFO] skipping execute as per configuraion
>>> [INFO]
>>> [INFO] --- tycho-pack200b-plugin:0.19.0:pack (pack200-pack) @ javaee.all.tests ---
>>> [INFO]
>>> [INFO] --- tycho-p2-plugin:0.19.0:p2-metadata (attached-p2-metadata) @ javaee.all.tests ---
>>> [INFO]
>>> [INFO] --- tycho-p2-plugin:0.19.0:p2-metadata (p2-metadata) @ javaee.all.tests ---
>>> [INFO] ------------------------------------------------------------------------
>>> [INFO] Reactor Summary:
>>> [INFO]
>>> [INFO] cdi.tests ......................................... SUCCESS [0.482s]
>>> [INFO] org.jboss.tools.cdi.core.test ..................... SUCCESS [6:20.054s]
>>> [INFO] org.jboss.tools.cdi.extension.core.test ........... SUCCESS [27.036s]
>>> [INFO] org.jboss.tools.cdi.seam.solder.core.test ......... SUCCESS [1:22.732s]
>>> [INFO] org.jboss.tools.cdi.seam.config.core.test ......... SUCCESS [52.370s]
>>> [INFO] org.jboss.tools.cdi.seam.config.ui.test ........... SUCCESS [34.175s]
>>> [INFO] org.jboss.tools.cdi.seam.core.test ................ SUCCESS [42.391s]
>>> [INFO] org.jboss.tools.cdi.seam.faces.core.test .......... SUCCESS [49.489s]
>>> [INFO] org.jboss.tools.cdi.text.ext.test ................. SUCCESS [1:43.859s]
>>> [INFO] org.jboss.tools.cdi.seam.text.ext.test ............ SUCCESS [1:10.852s]
>>> [INFO] org.jboss.tools.cdi.ui.test ....................... SUCCESS [4:37.167s]
>>> [INFO] org.jboss.tools.cdi.deltaspike.core.test .......... SUCCESS [29.392s]
>>> [INFO] jsf.tests ......................................... SUCCESS [0.008s]
>>> [INFO] org.jboss.tools.jsf.base.test ..................... SUCCESS [3.284s]
>>> [INFO] org.jboss.tools.jsf.test .......................... SUCCESS [1:58.447s]
>>> [INFO] org.jboss.tools.jsf.text.ext.test ................. SUCCESS [1:00.058s]
>>> [INFO] org.jboss.tools.jsf.ui.test ....................... FAILURE [1:00:12.253s]
>>> [INFO] org.jboss.tools.jsf.verification.test ............. SUCCESS [25.314s]
>>> [INFO] org.jboss.tools.jsf.vpe.ajax4jsf.test ............. SUCCESS [42.422s]
>>> [INFO] org.jboss.tools.jsf.vpe.facelets.test ............. SUCCESS [43.093s]
>>> [INFO] org.jboss.tools.jsf.vpe.jbpm.test ................. SUCCESS [32.294s]
>>> [INFO] org.jboss.tools.jsf.vpe.jsf.test .................. SUCCESS [4:49.452s]
>>> [INFO] org.jboss.tools.jsf.vpe.jstl.test ................. SUCCESS [54.093s]
>>> [INFO] org.jboss.tools.jsf.vpe.myfaces.test .............. SUCCESS [52.850s]
>>> [INFO] org.jboss.tools.jsf.vpe.richfaces.test ............ SUCCESS [1:25.824s]
>>> [INFO] org.jboss.tools.jsf.vpe.seam.test ................. SUCCESS [1:01.668s]
>>> [INFO] seam.tests ........................................ SUCCESS [0.007s]
>>> [INFO] org.jboss.tools.seam.base.test .................... SUCCESS [14.831s]
>>> [INFO] org.jboss.tools.seam.core.test .................... SUCCESS [4:02.653s]
>>> [INFO] org.jboss.tools.seam.pages.xml.test ............... SUCCESS [20.071s]
>>> [INFO] org.jboss.tools.seam.ui.test ...................... FAILURE [31:07.334s]
>>> [INFO] org.jboss.tools.seam.xml.test ..................... SUCCESS [16.786s]
>>> [INFO] org.jboss.tools.seam121EAP.core.test .............. SUCCESS [1:22.502s]
>>> [INFO] org.jboss.tools.seam121EAP.ui.test ................ SUCCESS [1:32.272s]
>>> [INFO] org.jboss.tools.seam212GA.core.test ............... SUCCESS [2:07.441s]
>>> [INFO] org.jboss.tools.seam212GA.ui.test ................. SUCCESS [1:45.919s]
>>> [INFO] org.jboss.tools.seam221GA.core.test ............... SUCCESS [2:02.943s]
>>> [INFO] org.jboss.tools.seam221GA.ui.test ................. SUCCESS [1:40.872s]
>>> [INFO] org.jboss.tools.seam230.core.test ................. SUCCESS [1:48.679s]
>>> [INFO] org.jboss.tools.seam230.ui.test ................... SUCCESS [1:20.472s]
>>> [INFO] org.jboss.tools.seamfp.core.test .................. SUCCESS [2:03.157s]
>>> [INFO] org.jboss.tools.seamfp.ui.test .................... SUCCESS [1:52.727s]
>>> [INFO] org.jboss.tools.runtime.seam.detector.test ........ SUCCESS [1:44.302s]
>>> [INFO] javaee.all.tests .................................. SUCCESS [0.017s]
>>> [INFO] ------------------------------------------------------------------------
>>> [INFO] BUILD FAILURE
>>> [INFO] ------------------------------------------------------------------------
>>> [INFO] Total time: 2:30:10.909s
>>> [INFO] Finished at: Sun Feb 02 06:55:37 EST 2014
>>> [INFO] Final Memory: 151M/677M
>>> [INFO] ------------------------------------------------------------------------
>>> [ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.19.0:test (default-test) on project org.jboss.tools.jsf.ui.test: Error while executing platform: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed. Process timeout out after 3600 seconds -> [Help 1]
>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.19.0:test (default-test) on project org.jboss.tools.jsf.ui.test: Error while executing platform
>>> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
>>> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>>> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>>> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>>> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>>> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>>> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>>> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
>>> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
>>> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
>>> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
>>> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> 	at java.lang.reflect.Method.invoke(Method.java:597)
>>> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>>> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>>> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>>> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
>>> Caused by: org.apache.maven.plugin.MojoExecutionException: Error while executing platform
>>> 	at org.eclipse.tycho.surefire.TestMojo.runTest(TestMojo.java:946)
>>> 	at org.eclipse.tycho.surefire.TestMojo.execute(TestMojo.java:668)
>>> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
>>> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>>> 	... 19 more
>>> Caused by: org.eclipse.sisu.equinox.launching.EquinoxLaunchingException: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed.
>>> 	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:74)
>>> 	at org.eclipse.tycho.surefire.TestMojo.runTest(TestMojo.java:944)
>>> 	... 22 more
>>> Caused by: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed.
>>> 	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:213)
>>> 	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:114)
>>> 	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:88)
>>> 	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:72)
>>> 	... 23 more
>>> Caused by: java.lang.InterruptedException: Process timeout out after 3600 seconds
>>> 	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:186)
>>> 	... 26 more
>>> [ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.19.0:test (default-test) on project org.jboss.tools.seam.ui.test: Error while executing platform: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed. Process timeout out after 1800 seconds -> [Help 1]
>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.19.0:test (default-test) on project org.jboss.tools.seam.ui.test: Error while executing platform
>>> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
>>> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>>> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>>> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>>> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>>> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>>> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>>> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
>>> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
>>> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
>>> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
>>> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> 	at java.lang.reflect.Method.invoke(Method.java:597)
>>> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>>> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>>> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>>> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
>>> Caused by: org.apache.maven.plugin.MojoExecutionException: Error while executing platform
>>> 	at org.eclipse.tycho.surefire.TestMojo.runTest(TestMojo.java:946)
>>> 	at org.eclipse.tycho.surefire.TestMojo.execute(TestMojo.java:668)
>>> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
>>> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>>> 	... 19 more
>>> Caused by: org.eclipse.sisu.equinox.launching.EquinoxLaunchingException: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed.
>>> 	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:74)
>>> 	at org.eclipse.tycho.surefire.TestMojo.runTest(TestMojo.java:944)
>>> 	... 22 more
>>> Caused by: org.codehaus.plexus.util.cli.CommandLineTimeOutException: Error while executing external command, process killed.
>>> 	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:213)
>>> 	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:114)
>>> 	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:88)
>>> 	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:72)
>>> 	... 23 more
>>> Caused by: java.lang.InterruptedException: Process timeout out after 1800 seconds
>>> 	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:186)
>>> 	... 26 more
>>> [ERROR]
>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>> [ERROR]
>>> [ERROR] For more information about the errors and possible solutions, please read the following articles:
>>> [ERROR] [Help 1]http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>>> [ERROR]
>>> [ERROR] After correcting the problems, you can resume the build with the command
>>> [ERROR]   mvn <goals> -rf :org.jboss.tools.jsf.ui.test
>>> Build step 'Invoke top-level Maven targets' marked build as failure
>>> Terminating xvnc.
>>> $ vncserver -kill :114
>>> Killing Xvnc process ID 12309
>>> Archiving artifacts
>>> Recording test results
>>> Description set:
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140204/98fb6207/attachment-0001.html 

From dgolovin at exadel.com  Mon Feb  3 18:44:23 2014
From: dgolovin at exadel.com (Denis Golovin)
Date: Mon, 03 Feb 2014 15:44:23 -0800
Subject: [jbosstools-dev] Fwd: Build failed in Jenkins:
 jbosstools-javaee_master #541
In-Reply-To: <52F015E3.8020103@exadel.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>	<52EEDEDE.4040500@exadel.com>
	<52EEE2DC.1010907@exadel.com> <52EFFBA1.8000508@exadel.com>
	<52F015E3.8020103@exadel.com>
Message-ID: <52F029D7.9030805@exadel.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140203/021393c4/attachment-0001.html 

From mistria at redhat.com  Tue Feb  4 03:25:36 2014
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 04 Feb 2014 09:25:36 +0100
Subject: [jbosstools-dev] Fwd: Build failed in Jenkins:
 jbosstools-javaee_master #541
In-Reply-To: <52F029D7.9030805@exadel.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>	<52EEDEDE.4040500@exadel.com>	<52EEE2DC.1010907@exadel.com>
	<52EFFBA1.8000508@exadel.com>	<52F015E3.8020103@exadel.com>
	<52F029D7.9030805@exadel.com>
Message-ID: <52F0A400.9030603@redhat.com>

On 02/04/2014 12:44 AM, Denis Golovin wrote:
> It is maven or surefire killing timed out process, not jenkins.
Right, and as far as I know Surefire doesn't provide hooks. So I don't 
know a good way to make you happy with that.
I have some SSH and VPN access to the Jenkins slave. In case you notice 
one slave is in trouble, feel free to ask me, I'll connect and run 
jstack or whatever helps you to figure out the cause of the issue.
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140204/49794647/attachment.html 

From max.andersen at gmail.com  Tue Feb  4 04:34:52 2014
From: max.andersen at gmail.com (Max Rydahl Andersen)
Date: Tue, 04 Feb 2014 10:34:52 +0100
Subject: [jbosstools-dev] codefreeze for alpha2 this Thursday
Message-ID: <5AD4062C-0078-4CC1-8565-0A6D54A22017@gmail.com>

Hey,

Just a reminder that code freeze for 4.2.0.Alpha2 is set to be this 
Thursday. Targeting Luna M5.

Please prepare master to compile and work decently by Thursday.

/max
http://about.me/maxandersen

From mistria at redhat.com  Tue Feb  4 10:30:30 2014
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 04 Feb 2014 16:30:30 +0100
Subject: [jbosstools-dev] Some activity in Eclipse VJET project
Message-ID: <52F10796.6010809@redhat.com>

Hi,

There are some (small) news in the VJET world: After several months of 
inactivity in this project, Justin Early (from AvantSoft) made a few 
commits and did set up some CI infrastructure for VJET. Not sure if this 
shows a potential revival of the project or not. I let those interested 
go to the mailing-list and ask him.

Cheers,
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140204/27166e21/attachment.html 

From vrubezhny at exadel.com  Tue Feb  4 10:43:06 2014
From: vrubezhny at exadel.com (Victor Rubezhny)
Date: Tue, 04 Feb 2014 19:43:06 +0400
Subject: [jbosstools-dev] Some activity in Eclipse VJET project
In-Reply-To: <52F10796.6010809@redhat.com>
References: <52F10796.6010809@redhat.com>
Message-ID: <52F10A8A.1020805@exadel.com>

Yeah,

since we provide a possibility to install VJET from Central, we should 
be aware of coming changes and versions.
Good to know that some life is continuing on the project.

Thanks,

On 02/04/2014 07:30 PM, Mickael Istria wrote:
> Hi,
>
> There are some (small) news in the VJET world: After several months of 
> inactivity in this project, Justin Early (from AvantSoft) made a few 
> commits and did set up some CI infrastructure for VJET. Not sure if 
> this shows a potential revival of the project or not. I let those 
> interested go to the mailing-list and ask him.
>
> Cheers,
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets 
> <http://twitter.com/mickaelistria>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140204/7270ffa1/attachment.html 

From nboldt at redhat.com  Tue Feb  4 13:30:39 2014
From: nboldt at redhat.com (Nick Boldt)
Date: Tue, 04 Feb 2014 13:30:39 -0500
Subject: [jbosstools-dev] 20 JBIDE JIRAs moved to Alpha2 fixVersion
Message-ID: <52F131CF.8020409@redhat.com>

There were 20 JIRAs still unresolved for fixVersion = 4.2.0.Alpha1, so 
since that release is done (Dec 19, 2013) I've moved the 20 JIRAs to 
4.2.0.Alpha2.

These are the affected JIRAs. If they're yours, and they're in fact done 
in Alpha1, please fix the fixVersion back to Alpha1 and resolve them.

https://issues.jboss.org/issues/?jql=key%20in%20%28%20JBIDE-16421%2C%20JBIDE-16291%2C%20JBIDE-16277%2C%20JBIDE-15973%2C%20JBIDE-15865%2C%20JBIDE-15798%2C%20JBIDE-15639%2C%20JBIDE-15526%2C%20JBIDE-15276%2C%20JBIDE-15270%2C%20JBIDE-15191%2C%20JBIDE-15148%2C%20JBIDE-14793%2C%20JBIDE-14725%2C%20JBIDE-14697%2C%20JBIDE-13748%2C%20JBIDE-13333%2C%20JBIDE-13297%2C%20JBIDE-12093%2C%20JBIDE-2507%20%29

Or the individual JIRAs:

https://issues.jboss.org/browse/JBIDE-16421
https://issues.jboss.org/browse/JBIDE-16291
https://issues.jboss.org/browse/JBIDE-16277
https://issues.jboss.org/browse/JBIDE-15973
https://issues.jboss.org/browse/JBIDE-15865

https://issues.jboss.org/browse/JBIDE-15798
https://issues.jboss.org/browse/JBIDE-15639
https://issues.jboss.org/browse/JBIDE-15526
https://issues.jboss.org/browse/JBIDE-15276
https://issues.jboss.org/browse/JBIDE-15270

https://issues.jboss.org/browse/JBIDE-15191
https://issues.jboss.org/browse/JBIDE-15148
https://issues.jboss.org/browse/JBIDE-14793
https://issues.jboss.org/browse/JBIDE-14725
https://issues.jboss.org/browse/JBIDE-14697

https://issues.jboss.org/browse/JBIDE-13748
https://issues.jboss.org/browse/JBIDE-13333
https://issues.jboss.org/browse/JBIDE-13297
https://issues.jboss.org/browse/JBIDE-12093
https://issues.jboss.org/browse/JBIDE-2507


-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From nboldt at redhat.com  Tue Feb  4 13:47:28 2014
From: nboldt at redhat.com (Nick Boldt)
Date: Tue, 04 Feb 2014 13:47:28 -0500
Subject: [jbosstools-dev] codefreeze for alpha2 this Thursday
In-Reply-To: <5AD4062C-0078-4CC1-8565-0A6D54A22017@gmail.com>
References: <5AD4062C-0078-4CC1-8565-0A6D54A22017@gmail.com>
Message-ID: <52F135C0.9060205@redhat.com>

Additionally, I've added the upcoming code freeze & milestone release 
dates (as currently planned) to JIRA:

https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel

Task JIRAs will go out Wed night so that everyone knows what needs to be 
done to branch for the upcoming 4.2.0.Alpha2 builds this weekend.

Cheers,

On 02/04/2014 04:34 AM, Max Rydahl Andersen wrote:
> Hey,
>
> Just a reminder that code freeze for 4.2.0.Alpha2 is set to be this
> Thursday. Targeting Luna M5.
>
> Please prepare master to compile and work decently by Thursday.
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From dgolovin at exadel.com  Tue Feb  4 18:11:09 2014
From: dgolovin at exadel.com (Denis Golovin)
Date: Tue, 04 Feb 2014 15:11:09 -0800
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
 to Luna M5
In-Reply-To: <52EFACB8.8050504@redhat.com>
References: <52EBD3D0.1010406@redhat.com> <52EFACB8.8050504@redhat.com>
Message-ID: <52F1738D.7000805@exadel.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140204/0f6e946f/attachment.html 

From rstryker at redhat.com  Tue Feb  4 18:17:29 2014
From: rstryker at redhat.com (Rob Stryker)
Date: Wed, 05 Feb 2014 07:17:29 +0800
Subject: [jbosstools-dev] ASTools 3.0 to be merged Wednessday (today)
Message-ID: <52F17509.1000608@redhat.com>

Hi All:

So a lot of work has gone on to get astools 3.0 in progress with a new 
api and internal structure. Tonight I managed to get a green build 
locally, and so it looks like we may actually squeeze it in for Thursday.

One thing everyone needs to take note of is that the version is now 3.0, 
and so all dependency version ranges should be updated in your own 
plugins to reflect this. Also, if you have binary deps on any astools 
classes, please give it a runthrough (as soon as its available) to 
verify that there's no code api breakages that affect you.

The branch can be found here: 
https://github.com/robstryker/jbosstools-server/tree/JBIDE-15915

If you can, check it out, import it into your workspace, and tell me if 
anything breaks.

The details of what's changed is basically that the "serverBehavior" has 
been completely rewritten, as well as lots of the underlying logic. If 
you were previously reaching into non-public api, you may be broken. If 
you previously depended on adapting a server into a "serverbehavior" (or 
any of their subclasses) you may also be affected.

Most other logic should still work, but it depends how you're going 
about it. If there are breakages, we'll be reverting the change. But our 
goal for right now is to get devs to smoke-test it and make sure it works.

Thanks for all your time.

- Rob Stryker

From rstryker at redhat.com  Tue Feb  4 18:19:00 2014
From: rstryker at redhat.com (Rob Stryker)
Date: Wed, 05 Feb 2014 07:19:00 +0800
Subject: [jbosstools-dev] ASTools 3.0 to be merged Wednessday (today)
Message-ID: <52F17564.2070009@redhat.com>

Hi All:

So a lot of work has gone on to get astools 3.0 in progress with a new 
api and internal structure. Tonight I managed to get a green build 
locally, and so it looks like we may actually squeeze it in for Thursday.

One thing everyone needs to take note of is that the version is now 3.0, 
and so all dependency version ranges should be updated in your own 
plugins to reflect this. Also, if you have binary deps on any astools 
classes, please give it a runthrough (as soon as its available) to 
verify that there's no code api breakages that affect you.

The branch can be found here: 
https://github.com/robstryker/jbosstools-server/tree/JBIDE-15915

If you can, check it out, import it into your workspace, and tell me if 
anything breaks.

The details of what's changed is basically that the "serverBehavior" has 
been completely rewritten, as well as lots of the underlying logic. If 
you were previously reaching into non-public api, you may be broken. If 
you previously depended on adapting a server into a "serverbehavior" (or 
any of their subclasses) you may also be affected.

Most other logic should still work, but it depends how you're going 
about it. If there are breakages, we'll be reverting the change. But our 
goal for right now is to get devs to smoke-test it and make sure it works.

Thanks for all your time.

- Rob Stryker

From mistria at redhat.com  Wed Feb  5 01:14:12 2014
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 05 Feb 2014 07:14:12 +0100
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
 to Luna M5
In-Reply-To: <52F1738D.7000805@exadel.com>
References: <52EBD3D0.1010406@redhat.com> <52EFACB8.8050504@redhat.com>
	<52F1738D.7000805@exadel.com>
Message-ID: <52F1D6B4.20907@redhat.com>

On 02/05/2014 12:11 AM, Denis Golovin wrote:
> Mickael,
>
> when I build it locally with mirroring my local mirror doesn't include 
> sources.
> I guess that is expected behavior. Is that possible to force mirroring 
> w/ sources?
Yes, you can run the command-line to mirror repo adding it the flag 
"-Dmirror-target-to-repo.includeSources". Cf 
https://github.com/jbosstools/jbosstools-maven-plugins/blob/master/tycho-plugins/target-platform-utils/src/main/java/org/jboss/tools/tycho/targets/TargetToRepoMojo.java#L82 
. However, I don't see any good use case for this in our case. Can you 
please elaborate on why you need to do it and can't work with the 
recommended usages (use .target in IDE) ?
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140205/8ef9b232/attachment.html 

From mistria at redhat.com  Wed Feb  5 02:42:30 2014
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 05 Feb 2014 08:42:30 +0100
Subject: [jbosstools-dev] Release Target Platforms 4.40.0.Alpha2
Message-ID: <52F1EB66.7030003@redhat.com>

|JBoss Tools Target Platform 4.40.0.Alpha2 has been released.

Changes
=======

* Usage of Luna M5
* Newer SWTBot
* Newer m2e-apt and m2eclipse-mavenarchiver

Usage
=====
Beta1 is what JBoss Tools 4.2.0.Alpha2 will use.

All jobs in jenkins for branches 4.2.x/8.0.luna and master have been updated to use TP 4.40.0.Alpha2.
Parent pom 4.2.0.Alpha2-SNAPSHOT on master has been updated to use TP 4.40.0.Alpha2.

Download
========

Zip: http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.40.0.Alpha2/jbosstoolstarget-|||4.40.0.Alpha2|.zip
p2 site: http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/|||4.40.0.Alpha2|/REPO/
Git tag: https://github.com/jbosstools/jbosstools-target-platforms/tree/|||4.40.0.Alpha2|

Testing/Development
===================

This should be used by default if you're using the latest SNAPSHOT of parent pom on master, so a simple "mvn clean verify" should be enough to build against this new target platform.
For other cases, you can try it out and use it directly like this:

     $ mvn clean verify -Dtpc.version=|||4.40.0.Alpha2|

For other usage and help (using in IDE, building a mirror locally, using a zip...), plese read https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platforms_for_consumers.md


What's next?
============

Branch 4.40.x for target platform has been prepared for potential upgrades, and it's version is now 4.40.0.Beta1-SNAPSHOT.|

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140205/088db64d/attachment.html 

From nboldt at redhat.com  Wed Feb  5 10:36:55 2014
From: nboldt at redhat.com (Nick Boldt)
Date: Wed, 05 Feb 2014 10:36:55 -0500
Subject: [jbosstools-dev] Fwd: Build failed in Jenkins:
 jbosstools-javaee_master #541
In-Reply-To: <52F0A400.9030603@redhat.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>	<52EEDEDE.4040500@exadel.com>	<52EEE2DC.1010907@exadel.com>	<52EFFBA1.8000508@exadel.com>	<52F015E3.8020103@exadel.com>	<52F029D7.9030805@exadel.com>
	<52F0A400.9030603@redhat.com>
Message-ID: <52F25A97.8080201@redhat.com>

You can extend the timeout provided to individual tests if they require 
more time (pom.xml), or you can extend the timeout for the whole job 
(Jenkins).

Here's an example of how to add more time to a test plugin:

https://github.com/jbosstools/jbosstools-server/blob/master/as/tests/org.jboss.tools.as.test.core/pom.xml#L32

If you need that a job be given more time to run, just edit your job 
directly to increase the timeout, or ask Mickael or myself and we can 
make the change for you.

Cheers,

Nick

On 02/04/2014 03:25 AM, Mickael Istria wrote:
> On 02/04/2014 12:44 AM, Denis Golovin wrote:
>> It is maven or surefire killing timed out process, not jenkins.
> Right, and as far as I know Surefire doesn't provide hooks. So I don't
> know a good way to make you happy with that.
> I have some SSH and VPN access to the Jenkins slave. In case you notice
> one slave is in trouble, feel free to ask me, I'll connect and run
> jstack or whatever helps you to figure out the cause of the issue.
> --
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets
> <http://twitter.com/mickaelistria>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From vrubezhny at exadel.com  Wed Feb  5 10:46:24 2014
From: vrubezhny at exadel.com (Victor Rubezhny)
Date: Wed, 05 Feb 2014 19:46:24 +0400
Subject: [jbosstools-dev] Fwd: Build failed in Jenkins:
 jbosstools-javaee_master #541
In-Reply-To: <52F25A97.8080201@redhat.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>	<52EEDEDE.4040500@exadel.com>	<52EEE2DC.1010907@exadel.com>	<52EFFBA1.8000508@exadel.com>	<52F015E3.8020103@exadel.com>	<52F029D7.9030805@exadel.com>	<52F0A400.9030603@redhat.com>
	<52F25A97.8080201@redhat.com>
Message-ID: <52F25CD0.8050708@exadel.com>

Nick,

we don't need to extend the timeout value. We need to get the stacktrace 
written into some log-file _before_ the test is killed by the timeout.

Usually the fact of some test is timed out mean some hang up or even a 
deadlock occurred, so we need to determine the reason of such a problem 
and as such we need to have a stacktrace logged somehow.

So, we are finding a way to run something like 'jstack -F <PID> | tee 
<test>/target/work/data/.metadata/jstack.log' or something like this 
_right_before_ the test will be killed by surefire as timed out.

/Victor

On 02/05/2014 07:36 PM, Nick Boldt wrote:
> You can extend the timeout provided to individual tests if they require
> more time (pom.xml), or you can extend the timeout for the whole job
> (Jenkins).
>
> Here's an example of how to add more time to a test plugin:
>
> https://github.com/jbosstools/jbosstools-server/blob/master/as/tests/org.jboss.tools.as.test.core/pom.xml#L32
>
> If you need that a job be given more time to run, just edit your job
> directly to increase the timeout, or ask Mickael or myself and we can
> make the change for you.
>
> Cheers,
>
> Nick
>
> On 02/04/2014 03:25 AM, Mickael Istria wrote:
>> On 02/04/2014 12:44 AM, Denis Golovin wrote:
>>> It is maven or surefire killing timed out process, not jenkins.
>> Right, and as far as I know Surefire doesn't provide hooks. So I don't
>> know a good way to make you happy with that.
>> I have some SSH and VPN access to the Jenkins slave. In case you notice
>> one slave is in trouble, feel free to ask me, I'll connect and run
>> jstack or whatever helps you to figure out the cause of the issue.
>> --
>> Mickael Istria
>> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
>> My blog <http://mickaelistria.wordpress.com> - My Tweets
>> <http://twitter.com/mickaelistria>
>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>


From dgolovin at exadel.com  Wed Feb  5 14:00:18 2014
From: dgolovin at exadel.com (Denis Golovin)
Date: Wed, 05 Feb 2014 11:00:18 -0800
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
 to Luna M5
In-Reply-To: <52F1D6B4.20907@redhat.com>
References: <52EBD3D0.1010406@redhat.com> <52EFACB8.8050504@redhat.com>
	<52F1738D.7000805@exadel.com> <52F1D6B4.20907@redhat.com>
Message-ID: <52F28A42.20803@exadel.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140205/c603bfab/attachment.html 

From mistria at redhat.com  Wed Feb  5 14:09:14 2014
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 05 Feb 2014 20:09:14 +0100
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
 to Luna M5
In-Reply-To: <52F28A42.20803@exadel.com>
References: <52EBD3D0.1010406@redhat.com> <52EFACB8.8050504@redhat.com>
	<52F1738D.7000805@exadel.com> <52F1D6B4.20907@redhat.com>
	<52F28A42.20803@exadel.com>
Message-ID: <52F28C5A.9000603@redhat.com>

On 02/05/2014 08:00 PM, Denis Golovin wrote:
> Currently eclipse is having problems with .target updates and shows 
> that some TP elements are missing when they are not.
Can you please put this in a Jira?
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140205/fdbf763e/attachment.html 

From dgolovin at exadel.com  Wed Feb  5 14:15:43 2014
From: dgolovin at exadel.com (Denis Golovin)
Date: Wed, 05 Feb 2014 11:15:43 -0800
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
 to Luna M5
In-Reply-To: <52F28A42.20803@exadel.com>
References: <52EBD3D0.1010406@redhat.com>
	<52EFACB8.8050504@redhat.com>	<52F1738D.7000805@exadel.com>
	<52F1D6B4.20907@redhat.com> <52F28A42.20803@exadel.com>
Message-ID: <52F28DDF.2090709@exadel.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140205/19d35c28/attachment-0001.html 

From mistria at redhat.com  Wed Feb  5 15:23:25 2014
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 05 Feb 2014 21:23:25 +0100
Subject: [jbosstools-dev] Fwd: Build failed in Jenkins:
 jbosstools-javaee_master #541
In-Reply-To: <52F25CD0.8050708@exadel.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>	<52EEDEDE.4040500@exadel.com>	<52EEE2DC.1010907@exadel.com>	<52EFFBA1.8000508@exadel.com>	<52F015E3.8020103@exadel.com>	<52F029D7.9030805@exadel.com>	<52F0A400.9030603@redhat.com>	<52F25A97.8080201@redhat.com>
	<52F25CD0.8050708@exadel.com>
Message-ID: <52F29DBD.3000300@redhat.com>

On 02/05/2014 04:46 PM, Victor Rubezhny wrote:
> we don't need to extend the timeout value. We need to get the stacktrace
> written into some log-file _before_ the test is killed by the timeout.
>
> Usually the fact of some test is timed out mean some hang up or even a
> deadlock occurred, so we need to determine the reason of such a problem
> and as such we need to have a stacktrace logged somehow.
>
> So, we are finding a way to run something like 'jstack -F <PID> | tee
> <test>/target/work/data/.metadata/jstack.log' or something like this
> _right_before_ the test will be killed by surefire as timed out.
Is there a Jira for this request? If not, can you please create one to 
carry on this discussion?
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140205/f656eb64/attachment.html 

From dgolovin at exadel.com  Wed Feb  5 15:31:32 2014
From: dgolovin at exadel.com (Denis Golovin)
Date: Wed, 05 Feb 2014 12:31:32 -0800
Subject: [jbosstools-dev] Fwd: Build failed in Jenkins:
 jbosstools-javaee_master #541
In-Reply-To: <52F29DBD.3000300@redhat.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>	<52EEDEDE.4040500@exadel.com>	<52EEE2DC.1010907@exadel.com>	<52EFFBA1.8000508@exadel.com>	<52F015E3.8020103@exadel.com>	<52F029D7.9030805@exadel.com>	<52F0A400.9030603@redhat.com>	<52F25A97.8080201@redhat.com>	<52F25CD0.8050708@exadel.com>
	<52F29DBD.3000300@redhat.com>
Message-ID: <52F29FA4.1040601@exadel.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140205/a3557054/attachment.html 

From itewksbu at redhat.com  Wed Feb  5 20:38:29 2014
From: itewksbu at redhat.com (Ian Tewksbury)
Date: Wed, 5 Feb 2014 20:38:29 -0500 (EST)
Subject: [jbosstools-dev] Windup Eclipse Plugin v3.0.0 - Export Windup
	reports from Eclipse
Message-ID: <2ec8db18.00008214.0000006a@RHCR9L4HN9>

All,

 

I have just released version 3.0.0 of the Windup Eclipse plugin. In this
new release you can now export Windup reports that are generated in
Eclipse. This allows a developer to easily generate a Windup report in
Eclipse and then export it for sharing with whoever requested a Windup
report.

 

Relevant Links:

*        Demo Video: http://www.youtube.com/watch?v=BbBiQaQj2zk  

*        Project Page: https://github.com/windup/windup-eclipse-plugin

*        Wiki: https://github.com/windup/windup-eclipse-plugin/wiki

*        Windup Project Page: https://github.com/windup/windup 

 

If you wish to spread the news you can re-tweet my post:
https://twitter.com/itewk/status/431238274854580224

 

Enjoy,

~Ian Tewksbury

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140205/5503c5de/attachment.html 

From nboldt at redhat.com  Thu Feb  6 01:47:57 2014
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 06 Feb 2014 01:47:57 -0500
Subject: [jbosstools-dev] ACTION REQUIRED: Code Freeze and Branch for JBoss
 Tools 4.2.0.Alpha2 / JBDS 8.0.0.Alpha2 is today, Feb 6 2014
Message-ID: <52F3301D.5000503@redhat.com>

Task JIRA created for this milestone include:

JBDS              : https://issues.jboss.org/browse/JBDS-2893
JBoss Tools       : https://issues.jboss.org/browse/JBIDE-16447
Aerogear          : https://issues.jboss.org/browse/JBIDE-16448
JST               : https://issues.jboss.org/browse/JBIDE-16449
VPE               : https://issues.jboss.org/browse/JBIDE-16450
JBT Update Sites  : https://issues.jboss.org/browse/JBIDE-16451
Central Discovery : https://issues.jboss.org/browse/JBIDE-16452
Server            : https://issues.jboss.org/browse/JBIDE-16453
Hibernate         : https://issues.jboss.org/browse/JBIDE-16454
Base              : https://issues.jboss.org/browse/JBIDE-16455
OpenShift         : https://issues.jboss.org/browse/JBIDE-16456
JavaEE            : https://issues.jboss.org/browse/JBIDE-16457
Birt              : https://issues.jboss.org/browse/JBIDE-16458
GWT               : https://issues.jboss.org/browse/JBIDE-16459
Forge             : https://issues.jboss.org/browse/JBIDE-16460
Webservices       : https://issues.jboss.org/browse/JBIDE-16461
Arquillian        : https://issues.jboss.org/browse/JBIDE-16462
Central           : https://issues.jboss.org/browse/JBIDE-16463
Portlet           : https://issues.jboss.org/browse/JBIDE-16464
Freemarker        : https://issues.jboss.org/browse/JBIDE-16465
LiveReload        : https://issues.jboss.org/browse/JBIDE-16466


-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From mistria at redhat.com  Thu Feb  6 01:50:30 2014
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 06 Feb 2014 07:50:30 +0100
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
 to Luna M5
In-Reply-To: <52F28DDF.2090709@exadel.com>
References: <52EBD3D0.1010406@redhat.com>
	<52EFACB8.8050504@redhat.com>	<52F1738D.7000805@exadel.com>
	<52F1D6B4.20907@redhat.com> <52F28A42.20803@exadel.com>
	<52F28DDF.2090709@exadel.com>
Message-ID: <52F330B6.60807@redhat.com>

On 02/05/2014 08:15 PM, Denis Golovin wrote:
> Would be good to fix as much such warnings as possible.
I'd rather fix the issue you have in your IDE that prevents you from 
simply using the target platform as recommended.
Can you describe it in a jira please?

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/85fcfee0/attachment.html 

From manderse at redhat.com  Thu Feb  6 03:19:38 2014
From: manderse at redhat.com (Max Andersen)
Date: Thu, 6 Feb 2014 03:19:38 -0500 (EST)
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
	to Luna M5
In-Reply-To: <52F330B6.60807@redhat.com>
References: <52EBD3D0.1010406@redhat.com> <52EFACB8.8050504@redhat.com>
	<52F1738D.7000805@exadel.com> <52F1D6B4.20907@redhat.com>
	<52F28A42.20803@exadel.com> <52F28DDF.2090709@exadel.com>
	<52F330B6.60807@redhat.com>
Message-ID: <17445BBB-1514-4CB1-B771-336B72BA8436@redhat.com>

Please stop saying .target is recommended. We would like it to be but it just can't be since:

It's slow
It needs to download everything on every new workspace
It often fails

Having the tp locally and use as direct platform works much better since

It's faster 
I just need to point to the target dir on every workspace
It doesn't seem to fail(probably because I don't need to download everything every time ;)

/max (sent from my phone)


> On 06/02/2014, at 07.50, Mickael Istria <mistria at redhat.com> wrote:
> 
>> On 02/05/2014 08:15 PM, Denis Golovin wrote:
>> Would be good to fix as much such warnings as possible.
> I'd rather fix the issue you have in your IDE that prevents you from simply using the target platform as recommended.
> Can you describe it in a jira please?
> 
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/8e3e1358/attachment-0001.html 

From mistria at redhat.com  Thu Feb  6 03:42:45 2014
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 06 Feb 2014 09:42:45 +0100
Subject: [jbosstools-dev] Starting 4.32.0 target-platform branch (based on
	Kepler SR2)
Message-ID: <52F34B05.6020306@redhat.com>

Hi all,

I created a new TP branch for 4.32.0.Alpha1-SNAPSHOT, which will be based on Kepler. See https://github.com/jbosstools/jbosstools-target-platforms/tree/4.32.x .
For the moment, it consists in the following changes:
* JBIDE-16409: Use WTP 3.5.2 RC

Please try this new TP to build you component (on jbosstools-4.1.x branch) this PR and yell if there is anything shocking.
A snapshot of this TP is already published, so no need to build it locally

Try it with:
   $ cd /path/to/your/component
   $ mvn clean verify -Dtpc.version=4.32.0.Alpha1-SNAPSHOT

If I don't get bad new by the end of today, I'll update jobs and parent pom for 4.1.x branch to use this target-platform.

Cheers,

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/5069acda/attachment.html 

From manderse at redhat.com  Thu Feb  6 03:56:35 2014
From: manderse at redhat.com (Max Andersen)
Date: Thu, 6 Feb 2014 03:56:35 -0500 (EST)
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
	to Luna M5
In-Reply-To: <17445BBB-1514-4CB1-B771-336B72BA8436@redhat.com>
References: <52EBD3D0.1010406@redhat.com> <52EFACB8.8050504@redhat.com>
	<52F1738D.7000805@exadel.com> <52F1D6B4.20907@redhat.com>
	<52F28A42.20803@exadel.com> <52F28DDF.2090709@exadel.com>
	<52F330B6.60807@redhat.com>
	<17445BBB-1514-4CB1-B771-336B72BA8436@redhat.com>
Message-ID: <980EB0E8-E614-4401-B405-A231C2939C21@redhat.com>



/max (sent from my phone)


> On 06/02/2014, at 09.19, Max Andersen <manderse at redhat.com> wrote:
> 
> Please stop saying .target is recommended. We would like it to be but it just can't be since:
> 

I meant to say "stop saying .target is the only recommended". I know .target is the simplest in theory but in practice it has many downsides. 

/max

> It's slow
> It needs to download everything on every new workspace
> It often fails
> 
> Having the tp locally and use as direct platform works much better since
> 
> It's faster 
> I just need to point to the target dir on every workspace
> It doesn't seem to fail(probably because I don't need to download everything every time ;)
> 
> /max (sent from my phone)
> 
> 
>> On 06/02/2014, at 07.50, Mickael Istria <mistria at redhat.com> wrote:
>> 
>>> On 02/05/2014 08:15 PM, Denis Golovin wrote:
>>> Would be good to fix as much such warnings as possible.
>> I'd rather fix the issue you have in your IDE that prevents you from simply using the target platform as recommended.
>> Can you describe it in a jira please?
>> 
>> -- 
>> Mickael Istria
>> Eclipse developer at JBoss, by Red Hat
>> My blog - My Tweets
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/d7ef0998/attachment.html 

From mistria at redhat.com  Thu Feb  6 05:09:06 2014
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 06 Feb 2014 11:09:06 +0100
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
 to Luna M5
In-Reply-To: <17445BBB-1514-4CB1-B771-336B72BA8436@redhat.com>
References: <52EBD3D0.1010406@redhat.com> <52EFACB8.8050504@redhat.com>
	<52F1738D.7000805@exadel.com> <52F1D6B4.20907@redhat.com>
	<52F28A42.20803@exadel.com> <52F28DDF.2090709@exadel.com>
	<52F330B6.60807@redhat.com>
	<17445BBB-1514-4CB1-B771-336B72BA8436@redhat.com>
Message-ID: <52F35F42.7090200@redhat.com>

On 02/06/2014 09:19 AM, Max Andersen wrote:
> It's slow vs it's faster
This seems to be a misconception. I let you try the following scenario:
At the same time
* start "mvn clean verify -Dmultile-to-repo.includeSources=true" on 
jbosstools-target-platforms/jbosstools/multiple
* Import TP in workspace and click "Set as Target Platform", or (often 
better) go to Preferences > PDE > Target-Platform, select the new TP and 
click "Apply"
The first one to finish is declared winner.

 From my place, IDE takes about 15 minutes to have TP loaded (I tried 3 
times), whereas I started mirroring with Maven 50 minutes ago and it's 
still running.

> [TP in IDE] needs to download everything on every new workspace
That's true. But since mirroring takes more than 3 times more time, then 
it's the same time to update TP in 3 different workspace. There is no 
time saved by mirroring TP with Maven except if you're using it in more 
that 4 workspace.

> It often fails
I wish you would report it when it happens, so we can find out the 
reason and hopefully fix it.


So I confirm and insist that I still (and will probably always) 
recommend using directly .target in IDE, because it's simpler and more 
efficient. 
https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platforms_for_consumers.md#load-in-ide
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/52fe729b/attachment.html 

From mmalina at redhat.com  Thu Feb  6 06:29:42 2014
From: mmalina at redhat.com (Martin Malina)
Date: Thu, 6 Feb 2014 12:29:42 +0100
Subject: [jbosstools-dev] Build failed in Jenkins:
	jbosstools-javaee_master #541
In-Reply-To: <52F29FA4.1040601@exadel.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>	<52EEDEDE.4040500@exadel.com>	<52EEE2DC.1010907@exadel.com>	<52EFFBA1.8000508@exadel.com>	<52F015E3.8020103@exadel.com>	<52F029D7.9030805@exadel.com>	<52F0A400.9030603@redhat.com>	<52F25A97.8080201@redhat.com>	<52F25CD0.8050708@exadel.com>
	<52F29DBD.3000300@redhat.com> <52F29FA4.1040601@exadel.com>
Message-ID: <FF2158D6-1ED4-4A4F-85E4-E835D3721DCE@redhat.com>

Good you mention this, Denis. We noticed this too - when a test times out because of surefire timeout, the job fails, but eclipse keeps running on the slave - at least that?s the (unfortunate) behavior on our local jenkinse instance. Does the Boston jenkins have some plugin installed to prevent this? Nick, do you know?

-Martin

On 5. 2. 2014, at 21:31, Denis Golovin <dgolovin at exadel.com> wrote:

> Guys, it looks like I was wrong about maven killing the process. In my local builds when it fails because of time out eclipse keeps still running. So it could be jenkins killing leftover processes fro job.
> 
> On 02/05/2014 12:23 PM, Mickael Istria wrote:
>> On 02/05/2014 04:46 PM, Victor Rubezhny wrote:
>>> we don't need to extend the timeout value. We need to get the stacktrace 
>>> written into some log-file _before_ the test is killed by the timeout.
>>> 
>>> Usually the fact of some test is timed out mean some hang up or even a 
>>> deadlock occurred, so we need to determine the reason of such a problem 
>>> and as such we need to have a stacktrace logged somehow.
>>> 
>>> So, we are finding a way to run something like 'jstack -F <PID> | tee 
>>> <test>/target/work/data/.metadata/jstack.log' or something like this 
>>> _right_before_ the test will be killed by surefire as timed out.
>> Is there a Jira for this request? If not, can you please create one to carry on this discussion?
>> -- 
>> Mickael Istria
>> Eclipse developer at JBoss, by Red Hat
>> My blog - My Tweets
>> 
>> 
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> 
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

--
Martin Malina
JBoss QA Engineer
Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno, Czech Republic

Tel.: +420 532 294 265




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/c49cf139/attachment.html 

From mistria at redhat.com  Thu Feb  6 06:39:33 2014
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 06 Feb 2014 12:39:33 +0100
Subject: [jbosstools-dev] Build failed in Jenkins:
 jbosstools-javaee_master #541
In-Reply-To: <FF2158D6-1ED4-4A4F-85E4-E835D3721DCE@redhat.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>	<52EEDEDE.4040500@exadel.com>	<52EEE2DC.1010907@exadel.com>	<52EFFBA1.8000508@exadel.com>	<52F015E3.8020103@exadel.com>	<52F029D7.9030805@exadel.com>	<52F0A400.9030603@redhat.com>	<52F25A97.8080201@redhat.com>	<52F25CD0.8050708@exadel.com>
	<52F29DBD.3000300@redhat.com> <52F29FA4.1040601@exadel.com>
	<FF2158D6-1ED4-4A4F-85E4-E835D3721DCE@redhat.com>
Message-ID: <52F37475.8010104@redhat.com>

On 02/06/2014 12:29 PM, Martin Malina wrote:
> Good you mention this, Denis. We noticed this too - when a test times 
> out because of surefire timeout, the job fails, but eclipse keeps 
> running on the slave - at least that?s the (unfortunate) behavior on 
> our local jenkinse instance. Does the Boston jenkins have some plugin 
> installed to prevent this? Nick, do you know?
You should open a bug against Tycho to mention it. Timeout is expected 
to kill the process under test, it it doesn't, it's a bug in Surefire.
Please open it ASAP and make me a CC.
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/dcf3ea38/attachment-0001.html 

From vrubezhny at exadel.com  Thu Feb  6 07:09:32 2014
From: vrubezhny at exadel.com (Victor Rubezhny)
Date: Thu, 06 Feb 2014 16:09:32 +0400
Subject: [jbosstools-dev] Build failed in Jenkins:
 jbosstools-javaee_master #541
In-Reply-To: <52F37475.8010104@redhat.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>	<52EEDEDE.4040500@exadel.com>	<52EEE2DC.1010907@exadel.com>	<52EFFBA1.8000508@exadel.com>	<52F015E3.8020103@exadel.com>	<52F029D7.9030805@exadel.com>	<52F0A400.9030603@redhat.com>	<52F25A97.8080201@redhat.com>	<52F25CD0.8050708@exadel.com>	<52F29DBD.3000300@redhat.com>
	<52F29FA4.1040601@exadel.com>	<FF2158D6-1ED4-4A4F-85E4-E835D3721DCE@redhat.com>
	<52F37475.8010104@redhat.com>
Message-ID: <52F37B7C.9080904@exadel.com>

Looks like common behavior of surefire. I see that eclipse instance 
still running after it's "killed" by timeout too.

can we use it to obtain a stacktrace for such a "killed" eclipse 
process? (I'm doing it locally, but here I'm free to get it's PID and 
run 'jstack -F PID'.)

/Victor

On 02/06/2014 03:39 PM, Mickael Istria wrote:
> On 02/06/2014 12:29 PM, Martin Malina wrote:
>> Good you mention this, Denis. We noticed this too - when a test times 
>> out because of surefire timeout, the job fails, but eclipse keeps 
>> running on the slave - at least that's the (unfortunate) behavior on 
>> our local jenkinse instance. Does the Boston jenkins have some plugin 
>> installed to prevent this? Nick, do you know?
> You should open a bug against Tycho to mention it. Timeout is expected 
> to kill the process under test, it it doesn't, it's a bug in Surefire.
> Please open it ASAP and make me a CC.
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets 
> <http://twitter.com/mickaelistria>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/f3dd6361/attachment.html 

From mistria at redhat.com  Thu Feb  6 07:20:42 2014
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 06 Feb 2014 13:20:42 +0100
Subject: [jbosstools-dev] Build failed in Jenkins:
 jbosstools-javaee_master #541
In-Reply-To: <52F37B7C.9080904@exadel.com>
References: <1345275532.15314.1391342144051.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>	<52EEDEDE.4040500@exadel.com>	<52EEE2DC.1010907@exadel.com>	<52EFFBA1.8000508@exadel.com>	<52F015E3.8020103@exadel.com>	<52F029D7.9030805@exadel.com>	<52F0A400.9030603@redhat.com>	<52F25A97.8080201@redhat.com>	<52F25CD0.8050708@exadel.com>	<52F29DBD.3000300@redhat.com>	<52F29FA4.1040601@exadel.com>	<FF2158D6-1ED4-4A4F-85E4-E835D3721DCE@redhat.com>	<52F37475.8010104@redhat.com>
	<52F37B7C.9080904@exadel.com>
Message-ID: <52F37E1A.1060407@redhat.com>

On 02/06/2014 01:09 PM, Victor Rubezhny wrote:
> Looks like common behavior of surefire. I see that eclipse instance 
> still running after it's "killed" by timeout too.
I think it's a bug. I opened this for discussion 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=427556
Currently, the surefire process probably gets killed when its parent 
process (Maven) ends.

> can we use it to obtain a stacktrace for such a "killed" eclipse 
> process? (I'm doing it locally, but here I'm free to get it's PID and 
> run 'jstack -F PID'.)
Please put this request in a bug. It's not an easy thing.
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/2d6b78ba/attachment.html 

From manderse at redhat.com  Thu Feb  6 09:13:22 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Thu, 06 Feb 2014 15:13:22 +0100
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
 to Luna M5
In-Reply-To: <52F35F42.7090200@redhat.com>
References: <52EBD3D0.1010406@redhat.com> <52EFACB8.8050504@redhat.com>
	<52F1738D.7000805@exadel.com> <52F1D6B4.20907@redhat.com>
	<52F28A42.20803@exadel.com> <52F28DDF.2090709@exadel.com>
	<52F330B6.60807@redhat.com>
	<17445BBB-1514-4CB1-B771-336B72BA8436@redhat.com>
	<52F35F42.7090200@redhat.com>
Message-ID: <1FDAD88E-8C24-4EE0-ADE2-8D213B540CC3@redhat.com>

On 6 Feb 2014, at 11:09, Mickael Istria wrote:

> On 02/06/2014 09:19 AM, Max Andersen wrote:
>> It's slow vs it's faster
> This seems to be a misconception. I let you try the following 
> scenario:
> At the same time
> * start "mvn clean verify -Dmultile-to-repo.includeSources=true" on 
> jbosstools-target-platforms/jbosstools/multiple
> * Import TP in workspace and click "Set as Target Platform", or (often 
> better) go to Preferences > PDE > Target-Platform, select the new TP 
> and click "Apply"
> The first one to finish is declared winner.

No, the first one to let me work in my IDE is the winner. The Mvn task 
does not block my workspace.

Btw. just so we compare the right apples and oranges - which target file 
do you want me to use ? also .multiple ?

> From my place, IDE takes about 15 minutes to have TP loaded (I tried 3 
> times), whereas I started mirroring with Maven 50 minutes ago and it's 
> still running.
>
>> [TP in IDE] needs to download everything on every new workspace
> That's true. But since mirroring takes more than 3 times more time, 
> then it's the same time to update TP in 3 different workspace. There 
> is no time saved by mirroring TP with Maven except if you're using it 
> in more that 4 workspace.

Since I can also use the mvn output as a mirror setup it at least for me 
is much faster and reputable.

btw. if tycho is so much slower - I wonder what it is doing since PDE 
should be doing the same thing...

>> It often fails
> I wish you would report it when it happens, so we can find out the 
> reason and hopefully fix it.

You want me to report broken network connections to eclipse.org mirrored 
servers ?

/max

>
> So I confirm and insist that I still (and will probably always) 
> recommend using directly .target in IDE, because it's simpler and more 
> efficient. 
> https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platforms_for_consumers.md#load-in-ide
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets 
> <http://twitter.com/mickaelistria>


/max
http://about.me/maxandersen


From mistria at redhat.com  Thu Feb  6 09:32:04 2014
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 06 Feb 2014 15:32:04 +0100
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
 to Luna M5
In-Reply-To: <1FDAD88E-8C24-4EE0-ADE2-8D213B540CC3@redhat.com>
References: <52EBD3D0.1010406@redhat.com> <52EFACB8.8050504@redhat.com>
	<52F1738D.7000805@exadel.com> <52F1D6B4.20907@redhat.com>
	<52F28A42.20803@exadel.com> <52F28DDF.2090709@exadel.com>
	<52F330B6.60807@redhat.com>
	<17445BBB-1514-4CB1-B771-336B72BA8436@redhat.com>
	<52F35F42.7090200@redhat.com>
	<1FDAD88E-8C24-4EE0-ADE2-8D213B540CC3@redhat.com>
Message-ID: <52F39CE4.2080808@redhat.com>


> Btw. just so we compare the right apples and oranges - which target 
> file do you want me to use ? also .multiple ?
Yes, multiple only. The one that is recommended to use for development 
in IDE as it provides source "naturally", and which is used by Tycho to 
create the mirror.

> Since I can also use the mvn output as a mirror setup it at least for 
> me is much faster and reputable.
Why do you need a mirror? Tycho caches so much stuff that you already 
have a mirror without even configuring one.

> btw. if tycho is so much slower - I wonder what it is doing since PDE 
> should be doing the same thing...
PDE relies on p2, which relies on ECF, allowing parallel downloads among 
other optimizations. I guess It also fetches only p2 artifacts and 
unpack them locally, dividing by 3 to 4 the amount of downloaded bytes. 
It's just smarter than the mirror goal (that is not part of Tycho, but a 
plugin of ours).

> You want me to report broken network connections to eclipse.org 
> mirrored servers ?
So broken connection are not at all related to how you consume TP. They 
happen for both "mvn verify" and IDE the same way. This is not a 
criterion to tell one thing is better than the other.
FYI, I also often have broken connection when mirroring TP with Maven. 
It's not better for that.

If you feel comfortable with TP, and want to hack stuff, it's up to you. 
But beware that several people in the team didn't fully understand it 
yet and get confused by opposite instructions. The simplest approach is 
the one documented in 
https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platforms_for_consumers.md#load-in-ide 
, which as for only drawback compared to mirroring locally to make 
workspace not usable for the time it fetches artifacts. But it's simple, 
people understand it, and it only cost 15 minutes per workspace every 6 
weeks or so.

I believe there aren't many arguments remaining for not recommending 
simply using .target file in IDE :P
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/4c11d5d2/attachment.html 

From fbricon at gmail.com  Thu Feb  6 09:47:48 2014
From: fbricon at gmail.com (Fred Bricon)
Date: Thu, 6 Feb 2014 15:47:48 +0100
Subject: [jbosstools-dev] Status of bug fixes for memory leaks in WTP
Message-ID: <CAG2ouxSk4tECYZvxWWiFydOB2TmcKBn07T1EC7-5ZQuQr_sj=A@mail.gmail.com>

Hello World,

about a year ago, Snjezana Peco, from Red Hat, opened a series of bugs
about memory leaks in WTP. She also provided patches to fix them. To this
day, the following bugs are still open :

https://bugs.eclipse.org/bugs/show_bug.cgi?id=398568 target: none
https://bugs.eclipse.org/bugs/show_bug.cgi?id=398599 target: none
https://bugs.eclipse.org/bugs/show_bug.cgi?id=399099 target: none
https://bugs.eclipse.org/bugs/show_bug.cgi?id=399523 target: Dali JPA 3.2.3

Could the WTP team take a look a those and give us a heads up?

Thanks,

Fred Bricon

-- 
"Have you tried turning it off and on again" - The IT Crowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/156fba1b/attachment.html 

From fbricon at redhat.com  Thu Feb  6 10:47:04 2014
From: fbricon at redhat.com (Fred Bricon)
Date: Thu, 06 Feb 2014 16:47:04 +0100
Subject: [jbosstools-dev] Pending Luna patches basket
Message-ID: <52F3AE78.3000103@redhat.com>

Hi Team,

I've opened https://issues.jboss.org/browse/JBIDE-16478 to gather 
upstream Luna bugs we've contributed fixes for.

If you know of any other issues with patches waiting to be applied 
upstream, please edit the bug description.

It'll be useful to contact the appropriate eclipse teams for status updates.

Fred

From nboldt at redhat.com  Thu Feb  6 10:54:17 2014
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 06 Feb 2014 10:54:17 -0500
Subject: [jbosstools-dev] FYI: JBoss Tools 4.1.2 jobs have been re-enabled
Message-ID: <52F3B029.4060408@redhat.com>

As we have a new target platform based on Kepler SR2 [1] starting up 
this week, it's time also to start rebuilding the JBT 4.1.x to verify 
they still compile w/ this new platform.

As such I've re-enabled the jobs and have kicked off the "buildflow" job 
to cause everything to be rebuilt (except for birt [2], freemarker [3], 
and gwt [4], which show no significant commits since 4.1.0 was released).

Jobs can be found here:

http://hudson.jboss.org/hudson/view/JBossTools/view/JBossTools_4.1.kepler/

Once the builds have respun, you will be able to find new nightly builds 
per component here:

http://download.jboss.org/jbosstools/builds/staging/

Nightly JBoss Tools builds will be here:

http://download.jboss.org/jbosstools/builds/nightly/core/4.1.kepler/

---

[1] 
http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.32.0.Alpha1-SNAPSHOT/
[2] https://github.com/jbosstools/jbosstools-birt/commits/jbosstools-4.1.x
[3] 
https://github.com/jbosstools/jbosstools-freemarker/commits/jbosstools-4.1.x
[4] https://github.com/jbosstools/jbosstools-gwt/commits/jbosstools-4.1.x

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From ccc at us.ibm.com  Thu Feb  6 11:03:07 2014
From: ccc at us.ibm.com (Carl Anderson)
Date: Thu, 6 Feb 2014 11:03:07 -0500
Subject: [jbosstools-dev] [wtp-dev] Status of bug fixes for memory leaks
	in WTP
In-Reply-To: <CAG2ouxSk4tECYZvxWWiFydOB2TmcKBn07T1EC7-5ZQuQr_sj=A@mail.gmail.com>
References: <CAG2ouxSk4tECYZvxWWiFydOB2TmcKBn07T1EC7-5ZQuQr_sj=A@mail.gmail.com>
Message-ID: <OF77746BBC.C07B5C40-ON85257C77.0057A82D-85257C77.00582D1B@us.ibm.com>


Fred,

	Yes, it does seem that WTP has been overly slow in responding to
these bugs.  However, there are two things that can always help this along:

1) A comment in the bug or an e-mail to the mailing list (which you did,
and you can see that it gets responses)
2) Marking the bugs as a hotbug_request, as per
https://wiki.eclipse.org/WTP/Hotbug_Policy (we review those every week in
our meeting)

Unfortunately, it is too late to get these into WTP 3.5.2 for Kepler SR2.
(A quick glance shows that bug 398599 is a great fix, and I will commit it
as soon as we declare our integration driver for WTP 3.6 - but since we are
declaring our RC3 driver for WTP 3.5.2, this bug does not seem important
enough to risk a regression so late in the shutdown.)  Hopefully we will do
better at addressing these issues in a more timely fashion in the future.

FWIW,

- Carl Anderson
WTP programmer


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Fred Bricon <fbricon at gmail.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |"General discussion of project-wide or architectural issues." <wtp-dev at eclipse.org>                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |jbosstools-dev <jbosstools-dev at lists.jboss.org>, Snjezana Peco <snjezana.peco at redhat.com>                                                         |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |02/06/2014 09:48 AM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |[wtp-dev] Status of bug fixes for memory leaks in WTP                                                                                             |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |wtp-dev-bounces at eclipse.org                                                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Hello World,

about a year ago, Snjezana Peco, from Red Hat, opened a series of bugs
about memory leaks in WTP. She also provided patches to fix them. To this
day, the following bugs are still open :

https://bugs.eclipse.org/bugs/show_bug.cgi?id=398568?target: none
https://bugs.eclipse.org/bugs/show_bug.cgi?id=398599?target: none
https://bugs.eclipse.org/bugs/show_bug.cgi?id=399099?target: none
https://bugs.eclipse.org/bugs/show_bug.cgi?id=399523?target: Dali JPA 3.2.3

Could the WTP team take a look a those and give us a heads up?

Thanks,

Fred Bricon

--
"Have you tried turning it off and on again" - The IT Crowd
_______________________________________________
wtp-dev mailing list
wtp-dev at eclipse.org
https://dev.eclipse.org/mailman/listinfo/wtp-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/2da46ecf/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/2da46ecf/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/2da46ecf/attachment-0001.gif 

From manderse at redhat.com  Thu Feb  6 11:07:00 2014
From: manderse at redhat.com (Max Andersen)
Date: Thu, 6 Feb 2014 11:07:00 -0500 (EST)
Subject: [jbosstools-dev] FYI: JBoss Tools 4.1.2 jobs have been
	re-enabled
In-Reply-To: <52F3B029.4060408@redhat.com>
References: <52F3B029.4060408@redhat.com>
Message-ID: <2AADB1A6-A954-4A03-B594-10E248994E36@redhat.com>

I know I always ask - but please remember to ensure any new commits = must bum version accordingly. 

/max (sent from my phone)


> On 06/02/2014, at 16.54, Nick Boldt <nboldt at redhat.com> wrote:
> 
> As we have a new target platform based on Kepler SR2 [1] starting up 
> this week, it's time also to start rebuilding the JBT 4.1.x to verify 
> they still compile w/ this new platform.
> 
> As such I've re-enabled the jobs and have kicked off the "buildflow" job 
> to cause everything to be rebuilt (except for birt [2], freemarker [3], 
> and gwt [4], which show no significant commits since 4.1.0 was released).
> 
> Jobs can be found here:
> 
> http://hudson.jboss.org/hudson/view/JBossTools/view/JBossTools_4.1.kepler/
> 
> Once the builds have respun, you will be able to find new nightly builds 
> per component here:
> 
> http://download.jboss.org/jbosstools/builds/staging/
> 
> Nightly JBoss Tools builds will be here:
> 
> http://download.jboss.org/jbosstools/builds/nightly/core/4.1.kepler/
> 
> ---
> 
> [1] 
> http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.32.0.Alpha1-SNAPSHOT/
> [2] https://github.com/jbosstools/jbosstools-birt/commits/jbosstools-4.1.x
> [3] 
> https://github.com/jbosstools/jbosstools-freemarker/commits/jbosstools-4.1.x
> [4] https://github.com/jbosstools/jbosstools-gwt/commits/jbosstools-4.1.x
> 
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


From dgolovin at exadel.com  Thu Feb  6 13:06:19 2014
From: dgolovin at exadel.com (Denis Golovin)
Date: Thu, 06 Feb 2014 10:06:19 -0800
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
 to Luna M5
In-Reply-To: <52F39CE4.2080808@redhat.com>
References: <52EBD3D0.1010406@redhat.com> <52EFACB8.8050504@redhat.com>
	<52F1738D.7000805@exadel.com> <52F1D6B4.20907@redhat.com>
	<52F28A42.20803@exadel.com> <52F28DDF.2090709@exadel.com>
	<52F330B6.60807@redhat.com>
	<17445BBB-1514-4CB1-B771-336B72BA8436@redhat.com>
	<52F35F42.7090200@redhat.com>
	<1FDAD88E-8C24-4EE0-ADE2-8D213B540CC3@redhat.com>
	<52F39CE4.2080808@redhat.com>
Message-ID: <52F3CF1B.1050006@exadel.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/de7f9f4a/attachment.html 

From mistria at redhat.com  Thu Feb  6 13:10:20 2014
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 06 Feb 2014 19:10:20 +0100
Subject: [jbosstools-dev] Update Target Platform 4.40.0.Alpha2-SNAPSHOT
 to Luna M5
In-Reply-To: <52F3CF1B.1050006@exadel.com>
References: <52EBD3D0.1010406@redhat.com> <52EFACB8.8050504@redhat.com>
	<52F1738D.7000805@exadel.com> <52F1D6B4.20907@redhat.com>
	<52F28A42.20803@exadel.com> <52F28DDF.2090709@exadel.com>
	<52F330B6.60807@redhat.com>
	<17445BBB-1514-4CB1-B771-336B72BA8436@redhat.com>
	<52F35F42.7090200@redhat.com>
	<1FDAD88E-8C24-4EE0-ADE2-8D213B540CC3@redhat.com>
	<52F39CE4.2080808@redhat.com> <52F3CF1B.1050006@exadel.com>
Message-ID: <52F3D00C.9040802@redhat.com>

On 02/06/2014 07:06 PM, Denis Golovin wrote:
> Problem is it is broken every time when TP is updated, not every new 
> workspace. Eclipse seems to have problem with resolving the content 
> from the same updated .target file.
> So it not that simple. What guys do they just wait as much as the can 
> and keep older version of TP.
Please define "broken" (in a Jira ideally).
I've updated documentation to prefer using Preferences > PDE > 
Target-Platform > Select TP | Reload instead of using "Set as target 
platform". I have the impression this works just fine (and better). That 
would be nice if you could try that and provide feedback.
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140206/3eef8f48/attachment-0001.html 

From fbricon at redhat.com  Thu Feb  6 16:11:25 2014
From: fbricon at redhat.com (Fred Bricon)
Date: Thu, 06 Feb 2014 22:11:25 +0100
Subject: [jbosstools-dev] ACTION REQUIRED: Code Freeze and Branch for
 JBoss Tools 4.2.0.Alpha2 / JBDS 8.0.0.Alpha2 is today, Feb 6 2014
In-Reply-To: <52F3301D.5000503@redhat.com>
References: <52F3301D.5000503@redhat.com>
Message-ID: <52F3FA7D.4030308@redhat.com>

jbosstools-central is done

Le 06/02/2014 07:47, Nick Boldt a ?crit :
> Task JIRA created for this milestone include:
>
> JBDS              : https://issues.jboss.org/browse/JBDS-2893
> JBoss Tools       : https://issues.jboss.org/browse/JBIDE-16447
> Aerogear          : https://issues.jboss.org/browse/JBIDE-16448
> JST               : https://issues.jboss.org/browse/JBIDE-16449
> VPE               : https://issues.jboss.org/browse/JBIDE-16450
> JBT Update Sites  : https://issues.jboss.org/browse/JBIDE-16451
> Central Discovery : https://issues.jboss.org/browse/JBIDE-16452
> Server            : https://issues.jboss.org/browse/JBIDE-16453
> Hibernate         : https://issues.jboss.org/browse/JBIDE-16454
> Base              : https://issues.jboss.org/browse/JBIDE-16455
> OpenShift         : https://issues.jboss.org/browse/JBIDE-16456
> JavaEE            : https://issues.jboss.org/browse/JBIDE-16457
> Birt              : https://issues.jboss.org/browse/JBIDE-16458
> GWT               : https://issues.jboss.org/browse/JBIDE-16459
> Forge             : https://issues.jboss.org/browse/JBIDE-16460
> Webservices       : https://issues.jboss.org/browse/JBIDE-16461
> Arquillian        : https://issues.jboss.org/browse/JBIDE-16462
> Central           : https://issues.jboss.org/browse/JBIDE-16463
> Portlet           : https://issues.jboss.org/browse/JBIDE-16464
> Freemarker        : https://issues.jboss.org/browse/JBIDE-16465
> LiveReload        : https://issues.jboss.org/browse/JBIDE-16466
>
>


From mistria at redhat.com  Fri Feb  7 09:04:31 2014
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 07 Feb 2014 15:04:31 +0100
Subject: [jbosstools-dev] Who uses Eclipse TM and RSE projects?
Message-ID: <52F4E7EF.8060607@redhat.com>

Hi all,

I'm trying to put some stuff out of target-platforms ( 
https://issues.jboss.org/browse/JBIDE-16368 ). One of my candidates for 
deletion is the TM/RSE project at Eclipse.
Who uses this? Is it used by browsersim or cordovasim? If so, do you 
know the features that those projects actually depend on?

Cheers,
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140207/976b5ecf/attachment.html 

From manderse at redhat.com  Fri Feb  7 09:07:08 2014
From: manderse at redhat.com (Max Andersen)
Date: Fri, 7 Feb 2014 09:07:08 -0500 (EST)
Subject: [jbosstools-dev] Who uses Eclipse TM and RSE projects?
In-Reply-To: <52F4E7EF.8060607@redhat.com>
References: <52F4E7EF.8060607@redhat.com>
Message-ID: <0C8A649F-920F-49EF-A5B0-7FE73785CCD9@redhat.com>

That is used by server for remote deployment and very useful for OpenShift and any remote host users. 

So I'm pretty sure we need it both for compile and for providing fully working jbds for those with remote hosts. 

/max (sent from my phone)


> On 07/02/2014, at 15.04, Mickael Istria <mistria at redhat.com> wrote:
> 
> Hi all,
> 
> I'm trying to put some stuff out of target-platforms ( https://issues.jboss.org/browse/JBIDE-16368 ). One of my candidates for deletion is the TM/RSE project at Eclipse.
> Who uses this? Is it used by browsersim or cordovasim? If so, do you know the features that those projects actually depend on?
> 
> Cheers,
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140207/6a9e44e5/attachment.html 

From adietish at redhat.com  Fri Feb  7 09:46:45 2014
From: adietish at redhat.com (=?ISO-8859-1?Q?Andr=E9_Dietisheim?=)
Date: Fri, 07 Feb 2014 15:46:45 +0100
Subject: [jbosstools-dev] Who uses Eclipse TM and RSE projects?
In-Reply-To: <52F4E7EF.8060607@redhat.com>
References: <52F4E7EF.8060607@redhat.com>
Message-ID: <52F4F1D5.7090601@redhat.com>

On 02/07/2014 03:04 PM, Mickael Istria wrote:
> Hi all,
>
> I'm trying to put some stuff out of target-platforms ( 
> https://issues.jboss.org/browse/JBIDE-16368 ). One of my candidates 
> for deletion is the TM/RSE project at Eclipse.
> Who uses this? Is it used by browsersim or cordovasim? If so, do you 
> know the features that those projects actually depend on?
>

jbosstools-server is using it to deploy to a remote server:
https://github.com/jbosstools/jbosstools-server/tree/master/as/features/org.jboss.ide.eclipse.as.server.rse.integration.feature

> Cheers,
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets 
> <http://twitter.com/mickaelistria>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140207/4e8bbc16/attachment.html 

From strada0809prosperi at 126.com  Sun Feb  9 08:13:39 2014
From: strada0809prosperi at 126.com (=?GBK?B?zqLQxdOqz/q/zbf+?=)
Date: Sun, 9 Feb 2014 21:13:39 +0800 (CST)
Subject: [jbosstools-dev] slkfjlsj
Message-ID: <15263f95.6719.14416c823f3.Coremail.strada0809prosperi@126.com>
































-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140209/d30c2fbd/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7890.jpg
Type: image/jpeg
Size: 150215 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140209/d30c2fbd/attachment-0001.jpg 

From nboldt at redhat.com  Mon Feb 10 03:15:48 2014
From: nboldt at redhat.com (Nick Boldt)
Date: Mon, 10 Feb 2014 03:15:48 -0500
Subject: [jbosstools-dev] JBoss Tools Core 4.2.0.Alpha2 bits available for
	QE testing
Message-ID: <52F88AB4.1090200@redhat.com>

As always, these are not FINAL bits, but preliminary results for QE 
testing. Not for redistribution to customers.

Update Sites:
* http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2.core/
* 
http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2.coretests/
* 
http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2.hibernatetools/
* 
http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2.webtools/

Builds:
* 
http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2.core/2014-02-10_02-12-25-B54
* 
http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2.coretests/2014-02-10_02-12-25-B40
* 
http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2.hibernatetools/2014-02-10_02-48-32-B13
* 
http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2.webtools/2014-02-10_02-48-32-B51

JBoss Central:
* 
http://download.jboss.org/jbosstools/targetplatforms/jbtcentraltarget/4.40.0.Alpha2/ 
(JBoss Central - upcoming milestone)

To test the upcoming version of Central, add this to your eclipse.ini 
file after the -vmargs line:
 
-Djboss.discovery.directory.url=http://download.jboss.org/jbosstools/discovery/development/4.2.0.Alpha2/jbosstools-directory.xml
 
-Djboss.discovery.site.url=http://download.jboss.org/jbosstools/discovery/development/4.2.0.Alpha2/

JBoss Tools Target Platforms (This is loaded automatically into Eclipse 
when installing JBoss Tools. Provided here simply for reference):
* 
http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.40.0.Alpha2 
(JBoss Tools - upcoming milestone)

New + Noteworthy: 
http://htmlpreview.github.com/?https://raw.github.com/jbosstools/jbosstools-documentation/master/whatsnew/index.html 
(subject to change) and http://docs.jboss.org/tools/whatsnew/

Schedule / Upcoming Releases: 
https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel


-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From manderse at redhat.com  Mon Feb 10 09:42:05 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 10 Feb 2014 15:42:05 +0100
Subject: [jbosstools-dev] Windup Eclipse Plugin v3.0.0 - Export Windup
 reports from Eclipse
In-Reply-To: <2ec8db18.00008214.0000006a@RHCR9L4HN9>
References: <2ec8db18.00008214.0000006a@RHCR9L4HN9>
Message-ID: <6B8A8744-F1C3-428F-82BB-D72C36C86B78@redhat.com>


> I have just released version 3.0.0 of the Windup Eclipse plugin. In 
> this
> new release you can now export Windup reports that are generated in
> Eclipse. This allows a developer to easily generate a Windup report in
> Eclipse and then export it for sharing with whoever requested a Windup
> report.

Cool.  (I assume its "just" saving the already generated html to a 
separate location?)

Wondering if its time to include this into jboss tools releases ?

> *        Demo Video: http://www.youtube.com/watch?v=BbBiQaQj2zk

seem to only be available in 360 resolution - got something bigger so 
can see what happens ?

btw. I noticed Windup is added to the ever growing root context menu. 
shouldn't this not just be via
the wizard menu or configured first via the Configure submenu instead of 
polluting this context menu ?

> *        Project Page: https://github.com/windup/windup-eclipse-plugin
>
> *        Wiki: https://github.com/windup/windup-eclipse-plugin/wiki
>
> *        Windup Project Page: https://github.com/windup/windup

/max

From manderse at redhat.com  Mon Feb 10 09:51:09 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 10 Feb 2014 15:51:09 +0100
Subject: [jbosstools-dev] Release Target Platforms 4.40.0.Alpha2
In-Reply-To: <52F1EB66.7030003@redhat.com>
References: <52F1EB66.7030003@redhat.com>
Message-ID: <C9B3BDB4-F689-448B-94F0-EE4D6DADB8BE@redhat.com>


> |JBoss Tools Target Platform 4.40.0.Alpha2 has been released.
>
> Changes
> =======
>
> * Usage of Luna M5
> * Newer SWTBot
> * Newer m2e-apt and m2eclipse-mavenarchiver
>
> Usage
> =====
> Beta1 is what JBoss Tools 4.2.0.Alpha2 will use.

I assume you mean 4.40.0.Alpha2 and not "Beta1" ?

> All jobs in jenkins for branches 4.2.x/8.0.luna and master have been 
> updated to use TP 4.40.0.Alpha2.
> Parent pom 4.2.0.Alpha2-SNAPSHOT on master has been updated to use TP 
> 4.40.0.Alpha2.
>
> Download
> ========
>
> Zip: 
> http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.40.0.Alpha2/jbosstoolstarget-|||4.40.0.Alpha2|.zip
> p2 site: 
> http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/|||4.40.0.Alpha2|/REPO/
> Git tag: 
> https://github.com/jbosstools/jbosstools-target-platforms/tree/|||4.40.0.Alpha2|

Those are some screwed up links - did you copy paste/wrong ? The html 
version has the links wrong/incomplete too.

> Testing/Development
> ===================
>
> This should be used by default if you're using the latest SNAPSHOT of 
> parent pom on master, so a simple "mvn clean verify" should be enough 
> to build against this new target platform.
> For other cases, you can try it out and use it directly like this:
>
>  $ mvn clean verify -Dtpc.version=|||4.40.0.Alpha2|

more |||name| funkyness ;)

> For other usage and help (using in IDE, building a mirror locally, 
> using a zip...), plese read 
> https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platforms_for_consumers.md
>
> What's next?
> ============
>
> Branch 4.40.x for target platform has been prepared for potential 
> upgrades, and it's version is now 4.40.0.Beta1-SNAPSHOT.|

cool ;)


/max
http://about.me/maxandersen


From itewksbu at redhat.com  Mon Feb 10 15:55:22 2014
From: itewksbu at redhat.com (Ian Tewksbury)
Date: Mon, 10 Feb 2014 15:55:22 -0500 (EST)
Subject: [jbosstools-dev] Windup Eclipse Plugin v3.0.0 - Export Windup
	reports from Eclipse
In-Reply-To: <6B8A8744-F1C3-428F-82BB-D72C36C86B78@redhat.com>
References: <2ec8db18.00008214.0000006a@RHCR9L4HN9>
	<6B8A8744-F1C3-428F-82BB-D72C36C86B78@redhat.com>
Message-ID: <edcf4478.0000b458.00000063@RHCR9L4HN9>

Max,

I could have sworn I saw HD versions of all three of the demo videos when
I first uploaded them. Now looking at them again they are all small and
grainy. I will have to take a look tonight to see what is going on with
that.

Yes, the wizard takes the already generated report out of the .metadata
folder, zips/tars it up and exports it to the location of your choice.
Also if the report does not already exists then it generates one, and
there is the option to always generate new report before export as well.

As far as adding to the global menu. I did not know where else to put the
new actions. I do have the export wizard in the export wizards dialog, but
the other two options to view in the windup report view and to generate
the windup report need a place to live. Before I first added the menu I
was chatting with my friend who still commits to WTP about where he would
put them, because I was worried about clutter, but he said he would create
a new sub menu as I did.  If you have a better idea for where the "Open in
Windup Report View" and "Generate Windup Report" actions could live I am
all ears. The only reason I also added the "Export Windup Report" action
there as well was because I already had the sub menu and it seemed like a
logical place a user may look for the export function as well as checking
the export dialog. But if a new home is found for the other two actions I
have no problem just having the export wizard live in the export dialog.

As far as adding all of this to the jboss-tools project. The biggest
problem is I still not have a nightly build, and I do not have a nightly
build for the eclipse plugin because I have not been able to coordinate
with Brad to get a nightly build for Windup. The biggest issue with
getting a nightly for windup would be to actually do a windup release and
start doing windup development in a snapshot version rather than 0.7.0
where it has been being done for the past year. I did start that
conversation with Brad a few months back but it stalled out due to life
events. If you all are ready to make this happen on your end then I can
start trying to work with Brad again to get Windup versioning stabilized,
and the nightly builds set up.

Blue Skies,
~Ian

-----Original Message-----
From: Max Rydahl Andersen [mailto:manderse at redhat.com] 
Sent: Monday, February 10, 2014 9:42 AM
To: Ian Tewksbury
Cc: jboss-migration at redhat.com; windup-dev at lists.jboss.org;
jbosstools-dev at lists.jboss.org; Evong Nham; Brad Davis
Subject: Re: [jbosstools-dev] Windup Eclipse Plugin v3.0.0 - Export Windup
reports from Eclipse


> I have just released version 3.0.0 of the Windup Eclipse plugin. In 
> this new release you can now export Windup reports that are generated 
> in Eclipse. This allows a developer to easily generate a Windup report 
> in Eclipse and then export it for sharing with whoever requested a 
> Windup report.

Cool.  (I assume its "just" saving the already generated html to a
separate location?)

Wondering if its time to include this into jboss tools releases ?

> *        Demo Video: http://www.youtube.com/watch?v=BbBiQaQj2zk

seem to only be available in 360 resolution - got something bigger so can
see what happens ?

btw. I noticed Windup is added to the ever growing root context menu. 
shouldn't this not just be via
the wizard menu or configured first via the Configure submenu instead of
polluting this context menu ?

> *        Project Page: https://github.com/windup/windup-eclipse-plugin
>
> *        Wiki: https://github.com/windup/windup-eclipse-plugin/wiki
>
> *        Windup Project Page: https://github.com/windup/windup

/max

From mistria at redhat.com  Wed Feb 12 03:24:59 2014
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 12 Feb 2014 09:24:59 +0100
Subject: [jbosstools-dev] Feedback on JBoss Tools Cordova
In-Reply-To: <52F378C0.5010606@redhat.com>
References: <52F378C0.5010606@redhat.com>
Message-ID: <52FB2FDB.3030004@redhat.com>

Hi all,

I went to see this presentation yesterday 
http://humantalks.com/talks/347-demonstration-de-cordova-cli and had the 
opportunity to show the demo to 4 people who are actual Cordova users.

The presentation, from Sebastien Paul, was mainly showing simple usage 
of Cordova CLI. The demo showed many things that are available in the 
Cordova Eclipse plugins as well (create a project, add plugin, start ios 
emulator...). The only thing he didn't have in his CLI demo compared to 
the video is CordovaSim/Ripple.
He also demoed something nice: a livereload-cordova plugin ( 
https://github.com/fingerproof/cordova-plugin-gapreload and 
https://vimeo.com/81192559 ). This is interesting because it allows to 
configure the packaged application (the apk, ios, or whatever actual 
package) to use livereload to check for updates of some of its 
resources. So you can get livereload enabled on your actual tests 
devices while developing a cordova application and see updates without 
any need to repackage or redeploy the application. It's IMO a great 
productivity boost. Of course, this is something people wouldn't like to 
ship as part of there delivery, and is only good for development 
purpose. See last paragraph for more thoughts on this topic.

Feedback on JBoss Tools Cordova was quite positive. However, no-one did 
even know such tools were existing. Some Cordova users are not at all 
aware of what is JBoss and never started an Eclipse, although they'd be 
glad to use it for Cordova development as shown in the video. Some said 
they'll show the demo to some colleagues who are used to do Android 
development, and that they're pretty sure they'll start using Cordova 
Tools today.
 From this, we can deduce that:
1. Our tools really matches the current needs of users, and that's great
2. Those same tools are unknow to most of potential users. In order to 
become famous, it appears we need to communicate about it in 
Cordova/Phonegap specific channels (mailing-list, get retweeted by 
@apachecordova and @phonegap ).

Related to the concept of having plugins in a dev-mode, we discussed the 
idea of "profiles", similar to what Maven does, which would allow to 
package application in different flavours: Use this plugin in dev-mode 
with this set of properties (for example pointing to local IP address), 
whereas production should not ship this plugin and use the production 
URL... This would be an interesting feature.

That's all folks.
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140212/f3330a24/attachment.html 

From manderse at redhat.com  Wed Feb 12 03:44:02 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 12 Feb 2014 09:44:02 +0100
Subject: [jbosstools-dev] Feedback on JBoss Tools Cordova
In-Reply-To: <52FB2FDB.3030004@redhat.com>
References: <52F378C0.5010606@redhat.com> <52FB2FDB.3030004@redhat.com>
Message-ID: <E7736E73-FB60-412B-9B53-3AD9752C31B2@redhat.com>

> The presentation, from Sebastien Paul, was mainly showing simple usage 
> of Cordova CLI. The demo showed many things that are available in the 
> Cordova Eclipse plugins as well (create a project, add plugin, start 
> ios emulator...). The only thing he didn't have in his CLI demo 
> compared to the video is CordovaSim/Ripple.
> He also demoed something nice: a livereload-cordova plugin ( 
> https://github.com/fingerproof/cordova-plugin-gapreload and 
> https://vimeo.com/81192559 ). This is interesting because it allows to 
> configure the packaged application (the apk, ios, or whatever actual 
> package) to use livereload to check for updates of some of its 
> resources. So you can get livereload enabled on your actual tests 
> devices while developing a cordova application and see updates without 
> any need to repackage or redeploy the application. It's IMO a great 
> productivity boost. Of course, this is something people wouldn't like 
> to ship as part of there delivery, and is only good for development 
> purpose. See last paragraph for more thoughts on this topic.

nice - should work automagically with our live reload implementation too 
if I grok the demo right.

> Feedback on JBoss Tools Cordova was quite positive. However, no-one 
> did even know such tools were existing. Some Cordova users are not at 
> all aware of what is JBoss and never started an Eclipse, although 
> they'd be glad to use it for Cordova development as shown in the 
> video. Some said they'll show the demo to some colleagues who are used 
> to do Android development, and that they're pretty sure they'll start 
> using Cordova Tools today.
> From this, we can deduce that:
> 1. Our tools really matches the current needs of users, and that's 
> great
> 2. Those same tools are unknow to most of potential users. In order to 
> become famous, it appears we need to communicate about it in 
> Cordova/Phonegap specific channels (mailing-list, get retweeted by 
> @apachecordova and @phonegap ).

Good feedback and I agree - more blogs, more pushes needed.

> Related to the concept of having plugins in a dev-mode, we discussed 
> the idea of "profiles", similar to what Maven does, which would allow 
> to package application in different flavours: Use this plugin in 
> dev-mode with this set of properties (for example pointing to local IP 
> address), whereas production should not ship this plugin and use the 
> production URL... This would be an interesting feature.

Yeah everyone needs to reinvent every build tool every 4-5 years ;)

thanks for the writeup!

/max
http://about.me/maxandersen

From mistria at redhat.com  Wed Feb 12 03:49:32 2014
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 12 Feb 2014 09:49:32 +0100
Subject: [jbosstools-dev] Feedback on JBoss Tools Cordova
In-Reply-To: <E7736E73-FB60-412B-9B53-3AD9752C31B2@redhat.com>
References: <52F378C0.5010606@redhat.com> <52FB2FDB.3030004@redhat.com>
	<E7736E73-FB60-412B-9B53-3AD9752C31B2@redhat.com>
Message-ID: <52FB359C.8000404@redhat.com>

On 02/12/2014 09:44 AM, Max Rydahl Andersen wrote:
>> The presentation, from Sebastien Paul, was mainly showing simple 
>> usage of Cordova CLI. The demo showed many things that are available 
>> in the Cordova Eclipse plugins as well (create a project, add plugin, 
>> start ios emulator...). The only thing he didn't have in his CLI demo 
>> compared to the video is CordovaSim/Ripple.
>> He also demoed something nice: a livereload-cordova plugin ( 
>> https://github.com/fingerproof/cordova-plugin-gapreload and 
>> https://vimeo.com/81192559 ). This is interesting because it allows 
>> to configure the packaged application (the apk, ios, or whatever 
>> actual package) to use livereload to check for updates of some of its 
>> resources. So you can get livereload enabled on your actual tests 
>> devices while developing a cordova application and see updates 
>> without any need to repackage or redeploy the application. It's IMO a 
>> great productivity boost. Of course, this is something people 
>> wouldn't like to ship as part of there delivery, and is only good for 
>> development purpose. See last paragraph for more thoughts on this topic.
>
> nice - should work automagically with our live reload implementation 
> too if I grok the demo right.
Yes, but the plugin requires to configure the URL of livereload server. 
So JBoss Tools Cordova should expose a property or provide a hook to 
avoid hardcoding this property in the plugin config.
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140212/4aeee341/attachment-0001.html 

From manderse at redhat.com  Wed Feb 12 05:25:17 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 12 Feb 2014 11:25:17 +0100
Subject: [jbosstools-dev] Feedback on JBoss Tools Cordova
In-Reply-To: <52FB359C.8000404@redhat.com>
References: <52F378C0.5010606@redhat.com> <52FB2FDB.3030004@redhat.com>
	<E7736E73-FB60-412B-9B53-3AD9752C31B2@redhat.com>
	<52FB359C.8000404@redhat.com>
Message-ID: <ABC50007-B4BA-47B4-A181-CDC5B3EEFDA0@redhat.com>

On 12 Feb 2014, at 9:49, Mickael Istria wrote:

> On 02/12/2014 09:44 AM, Max Rydahl Andersen wrote:
>>> The presentation, from Sebastien Paul, was mainly showing simple 
>>> usage of Cordova CLI. The demo showed many things that are available 
>>> in the Cordova Eclipse plugins as well (create a project, add 
>>> plugin, start ios emulator...). The only thing he didn't have in his 
>>> CLI demo compared to the video is CordovaSim/Ripple.
>>> He also demoed something nice: a livereload-cordova plugin ( 
>>> https://github.com/fingerproof/cordova-plugin-gapreload and 
>>> https://vimeo.com/81192559 ). This is interesting because it allows 
>>> to configure the packaged application (the apk, ios, or whatever 
>>> actual package) to use livereload to check for updates of some of 
>>> its resources. So you can get livereload enabled on your actual 
>>> tests devices while developing a cordova application and see updates 
>>> without any need to repackage or redeploy the application. It's IMO 
>>> a great productivity boost. Of course, this is something people 
>>> wouldn't like to ship as part of there delivery, and is only good 
>>> for development purpose. See last paragraph for more thoughts on 
>>> this topic.
>>
>> nice - should work automagically with our live reload implementation 
>> too if I grok the demo right.
> Yes, but the plugin requires to configure the URL of livereload 
> server. So JBoss Tools Cordova should expose a property or provide a 
> hook to avoid hardcoding this property in the plugin config.

isn't this the same for the live reload mac app ?

/max
http://about.me/maxandersen

From mistria at redhat.com  Wed Feb 12 05:29:35 2014
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 12 Feb 2014 11:29:35 +0100
Subject: [jbosstools-dev] Feedback on JBoss Tools Cordova
In-Reply-To: <ABC50007-B4BA-47B4-A181-CDC5B3EEFDA0@redhat.com>
References: <52F378C0.5010606@redhat.com> <52FB2FDB.3030004@redhat.com>
	<E7736E73-FB60-412B-9B53-3AD9752C31B2@redhat.com>
	<52FB359C.8000404@redhat.com>
	<ABC50007-B4BA-47B4-A181-CDC5B3EEFDA0@redhat.com>
Message-ID: <52FB4D0F.1080904@redhat.com>

On 02/12/2014 11:25 AM, Max Rydahl Andersen wrote:
> On 12 Feb 2014, at 9:49, Mickael Istria wrote:
>> On 02/12/2014 09:44 AM, Max Rydahl Andersen wrote:
>>>> The presentation, from Sebastien Paul, was mainly showing simple 
>>>> usage of Cordova CLI. The demo showed many things that are 
>>>> available in the Cordova Eclipse plugins as well (create a project, 
>>>> add plugin, start ios emulator...). The only thing he didn't have 
>>>> in his CLI demo compared to the video is CordovaSim/Ripple.
>>>> He also demoed something nice: a livereload-cordova plugin ( 
>>>> https://github.com/fingerproof/cordova-plugin-gapreload and 
>>>> https://vimeo.com/81192559 ). This is interesting because it allows 
>>>> to configure the packaged application (the apk, ios, or whatever 
>>>> actual package) to use livereload to check for updates of some of 
>>>> its resources. So you can get livereload enabled on your actual 
>>>> tests devices while developing a cordova application and see 
>>>> updates without any need to repackage or redeploy the application. 
>>>> It's IMO a great productivity boost. Of course, this is something 
>>>> people wouldn't like to ship as part of there delivery, and is only 
>>>> good for development purpose. See last paragraph for more thoughts 
>>>> on this topic.
>>> nice - should work automagically with our live reload implementation 
>>> too if I grok the demo right.
>> Yes, but the plugin requires to configure the URL of livereload 
>> server. So JBoss Tools Cordova should expose a property or provide a 
>> hook to avoid hardcoding this property in the plugin config.
> isn't this the same for the live reload mac app ?
Yes, he had to configure the plugin with cordova CLI to set the right 
IP. It was an annoying set (need to find out the IP, copy-paste it...)
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140212/6ab47732/attachment.html 

From manderse at redhat.com  Wed Feb 12 05:33:27 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 12 Feb 2014 11:33:27 +0100
Subject: [jbosstools-dev] Feedback on JBoss Tools Cordova
In-Reply-To: <52FB4D0F.1080904@redhat.com>
References: <52F378C0.5010606@redhat.com> <52FB2FDB.3030004@redhat.com>
	<E7736E73-FB60-412B-9B53-3AD9752C31B2@redhat.com>
	<52FB359C.8000404@redhat.com>
	<ABC50007-B4BA-47B4-A181-CDC5B3EEFDA0@redhat.com>
	<52FB4D0F.1080904@redhat.com>
Message-ID: <240DA64D-ECE3-4519-91F4-93CEB1FB286E@redhat.com>

> Yes, he had to configure the plugin with cordova CLI to set the right 
> IP. It was an annoying set (need to find out the IP, copy-paste it...)

yeah, welcome to mobile development ;)

Honestly - I don't think much can be done about this since it depends on 
how your machine is setup and the plugin needs to know the public IP 
which just need to be set once (hopefully)

/max
http://about.me/maxandersen

From mistria at redhat.com  Wed Feb 12 05:36:13 2014
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 12 Feb 2014 11:36:13 +0100
Subject: [jbosstools-dev] Feedback on JBoss Tools Cordova
In-Reply-To: <240DA64D-ECE3-4519-91F4-93CEB1FB286E@redhat.com>
References: <52F378C0.5010606@redhat.com> <52FB2FDB.3030004@redhat.com>
	<E7736E73-FB60-412B-9B53-3AD9752C31B2@redhat.com>
	<52FB359C.8000404@redhat.com>
	<ABC50007-B4BA-47B4-A181-CDC5B3EEFDA0@redhat.com>
	<52FB4D0F.1080904@redhat.com>
	<240DA64D-ECE3-4519-91F4-93CEB1FB286E@redhat.com>
Message-ID: <52FB4E9D.8080205@redhat.com>

On 02/12/2014 11:33 AM, Max Rydahl Andersen wrote:
> Honestly - I don't think much can be done about this since it depends 
> on how your machine is setup and the plugin needs to know the public 
> IP which just need to be set once (hopefully)
The tool (or plugin installation hook) could find the public IP of the 
machine and set it automatically. Or even do that everytime the 
application is packed before deployment.

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140212/cea39b70/attachment.html 

From manderse at redhat.com  Wed Feb 12 06:01:59 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 12 Feb 2014 12:01:59 +0100
Subject: [jbosstools-dev] Feedback on JBoss Tools Cordova
In-Reply-To: <52FB4E9D.8080205@redhat.com>
References: <52F378C0.5010606@redhat.com> <52FB2FDB.3030004@redhat.com>
	<E7736E73-FB60-412B-9B53-3AD9752C31B2@redhat.com>
	<52FB359C.8000404@redhat.com>
	<ABC50007-B4BA-47B4-A181-CDC5B3EEFDA0@redhat.com>
	<52FB4D0F.1080904@redhat.com>
	<240DA64D-ECE3-4519-91F4-93CEB1FB286E@redhat.com>
	<52FB4E9D.8080205@redhat.com>
Message-ID: <CF1C1C12-6E12-4F02-B365-3A2B8471DE52@redhat.com>

On 12 Feb 2014, at 11:36, Mickael Istria wrote:

> On 02/12/2014 11:33 AM, Max Rydahl Andersen wrote:
>> Honestly - I don't think much can be done about this since it depends 
>> on how your machine is setup and the plugin needs to know the public 
>> IP which just need to be set once (hopefully)
> The tool (or plugin installation hook) could find the public IP of the 
> machine and set it automatically. Or even do that everytime the 
> application is packed before deployment.

yeah once there is a build tool for such apps.

Also there is no (easy) way for a machine to know its public IP, it 
knows its local ip.

I think it would be easier to simply update that file depending on your 
own config.

/max
http://about.me/maxandersen

From nboldt at redhat.com  Wed Feb 12 19:32:45 2014
From: nboldt at redhat.com (Nick Boldt)
Date: Wed, 12 Feb 2014 19:32:45 -0500
Subject: [jbosstools-dev] JBoss Tools Core 4.2.0.Alpha2a bits available for
	QE testing
Message-ID: <52FC12AD.4010608@redhat.com>

As always, these are not FINAL bits, but preliminary results for QE 
testing. Not for redistribution to customers.

Update Sites:
* 
http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2a.core/
* 
http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2a.coretests/
* 
http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2a.hibernatetools/
* 
http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2a.webtools/

Builds:
* 
http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2a.core/2014-02-12_11-22-30-B82
* 
http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2a.coretests/2014-02-12_11-17-18-B68
* 
http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2a.hibernatetools/2014-02-11_11-52-33-B29
* 
http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2a.webtools/2014-02-12_12-25-08-B78

JBoss Central:
* 
http://download.jboss.org/jbosstools/targetplatforms/jbtcentraltarget/4.40.0.Alpha2/ 
(JBoss Central - upcoming milestone)

To test the upcoming version of Central, add this to your eclipse.ini 
file after the -vmargs line:
 
-Djboss.discovery.directory.url=http://download.jboss.org/jbosstools/discovery/development/4.2.0.Alpha2a/jbosstools-directory.xml
 
-Djboss.discovery.site.url=http://download.jboss.org/jbosstools/discovery/development/4.2.0.Alpha2a/

JBoss Tools Target Platforms (This is loaded automatically into Eclipse 
when installing JBoss Tools. Provided here simply for reference):
* 
http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.40.0.Alpha2 
(JBoss Tools - upcoming milestone)

New + Noteworthy: 
http://htmlpreview.github.com/?https://raw.github.com/jbosstools/jbosstools-documentation/master/whatsnew/index.html 
(subject to change) and http://docs.jboss.org/tools/whatsnew/

Schedule / Upcoming Releases: 
https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel

--

Changes prompting this respin-a are:
https://issues.jboss.org/issues/?jql=labels%20in%20%28%22respin-a%22%29%20and%20%28%28project%20in%20%28%22JBDS%22%29%20and%20fixversion%20in%20%28%228.0.0.Alpha2%22%29%29%20or%20%28project%20in%20%28%22JBIDE%22%2C%22TOOLSDOC%22%29%20and%20fixversion%20in%20%28%224.2.0.Alpha2%22%29%29%29


-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From max.andersen at gmail.com  Thu Feb 13 08:50:11 2014
From: max.andersen at gmail.com (Max Rydahl Andersen)
Date: Thu, 13 Feb 2014 14:50:11 +0100
Subject: [jbosstools-dev] staged website have moved
Message-ID: <B6002E3C-3DC6-44F6-9351-AB3CAE84D608@gmail.com>

Just a FYI:

I've enabled rsync to http://tools-stg.jboss.org/ meaning the github 
pages on master jbosstools-website is no longer relevant.

I've deleted the gh-pages branch meaning the old stage website on 
http://jbosstools.github.io/jbosstools-website/ is now gone.

Please use http://tools-stg.jboss.org/ instead now if you are giving 
feedback to https://issues.jboss.org/browse/JBIDE-12355

Thanks,
/max
http://about.me/maxandersen

From max.andersen at gmail.com  Fri Feb 14 06:21:04 2014
From: max.andersen at gmail.com (Max Rydahl Andersen)
Date: Fri, 14 Feb 2014 12:21:04 +0100
Subject: [jbosstools-dev] IMPORTANT: Testing in PDE is *never* enough
Message-ID: <795CB275-7CF0-4167-A5A4-EB2AD048EB94@gmail.com>

Hi team,

The last two blocking issues for Alpha2:

https://issues.jboss.org/browse/JBIDE-16572 and 
https://issues.jboss.org/browse/JBIDE-16430

shows that yet again we need to remember that it is *not* sufficient to 
test your plugin
in isolation from your perfect development environment.

In this case it was a missing plugin entry in feature.xml and a bug in 
Luna M5 that would have been
visible several weeks ago.

Yes, it is human to error and failure is much better than no progress at 
all.

But QE should not have to fight so easily avoidable and basic failures 
like this.

Please take the time necessary to try out your plugins new feature in 
the actually distributed
environment with all plugins installed and we would not have to hustle 
so close to the release.

This time combines pretty well together with writing your New and 
noteworthy https://issues.jboss.org/browse/JBIDE-16551
which also is part of the code freeze week.

Thanks,
/max
http://about.me/maxandersen

From mistria at redhat.com  Fri Feb 14 06:36:01 2014
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 14 Feb 2014 12:36:01 +0100
Subject: [jbosstools-dev] IMPORTANT: Testing in PDE is *never* enough
In-Reply-To: <795CB275-7CF0-4167-A5A4-EB2AD048EB94@gmail.com>
References: <795CB275-7CF0-4167-A5A4-EB2AD048EB94@gmail.com>
Message-ID: <52FDFFA1.4090300@redhat.com>

I'd like to add that you can always get access to the "snapshot" build 
of JBoss Tools. When you push a changes, it should be maximum a few 
hours before it is available there; so if you push in the morning, then 
you should be able to test the actual result in the afternoon.
The link is 
http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-sites.aggregate.site_master/all/repo/

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140214/bef7adfa/attachment.html 

From mistria at redhat.com  Fri Feb 14 12:30:48 2014
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 14 Feb 2014 18:30:48 +0100
Subject: [jbosstools-dev] JBoss Tools Core 4.2.0.Alpha2b bits available for
	QE testing
Message-ID: <52FE52C8.3080306@redhat.com>

JBoss Tools Core 4.2.0.Alpha1 bits available for QE testing

As always, these are not FINAL bits, but preliminary results for QE testing. Not for redistribution to customers.

Update Sites:
* http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2b.core/
* http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2b.coretests/
* http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2b.webtools/

Builds:
* http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2b.core/${coreBuildID}
* http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2b.coretests/${coretestsBuildID}
* http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2b.webtools/${webtoolsBuildID}

JBoss Central:
* http://download.jboss.org/jbosstools/targetplatforms/jbtcentraltarget/kepler/ (JBoss Central - current release)
* http://download.jboss.org/jbosstools/targetplatforms/jbtcentraltarget/4.40.0.Alpha2/ (JBoss Central - upcoming milestone)

To test the upcoming version of Central, add this to your eclipse.ini file after the -vmargs line:
  -Djboss.discovery.directory.url=http://download.jboss.org/jbosstools/discovery/development/4.2.0.Alpha2b/jbosstools-directory.xml
  -Djboss.discovery.site.url=http://download.jboss.org/jbosstools/discovery/development/4.2.0.Alpha2b/

JBoss Tools Target Platforms (This is loaded automatically into Eclipse when installing JBoss Tools. Provided here simply for reference):
* http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/kepler/ (JBoss Tools - current release)
* http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.40.0.Alpha2 (JBoss Tools - upcoming milestone)



New + Noteworthy: http://htmlpreview.github.com/?https://raw.github.com/jbosstools/jbosstools-documentation/master/whatsnew/index.html (subject to change) and http://docs.jboss.org/tools/whatsnew/

Schedule / Upcoming Releases: https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel

Changes prompting this "respin-b" are:
https://issues.jboss.org/issues/?jql=labels%20in%20%28%22'respin-b'%22%29%20and%20%28%28project%20in%20%28%22JBDS%22%29%20and%20fixversion%20in%20%28%22'4.2.0.Alpha2'%22%2

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140214/cb475ad1/attachment.html 

From psrna at redhat.com  Mon Feb 17 05:05:58 2014
From: psrna at redhat.com (Pavol Srna)
Date: Mon, 17 Feb 2014 11:05:58 +0100
Subject: [jbosstools-dev] JBoss Tools Core 4.2.0.Alpha2b bits available
 for QE testing
In-Reply-To: <52FE52C8.3080306@redhat.com>
References: <52FE52C8.3080306@redhat.com>
Message-ID: <5301DF06.7020707@redhat.com>

Hi Mickael,

On 02/14/2014 06:30 PM, Mickael Istria wrote:
> JBoss Tools Core 4.2.0.Alpha1 bits available for QE testing
>
> As always, these are not FINAL bits, but preliminary results for QE testing. Not for redistribution to customers.
>
> Update Sites:
> *http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2b.core/
> *http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2b.coretests/
> *http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha2b.webtools/

The links below are broken. ${coreBuildID}, ${coretestsBuildID}, 
${webtoolsBuildID} are not evaluated properly.

> Builds:
> *http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2b.core/${coreBuildID}
> *http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2b.coretests/${coretestsBuildID}
> *http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2b.webtools/${webtoolsBuildID}
>
> JBoss Central:
> *http://download.jboss.org/jbosstools/targetplatforms/jbtcentraltarget/kepler/  (JBoss Central - current release)
> *http://download.jboss.org/jbosstools/targetplatforms/jbtcentraltarget/4.40.0.Alpha2/  (JBoss Central - upcoming milestone)
>
> To test the upcoming version of Central, add this to your eclipse.ini file after the -vmargs line:
>   -Djboss.discovery.directory.url=http://download.jboss.org/jbosstools/discovery/development/4.2.0.Alpha2b/jbosstools-directory.xml
>   -Djboss.discovery.site.url=http://download.jboss.org/jbosstools/discovery/development/4.2.0.Alpha2b/
>
> JBoss Tools Target Platforms (This is loaded automatically into Eclipse when installing JBoss Tools. Provided here simply for reference):
> *http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/kepler/  (JBoss Tools - current release)
> *http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.40.0.Alpha2  (JBoss Tools - upcoming milestone)
>
>
>
> New + Noteworthy:http://htmlpreview.github.com/?https://raw.github.com/jbosstools/jbosstools-documentation/master/whatsnew/index.html  (subject to change) andhttp://docs.jboss.org/tools/whatsnew/
>
> Schedule / Upcoming Releases:https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel
>
> Changes prompting this "respin-b" are:
> https://issues.jboss.org/issues/?jql=labels%20in%20%28%22'respin-b'%22%29%20and%20%28%28project%20in%20%28%22JBDS%22%29%20and%20fixversion%20in%20%28%22'4.2.0.Alpha2'%22%2
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets 
> <http://twitter.com/mickaelistria>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


-- 
Pavol Srna
QA Engineer, JBDS
Phone: +420 532 294 352

Red Hat Czech
Purkynova 99, 612 00 Brno, Czech Republic

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140217/f55faa6b/attachment.html 

From mistria at redhat.com  Mon Feb 17 05:11:39 2014
From: mistria at redhat.com (Mickael Istria)
Date: Mon, 17 Feb 2014 11:11:39 +0100
Subject: [jbosstools-dev] JBoss Tools Core 4.2.0.Alpha2b bits available
 for QE testing
In-Reply-To: <5301DF06.7020707@redhat.com>
References: <52FE52C8.3080306@redhat.com> <5301DF06.7020707@redhat.com>
Message-ID: <5301E05B.2070702@redhat.com>

On 02/17/2014 11:05 AM, Pavol Srna wrote:
> The links below are broken. ${coreBuildID}, ${coretestsBuildID}, 
> ${webtoolsBuildID} are not evaluated properly.
Sorry about that. I copy-pasted to blindly and missed this part.

Builds:
*http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2b.core/2014-02-14_09-54-39-B84/
*http://download.jboss.org/jbosstools/builds/development/4.2.0.Alpha2b.coretests/2014-02-14_11-13-25-B72

There is no Alpha2b for webtools (nothing changed).

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140217/e974217c/attachment.html 

From mistria at redhat.com  Thu Feb 20 12:21:11 2014
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 20 Feb 2014 18:21:11 +0100
Subject: [jbosstools-dev] =?utf-8?q?ACTION_REQUIRED=3A_Project_leads=2C_pl?=
 =?utf-8?q?ease_tag_your_projects_=5B_branch_jbosstools-4=2E2=2E0=2EAlpha2?=
 =?utf-8?b?eCDihpIgdGFnIGpib3NzdG9vbHMtNC4yLjAuQWxwaGEyIF0=?=
Message-ID: <53063987.9040101@redhat.com>

Project leads, please tag your projects!

   git fetch origin jbosstools-4.2.0.Alpha2x
   git tag jbosstools-4.2.0.Alpha2 FETCH_HEAD
   git push origin jbosstools-4.2.0.Alpha2

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140220/a29ad47e/attachment-0001.html 

From mistria at redhat.com  Thu Feb 20 12:42:20 2014
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 20 Feb 2014 18:42:20 +0100
Subject: [jbosstools-dev] JBoss Tools 4.2.0.Alpha2 is available
Message-ID: <53063E7C.4000503@redhat.com>

JBoss Tools 4.2.0.Alpha2 is now available.

This is a development release aimed at Eclipse 4.4.M5 (Luna M5) users.

Update Site: http://download.jboss.org/jbosstools/updates/development/luna/
Installation + Download Pages:
* http://www.jboss.org/tools/download
* http://www.jboss.org/tools/download/dev/4_2_x
* http://www.jboss.org/tools/download/installation/update_4_2


JBoss Central: This release includes changes to JBoss Central. To see these updates, launch Eclipse with this extra -vmarg in your eclipse.ini:
* -Djboss.discovery.directory.url=http://download.jboss.org/jbosstools/updates/development/luna/jbosstools-directory.xml


New + Noteworthy:
Subject to change, the latest N&N is here:
* http://htmlpreview.github.com/?https://raw.github.com/jbosstools/jbosstools-documentation/master/whatsnew/index.html
* http://docs.jboss.org/tools/whatsnew/

Schedule / Upcoming Releases:
* https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140220/a26c5550/attachment.html 

From adietish at redhat.com  Thu Feb 20 12:51:25 2014
From: adietish at redhat.com (=?UTF-8?B?QW5kcsOpIERpZXRpc2hlaW0=?=)
Date: Thu, 20 Feb 2014 18:51:25 +0100
Subject: [jbosstools-dev]
 =?utf-8?q?ACTION_REQUIRED=3A_Project_leads=2C_pl?=
 =?utf-8?q?ease_tag_your_projects_=5B_branch_jbosstools-4=2E2=2E0=2EAlpha2?=
 =?utf-8?b?eCDihpIgdGFnIGpib3NzdG9vbHMtNC4yLjAuQWxwaGEyIF0=?=
In-Reply-To: <53063987.9040101@redhat.com>
References: <53063987.9040101@redhat.com>
Message-ID: <5306409D.5050301@redhat.com>

done for OpenShift

On 02/20/2014 06:21 PM, Mickael Istria wrote:
> Project leads, please tag your projects!
>
>    git fetch origin jbosstools-4.2.0.Alpha2x
>    git tag jbosstools-4.2.0.Alpha2 FETCH_HEAD
>    git push origin jbosstools-4.2.0.Alpha2
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets 
> <http://twitter.com/mickaelistria>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140220/e5e3624e/attachment.html 

From xcoulon at redhat.com  Thu Feb 20 12:56:55 2014
From: xcoulon at redhat.com (Xavier Coulon)
Date: Thu, 20 Feb 2014 18:56:55 +0100
Subject: [jbosstools-dev]
 =?utf-8?q?ACTION_REQUIRED=3A_Project_leads=2C_pl?=
 =?utf-8?q?ease_tag_your_projects_=5B_branch_jbosstools-4=2E2=2E0=2EAlpha2?=
 =?utf-8?b?eCDihpIgdGFnIGpib3NzdG9vbHMtNC4yLjAuQWxwaGEyIF0=?=
In-Reply-To: <53063987.9040101@redhat.com>
References: <53063987.9040101@redhat.com>
Message-ID: <09294CC1-8D2E-45D5-853B-90C47512419A@redhat.com>

Done for LiveReload and WebServices

Best regards,
/Xavier



On 20 Feb 2014, at 18:21, Mickael Istria <mistria at redhat.com> wrote:

> Project leads, please tag your projects!
> 
>   git fetch origin jbosstools-4.2.0.Alpha2x
>   git tag jbosstools-4.2.0.Alpha2 FETCH_HEAD
>   git push origin jbosstools-4.2.0.Alpha2
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140220/fd8f4e9d/attachment.html 

From manderse at redhat.com  Fri Feb 21 03:43:01 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 21 Feb 2014 09:43:01 +0100
Subject: [jbosstools-dev] JBoss Tools 4.2.0.Alpha2 is available
In-Reply-To: <53063E7C.4000503@redhat.com>
References: <53063E7C.4000503@redhat.com>
Message-ID: <9D956BE2-1424-4CDA-AAA4-59CE670E6990@redhat.com>

On 20 Feb 2014, at 18:42, Mickael Istria wrote:

> JBoss Tools 4.2.0.Alpha2 is now available.
>
> This is a development release aimed at Eclipse 4.4.M5 (Luna M5) users.
>
> Update Site: 
> http://download.jboss.org/jbosstools/updates/development/luna/
> Installation + Download Pages:
> * http://www.jboss.org/tools/download
> * http://www.jboss.org/tools/download/dev/4_2_x
> * http://www.jboss.org/tools/download/installation/update_4_2
>
>
> JBoss Central: This release includes changes to JBoss Central. To see 
> these updates, launch Eclipse with this extra -vmarg in your 
> eclipse.ini:
> * 
> -Djboss.discovery.directory.url=http://download.jboss.org/jbosstools/updates/development/luna/jbosstools-directory.xml

is it not using this by default  ?

if it is not - which directory is it actually using ?

/max


From rstryker at redhat.com  Fri Feb 21 03:24:13 2014
From: rstryker at redhat.com (Rob Stryker)
Date: Fri, 21 Feb 2014 16:24:13 +0800
Subject: [jbosstools-dev] $0 subscription downloads - Stacks integration
	with download manager
Message-ID: <53070D2D.7090302@redhat.com>

Rafael (and others):

So I spent an hour or so yesterday chatting with David Hladky about the 
new download manager rest services which JBosstools intends to use to 
help us download EAP 6.x. It allows for a workflow that can help us get 
terms and conditions, verify credentials, verify agreements have been 
signed, and then provide a download utility with a temporary url that 
expires to download the EAP.

The api and the test server I played with look good so far. JBossTools, 
though, pulls all of its runtime information from jdf-stacks. We 
typically pull our download urls from there.

Currently in stacks, community editions have a "url" for the project 
page, and a "downloadUrl" for a link to a permanent url for the given 
runtime to download.

EAP instances in stacks.yaml only have a url for a project page. When 
the download manager written by David goes live, we'll need to consider 
what to do for stacks.yaml, and I'd prefer to get this stuff sorted now.

I'd like to suggest that we add a new attribute "downloadManagerUrl".  
This will ensure clients know that this is a workflow url and not a 
static url for downloading a file.

There's 2 parts to the rest service written by David. First is the rest 
service url itself, and the second is the file we're requesting. 
Currently a url for one part of the rest workflow (in this example, to 
get terms and conditions) looks like this:

${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar

You can see the two parts are the rest service url (on test server, 
https://www-eng.jboss.org/download-manager/rest/tc)  and the second part 
is what we're requesting (in this case, 
/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar)

I see a few problems here. The first is that, in my opinion, those urls 
are pretty long to be including in stacks.yaml... but luckily the 
download-manager allows for shortened urls, so we could have the 
download-manager server respond to a url like 
${server-root}/rest/tc?downloadURL=jboss-eap-6.0.0.dv.ci-installer.jar. 
The download manager would then map the attribute to the 
/content/blah/blah/sha path and proceed accordingly. So this is easily 
fixed.


The second, is that the rest services do not point to the next url to 
request. For example, if I go to the tc-accepted rest service to see if 
the terms and conditions were accepted yet, it does not point me to the 
next url in the workflow. Because of this, there's really no single 
entry-point in the workflow, and each rest service url is kind of a 
standalone url.

With the second point in mind, we might just want our stacks.yaml 
attribute to say downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar.

The client (in this case jbosstools) would pass that string to the 
download manager rest service it chooses to use. The download-manager 
server would resolve jboss-eap-6.0.0.dv.ci-installer.jar to its more 
specific /content/sha256/23423823423/etc  path, and proceed normally.

One concern with this approach is that the stacks.yaml will never 
include the actual url of the rest service entry point. Even if we 
wanted to have stacks.yaml point to the entry point, there's no one 
entry-point since the rest services do not point to the next step in the 
workflow.

I personally have no problem using the service as it's written now, and 
with stacks.yaml only having a shortened path available, but I wanted to 
get your (and others) feedback on the situation before this gets pushed 
to production, after which we probably won't have much chance to change it.

Any thoughts?

- Rob Stryker

From koen.aers at jboss.com  Fri Feb 21 05:19:39 2014
From: koen.aers at jboss.com (Koen Aers)
Date: Fri, 21 Feb 2014 11:19:39 +0100
Subject: [jbosstools-dev]
 =?utf-8?q?ACTION_REQUIRED=3A_Project_leads=2C_pl?=
 =?utf-8?q?ease_tag_your_projects_=5B_branch_jbosstools-4=2E2=2E0=2EAlpha2?=
 =?utf-8?b?eCDihpIgdGFnIGpib3NzdG9vbHMtNC4yLjAuQWxwaGEyIF0=?=
In-Reply-To: <53063987.9040101@redhat.com>
References: <53063987.9040101@redhat.com>
Message-ID: <8C2336C4-2093-47CA-9E94-90C20DC0AA51@jboss.com>

Done for Forge and Hibernate

Op 20-feb.-2014, om 18:21 heeft Mickael Istria het volgende geschreven:

> Project leads, please tag your projects!
> 
>   git fetch origin jbosstools-4.2.0.Alpha2x
>   git tag jbosstools-4.2.0.Alpha2 FETCH_HEAD
>   git push origin jbosstools-4.2.0.Alpha2
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140221/8d3f3af3/attachment.html 

From benevides at redhat.com  Fri Feb 21 07:16:08 2014
From: benevides at redhat.com (Rafael Benevides)
Date: Fri, 21 Feb 2014 09:16:08 -0300
Subject: [jbosstools-dev] $0 subscription downloads - Stacks integration
 with download manager
In-Reply-To: <53070D2D.7090302@redhat.com>
References: <53070D2D.7090302@redhat.com>
Message-ID: <53074388.8080209@redhat.com>

Hi everybody.

My first suggestion should be to use downloadUrl attribute but given 
that it's a workflowUrl I'm ok to create a label called 
downloadManagerUrl. We can't add an attribute without change the version 
(it breaks stacks-client).

I also liked to use a short version 
downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar. But it lead me 
to think If we can do something like:

*downloadUrl*=downloadManager://jboss-eap-6.0.0.dv.ci-installer.jar

This way we can continue to use the existing *downloadUrl attribute* but 
also emphasizes that this use uses a custom "protocol" that is handled 
by the downloadManager

This is my 2 cents.

Em 21/02/14 05:24, Rob Stryker escreveu:
> Rafael (and others):
>
> So I spent an hour or so yesterday chatting with David Hladky about 
> the new download manager rest services which JBosstools intends to use 
> to help us download EAP 6.x. It allows for a workflow that can help us 
> get terms and conditions, verify credentials, verify agreements have 
> been signed, and then provide a download utility with a temporary url 
> that expires to download the EAP.
>
> The api and the test server I played with look good so far. 
> JBossTools, though, pulls all of its runtime information from 
> jdf-stacks. We typically pull our download urls from there.
>
> Currently in stacks, community editions have a "url" for the project 
> page, and a "downloadUrl" for a link to a permanent url for the given 
> runtime to download.
>
> EAP instances in stacks.yaml only have a url for a project page. When 
> the download manager written by David goes live, we'll need to 
> consider what to do for stacks.yaml, and I'd prefer to get this stuff 
> sorted now.
>
> I'd like to suggest that we add a new attribute "downloadManagerUrl".  
> This will ensure clients know that this is a workflow url and not a 
> static url for downloading a file.
>
> There's 2 parts to the rest service written by David. First is the 
> rest service url itself, and the second is the file we're requesting. 
> Currently a url for one part of the rest workflow (in this example, to 
> get terms and conditions) looks like this:
>
> ${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar 
>
>
> You can see the two parts are the rest service url (on test server, 
> https://www-eng.jboss.org/download-manager/rest/tc)  and the second 
> part is what we're requesting (in this case, 
> /content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar)
>
> I see a few problems here. The first is that, in my opinion, those 
> urls are pretty long to be including in stacks.yaml... but luckily the 
> download-manager allows for shortened urls, so we could have the 
> download-manager server respond to a url like 
> ${server-root}/rest/tc?downloadURL=jboss-eap-6.0.0.dv.ci-installer.jar. The 
> download manager would then map the attribute to the 
> /content/blah/blah/sha path and proceed accordingly. So this is easily 
> fixed.
>
>
> The second, is that the rest services do not point to the next url to 
> request. For example, if I go to the tc-accepted rest service to see 
> if the terms and conditions were accepted yet, it does not point me to 
> the next url in the workflow. Because of this, there's really no 
> single entry-point in the workflow, and each rest service url is kind 
> of a standalone url.
>
> With the second point in mind, we might just want our stacks.yaml 
> attribute to say downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar.
>
> The client (in this case jbosstools) would pass that string to the 
> download manager rest service it chooses to use. The download-manager 
> server would resolve jboss-eap-6.0.0.dv.ci-installer.jar to its more 
> specific /content/sha256/23423823423/etc  path, and proceed normally.
>
> One concern with this approach is that the stacks.yaml will never 
> include the actual url of the rest service entry point. Even if we 
> wanted to have stacks.yaml point to the entry point, there's no one 
> entry-point since the rest services do not point to the next step in 
> the workflow.
>
> I personally have no problem using the service as it's written now, 
> and with stacks.yaml only having a shortened path available, but I 
> wanted to get your (and others) feedback on the situation before this 
> gets pushed to production, after which we probably won't have much 
> chance to change it.
>
> Any thoughts?
>
> - Rob Stryker

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140221/c39e442d/attachment-0001.html 

From mistria at redhat.com  Fri Feb 21 09:28:34 2014
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 21 Feb 2014 15:28:34 +0100
Subject: [jbosstools-dev] Kepler SR2 pre-release
Message-ID: <53076292.7080600@redhat.com>

Hi all,

Kepler SR2 RC4 (which is to become Kepler SR2) is available. EPP builds 
are at 
http://build.eclipse.org/technology/epp/epp_build/kepler/download/20140220-0320/ 
. Those ones will be promoted as the official Kepler SR2 release on 
Wednesday and announced on next Friday.
Testing and finding potential problems now will make it way easier to 
ship our upcoming 4.1.2 release without obvious issue. So I encourage 
those of you who have done some work related to this Kepler SR2 to give 
it a try now and see how it works with your recent development on the 
4.1.x branch. I'm working on setting up the target-platform so we'll be 
able to start adoption for build and tests against this Kepler SR2 later 
today or Monday.

Cheers,
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140221/629b06de/attachment.html 

From manderse at redhat.com  Fri Feb 21 09:22:21 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 21 Feb 2014 15:22:21 +0100
Subject: [jbosstools-dev] $0 subscription downloads - Stacks integration
 with download manager
In-Reply-To: <53070D2D.7090302@redhat.com>
References: <53070D2D.7090302@redhat.com>
Message-ID: <0FB63D69-BCA0-4E63-83D4-1F3ACA30D42A@redhat.com>


> I'd like to suggest that we add a new attribute "downloadManagerUrl".
> This will ensure clients know that this is a workflow url and not a
> static url for downloading a file.

The original idea was that downloadUrl would be sufficient and then just 
a label
to mark it as something that can use the download manager api and the 
tools would
know the url to use for that download mechanism (maybe we could have the 
label be:
downloadmanager: <initial-resturl> ? and you look up that label and know 
what to start from?)

Is that no longer an option ?

> There's 2 parts to the rest service written by David. First is the 
> rest
> service url itself, and the second is the file we're requesting.
> Currently a url for one part of the rest workflow (in this example, to
> get terms and conditions) looks like this:
>
> ${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar
>
> You can see the two parts are the rest service url (on test server,
> https://www-eng.jboss.org/download-manager/rest/tc)  and the second 
> part
> is what we're requesting (in this case,
> /content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar)
>
> I see a few problems here. The first is that, in my opinion, those 
> urls
> are pretty long to be including in stacks.yaml

Irrelevant. Those urls are already used on our download pages so I don't 
see that as a big issue at all.

> The second, is that the rest services do not point to the next url to
> request. For example, if I go to the tc-accepted rest service to see 
> if
> the terms and conditions were accepted yet, it does not point me to 
> the
> next url in the workflow. Because of this, there's really no single
> entry-point in the workflow, and each rest service url is kind of a
> standalone url.

Sounds like something that should get fixed in the download service ?

> With the second point in mind, we might just want our stacks.yaml
> attribute to say 
> downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar.

Rather fix the download service so no such weird details has to leak 
into stacks.yml.

> The client (in this case jbosstools) would pass that string to the
> download manager rest service it chooses to use. The download-manager
> server would resolve jboss-eap-6.0.0.dv.ci-installer.jar to its more
> specific /content/sha256/23423823423/etc  path, and proceed normally.
>
> One concern with this approach is that the stacks.yaml will never
> include the actual url of the rest service entry point. Even if we
> wanted to have stacks.yaml point to the entry point, there's no one
> entry-point since the rest services do not point to the next step in 
> the
> workflow.

lets fix the service to be complete then ?

/max


From dhladky at redhat.com  Fri Feb 21 09:41:42 2014
From: dhladky at redhat.com (David Hladky)
Date: Fri, 21 Feb 2014 09:41:42 -0500 (EST)
Subject: [jbosstools-dev] $0 subscription downloads - Stacks integration
 with download manager
In-Reply-To: <53070D2D.7090302@redhat.com>
References: <53070D2D.7090302@redhat.com>
Message-ID: <465855590.3886408.1392993702233.JavaMail.zimbra@redhat.com>

Hi Rob, 

will you also use the part of the interface, that would allow the user to accept the terms and conditions in Eclipse? It may look better if you do. 

David Hladky

----- Original Message -----
From: "Rob Stryker" <rstryker at redhat.com>
To: "David Hladky" <dhladky at redhat.com>, "Rafael Benevides" <benevides at redhat.com>, "Snjezana Peco" <snjezana.peco at redhat.com>, "jbosstools-dev jbosstools-dev" <jbosstools-dev at lists.jboss.org>
Sent: Friday, 21 February, 2014 9:24:13 AM
Subject: $0 subscription downloads - Stacks integration with download manager

Rafael (and others):

So I spent an hour or so yesterday chatting with David Hladky about the 
new download manager rest services which JBosstools intends to use to 
help us download EAP 6.x. It allows for a workflow that can help us get 
terms and conditions, verify credentials, verify agreements have been 
signed, and then provide a download utility with a temporary url that 
expires to download the EAP.

The api and the test server I played with look good so far. JBossTools, 
though, pulls all of its runtime information from jdf-stacks. We 
typically pull our download urls from there.

Currently in stacks, community editions have a "url" for the project 
page, and a "downloadUrl" for a link to a permanent url for the given 
runtime to download.

EAP instances in stacks.yaml only have a url for a project page. When 
the download manager written by David goes live, we'll need to consider 
what to do for stacks.yaml, and I'd prefer to get this stuff sorted now.

I'd like to suggest that we add a new attribute "downloadManagerUrl".  
This will ensure clients know that this is a workflow url and not a 
static url for downloading a file.

There's 2 parts to the rest service written by David. First is the rest 
service url itself, and the second is the file we're requesting. 
Currently a url for one part of the rest workflow (in this example, to 
get terms and conditions) looks like this:

${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar

You can see the two parts are the rest service url (on test server, 
https://www-eng.jboss.org/download-manager/rest/tc)  and the second part 
is what we're requesting (in this case, 
/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar)

I see a few problems here. The first is that, in my opinion, those urls 
are pretty long to be including in stacks.yaml... but luckily the 
download-manager allows for shortened urls, so we could have the 
download-manager server respond to a url like 
${server-root}/rest/tc?downloadURL=jboss-eap-6.0.0.dv.ci-installer.jar. 
The download manager would then map the attribute to the 
/content/blah/blah/sha path and proceed accordingly. So this is easily 
fixed.


The second, is that the rest services do not point to the next url to 
request. For example, if I go to the tc-accepted rest service to see if 
the terms and conditions were accepted yet, it does not point me to the 
next url in the workflow. Because of this, there's really no single 
entry-point in the workflow, and each rest service url is kind of a 
standalone url.

With the second point in mind, we might just want our stacks.yaml 
attribute to say downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar.

The client (in this case jbosstools) would pass that string to the 
download manager rest service it chooses to use. The download-manager 
server would resolve jboss-eap-6.0.0.dv.ci-installer.jar to its more 
specific /content/sha256/23423823423/etc  path, and proceed normally.

One concern with this approach is that the stacks.yaml will never 
include the actual url of the rest service entry point. Even if we 
wanted to have stacks.yaml point to the entry point, there's no one 
entry-point since the rest services do not point to the next step in the 
workflow.

I personally have no problem using the service as it's written now, and 
with stacks.yaml only having a shortened path available, but I wanted to 
get your (and others) feedback on the situation before this gets pushed 
to production, after which we probably won't have much chance to change it.

Any thoughts?

- Rob Stryker

From mistria at redhat.com  Fri Feb 21 11:52:07 2014
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 21 Feb 2014 17:52:07 +0100
Subject: [jbosstools-dev] Change
Message-ID: <53078437.4080005@redhat.com>

Hi all,

Here is a proposal for a new 4.32.0.Alpha1-SNAPSHOT target platform: https://github.com/jbosstools/jbosstools-target-platforms/pull/37
It consists in the following changes:
* Move to Kepler SR2
** some projects are still using same version that we had for Kepler release (Orbit, m2eclipse, TM, SWTBot)
** most projects have contributed a SR2 build

Please review this PR and yell if there is anything shocking. You can use the following stuff to try to build build the TP locally and try out against your component.
Once this changed is pushed, CI jobs for branch 4.1.x will be updated to use it as TARGET_PLATFORM_MAXIMUM.

Build target-platform:

   $ cd jbosstools-target-platforms
   $ git fetch mistria Kepler-SR2
   $ git checkout FETCH_HEAD
   $ cd jbosstools/multiple
   $ mvn clean install -P \!multiple2repo

Try with just built target-platform:
   $ cd /path/to/your/component
   $ mvn clean verify -Dtpc.version=4.32.0.Alpha1-SNAPSHOT -Pmultiple.target

Cheers,

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140221/292ef23d/attachment.html 

From mistria at redhat.com  Fri Feb 21 11:53:38 2014
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 21 Feb 2014 17:53:38 +0100
Subject: [jbosstools-dev]  Change in TP 4.32.0.Alpha1-SNAPSHOT,
 targetting Kepler SR2
In-Reply-To: <53078437.4080005@redhat.com>
References: <53078437.4080005@redhat.com>
Message-ID: <53078492.7070306@redhat.com>

Hi all,

Here is a proposal for a new 4.32.0.Alpha1-SNAPSHOT target platform:https://github.com/jbosstools/jbosstools-target-platforms/pull/37
It consists in the following changes:
* Move to Kepler SR2
** some projects are still using same version that we had for Kepler release (Orbit, m2eclipse, TM, SWTBot)
** most projects have contributed a SR2 build

Please review this PR and yell if there is anything shocking. You can use the following stuff to try to build build the TP locally and try out against your component.
Once this changed is pushed, CI jobs for branch 4.1.x will be updated to use it as TARGET_PLATFORM_MAXIMUM.

Build target-platform:

   $ cd jbosstools-target-platforms
   $ git fetch mistria Kepler-SR2
   $ git checkout FETCH_HEAD
   $ cd jbosstools/multiple
   $ mvn clean install -P \!multiple2repo

Try with just built target-platform:
   $ cd /path/to/your/component
   $ mvn clean verify -Dtpc.version=4.32.0.Alpha1-SNAPSHOT -Pmultiple.target

Cheers,

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140221/083bfc08/attachment.html 

From nboldt at redhat.com  Fri Feb 21 12:31:38 2014
From: nboldt at redhat.com (Nick Boldt)
Date: Fri, 21 Feb 2014 12:31:38 -0500
Subject: [jbosstools-dev] Change in TP 4.32.0.Alpha1-SNAPSHOT,
 targeting Kepler SR2
In-Reply-To: <53078437.4080005@redhat.com>
References: <53078437.4080005@redhat.com>
Message-ID: <53078D7A.7020801@redhat.com>

FYI, if you use hub [1], then the process for checking out Mickael's 
topic branch / PR is simply:

$ cd jbosstools-target-platforms
$ git checkout 
https://github.com/jbosstools/jbosstools-target-platforms/pull/37

[1] http://hub.github.com/

Added bonus is that if you don't already have mistria or mickaelistria 
[2] listed as a repo source, he'll be added automatically to your list 
of remotes.

[2] 
https://github.com/mickaelistria/jbosstools-target-platforms/tree/Kepler-SR2

After the above, the same steps apply:

 > $ cd jbosstools/multiple
 > $ mvn clean install -P \!multiple2repo

Cheers,

Nick

On 02/21/2014 11:52 AM, Mickael Istria wrote:
> Hi all,
>
> Here is a proposal for a new 4.32.0.Alpha1-SNAPSHOT target platform:https://github.com/jbosstools/jbosstools-target-platforms/pull/37
> It consists in the following changes:
> * Move to Kepler SR2
> ** some projects are still using same version that we had for Kepler release (Orbit, m2eclipse, TM, SWTBot)
> ** most projects have contributed a SR2 build
>
> Please review this PR and yell if there is anything shocking. You can use the following stuff to try to build build the TP locally and try out against your component.
> Once this changed is pushed, CI jobs for branch 4.1.x will be updated to use it as TARGET_PLATFORM_MAXIMUM.
>
> Build target-platform:
>
>    $ cd jbosstools-target-platforms
>    $ git fetch mistria Kepler-SR2
>    $ git checkout FETCH_HEAD
>    $ cd jbosstools/multiple
>    $ mvn clean install -P \!multiple2repo
>
> Try with just built target-platform:
>    $ cd /path/to/your/component
>    $ mvn clean verify -Dtpc.version=4.32.0.Alpha1-SNAPSHOT -Pmultiple.target
>
> Cheers,
>
> --
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets
> <http://twitter.com/mickaelistria>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From nboldt at redhat.com  Fri Feb 21 13:09:26 2014
From: nboldt at redhat.com (Nick Boldt)
Date: Fri, 21 Feb 2014 13:09:26 -0500
Subject: [jbosstools-dev] JBoss Tools 4.1.2.CR1 codefreeze is next thursday
	(27th February)
In-Reply-To: <16358B0C-8E94-4CC2-83D5-FDD2FF956C2B@redhat.com>
References: <16358B0C-8E94-4CC2-83D5-FDD2FF956C2B@redhat.com>
Message-ID: <53079656.4080300@redhat.com>




-------- Original Message --------
Subject: JBDS 7.1 CR1 codefreeze is next thursday
Date: Thu, 20 Feb 2014 11:42:00 +0100
From: Max Rydahl Andersen <manderse at redhat.com>
To: external-exadel-list at redhat.com external-exadel-list at redhat.com 
<external-exadel-list at redhat.com>

Hi,

A friendly reminder that next thursday (27th February) is code freeze
for JBoss Tools 4.1.2 and Developer Studio 7.1.1

We already have some issues done here but please don't forget that when
you or QE find issues in master that affects
maintenance to clone and raise them as issues to consider for
maintenance!

Thanks,
/max
http://about.me/maxandersen




From rstryker at redhat.com  Fri Feb 21 13:06:35 2014
From: rstryker at redhat.com (Rob Stryker)
Date: Sat, 22 Feb 2014 02:06:35 +0800
Subject: [jbosstools-dev] $0 subscription downloads - Stacks integration
 with download manager
In-Reply-To: <465855590.3886408.1392993702233.JavaMail.zimbra@redhat.com>
References: <53070D2D.7090302@redhat.com>
	<465855590.3886408.1392993702233.JavaMail.zimbra@redhat.com>
Message-ID: <530795AB.9030800@redhat.com>

On 02/21/2014 10:41 PM, David Hladky wrote:
> Hi Rob,
>
> will you also use the part of the interface, that would allow the user to accept the terms and conditions in Eclipse? It may look better if you do.
>
> David Hladky

Yes, David, we will definitely be using that part of the interface.

Considering that the download-manager is set to be released and in 
production soon, I'm really not sure I can expect your team to make 
changes to the workflow, responses, etc.  I think at this point it's 
more likely to break stuff. But I'll list the problems so far:

    1) Each rest entry point response does not point to the next step in 
the workflow
    2) This means a client (like jbt) must assume the workflow
    3) This means that if you guys need to add steps to the workflow in 
the future, you can't, without breaking clients
    4) It also means that we must hard-code each url (tc, tc-accepted, 
tc-accept, file) and that these become API and can never be renamed.
    5) Even if you added the next url as part of the response, your 
initial entry point is basically the service "tc-accepted",  which seems 
a strange name to begin the workflow.

The only part of this I see as 'dangerous' really is item 3) and 4).   
You guys won't be able to add steps to the workflow without breaking 
clients. Item 1) is annoying, though, as it means we can't simply put 
the url to the download-manager with its attribute in stacks.yaml.


Considering time is tight and I doubt the download-manager team can make 
the changes above, For stacks.yaml, I like Rafael's suggestion:

*downloadUrl*=downloadManager://jboss-eap-6.0.0.dv.ci-installer.jar

JBT would then recognize the prefix, chop it off, and use that string as 
what we pass to download-manager's rest services.  Perhaps stacks can 
have a property somewhere in its client jar that lists the download 
manager's root url, to avoid multiple clients having it hard-coded 
everywhere. (Rafael, if you think it doesn't belong there, I guess jbt 
can just have it hard-coded or pulled from somewhere, but I think if 
stacks is listing download-manager urls in the stacks.yaml, it should 
list the URL of the rest services somewhere, for example inside 
jdf-stacks-client / src / main / resources / org / jboss / jdf / stacks 
/ client / config.properties where you list the stacks url and 
pre-stacks url)

Assuming Rafael's solution doesn't offend anyone, I think it's the best 
we have for now.

>
> ----- Original Message -----
> From: "Rob Stryker" <rstryker at redhat.com>
> To: "David Hladky" <dhladky at redhat.com>, "Rafael Benevides" <benevides at redhat.com>, "Snjezana Peco" <snjezana.peco at redhat.com>, "jbosstools-dev jbosstools-dev" <jbosstools-dev at lists.jboss.org>
> Sent: Friday, 21 February, 2014 9:24:13 AM
> Subject: $0 subscription downloads - Stacks integration with download manager
>
> Rafael (and others):
>
> So I spent an hour or so yesterday chatting with David Hladky about the
> new download manager rest services which JBosstools intends to use to
> help us download EAP 6.x. It allows for a workflow that can help us get
> terms and conditions, verify credentials, verify agreements have been
> signed, and then provide a download utility with a temporary url that
> expires to download the EAP.
>
> The api and the test server I played with look good so far. JBossTools,
> though, pulls all of its runtime information from jdf-stacks. We
> typically pull our download urls from there.
>
> Currently in stacks, community editions have a "url" for the project
> page, and a "downloadUrl" for a link to a permanent url for the given
> runtime to download.
>
> EAP instances in stacks.yaml only have a url for a project page. When
> the download manager written by David goes live, we'll need to consider
> what to do for stacks.yaml, and I'd prefer to get this stuff sorted now.
>
> I'd like to suggest that we add a new attribute "downloadManagerUrl".
> This will ensure clients know that this is a workflow url and not a
> static url for downloading a file.
>
> There's 2 parts to the rest service written by David. First is the rest
> service url itself, and the second is the file we're requesting.
> Currently a url for one part of the rest workflow (in this example, to
> get terms and conditions) looks like this:
>
> ${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar
>
> You can see the two parts are the rest service url (on test server,
> https://www-eng.jboss.org/download-manager/rest/tc)  and the second part
> is what we're requesting (in this case,
> /content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar)
>
> I see a few problems here. The first is that, in my opinion, those urls
> are pretty long to be including in stacks.yaml... but luckily the
> download-manager allows for shortened urls, so we could have the
> download-manager server respond to a url like
> ${server-root}/rest/tc?downloadURL=jboss-eap-6.0.0.dv.ci-installer.jar.
> The download manager would then map the attribute to the
> /content/blah/blah/sha path and proceed accordingly. So this is easily
> fixed.
>
>
> The second, is that the rest services do not point to the next url to
> request. For example, if I go to the tc-accepted rest service to see if
> the terms and conditions were accepted yet, it does not point me to the
> next url in the workflow. Because of this, there's really no single
> entry-point in the workflow, and each rest service url is kind of a
> standalone url.
>
> With the second point in mind, we might just want our stacks.yaml
> attribute to say downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar.
>
> The client (in this case jbosstools) would pass that string to the
> download manager rest service it chooses to use. The download-manager
> server would resolve jboss-eap-6.0.0.dv.ci-installer.jar to its more
> specific /content/sha256/23423823423/etc  path, and proceed normally.
>
> One concern with this approach is that the stacks.yaml will never
> include the actual url of the rest service entry point. Even if we
> wanted to have stacks.yaml point to the entry point, there's no one
> entry-point since the rest services do not point to the next step in the
> workflow.
>
> I personally have no problem using the service as it's written now, and
> with stacks.yaml only having a shortened path available, but I wanted to
> get your (and others) feedback on the situation before this gets pushed
> to production, after which we probably won't have much chance to change it.
>
> Any thoughts?
>
> - Rob Stryker

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140222/65251743/attachment.html 

From manderse at redhat.com  Fri Feb 21 13:43:44 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 21 Feb 2014 13:43:44 -0500 (EST)
Subject: [jbosstools-dev] $0 subscription downloads - Stacks integration
	with download manager
In-Reply-To: <530795AB.9030800@redhat.com>
References: <53070D2D.7090302@redhat.com>
	<465855590.3886408.1392993702233.JavaMail.zimbra@redhat.com>
	<530795AB.9030800@redhat.com>
Message-ID: <F8122F53-0F6C-4314-8C4D-2B46F39AC491@redhat.com>

Hi Rob, 
>> 
>> will you also use the part of the interface, that would allow the user to accept the terms and conditions in Eclipse? It may look better if you do. 
>> 
>> David Hladky
> 
> Yes, David, we will definitely be using that part of the interface. 
> 
> Considering that the download-manager is set to be released and in     production soon, I'm really not sure I can expect your team to make changes to the workflow,

Aren't we the only one that are clients of this ? Then there should not be a problem fixing it. The whole idea/reason for rest API is for our usecase. David - correct me if I'm wrong here ?

> responses, etc.  I think at this point it's more likely to break stuff. But I'll list the problems so far:
> 
>    1) Each rest entry point response does not point to the next step in the workflow
>    2) This means a client (like jbt) must assume the workflow
>    3) This means that if you guys need to add steps to the workflow in the future, you can't, without breaking clients
>    4) It also means that we must hard-code each url (tc, tc-accepted, tc-accept, file) and that these become API and can never be renamed. 
>    5) Even if you added the next url as part of the response, your initial entry point is basically the service "tc-accepted",  which seems a strange name to begin the workflow. 
> 
> The only part of this I see as 'dangerous' really is item 3) and 4).   You guys won't be able to add steps to the workflow without breaking clients. Item 1) is annoying, though, as it means we can't simply put the url to the download-manager with its attribute in stacks.yaml. 
> 
> 
> Considering time is tight and I doubt the download-manager team can make the changes above, For stacks.yaml, I like Rafael's suggestion:
> 
> downloadUrl=downloadManager://jboss-eap-6.0.0.dv.ci-installer.jar
> 

Okey I'm lost here. Aren't the URL the downloadmanager can be handed the exact same as what a browser can open and the user will be walked through the urls ?

Jdf website will use that download URL just as is in a plain href. 

Only clients like jbt that does not want to jump to the browser to download would have to trigger special treatment. Which for me seems sufficient to put in a label ?

> JBT would then recognize the prefix, chop it off, and use that string as what we pass to download-manager's rest services. 

No other client can use that URL for anything so I really don't like that approach. 

/max

> Perhaps stacks can have a property somewhere in its client jar that lists the download manager's root url, to avoid multiple clients having it hard-coded everywhere. (Rafael, if you think it doesn't belong there, I guess jbt can just have it hard-coded or pulled from somewhere, but I think if stacks is listing download-manager urls in the stacks.yaml, it should list the URL of the rest services somewhere, for example inside jdf-stacks-client / src / main / resources / org / jboss / jdf / stacks / client / config.properties where you list the stacks url and pre-stacks url)
> 
> Assuming Rafael's solution doesn't offend anyone, I think it's the best we have for now. 
> 
>> 
>> ----- Original Message -----
>> From: "Rob Stryker" <rstryker at redhat.com>
>> To: "David Hladky" <dhladky at redhat.com>, "Rafael Benevides" <benevides at redhat.com>, "Snjezana Peco" <snjezana.peco at redhat.com>, "jbosstools-dev jbosstools-dev" <jbosstools-dev at lists.jboss.org>
>> Sent: Friday, 21 February, 2014 9:24:13 AM
>> Subject: $0 subscription downloads - Stacks integration with download manager
>> 
>> Rafael (and others):
>> 
>> So I spent an hour or so yesterday chatting with David Hladky about the 
>> new download manager rest services which JBosstools intends to use to 
>> help us download EAP 6.x. It allows for a workflow that can help us get 
>> terms and conditions, verify credentials, verify agreements have been 
>> signed, and then provide a download utility with a temporary url that 
>> expires to download the EAP.
>> 
>> The api and the test server I played with look good so far. JBossTools, 
>> though, pulls all of its runtime information from jdf-stacks. We 
>> typically pull our download urls from there.
>> 
>> Currently in stacks, community editions have a "url" for the project 
>> page, and a "downloadUrl" for a link to a permanent url for the given 
>> runtime to download.
>> 
>> EAP instances in stacks.yaml only have a url for a project page. When 
>> the download manager written by David goes live, we'll need to consider 
>> what to do for stacks.yaml, and I'd prefer to get this stuff sorted now.
>> 
>> I'd like to suggest that we add a new attribute "downloadManagerUrl".  
>> This will ensure clients know that this is a workflow url and not a 
>> static url for downloading a file.
>> 
>> There's 2 parts to the rest service written by David. First is the rest 
>> service url itself, and the second is the file we're requesting. 
>> Currently a url for one part of the rest workflow (in this example, to 
>> get terms and conditions) looks like this:
>> 
>> ${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar
>> 
>> You can see the two parts are the rest service url (on test server, 
>> https://www-eng.jboss.org/download-manager/rest/tc)  and the second part 
>> is what we're requesting (in this case, 
>> /content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar)
>> 
>> I see a few problems here. The first is that, in my opinion, those urls 
>> are pretty long to be including in stacks.yaml... but luckily the 
>> download-manager allows for shortened urls, so we could have the 
>> download-manager server respond to a url like 
>> ${server-root}/rest/tc?downloadURL=jboss-eap-6.0.0.dv.ci-installer.jar. 
>> The download manager would then map the attribute to the 
>> /content/blah/blah/sha path and proceed accordingly. So this is easily 
>> fixed.
>> 
>> 
>> The second, is that the rest services do not point to the next url to 
>> request. For example, if I go to the tc-accepted rest service to see if 
>> the terms and conditions were accepted yet, it does not point me to the 
>> next url in the workflow. Because of this, there's really no single 
>> entry-point in the workflow, and each rest service url is kind of a 
>> standalone url.
>> 
>> With the second point in mind, we might just want our stacks.yaml 
>> attribute to say downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar.
>> 
>> The client (in this case jbosstools) would pass that string to the 
>> download manager rest service it chooses to use. The download-manager 
>> server would resolve jboss-eap-6.0.0.dv.ci-installer.jar to its more 
>> specific /content/sha256/23423823423/etc  path, and proceed normally.
>> 
>> One concern with this approach is that the stacks.yaml will never 
>> include the actual url of the rest service entry point. Even if we 
>> wanted to have stacks.yaml point to the entry point, there's no one 
>> entry-point since the rest services do not point to the next step in the 
>> workflow.
>> 
>> I personally have no problem using the service as it's written now, and 
>> with stacks.yaml only having a shortened path available, but I wanted to 
>> get your (and others) feedback on the situation before this gets pushed 
>> to production, after which we probably won't have much chance to change it.
>> 
>> Any thoughts?
>> 
>> - Rob Stryker
> 
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140221/93624e47/attachment-0001.html 

From rstryker at redhat.com  Fri Feb 21 15:05:03 2014
From: rstryker at redhat.com (Rob Stryker)
Date: Sat, 22 Feb 2014 04:05:03 +0800
Subject: [jbosstools-dev] $0 subscription downloads - Stacks integration
 with download manager
In-Reply-To: <F8122F53-0F6C-4314-8C4D-2B46F39AC491@redhat.com>
References: <53070D2D.7090302@redhat.com>
	<465855590.3886408.1392993702233.JavaMail.zimbra@redhat.com>
	<530795AB.9030800@redhat.com>
	<F8122F53-0F6C-4314-8C4D-2B46F39AC491@redhat.com>
Message-ID: <5307B16F.8010505@redhat.com>

On 02/22/2014 02:43 AM, Max Rydahl Andersen wrote:
>
> Okey I'm lost here. Aren't the URL the downloadmanager can be handed 
> the exact same as what a browser can open and the user will be walked 
> through the urls ?
>

The "url" the download manager is handed isn't really a url, but is more 
of a filesystem path.  Something like 
"/content/sha256/2342343242/some-name.zip".   So there's no way to open 
this string in a web browser.

However, if I misunderstood your question,  I still believe the answer 
is no. If you go to the rest service URLs directly in a web browser, 
such as 
{server}/rest/tc?downloadURL=/content/sha256/234234324/some-download.zip, you 
will never be walked through a web browser workflow for signing the 
terms and conditions.  As far as I can tell, the download portion of the 
website is merely a consumer of the download-manager, and, based on what 
the download-manager returns, will show different content.

From mistria at redhat.com  Mon Feb 24 05:35:27 2014
From: mistria at redhat.com (Mickael Istria)
Date: Mon, 24 Feb 2014 11:35:27 +0100
Subject: [jbosstools-dev] Change in TP 4.32.0.Alpha1-SNAPSHOT,
 targetting Kepler SR2
In-Reply-To: <53078492.7070306@redhat.com>
References: <53078437.4080005@redhat.com> <53078492.7070306@redhat.com>
Message-ID: <530B206F.4080609@redhat.com>

Just so you know, there has been a Kepler SR2 RC4a because of a bug in p2:
* 
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10328.html
* 
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10331.html

So I'm currently mirroring this new repo and will come up with an update 
on this PR to use the new p2 bundles.
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140224/26d83450/attachment.html 

From fbricon at redhat.com  Mon Feb 24 08:23:38 2014
From: fbricon at redhat.com (Fred Bricon)
Date: Mon, 24 Feb 2014 14:23:38 +0100
Subject: [jbosstools-dev] $0 subscription downloads - Stacks integration
 with download manager
In-Reply-To: <530795AB.9030800@redhat.com>
References: <53070D2D.7090302@redhat.com>	<465855590.3886408.1392993702233.JavaMail.zimbra@redhat.com>
	<530795AB.9030800@redhat.com>
Message-ID: <530B47DA.7050309@redhat.com>

*downloadUrl*=downloadManager://jboss-eap-6.0.0.dv.ci-installer.jar will 
not be supported by existing JBT/JBDS clients

Le 21/02/2014 19:06, Rob Stryker a ?crit :
> On 02/21/2014 10:41 PM, David Hladky wrote:
>> Hi Rob,
>>
>> will you also use the part of the interface, that would allow the user to accept the terms and conditions in Eclipse? It may look better if you do.
>>
>> David Hladky
>
> Yes, David, we will definitely be using that part of the interface.
>
> Considering that the download-manager is set to be released and in 
> production soon, I'm really not sure I can expect your team to make 
> changes to the workflow, responses, etc.  I think at this point it's 
> more likely to break stuff. But I'll list the problems so far:
>
>    1) Each rest entry point response does not point to the next step 
> in the workflow
>    2) This means a client (like jbt) must assume the workflow
>    3) This means that if you guys need to add steps to the workflow in 
> the future, you can't, without breaking clients
>    4) It also means that we must hard-code each url (tc, tc-accepted, 
> tc-accept, file) and that these become API and can never be renamed.
>    5) Even if you added the next url as part of the response, your 
> initial entry point is basically the service "tc-accepted",  which 
> seems a strange name to begin the workflow.
>
> The only part of this I see as 'dangerous' really is item 3) and 4).   
> You guys won't be able to add steps to the workflow without breaking 
> clients. Item 1) is annoying, though, as it means we can't simply put 
> the url to the download-manager with its attribute in stacks.yaml.
>
>
> Considering time is tight and I doubt the download-manager team can 
> make the changes above, For stacks.yaml, I like Rafael's suggestion:
>
> *downloadUrl*=downloadManager://jboss-eap-6.0.0.dv.ci-installer.jar
>
> JBT would then recognize the prefix, chop it off, and use that string 
> as what we pass to download-manager's rest services. Perhaps stacks 
> can have a property somewhere in its client jar that lists the 
> download manager's root url, to avoid multiple clients having it 
> hard-coded everywhere. (Rafael, if you think it doesn't belong there, 
> I guess jbt can just have it hard-coded or pulled from somewhere, but 
> I think if stacks is listing download-manager urls in the stacks.yaml, 
> it should list the URL of the rest services somewhere, for example 
> inside jdf-stacks-client / src / main / resources / org / jboss / jdf 
> / stacks / client / config.properties where you list the stacks url 
> and pre-stacks url)
>
> Assuming Rafael's solution doesn't offend anyone, I think it's the 
> best we have for now.
>
>> ----- Original Message -----
>> From: "Rob Stryker"<rstryker at redhat.com>
>> To: "David Hladky"<dhladky at redhat.com>, "Rafael Benevides"<benevides at redhat.com>, "Snjezana Peco"<snjezana.peco at redhat.com>, "jbosstools-dev jbosstools-dev"<jbosstools-dev at lists.jboss.org>
>> Sent: Friday, 21 February, 2014 9:24:13 AM
>> Subject: $0 subscription downloads - Stacks integration with download manager
>>
>> Rafael (and others):
>>
>> So I spent an hour or so yesterday chatting with David Hladky about the
>> new download manager rest services which JBosstools intends to use to
>> help us download EAP 6.x. It allows for a workflow that can help us get
>> terms and conditions, verify credentials, verify agreements have been
>> signed, and then provide a download utility with a temporary url that
>> expires to download the EAP.
>>
>> The api and the test server I played with look good so far. JBossTools,
>> though, pulls all of its runtime information from jdf-stacks. We
>> typically pull our download urls from there.
>>
>> Currently in stacks, community editions have a "url" for the project
>> page, and a "downloadUrl" for a link to a permanent url for the given
>> runtime to download.
>>
>> EAP instances in stacks.yaml only have a url for a project page. When
>> the download manager written by David goes live, we'll need to consider
>> what to do for stacks.yaml, and I'd prefer to get this stuff sorted now.
>>
>> I'd like to suggest that we add a new attribute "downloadManagerUrl".
>> This will ensure clients know that this is a workflow url and not a
>> static url for downloading a file.
>>
>> There's 2 parts to the rest service written by David. First is the rest
>> service url itself, and the second is the file we're requesting.
>> Currently a url for one part of the rest workflow (in this example, to
>> get terms and conditions) looks like this:
>>
>> ${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar
>>
>> You can see the two parts are the rest service url (on test server,
>> https://www-eng.jboss.org/download-manager/rest/tc)  and the second part
>> is what we're requesting (in this case,
>> /content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar)
>>
>> I see a few problems here. The first is that, in my opinion, those urls
>> are pretty long to be including in stacks.yaml... but luckily the
>> download-manager allows for shortened urls, so we could have the
>> download-manager server respond to a url like
>> ${server-root}/rest/tc?downloadURL=jboss-eap-6.0.0.dv.ci-installer.jar.
>> The download manager would then map the attribute to the
>> /content/blah/blah/sha path and proceed accordingly. So this is easily
>> fixed.
>>
>>
>> The second, is that the rest services do not point to the next url to
>> request. For example, if I go to the tc-accepted rest service to see if
>> the terms and conditions were accepted yet, it does not point me to the
>> next url in the workflow. Because of this, there's really no single
>> entry-point in the workflow, and each rest service url is kind of a
>> standalone url.
>>
>> With the second point in mind, we might just want our stacks.yaml
>> attribute to say downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar.
>>
>> The client (in this case jbosstools) would pass that string to the
>> download manager rest service it chooses to use. The download-manager
>> server would resolve jboss-eap-6.0.0.dv.ci-installer.jar to its more
>> specific /content/sha256/23423823423/etc  path, and proceed normally.
>>
>> One concern with this approach is that the stacks.yaml will never
>> include the actual url of the rest service entry point. Even if we
>> wanted to have stacks.yaml point to the entry point, there's no one
>> entry-point since the rest services do not point to the next step in the
>> workflow.
>>
>> I personally have no problem using the service as it's written now, and
>> with stacks.yaml only having a shortened path available, but I wanted to
>> get your (and others) feedback on the situation before this gets pushed
>> to production, after which we probably won't have much chance to change it.
>>
>> Any thoughts?
>>
>> - Rob Stryker
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140224/b3fcf7af/attachment.html 

From dgolovin at exadel.com  Mon Feb 24 15:29:49 2014
From: dgolovin at exadel.com (Denis Golovin)
Date: Mon, 24 Feb 2014 12:29:49 -0800
Subject: [jbosstools-dev]
 =?utf-8?q?ACTION_REQUIRED=3A_Project_leads=2C_pl?=
 =?utf-8?q?ease_tag_your_projects_=5B_branch_jbosstools-4=2E2=2E0=2EAlpha2?=
 =?utf-8?b?eCDihpIgdGFnIGpib3NzdG9vbHMtNC4yLjAuQWxwaGEyIF0=?=
In-Reply-To: <53063987.9040101@redhat.com>
References: <53063987.9040101@redhat.com>
Message-ID: <530BABBD.5000700@exadel.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140224/9bd2ce30/attachment.html 

From fbricon at redhat.com  Mon Feb 24 17:19:47 2014
From: fbricon at redhat.com (Fred Bricon)
Date: Mon, 24 Feb 2014 23:19:47 +0100
Subject: [jbosstools-dev]
 =?utf-8?q?ACTION_REQUIRED=3A_Project_leads=2C_pl?=
 =?utf-8?q?ease_tag_your_projects_=5B_branch_jbosstools-4=2E2=2E0=2EAlpha2?=
 =?utf-8?b?eCDihpIgdGFnIGpib3NzdG9vbHMtNC4yLjAuQWxwaGEyIF0=?=
In-Reply-To: <530BABBD.5000700@exadel.com>
References: <53063987.9040101@redhat.com> <530BABBD.5000700@exadel.com>
Message-ID: <530BC583.2040706@redhat.com>

I tagged central this morning but forgot to push it upstream. /facepalm
It's done now.

Le lundi 24 f?vrier 2014 21:29:49, Denis Golovin a ?crit :
> Modules below still have no jbosstools-4.2.0.Alpha2 tag:
> jbosstools-aerogear
> jbosstools-central
> jbosstools-server
>
> Denis
>
>
> On 02/20/2014 09:21 AM, Mickael Istria wrote:
>> git push origin jbosstools-4.2.0.Alpha2
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev



From max.andersen at gmail.com  Tue Feb 25 04:59:19 2014
From: max.andersen at gmail.com (Max Rydahl Andersen)
Date: Tue, 25 Feb 2014 10:59:19 +0100
Subject: [jbosstools-dev] Use of sapphire in jboss tools projects ?
Message-ID: <78D46466-077C-4B24-9E25-F745B4C448B6@gmail.com>

Heya,


In past in jboss tools core we haven't used it  but I know integration 
stack uses it (SwitchYard? others ?)

I'm just wondering:

1) Was it worth it ?

2) How much do you use it ? for xml-tree editors, graphical editors, 
wizards, more ?

Asking since I just got aware that they plan to go out of incubation for 
Luna (https://www.eclipse.org/sapphire/releases/)
and with https://issues.jboss.org/browse/JBIDE-15394 and 
http://screencast.com/t/058KgoS7ZK0 the value at least now
seem much greater than the past API breakage issues there was.

I especially like 
http://www.eclipse.org/sapphire/documentation/latest/versions/index.html 
and the zero-EMF requirement on the models ;)

/max
http://about.me/maxandersen

From bfitzpat at redhat.com  Tue Feb 25 08:32:40 2014
From: bfitzpat at redhat.com (Brian Fitzpatrick)
Date: Tue, 25 Feb 2014 08:32:40 -0500 (EST)
Subject: [jbosstools-dev] Use of sapphire in jboss tools projects ?
In-Reply-To: <78D46466-077C-4B24-9E25-F745B4C448B6@gmail.com>
References: <78D46466-077C-4B24-9E25-F745B4C448B6@gmail.com>
Message-ID: <2132933691.5517398.1393335160812.JavaMail.zimbra@redhat.com>

We tried to use it, but abandoned it pretty quickly. The issue wasn't that it didn't work, but that it was a bit unstable at the time and didn't quite handle everything we needed.  

That was a couple of years ago now, so I'm sure it's improved since then. 

I wish I could remember specifics, but it's been a long time now and there's been a lot of water under the bridge.

--Fitz

_______________________________
Brian Fitzpatrick (aka "Fitz")
Senior Software Engineer, SOA-P
JBoss by Red Hat

----- Original Message -----
From: "Max Rydahl Andersen" <max.andersen at gmail.com>
To: "jbosstools-dev jbosstools-dev" <jbosstools-dev at lists.jboss.org>
Cc: "soa-tools-list" <soa-tools-list at redhat.com>
Sent: Tuesday, February 25, 2014 2:59:19 AM
Subject: [jbosstools-dev] Use of sapphire in jboss tools projects ?

Heya,


In past in jboss tools core we haven't used it  but I know integration 
stack uses it (SwitchYard? others ?)

I'm just wondering:

1) Was it worth it ?

2) How much do you use it ? for xml-tree editors, graphical editors, 
wizards, more ?

Asking since I just got aware that they plan to go out of incubation for 
Luna (https://www.eclipse.org/sapphire/releases/)
and with https://issues.jboss.org/browse/JBIDE-15394 and 
http://screencast.com/t/058KgoS7ZK0 the value at least now
seem much greater than the past API breakage issues there was.

I especially like 
http://www.eclipse.org/sapphire/documentation/latest/versions/index.html 
and the zero-EMF requirement on the models ;)

/max
http://about.me/maxandersen
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev

From rcernich at redhat.com  Tue Feb 25 09:19:53 2014
From: rcernich at redhat.com (Rob Cernich)
Date: Tue, 25 Feb 2014 09:19:53 -0500 (EST)
Subject: [jbosstools-dev] [Soa-tools-list] Use of sapphire in
	jboss	tools projects ?
In-Reply-To: <2132933691.5517398.1393335160812.JavaMail.zimbra@redhat.com>
References: <78D46466-077C-4B24-9E25-F745B4C448B6@gmail.com>
	<2132933691.5517398.1393335160812.JavaMail.zimbra@redhat.com>
Message-ID: <84397649.8955564.1393337993485.JavaMail.zimbra@redhat.com>

I think it may work well for smaller models.  As I recall, you needed to create your own model interfaces, annotating them with the XML/UI details.  Sapphire then processed those annotations, generating the code required for the UI.  I don't believe there is any tooling available for automatically generating these annotated interfaces directly from an XSD/DTD.

Initially, they had some support for Graphiti, so you could generate graphical editors in addition to master/detail style tree/field editors.  That changed early on so the graphical editor was generated directly on GEF.

As Brian said, this is my knowledge as of about two years ago.

----- Original Message -----
> We tried to use it, but abandoned it pretty quickly. The issue wasn't that it
> didn't work, but that it was a bit unstable at the time and didn't quite
> handle everything we needed.
> 
> That was a couple of years ago now, so I'm sure it's improved since then.
> 
> I wish I could remember specifics, but it's been a long time now and there's
> been a lot of water under the bridge.
> 
> --Fitz
> 
> _______________________________
> Brian Fitzpatrick (aka "Fitz")
> Senior Software Engineer, SOA-P
> JBoss by Red Hat
> 
> ----- Original Message -----
> From: "Max Rydahl Andersen" <max.andersen at gmail.com>
> To: "jbosstools-dev jbosstools-dev" <jbosstools-dev at lists.jboss.org>
> Cc: "soa-tools-list" <soa-tools-list at redhat.com>
> Sent: Tuesday, February 25, 2014 2:59:19 AM
> Subject: [jbosstools-dev] Use of sapphire in jboss tools projects ?
> 
> Heya,
> 
> 
> In past in jboss tools core we haven't used it  but I know integration
> stack uses it (SwitchYard? others ?)
> 
> I'm just wondering:
> 
> 1) Was it worth it ?
> 
> 2) How much do you use it ? for xml-tree editors, graphical editors,
> wizards, more ?
> 
> Asking since I just got aware that they plan to go out of incubation for
> Luna (https://www.eclipse.org/sapphire/releases/)
> and with https://issues.jboss.org/browse/JBIDE-15394 and
> http://screencast.com/t/058KgoS7ZK0 the value at least now
> seem much greater than the past API breakage issues there was.
> 
> I especially like
> http://www.eclipse.org/sapphire/documentation/latest/versions/index.html
> and the zero-EMF requirement on the models ;)
> 
> /max
> http://about.me/maxandersen
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> 
> _______________________________________________
> Soa-tools-list mailing list
> Soa-tools-list at redhat.com
> https://www.redhat.com/mailman/listinfo/soa-tools-list
> 

From manderse at redhat.com  Tue Feb 25 10:00:08 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 25 Feb 2014 16:00:08 +0100
Subject: [jbosstools-dev] Use of sapphire in jboss tools projects ?
In-Reply-To: <2132933691.5517398.1393335160812.JavaMail.zimbra@redhat.com>
References: <78D46466-077C-4B24-9E25-F745B4C448B6@gmail.com>
	<2132933691.5517398.1393335160812.JavaMail.zimbra@redhat.com>
Message-ID: <EFBF5419-12E4-48CE-B9C8-AC87F897A09C@redhat.com>

On 25 Feb 2014, at 14:32, Brian Fitzpatrick wrote:

> We tried to use it, but abandoned it pretty quickly.

that was for the jbossesb attempt or ?

> The issue wasn't that it didn't work, but that it was a bit unstable 
> at the time and didn't quite handle everything we needed.
>
> That was a couple of years ago now, so I'm sure it's improved since 
> then.
>
> I wish I could remember specifics, but it's been a long time now and 
> there's been a lot of water under the bridge.

Okey - I think its matured since then...at least thats how it looks 
like.

/max

> --Fitz
>
> _______________________________
> Brian Fitzpatrick (aka "Fitz")
> Senior Software Engineer, SOA-P
> JBoss by Red Hat
>
> ----- Original Message -----
> From: "Max Rydahl Andersen" <max.andersen at gmail.com>
> To: "jbosstools-dev jbosstools-dev" <jbosstools-dev at lists.jboss.org>
> Cc: "soa-tools-list" <soa-tools-list at redhat.com>
> Sent: Tuesday, February 25, 2014 2:59:19 AM
> Subject: [jbosstools-dev] Use of sapphire in jboss tools projects ?
>
> Heya,
>
>
> In past in jboss tools core we haven't used it  but I know integration
> stack uses it (SwitchYard? others ?)
>
> I'm just wondering:
>
> 1) Was it worth it ?
>
> 2) How much do you use it ? for xml-tree editors, graphical editors,
> wizards, more ?
>
> Asking since I just got aware that they plan to go out of incubation 
> for
> Luna (https://www.eclipse.org/sapphire/releases/)
> and with https://issues.jboss.org/browse/JBIDE-15394 and
> http://screencast.com/t/058KgoS7ZK0 the value at least now
> seem much greater than the past API breakage issues there was.
>
> I especially like
> http://www.eclipse.org/sapphire/documentation/latest/versions/index.html
> and the zero-EMF requirement on the models ;)
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen

From max.andersen at gmail.com  Tue Feb 25 10:06:25 2014
From: max.andersen at gmail.com (Max Rydahl Andersen)
Date: Tue, 25 Feb 2014 16:06:25 +0100
Subject: [jbosstools-dev] [Soa-tools-list] Use of sapphire in jboss
 tools projects ?
In-Reply-To: <84397649.8955564.1393337993485.JavaMail.zimbra@redhat.com>
References: <78D46466-077C-4B24-9E25-F745B4C448B6@gmail.com>
	<2132933691.5517398.1393335160812.JavaMail.zimbra@redhat.com>
	<84397649.8955564.1393337993485.JavaMail.zimbra@redhat.com>
Message-ID: <BB7607C9-30D0-4974-AA0D-8A12A9F96EF4@gmail.com>

On 25 Feb 2014, at 15:19, Rob Cernich wrote:

> I think it may work well for smaller models.

define small ? :) My main interest is just for editing single files - 
not something that crosses multiple artefacts.

> As I recall, you needed to create your own model interfaces, 
> annotating them with the XML/UI details.

Yeah, and they can be adjusted to handle multiple versions so it feels 
much more sustainable/robust/flexible approach compared to i.e. EMF 
models.

> Sapphire then processed those annotations, generating the code 
> required for the UI.  I don't believe there is any tooling available 
> for automatically generating these annotated interfaces directly from 
> an XSD/DTD.

good point.

> Initially, they had some support for Graphiti, so you could generate 
> graphical editors in addition to master/detail style tree/field 
> editors.  That changed early on so the graphical editor was generated 
> directly on GEF.
>
> As Brian said, this is my knowledge as of about two years ago.

okey - the other issue Gorkem just mentioned to me is custom layout...I 
guess if you buy into sapphire you just need
to accept their layout ...

/max

> ----- Original Message -----
>> We tried to use it, but abandoned it pretty quickly. The issue wasn't 
>> that it
>> didn't work, but that it was a bit unstable at the time and didn't 
>> quite
>> handle everything we needed.
>>
>> That was a couple of years ago now, so I'm sure it's improved since 
>> then.
>>
>> I wish I could remember specifics, but it's been a long time now and 
>> there's
>> been a lot of water under the bridge.
>>
>> --Fitz
>>
>> _______________________________
>> Brian Fitzpatrick (aka "Fitz")
>> Senior Software Engineer, SOA-P
>> JBoss by Red Hat
>>
>> ----- Original Message -----
>> From: "Max Rydahl Andersen" <max.andersen at gmail.com>
>> To: "jbosstools-dev jbosstools-dev" <jbosstools-dev at lists.jboss.org>
>> Cc: "soa-tools-list" <soa-tools-list at redhat.com>
>> Sent: Tuesday, February 25, 2014 2:59:19 AM
>> Subject: [jbosstools-dev] Use of sapphire in jboss tools projects ?
>>
>> Heya,
>>
>>
>> In past in jboss tools core we haven't used it  but I know 
>> integration
>> stack uses it (SwitchYard? others ?)
>>
>> I'm just wondering:
>>
>> 1) Was it worth it ?
>>
>> 2) How much do you use it ? for xml-tree editors, graphical editors,
>> wizards, more ?
>>
>> Asking since I just got aware that they plan to go out of incubation 
>> for
>> Luna (https://www.eclipse.org/sapphire/releases/)
>> and with https://issues.jboss.org/browse/JBIDE-15394 and
>> http://screencast.com/t/058KgoS7ZK0 the value at least now
>> seem much greater than the past API breakage issues there was.
>>
>> I especially like
>> http://www.eclipse.org/sapphire/documentation/latest/versions/index.html
>> and the zero-EMF requirement on the models ;)
>>
>> /max
>> http://about.me/maxandersen
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>> _______________________________________________
>> Soa-tools-list mailing list
>> Soa-tools-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/soa-tools-list
>>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen

From gorkem.ercan at gmail.com  Tue Feb 25 10:09:48 2014
From: gorkem.ercan at gmail.com (Gorkem Ercan)
Date: Tue, 25 Feb 2014 10:09:48 -0500
Subject: [jbosstools-dev] Use of sapphire in jboss tools projects ?
In-Reply-To: <EFBF5419-12E4-48CE-B9C8-AC87F897A09C@redhat.com>
References: <78D46466-077C-4B24-9E25-F745B4C448B6@gmail.com>
	<2132933691.5517398.1393335160812.JavaMail.zimbra@redhat.com>
	<EFBF5419-12E4-48CE-B9C8-AC87F897A09C@redhat.com>
Message-ID: <CA+X37c=XCLYR-qB5HvoBp=J5dNYCnNPwY0y+5dxe1OWS7w89Tg@mail.gmail.com>

I have also considered it for the cordova config.xml editor. However, I
wanted my editor to be more than an xml editor and have actions for
running, plugin configs etc. This meant a lot of custom code and I could
not easily see a way to accomplish some of them (different layouts on the
editor for instance) so decided not to use it.
--
Gorkem


On Tue, Feb 25, 2014 at 10:00 AM, Max Rydahl Andersen
<manderse at redhat.com>wrote:

> On 25 Feb 2014, at 14:32, Brian Fitzpatrick wrote:
>
> > We tried to use it, but abandoned it pretty quickly.
>
> that was for the jbossesb attempt or ?
>
> > The issue wasn't that it didn't work, but that it was a bit unstable
> > at the time and didn't quite handle everything we needed.
> >
> > That was a couple of years ago now, so I'm sure it's improved since
> > then.
> >
> > I wish I could remember specifics, but it's been a long time now and
> > there's been a lot of water under the bridge.
>
> Okey - I think its matured since then...at least thats how it looks
> like.
>
> /max
>
> > --Fitz
> >
> > _______________________________
> > Brian Fitzpatrick (aka "Fitz")
> > Senior Software Engineer, SOA-P
> > JBoss by Red Hat
> >
> > ----- Original Message -----
> > From: "Max Rydahl Andersen" <max.andersen at gmail.com>
> > To: "jbosstools-dev jbosstools-dev" <jbosstools-dev at lists.jboss.org>
> > Cc: "soa-tools-list" <soa-tools-list at redhat.com>
> > Sent: Tuesday, February 25, 2014 2:59:19 AM
> > Subject: [jbosstools-dev] Use of sapphire in jboss tools projects ?
> >
> > Heya,
> >
> >
> > In past in jboss tools core we haven't used it  but I know integration
> > stack uses it (SwitchYard? others ?)
> >
> > I'm just wondering:
> >
> > 1) Was it worth it ?
> >
> > 2) How much do you use it ? for xml-tree editors, graphical editors,
> > wizards, more ?
> >
> > Asking since I just got aware that they plan to go out of incubation
> > for
> > Luna (https://www.eclipse.org/sapphire/releases/)
> > and with https://issues.jboss.org/browse/JBIDE-15394 and
> > http://screencast.com/t/058KgoS7ZK0 the value at least now
> > seem much greater than the past API breakage issues there was.
> >
> > I especially like
> > http://www.eclipse.org/sapphire/documentation/latest/versions/index.html
> > and the zero-EMF requirement on the models ;)
> >
> > /max
> > http://about.me/maxandersen
> > _______________________________________________
> > jbosstools-dev mailing list
> > jbosstools-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> > _______________________________________________
> > jbosstools-dev mailing list
> > jbosstools-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140225/fa241e4b/attachment-0001.html 

From rcernich at redhat.com  Tue Feb 25 10:11:37 2014
From: rcernich at redhat.com (Rob Cernich)
Date: Tue, 25 Feb 2014 10:11:37 -0500 (EST)
Subject: [jbosstools-dev] [Soa-tools-list] Use of sapphire in jboss
 tools projects ?
In-Reply-To: <BB7607C9-30D0-4974-AA0D-8A12A9F96EF4@gmail.com>
References: <78D46466-077C-4B24-9E25-F745B4C448B6@gmail.com>
	<2132933691.5517398.1393335160812.JavaMail.zimbra@redhat.com>
	<84397649.8955564.1393337993485.JavaMail.zimbra@redhat.com>
	<BB7607C9-30D0-4974-AA0D-8A12A9F96EF4@gmail.com>
Message-ID: <550224162.9039655.1393341097975.JavaMail.zimbra@redhat.com>

> > I think it may work well for smaller models.
> 
> define small ? :) My main interest is just for editing single files -
> not something that crosses multiple artefacts.
> 

Models, not instances.  This is a function of you having to manually generate the interfaces for the model, so, more types, more interfaces, more fields, bigger interfaces.

Also, early on, there were some issues with substitution groups and multiple namespaces, but I suspect those have been fixed.  If you're an advanced user of XSD, you may want to make sure Sapphire supports all the features you are using.

From rcernich at redhat.com  Tue Feb 25 10:13:10 2014
From: rcernich at redhat.com (Rob Cernich)
Date: Tue, 25 Feb 2014 10:13:10 -0500 (EST)
Subject: [jbosstools-dev] Use of sapphire in jboss tools projects ?
In-Reply-To: <CA+X37c=XCLYR-qB5HvoBp=J5dNYCnNPwY0y+5dxe1OWS7w89Tg@mail.gmail.com>
References: <78D46466-077C-4B24-9E25-F745B4C448B6@gmail.com>
	<2132933691.5517398.1393335160812.JavaMail.zimbra@redhat.com>
	<EFBF5419-12E4-48CE-B9C8-AC87F897A09C@redhat.com>
	<CA+X37c=XCLYR-qB5HvoBp=J5dNYCnNPwY0y+5dxe1OWS7w89Tg@mail.gmail.com>
Message-ID: <2091277194.9040631.1393341190409.JavaMail.zimbra@redhat.com>

> I have also considered it for the cordova config.xml editor. However, I
> wanted my editor to be more than an xml editor and have actions for running,
> plugin configs etc. This meant a lot of custom code and I could not easily
> see a way to accomplish some of them (different layouts on the editor for
> instance) so decided not to use it.
> --
> Gorkem

That was another issue we came across: documentation. It was difficult to figure out how to customize things. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140225/dded18fb/attachment.html 

From manderse at redhat.com  Tue Feb 25 10:33:26 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 25 Feb 2014 16:33:26 +0100
Subject: [jbosstools-dev] Use of sapphire in jboss tools projects ?
In-Reply-To: <2091277194.9040631.1393341190409.JavaMail.zimbra@redhat.com>
References: <78D46466-077C-4B24-9E25-F745B4C448B6@gmail.com>
	<2132933691.5517398.1393335160812.JavaMail.zimbra@redhat.com>
	<EFBF5419-12E4-48CE-B9C8-AC87F897A09C@redhat.com>
	<CA+X37c=XCLYR-qB5HvoBp=J5dNYCnNPwY0y+5dxe1OWS7w89Tg@mail.gmail.com>
	<2091277194.9040631.1393341190409.JavaMail.zimbra@redhat.com>
Message-ID: <F1F76A07-BB71-4555-B992-BA3E75E9194B@redhat.com>

On 25 Feb 2014, at 16:13, Rob Cernich wrote:

>> I have also considered it for the cordova config.xml editor. However, 
>> I
>> wanted my editor to be more than an xml editor and have actions for 
>> running,
>> plugin configs etc. This meant a lot of custom code and I could not 
>> easily
>> see a way to accomplish some of them (different layouts on the editor 
>> for
>> instance) so decided not to use it.
>> --
>> Gorkem
>
> That was another issue we came across: documentation. It was difficult 
> to figure out how to customize things.

does this 
http://www.eclipse.org/sapphire/documentation/latest/index.html looks 
better or worse than what you recall ?

besides custom layout it seem to be pretty flexible from why I can see - 
but wondering if the devil is in the details ;)


/max
http://about.me/maxandersen

From rcernich at redhat.com  Tue Feb 25 10:44:09 2014
From: rcernich at redhat.com (Rob Cernich)
Date: Tue, 25 Feb 2014 10:44:09 -0500 (EST)
Subject: [jbosstools-dev] Use of sapphire in jboss tools projects ?
In-Reply-To: <F1F76A07-BB71-4555-B992-BA3E75E9194B@redhat.com>
References: <78D46466-077C-4B24-9E25-F745B4C448B6@gmail.com>
	<2132933691.5517398.1393335160812.JavaMail.zimbra@redhat.com>
	<EFBF5419-12E4-48CE-B9C8-AC87F897A09C@redhat.com>
	<CA+X37c=XCLYR-qB5HvoBp=J5dNYCnNPwY0y+5dxe1OWS7w89Tg@mail.gmail.com>
	<2091277194.9040631.1393341190409.JavaMail.zimbra@redhat.com>
	<F1F76A07-BB71-4555-B992-BA3E75E9194B@redhat.com>
Message-ID: <914229835.9068218.1393343049763.JavaMail.zimbra@redhat.com>

> >> I have also considered it for the cordova config.xml editor. However,
> >> I
> >> wanted my editor to be more than an xml editor and have actions for
> >> running,
> >> plugin configs etc. This meant a lot of custom code and I could not
> >> easily
> >> see a way to accomplish some of them (different layouts on the editor
> >> for
> >> instance) so decided not to use it.
> >> --
> >> Gorkem
> >
> > That was another issue we came across: documentation. It was difficult
> > to figure out how to customize things.
> 
> does this
> http://www.eclipse.org/sapphire/documentation/latest/index.html looks
> better or worse than what you recall ?
> 
> besides custom layout it seem to be pretty flexible from why I can see -
> but wondering if the devil is in the details ;)
> 

As long as you stay on the fairway, you shouldn't have any problems.  I think, some of the EE descriptor editors have been migrated to Sapphire.  If you're happy with the UI and the way it's structured, it is pretty nice.  If we didn't have a requirement for a graphical editor, we'd probably still be using it.  I don't recall how/if it integrates with SSE.

As I recall, customization was difficult to figure out.  It looks like the basic mechanism for this may have changed, but I don't remember enough to say.

From mistria at redhat.com  Wed Feb 26 08:45:57 2014
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 26 Feb 2014 14:45:57 +0100
Subject: [jbosstools-dev] Target-Platform 4.32.0.Final has been released
Message-ID: <530DF015.2010308@redhat.com>

|JBoss Tools Target Platform 4.32.0.Final has been released.

Changes
=======

* Use Kepler SR2 (current RC4a, hopefully to be promoted as SR2 on Feb 28th)

Usage
=====
|||4.32.0.Final|  is what JBoss Tools 4.1.2 will use.

All jobs in jenkins for branch jbosstools-4.1.x have been updated to use TP||||4.32.0.Final|  |as "maximum" target-platfrom.
Parent pom 4.1.2.Alpha1-SNAPSHOT for branch jbosstools-4.1.x has been updated to use TP 4.32.0.Final as "maximum" target-platform.

Download
========

Zip: http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/|||4.32.0.Final|/jbosstoolstarget-|||4.32.0.Final|.zip
p2 site: http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/|||4.32.0.Final|/REPO/
Git tag: https://github.com/jbosstools/jbosstools-target-platforms/tree/|||4.32.0.Final|

Testing/Development
===================


This should be used by default if you're using the latest SNAPSHOT of parent pom on master, so a simple "mvn clean verify" should be enough to build against this new target platform.
You can try it out and use it directly like this:

     $ mvn clean verify -Dtpc.version=|||4.32.0.Final|

For advanced usage and help (using in IDE, building a mirror locally, using a zip...), plese read https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platforms_for_consumers.md


What's next?
============

Branch 4.32.x for target platform has been prepared for potential upgrades, and it's version is now 4.32.1.Alpha1-SNAPSHOT.|

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140226/2ff9ecb1/attachment.html 

From angelo.zerr at gmail.com  Wed Feb 26 09:01:36 2014
From: angelo.zerr at gmail.com (Angelo zerr)
Date: Wed, 26 Feb 2014 15:01:36 +0100
Subject: [jbosstools-dev] AngularJS Eclipse
Message-ID: <CAKLdLg-fSkTS8E5fMV=Rn-qgStMfWkOKj3zUh0u8ouCUcZmLVg@mail.gmail.com>

Hi JBoss guys,

I'm the creator of AngularJS Eclipse and Mickael Istria suggested me to
contact you.

I have seen that you have spoken about AngluarJS Eclipse at
http://lists.jboss.org/pipermail/jbosstools-dev/2013-December/008450.html

At first, I would like to apologize because Max pinged me on tweeter and I
have not seen that-( Sorry!

I would like to answer about some comments :

>It provides ng-* completion which we do too. And IMO ours is better
>since we provide context-dependent code completion.
>For example we suggest count/when/... attributes only for ng-pluralize
>directives (<ANY ng-pluralize> or <ng-pluralize>)
>Or ng-maxlength only for input directives. Or we don't suggest ng-app if
>it's already defined in any parent tag. Etc. So we analyze the context
>when calculating what can be suggested in the particular place.

Except for "ng-app if  it's already defined in any parent tag", AngularJS
Eclipse manages that :
See screenshots at
https://github.com/angelozerr/angularjs-eclipse/wiki/HTML-Directives

More it works too with custom directive : see screenshots at
https://github.com/angelozerr/angularjs-eclipse/wiki/HTML-Directives#wiki-custom-directive

>It does not provide code completion for {{}} expressions which we plan to
do in JBT 4.2.
Today it supports it. See screenshots at
https://github.com/angelozerr/angularjs-eclipse/wiki/HTML-Features#wiki-angular-expression-management

>The upstream project
>https://github.com/angelozerr/tern.java/wiki/Tern-Eclipse-IDE is
>supposed to provide some angular specific code completion in *.js files
>but I couldn't manage to make it work.
It seems that it's a problem with node.js Please
read https://github.com/angelozerr/tern.java/wiki/Tern-Eclipse-IDE-Node.js<https://github.com/angelozerr/tern.java/wiki/Tern-Eclipse-IDE-Node.js>


Completion is done for angular model (angular.module, etc) but too with the
injection of controller scope and directive (should be improved again). See
screenshots
at https://github.com/angelozerr/angularjs-eclipse/wiki/Javascript-Features<https://github.com/angelozerr/angularjs-eclipse/wiki/Javascript-Features>

AngularJS Eclipse extends the WTP HTML Editor (I don't have created a new
HTML editor).

I would like tell you about pros and cons for using tern :

The cons for using tern  :

 * needs node.js
 * written in Javascript, so it's difficult to debug it with Eclipse. But
tern works in the browser, so I use Chrome to develop the angular plugin.

The pros for using tern  :

 * very powerful. It manages complex case. See demo at
http://ternjs.net/doc/demo.html
 * tern provides plugin/defintions for ecma5, jquery, node, angular.
 * tern is very extensible, so you can create your own tern
definition/plugin like I have done with AngularJS. I use tern in HTML
Editor (see
https://github.com/angelozerr/angularjs-eclipse/wiki/HTML-Features) and
Javascript Editor (
https://github.com/angelozerr/angularjs-eclipse/wiki/Javascript-Features).
 * tern can be executed in a browser. This feature can be very interesting
in some case. For instance I'm developping a tern plugin to manage AlloYUi
a javascript framework used by Liferay (see online demo with CodeMirror at
http://codemirror-java.opensagres.eu.cloudbees.net/codemirror-javascript/demo/alloyui.html).
My idea is that you could use this AlloYUi plugin inside Eclipse IDE and
inside the Liferay Portal.
 * as tern is written in Javascript, the community is very big.

Hope my information will be useful for you.

Regards Angelo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140226/49e2113e/attachment-0001.html 

From manderse at redhat.com  Wed Feb 26 11:05:04 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 26 Feb 2014 17:05:04 +0100
Subject: [jbosstools-dev] AngularJS Eclipse
In-Reply-To: <CAKLdLg-fSkTS8E5fMV=Rn-qgStMfWkOKj3zUh0u8ouCUcZmLVg@mail.gmail.com>
References: <CAKLdLg-fSkTS8E5fMV=Rn-qgStMfWkOKj3zUh0u8ouCUcZmLVg@mail.gmail.com>
Message-ID: <9BD11EA2-AF09-49DD-9AE8-166B2356B833@redhat.com>

> Hi JBoss guys,

Hey Angelo!

> I'm the creator of AngularJS Eclipse and Mickael Istria suggested me 
> to
> contact you.

Yes :)

> I have seen that you have spoken about AngluarJS Eclipse at
> http://lists.jboss.org/pipermail/jbosstools-dev/2013-December/008450.html

> At first, I would like to apologize because Max pinged me on tweeter 
> and I
> have not seen that-( Sorry!

no worries - you are here now ;)

> I would like to answer about some comments :
>
>> It provides ng-* completion which we do too. And IMO ours is better
>> since we provide context-dependent code completion.
>> For example we suggest count/when/... attributes only for 
>> ng-pluralize
>> directives (<ANY ng-pluralize> or <ng-pluralize>)
>> Or ng-maxlength only for input directives. Or we don't suggest ng-app 
>> if
>> it's already defined in any parent tag. Etc. So we analyze the 
>> context
>> when calculating what can be suggested in the particular place.
>
> Except for "ng-app if  it's already defined in any parent tag", 
> AngularJS
> Eclipse manages that :
> See screenshots at
> https://github.com/angelozerr/angularjs-eclipse/wiki/HTML-Directives
>
> More it works too with custom directive : see screenshots at
> https://github.com/angelozerr/angularjs-eclipse/wiki/HTML-Directives#wiki-custom-directive
>
>> It does not provide code completion for {{}} expressions which we 
>> plan to
> do in JBT 4.2.
> Today it supports it. See screenshots at
> https://github.com/angelozerr/angularjs-eclipse/wiki/HTML-Features#wiki-angular-expression-management

and it does that without *running* the project javascript ? that is pure 
tern parsed ?

if yes - that is nice!

I thought there were things in angularjs context that would not be 
possible to extract from javascript?

Saying this in context of our experiment where we actually ask the 
browser what is in the angular scope
at runtime....but maybe these two approaches could simply be merged and 
we get best of both worlds?

>> The upstream project
>> https://github.com/angelozerr/tern.java/wiki/Tern-Eclipse-IDE is
>> supposed to provide some angular specific code completion in *.js 
>> files
>> but I couldn't manage to make it work.
> It seems that it's a problem with node.js Please
> read 
> https://github.com/angelozerr/tern.java/wiki/Tern-Eclipse-IDE-Node.js<https://github.com/angelozerr/tern.java/wiki/Tern-Eclipse-IDE-Node.js>

I tried installing OSX osgi bundle provided node.js and it seems to NPE 
for me ;/

I thought I actually saw this working but that might have been earlier 
version.

I think the default should be that out of box Tern/angularjs integration 
should use the bundled one and
then advanced users can decide use native one...optimally default users 
should not have to care about
it is using node.

> Completion is done for angular model (angular.module, etc) but too 
> with the
> injection of controller scope and directive (should be improved 
> again). See
> screenshots
> at 
> https://github.com/angelozerr/angularjs-eclipse/wiki/Javascript-Features<https://github.com/angelozerr/angularjs-eclipse/wiki/Javascript-Features>
>
> AngularJS Eclipse extends the WTP HTML Editor (I don't have created a 
> new
> HTML editor).

Yeah, what I would like to enable is that we don't need 
"yet-another-editor" but could just
have this enable in jboss tools existing html editor (or even JSDT html 
editor but thats far off yet ;)

> I would like tell you about pros and cons for using tern :
>
> The cons for using tern  :
>
> * needs node.js
> * written in Javascript, so it's difficult to debug it with Eclipse. 
> But
> tern works in the browser, so I use Chrome to develop the angular 
> plugin.
>
> The pros for using tern  :
>
> * very powerful. It manages complex case. See demo at
> http://ternjs.net/doc/demo.html
> * tern provides plugin/defintions for ecma5, jquery, node, angular.
> * tern is very extensible, so you can create your own tern
> definition/plugin like I have done with AngularJS. I use tern in HTML
> Editor (see
> https://github.com/angelozerr/angularjs-eclipse/wiki/HTML-Features) 
> and
> Javascript Editor (
> https://github.com/angelozerr/angularjs-eclipse/wiki/Javascript-Features).
> * tern can be executed in a browser. This feature can be very 
> interesting
> in some case. For instance I'm developping a tern plugin to manage 
> AlloYUi
> a javascript framework used by Liferay (see online demo with 
> CodeMirror at
> http://codemirror-java.opensagres.eu.cloudbees.net/codemirror-javascript/demo/alloyui.html).
> My idea is that you could use this AlloYUi plugin inside Eclipse IDE 
> and
> inside the Liferay Portal.
> * as tern is written in Javascript, the community is very big.

Yeah, you basically outline the same exact reasons why I think trying to 
use Tern as a
backend for JSDT is a bit weird, but more sustainable/maintainable than 
writing/extending
the java based parser.

It just needs some enduser polish (i.e. users should not need to care 
about different html editors,
different node.js runtimes, it should "just work").

> Hope my information will be useful for you.

Yes definitely.

One concern we had was performance and portability.
Does Tern handle larger projects of javascript well ? Can we avoid it 
have to parse
constantly ? can one just tell it to parse one file as oppose to all 
files all the time ?

Have you found the bundled binaries to work across various OS's ?



/max
http://about.me/maxandersen


From akazakov at exadel.com  Wed Feb 26 14:59:04 2014
From: akazakov at exadel.com (Alexey Kazakov)
Date: Wed, 26 Feb 2014 11:59:04 -0800
Subject: [jbosstools-dev] AngularJS Eclipse
In-Reply-To: <CAKLdLg-fSkTS8E5fMV=Rn-qgStMfWkOKj3zUh0u8ouCUcZmLVg@mail.gmail.com>
References: <CAKLdLg-fSkTS8E5fMV=Rn-qgStMfWkOKj3zUh0u8ouCUcZmLVg@mail.gmail.com>
Message-ID: <530E4788.9050608@exadel.com>

Hi Angelo!

I actually tried some old AngularJS Eclipse plugins available in 
December. Latter I tried the new one and saw a lot of cool stuff like 
{{}} support. It's very nice.

> AngularJS Eclipse extends the WTP HTML Editor (I don't have created a 
> new HTML editor).

There is AngularJS Editor which extends WTP HTML Editor. And I have to 
use this editor if I want to have full support of AngularJS stuff like 
{{}} code completion or code highlighting. Has it been changed?

On 02/26/2014 08:05 AM, Max Rydahl Andersen wrote:
> I tried installing OSX osgi bundle provided node.js and it seems to NPE
> for me ;/

We didn't try the OSX version but there was a bug in the Linux one. 
Victor Rebezhny created a PR to fix it and Angelo has already merged it 
- https://github.com/angelozerr/tern.java/pull/14
There is one more issue with node.js on Linux actually. It's impossible 
to use a local installation of node.js since the command "node" is 
already used at least in some popular distributives like Ubuntu. So if 
you chose to use a local node.js instead of the bundled one then 
"nodejs" command should be used instead of "node".



From vrubezhny at exadel.com  Wed Feb 26 15:36:43 2014
From: vrubezhny at exadel.com (Victor Rubezhny)
Date: Thu, 27 Feb 2014 00:36:43 +0400
Subject: [jbosstools-dev] AngularJS Eclipse
In-Reply-To: <530E4788.9050608@exadel.com>
References: <CAKLdLg-fSkTS8E5fMV=Rn-qgStMfWkOKj3zUh0u8ouCUcZmLVg@mail.gmail.com>
	<530E4788.9050608@exadel.com>
Message-ID: <530E505B.4000602@exadel.com>

On 02/26/2014 11:59 PM, Alexey Kazakov wrote:
> Hi Angelo!
>
> I actually tried some old AngularJS Eclipse plugins available in
> December. Latter I tried the new one and saw a lot of cool stuff like
> {{}} support. It's very nice.
>
>> AngularJS Eclipse extends the WTP HTML Editor (I don't have created a
>> new HTML editor).
> There is AngularJS Editor which extends WTP HTML Editor. And I have to
> use this editor if I want to have full support of AngularJS stuff like
> {{}} code completion or code highlighting. Has it been changed?
>
> On 02/26/2014 08:05 AM, Max Rydahl Andersen wrote:
>> I tried installing OSX osgi bundle provided node.js and it seems to NPE
>> for me ;/
> We didn't try the OSX version but there was a bug in the Linux one.
> Victor Rebezhny created a PR to fix it and Angelo has already merged it
> - https://github.com/angelozerr/tern.java/pull/14
> There is one more issue with node.js on Linux actually. It's impossible
> to use a local installation of node.js since the command "node" is
> already used at least in some popular distributives like Ubuntu. So if
> you chose to use a local node.js instead of the bundled one then
> "nodejs" command should be used instead of "node".

It looks like the issue is a common thing for linuxes. And may be not 
only for linuxes.
In ubuntu you cannot use "node" (because it's reserved for other util, 
not node.js)
in fedora the node.js is not installed to /usr/local/bin/ directory. So, 
due to make it work I had to manually create a link to "node" in 
/usr/local/bin/ directory.
IMHO, there should be a possibility for a user to point Tern.java to 
node.js executable in preferences instead of having some hardly 
predefined path, because the path and the name of node.js executable 
could be different for different OS distributions.
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


From angelo.zerr at gmail.com  Thu Feb 27 06:11:24 2014
From: angelo.zerr at gmail.com (Angelo zerr)
Date: Thu, 27 Feb 2014 12:11:24 +0100
Subject: [jbosstools-dev] AngularJS Eclipse
In-Reply-To: <530E505B.4000602@exadel.com>
References: <CAKLdLg-fSkTS8E5fMV=Rn-qgStMfWkOKj3zUh0u8ouCUcZmLVg@mail.gmail.com>
	<530E4788.9050608@exadel.com> <530E505B.4000602@exadel.com>
Message-ID: <CAKLdLg-buXWwnzTujHpA1KTZVFUWrntqa+B_JPApZDc4OMuCTQ@mail.gmail.com>

Hi Max, Alexey , Victor,

Today it supports it. See screenshots at
> https://github.com/angelozerr/angularjs-eclipse/wiki/HTML-
> Features#wiki-angular-expression-management
>

>and it does that without *running* the project javascript ? that is pure
tern parsed ?

Yes that"s it. But I think I don't manage the whole case. The angular tern
plugin must be improved.

>if yes - that is nice!

Thank's!

>I thought there were things in angularjs context that would not be
possible to extract from javascript?

With Tern plugin you can add you own logic when some methods is called. In
angular plugin case, it forces the $scope parameter used in the controller
to an instance of scope by injecting teh well methods $watch, etc

>Saying this in context of our experiment where we actually ask the browser
what is in the angular scope
>at runtime....but maybe these two approaches could simply be merged and we
get best of both worlds?
Yes I have seen that with your demo with Livereload.

The pros with this mean is that you get the well methods.
The cons with this mean is it doesn't work if your JS is not valid. I have
not managed that, but I would like to manage Hyperlink
for expression (ex : Ctrl+Click on "{{todo"  open the todo.js an select
$scope.todo). With Tern I can do that (because it's an AST)
I think you cannot do that with LiveReload?

>I tried installing OSX osgi bundle provided node.js and it seems to NPE
for me ;/
Yes it was a stupid error and Victor created an issue that I have fixed.

>I thought I actually saw this working but that might have been earlier
version.

>I think the default should be that out of box Tern/angularjs integration
should use the bundled one and
>then advanced users can decide use native one...optimally default users
should not have to care about
>it is using node.
I agree with you. I must improve that, but I develop this plugin in my
spare time and I was very exciting to see tern integrated in Eclipse IDE.
So I have not worked a lot about the node.js topic.

We provide "embed" node.js that you must select when you install Tern IDE.
Perhaps it should better to have an install URL per OS?

As Alexey , Victor suggested me, node.js must be more customizable. I had
created this issue at https://github.com/angelozerr/tern.java/issues/4

>It just needs some enduser polish (i.e. users should not need to care
about different html editors,
>different node.js runtimes, it should "just work").
definitely!

>One concern we had was performance and portability.
>Does Tern handle larger projects of javascript well ?
By using node.js, tern can handle big file. But if you try to parse a big
framework like dojo it takes time.
Today Eclipse freezes, but I must do that in background.

>Can we avoid it have to parse
>constantly ?
>can one just tell it to parse one file as oppose to all files all the time
?
When you open completion, it parses one time the whole files and after it
parses the current file.
I must improve the completion performance by using the "part" feature of
tern (not need to parse each time the whole file).

Today I use Tern for completion, find type in HTML editor. But Tern is
enable to manage search and refactoring.

>Have you found the bundled binaries to work across various OS's ?
No I have just Windows and my friend pascal has Linux.

Have a nice days.

Regards Angelo

2014-02-26 21:36 GMT+01:00 Victor Rubezhny <vrubezhny at exadel.com>:

> On 02/26/2014 11:59 PM, Alexey Kazakov wrote:
> > Hi Angelo!
> >
> > I actually tried some old AngularJS Eclipse plugins available in
> > December. Latter I tried the new one and saw a lot of cool stuff like
> > {{}} support. It's very nice.
> >
> >> AngularJS Eclipse extends the WTP HTML Editor (I don't have created a
> >> new HTML editor).
> > There is AngularJS Editor which extends WTP HTML Editor. And I have to
> > use this editor if I want to have full support of AngularJS stuff like
> > {{}} code completion or code highlighting. Has it been changed?
> >
> > On 02/26/2014 08:05 AM, Max Rydahl Andersen wrote:
> >> I tried installing OSX osgi bundle provided node.js and it seems to NPE
> >> for me ;/
> > We didn't try the OSX version but there was a bug in the Linux one.
> > Victor Rebezhny created a PR to fix it and Angelo has already merged it
> > - https://github.com/angelozerr/tern.java/pull/14
> > There is one more issue with node.js on Linux actually. It's impossible
> > to use a local installation of node.js since the command "node" is
> > already used at least in some popular distributives like Ubuntu. So if
> > you chose to use a local node.js instead of the bundled one then
> > "nodejs" command should be used instead of "node".
>
> It looks like the issue is a common thing for linuxes. And may be not
> only for linuxes.
> In ubuntu you cannot use "node" (because it's reserved for other util,
> not node.js)
> in fedora the node.js is not installed to /usr/local/bin/ directory. So,
> due to make it work I had to manually create a link to "node" in
> /usr/local/bin/ directory.
> IMHO, there should be a possibility for a user to point Tern.java to
> node.js executable in preferences instead of having some hardly
> predefined path, because the path and the name of node.js executable
> could be different for different OS distributions.
> >
> > _______________________________________________
> > jbosstools-dev mailing list
> > jbosstools-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140227/39133d7a/attachment-0001.html 

From mistria at redhat.com  Thu Feb 27 08:37:44 2014
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 27 Feb 2014 14:37:44 +0100
Subject: [jbosstools-dev] Please ignore recent (before 1pm today) failures
	on *_41 jobs
Message-ID: <530F3FA8.1000204@redhat.com>

Hi all,

I missed a step when publishing the 4.32.0.Final target-platform that 
caused most CI jobs to fail.
This has been fixed in the morning and all those jobs have a build 
pending which should show the blue ball again. So you don't have to care 
about those previous failures.

In case you have any doubt with your build, just try it locally with a 
"mvn clean verify -Pmaximum". If it works, don't worry.

Sorry for the noise!
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140227/bf3e4e9d/attachment.html 

From mistria at redhat.com  Thu Feb 27 09:07:51 2014
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 27 Feb 2014 15:07:51 +0100
Subject: [jbosstools-dev] ACTION REQUIRED: JBT 4.1.2.Final / JBDS
 7.1.1.Final Code Freeze is today (2014-02-27)
In-Reply-To: <52A0094D.9050109@redhat.com>
References: <52A0094D.9050109@redhat.com>
Message-ID: <530F46B7.9020807@redhat.com>

Today is the code freeze for JBT 4.1.2.Final / JBDS 7.1.1.Final, for 
code that is on the *jbosstools-4.1.x* branch.

The only thing you have to is to *update parent pom to 
4.1.2.Final-SNAPSHOT* in order to reference the newest target-platform 
(relying on Kepler SR2). Since branch is already existing, nothing to 
create this time. Tags will be created after the built artifacts are 
approved by QA.

Please do it promptly ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140227/cc8a3d78/attachment.html 

From xcoulon at redhat.com  Thu Feb 27 09:15:35 2014
From: xcoulon at redhat.com (Xavier Coulon)
Date: Thu, 27 Feb 2014 15:15:35 +0100
Subject: [jbosstools-dev] ACTION REQUIRED: JBT 4.1.2.Final / JBDS
	7.1.1.Final Code Freeze is today (2014-02-27)
In-Reply-To: <530F46B7.9020807@redhat.com>
References: <52A0094D.9050109@redhat.com> <530F46B7.9020807@redhat.com>
Message-ID: <5178B427-5030-4580-A81D-4F62CDF81A49@redhat.com>

Thanks for the info, Micka?l !

It's done for Web Services and LiveReload

Best regards,
/Xavier



On 27 Feb 2014, at 15:07, Mickael Istria <mistria at redhat.com> wrote:

> Today is the code freeze for JBT 4.1.2.Final / JBDS 7.1.1.Final, for code that is on the jbosstools-4.1.x branch.
> 
> The only thing you have to is to update parent pom to 4.1.2.Final-SNAPSHOT in order to reference the newest target-platform (relying on Kepler SR2). Since branch is already existing, nothing to create this time. Tags will be created after the built artifacts are approved by QA.
> 
> Please do it promptly ;)
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140227/a4da5f74/attachment.html 

From xcoulon at redhat.com  Thu Feb 27 09:17:46 2014
From: xcoulon at redhat.com (Xavier Coulon)
Date: Thu, 27 Feb 2014 15:17:46 +0100
Subject: [jbosstools-dev] Please ignore recent (before 1pm today)
	failures on *_41 jobs
In-Reply-To: <530F3FA8.1000204@redhat.com>
References: <530F3FA8.1000204@redhat.com>
Message-ID: <1B8CB92B-E81D-455B-8F0F-A934E3EA5E9D@redhat.com>

No problem, thanks for the feedback !

Best regards,
/Xavier



On 27 Feb 2014, at 14:37, Mickael Istria <mistria at redhat.com> wrote:

> Hi all,
> 
> I missed a step when publishing the 4.32.0.Final target-platform that caused most CI jobs to fail.
> This has been fixed in the morning and all those jobs have a build pending which should show the blue ball again. So you don't have to care about those previous failures.
> 
> In case you have any doubt with your build, just try it locally with a "mvn clean verify -Pmaximum". If it works, don't worry.
> 
> Sorry for the noise!
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140227/a7c7a3e1/attachment.html 

From snjezana.peco at redhat.com  Thu Feb 27 11:54:19 2014
From: snjezana.peco at redhat.com (Snjezana Peco)
Date: Thu, 27 Feb 2014 17:54:19 +0100
Subject: [jbosstools-dev] ACTION REQUIRED: JBT 4.1.2.Final / JBDS
 7.1.1.Final Code Freeze is today (2014-02-27)
In-Reply-To: <530F46B7.9020807@redhat.com>
References: <52A0094D.9050109@redhat.com> <530F46B7.9020807@redhat.com>
Message-ID: <530F6DBB.3030900@redhat.com>

Done for arquillian, birt and portlet.

Snjeza

On 2/27/2014 3:07 PM, Mickael Istria wrote:
> Today is the code freeze for JBT 4.1.2.Final / JBDS 7.1.1.Final, for 
> code that is on the *jbosstools-4.1.x* branch.
>
> The only thing you have to is to *update parent pom to 
> 4.1.2.Final-SNAPSHOT* in order to reference the newest target-platform 
> (relying on Kepler SR2). Since branch is already existing, nothing to 
> create this time. Tags will be created after the built artifacts are 
> approved by QA.
>
> Please do it promptly ;)
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140227/6f90e3e2/attachment.html 

From akazakov at exadel.com  Thu Feb 27 14:41:54 2014
From: akazakov at exadel.com (Alexey Kazakov)
Date: Thu, 27 Feb 2014 11:41:54 -0800
Subject: [jbosstools-dev] ACTION REQUIRED: JBT 4.1.2.Final / JBDS
 7.1.1.Final Code Freeze is today (2014-02-27)
In-Reply-To: <530F46B7.9020807@redhat.com>
References: <52A0094D.9050109@redhat.com> <530F46B7.9020807@redhat.com>
Message-ID: <530F9502.7040709@exadel.com>

base, javaee, jst - done

On 02/27/2014 06:07 AM, Mickael Istria wrote:
> Today is the code freeze for JBT 4.1.2.Final / JBDS 7.1.1.Final, for 
> code that is on the *jbosstools-4.1.x* branch.
>
> The only thing you have to is to *update parent pom to 
> 4.1.2.Final-SNAPSHOT* in order to reference the newest target-platform 
> (relying on Kepler SR2). Since branch is already existing, nothing to 
> create this time. Tags will be created after the built artifacts are 
> approved by QA.
>
> Please do it promptly ;)
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140227/a9f31ccb/attachment.html 

From fbricon at redhat.com  Thu Feb 27 18:17:34 2014
From: fbricon at redhat.com (Fred Bricon)
Date: Fri, 28 Feb 2014 00:17:34 +0100
Subject: [jbosstools-dev] ACTION REQUIRED: JBT 4.1.2.Final / JBDS
 7.1.1.Final Code Freeze is today (2014-02-27)
In-Reply-To: <530F46B7.9020807@redhat.com>
References: <52A0094D.9050109@redhat.com> <530F46B7.9020807@redhat.com>
Message-ID: <530FC78E.7030902@redhat.com>

jbosstools-central done

Le 27/02/2014 15:07, Mickael Istria a ?crit :
> Today is the code freeze for JBT 4.1.2.Final / JBDS 7.1.1.Final, for 
> code that is on the *jbosstools-4.1.x* branch.
>
> The only thing you have to is to *update parent pom to 
> 4.1.2.Final-SNAPSHOT* in order to reference the newest target-platform 
> (relying on Kepler SR2). Since branch is already existing, nothing to 
> create this time. Tags will be created after the built artifacts are 
> approved by QA.
>
> Please do it promptly ;)
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140228/4b1d81fd/attachment-0001.html 

From optimus at cybertrons.net  Fri Feb 28 00:58:14 2014
From: optimus at cybertrons.net (xrogvb315)
Date: Fri, 28 Feb 2014 13:58:14 +0800
Subject: [jbosstools-dev] =?gb2312?b?08PK/dfWy7W7sDc0MDU3Njc0MDU3Ng==?=
Message-ID: <201402280558.s1S5wJKp020584@lists01.dmz-a.mwc.hst.phx2.redhat.com>


               ??????------???????????  ?????


??????2014?3?15-16????3?20-21????3?22-23???
?????????????????????????????????????
            ??????
?????????? + ???? + ???? +???? + ???? + ?????
??????4800/???????????????3200????????????????
??????????0755 6128 3537?????021-5103 6383  150 7427 5950
????????????????????????????????????????
??????
    ????????????????????????????????????
??????????????????????????????????????
??????????????????????????????????????
??????????????????????????????????????
??????????????????????????????????????
??????????????????????????????????????
?????????????????????????????????????
??????BladeOffice?????????????????????

?????
	????????????????????Microsoft office2007?????
??Excel????????
?????????BladeOffice???????????????????????
????
????????????????????????????????????????
??????
????????
??????????????????????????????????????
??????????????????????????????????????
???????...
????????
??????????
????????????
???????????????
??????????????
??????????????????????????????????????
?????????????????????

??????
?????????????????????????????????? ???
????????????????

??????????
????????????????
?KPI??????????
????????????
?????????????
??????
????


??????
????????????????????????????

??????????????
?????????
????????
?????????
?????????


?????????????
?????????????????????????????????????
????????

???????????
?????????
????????
??????
??????????


????????
???????????????????????????????????????

?????????
??????
??????
??????

??????????????????????

??????
?????????????????????????????????????

?????????
????????
??????
???????
??????
????????


??????
?????????????????????????????????????
?????????????????????????????????????
????????

?????????
???????
?????????
????????RFM??
?????????????
???????


????????
??????????????????????????????????????
???????????

?????????
???????
?????????????
???????
????
?????????

????????????????????????????????????????
??????  
??   ?????

??????
????????IPMA???????MCSE?MCDBA???????????????
??????????????????????????????????????
???OA?ERP?BI?????????????????????????????
??????????????????????????????
????????????
??????????????? 
??????????????
????????              
 ??????????????

?Excel?Access?POWERPOINT??????????

??????????????
????????????????????????????????????????
?????????OPPO????????????????????????????
??????????????????????????????????????
????????????????????????????????Bacardi?
????????????????????????????????????
??????????????????????????????????????
CTI??????????????(?????)??????????????
???????????????????????????????????
??????????????????????????(??)??????????
?????????????????????(???????????????)?
????(??????????????????????????????)?
??(?????)?????(?????)??????(???????)???
???????????????????????????????????
?????????????????????????????????????
????????????????????????????????????
???????????????????????????MBA???

????????
????????EXCEL?????????????????????
                                --------------------??????????
?EXCEL???????????????????????????????????
??????????????
?????????????--------------------?????????????
????????????????????????????????????
????????????PPT??????????????PPT???????
???????
                          --------------------?????????????
???????????????????????????
                --------------------??????????????????
????????????????????????????????????????
740576740576

From snjezana.peco at redhat.com  Fri Feb 28 08:55:03 2014
From: snjezana.peco at redhat.com (Snjezana Peco)
Date: Fri, 28 Feb 2014 14:55:03 +0100
Subject: [jbosstools-dev] https://issues.jboss.org/browse/JBIDE-16665 - Add
	Sapphire to TP
Message-ID: <53109537.7030504@redhat.com>

Hi,

The Sapphire framework enables us to easily create editors, wizards, 
dialogs ...
You can see the Arquillian XML editor created using this framework: 
https://issues.jboss.org/browse/JBIDE-15394

It would be good to have the Sapphire framework in our TP.

Thanks,
Snjeza



From manderse at redhat.com  Fri Feb 28 09:09:59 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 28 Feb 2014 15:09:59 +0100
Subject: [jbosstools-dev] https://issues.jboss.org/browse/JBIDE-16665 -
	Add Sapphire to TP
In-Reply-To: <53109537.7030504@redhat.com>
References: <53109537.7030504@redhat.com>
Message-ID: <05FE862E-C75F-44F7-A856-7C1E11C04CC2@redhat.com>

On 28 Feb 2014, at 14:55, Snjezana Peco wrote:

> Hi,
>
> The Sapphire framework enables us to easily create editors, wizards, 
> dialogs ...
> You can see the Arquillian XML editor created using this framework: 
> https://issues.jboss.org/browse/JBIDE-15394
>
> It would be good to have the Sapphire framework in our TP.
can you create a jira for it with the info asked for in here 
https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platforms_updates.adoc 
?

ping on irc and mistrial, nboldt, me and others can help locate any info 
you might not be able to locate.

/max
http://about.me/maxandersen


From snjezana.peco at redhat.com  Fri Feb 28 09:43:03 2014
From: snjezana.peco at redhat.com (Snjezana Peco)
Date: Fri, 28 Feb 2014 15:43:03 +0100
Subject: [jbosstools-dev] https://issues.jboss.org/browse/JBIDE-16665 -
 Add Sapphire to TP
In-Reply-To: <05FE862E-C75F-44F7-A856-7C1E11C04CC2@redhat.com>
References: <53109537.7030504@redhat.com>
	<05FE862E-C75F-44F7-A856-7C1E11C04CC2@redhat.com>
Message-ID: <5310A077.7000206@redhat.com>

On 2/28/2014 3:09 PM, Max Rydahl Andersen wrote:
> On 28 Feb 2014, at 14:55, Snjezana Peco wrote:
>
>> Hi,
>>
>> The Sapphire framework enables us to easily create editors, wizards, 
>> dialogs ...
>> You can see the Arquillian XML editor created using this framework: 
>> https://issues.jboss.org/browse/JBIDE-15394
>>
>> It would be good to have the Sapphire framework in our TP.
> can you create a jira for it with the info asked for in here 
> https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platforms_updates.adoc 
> ?
>
> ping on irc and mistrial, nboldt, me and others can help locate any 
> info you might not be able to locate.
>
>

I have created https://issues.jboss.org/browse/JBIDE-16665 .

Snjeza


From manderse at redhat.com  Fri Feb 28 11:35:20 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 28 Feb 2014 17:35:20 +0100
Subject: [jbosstools-dev] AngularJS Eclipse
In-Reply-To: <CAKLdLg-buXWwnzTujHpA1KTZVFUWrntqa+B_JPApZDc4OMuCTQ@mail.gmail.com>
References: <CAKLdLg-fSkTS8E5fMV=Rn-qgStMfWkOKj3zUh0u8ouCUcZmLVg@mail.gmail.com>
	<530E4788.9050608@exadel.com> <530E505B.4000602@exadel.com>
	<CAKLdLg-buXWwnzTujHpA1KTZVFUWrntqa+B_JPApZDc4OMuCTQ@mail.gmail.com>
Message-ID: <117417CF-888C-46D3-BB6C-C1CB676ADA0D@redhat.com>

>> Saying this in context of our experiment where we actually ask the 
>> browser
> what is in the angular scope
>> at runtime....but maybe these two approaches could simply be merged 
>> and we
> get best of both worlds?
> Yes I have seen that with your demo with Livereload.
>
> The pros with this mean is that you get the well methods.
> The cons with this mean is it doesn't work if your JS is not valid. I 
> have
> not managed that, but I would like to manage Hyperlink
> for expression (ex : Ctrl+Click on "{{todo"  open the todo.js an 
> select
> $scope.todo). With Tern I can do that (because it's an AST)
> I think you cannot do that with LiveReload?

No, but that is why I merging those two approaches would give best of 
both worlds.

>> I tried installing OSX osgi bundle provided node.js and it seems to 
>> NPE
> for me ;/
> Yes it was a stupid error and Victor created an issue that I have 
> fixed.

I updated the plugin and I can see the node and npm binaries are not 
executable
so I get an error like:

Cannot run program 
"/Users/max/products/eclipse/luna/eclipse/plugins/tern.eclipse.ide.server.nodejs.embed.macosx.cocoa.x86_64_1.0.0.201402271715/nodejs/node-v0.10.22-macosx-x86_64/bin/node" 
(in directory "/Users/max/Documents/workspace-luna3/dfdf"): error=13, 
Permission denied

When I chmod +X those files it seem to start working.

>> I thought I actually saw this working but that might have been 
>> earlier
> version.
>
>> I think the default should be that out of box Tern/angularjs 
>> integration
> should use the bundled one and
>> then advanced users can decide use native one...optimally default 
>> users
> should not have to care about
>> it is using node.
> I agree with you. I must improve that, but I develop this plugin in my
> spare time and I was very exciting to see tern integrated in Eclipse 
> IDE.
> So I have not worked a lot about the node.js topic.
>
> We provide "embed" node.js that you must select when you install Tern 
> IDE.
> Perhaps it should better to have an install URL per OS?

noo - not necessary. You can mark a bundle to just apply to a specific 
OS via Eclipse-PlatformFilter

See 
https://github.com/jbosstools/jbosstools-xulrunner/blob/master/plugins/org.mozilla.xulrunner.gtk.linux.x86/META-INF/MANIFEST.MF#L9 
as an example.

I would suggest making the feature default require these plugins so any 
install by default would work.

>> It just needs some enduser polish (i.e. users should not need to care
> about different html editors,
>> different node.js runtimes, it should "just work").
> definitely!
>
>> One concern we had was performance and portability.
>> Does Tern handle larger projects of javascript well ?
> By using node.js, tern can handle big file. But if you try to parse a 
> big
> framework like dojo it takes time.
> Today Eclipse freezes, but I must do that in background.

Is there an issue for this somewhere ?

>> Can we avoid it have to parse
>> constantly ?
>> can one just tell it to parse one file as oppose to all files all the 
>> time
> ?
> When you open completion, it parses one time the whole files and after 
> it
> parses the current file.
> I must improve the completion performance by using the "part" feature 
> of
> tern (not need to parse each time the whole file).

> Today I use Tern for completion, find type in HTML editor. But Tern is
> enable to manage search and refactoring.

>> Have you found the bundled binaries to work across various OS's ?
> No I have just Windows and my friend pascal has Linux.
>
> Have a nice days.
>
> Regards Angelo
>
> 2014-02-26 21:36 GMT+01:00 Victor Rubezhny <vrubezhny at exadel.com>:

/max


From vrubezhny at exadel.com  Fri Feb 28 11:44:48 2014
From: vrubezhny at exadel.com (Victor Rubezhny)
Date: Fri, 28 Feb 2014 20:44:48 +0400
Subject: [jbosstools-dev] AngularJS Eclipse
In-Reply-To: <117417CF-888C-46D3-BB6C-C1CB676ADA0D@redhat.com>
References: <CAKLdLg-fSkTS8E5fMV=Rn-qgStMfWkOKj3zUh0u8ouCUcZmLVg@mail.gmail.com>	<530E4788.9050608@exadel.com>
	<530E505B.4000602@exadel.com>	<CAKLdLg-buXWwnzTujHpA1KTZVFUWrntqa+B_JPApZDc4OMuCTQ@mail.gmail.com>
	<117417CF-888C-46D3-BB6C-C1CB676ADA0D@redhat.com>
Message-ID: <5310BD00.9080209@exadel.com>

On 02/28/2014 08:35 PM, Max Rydahl Andersen wrote:
>>> Saying this in context of our experiment where we actually ask the
>>> browser
>> what is in the angular scope
>>> at runtime....but maybe these two approaches could simply be merged
>>> and we
>> get best of both worlds?
>> Yes I have seen that with your demo with Livereload.
>>
>> The pros with this mean is that you get the well methods.
>> The cons with this mean is it doesn't work if your JS is not valid. I
>> have
>> not managed that, but I would like to manage Hyperlink
>> for expression (ex : Ctrl+Click on "{{todo"  open the todo.js an
>> select
>> $scope.todo). With Tern I can do that (because it's an AST)
>> I think you cannot do that with LiveReload?
> No, but that is why I merging those two approaches would give best of
> both worlds.
>
>>> I tried installing OSX osgi bundle provided node.js and it seems to
>>> NPE
>> for me ;/
>> Yes it was a stupid error and Victor created an issue that I have
>> fixed.
> I updated the plugin and I can see the node and npm binaries are not
> executable
> so I get an error like:
>
> Cannot run program
> "/Users/max/products/eclipse/luna/eclipse/plugins/tern.eclipse.ide.server.nodejs.embed.macosx.cocoa.x86_64_1.0.0.201402271715/nodejs/node-v0.10.22-macosx-x86_64/bin/node"
> (in directory "/Users/max/Documents/workspace-luna3/dfdf"): error=13,
> Permission denied
>
> When I chmod +X those files it seem to start working.
I wasn't required to change "executable" attribute on my Fedora 20 
x86_64. What kind of problem it could be: the problem of OSX or wrong 
executable attribute for "node" and "executable" binaries in repository?

>>> I thought I actually saw this working but that might have been
>>> earlier
>> version.
>>
>>> I think the default should be that out of box Tern/angularjs
>>> integration
>> should use the bundled one and
>>> then advanced users can decide use native one...optimally default
>>> users
>> should not have to care about
>>> it is using node.
>> I agree with you. I must improve that, but I develop this plugin in my
>> spare time and I was very exciting to see tern integrated in Eclipse
>> IDE.
>> So I have not worked a lot about the node.js topic.
>>
>> We provide "embed" node.js that you must select when you install Tern
>> IDE.
>> Perhaps it should better to have an install URL per OS?
> noo - not necessary. You can mark a bundle to just apply to a specific
> OS via Eclipse-PlatformFilter
>
> See
> https://github.com/jbosstools/jbosstools-xulrunner/blob/master/plugins/org.mozilla.xulrunner.gtk.linux.x86/META-INF/MANIFEST.MF#L9
> as an example.
>
> I would suggest making the feature default require these plugins so any
> install by default would work.
>
>>> It just needs some enduser polish (i.e. users should not need to care
>> about different html editors,
>>> different node.js runtimes, it should "just work").
>> definitely!
>>
>>> One concern we had was performance and portability.
>>> Does Tern handle larger projects of javascript well ?
>> By using node.js, tern can handle big file. But if you try to parse a
>> big
>> framework like dojo it takes time.
>> Today Eclipse freezes, but I must do that in background.
> Is there an issue for this somewhere ?
>
>>> Can we avoid it have to parse
>>> constantly ?
>>> can one just tell it to parse one file as oppose to all files all the
>>> time
>> ?
>> When you open completion, it parses one time the whole files and after
>> it
>> parses the current file.
>> I must improve the completion performance by using the "part" feature
>> of
>> tern (not need to parse each time the whole file).
>> Today I use Tern for completion, find type in HTML editor. But Tern is
>> enable to manage search and refactoring.
>>> Have you found the bundled binaries to work across various OS's ?
>> No I have just Windows and my friend pascal has Linux.
>>
>> Have a nice days.
>>
>> Regards Angelo
>>
>> 2014-02-26 21:36 GMT+01:00 Victor Rubezhny <vrubezhny at exadel.com>:
> /max
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


From mistria at redhat.com  Fri Feb 28 11:51:32 2014
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 28 Feb 2014 17:51:32 +0100
Subject: [jbosstools-dev] Does your code depend on Zest or GEF ?
Message-ID: <5310BE94.6@redhat.com>

Hi all,

I could notice target-platform currently contains a few features related 
to GEF and Zest.
Is anyone actually using them or could we investigate removing them from 
the Target-platform? (some bundles would remain pulled transitively anyway).

Cheers,
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140228/ac900a77/attachment-0001.html 

From manderse at redhat.com  Fri Feb 28 12:02:07 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 28 Feb 2014 18:02:07 +0100
Subject: [jbosstools-dev] AngularJS Eclipse
In-Reply-To: <5310BD00.9080209@exadel.com>
References: <CAKLdLg-fSkTS8E5fMV=Rn-qgStMfWkOKj3zUh0u8ouCUcZmLVg@mail.gmail.com>
	<530E4788.9050608@exadel.com> <530E505B.4000602@exadel.com>
	<CAKLdLg-buXWwnzTujHpA1KTZVFUWrntqa+B_JPApZDc4OMuCTQ@mail.gmail.com>
	<117417CF-888C-46D3-BB6C-C1CB676ADA0D@redhat.com>
	<5310BD00.9080209@exadel.com>
Message-ID: <522B9BC3-A7FF-487B-A872-B9440C4AA3F2@redhat.com>

>> Cannot run program
>> "/Users/max/products/eclipse/luna/eclipse/plugins/tern.eclipse.ide.server.nodejs.embed.macosx.cocoa.x86_64_1.0.0.201402271715/nodejs/node-v0.10.22-macosx-x86_64/bin/node"
>> (in directory "/Users/max/Documents/workspace-luna3/dfdf"): error=13,
>> Permission denied
>>
>> When I chmod +X those files it seem to start working.
> I wasn't required to change "executable" attribute on my Fedora 20
> x86_64. What kind of problem it could be: the problem of OSX or wrong
> executable attribute for "node" and "executable" binaries in 
> repository?

don't know - could be both if the code for launching is done differently 
on the OS's too.

/max


From angelo.zerr at gmail.com  Fri Feb 28 12:05:16 2014
From: angelo.zerr at gmail.com (Angelo zerr)
Date: Fri, 28 Feb 2014 18:05:16 +0100
Subject: [jbosstools-dev] AngularJS Eclipse
In-Reply-To: <5310BD00.9080209@exadel.com>
References: <CAKLdLg-fSkTS8E5fMV=Rn-qgStMfWkOKj3zUh0u8ouCUcZmLVg@mail.gmail.com>
	<530E4788.9050608@exadel.com> <530E505B.4000602@exadel.com>
	<CAKLdLg-buXWwnzTujHpA1KTZVFUWrntqa+B_JPApZDc4OMuCTQ@mail.gmail.com>
	<117417CF-888C-46D3-BB6C-C1CB676ADA0D@redhat.com>
	<5310BD00.9080209@exadel.com>
Message-ID: <CAKLdLg8UrN9EgsY6RjMjrGK42e9Q6752FLrCbuhppjdmEWiyEQ@mail.gmail.com>

Hi,

At first I have commited an improvment about Node.js preferences. Now you
can set the node.js path. See attached screenshot.
The combo is filled with default path according the OS. If your node is not
installed in the default path, it searchs in your PATH env if you have a
node path to retrieve the well path.

> I updated the plugin and I can see the node and npm binaries are not
> > executable
> > so I get an error like:
> >
> > Cannot run program
> >
> "/Users/max/products/eclipse/luna/eclipse/plugins/tern.eclipse.ide.server.nodejs.embed.macosx.cocoa.x86_64_1.0.0.201402271715/nodejs/node-v0.10.22-macosx-x86_64/bin/node"
> > (in directory "/Users/max/Documents/workspace-luna3/dfdf"): error=13,
> > Permission denied
> >
> > When I chmod +X those files it seem to start working.
> I wasn't required to change "executable" attribute on my Fedora 20
> x86_64. What kind of problem it could be: the problem of OSX or wrong
> executable attribute for "node" and "executable" binaries in repository?
>

It's my friend Pascal who has created this embed node.js, I will answer you
but now he is on holiday.
But with my improvement, you can try to install node.js in your computer
and use "Native Node.js".

If you want to see the command line of node.js + teh JSON request/response
used with tern server, you can see those traces in Eclipse Console.
See https://github.com/angelozerr/tern.java/wiki/Tern-Console

>
> >> Perhaps it should better to have an install URL per OS?
> > noo - not necessary. You can mark a bundle to just apply to a specific
> > OS via Eclipse-PlatformFilter
> >
> > See
> >
> https://github.com/jbosstools/jbosstools-xulrunner/blob/master/plugins/org.mozilla.xulrunner.gtk.linux.x86/META-INF/MANIFEST.MF#L9
> > as an example.
> >
> > I would suggest making the feature default require these plugins so any
> > install by default would work.
>

Many thank's for your information. I will speak to Pascal about this idea.

>> Today Eclipse freezes, but I must do that in background.
> > Is there an issue for this somewhere ?
>

There is 2 issues about tern performance :

 * "Parse JS file of tern doc with monitor" =>
https://github.com/angelozerr/tern.java/issues/5
 * "Improve performance with JS Editor and tern completion" =>
https://github.com/angelozerr/tern.java/issues/6


> >
> >>> Can we avoid it have to parse
> >>> constantly ?
> >>> can one just tell it to parse one file as oppose to all files all the
> >>> time
> >> ?
> >> When you open completion, it parses one time the whole files and after
> >> it
> >> parses the current file.
> >> I must improve the completion performance by using the "part" feature
> >> of
> >> tern (not need to parse each time the whole file).
> >> Today I use Tern for completion, find type in HTML editor. But Tern is
> >> enable to manage search and refactoring.
> >>> Have you found the bundled binaries to work across various OS's ?
> >> No I have just Windows and my friend pascal has Linux.
> >>
> >> Have a nice days.
> >>
> >> Regards Angelo
> >>
> >> 2014-02-26 21:36 GMT+01:00 Victor Rubezhny <vrubezhny at exadel.com>:
> > /max
> >
> > _______________________________________________
> > jbosstools-dev mailing list
> > jbosstools-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140228/c7950000/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TernNodePath.png
Type: image/png
Size: 20860 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140228/c7950000/attachment-0001.png 

From mistria at redhat.com  Fri Feb 28 12:08:41 2014
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 28 Feb 2014 18:08:41 +0100
Subject: [jbosstools-dev] Does your code depend on Zest or GEF ?
In-Reply-To: <10C27269-47AD-4D8B-A852-F8B271BF9732@redhat.com>
References: <5310BE94.6@redhat.com>
	<10C27269-47AD-4D8B-A852-F8B271BF9732@redhat.com>
Message-ID: <5310C299.4030302@redhat.com>

On 02/28/2014 06:00 PM, Max Rydahl Andersen wrote:
> eh - just do a grep. we got plenty of org.eclipse.gef in base.
Ok, I've seen it's extensively used by hibernate.
> zest seem to be used by jbosstools-esb.
AFAIK, jbosstools-esb is not part of JBoss Tools core, but more of JBoss 
Tools Integration Stack. So we might be able to remove this from our TP 
and add it to JBTIS one instead.
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140228/c2066b3f/attachment.html 

From manderse at redhat.com  Fri Feb 28 12:00:01 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 28 Feb 2014 18:00:01 +0100
Subject: [jbosstools-dev] Does your code depend on Zest or GEF ?
In-Reply-To: <5310BE94.6@redhat.com>
References: <5310BE94.6@redhat.com>
Message-ID: <10C27269-47AD-4D8B-A852-F8B271BF9732@redhat.com>

On 28 Feb 2014, at 17:51, Mickael Istria wrote:

> Hi all,
>
> I could notice target-platform currently contains a few features 
> related to GEF and Zest.
> Is anyone actually using them or could we investigate removing them 
> from the Target-platform? (some bundles would remain pulled 
> transitively anyway).

eh - just do a grep. we got plenty of org.eclipse.gef in base.

zest seem to be used by jbosstools-esb.

/max



>
> Cheers,
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets 
> <http://twitter.com/mickaelistria>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen

From p.g.richardson at phantomjinx.co.uk  Fri Feb 28 14:46:05 2014
From: p.g.richardson at phantomjinx.co.uk (phantomjinx)
Date: Fri, 28 Feb 2014 19:46:05 +0000
Subject: [jbosstools-dev] Does your code depend on Zest or GEF ?
In-Reply-To: <5310BE94.6@redhat.com>
References: <5310BE94.6@redhat.com>
Message-ID: <5310E77D.4090206@phantomjinx.co.uk>

On 02/28/2014 04:51 PM, Mickael Istria wrote:
> Hi all,
>
> I could notice target-platform currently contains a few features related to GEF and Zest.
> Is anyone actually using them or could we investigate removing them from the Target-platform?
> (some bundles would remain pulled transitively anyway).
>
Teiid Designer uses GEF for it modelling graphics.

PGR

-- 

Paul Richardson

  * p.g.richardson at phantomjinx.co.uk
  * p.g.richardson at redhat.com
  * pgrichardson at linux.com

"I know exactly who reads the papers ...

  * The Daily Mirror is read by people who think they run the country.
  * The Guardian is read by people who think they ought to run the country.
  * The Times is read by people who do actually run the country.
  * The Daily Mail is read by the wives of the people who run the country.
  * The Financial Times is read by the people who own the country.
  * The Morning Star is read by the people who think the country ought to be run by another country.
  * The Daily Telegraph is read by the people who think it is."

Jim Hacker, Yes Minister