geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Release Roller plugin soon?
Date Wed, 20 Feb 2008 21:34:19 GMT
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 <peter@pmb.mine.nu>
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
>>>>
>>>>
>>>>
>>>
>>
>>
>





Mime
View raw message