Hi,

I agree that it would be good to separate Planet from roller so they can be released independently etc.

One thing to consider is to make both Planet and roller sub-projects explicitly, as in

svn copy <rollersvn>/trunk/apps/planet <rollersvn>/planet/trunk
svn move <rollersvn>/trunk <rollersvn>/core/trunk

Whatever you call roller core, it might be cleaner. No strong opinion, just other projects seem to have this structure...

Craig

On Jun 25, 2008, at 6:42 PM, Nathan Beyer wrote:

Personally, I think that would help to clarify the separation of the
projects. It would be nice to see 'weblogger' get rearranged a bit at the
same.

-Nathan

On Wed, Jun 25, 2008 at 3:32 PM, Allen Gilliland <[EMAIL PROTECTED] >
wrote:

I mentioned this to Dave a while back, but I have made a fairly significant
number of improvements to the Roller Planet code to work it into a
standalone application which we use on planets.sun.com.

I am happy to commit those changes back to the Roller SVN repository but the changes I've made are not really compatible with the way Roller manages the Planet project right now, so it would be a major PITA to revert things. Instead I'd like to propose that the Roller Planet code be moved in the SVN repository so that it effectively stands as its own project. It would still be a part of Roller, just instead of treating Roller like 1 project with
multiple modules it would actually be treated like multiple projects.

The svn command would basically be ...

svn copy <rollersvn>/trunk/apps/planet <rollersvn>/planet/trunk

... this makes "planet" a project within Roller and it would have its own trunk/branches/tags which allow it to be worked on completely independently
of the Roller Weblogger code.

The actual code changes I have to offer are numerous, but include ..

* cleanup and bug fixes to tighten up JPA backend.
* merging of static & runtime configs into a single class.
* config class is no longer static which promotes more DI.
* some class renaming to fix a naming clash problem.
* improvements to bootstrapping process to promote more DI.
* elimination of lots of unused code.
* cleanup of exception throwing/handling.
* lots more unit tests, including unit tests for most struts2 actions.
* simplification and streamlining for UI.

Anyone interested in this?  thoughts?  comments?

-- Allen






Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to