You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/06/08 13:06:24 UTC
[proposal] restructure fortress
Hi gang,
with 1.0 out, I think now is the time to get fortress into an
organisational (ie no code changes) structure more similar to merlin and
phoenix. I'm kinda expecting growth :D
How about....
----
1) breaking fortress out of excalibur.
At a minimum, that means making
http://avalon.apache.org/fortress/
work. Going a little further I would like fortress to break out of
excalibur, making excalibur more about fortress and making fortress more
findable. I like to think of fortress as Avalon-Fortress, not
Avalon-Excalibur-Fortress. It could go into two places:
1a) ~/cvs/avalon/fortress
1b) ~/cvs/avalon-fortress
we talked (I think even voted) about 1a) before. IMHO it's preferable,
but 1b) is workable, too. The latter might make it easier for people to
use cvs branching as partial branching is not needed. 1a) will
additionally require framework to move to ~/cvs/avalon/framework/.
2) splitting fortress up.
At a minimum, that means an 'api/' directory and an 'impl/' directory,
and a fortress-api.jar and a fortress-impl.jar. However, I would like to
restructure a little more rigorously, somewhat like merlin, with
seperate subbuilds:
container/ # this is most of the current codebase
src/api
src/impl
src/test
platform/ # a Kernel 'n stuff
src/api
src/impl
src/test
tools/ # the meta tool and stoof
src/java
src/test
cli/ # the frontend Berin keeps talking
# about :D
src/java
src/test
servlet/
src/java
src/test
examples/
src/java
src/test
docs/
src/xdocs
maven.xml # reactor build ensuring you can still build just as
project.xml # easiliy
(note: not everything mentioned above even exists yet. But my hunch is
that it will sometime soon.)
3) converting the build to maven.
A structure like the above would require rather a lot of work if it were
to be done using ant, whereas using maven it is quite feasible. I would
like to just switch over to maven in one go. This will in addition
require little build.xml files to be written that will enable gump
integration. More importantly, it will require y'all to install, and get
to basic grips with, maven.
----
....you might imagine restructuring like this will take some time. I
would like to get started with setting up the structure like this, then
move over the actual sources later in one go. That should avoid
disrupting the regular work.
thoughts?
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] restructure fortress
Posted by Leo Simons <le...@apache.org>.
initial import in place! Coming week will hopefully see removal of all
bumps.
cheers,
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] restructure fortress
Posted by Berin Loritsch <bl...@d-haven.org>.
I am responding via a webmail client, so I won't be as on top
of things as I was when my DNS was working. Hopefully the name
should repropogate by tomorrow and all will be well...
-------- Original Message --------
Subject: [proposal] restructure fortress
From: Leo Simons <le...@apache.org>
Date: Sun, June 8, 2003 4:06 am
To: dev@avalon.apache.org
Hi gang,
with 1.0 out, I think now is the time to get fortress into an
organisational (ie no code changes) structure more similar to merlin
and phoenix. I'm kinda expecting growth :D
:)
How about....
----
1) breaking fortress out of excalibur.
At a minimum, that means making
http://avalon.apache.org/fortress/
work. Going a little further I would like fortress to break out of
excalibur, making excalibur more about fortress and making fortress
more findable. I like to think of fortress as Avalon-Fortress, not
Avalon-Excalibur-Fortress. It could go into two places:
1a) ~/cvs/avalon/fortress
1b) ~/cvs/avalon-fortress
we talked (I think even voted) about 1a) before. IMHO it's preferable,
but 1b) is workable, too. The latter might make it easier for people
to use cvs branching as partial branching is not needed. 1a) will
additionally require framework to move to ~/cvs/avalon/framework/.
+1 to 1a.
Of course that means that framework gets moved to
~/cvs/avalon/framework as well....
2) splitting fortress up.
At a minimum, that means an 'api/' directory and an 'impl/' directory,
and a fortress-api.jar and a fortress-impl.jar. However, I would like
to restructure a little more rigorously, somewhat like merlin, with
seperate subbuilds:
container/ # this is most of the current codebase
src/api
src/impl
src/test
platform/ # a Kernel 'n stuff
src/api
src/impl
src/test
tools/ # the meta tool and stoof
src/java
src/test
cli/ # the frontend Berin keeps talking
# about :D
src/java
src/test
servlet/
src/java
src/test
examples/
src/java
src/test
docs/
src/xdocs
maven.xml # reactor build ensuring you can still build just as
project.xml # easiliy
(note: not everything mentioned above even exists yet. But my hunch is
that it will sometime soon.)
:) Yep.
3) converting the build to maven.
A structure like the above would require rather a lot of work if it
were to be done using ant, whereas using maven it is quite feasible.
I would like to just switch over to maven in one go. This will in
addition require little build.xml files to be written that will
enable gump integration. More importantly, it will require y'all to
install, and get to basic grips with, maven.
+1
----
....you might imagine restructuring like this will take some time. I
would like to get started with setting up the structure like this,
then move over the actual sources later in one go. That should avoid
disrupting the regular work.
thoughts?
The important thing is that we aren't held up with the restructuring.
If we are all on a common baseline for Merlin, and all is working well,
then we should be OK. I would advise not to create a type of directory
(i.e. cli, servlet, etc.) until there is something to put there.
I also suggest that we use directory names that make sense. For instance
CLI is understandable because we all know it means command line interface,
but SMP in merlin parlance looks as if it has little to do with symmetric
multi-processing. So only use acronyms if it is painfully obvious what
the accronym means.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org