Re: [phoenix] Relooking at distributions

[Uli Mayring <ul...@denic.de>]

On Wed, 26 Sep 2001, Peter Donald wrote:

> If we were to accept all these changes then the deployment layout would be 
> something like
> 
> SAR-INF/lib/myBlockArchive.jar    (note the .jar rather than .bar ending)
> SAR-INF/lib/mySupport.jar
> SAR-INF/conf/server.xml or SAR-INF/server.xml
> SAR-INF/conf/config.xml or SAR-INF/config.xml
> SAR-INF/conf/assembly.xml or SAR-INF/assembly.xml
> data/my-random-datafile.txt

Is that part of the "exciting and important things" you were planning on
doing to Phoenix? :)

I see nothing wrong in allowing Block Archives as .bar, .jar or, for all I
care, as .foo or whatever people decide on. But why prefer one name over
the other? Either specify exactly what the name should be or leave it to
the users, anything in-between creates unnecessary complexity.

Like in ant now I am told that the jarfile attribute is deprecated and I
should use file instead. Hell, why not just keep jarfile around and make
an internal pointer to file? From a user's perspective "file" instead of 
"jarfile" is not really a cool new feature :)

I estimate we spend about 20 hours every week to change our applications
and build-scripts, so that they work with the newest Avalon. Of course
alpha means "can change", but it does not mean "must change, even for
micro-benefits" :)

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung


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

Re: [phoenix] Relooking at distributions

[Peter Donald <do...@apache.org>]

On Wed, 26 Sep 2001 17:49, Ulrich Mayring wrote:
> 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? :)

probably. I will try to be more clear about things that will need changing in 
future then ;)

> > 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. 

Not sure what you mean.

> 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.

Well my hope was that displaying warning messages explaining what was wrong 
would make it easier to migrate to new interfaces. Some of the messages were 
less specific but I have just made them more a bit more useful today and so 
you should get exact messages telling you what to change. 

Anyways this is probably just an active period. I have had two weeks off and 
needed to keep active ;) So the slew of changes is definetly not a regular 
occurence.

> > 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.

The problem is that the current mechanism is expected behaviour. If the 
directory has already been extracted then it won't be written over. This was 
to follow trends with other similar systems (specifically Tomcat3.x and many 
other servlet containers). 

It wouldn't be possible to delete this directory because many applications 
use this directory to store extra information generated at runtime. For 
instance it could be used to store a mail spool, log files, or virtually 
anything else that the server generates/uses.

> > 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 :)

Well I would suggest that you stay with recently released phoenix for a while 
and perhaps wait till beta before grabbing next download. 

I don't have the time/resources to develope in large steps. It has to be 
incremental changes when I or other peeps have time. If we were to require 
these large steps nothing would ever get done ;)

-- 
Cheers,

Pete

--------------------------------------------------
 Where ignorance is bliss, 'tis folly to be wise.
--------------------------------------------------


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

Re: [phoenix] Relooking at distributions

[Ulrich Mayring <ul...@denic.de>]

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

-- 
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

Re: [phoenix] Relooking at distributions

[Peter Donald <do...@apache.org>]

On Wed, 26 Sep 2001 05:41, Uli Mayring wrote:
> On Wed, 26 Sep 2001, Peter Donald wrote:
> > If we were to accept all these changes then the deployment layout would
> > be something like
> >
> > SAR-INF/lib/myBlockArchive.jar    (note the .jar rather than .bar ending)
> > SAR-INF/lib/mySupport.jar
> > SAR-INF/conf/server.xml or SAR-INF/server.xml
> > SAR-INF/conf/config.xml or SAR-INF/config.xml
> > SAR-INF/conf/assembly.xml or SAR-INF/assembly.xml
> > data/my-random-datafile.txt
>
> Is that part of the "exciting and important things" you were planning on
> doing to Phoenix? :)

part of it.

> I see nothing wrong in allowing Block Archives as .bar, .jar or, for all I
> care, as .foo or whatever people decide on. But why prefer one name over
> the other? Either specify exactly what the name should be or leave it to
> the users, anything in-between creates unnecessary complexity.

I am not sure what you are saying. Quite a few people would prefer it if we 
just used one convention to locate code which is exactly what I am proposing. 
ie All code is stored in SAR-INF/lib/*.jar rathern than in multiple places 
and multiple extensions (ie lib/*.jar and blocks/*.bar). 

The aim of simplifying this to use one convention is to reduce uneeded 
complexity ;)

> Like in ant now I am told that the jarfile attribute is deprecated and I
> should use file instead. Hell, why not just keep jarfile around and make
> an internal pointer to file? From a user's perspective "file" instead of
> "jarfile" is not really a cool new feature :)

jarfile does redirect to file. However theres a similar argument there. WOuld 
you prefer to use ant if there were 100 ant tasks that all used different 
attribute names for the same thing and each time you had to use task you 
neede to go to documentation to figure out what the name of the attribute is 
(ie src, source, nested filestet, file, dir, ....). Compare this to using 
consistent naming conventions throughout ant tasks - much easier to read and 
write files without having to go to documentation. Much better no?

Feature driven development is not something that leads to high quality 
software. MS is a prime example of a shop that uses feature driven 
development. It is true that a lot of their software eventually gets decent 
or even good but they have thousands of man hours they can throw at a problem 
... after it has been released and sold ;)

> I estimate we spend about 20 hours every week to change our applications
> and build-scripts, so that they work with the newest Avalon. Of course
> alpha means "can change", but it does not mean "must change, even for
> micro-benefits" :)

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. 
Even then all the changes of late in Phoenix have been backwards compatible 
and only issue warnings when you dont comply. The one binary incompatability 
(that I know of) is the removal of old ThreadContext and some changes to 
ThreadPool interface from Excalibur project. This was unfortunate but 
necessary for progress and you probably should not have been relying on these 
classes considering they were Alpha and I had said several times for quite a 
few months that I would change them ;)

Was there other changes that broke your builds or something? (If you tell us 
we can revert or make it easier to migrate you across).

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.

Anyways what I would suggest is that you stay with the version you are 
currently using (or maybe the recently released version) until Phoenix goes 
beta. Between now and phoenix-beta I hope to make all changes backward 
compatible and will just issue warnings if you don't comply ;) When we change 
from alpha to beta there will be backwards incompatible changes but if you 
wait till then to update phoenix it may be easier to manage - not sure.

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.

-- 
Cheers,

Pete

----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------

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