You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Peter Petersson <pe...@gmail.com> on 2007/07/18 01:37:02 UTC
Apache Roller v4.0 plugin
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
Re: Apache Roller v4.0 plugin
Posted by Peter Petersson <pe...@pmb.mine.nu>.
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?
yes, I will probably get some time to try this out during the weekend.
>
>
> 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.
... trusting google to deliver the mail is not a problem ;) eventually
it will drop through the box, better late (>6h) then never, or ...
>>
>> 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
>>
>
Re: Apache Roller v4.0 plugin
Posted by Peter Petersson <pe...@pmb.mine.nu>.
Peter Petersson wrote:
> David Jencks wrote:
>>
>> 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 :-)
> This is great news.
>>
>> 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.
> Yes it would be nice to have the properties files easy accessible by
> users as we no longer have any useful information in the override
> properties file it could as well reside in the war. Is there any
> gbeans that exposes properties to web apps. from these locations, or
> something similar, available that I can take a look at ?
I was a bit unclear here. When we get things into g:s var directory I
think the only properties file we need to expose is the override
properties file. There will also be roller account specific indexing,
cashing and other files that are best contained here, most of (if not
all) which are path configurable from the override properties file and
should if possible be defaulting to g:s var directory.
>>
>> 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 will test this tomorrow after updating to your new roler jira :) by
> removing the db ref in web.xml and downgrading the schema version to
> 2.4 and test the artifact aliasing switch without any specific
> DBDictionary property set. The concern I have with the roller-jetty
> and roller-tomcat modules is not just the jpa dictionary settings but
> also the database dependency settings.
>>
>> 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?
> Yes this is what I am thinking. The intention of my proposal was to
> not depend on aliasing on the first releases of the roller plugin
> (when ever it is ready) as I have the impression it would require
> changes to Greonimo system modules for smooth usage, hence the short
> time table, but maybe it could be accomplished without requiring
> changes to G? in that case the proposal has no point. The four modules
> would each contain there respective container and database dependency.
> The rest was just normal branching for future work on the roller
> modules that uses aliasing.
> thanks
> Peter Petersson
>>
>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Apache Roller v4.0 plugin
Posted by Peter Petersson <pe...@pmb.mine.nu>.
David Jencks wrote:
>
> 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 :-)
This is great news.
>
> 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.
Yes it would be nice to have the properties files easy accessible by
users as we no longer have any useful information in the override
properties file it could as well reside in the war. Is there any gbeans
that exposes properties to web apps. from these locations, or something
similar, available that I can take a look at ?
>
> 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 will test this tomorrow after updating to your new roler jira :) by
removing the db ref in web.xml and downgrading the schema version to 2.4
and test the artifact aliasing switch without any specific DBDictionary
property set. The concern I have with the roller-jetty and roller-tomcat
modules is not just the jpa dictionary settings but also the database
dependency settings.
>
> 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?
Yes this is what I am thinking. The intention of my proposal was to not
depend on aliasing on the first releases of the roller plugin (when ever
it is ready) as I have the impression it would require changes to
Greonimo system modules for smooth usage, hence the short time table,
but maybe it could be accomplished without requiring changes to G? in
that case the proposal has no point. The four modules would each contain
there respective container and database dependency. The rest was just
normal branching for future work on the roller modules that uses aliasing.
thanks
Peter Petersson
>
> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Apache Roller v4.0 plugin
Posted by David Jencks <da...@yahoo.com>.
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
>>>>>
>>>>
>>>
>>
>
Re: Apache Roller v4.0 plugin
Posted by Peter Petersson <pe...@pmb.mine.nu>.
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.
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
>>>>
>>>
>>
>
Re: Apache Roller v4.0 plugin
Posted by David Jencks <da...@yahoo.com>.
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
>>>
>>
>
Re: Apache Roller v4.0 plugin
Posted by Peter Petersson <pe...@pmb.mine.nu>.
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.
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
>>
>
Re: Apache Roller v4.0 plugin
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: Apache Roller v4.0 plugin
Posted by Peter Petersson <pe...@pmb.mine.nu>.
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.
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
Re: Apache Roller v4.0 plugin
Posted by Peter Petersson <pe...@gmail.com>.
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.
Once again sry for the triple post above gmail was so slow i lost
confidence in it, my mistake.
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