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/confetc, 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.
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.
-- Allen Dave wrote:
Hmmm... I wish I'd thought of this earlier. These changes have introduced a dependency on code that is in the sandbox. You have to build planet first, before you build Roller. It's probably a bad thing for Roller itself to depend on code that is in the sandbox, a place which is supposed to be for experimental and half-baked things that don't get released. Perhaps now is the time to move the planet code up into Roller itself. src/weblogger src/planet Or something along those lines. - DaveOK, sounds good for now. - Dave On 12/11/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > > Dave wrote: > > On 12/11/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > >> There wouldn't really be any directory structure changes that are> >> different from what we already have actually. We may want to move some> >> things around a bit to organize things better after we get all the > >> planet code together, but I don't think we need to do that yet. > >>> >> The basics of the plan are to move the remaining pieces of the planet> >> business code from the Weblogger src to the sandbox/planetroller src> >> directory. So that would include the planet pojos and PlanetManager as > >> well as the planet unit tests. This would put all the code needed to > >> run the planet aggregator in the actual sandbox/planetroller src and we > >> would continue building the planet code into a roller-planet.jar which> >> just gets included in the set of jars that are part of the current > >> Weblogger app. > >>> >> So nothing really changes except that the planet code gets moved into > >> its own codebase and the build process gets updated a bit so that the> >> planet code is built on its own and added to the weblogger app. > > > > The planet code contains Struts actions, how do those get integrated > > into the Roller Struts config file? Or are you only planning to move > > the POJOs and backend manager code? > > The struts actions that are part of the Weblogger src will not really > change. They will still be part of the struts config and function as > usual, the only difference will be that instead of getting the > PlanetManager from Roller.getPlanetManager() they will use > Planet.getPlanetManager(). I've tested this out and it works well. > > I should have been more clear with my last email, but all of the planet> related code which is specific to the Weblogger app will remain in place> and only be updated a bit based on classes changing packages, etc. So > that would include the PlanetModel, PlanetEntriesPager, > PlanetFeedServlet, PlanetCache, RefreshEntriesTask, SyncWebsitesTask, > and the planet admin struts actions. > > -- Allen > > > > > > - Dave >
