Jeromy Evans wrote:
Hi Brian,
I shared your frustration when I moved a plugin from 2.1.0 to 2.1.1.
Initially I was taken-aback by the significance of the changes to the
PackageConfig and ActionConfig that broke uses of MockConfiguration. I
didn't expect such a large change between minor revisions and was
disappointed there was no attempt to stay backwards compatible.
HOWEVER, within a few minutes I'd seen the Builders and found the
comments that backwards compatibility was broken to ensure
immutability of the objects. It didn't take me long to get over it.
I had the same experience and moved forward with the convention plugin.
However, it doesn't mean that red flags didn't go up. Upgrading code is
something that can always be done. However, at some point things should
solidify so that Struts can be upgraded without upgrading everything
else and recompiling everything. This isn't about my experience, it is
about how this impacts everyone else out there. Transitive dependencies
are very tricky and we need to be cognizant of the fact that some folks
might not depend on Struts or the plugins directly.
For me the problem is was one of communication:
- I didn't know the change was coming because I generally don't follow
XWork (I blame myself for not seeking release notes);
- I didn't expect such a significant change between 2.1.0 -> 2.1.1,
but as there hasn't been a GA release in the 2.1.x branch it's
acceptable and known that each revision may be largely incompatible
with the last. It's unreasonable to withhold such a change until 2.2
as feedback is necessary, so within the existing configuration
management framework it seems the correct practice was followed. Sure
I'd prefer a numbering system matched my own, but the current one does
work. Sure I'd have preferred some transitional arrangements, but the
hard-change was technically justified.
In my case the issue was a not a matter of communication. It was a
matter of broken dependencies, runtime errors and managing two separate
codebases for SmartURLs and other projects depending on the version of
struts. I work with roughly 20-30 codebases all using different versions
of nearly everything and managing that can be a severe nightmare when
you consider these types of API changes.
In the case of renaming interceptors and results, I think that
migration was managed very well. It was introduced early,
transitional arrangements put in place and it has been
well-communicated.
True, however it still required that applications wanting to upgrade
required changes. It is still an API change. Again, just to re-iterate
the fact that I'm okay with API breakage, as long as it is managed and
allows tools to figure things out.
In the case of removing support for EL in struts tags, I think that
migration was managed badly from 2.0.9->2.0.11 and many users were
adversely affected.
Yeah, that was painful for a lot of clients and applications I manage
and I still am considering a taglib fork that uses EL and deals well
with Object.
With respect to Tools, the continuous build system is the *best* tool
for checking if a contract through a public API has been broken iff
there are test cases and/or a reference versions (eg. showcase) for
each API. I do think its a reasonable assumption that a plugin built
against, say, 2.0.6, will "by definition" execute with 2.0.11.
However I would not expect that before a GA release of the branch, and
I would never warrant that myself that if I released a plugin. I
guess that's your fundamental expectation.
Agreed. That would be the way to manage some of the complexity. It would
also be the way to roll integration builds that users can consume.
I do think there is a problem of communication in that:
- there is no "reference" plugin that exercises what we're loosely
calling the public APIs
- the release notes are oriented towards users. There's no release
notes for plugin developers
- The plugin developers guide doesn't articulate what is in fact a
public API
I agree that there are some communication problems, but they aren't
really all that major for me. Most of my frustration comes from not
having a convention that I can tell new developers, clients, etc. how
Struts is compatible across versions.
With respect to dependency management, there was a specific problem in
that bundled plugins generally referenced a specific struts 2 core
version (eg. 2.0.6) rather than the parent ${pom.version}so they could
build if the latest core API had changed. I believe that's been
rectified, or perhaps it only applied in the non-bundled plugins I've
examined.
That's very maven specific and often only useful for those folks
intimately using Maven and Struts. All the clients I work with use
Apache Ant and Savant for builds and a few use Ivy. Therefore,
transitive dependencies are managed through those systems, so we usually
do them by hand up front. However, there are a number of transitive
dependency cases that I've outlined in earlier emails where it would not
matter if the pom is correct.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
