avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <u...@denic.de>
Subject Re: [phoenix] Relooking at distributions
Date Wed, 26 Sep 2001 07:49:30 GMT
Peter Donald wrote:
> Hmmm then there is something wrong here. I just went and updated 9 projects
> that use phoenix and I managed to bring them up to speed in about 35 minutes.

Perhaps because you wrote the stuff and I'm just a user without docs? :)

> Even then all the changes of late in Phoenix have been backwards compatible
> and only issue warnings when you dont comply.

Well, recently I had to convert all my blocks to interfaces. Then the
ThreadManager section left server.xml, went to config.xml and became its
own block. I had to figure out which of the cornerstone blocks use it.
Then I had to add <block> sections instead of <meta> sections etc.

It really doesn't help much to deprecate and keep backwards
compatibility, because that only delays the point where things break. So
I better fix it now, because in several months I won't know anymore what
I have to do.

> The changes that I am suggesting are almost required as the basis of further
> progress. For instance a requested features is that .sar files are not
> extracted onto filesystem if at all possible to stop people accidently
> messing up the deployments. This is not really possible to do now because we
> don't know which parts are safe to be kept in archive and which need to be
> extracted. It is also required if/when I get around to adding in some funky
> deployment management stuff.

Well, this sounds nice, but I'd prefer if the current mechanism would
work first. The .sar archives are not reliably expanded, sometimes old
files from previous .sar archives are not overwritten. Perhaps have
Avalon automatically delete the deployment directory on startup? That's
what I currently have to do.

> Anyways what I would suggest is that you complain loudly about specific
> changes if you don't like them ;) That way we can add more backwards
> compatability/transitioning support or maybe revert the change.

My suggestion is to change things when it becomes necessary, not before.
So, once you start to actually do some funky stuff with .sar archives,
that would be a good time to change the .sar structure, if required.
It's easier to sell to the users, because they immediately see what they
get for it :)


Ulrich Mayring
DENIC eG, Systementwicklung

To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message