I haven't found any problems using openjpa 1.0 against roller trunk. I'll try again with the released roller 4.0 soon.
If I remove roller's log4j.properties file and override a couple properties in our roller-custom.properties file then logging starts working. I'm wondering if there's a way to keep log4j from jumping on the latest bandwagon whenever you deploy a new app that has the misguided idea that it owns the universe.... thanks david jencks ----- Original Message ---- From: Peter Petersson <[EMAIL PROTECTED]> To: dev@geronimo.apache.org Sent: Wednesday, February 20, 2008 12:49:42 PM Subject: Re: Release Roller plugin soon? I found where jpa 1.0 was mentioned not to work with roller take a look at the "Roller 4.0 RC8 on Geronimo 2.0.2" - tread in rollers dev list (Daves replay to fp). Apparently you will be able to set up the derby db but you will get a Foreign-Key-Vailolation wile creating a new weblog, but maybe this issue have been fixed. regards peter petersson Peter Petersson wrote: > David Jencks wrote: >> >> On Feb 16, 2008, at 9:51 AM, Peter Petersson wrote: >> >>> David Jencks wrote: >>>> Now that 2.1 is released (I think :-) I'd like to move toward >>>> releasing the Roller plugin pretty soon. >>>> >>>> The major obstacle I know of is that the source of the roller war >>>> used as input is rather mysterious and is certainly not released by >>>> roller. I can build it locally but I've forgotten what roller >>>> modifications if any are in it. >>> You are right about that ;). If you chose the local build strategy, >>> checking out the roller 4.0 tag and use "ant mvn-install" (also >>> before first time build "ant mvn-get") should build and install the >>> roller artifacs. My impression is that this should produce the same >>> stuff as is released by the roller teem as mvn-install depends on >>> "build" and I cant find any other ant release related sections but >>> maybe the actuall release is done some other way (?). No extra >>> patches should be needed every necessary patch we provided and >>> wanted to get in for the plugin to work smoothly has been included >>> by the roller teem before the svn branching to 4.1. >>>> >>>> I'm not exactly happy with the idea but think the most practical >>>> solution is to check any necessary roller patch and the built war >>>> into svn. I don't know if we could convince the roller project to >>>> release maven-compatible artifacts in a reasonable amount of time. >>> There is a "mvn-deploy" section in the roller projects ant build.xml >>> file but I don't know if anybody has pulled the trigger ;) but >>> releasing artifacts may not be that far away. But as you say a more >>> practical solution is probably to add the war by setting up a extra >>> "roller-war-mvn-install" section in the roller plugin code base that >>> puts the war in your local maven repos. >>>> >>>> Another possible improvement is to remove the jars from WEB-INF/lib >>>> and put them into our repository. This would greatly reduce the >>>> size of the war we'd have to keep in svn. >>> In the long run, if we cant convince the roller teem to pick up >>> maven which dosen't seem likely, this would be something to consider >>> although during my work on a maven build system for roller I found >>> that 4 of the roller used lib jars is not present in maven, but that >>> may have changed. One way to accomplish this would be to pick up and >>> maintain the maven build patch for roller but maybe that would be to >>> "go over the river for water". >> >> It might be worth it :-).... after spending some time working on a >> roller security refactoring I remember so many of the reasons I don't >> like ant :-) >> >> I've confirmed that we don't need additional roller patches with the >> current plugin to get something installable. >> >> I've also played around with a "no-libs" roller without anything in >> its WEB-INF/lib, all these jars being dependencies in the geronimo >> repo. See the GERONIMO-2994-nolibs.patch and >> GERONIMO-2994-roller-patch patches. These seem to work fine (only >> tried jetty so far) but introduce the question of how to make the 4-5 >> unpublished jars and roller jars available to someone who wants to >> download and install the plugin. Maybe I can cook up a way to get >> just these jars into the WEB-INF/lib. One of the jars, >> commons-id-1.0-SNAPSHOT has never been released in any form >> whatsoever, so I kinda wonder about including it in any apache projects. > Great! I hope to get some time this weekend to do some testing on the > patches. Taking a quick peek at the nolibs patch I notice it uses G:s > openjpa and I have a faint memory of there being a issue that prevents > roller from using anything jpa newer than 0.9.7 or .8 so there may be > some problem lurking inside ;-). On the none maven jars topic, > commons-id at least the project has some sporadic activity see > http://commons.apache.org/sandbox/id/. What surprise me a bit is that, > although widely used, none of the rome jars is found in a public maven > repo, although the rome stuff is clearly built with maven see > http://wiki.java.net/bin/view/Javawsxml/HowToBuild >> >> Another idea I had before releasing this is to try to get logging >> working. So far everything I've tried has not allowed any logging >> from roller in any form I can find. Anyone have any ideas? > Have you looked in jetty's log? I don't know way I haven't mentioned > this but at least logging is somehow working using roller on tomcat > but roller seem to hijack parts of the logging and place it in > catalina/logs/roller.log. Looks like this > > INFO 2008-02-20 19:38:20,977 GeronimoLog:info - SUCCESS: Got > parameters. Using configuration type JNDI_NAME > INFO 2008-02-20 19:38:20,979 GeronimoLog:info - -- Using JNDI > datasource name: java:comp/env/jdbc/rollerdb > INFO 2008-02-20 19:38:20,981 GeronimoLog:info - SUCCESS: located JNDI > DataSource [java:comp/env/jdbc/rollerdb] > WARN 2008-02-20 19:38:23,336 GeronimoLog:warn - Failed to setup mail > provider, continuing anways. > > >> >> >> >>>> >>>> Does anyone else want improvements before we release? >>> If the "how to build" section in the readme file is not enough I >>> would vote for including the war "as is" in a "install war section" >>> in the plugin code base before release to "ensure" everybody >>> building the plugin uses the same roller war. >>> >>> There is a roller v4.0.1 on its way I haven't looked at it but maybe >>> we should upgrade to it as it is likely it is a bug fix release. >>> >> >> I've seen talk of 4.1 which has some enhancements but not a 4.0.1.... >> will have to look harder. > Dave is talking about a 4.0.1 snapshot in the "4.0.1 snapshot and > 4.1-m1 builds available for testing" - thread see > http://www.nabble.com/4.0.1-snapshot-and-4.1-m1-builds-available-for-testing-td15426769s12275.html > and I got the impression it will eventually be a 4.0.1 "bugfix" release. > > regards > peter petersson >> >> thanks >> david jencks >> >> >>> regards >>> Peter Petersson >>>> >>>> thanks >>>> david jencks >>>> >>>> >>>> >>> >> >> >
