[Design of JBoss Build System] - AS Components Bound to AS Release Cycle
by ALRubinger
Many AS Components are currently bound to the AS Release Cycle. ie:
<dependency>
| <groupId>org.jboss.jbossas</groupId>
| <artifactId>jboss-as-aspects</artifactId>
| <version>${project.version}</version>
| </dependency>
...where ${project.version} is currently 5.0.0-SNAPSHOT.
This introduces the following:
1) Whereas AS Components are bound to AS Release Cycle
2) ...And whereas AS inherits AS Component dependencies from "dependency-matrix"
3) ...And whereas Consumers of AS Components inherit dependencies from "dependency-matrix"
4) Therefore AS Consumers are bound to a valid release of AS
Use Case:
1) We release AS 5.0.0.GA
2) 2 weeks later, AS dependency-matrix is now in 5.0.1-SNAPSHOT
3) We want to release EJB3 RC13, which requires changes introduced to jboss-as-aspects after AS 5.0.0.GA shipped
4) We'd have to release a new version of jboss-as-aspects (5.0.1) and jboss-as-dependency-matrix (5.0.1), but no changes to AS. This would put the current versioning (binding AS Components to SA Version) out of sync.
So we need for all components of AS to have independent release cycles.
Which also begs the question: if that's possible, shoudn't each component also have its own SVN structure (trunk, branches, tags)?
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138141#4138141
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138141
18 years
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int
by kabir.khan＠jboss.com
"alex.loubyansky(a)jboss.com" wrote : I guess, it should be
| <xsd:group ref="..."/>
| instead of
| <xsd:group name="..."/>
|
| That's what makes the difference between the group definition and a reference to it.
The only group defined is valueGroup. In the aop beans schema I do:
| <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
| ...
| <xsd:group name="valueGroup"/>
| ...
| </xsd:redefine>
|
in the jboss-beans-common schema, the group is defined
| <xsd:group name="valueGroup">
| <xsd:annotation>
| <xsd:documentation>
| ...
| </xsd:documentation>
| </xsd:annotation>
| <xsd:choice>
| <!--<xsd:element name="bean" type="beanType"/>-->
| <!--<xsd:element name="lazy" type="lazyType"/>-->
| <xsd:element name="value" type="plainValueType"/>
| <xsd:element name="inject" type="injectionType"/>
| <xsd:element name="value-factory" type="valueFactoryType"/>
| <xsd:element name="collection" type="collectionType"/>
| <xsd:element name="list" type="listType"/>
| <xsd:element name="set" type="setType"/>
| <xsd:element name="array" type="arrayType"/>
| <xsd:element name="map" type="mapType"/>
| <xsd:element name="null">
| <xsd:complexType/>
| </xsd:element>
| <xsd:element name="this">
| <xsd:complexType/>
| </xsd:element>
| <xsd:any namespace="##other" processContents="strict">
| <xsd:annotation>
| <xsd:documentation>An extension value</xsd:documentation>
| </xsd:annotation>
| </xsd:any>
| </xsd:choice>
| </xsd:group>
|
Then everywhere it is used it uses 'ref', e.g.
| <xsd:complexType name="valueType" mixed="true">
| <xsd:annotation>
| <xsd:documentation>
| <![CDATA[
| A value that can take other values, i.e. properties and parameters.
|
| e.g.
| <parameter><value class="com.acme.MyClass">xxx</value></parameter>
| ]]>
| </xsd:documentation>
| </xsd:annotation>
| <xsd:complexContent>
| <xsd:extension base="plainValueType">
| <xsd:sequence>
| <xsd:choice minOccurs="0">
| <xsd:group ref="valueGroup"/>
| </xsd:choice>
| </xsd:sequence>
| </xsd:extension>
| </xsd:complexContent>
| </xsd:complexType>
|
There isn't any group called "global"?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138138#4138138
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138138
18 years
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int
by kabir.khan＠jboss.com
I've got the JAXB parsing to almost the same level as for the old AOPBeanSchemaInitializer method, and will now work on adding the rest of the features. Locally I build and install snapshots of common-core and jbossxb, and use those.
I did notice however when using the AOPBeanSchemaInitializer again by accident that the https://svn.jboss.org/repos/jbossas/projects/microcontainer/branches/jaxb... does not parse properly. If I turn on schema validation get exceptions like:
| org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/C:/cygwin/home/Kabir/sourcecontrol/microcontainer-jaxb-aop-mc-int/aop-mc-int/target/tests-classes/org/jboss/test/microcontainer/beans/test/CFlowAopTestCase.xml@3,38
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:177)
| at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:139)
| at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:147)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:294)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:438)
| at org.jboss.test.aop.junit.AOPMicrocontainerTestDelegate.deploy(AOPMicrocontainerTestDelegate.java:76)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.setUp(MicrocontainerTestDelegate.java:83)
| at org.jboss.test.aop.junit.AOPMicrocontainerTestDelegate.setUp(AOPMicrocontainerTestDelegate.java:60)
| at org.jboss.test.AbstractTestSetup.setUp(AbstractTestSetup.java:63)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.extensions.TestSetup.run(TestSetup.java:23)
| at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
| at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
| Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to parse schema for nsURI=urn:jboss:aop-beans:1.0, baseURI=null, schemaLocation=aop
| at org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver.resolve(DefaultSchemaResolver.java:338)
| at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:302)
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:407)
| at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:496)
| at org.apache.xerces.xinclude.XIncludeHandler.startElement(XIncludeHandler.java:938)
| at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:283)
| at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(XMLNSDocumentScannerImpl.java:733)
| at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1754)
| at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
| at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:845)
| at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:768)
| at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
| at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1127)
| at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:567)
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:173)
| ... 17 more
| Caused by: org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 124:37 s4s-elt-must-match.2: The content of 'group (global)' must match (annotation?, (all | choice | sequence)). Not enough elements were found.
| at org.jboss.xb.binding.sunday.unmarshalling.XsdBinderTerminatingErrorHandler.handleError(XsdBinderTerminatingErrorHandler.java:40)
| at org.apache.xerces.impl.xs.XMLSchemaLoader.reportDOMFatalError(XMLSchemaLoader.java:1124)
| at org.apache.xerces.impl.xs.XSLoaderImpl.load(XSLoaderImpl.java:175)
| at org.jboss.xb.binding.Util.loadSchema(Util.java:395)
| at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:175)
| at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:146)
| at org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver.resolve(DefaultSchemaResolver.java:330)
| ... 31 more
|
Does anybody know what this means :-)
And is there an easier way to turn on validation of the schema than hacking it to use the AOPSchemaBindingResolver in SingletonSchemaResolverFactory? I've tried calling org.jboss.xb.binding.Unmarshaller.setValidation() and org.jboss.xb.binding.Unmarshaller.setSchemaValidation() but they don't seem to have any effect.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138126#4138126
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138126
18 years