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 Thu, 19 Jul 2007 23:07:00 GMT

On Jul 19, 2007, at 2:58 PM, Peter Petersson wrote:

> David Jencks wrote:
>> 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/ 
>> org.apache.geronimo.plugins/roller-derby-database// 
>> car=org.apache.geronimo.plugins/roller-mysql-database/2.0-SNAPSHOT/ 
>> car
>> 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 can now confirm that the artifact_alias switch worked :) although  
> with a couple of glitches.
> I started with installing the roller derby db on tomcat and the  
> database tables was created nicely. Installed tomcat-roller and  
> started it up as expected, added a roller user account  (to make  
> some changes in the roller derby db). Added and saved the artifact  
> alias line (manually) and installed the mysql-roller-database (or  
> maybe I did it the other way around) getting some errors as the  
> table, via the DatabaseInitializationGBean and script, creation  
> didn't work, created them manually.
> Now /roller was off-line (not a total surprise) and it wouldn't  
> start as it complained about missing dependency on the roller-derby- 
> database. Restarting the Geronimo server resolved the problem  
> roller could be started and my newly created account (in the derby  
> db) was, as expected, gone. Created a new account and confirming  
> the mysql database update with "select * from rolleruser". I may  
> get some time this weekend to try to make this a bit smother.

It would be great to have something in the geronimo-plugin.xml file  
that would modify artifact_aliases.xml.  However it might be a fairly  
large project....

I think what you'd want to do is modify the  
ExplicitDefaultArtifactResolver so the plugin installer can tell it  
to change stuff.  It should either have a query for an existing entry  
or return any existing entry so the plugin installer can stop that  
artifact, which will stop all the artifacts depending on it.  I guess  
ideally the plugin system would then try to start all the artifacts  
that just got stopped...

david jencks

> thanks
>   Peter Petersson
>> 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.
>> thanks
>> 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