[Design of JBoss Web Services] - Re: JBossWS Test Approach
by alessio.soldano＠jboss.com
"richard.opalka(a)jboss.com" wrote : Because we're supporting multiple AS versions we can't
| construct proper client classpath using maven dependencies..
Given that I see the issue that drove to this forum thread, I don't get why you think we can't construct proper client classpath using m2 dependencies because we're using multiple AS versions.
anonymous wrote :
| Example:
|
| JBossWS 3.0.5
| AS 5.0.0
|
| Which jaxb-impl version will be used in testing if we don't exclude it?
|
| (dependency:tree output from testsuite module in jboss500 configuration)
| [INFO] org.jboss.ws.native:jbossws-native-testsuite:pom:3.0.5.GA
| [INFO] +- org.jboss.ws.native:jbossws-native-client:jar:3.0.5.GA:compile
| [INFO] | +- org.jboss.ws.native:jbossws-native-core:jar:3.0.5.GA:compile
| [INFO] | | +- com.sun.xml.bind:jaxb-impl:jar:2.1.6:compile
| ...
| [INFO] +- org.jboss.ws:jbossws-jboss500:jar:3.0.5.GA:compile
| [INFO] | +- org.jboss:jbossxb:jar:2.0.0.GA:compile
| [INFO] | | +- sun-jaxb:jaxb-api:jar:2.1.4:compile
| ...
|
The artifact that's closest to the root will be used (with the distance being defined by the number of nested dependencies you need to go through to reach the artifact).
anonymous wrote :
| We can't exclude jaxb-impl neither from jbossws-native-client (note doesn't matter the different group.id)
| neither jaxb-impl from jbossws-jboss500 because it's compile dependency (it won't compile without it).
| We could exclude jaxb-impl either from jbossws-native-client or from jbossws-jboss500 in testsuite.pom xml.
Exclusions are required only when the closest version of a given artifact is not the one you want to use, but this should not happen if the dependency hierarchy is well done (which did not apply in our webservice module since some days ago).
This is besides the original problem, just to be clear on maven.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216141#4216141
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216141
17 years, 1 month
[Design of JBoss Web Services] - Re: JBossWS Test Approach
by richard.opalka＠jboss.com
"alessio.soldano(a)jboss.com" wrote : Basing the tests on maven dependencies was the most natural solution when the mavenization took place,
Well I have different point of view on it:( It don't think it was the most natural solution to mavenize our test suite.
"alessio.soldano(a)jboss.com" wrote : what would you suggest instead of that? I don't like that much the idea of specifying the surefire additionalClasspath with a list of jar from the curent AS... any other idea?
I'm thinking exactly about that ;) But I have to googlize this problem much more. I don't believe we're the first one facing this problem.
"alessio.soldano(a)jboss.com" wrote :
| After all, we also get advantages from using maven dependencies to build test classpath, otherwise we need keep track of jar changes (names, position), addition of jars (while we simply get the new dependency for free when somebody updates the dependency in an artifact we include), etc.
Wrong point of view. I'd maintain all this staff like we did it before JBossWS mavenization and like we do it now (see our binary distribution) and be sure we're using proper jars directly from AS than using current approach which is broken.
Current approach doesn't save anything. It just makes me sleep really very bad :(
I have a nightmare regularly at nights where I'm debugging for hours/days something and finally solving the problem with conclusion we're using wrong client classpath and hotfixing it with one maven dependencies exclusion in our testsuite pom.xml
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216135#4216135
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216135
17 years, 1 month
[Design of JBoss Web Services] - Re: JBossWS Test Approach
by richard.opalka＠jboss.com
JBossWS supports AS 5.0.0, 5.0.1, Branch_5_x and trunk (version numbers will change in the future).
Each AS has it's dependencies specifed using maven.
Each of these dependencies specified in AS components matrix
has its own dependencies on another subprojects.
To be absolutely clear the main problem I'm talking here is:
Because we're supporting multiple AS versions we can't
construct proper client classpath using maven dependencies..
Example:
JBossWS 3.0.5
AS 5.0.0
Q1) Which jaxb-impl version will be used in testing if we don't exclude it?
(dependency:tree output from testsuite module in jboss500 configuration)
[INFO] org.jboss.ws.native:jbossws-native-testsuite:pom:3.0.5.GA
[INFO] +- org.jboss.ws.native:jbossws-native-client:jar:3.0.5.GA:compile
[INFO] | +- org.jboss.ws.native:jbossws-native-core:jar:3.0.5.GA:compile
[INFO] | | +- com.sun.xml.bind:jaxb-impl:jar:2.1.6:compile
...
[INFO] +- org.jboss.ws:jbossws-jboss500:jar:3.0.5.GA:compile
[INFO] | +- org.jboss:jbossxb:jar:2.0.0.GA:compile
[INFO] | | +- sun-jaxb:jaxb-api:jar:2.1.4:compile
...
We can't exclude jaxb-impl neither from jbossws-native-client (note doesn't matter the different group.id)
neither jaxb-impl from jbossws-jboss500 because it's compile dependency (it won't compile without it).
We could exclude jaxb-impl either from jbossws-native-client or from jbossws-jboss500 in testsuite.pom xml.
But doing so for each conflicting component (there are many such) would be a real maintainability nightmare (especially for moving AS versions even they would be fully mavenized as mentioned in above post)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216131#4216131
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216131
17 years, 1 month
[Design of JBoss Web Services] - Re: JBossWS Test Approach
by richard.opalka＠jboss.com
"alessio.soldano(a)jboss.com" wrote :
| ... we're evaluating this still a bit early ...
| I don't think so. We were talking about this problem a year ago for the first time. I'm afraid we'll be talking about it next years :(
"alessio.soldano(a)jboss.com" wrote :
| ... AS is not completely mavenized yet ...
| and won't be next few years ;) Note that AS mavenization process runs already more than 1 year and it's still at its beginnings.
"alessio.soldano(a)jboss.com" wrote :
| ...Once the process will be completed I think we will be pretty sure we're testing against the right artifacts.
| Almost true, but not absolute ;)
"alessio.soldano(a)jboss.com" wrote :
| This said, the specific failures that made us to stop and think about our testing approach were caused by some mistakes we actually did in the webservice module pom.xml in the AS. IOW it didn't have the right dependencies which were instead specified in the container integration pom.xml files. Of course this caused the trunk and 5_x branch only to fail, but I fixed that. The whole "exclusion game" in the stacks' testsuite pom.xml is not required anymore, there're few dependencies still specified there and they're quite straightforward.
| Thanks for the hotfix Alessio, but it didn't solve the problem I'm discussing here. It just hotfixed the result of the problem. I'd like to fix the reason of all these problems instead. I'll explain this argument in next post following this one.
"alessio.soldano(a)jboss.com" wrote :
| Finally, considering we're using maven for the project, I think it's important to run tests using surefire. IOW my point of view is that either we use this tool (maven) completely or we don't use it (which currently is not an option given the direction taken 1 year ago by the whole AS development).
| Basing the tests on maven dependencies was the most natural solution when the mavenization took place, what would you suggest instead of that? I don't like that much the idea of specifying the surefire additionalClasspath with a list of jar from the curent AS... any other idea?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216117#4216117
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216117
17 years, 1 month
[Design of JBoss Build System] - Ivy or Maven
by wolfc
Using Maven for some time it has shown some quirks which make continuous integration basically impossible:
1. Snapshot artifacts must be static (http://jira.codehaus.org/browse/MDEPLOY-77) and should be reproducible;
2. All other artifacts (Alpha, Beta, CR, GA) must be static and must be reproducible (http://jira.codehaus.org/browse/MDEPLOY-82);
3. Dependency resolution must fail if no valid component matrix can be formed (http://jira.codehaus.org/browse/MNG-612);
Since there are no viable solutions within the Maven domain I'm looking towards Ivy to see if that can cover these requirements.
Ivy has the notion of 'latest.integration' revision with which it can bring in the latest snapshot of a component. During publishing (deploying) the resolved revisions can be written back to an ivy descriptor and put into the repository.
Secondly you can also dynamically ask for the 'latest.release' dependencies and thus produce a nightly build based on latest.integration and a milestone build based on latest.release artifacts.
To be compatible with Maven Ivy has taken over the same flawed concept of a SNAPSHOT revision (aside from the real Ivy revisions). Meaning that Ivy will handle a dependency of 1.0.0-SNAPSHOT in the same flawed way Maven does. To get it back to static dependencies (latest.integration) we need a custom dependency resolver (https://issues.apache.org/jira/browse/IVY-1036).
Releasing components in conjunction with svn is still a very much non-standardized operation. This needs more work.
At the end of a resolve phase a conflict manager will determine whether a stable matrix can be formed or not.
All of this can be viewed in Ivy reports and graphs.
One important missing feature is actually deploying a snapshot artifact. Ivy doesn't do this at all. So to make this I've resorted to using maven-ant-tasks. Which actually makes an interesting combination. Using the custom Ivy resolver I can create a static 'snapshot' descriptor, translate this to a pom.xml and use that to deploy into the snapshot repository.
The resulting component is here: http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/ivy/.
So would I use this to start a new component?
Actually, no. Maven has shown that it's actually nice to have almost no prose to create a new component. With Ivy I have to resort back to ehr.. build magic. :-)
But there are two paths that lead beyond this point:
1. create a build.xml which allows for bootstrapping build magic using Ivy
2. use Ivy as a dependency resolver within Maven
So a new requirement forms:
- to create a new project it must not be required to copy any logic (except the inevitable bootstrap)
(hmm, we could actually mandate $HOME/.ivy/bootstrap.xml (before anybody howls, Maven needs $HOME/.m2/settings.xml))
One thing that I'll keep beyond scope (even though it would be cool) is a dynamic component matrix:
Suppose A 1.0.0 depends on B 1.0+. Within the repo this is reflected as:
A 1.0.0 -> B 1.0.0
Now we release B 1.0.1 and rebuild A:
A 1.0.0-2 -> B 1.0.1.
In effect the dynamic dependency reflects what can form a compatibility matrix, but since we want a stable dependency chain B 1.0.0 will become an invalid artifact for the matrix.
So to really know which components can form a stable matrix you must know all versions that have been tested against component A.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216114#4216114
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216114
17 years, 1 month