On 12/11/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Ahhh, good point. I suppose that's my fault though because I wasn't
really thinking that the code in the sandbox was experimental, I just
figured that's where you happened to put it. I don't think that any of
the new code which was in the planetroller sandbox will affect anything
though, since none of it will actually be referenced by the Weblogger code.
In any case, I definitely agree that we should figure out the proper
permanent home for the code and we should make some decisions to ensure
that the relationship between Roller Weblogger and Roller Planet is how
we want it. I was going to suggest that we use the blueprints model for
j2ee apps for organizing the code ...
http://java.sun.com/blueprints/code/projectconventions.html#99632
So you would have ...
apps/planet/src/java
apps/planet/src/conf
apps/planet/test/src/java
apps/planet/test/src/conf
apps/weblogger/src/java
apps/weblogger/src/conf
apps/weblogger/test/src/java
apps/weblogger/test/src/conf
etc, etc. things like jars are shared in a root "lib" directory so you
aren't maintaining jars inside the various apps, they are all shared in
one location. i am open to alternatives, but i do like the idea of
sticking with a standardized layout rather than trying to do our own thing.
Yes. I like that idea too.
I looked at the very same blueprints page and was going to suggest the
same thing, but with one change. I 'd prefer to keep the Planet web UI
in the sandbox because it depends on JSF, we don't actually ship it
yet, I still consider it to be experimental.
How about using the blueprint's concepts of apps and components:
/apps/roller
/apps/planet
/components/roller-core
/components/planet-core
But we don't need to set all that up right now.
For now, Roller can just be an app. At some point we might want to
break the core of Roller, i.e. the POJOs and managers, into a
component.
/apps/roller/src/java
/apps/roller/src/conf
/apps/roller/test/java
/apps/roller/test/conf
And for now, Planet can just be a component with no UI. So the POJOs
and managers:
/components/planet-core/src/java
/components/planet-core/src/conf
/components/planet-core/tests/java
/components/planet-core/tests/conf
So app "roller" depends on component "planet-core"
And the Planet web UI stays in the sandbox and also depends on planet-core.
another interesting question i had about the planet code was whether or
not we want to setup the build process for Weblogger to dynamically
build the Planet code and include it or if the Weblogger code should
just use a static build of the Planet code. Basically, if we use a
static build we would treat the Planet code like any other dependency we
have and build the jar file and then put it in the "lib" directory for
use, only updating it when appropriate. The dynamic process would mean
that in order to build Weblogger you have to trigger a Planet build and
then reference the planet jar that was just built for use in the
Weblogger build.
i like the static build option because that would allow us to decouple
the Weblogger and Planet development so they can't conflict with each other.
I'd much prefer dynamic. Planet is going to continue to be included in
Roller and not installed as a versioned module, so I don't want to
have to worry about which version of the planet jar is in SVN.
- Dave
