Are you referring to using the same tools and common binary across branches? I don't think we should go this route because tools changes often impact metadata, tools, and common/core. Therefore if we did this we would surely end up maintaining multiple versions of binary dependencies which is just as much if not more work (since you would need branches for each subcomponent).
The only diversion that I think is necessary for 4.2 is a couple of configuration lines for remoting. IMO as long as this is true, I think it would be better just to add code that detects which version of remoting, and then configures appropriately across all versions.
Here are my 2 cents:
- What's the difference between org.jboss.ws.common.metadata and org.jboss.ws.core.metadata?
- I would rename 'extras' to 'extensions'
- As a general approach i would recommend to use *.jaxrpc *.jaxws subpackages.
I.e. there would be *.xop.jaxrpc and *.xop.jaxws
- As a consequence of the above, we should have org.jboss.ws.core.j2ee.jaxrpc and org.jboss.ws.core.j2ee.jaxws
Before we decide on implementation details, lets have a look at the current sittuation with respect to tools/metadata. Please step back a little and look at it from a consultants perspective whose only aim it is to make it better in the future - what happend in the past is not of interrest.
* jbossws-2.0.x is a functional superset of jbossws-1.2.x and jbossws-1.0.x. There is however a conflicting implementation with respect to how JSR181 endpoints are handled.
* currently we have two (in the near future three) code bases
that are divergent to a degree where it becomes virtualy impossible to merge changes from branch to trunk and vice versa. Effectivly, team members spend days merging trivial functionality or don't do it at all (which is worse)
* the tools code base in branch has virtually not been maintained for the largest part of the year it is also in a state where it is still difficult to maintain
* the tools code base in trunk builds on the tools code base from branch, such that maintainability concerns apply likewise
* there is no tools api that can be used from core and thirdparty
Therefore, I'll put some effort in
* unify the metadata model accross branches
* reuse a single tools code base accross branches
* draft a tools api
I see this as necessary prerequisity before I continue with CTS work and the foundation for 1.0.5, 1.2.0
Therefore if we did this we would surely end up maintaining multiple versions of binary dependencies which is just as much if not more work (since you would need branches for each subcomponent).
Only if the changes are not backward compatible, which they should be given that trunk is a superset in functionality.
Looking at it from a different angle, there is no way we would be able to maintain the current largely divereged code base. Therefore it is a MUST that we consolidate.
Lest look at the actual real problem, which is the need for a legacy jsr181 implementation. We could even have this legacy implementation in the trunk codebase if desired, but disabled. This can be achieved by simply having a metadata builder that exists in the branch that does not exist in trunk. If we want 1 codebase, all that is needed is to sync trunk with the jbossws-1.0 branch and whenever a change is made it is committed to trunk first, and then after committed to the 1.0 branch. The code bases would be virtually identical, and by merging in this order we guarantee that 1.0 specific stuff remains.
The contract between what you call core, and what you call tools is NOT static, but rather changes significantly. In fact, it is a work in progress. For an example take a look at WSDLMetaData, this is by no means complete or fully accurate, and if we solidify this to some kind of API, we are only going to make things more difficult by having to guarantee backwards compatibility across any particular branch of core.
I only see this effort as creating more work for us, and I don't see how it helps achieve any of the outstanding project goals.
Also, isn't the purpose of the integration API to support not only multiple containers, but also multiple versions of JBossAS?
I think this is the proper abstraction to use (rather than dividing our stack in the middle), and we can reduce our workload by not introducing new branches for every AS release, and instead just adding a new integration module.
I don't care about where the code lives. If we have virtually identiacal code in trunk and branch(es) thats fine with me. This is the methodology that we use for the jaxrpc testsuite.
Consolidation is my concern. If we do not consolidate the tools,metadata, raxrpc codebase to a degree where I can more or less brainlessly merge stuff, I don't see a chance (for myself) to get future releases off the ground in a timely manner.
The UMDM might be in flux it is still part of the contract. The curernt issue is that we have multiple code bases that work off diffent UMDMs which is unneccessary and MUST be fixed.
Lets, take this discussion off-line - this will be more productive.
The aim is to decide upon a clear migration path towards a maintainable code base, which we currently do not have.
We agreed on the following plan
1) Thomas commits changes to package structure in trunk
2) Jason synchronises meta data and tools code base accross branches
3) for now, there will be no seperate module
4) after CTS completion we get together for a tools/core design session that should produce a migration path towards a better maintainable tools code base