It isn't very hard to migrate, which is one of the reasons why I didn't start from a blank sheet of editor buffer. It took me an hour for all of CXF's rather complex uses.
Such an app would be somewhat screwed. It would need to play with classloaders to isolate the consumers of the two versions. HOWEVER, In the nicest way possible, I wish to point out that a release vote is a very late moment to start posing these questions. I further want to point out that the maintainers of the code consist of me and some small contributions from others. I don't have the bandwidth to design and implement some sort of complex migration strategy. Based on list traffic, I can estimate that there are perishing few things in the world that incorporate XmlSchema. Do you think that very many people try to cram CXF and Axis onto one webapp? I don't. AFAICT, it's quite common to make incompatible changes at major version boundaries, and, yes, this leads to some pain for some people who do a lot of mixing and matching. On Mon, Feb 14, 2011 at 3:24 PM, Tom Jordahl <[email protected]> wrote: > A few questions for thought: > > - Is the API transition from 1.x to 2.0 fairly easy? > - If a single web application depends on two pieces of "third party" > software, one using 1.x and one using 2.0, will that web application be > totally screwed? > - Is there a simple way to make migration and coexistence easier? Would > changing the package name be that way? > > Having faced many of these type of issues from the user side (since I work on > stuff that basically integrates as or into Java web applications), anything > we can do to make coexistence easier is a big +1. On the flip side, changing > package names is pretty ugly. > > Tom Jordahl > > > -----Original Message----- > From: Benson Margulies [mailto:[email protected]] > Sent: Monday, February 14, 2011 9:23 AM > To: [email protected] > Subject: Re: [VOTE] Release XmlSchema 2.0 > > No, it isn't compatible. > > I can see your logic as to how someone might end up with incompatible > versions, but I don't, at this point, want to change the package > names. 2.0 has been under development for a year, and I've advertised > it on the user list, incompatibility and all, on several occasions. No > one has raised this issue. > > Anyone who runs into this can always use classloader technology to > achieve isolation. I won't claim that this would be painless. > > As an example of another ASF project, I think that commons-http client > has not changed package names as they have gone through several major > versions of incompatibility, though I could be confused. > > Obviously, it would only take me about a day to change the package > name, so if there are a bunch of people who agree with you, I'll > capitulate. Let's see what other people think. > > > > On Mon, Feb 14, 2011 at 9:14 AM, Jochen Wiedmann > <[email protected]> wrote: >> Is release 2.0 binary compatible with 1.x? If so, a clirr report would >> be good to demonstrate this compatibility. >> >> Otherwise, wouldn't it be better to change the package name? Note, >> that schema is a component that is relatively likely to be used by >> different parts of an application and in different versions. >> >> Jochen >> >> >> >> On Mon, Feb 14, 2011 at 1:28 PM, Benson Margulies <[email protected]> >> wrote: >>> https://repository.apache.org/content/repositories/orgapachews-001/ >>> >>> The above URL is a staging repository for the proposed 2.0 release of >>> XML schema. >>> >>> This release is a significant housecleaning of XmlSchema: updated to >>> use Java 1.5 collections, rationalize the data model, and generally >>> try to make it a simpler and more efficient beast. >>> >>> The CXF trunk has been testing against this version for a couple of >>> months now, so I think it's time for a release. >>> >>> This vote will run for 72 hours. >>> >>> Options as usual as -1, 0, +1. >>> >>> I vote +1. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> >> -- >> I Am What I Am And That's All What I Yam (Popeye) >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
