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://
issues.apache.org/jira/browse/GERONIMO-2994?
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?
thanks
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/
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 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://
cwiki.apache.org/confluence/display/ROLLER/Roller+Mailing+Lists
thanks
Peter Petersson
