Dave wrote:
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.
sounds good.
How about using the blueprint's concepts of apps and components:
/apps/roller
/apps/planet
/components/roller-core
/components/planet-core
That works for me, although I hadn't really thought that we would need a
planet-core component. My thinking was that the roller-core component
would be things that apply to both Planet and Weblogger and that there
would just be 2 apps which are Planet and Weblogger. So ...
/apps/weblogger
/apps/planet
/components/core
I consider all of the pieces to be "Roller" so I think it's easier to
refer to them as Weblogger and Planet (or Aggregator?). So the
Weblogger app would include the planet code, both business and ui.
But we don't need to set all that up right now.
I agree, but we need some kind of plan for the short term. How about we
create the /apps/planet setup now and just put the planet code which
Roller Weblogger depends on there, basically the business layer classes.
And for right now it will only build a jar file which can be include
in the app build for both projects.
So basically we would just do ...
/apps/planet/src/java
/apps/planet/test/java
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
That's fine with me. I think we can move the Roller Weblogger code a
little later after we've already got the Planet code setup and we are
sure that we are comfortable with the layout.
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"
This is the only part I am unsure about because the current planet code
that is used by the Weblogger code is not really planet-core, it's more
the planet business layer and I'm not sure it's a component so much as
it is the part of the Planet codebase which is used by the Weblogger app.
And the Planet web UI stays in the sandbox and also depends on planet-core.
sounds good.
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.
That's true, but we can put a version number in the jar filename and it
wouldn't be that confusing. The main problem with doing dynamic is that
the build process gets longer and more complex, and to a greater degree
you can no longer work on the Planet code without having to worry about
breaking things in Weblogger. By doing static the 2 apps can actually
progress at their own pace, which seems like a good thing to me.
We can start the process as dynamic and see how it goes.
-- Allen
- Dave
