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/
artifact_aliases.properties
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 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://
cwiki.apache.org/confluence/display/ROLLER/Roller+Mailing+Lists
thanks
Peter Petersson