Hi Jason: Jason Fager wrote: > I'm sorry, I'm kind of new around here, but the basic strategy that I know
Welcome! :) > to follow is to cut a branch, change the dependency in the pom of the branch > to the released version of the upstream dependency that you're milestoning > against, and then release from the branch. Exactly right. > If you can't do this because the transports actually do depend on > kernel-SNAPSHOT, and won't work with a previous version, then what are you > releasing them *for* - i.e., where do you expect to use them, if the > underlying code they depend on doesn't exist as a release anywhere? Good question, and I think the crux of the issue. > I kind of agree with Dennis - if the intent is for these things to exist > independent from the larger axis2 codebase, then one of two things needs to > happen. Either the interfaces in question need to be rolled into the > transports package, or (and probably even better) they need to be split off > into their own artifact (axis2-api?) that both transports and the mainline > axis2 code can depend on. The was never to release the transports without dependency on Axis2 - they are *Axis2* transports, and while they're pluggable components, they're not designed for usage outside of Axis2 (Synapse notwithstanding - Synapse is built around Axis2, not without it). They live in WS-Commons > I would be emphatically against the idea of a "Maven-only" release. That's > a stopgap measure, and it creates confusion for people coming into the > project (and being in the middle of this process myself, it's pretty > confusing as is). If this is a problem, the time should be taken to solve > it correctly, else it's just going to get worse in the future. Well, it's not quite that easy. The problem is that we want to release Axis2 (the distribution assemblies) /with/ at least the HTTP and local transports included. This puts us in a situation where we can't release either unless the other has been released first... but only if we tightly couple the Maven releases of the Axis2 jars to the release of the Axis2 distribution files. I'd like to understand the confusion that releasing Maven artifacts first (before the distribution packages) would cause, because as I think about it more, I think it might be a pretty reasonable solution. Release the Axis2 1.5 jars to the Maven repositories (those jars depend upon the transports 1.0-SNAPSHOT version, but only for tests), then release the transport 1.0 jars bound to those, then build and release the Axis2 1.5 distribution assemblies (containing the 1.0 transports). I do not, clearly, agree with the point of view that the transports should become truly decoupled from Axis2. I'm not sure what that would even mean, when you think about what the transports actually do - which is take wire-level stuff and turn it into MessageContexts to push into AxisEngine, and vice versa. Thanks, --Glen > - Jason > > > >> Hi folks: >> >> So I'm trying to get the transports 1.0 releases moving along, and have run >> into a bit of a snag. The transports depend on axis2-kernel SNAPSHOT, for >> interfaces like MessageContext, Flow, etc. - the problem is how do we do the >> release when we want to release the transports before the actual Axis2 >> release? We need to resolve all the SNAPSHOT dependencies for the Maven >> release plugin to be happy, and for this case, we seem to have a circular >> dependency chain. :( >> >> A couple of options off the top of my head: >> >> * Release transports against Axis2 1.4.1's kernel - this may not even be >> possible as there may have been incompatible changes. >> >> * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution but >> just a release into Maven. Then use that for the Transports 1.0 releases, >> and then release the Axis2 1.5 distribution after that. >> >> Moving forward, anyone have thoughts on how to best deal with this? One of >> these options, or something else? >> >> Thanks, >> --Glen >
