[JBoss JIRA] (JBIDE-22818) vagrant service-manager call experiences timeout after output
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22818?page=com.atlassian.jira.plugi... ]
Rob Stryker reassigned JBIDE-22818:
-----------------------------------
Assignee: Rob Stryker
> vagrant service-manager call experiences timeout after output
> --------------------------------------------------------------
>
> Key: JBIDE-22818
> URL: https://issues.jboss.org/browse/JBIDE-22818
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.1.AM2
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.4.1.Final
>
>
> {noformat}
> !ENTRY org.jboss.tools.openshift.cdk.server 4 0 2016-07-21 09:48:26.869
> !MESSAGE Unable to successfully complete a call to vagrant service-manager.
> !STACK 0
> java.util.concurrent.TimeoutException: Process output:
> ^[[0m # docker env:^[[0m # Set the following environment variables to enable access to the # docker daemon running inside of the vagrant virtual machine: export DOCKER_HOST=tcp://10.1.2.2:2376 export DOCKER_CERT_PATH='C:\Pedro\Software\Openshift_RHCDK_suite10\cdk\components\rhel\rhel-ose\.vagrant\machines\default\virtualbox\docker\' export DOCKER_TLS_VERIFY=1 export DOCKER_API_VERSION=1.21 ^[[0m^[[0m ^[[0m # openshift env:^[[0m ^[[0m# You can access the OpenShift console on: https://10.1.2.2:8443/console # To use OpenShift CLI, run: oc login https://10.1.2.2:8443 export OPENSHIFT_URL=https://10.1.2.2:8443 export OPENSHIFT_WEB_CONSOLE=https://10.1.2.2:8443/console export DOCKER_REGISTRY=hub.openshift.rhel-cdk.10.1.2.2.xip.io^[[0m ^[[0m # run following command to configure your shell: # eval "$(VAGRANT_NO_COLOR=1 vagrant service-manager env | tr -d '\r')"^[[0m
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.VagrantLaunchUtility.call(VagrantLaunchUtility.java:186)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.VagrantLaunchUtility.call(VagrantLaunchUtility.java:153)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.loadServiceManagerEnvironment(ServiceManagerEnvironment.java:108)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.loadServiceManagerEnvironment(ServiceManagerEnvironment.java:85)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.getOrLoadServiceManagerEnvironment(ServiceManagerEnvironment.java:67)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.getOrLoadServiceManagerEnvironment(ServiceManagerEnvironment.java:59)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.checkOpenShiftHealth(VagrantPoller.java:185)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.onePing(VagrantPoller.java:174)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.onePingSafe(VagrantPoller.java:154)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.getCurrentStateSynchronous(VagrantPoller.java:133)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.handleProcessTerminated(CDKLaunchController.java:250)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.access$2(CDKLaunchController.java:242)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController$2.run(CDKLaunchController.java:235)
> !ENTRY org.jboss.tools.openshift.cdk.server 4 0 2016-07-21 09:49:07.139
> !MESSAGE Unable to successfully complete a call to vagrant service-manager.
> !STACK 0
> java.util.concurrent.TimeoutException: Process output:
> ^[[0m # docker env:^[[0m # Set the following environment variables to enable access to the # docker daemon running inside of the vagrant virtual machine: export DOCKER_HOST=tcp://10.1.2.2:2376 export DOCKER_CERT_PATH='C:\Pedro\Software\Openshift_RHCDK_suite10\cdk\components\rhel\rhel-ose\.vagrant\machines\default\virtualbox\docker\' export DOCKER_TLS_VERIFY=1 export DOCKER_API_VERSION=1.21 ^[[0m^[[0m ^[[0m # openshift env:^[[0m ^[[0m# You can access the OpenShift console on: https://10.1.2.2:8443/console # To use OpenShift CLI, run: oc login https://10.1.2.2:8443 export OPENSHIFT_URL=https://10.1.2.2:8443 export OPENSHIFT_WEB_CONSOLE=https://10.1.2.2:8443/console export DOCKER_REGISTRY=hub.openshift.rhel-cdk.10.1.2.2.xip.io^[[0m ^[[0m # run following command to configure your shell: # eval "$(VAGRANT_NO_COLOR=1 vagrant service-manager env | tr -d '\r')"^[[0m
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.VagrantLaunchUtility.call(VagrantLaunchUtility.java:186)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.VagrantLaunchUtility.call(VagrantLaunchUtility.java:153)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.loadServiceManagerEnvironment(ServiceManagerEnvironment.java:108)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.loadServiceManagerEnvironment(ServiceManagerEnvironment.java:85)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.getOrLoadServiceManagerEnvironment(ServiceManagerEnvironment.java:67)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.getOrLoadServiceManagerEnvironment(ServiceManagerEnvironment.java:59)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ConfigureDependentFrameworksListener.configureFrameworks(ConfigureDependentFrameworksListener.java:53)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ConfigureDependentFrameworksListener$1.run(ConfigureDependentFrameworksListener.java:43)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22818) vagrant service-manager call experiences timeout after output
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22818?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22818:
--------------------------------
Fix Version/s: 4.4.1.Final
> vagrant service-manager call experiences timeout after output
> --------------------------------------------------------------
>
> Key: JBIDE-22818
> URL: https://issues.jboss.org/browse/JBIDE-22818
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.1.AM2
> Reporter: Rob Stryker
> Fix For: 4.4.1.Final
>
>
> {noformat}
> !ENTRY org.jboss.tools.openshift.cdk.server 4 0 2016-07-21 09:48:26.869
> !MESSAGE Unable to successfully complete a call to vagrant service-manager.
> !STACK 0
> java.util.concurrent.TimeoutException: Process output:
> ^[[0m # docker env:^[[0m # Set the following environment variables to enable access to the # docker daemon running inside of the vagrant virtual machine: export DOCKER_HOST=tcp://10.1.2.2:2376 export DOCKER_CERT_PATH='C:\Pedro\Software\Openshift_RHCDK_suite10\cdk\components\rhel\rhel-ose\.vagrant\machines\default\virtualbox\docker\' export DOCKER_TLS_VERIFY=1 export DOCKER_API_VERSION=1.21 ^[[0m^[[0m ^[[0m # openshift env:^[[0m ^[[0m# You can access the OpenShift console on: https://10.1.2.2:8443/console # To use OpenShift CLI, run: oc login https://10.1.2.2:8443 export OPENSHIFT_URL=https://10.1.2.2:8443 export OPENSHIFT_WEB_CONSOLE=https://10.1.2.2:8443/console export DOCKER_REGISTRY=hub.openshift.rhel-cdk.10.1.2.2.xip.io^[[0m ^[[0m # run following command to configure your shell: # eval "$(VAGRANT_NO_COLOR=1 vagrant service-manager env | tr -d '\r')"^[[0m
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.VagrantLaunchUtility.call(VagrantLaunchUtility.java:186)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.VagrantLaunchUtility.call(VagrantLaunchUtility.java:153)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.loadServiceManagerEnvironment(ServiceManagerEnvironment.java:108)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.loadServiceManagerEnvironment(ServiceManagerEnvironment.java:85)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.getOrLoadServiceManagerEnvironment(ServiceManagerEnvironment.java:67)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.getOrLoadServiceManagerEnvironment(ServiceManagerEnvironment.java:59)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.checkOpenShiftHealth(VagrantPoller.java:185)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.onePing(VagrantPoller.java:174)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.onePingSafe(VagrantPoller.java:154)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.getCurrentStateSynchronous(VagrantPoller.java:133)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.handleProcessTerminated(CDKLaunchController.java:250)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.access$2(CDKLaunchController.java:242)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController$2.run(CDKLaunchController.java:235)
> !ENTRY org.jboss.tools.openshift.cdk.server 4 0 2016-07-21 09:49:07.139
> !MESSAGE Unable to successfully complete a call to vagrant service-manager.
> !STACK 0
> java.util.concurrent.TimeoutException: Process output:
> ^[[0m # docker env:^[[0m # Set the following environment variables to enable access to the # docker daemon running inside of the vagrant virtual machine: export DOCKER_HOST=tcp://10.1.2.2:2376 export DOCKER_CERT_PATH='C:\Pedro\Software\Openshift_RHCDK_suite10\cdk\components\rhel\rhel-ose\.vagrant\machines\default\virtualbox\docker\' export DOCKER_TLS_VERIFY=1 export DOCKER_API_VERSION=1.21 ^[[0m^[[0m ^[[0m # openshift env:^[[0m ^[[0m# You can access the OpenShift console on: https://10.1.2.2:8443/console # To use OpenShift CLI, run: oc login https://10.1.2.2:8443 export OPENSHIFT_URL=https://10.1.2.2:8443 export OPENSHIFT_WEB_CONSOLE=https://10.1.2.2:8443/console export DOCKER_REGISTRY=hub.openshift.rhel-cdk.10.1.2.2.xip.io^[[0m ^[[0m # run following command to configure your shell: # eval "$(VAGRANT_NO_COLOR=1 vagrant service-manager env | tr -d '\r')"^[[0m
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.VagrantLaunchUtility.call(VagrantLaunchUtility.java:186)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.VagrantLaunchUtility.call(VagrantLaunchUtility.java:153)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.loadServiceManagerEnvironment(ServiceManagerEnvironment.java:108)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.loadServiceManagerEnvironment(ServiceManagerEnvironment.java:85)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.getOrLoadServiceManagerEnvironment(ServiceManagerEnvironment.java:67)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ServiceManagerEnvironment.getOrLoadServiceManagerEnvironment(ServiceManagerEnvironment.java:59)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ConfigureDependentFrameworksListener.configureFrameworks(ConfigureDependentFrameworksListener.java:53)
> at org.jboss.tools.openshift.cdk.server.core.internal.listeners.ConfigureDependentFrameworksListener$1.run(ConfigureDependentFrameworksListener.java:43)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22598) Support runtime detection for manual CDK install
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22598?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22598:
--------------------------------
Fix Version/s: 4.4.x
> Support runtime detection for manual CDK install
> ------------------------------------------------
>
> Key: JBIDE-22598
> URL: https://issues.jboss.org/browse/JBIDE-22598
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdk, runtime-detection
> Affects Versions: 4.4.0.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.x
>
>
> Right now with CDK 2.1 when you have a manual cdk install (i.e. using cdk.zip and then adding the vagrant box yourself), there will be no .cdk marker, so Runtime Detection will not work.
> The only case where Runtime Detection will work is when you use the (as of now Windows-only) suite installer. At that point Runtime Detection will do its thing silently without you noticing.
> The way I see it there are two options:
> a) Create and upstream issue with CDK and ask them to include a basic .cdk in their zip
> b) Make the runtime detection work without .cdk
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22878) EAR deployed from DevStudio to EAP contains errorneously named ejbs
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22878?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-22878:
-------------------------------------
I am not able to replicate this.
When I import the attached project, if I right-click the ear project, go to properties, and go to "Deployment Assembly", we can see that the ejb has a name set for it. When I publish, that is the name I see in the resultant output ear: simple-ejb.jar. I will admit that sometimes the UI still references simple-ejb-1.5.0.jar but that is because those portions of the UI don't have the context to know whether the ear is in a standalone mode or part of an EAR, and I doubt this can be fixed.
Are you sure your environment has m2e-wtp installed?
Also, JBIDE-18697 is unrelated to this and was found to have been caused by an openjdk bug regarding file locking in the application server itself.
[~mmalina] Can you replicate this bug?
> EAR deployed from DevStudio to EAP contains errorneously named ejbs
> -------------------------------------------------------------------
>
> Key: JBIDE-22878
> URL: https://issues.jboss.org/browse/JBIDE-22878
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.Final, 4.4.0.Final
> Environment: I've observed this problem on a Win7 64 bit machine with Oracle JRE 1.8.0_102 64 bit. It was present in both JBoss Developer Studio 8.1.0.GA and 10.0.0.GA when used in conjunction with embedded Maven installation and JBoss EAP 6.4 target runtime.
> Reporter: Mikhail Kalkov
> Assignee: Rob Stryker
> Fix For: 4.4.1.Final
>
> Attachments: screendump.png, test-projects.zip
>
>
> I've created a maven-based EAR project that contains serveral ejb modules some of which come from workspace whereas others are downloaded from binary artifact repository. All modules have bundleFileName specified as module-name.jar in order to override the default module-name-version.jar.
> When I right-click on an EAR project and choose Export..., a correct EAR file is built, which looks exactly the same as when I build it from command line. However, when I add this project to an EAP 6.4 server, and check "Deploy projects as compressed archives" option, an EAR with erroneously named ejbs is deployed. the bundleFileName option is namely ignored for EJBs that come from binary artifact repository. See attached screenshot.
> This problem makes it extremely difficult to debug issues that arise only with zipped ear deployments. The only workaround is to comment out bundleFileName lines in test-ear pom.xml and remember to revert this change before committing!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22878) EAR deployed from DevStudio to EAP contains errorneously named ejbs
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22878?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22878:
--------------------------------
Fix Version/s: 4.4.1.Final
> EAR deployed from DevStudio to EAP contains errorneously named ejbs
> -------------------------------------------------------------------
>
> Key: JBIDE-22878
> URL: https://issues.jboss.org/browse/JBIDE-22878
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.Final, 4.4.0.Final
> Environment: I've observed this problem on a Win7 64 bit machine with Oracle JRE 1.8.0_102 64 bit. It was present in both JBoss Developer Studio 8.1.0.GA and 10.0.0.GA when used in conjunction with embedded Maven installation and JBoss EAP 6.4 target runtime.
> Reporter: Mikhail Kalkov
> Assignee: Rob Stryker
> Fix For: 4.4.1.Final
>
> Attachments: screendump.png, test-projects.zip
>
>
> I've created a maven-based EAR project that contains serveral ejb modules some of which come from workspace whereas others are downloaded from binary artifact repository. All modules have bundleFileName specified as module-name.jar in order to override the default module-name-version.jar.
> When I right-click on an EAR project and choose Export..., a correct EAR file is built, which looks exactly the same as when I build it from command line. However, when I add this project to an EAP 6.4 server, and check "Deploy projects as compressed archives" option, an EAR with erroneously named ejbs is deployed. the bundleFileName option is namely ignored for EJBs that come from binary artifact repository. See attached screenshot.
> This problem makes it extremely difficult to debug issues that arise only with zipped ear deployments. The only workaround is to comment out bundleFileName lines in test-ear pom.xml and remember to revert this change before committing!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22878) EAR deployed from DevStudio to EAP contains errorneously named ejbs
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22878?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22878:
--------------------------------
Comment: was deleted
(was: [~mkalkov] - There is a way to fix this. Please follow these steps instead:
* Download JBoss Developer Studio 10.0.0.GA
* Add JBoss EAP 6.4 runtime to the studio.
* Unzip attached test-project.zip into workspace
* In Studio, use import existing projects wizard to import test-ejb and test-ear projects into workspace
* Double-click the server in Servers view, select "Deployment" tab and check "Deploy projects as compressed archives"
* **Click in the table on the "Deployment Location" column for the module you wish to change the deployment name of, and make the change. This option is only available when the server is stopped and there are no modules added to the server adapter**
* Add test-ear to the server, right-click on the server and select "Clean".
* Now navigate to the deployments directory and inspect test-ear.ear contents. Compare this file to to test-ear.ear obtained from command-line maven build or via Export EAR Eclipse wizard.)
> EAR deployed from DevStudio to EAP contains errorneously named ejbs
> -------------------------------------------------------------------
>
> Key: JBIDE-22878
> URL: https://issues.jboss.org/browse/JBIDE-22878
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.Final, 4.4.0.Final
> Environment: I've observed this problem on a Win7 64 bit machine with Oracle JRE 1.8.0_102 64 bit. It was present in both JBoss Developer Studio 8.1.0.GA and 10.0.0.GA when used in conjunction with embedded Maven installation and JBoss EAP 6.4 target runtime.
> Reporter: Mikhail Kalkov
> Assignee: Rob Stryker
> Attachments: screendump.png, test-projects.zip
>
>
> I've created a maven-based EAR project that contains serveral ejb modules some of which come from workspace whereas others are downloaded from binary artifact repository. All modules have bundleFileName specified as module-name.jar in order to override the default module-name-version.jar.
> When I right-click on an EAR project and choose Export..., a correct EAR file is built, which looks exactly the same as when I build it from command line. However, when I add this project to an EAP 6.4 server, and check "Deploy projects as compressed archives" option, an EAR with erroneously named ejbs is deployed. the bundleFileName option is namely ignored for EJBs that come from binary artifact repository. See attached screenshot.
> This problem makes it extremely difficult to debug issues that arise only with zipped ear deployments. The only workaround is to comment out bundleFileName lines in test-ear pom.xml and remember to revert this change before committing!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22878) EAR deployed from DevStudio to EAP contains errorneously named ejbs
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22878?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-22878:
-------------------------------------
[~mkalkov] - There is a way to fix this. Please follow these steps instead:
* Download JBoss Developer Studio 10.0.0.GA
* Add JBoss EAP 6.4 runtime to the studio.
* Unzip attached test-project.zip into workspace
* In Studio, use import existing projects wizard to import test-ejb and test-ear projects into workspace
* Double-click the server in Servers view, select "Deployment" tab and check "Deploy projects as compressed archives"
* **Click in the table on the "Deployment Location" column for the module you wish to change the deployment name of, and make the change. This option is only available when the server is stopped and there are no modules added to the server adapter**
* Add test-ear to the server, right-click on the server and select "Clean".
* Now navigate to the deployments directory and inspect test-ear.ear contents. Compare this file to to test-ear.ear obtained from command-line maven build or via Export EAR Eclipse wizard.
> EAR deployed from DevStudio to EAP contains errorneously named ejbs
> -------------------------------------------------------------------
>
> Key: JBIDE-22878
> URL: https://issues.jboss.org/browse/JBIDE-22878
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.Final, 4.4.0.Final
> Environment: I've observed this problem on a Win7 64 bit machine with Oracle JRE 1.8.0_102 64 bit. It was present in both JBoss Developer Studio 8.1.0.GA and 10.0.0.GA when used in conjunction with embedded Maven installation and JBoss EAP 6.4 target runtime.
> Reporter: Mikhail Kalkov
> Assignee: Rob Stryker
> Attachments: screendump.png, test-projects.zip
>
>
> I've created a maven-based EAR project that contains serveral ejb modules some of which come from workspace whereas others are downloaded from binary artifact repository. All modules have bundleFileName specified as module-name.jar in order to override the default module-name-version.jar.
> When I right-click on an EAR project and choose Export..., a correct EAR file is built, which looks exactly the same as when I build it from command line. However, when I add this project to an EAP 6.4 server, and check "Deploy projects as compressed archives" option, an EAR with erroneously named ejbs is deployed. the bundleFileName option is namely ignored for EJBs that come from binary artifact repository. See attached screenshot.
> This problem makes it extremely difficult to debug issues that arise only with zipped ear deployments. The only workaround is to comment out bundleFileName lines in test-ear pom.xml and remember to revert this change before committing!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22728) Script the process for jbosstools projects to move up to the latest parent pom in their root pom & all-tests pom; verify that changes are valid & push to origin
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22728?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-22728:
------------------------------------
PR merged after a week of radio-silence from reviewers. :(
> Script the process for jbosstools projects to move up to the latest parent pom in their root pom & all-tests pom; verify that changes are valid & push to origin
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-22728
> URL: https://issues.jboss.org/browse/JBIDE-22728
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.4.1.AM1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.1.Final
>
> Attachments: console.log.txt, getProjectRootPomParents.tsk.txt
>
>
> Current process for moving all the JBT projects to the latest parent pom involves generating 15+ JIRAs assigned to the various project leads, so they can all adopt the latest parent pom, verify their build works, and push the change.
> With the advent of PR build jobs, we can now streamline this a little:
> instead of creating Task JIRAs, create PRs & let them run automatically.
> if they pass, push them in automatically (via script that Alexey or Denis would run)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months