Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1028474

Summary: Pull jboss-as-infinispan_1_4.xsd changes from WildFly into EAP
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Darran Lofthouse <darran.lofthouse>
Component: ClusteringAssignee: Paul Ferraro <paul.ferraro>
Status: CLOSED CURRENTRELEASE QA Contact: Jitka Kozana <jkudrnac>
Severity: unspecified Docs Contact: Russell Dickenson <rdickens>
Priority: unspecified    
Version: 6.2.0CC: brian.stansberry, jkudrnac, myarboro, rhusar
Target Milestone: CR1   
Target Release: EAP 6.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-15 16:20:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Darran Lofthouse 2013-11-08 14:26:36 UTC 
Description of problem:

The schema has been cleaned up within WildFly, the same changes should be pulled into EAP so that there is only one version 1.4.

(Not a blocker for a release but we do need to be able to verify schema compatibility, the current differences make this difficult)
Comment 2 Brian Stansberry 2013-11-08 15:54:09 UTC 
This absolutely should be a blocker; we cannot have two different versions of this schema in .Final releases.

It's no big deal to fix this; the PR is there already.
Comment 3 Paul Ferraro 2013-11-08 16:01:37 UTC 
Just to say, the versions are equivalent and any changes are cosmetic only.  So, I wouldn't call this a blocker - although it is inconvenient.

https://github.com/jbossas/jboss-eap/pull/684

I'll add a link to this BZ to the PR.
Comment 4 Brian Stansberry 2013-11-08 16:09:09 UTC 
Blocker, not blocker, whatever. It has to be fixed because it's absolutely stupid not to. :)
Comment 6 Jitka Kozana 2013-11-11 11:45:02 UTC 
This issue was verified using the 6.2.0.CR1 preview bits.