geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Apache Roller v4.0 plugin
Date Wed, 18 Jul 2007 16:57:42 GMT

On Jul 18, 2007, at 9:13 AM, Peter Petersson wrote:

> Nice repacking David your experience shines right throw it  ;)  I  
> have some suggestions that may future enhance the plugin.
> As it is now the roller exposed plugin modules consist of a  
> database choice and a container choice but as the roller-jetty and  
> roller-tomcat modules is dependent on specific database  
> configurations, in the current setup the derby database, and as  
> this dependency seems to be hard to "work around"(?) it would maybe  
> be a good idea to rearrange the modules as follows
> * roller-jetty-derby  (prev roller-jetty)
> * roller-jetty-mysql  (new)
> * roller-tomcat-derby (prev roller-tomcat)
> * roller-tomcat-mysql (new)
> ... and so on, and just expose them as the instalable roller plugin  
> alternatives leaving the database modules (roller-xxxx-database) to  
> be automaticaly pull in (prev. selectable).
> Would this be preferable or do you (David) or anyone else have  
> other ideas on how to best package the roller plugin to be easy  
> maintainable and expendable to other roller supported databases ?  
> Im quite new to maven, plugins and G for that mater so there may be  
> more elegant solutions to this, anyway i find myself needing a  
> roller-tomcat-mysql module to be able to test that combo out  
> without messing with the current roller-tomcat (derby specific)  
> module.

I think instead of the above we can add a line to var/config/


Then roller will start using the mysql database configuration.

I haven't actually installed mysql and tried this, but based on a lot  
of use of artifact_aliases in the tck it should work fine.  Could you  
try it?

I think we need to add the capability of adding/removing stuff from  
artifact_aliases to the plugin system so that if you install the  
roller-mysql plugin it adds this line all by itself.

david jencks

> Once again sry for the triple post above gmail was so slow i lost  
> confidence in it.
> Risking a double post again it has been 4h sins i posted this to  
> the list from my goggle account and it has not shown up yet.
> regards
>  Peter Petersson
> Peter Petersson wrote:
>> david jencks wrote:
>>> We should move this discussion to the dev list I think, you can  
>>> quote or copy anything I've written to the dev list.
>> Just did ;)
>>> It looks like we collided on this work :-)   I haven't had  
>>> consistent internet access for the last few days (my dsl just got  
>>> connected an hour ago) so I haven't done a good job of keeping  
>>> you up to date with my progress.
>> np
>>> I just committed some changes to geronimo/roller that, together  
>>> with ROL-1482, get roller working for me on geronimo-jetty.  I  
>>> haven't looked at your patch.
>> Great ! I will check out your changes as and if I find anything to  
>> add from my resent patch I will let you know.
>>> - I got the security realm gbean to work.  I doubt it is needed  
>>> since IIUC roller is using acegi and I don't think it is hooked  
>>> up to javaee security.
>>> - I got the database initialization gbean  to work by tweaking  
>>> the openjpa schema synchronization properties.  I'm not sure that  
>>> having openjpa create all the tables will end up with enough  
>>> indexes, and without more info in the orm.xml files the columns  
>>> will be dramatically different sizes..  For instance, the primary  
>>> key id columns appear to be 48 characters to accomodate a UUID,  
>>> but openjpa want to make the 255 characters.  On the other hand  
>>> it looks like roller can be set to create the tables itself or  
>>> even upgrade from previous schemas, so maybe we should try to  
>>> enable that feature instead of running our own script.  If we can  
>>> enable this feature I think we can drop the roller-*-resources  
>>> modules.
>> Yes I noticed roller was attempting to upgrade the db on some of  
>> my installation tests but at the moment it appears to be a bit  
>> jumpy. I agree it would be preferable to let roller handle the  
>> upgrade and installation. I resolved the mail configuration  
>> problem but I suspect you have that in you commit.
>>> - I will look at the tomcat/jasper problem you show below but I  
>>> suspect that it's caused by not including the jasper builder in  
>>> the car-maven-plugin configuration.  I think I fixed this in both  
>>> versions but I haven't actually tried running the tomcat version  
>>> yet.
>>> - I added a "top level build" that seems to work ok but only  
>>> after I've built each  module separately once.  I don't  
>>> understand why this is happening.
>> As did I (its in the patch) when I got tired of building the  
>> modules separately. I got the exact same problem it seems maven  
>> picks the modules in alphabetic order I thought maven would be  
>> able to find out the right (dependency) order (someone probably  
>> know the trick).
>>> It was very exciting to get roller to finally run on my machine  
>>> after months of struggle!
>> I know the feeling from G v1.1 and v1.2 :). Now we can focus on  
>> getting things stable and finaly into a public plugin repository  
>> soon after the G v2.0 release.
>>> I think we should ask roller to publish some usable artifacts to  
>>> the maven repo using the ant maven tasks.  Then we won't have to  
>>> do this silly unpacking the zip routine.
>> I agree go ahead and drop something in there dev list http:// 
>> thanks
>>   Peter Petersson

View raw message