Looks like castor 1.0.5 works fine with pluto 1.0.1 and our console.
The console-testsuite passes too... 'cept for one time that it
prompts for user-auth, but I don't think that is related to castor
change... but manually typing in system/manager there and the entire
suite passes. Looks
It doesn't... I just commit the change to use 1.0.5 and include the
new legal fluff.
--jason
On Mar 2, 2007, at 3:29 PM, Donald Woods wrote:
castor-0.9.5.3 is a prereq for Pluto. I haven't tried using the
newer version with Pluto to see if it breaks us yet.
-Donald
Jason Dillon
Haven't really looked at this yet, Does anyone know if this is a
Tomcat fork ?
http://labs.jboss.com/file-access/default/members/jbossweb/freezone/
dist/1.0.1.GA/jbossweb-usersguide.pdf
Building with Maven version: 2.0.5
Revision: 514164 built with tests skipped
See the full build-1000.log file at
http://people.apache.org/~prasad/binaries/20070303/build-1000.log
[INFO] Building Geronimo Configs :: Persistence Deployer
[INFO]task-segment: [install]
[INFO
Pluto 1.1 integration would be great, and would allow much more
reasonable dynamic additions of screens to the console. Someone just
needs to do the work. :)
I expect Jetspeed 2 would do the same, but I think Pluto would be much
more lightweight, so I would think it would be preferable for the
[
https://issues.apache.org/jira/browse/GERONIMO-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Genender closed GERONIMO-2921.
---
Resolution: Fixed
Fix Version/s: 2.0-beta2
Ok...here is the story...
Tomcat does
I agree with Aaron that Pluto 1.1 would provide a much better baseline
for making the admin console more pluggable. Jetspeed and Liferay are
excellent portals as well but since they are application frameworks in
their own right I think they provide a lot of functionality beyond
what is needed
From reading that PDF it looks to me more like it embeds Tomcat rather
than forking it. Specifically, it says that it uses the 5.5 branch
and then says that the servlet 2.5 and jsp 2.1 specs will be supported
by Tomcat 6.0.x.
On 3/3/07, Matt Hogstrom [EMAIL PROTECTED] wrote:
Haven't really
Paul McMahan wrote:
From reading that PDF it looks to me more like it embeds Tomcat rather
than forking it.
Kinda like us ;-)
[
https://issues.apache.org/activemq/browse/SM-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38650
]
Jamie Goodyear commented on SM-191:
---
Hi All,
After a quick look into this request here is my analysis...
I actually pinged the pluto dev list yesterday:
http://www.nabble.com/Pluto-1.0.x-to-1.1-upgrade-guide-%28Apache-
Geronimo-Console%29-tf3337657.html
If someone who knows more about the details could chime in (Paul?
Aaron?) it might help.
--jason
On Mar 3, 2007, at 9:04 AM, Paul
I'm trying to run the MimeBodyPartTest from
geronimo-javamail_1.4_spec/src/test/java folder but it can't compile due to
a missing dependency. It requires junit.framework package that I do not
seem to have. Does anyone know what this package is a part of and where I
can get it?
Thanks,
Jason
Latest Eclipse-Plugin trunk at Rev513960 fails to build with the
following error on WinXP, Maven 2.0.5 and Java 1.5.0_11 -
[INFO]
[ERROR] BUILD ERROR
[INFO]
How modular is the existing console code? I'm thinking that some
work is probably needed to make it more modular, so that the existing
functionality could be split up into smaller domain-specific modules
and then deployed into the console app. Right now it looks like a
big app, would
Cannot rebuild Geronimo with external ActiveMQ XBean configuration because
Spring Framework is missing
--
Key: GERONIMO-2927
URL:
This currently says...
Sorry! Temporarily unavailable will be back soon...
:-(
--jason
On Mar 2, 2007, at 4:31 PM, Dan Diephouse wrote:
I'm OK with rolling back for now. However the spec itself is final
and the RI impl is already out:
https://jax-ws.dev.java.net/2.1/
Everyone else
Why not just change these to use org/apache/geronimo/system/main/
Daemon, which should be on the parent's classloader? Or org/apache/
log4j/Level ?
Anyways... I don't know enough about what this is really testing to
just nuke it. Seems a tad safer to just pick a different class to load.
Jason Dillon wrote:
How modular is the existing console code? I'm thinking that some work
is probably needed to make it more modular, so that the existing
functionality could be split up into smaller domain-specific modules and
then deployed into the console app. Right now it looks like a
On Mar 3, 2007, at 4:41 PM, Joe Bohn wrote:
Jason Dillon wrote:
How modular is the existing console code? I'm thinking that some
work is probably needed to make it more modular, so that the
existing functionality could be split up into smaller domain-
specific modules and then deployed
On Mar 3, 2007, at 6:39 PM, Jason Dillon wrote:
How modular is the existing console code? I'm thinking that some
work is probably needed to make it more modular, so that the
existing functionality could be split up into smaller domain-
specific modules and then deployed into the console
Ok folks we have 14 votes +1 Let's move the authoring over Confluence. there
have been no 0's nor -1's
We'll move forward and go live with the site generated via Confluence.
Thank you all
Cheers!
Hernan
Hernan Cunico wrote:
Folks,
this vote is for moving the authoring of Geronimo's web
[
https://issues.apache.org/jira/browse/GERONIMO-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks reassigned GERONIMO-2735:
--
Assignee: David Jencks
Add property substitution capability in the config.xml and
[
https://issues.apache.org/jira/browse/GERONIMO-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477738
]
David Jencks commented on GERONIMO-2735:
I worked on trunk (2.0) and reworked the patch substantially.
Following Ted Kirby's idea of property substitution in config.xml
files (GERONIMO-2735) I applied and modified his patch. Jason Dillon
had a jexl expression evaluator lying around so I replace the
evaluation code in the patch with the jexl stuff, so now you can use
expressions in your
I'm OK with rolling back for now. However the spec itself is final
and the
RI impl is already out:
https://jax-ws.dev.java.net/2.1/
Everyone else ok with it?
In Eclipse-land we've got an IP clearance request in on 2.0, we'll
add another
one for 2.1, so we can have enabler plugins for
25 matches
Mail list logo