Rather than adding code to the builders to accept obsolete schema
versions, I would rather provide a standalone tool to update old plans.
I don't want to get into the business of supporting
non-formally-released obsolete formats forever.
Thoughts?
thanks
david jencks
On Jul 3, 2005, at 11:14 PM, David Jencks wrote:
On Jul 3, 2005, at 8:17 PM, Aaron Mulder wrote:
Jeremy,
No need to exaggerate. You can take a friendly tone and still
make your point. No one's saying that altering configuration formats
is a
"good" thing, just that it will steadily get "worse" the more stable
the
server gets. And note that an "unstable" release is exactly that --
we
need a well-documented Milestone 4 release to direct new users to.
In the
mean time, I'm trying to set up a weekly build environment here, so
hopefully I'll put up a fresh "unstable" release from that tomorrow.
Finally, as for the extra mile, I have no idea how to get
XMLBeans to accept an XML file that could contain one of two
namespaces,
but is otherwise identical in content (to handle old Jetty files).
Any
constructive tips?
I think this is fairly easy to do using an xmlcursor. I do a lot of
it in SchemaConversionUtils to convert the namespace of the embedded
naming and security elements to their actual namespaces.
If we add this I think we should print a loud warning that the
behavior will not be supported forever.
I suppose for Tomcat we could implement a schema converter that
would turn the Tomcat-specific elements into container-config
elements,
but this seems like a lot of work. If we get a lot of feedbcak from
confused Tomcat users I'll be happy to look into if further.
I would think that the tomcat integration is new enough so we don't
have to worry about this.
thanks
david jencks
Aaron
P.S. To address Dain's comment, I think he'd agree we need to call a
moratorium on config changes once we reach a certain level of pre-1.0
stability -- perhaps RC builds or whatever.
On Sun, 3 Jul 2005, Jeremy Boynes wrote:
So let me get this right ...
* announce to the world we pass the CTS tests and put out an unstable
release
* just when people are looking at the project, change the deployment
plans in an incompatible way
* don't provide any upgrade tool, just tell users they need
to edit all their existing plans
* tell them this is a *good* thing because we're going to keep
changing things until 1.0 finally comes out
And this is somehow supposed to encourage people to use this
software?
Aaron, I appreciate what you are trying to do. Please go the extra
mile
and make sure existing plans continue to work - it is not hard to do
and
will avoid putting off a lot of potential users.
--
Jeremy
Dain Sundstrom wrote:
+100000000 before we release 1.0 is the exactly when we should be
encouraging this type of drastic change. After 1.0 comes out, I
doubt
we will be able to make these type of changes until 2.0. I think
we
should review all of our configuration files and make
usability/consistency changes before we even consider a 1.0.
-dain
On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote:
On Sun, 3 Jul 2005, Jeremy Boynes wrote:
Won't this cause a problem for users, having to modify all
existing
plans to accomodate this change?
Sure. But we've already agreed on the need for a single web
deployment format, and I don't think it makes sense to support 3
formats
to try to ease transition. This is one of many configuration
changes
that
will be necessary in moving from Milestone 3 to Milestone 4.
Hopefully we
can minimize this kind of thing moving forward into more stable
releases,
but I'm not sure we're entirely there yet.
I'll make sure the Wiki docs are up to date.
Aaron
