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 Sat, 21 Jul 2007 22:45:04 GMT

On Jul 21, 2007, at 8:11 AM, Peter Petersson wrote:

> Considering the tight schedule and the work that needs to be done i  
> G to add functionality to the plugin system for smooth and  
> automatic artifact alias switching and my latest findings  
> surrounding this regarding the roller plugin ( see https:// 
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment- 
> tabpanel#action_12514407 ) i propose the following changes and  
> arrangement of the roller plugin modules
> * roller-jetty-derby (in new branch for Gv2.0 release)
> * roller-tomcat-derby (in new branch)
> * roller-jetty-mysql (in new branch)
> * roller-tomcat-mysql (in new branch)
> * roller-jetty (in trunk for future release)
> * roller-tomcat (in trunk)
> * roller-derby-database (in branch and trunk)
> * roller-derby-resources (in branch and trunk)
> * roller-mysql-database (in branch and trunk)
> * roller-mysql-resources (in branch and trunk)
> * roller-war (in branch and trunk)
> Additional files 2 separate geronimo-plugin.xml files in branch an  
> trunk respectively.
> By setting up the new modules listed above to depend on there  
> respective database modules and jpa settings they will not be far  
> away from "ready" for plugin usage (without aliasing) not long  
> after G v2.0 and Roller v4.0 release and we will be able to  
> continue working on the artifact aliasing switch for plugins on the  
> roller-jetty and roller-tomcat modules. This implies changing the  
> geronimo-plugin.xml file to include only the for new modules for  
> the first incarnation of the roller G plugins until things are  
> ready for aliasing switch usage. We could also branch the roller- 
> plugin repository as shown above to make the intention and usage of  
> the modules clearer.
> This is just a suggestion (and me being a bit eager to get  
> something out). This is a minor change (that I am naturally willing  
> to participate in) but once again ;) it may have implications I  
> haven't thought of, so it may still not be the best way to go  
> ahead, thoughts ?
> In future releases of the roller plugin we should look in to  
> including the roller planet subsystem and other enhancements like  
> contributed themes and adding more roller supported databases.

I appear to have planet working, I updated the ROL-1482 jira for  
this, and the derby resources jar.  I'm not sure how to tell if  
planet is actually working, but administering it doesn't generate any  
errors :-)

I think we should look at removing the "resources" jars, putting the  
override properties files perhaps in our war (?), and using the built- 
in roller schema creation (installation.type=auto).

It would also be great to get the roller files into the g. var  
directory and expose some of the properties file configuration  
somehow in a gbean or the admin console.

As I noted in the geronimo jira I think we can sidestep the  
DBDictionary problem by leaving out the property in web.xml and  
letting openjpa figure out for itself what db is being used.

I don't think I understand your proposal above.  Maybe we have  
different assumptions about how the roller plugin will be released.   
I've been wanting since the plugins were invented to distribute a lot  
of geronimo as plugins, each on its own release cycle.  So I was  
thinking that the roller plugin(s) would get released separately from  
geronimo after g. 2.0 was out, and that the maven projects for them  
would remain under plugins/roller.  We might need trunk + tags +  
branches :-).   Is this what you were thinking?

david jencks

> regards
>   Peter Petersson
> David Jencks wrote:
>> 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...
>> thanks!
>> 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