Integration metro

[thomas.diesler]

This is related to

http://jira.jboss.org/jira/browse/JBWS-1994

The metro-build-adapter.xml sais

 <!-- Metro 3rd party thats not available through repo.jboss.com -->

 <fileset dir="${lib.runtime.dir}">
 <include name="jaxws-local-transport.jar"/>
 <include name="stax-utils.jar"/>
 <include name="txnannprocessor.jar"/>
 <include name="wstx-asl-3.2.1.jar"/>
 <include name="xmldsig.jar"/>
 <include name="xws-security.jar"/>
 <!-- a custom jarjar resolver package -->
 <include name="resolver.jar"/>
 </fileset>

Why do we have two sources to get thirdparty dependencies from? Should they not all be pulled from the glassfish metro build?

It seems that the current build happily mixes metro dependencies from some previously released version and the current build.

[ropalka]

I'm not sure if I understand you correctly.
You don't like that we're mixing jars from METRO/trunk/thirdparty
with METRO/glassfish-metro/output jars (something like generated thirdparty for GF), right?

[thomas.diesler]

Yes, all of these jars are part of the metro build

 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/FastInfoset.jar" dest="${thirdparty.dir}/FastInfoset.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/http.jar" dest="${thirdparty.dir}/http.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jaxws-api.jar" dest="${thirdparty.dir}/jaxws-api.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jaxws-src.zip" dest="${thirdparty.dir}/jaxws-src.zip" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jaxws-rt.jar" dest="${thirdparty.dir}/jaxws-rt.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jaxws-tools.jar" dest="${thirdparty.dir}/jaxws-tools.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jsr173_api.jar" dest="${thirdparty.dir}/jsr173_api.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jsr181-api.jar" dest="${thirdparty.dir}/jsr181-api.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jsr250-api.jar" dest="${thirdparty.dir}/jsr250-api.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/mimepull.jar" dest="${thirdparty.dir}/mimepull.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/saaj-api.jar" dest="${thirdparty.dir}/saaj-api.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/saaj-impl.jar" dest="${thirdparty.dir}/saaj-impl.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/sjsxp.jar" dest="${thirdparty.dir}/sjsxp.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/stax-ex.jar" dest="${thirdparty.dir}/stax-ex.jar" usetimestamp="true" verbose="true"/>
 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/streambuffer.jar" dest="${thirdparty.dir}/streambuffer.jar" usetimestamp="true" verbose="true"/>

Are they not?

[heiko.braun]

Metro 3rd party thats not available through repo.jboss.com

Basically, we make sure that anything that is shared with the AS is provided through the repository. That requires identifying metro's thirdparty dependencies and and putting them into the repo. Anything else (Metro specific, mostly build artifacts) are pulled from the metro build.

[heiko.braun]

The examples you posted are all JAX-WS artifacts for instance.

[ropalka]

Folks,

just let me know the conclusion of this debate and I'll fix it as you will propose ;)

[thomas.diesler]

If the metro build depends on a certain version of jax-ws, that is published in the repository. How do we verify that

sun-jaxws=2.1.3

is correct?

If these jars

 <!-- Metro 3rd party thats not available through repo.jboss.com -->

 <fileset dir="${lib.runtime.dir}">
 <include name="jaxws-local-transport.jar"/>
 <include name="stax-utils.jar"/>
 <include name="txnannprocessor.jar"/>
 <include name="wstx-asl-3.2.1.jar"/>
 <include name="xmldsig.jar"/>
 <include name="xws-security.jar"/>
 <!-- a custom jarjar resolver package -->
 <include name="resolver.jar"/>
 </fileset>

are all part of jax-ws (like this one)

[tdiesler@tddell glassfish-metro]$ find . -name wstx-asl-*.jar
./wsit/wsit/lib/runtime/wstx-asl-3.2.1.jar

they should all come from the repository.

My issue is that wsit's dependency on jax-ws should be properly defined and verified.

[thomas.diesler]

The jax-ws repository is broken in another way

http://repository.jboss.com/sun-jaxws/2.1.3/lib/

Instead of

 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/FastInfoset.jar" dest="${thirdparty.dir}/FastInfoset.jar" usetimestamp="true" verbose="true"/>

the metro build needs to use

 <get src="${jboss.repository}/sun-fi/${sun-fi}/lib/FastInfoset.jar" dest="${thirdparty.dir}/FastInfoset.jar" usetimestamp="true" verbose="true"/>

Otherwise we have no idea what FastInfoset version we are talking about. Although FastInfoset is not critical (because probably not shared) we also seem to pull in

 <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/streambuffer.jar" dest="${thirdparty.dir}/streambuffer.jar" usetimestamp="true" verbose="true"/>

which is shared

[thomas.diesler]

Instead

http://repository.jboss.com/sun-jaxws/2.1.3/component-info.xml

needs to define a dependency on FastInfoset and not contain the artifact itself.

[thomas.diesler]

In a nutshell, we seem to ship thirdparty dependencies for wsit namely

 <include name="jaxws-local-transport.jar"/>
 <include name="stax-utils.jar"/>
 <include name="txnannprocessor.jar"/>
 <include name="wstx-asl-3.2.1.jar"/>
 <include name="xmldsig.jar"/>
 <include name="xws-security.jar"/>
 <!-- a custom jarjar resolver package -->
 <include name="resolver.jar"/>

that circumvent our dependency management.

I've noticed because of the broken stax integration
http://jira.jboss.org/jira/browse/JBWS-2057
which seems to be the reason why metro hudson tests are failing

[thomas.diesler]

Being curious about why the metro integration requires

sun-jaxws=2.1.3

I did a scan in wsit

[tdiesler@tddell glassfish-metro]$ ls wsit/wsit/lib/runtime
activation.jar jaxb-api.jar jaxrpc-spi.jar jsr173_1.0_src.zip README-BIN.txt sjsxp-src.zip txnannprocessor.jar
activation-src.zip jaxb-api-src.zip jaxws-api-doc.zip jsr173_api.jar resolver.jar special-README.txt txnannprocessor-src.zip
CVS jaxb-impl.jar jaxws-api.jar jsr181-api.jar resolver-src.zip stax-ex.jar wstx-asl-3.2.1.jar
FastInfoset.jar jaxb-impl.src.zip jaxws-api-src.zip jsr181-api.src.zip saaj-api.jar stax-ex-src.zip wstx-src-3.2.1.zip
FastInfoset.src.zip jaxr-api.jar jaxws-local-transport.jar jsr250-api.jar saaj-api-src.zip stax-utils.jar xmldsig.jar
http.jar jaxr-impl.jar jaxws-local-transport-src.zip mail-1.4.jar saaj-impl.jar stax-utils-src.zip xmlsec.jar
jaxb1-impl.jar jaxrpc-api.jar jaxws-rt.jar mimepull.jar saaj-impl.src.zip streambuffer.jar xws-security.jar
jaxb-api-doc.zip jaxrpc-impl.jar jaxws-rt.src.zip mimepull-src.zip sjsxp.jar streambuffer.src.zip xws-security.src.zip

It seems natural that wsit comes with all its dependencies, which would make a seperate download of these artifacts redundant (if not incorrect)

Why do we have this dependency on sun-jaxws and if it is needed how does it relate to the wsit build and our deployment?

[heiko.braun]

I was going through all the libs that come with the cvs checkout and replacing the shared ones with repository downloads. This includes looking at the manifest and identifying the corresponding version.