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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
