geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Petersson <pe...@pmb.mine.nu>
Subject Re: Release Roller plugin soon?
Date Wed, 20 Feb 2008 20:49:42 GMT
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
>>>>
>>>>
>>>>
>>>
>>
>>
>


Mime
View raw message