Bug 1005281 - EAP cartridge maps to specific EAP release
EAP cartridge maps to specific EAP release
Product: OpenShift Online
Classification: Red Hat
Component: Containers (Show other bugs)
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Brenton Leanhardt
libra bugs
Depends On: 1004868
  Show dependency treegraph
Reported: 2013-09-06 11:07 EDT by Brenton Leanhardt
Modified: 2015-05-14 19:28 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1004868
Last Closed: 2013-09-19 12:49:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Brenton Leanhardt 2013-09-06 11:07:26 EDT
+++ This bug was initially created as a clone of Bug #1004868 +++

The template files included in the EAP cartridge (specifically pom.xml) refer to a specific version of EAP.  This is problematic because the EAP rpm package tracks the latest EAP release although the cartridge itself is not synced to that release.  For OSE 1.2, the pom.xml file specifies:


The org.jboss.spec dependency is then used by maven during builds to transitively get all the needed EAP artifact dependencies.  Because the version element is 3.0.0.Final-redhat-1, the cartridge is essentially specifying all dependencies for the EAP 6.0.0 release.  For EAP 6.1.1 (most recent), the version should be 3.0.2.Final-redhat-4.

This problem manifests itself in disconnected environments when a shared EAP maven repository only contains artifacts for the current EAP release, resulting in missing dependencies during maven builds.  Including artifacts from the EAP 6.0.0 release in the shared maven repository resolves this issue, but software is then being built against artifacts several releases older than what's currently installed.

The default repository reference used by the cartridge for both artifacts and maven plugins is http://maven.repository.redhat.com/techpreview/all.  This repository includes specs for all released versions of EAP, but the maven builds within OSE are only going to use the EAP 6.0.0 dependencies.  For disconnected environments, the downloaded maven repository zips from our customer support portal must be used and they are not cumulative to past versions.

Ideally, changes to EAP releases should also include changes to the corresponding OSE cartridge to ensure they remain in sync.

--- Additional comment from RHEL Product and Program Management on 2013-09-05 12:09:59 EDT ---

Since this issue was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
Comment 1 openshift-github-bot 2013-09-06 13:58:50 EDT
Commit pushed to master at https://github.com/openshift/origin-server

Bug 1005281 - EAP cartridge maps to specific EAP release
Comment 2 Brenton Leanhardt 2013-09-06 13:59:46 EDT
I'm following up to see if the same change is needed for the EWS cartridge.
Comment 3 Brenton Leanhardt 2013-09-06 15:49:46 EDT
Word on the street says that stance isn't even needed for the EWS cartridge.  I removed that dep from the EWS template and I tested both the EWS 1.0 and 2.0 default builds.  Both built without issue.

dmace, Do you have any problems with me removing the EAP maven dependency from the EWS pom template as part of this bug?  I'll ask QE to regression test the quickstarts they have that use these cartridges.
Comment 4 Dan Mace 2013-09-06 15:58:43 EDT

There's no need for the dependency in the jbossews pom.xml- The template git repository doesn't even contain any Java code to compile, so the dependencies in the file are for demonstration purposes only.
Comment 5 Brenton Leanhardt 2013-09-06 16:00:10 EDT
ok.  I'm going to remove it then simply to avoid confusion.  Thanks for the info.
Comment 6 Brenton Leanhardt 2013-09-06 16:08:57 EDT
Thinking about this more.  I think we should just comment out the stanza from the EAP pom template.  I see no way for us to keep it in sync with EAP versions actually installed on the Node and we don't want build to fail for users the first time they try to create the cartridge.

The best way to avoid confusion in this case would be a comment suggesting that the user would want.  Sound OK?
Comment 7 openshift-github-bot 2013-09-06 17:54:43 EDT
Commit pushed to master at https://github.com/openshift/origin-server

Bug 1005281 - Removing unneeded EAP dependency from EWS pom template
Comment 8 Rich Lucente 2013-09-08 17:47:43 EDT
We should provide guidance for the customer or have the plugin track the version of EAP installed.  Figuring out the correct value for the <version> element is not exactly straightforward.  Guidance would need to include something like:

"The <version> element below should match the installed version of EAP on the node hosting your application.  To determine the version of EAP running on the node, log into an example EAP application and look in the jbosseap/logs/server.log file for the line:

... JBAS015874: JBoss EAP 6.1.1.GA (AS 7.2.1.Final-redhat-10) started ...

To determine the correct value for <version>, download the maven repository zip file corresponding to the installed version of EAP from the customer service portal [1].  Unzip the file and examine the single directory under jboss-eap-*-maven-repository/org/jboss/spec/jboss-javaee-6.0

[1] https://access.redhat.com/jbossnetwork/restricted/listSoftware.html?downloadType=distributions&product=appplatform&productChanged=yes"
Comment 9 openshift-github-bot 2013-09-10 08:37:15 EDT
Commit pushed to master at https://github.com/openshift/origin-server

Bug 1005281 - EAP cartridge maps to specific EAP release
Comment 10 Meng Bo 2013-09-11 07:04:33 EDT
Checked on devenv_3772, 

Create jbosseap app, and the content in comment#8 has been added to the pom.xml.
The version of javaee is "3.0.2.Final-redhat-4"

And for jbossews app, the jboss dependency has been removed from pom.xml.

Move bug to verified.

Note You need to log in before you can comment on or make changes to this bug.