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/trunkWhatever 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 theprojects. It would be nice to see 'weblogger' get rearranged a bit at thesame. -NathanOn 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 significantnumber 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 withmultiple 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 independentlyof 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!
smime.p7s
Description: S/MIME cryptographic signature
