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
