[JBoss JIRA] (ERT-531) Maven 3.3.1 doesn't pick up the customized Toolchain for the WTP build [EBZ#472084]
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/ERT-531?page=com.atlassian.jira.plugin.sy... ]
Nick Boldt updated ERT-531:
---------------------------
Sprint: (was: devex #141 December 2017)
> Maven 3.3.1 doesn't pick up the customized Toolchain for the WTP build [EBZ#472084]
> -----------------------------------------------------------------------------------
>
> Key: ERT-531
> URL: https://issues.jboss.org/browse/ERT-531
> Project: Eclipse Release Train
> Issue Type: Task
> Components: Community
> Reporter: Friendly Jira Robot
> Assignee: Nick Boldt
> Priority: Critical
> Labels: Hudson, bzira
>
> A few WTP plugins need to build with the old JDK and a WTP toolchains.xml is set up. It works fine with Maven 3.2.5 but fails with Maven 3.3.1.
> The current investigation showed that instead of using the WTP specific toolchains.xml which is defined in the Hudson build configuration, a common toolchains /opt/public/common/maven-toolchains.xml is linked as the user toolchains.
> genie.gef ~> ll ~/.m2
> [....]
> lrwxrwxrwx 1 genie.gef tools.gef 37 23 févr. 04:05 settings.xml -> /opt/public/common/maven-settings.xml
> lrwxrwxrwx 1 genie.gef tools.gef 39 23 févr. 04:05 toolchains.xml -> /opt/public/common/maven-toolchains.xml
> I wonder how Maven 3.2.5 can pick up the customized toolchains but not 3.3.1. It would be great if Maven 3.3.1 can pick up the customized toolchains as 3.2.5.
> At the same time, I wonder whether the common toolchains file can be changed to support IBM JDK 1.4. Its current JDK 1.4 points to the Sun's which is broken and generates compile errors.
> <toolchain>
> <type>jdk</type>
> <provides>
> <id>J2SE-1.4</id>
> </provides>
> <configuration>
> <jdkHome>/shared/webtools/apps/IBMJava2-142-SR13FP10/jre</jdkHome>
> </configuration>
> </toolchain>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JBIDE-25303) Server adapter: support hot-deployment on OpenShift for SpringBoot app
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25303?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-25303:
------------------------------------------
here's a screencast showing hot code replace working with the fuse-on-openshift demo app that's attached to this jira: https://youtu.be/YJXKtR1DcGI
So there are 2 issues left here:
# It looks as if the DEV_MODE env var isnt used, only DEBUG is (see my question in [OSFUSE-548|https://issues.jboss.org/browse/OSFUSE-548?focusedCommentId=13...]
# the packaging is still done via "Deployment Assembly" in the project preferences. We need to decide how to deal that.
> Server adapter: support hot-deployment on OpenShift for SpringBoot app
> ----------------------------------------------------------------------
>
> Key: JBIDE-25303
> URL: https://issues.jboss.org/browse/JBIDE-25303
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.5.1.Final
> Reporter: Aurélien Pupier
> Assignee: Andre Dietisheim
> Labels: openshift_v3, server_adapter
> Fix For: 4.5.2.AM3
>
> Attachments: fuse-on-openshift.zip, project-deployment-assembly.png, spring-boot-demo.zip
>
>
> currently, Springboot jar projects (such as Fuse Integration Services) are rsynced with a zipped jar file.
> The requirements are:
> - rsync unpacked jar
> - rsync without the jar name as folder
> - it will will work only if springboot devtool are included (so maybe need some dialog guiding user to do i in case it is not activated)
> use case "Develop SpringBoot application deployed on OpenShift as any other applications in JBoss Tools":
> - there is a SpringBoot app deployed on OpenShift
> - the developer want to develop evolution of the SpringBoot app
> -- when he/she modifies the project, the application needs to be automatically updated on OpenShift instance
> -- Remote java debug should be available when the OpenShift server adapter is in debug mode.
> Steps:
> # EXEC: create a project in your OpenShift server (ex. camel-ose-springboot)
> # EXEC: Import project within fuse-on-openshift.zip into your workspace
> # EXEC: open launch configuration and change:
> ** -Dkubernetes.master= so that it first your cdk instance
> ** -Dkubernetes.namespace= to the name of the project that you create in step 1.
> # EXEC: run the launch config (that is included in the project), so that the project gets deployed to OpenShift (cdk)
> # ASSERT: your project in OpenShift now contains a service **camel-ose-springboot-xml**, the pod for it is running.
> # EXEC: in OpenShift Explorer: select this service and create a server adapter for it (*Server Adapter..* in the context menu for the service)
> # ASSERT: server adapter is created and is *[started]*
> # EXEC: in OpenShift Explorer: pick *Pod Log...* in the context menu for the pod of your service)
> # ASSERT: pod log is opened in "Console" view and shows an output with random numbers in the end
> {code}
> simple-route - >>> 455
> simple-route - >>> 695
> simple-route - >>> 935
> {code}
> # EXEC: In Project Explorer: open class MyTransformer and change the transform method
> # ASSERT: "Console" view is opened and shows how the server adapter is publishing the MyTransformer class to the pod
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (ERT-550) Benchmark old and new JDT Indexers
by Roland Grunberg (JIRA)
[ https://issues.jboss.org/browse/ERT-550?page=com.atlassian.jira.plugin.sy... ]
Roland Grunberg closed ERT-550.
-------------------------------
Resolution: Done
Task completed. We have a much better idea of the performance of the new indexer relative to the old one. Unfortunately I'm as of yet, unable to show a case (in the context of the call hierarchy workflow) where the new indexer outperforms the old one.
The testing also exposed some UI performance issues (with respect to Tree widgets) on the Linux/GTK side that should get addressed.
> Benchmark old and new JDT Indexers
> ----------------------------------
>
> Key: ERT-550
> URL: https://issues.jboss.org/browse/ERT-550
> Project: Eclipse Release Train
> Issue Type: Task
> Reporter: Roland Grunberg
> Assignee: Roland Grunberg
>
> Benchmark the old and new JDT Indexers to determine which should be favoured in various conditions.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JBIDE-25438) Refactor CDK itests to be more stable against CDK starts that fail sometimes
by Ondrej Dockal (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25438?page=com.atlassian.jira.plugi... ]
Ondrej Dockal updated JBIDE-25438:
----------------------------------
Description:
Refactor cdk itests to avoid starting cdk over and over again in each test case which will result in better performance and health of jenkins jobs.
* repair discovery itests
* finish adding of mocking cdk binaries in unsupported cdk versions
* update suites to run faster test classes
* remove deprecated test cases
* think of skipping registration and adding one test case that will start cdk with registration
* extends shellisavailable condition to accept other error dialogs as well ("Multiple problems have occured") during adapter operations
Issues to be addressed or incidents that cause fail of job run:
* CDK-216
* JBIDE-25443
* https://status.redhat.com/incidents/s7tzh47440f5
* JBIDE-25446
* CDK-220 (cdk-3.3.0)
was:
Refactor cdk itests to avoid starting cdk over and over again in each test case which will result in better performance and health of jenkins jobs.
* repair discovery itests
* finish adding of mocking cdk binaries in unsupported cdk versions
* update suites to run faster test classes
* remove deprecated test cases
* think of skipping registration and adding one test case that will start cdk with registration
* extends shellisavailable condition to accept other error dialogs as well ("Multiple problems have occured") during adapter operations
Issues to be addressed or incidents that cause fail of job run:
* CDK-216
* JBIDE-25443
* https://status.redhat.com/incidents/s7tzh47440f5
* JBIDE-25446
> Refactor CDK itests to be more stable against CDK starts that fail sometimes
> ----------------------------------------------------------------------------
>
> Key: JBIDE-25438
> URL: https://issues.jboss.org/browse/JBIDE-25438
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: integration-tests
> Affects Versions: 4.5.2.AM2
> Reporter: Ondrej Dockal
> Assignee: Ondrej Dockal
> Priority: Critical
> Fix For: 4.5.2.AM2
>
>
> Refactor cdk itests to avoid starting cdk over and over again in each test case which will result in better performance and health of jenkins jobs.
> * repair discovery itests
> * finish adding of mocking cdk binaries in unsupported cdk versions
> * update suites to run faster test classes
> * remove deprecated test cases
> * think of skipping registration and adding one test case that will start cdk with registration
> * extends shellisavailable condition to accept other error dialogs as well ("Multiple problems have occured") during adapter operations
> Issues to be addressed or incidents that cause fail of job run:
> * CDK-216
> * JBIDE-25443
> * https://status.redhat.com/incidents/s7tzh47440f5
> * JBIDE-25446
> * CDK-220 (cdk-3.3.0)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months