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.

- Dave



OK, 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
>

Reply via email to