Re: [Discuss] What next?
On 9/3/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > Aighty? Done. Thanks! Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Closed: (GSHELL-32) Hook up slf4j to the plexus api to bridge logging
[ https://issues.apache.org/jira/browse/GSHELL-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-32. -- Resolution: Fixed Fix Version/s: 1.0-alpha-1 > Hook up slf4j to the plexus api to bridge logging > - > > Key: GSHELL-32 > URL: https://issues.apache.org/jira/browse/GSHELL-32 > Project: GShell > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Jason Dillon >Assignee: Jason Dillon > Fix For: 1.0-alpha-1 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-32) Hook up slf4j to the plexus api to bridge logging
Hook up slf4j to the plexus api to bridge logging - Key: GSHELL-32 URL: https://issues.apache.org/jira/browse/GSHELL-32 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Reporter: Jason Dillon Assignee: Jason Dillon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] Trunk: Failed for Revision: 572500
OpenEJB trunk at 572499
Geronimo Revision: 572500 built with tests skipped
See the full build-2300.log file at
http://people.apache.org/~prasad/binaries/trunk/20070903/build-2300.log
[WARNING] Unable to get resource 'com.agical.rmock:rmock:pom:2.0.0-rc-6' from
repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/com/agical/rmock/rmock/2.0.0-rc-6/rmock-2.0.0-rc-6.pom
4K downloaded
Downloading: http://download.java.net/maven/1//cglib/poms/cglib-nodep-2.1_2.pom
[WARNING] Unable to get resource 'cglib:cglib-nodep:pom:2.1_2' from repository
java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//cglib/cglib-nodep/2.1_2/cglib-nodep-2.1_2.pom
[WARNING] Unable to get resource 'cglib:cglib-nodep:pom:2.1_2' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/cglib/cglib-nodep/2.1_2/cglib-nodep-2.1_2.pom
214b downloaded
Downloading:
http://download.java.net/maven/1//com.agical.rmock/jars/rmock-2.0.0-rc-6.jar
[WARNING] Unable to get resource 'com.agical.rmock:rmock:jar:2.0.0-rc-6' from
repository java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//com/agical/rmock/rmock/2.0.0-rc-6/rmock-2.0.0-rc-6.jar
[WARNING] Unable to get resource 'com.agical.rmock:rmock:jar:2.0.0-rc-6' from
repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/com/agical/rmock/rmock/2.0.0-rc-6/rmock-2.0.0-rc-6.jar
174K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 31 source files to
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] Building jar:
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/geronimo-cli-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-cli-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/geronimo-cli-2.1-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-cli/2.1-SNAPSHOT/geronimo-cli-2.1-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: System
[INFO]task-segment: [install]
[INFO]
[INFO] artifact org.codehaus.mojo:jaxb2-maven-plugin: checking for updates from
central
Downloading:
http://repo1.maven.org/maven2/org/codehaus/mojo/jaxb2-maven-plugin/1.2/jaxb2-maven-plugin-1.2.pom
2K downloaded
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/mojo/11/mojo-11.pom
7K downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/mojo/jaxb2-maven-plugin/1.2/jaxb2-maven-plugin-1.2.jar
13K downloaded
Downloading:
http://download.java.net/maven/1//com.sun.xml.bind/poms/jaxb-impl-2.0.5.pom
656b downloaded
Downloading: http://download.java.net/maven/1//ognl/poms/ognl-2.6.9.pom
[WARNING] Unable to get resource 'ognl:ognl:pom:2.6.9' from repository java.net
(http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//ognl/ognl/2.6.9/ognl-2.6.9.pom
[WARNING] Unable to get resource 'ognl:ognl:pom:2.6.9' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading: http://repo1.maven.org/maven2/ognl/ognl/2.6.9/ognl-2.6.9.pom
792b downloaded
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository
java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository
central (http://repo1.maven.org/maven2)
Down
[jira] Commented: (GSHELL-31) Revisit using Modello for the gshell-layout xml handling instead of XStream
[ https://issues.apache.org/jira/browse/GSHELL-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524603 ] Jason Dillon commented on GSHELL-31: Currently xstream is eating up ~360k to handle our very simple xml parsing needs. Really would be ideal if we could get Modello to generate uber-lighteight xml parsers for the xml syntax and object tree we really want to use. But for now, xstream does the right thing so just use it until later. > Revisit using Modello for the gshell-layout xml handling instead of XStream > --- > > Key: GSHELL-31 > URL: https://issues.apache.org/jira/browse/GSHELL-31 > Project: GShell > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Jason Dillon >Assignee: Jason Dillon > Fix For: 1.0-alpha-1 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-31) Revisit using Modello for the gshell-layout xml handling instead of XStream
Revisit using Modello for the gshell-layout xml handling instead of XStream --- Key: GSHELL-31 URL: https://issues.apache.org/jira/browse/GSHELL-31 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Discuss] What next?
Thanks for the CWiki ... On Sep 3, 2007, at 2:30 PM, Jason Dillon wrote: FYI, I took a brief stab and making this into a wiki page here: http://cwiki.apache.org/confluence/display/GMOxDEV/Roadmap+for+2.1 I've only really included my thoughts and davids, so please update this puppy... IMO this type of information is better captured in a wiki page, though its gotta start in an email and the discussion should remain here, but lets capture things in the page so we can have a living document to express what are general plans/desires are for the next major release. Aighty? --jason
Re: [BUILD] Trunk: Failed for Revision: 572434
I get the same error David after an SVN up and rebuild. I'm at 572428.
On Sep 3, 2007, at 7:48 PM, David Jencks wrote:
I'm not getting this error, can anyone else reproduce it? It does
appear to be related to my last commit...
thanks
david jencks
On Sep 3, 2007, at 3:14 PM, [EMAIL PROTECTED] wrote:
[INFO] [jaxb2:xjc {execution: default}]
[INFO] Generating source...
[INFO]
-
---
[ERROR] BUILD ERROR
[INFO]
-
---
[INFO] grammar is not specified
[INFO]
-
---
[INFO] For more information, run Maven with the -e switch
[INFO]
-
---
[INFO] Total time: 3 minutes 5 seconds
[INFO] Finished at: Mon Sep 03 18:11:43 EDT 2007
[INFO] Final Memory: 65M/508M
[INFO]
-
---
Re: Two observations while testing out DayTrader 1.2 on Geronimo 2.0.1
Thanks for the heads up. I had a problem earlier with a JBoss file being processed and deleted all of these files in my local image and totally forgot about it until now. How about we release 1.2? Its probably about time. On Aug 31, 2007, at 10:36 AM, Christopher Blythe wrote: All... Last night/this morning I tried out DayTrader 1.2 on Geronimo 2.0.1 to make sure everything ran fine. During the effort, I ran into two subtle issues... Anyway, just wanted to pass them along. 1) Geronimo and/or OpenJPA appears to process sun-ejb-jar.xml files. This is a file used by Sun Java App Server 9 to handle resource mappings. I originally added the Sun specific DDs to DayTrader 1.2 for comparison purposes. I had to modify the files slightly to get it to work, but it should still work for both Geronimo and SJAS9. Overall, just wanted to express my surprise that OpenJPA would process this file. Any thoughts? 2) If any type of tracing is done on the OpenJPA components, the KeySequenceBean (in EJB mode) fails to work properly because the tracing performs a toString on the KeyBlock - which in turn spins through all the keys in the block. Consequently, when we attempt to get a key from the block all of them have been used. So... make note... be careful using tracing!!! I plan to update DayTrader 1.2 with a plan file for Geronimo 2.0.1 and also make some small changes for #1 and possibly add somethign to the ReadMe for #2. Chris -- "I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may." - Tyler Durden
Re: [BUILD] Trunk: Failed for Revision: 572434
I'm not getting this error, can anyone else reproduce it? It does
appear to be related to my last commit...
thanks
david jencks
On Sep 3, 2007, at 3:14 PM, [EMAIL PROTECTED] wrote:
OpenEJB trunk at 572433
Geronimo Revision: 572434 built with tests skipped
See the full build-1800.log file at http://people.apache.org/
~prasad/binaries/trunk/20070903/build-1800.log
[WARNING] Unable to get resource 'com.agical.rmock:rmock:pom:2.0.0-
rc-6' from repository apache-incubator (http://people.apache.org/
repo/m2-incubating-repository/)
Downloading: http://repo1.maven.org/maven2/com/agical/rmock/rmock/
2.0.0-rc-6/rmock-2.0.0-rc-6.pom
4K downloaded
Downloading: http://download.java.net/maven/1//cglib/poms/cglib-
nodep-2.1_2.pom
[WARNING] Unable to get resource 'cglib:cglib-nodep:pom:2.1_2' from
repository java.net (http://download.java.net/maven/1/)
Downloading: http://people.apache.org/repo/m2-incubating-
repository//cglib/cglib-nodep/2.1_2/cglib-nodep-2.1_2.pom
[WARNING] Unable to get resource 'cglib:cglib-nodep:pom:2.1_2' from
repository apache-incubator (http://people.apache.org/repo/m2-
incubating-repository/)
Downloading: http://repo1.maven.org/maven2/cglib/cglib-nodep/2.1_2/
cglib-nodep-2.1_2.pom
214b downloaded
Downloading: http://download.java.net/maven/1//com.agical.rmock/
jars/rmock-2.0.0-rc-6.jar
[WARNING] Unable to get resource 'com.agical.rmock:rmock:jar:2.0.0-
rc-6' from repository java.net (http://download.java.net/maven/1/)
Downloading: http://people.apache.org/repo/m2-incubating-
repository//com/agical/rmock/rmock/2.0.0-rc-6/rmock-2.0.0-rc-6.jar
[WARNING] Unable to get resource 'com.agical.rmock:rmock:jar:2.0.0-
rc-6' from repository apache-incubator (http://people.apache.org/
repo/m2-incubating-repository/)
Downloading: http://repo1.maven.org/maven2/com/agical/rmock/rmock/
2.0.0-rc-6/rmock-2.0.0-rc-6.jar
174K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /home/prasad/geronimo/trunk/modules/geronimo-
cli/target/classes/META-INF
[INFO] Copying 2 files to /home/prasad/geronimo/trunk/modules/
geronimo-cli/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 31 source files to /home/prasad/geronimo/trunk/
modules/geronimo-cli/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] Building jar: /home/prasad/geronimo/trunk/modules/geronimo-
cli/target/geronimo-cli-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-cli-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing /home/prasad/geronimo/trunk/modules/geronimo-cli/
target/geronimo-cli-2.1-SNAPSHOT.jar to /home/prasad/.m2/repository/
org/apache/geronimo/modules/geronimo-cli/2.1-SNAPSHOT/geronimo-
cli-2.1-SNAPSHOT.jar
[INFO]
--
--
[INFO] Building Geronimo :: System
[INFO]task-segment: [install]
[INFO]
--
--
[INFO] artifact org.codehaus.mojo:jaxb2-maven-plugin: checking for
updates from central
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/jaxb2-
maven-plugin/1.2/jaxb2-maven-plugin-1.2.pom
2K downloaded
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/mojo/
11/mojo-11.pom
7K downloaded
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/jaxb2-
maven-plugin/1.2/jaxb2-maven-plugin-1.2.jar
13K downloaded
Downloading: http://download.java.net/maven/1//com.sun.xml.bind/
poms/jaxb-impl-2.0.5.pom
656b downloaded
Downloading: http://download.java.net/maven/1//ognl/poms/
ognl-2.6.9.pom
[WARNING] Unable to get resource 'ognl:ognl:pom:2.6.9' from
repository java.net (http://download.java.net/maven/1/)
Downloading: http://people.apache.org/repo/m2-incubating-
repository//ognl/ognl/2.6.9/ognl-2.6.9.pom
[WARNING] Unable to get resource 'ognl:ognl:pom:2.6.9' from
repository apache-incubator (http://people.apache.org/repo/m2-
incubating-repository/)
Downloading: http://repo1.maven.org/maven2/ognl/ognl/2.6.9/
ognl-2.6.9.pom
792b downloaded
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-
asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from
repository java.net (http://download.java.net/maven/1/)
Downloading: http://people.apache.org/repo/m2-incubating-
repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from
repository apache-incubator (http://people.apache
[BUILD] Trunk: Failed for Revision: 572434
OpenEJB trunk at 572433
Geronimo Revision: 572434 built with tests skipped
See the full build-1800.log file at
http://people.apache.org/~prasad/binaries/trunk/20070903/build-1800.log
[WARNING] Unable to get resource 'com.agical.rmock:rmock:pom:2.0.0-rc-6' from
repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/com/agical/rmock/rmock/2.0.0-rc-6/rmock-2.0.0-rc-6.pom
4K downloaded
Downloading: http://download.java.net/maven/1//cglib/poms/cglib-nodep-2.1_2.pom
[WARNING] Unable to get resource 'cglib:cglib-nodep:pom:2.1_2' from repository
java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//cglib/cglib-nodep/2.1_2/cglib-nodep-2.1_2.pom
[WARNING] Unable to get resource 'cglib:cglib-nodep:pom:2.1_2' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/cglib/cglib-nodep/2.1_2/cglib-nodep-2.1_2.pom
214b downloaded
Downloading:
http://download.java.net/maven/1//com.agical.rmock/jars/rmock-2.0.0-rc-6.jar
[WARNING] Unable to get resource 'com.agical.rmock:rmock:jar:2.0.0-rc-6' from
repository java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//com/agical/rmock/rmock/2.0.0-rc-6/rmock-2.0.0-rc-6.jar
[WARNING] Unable to get resource 'com.agical.rmock:rmock:jar:2.0.0-rc-6' from
repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/com/agical/rmock/rmock/2.0.0-rc-6/rmock-2.0.0-rc-6.jar
174K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 31 source files to
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] Building jar:
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/geronimo-cli-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-cli-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/geronimo-cli-2.1-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-cli/2.1-SNAPSHOT/geronimo-cli-2.1-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: System
[INFO]task-segment: [install]
[INFO]
[INFO] artifact org.codehaus.mojo:jaxb2-maven-plugin: checking for updates from
central
Downloading:
http://repo1.maven.org/maven2/org/codehaus/mojo/jaxb2-maven-plugin/1.2/jaxb2-maven-plugin-1.2.pom
2K downloaded
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/mojo/11/mojo-11.pom
7K downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/mojo/jaxb2-maven-plugin/1.2/jaxb2-maven-plugin-1.2.jar
13K downloaded
Downloading:
http://download.java.net/maven/1//com.sun.xml.bind/poms/jaxb-impl-2.0.5.pom
656b downloaded
Downloading: http://download.java.net/maven/1//ognl/poms/ognl-2.6.9.pom
[WARNING] Unable to get resource 'ognl:ognl:pom:2.6.9' from repository java.net
(http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//ognl/ognl/2.6.9/ognl-2.6.9.pom
[WARNING] Unable to get resource 'ognl:ognl:pom:2.6.9' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading: http://repo1.maven.org/maven2/ognl/ognl/2.6.9/ognl-2.6.9.pom
792b downloaded
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository
java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository
central (http://repo1.maven.org/maven2)
Dow
[jira] Updated: (GERONIMO-2994) Apache Roller plugin
[ https://issues.apache.org/jira/browse/GERONIMO-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Petersson updated GERONIMO-2994: -- Attachment: roller_maven_ant_task_070902_0.patch roller_plugin_070803.patch Bringing Roller plugins to G v2.0.1 and roller-4.0_rc1 by adding roller_plugin_070803.patch and roller_maven_ant_task_070902_0.patch. Changes I recall doing = * Updating roller plugins from Geronimo 2.0-SNAPSHOT to Geronimo 2.0.1. * Changing the version schema of the plugins to (-SNAPSHOT) and adding geronimo and roller version information to the geronimo-plugin description. * Removing dependency of the roller-war plugin module and updating the roller-weblogger war by using the 4.0_rc1 version via local maven repo. See additional information on building and installing the roller weblogger artifact below. * Updating the plugins parent version accordingly (org.apache.geronimo.genesis.config/project-config/1.2) * Setting I am not sure this is needed (and it is likely a performance damper) but during my work on the roller maven build system (jira ROL-1537) I got rid of a random exception that bugged me wile adding and testing out the mvn jetty:run-war on roller-weblogger.war by setting it. * Could not get the DatabaseInitializationGBean to work properly, switched to rollers auto install by setting installation.type=auto in roller-custom.properties * Updating the geronimo-plugins.xml file to reflect the new version. * Updating the README file with up to date installation instructions. * Some general cleanup. Local maven roller-weblogger.war For now (as long as no official roller maven artifacts are available) I found this to be the most useful way of handling the weblogger. Check out the svn 4.0_rc1 tag found at https://svn.apache.org/repos/asf/roller/tags/roller_4.0_rc1/ patch it with the roller_maven_ant_task_070902_0.patch (it's a small maven patch to the ant build included in this jira) and run 'ant mvn-install'. Observe that you need to download and install the maven-ant-task jar from here http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-ant-tasks-2.0.7.jar and place it in /tools/buildtime/maven/. Some of this information can also be fond in the README file in the plugin root. Known Caveats = * uninstall of roller plugins leaves the roller--resources files present in geronimo/repostory and it will not be overwritten/replaced by a new one unless you manually delete it or change the version. This can be a bit annoying and cause some confusion during work on the plugins. * maven install from root directory dose not work the first time around (from a clean local repository) you have to install the modules one by one. > Apache Roller plugin > - > > Key: GERONIMO-2994 > URL: https://issues.apache.org/jira/browse/GERONIMO-2994 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 1.2 >Reporter: Peter Petersson >Assignee: David Jencks >Priority: Minor > Attachments: geronimo-plugins.xml, geronimo-plugins.xml, > geronimo-plugins_070602.xml, geronimo-web.xml, geronimo-web.xml, plan.xml, > PluginInstallerGBean.patch, pom.xml, pom.xml, roller-custom.properties, > roller-custom.properties, roller-custom.properties, > roller-derbydb-plan-g1_2.xml, roller-mysql-db-plan-1-2.xml, > roller070409.patch, roller12_070602.zip, roller_g20_svn_070602.patch, > roller_maven_ant_task_070902_0.patch, roller_plugin.patch, > roller_plugin_070717.patch, roller_plugin_070803.patch, > roller_plugin_patch_070724.txt > > > Have been working on getting Apache Roller running under Geronimo I finally > got to the point where the roller application seems to be running smoothly in > Geronimo v1.2 (current snapshot). It would be great to eventually see this > application as a plugin in G so here are pointers to resources and attached > plans. > Apache Roller v3.1 Resources (soon to be released) > Apache roller home: http://rollerweblogger.org/project/ > The bundle: http://people.apache.org/~snoopdave/apache-roller-3.1/ (until it > will be available directly via roller home) > Required jars: > https://roller.dev.java.net/servlets/ProjectDocumentList?expandFolder=6959&folderID=0 > Path to database create scripts can be found in the bundle above under: > apache-roller-3.1/webapp/roller/WEB-INF/dbscripts/ > I have tested with the derby database and mysql 5. > There is currently a issue with G v1.2 and hibernates v3.1 (used by roller > 3.1) property loader that gets a > > FATAL [HibernateRollerImpl] Error initializing Hibernate > java.lang.ClassCastException: java.util.HashSet >
Wiki clean up...
I just rand into some really old-arse stuff in the wiki, and I didn't
really look to hard to find more, but I started adorning stuff that
is growing stale with:
{warning:title=Stale Content}
The content of this page is growing stale and may or may not contain
relevant, useful or correct information.
{warning}
I think we need to clean this stuff up... nothing is worse IMO than
information that is irrelevant, misleading or completely invalid.
And well, I'm smelling a lot of that in the wiki...
Lets clean it up, delete the stuff that isn't relevant anymore and
try to take better care of the content in here...
--jason
Re: [Discuss] What next?
FYI, I took a brief stab and making this into a wiki page here: http://cwiki.apache.org/confluence/display/GMOxDEV/Roadmap+for+2.1 I've only really included my thoughts and davids, so please update this puppy... IMO this type of information is better captured in a wiki page, though its gotta start in an email and the discussion should remain here, but lets capture things in the page so we can have a living document to express what are general plans/desires are for the next major release. Aighty? --jason On Aug 30, 2007, at 5:12 PM, David Jencks wrote: Getting 2.0.1 out the door was a great step and now might be a good time to start discussing where we want geronimo to head next. Here are some ideas I've had or think are important. If I were to try to write actual sentences about all of this I'd probably never send the email so this is way too fragmentary but maybe can spark more discussion. I'm hoping everyone will chime in with their interests and viewpoints, this is just what I've been thinking about lately. Modularity. For a long time we've been on the brink of having an actually modular server, not just a conceptually modular server. As reflected in a lot of recent discussion on the dev list, I think we are so close we should really work hard to make this a pleasant reality. Some of the steps I see: - enhance the plugin framework so bits of more config files can be added, in particular artifact_aliases.properties and config_substitutions.properties. IIUC Paul has some schema changes and xml handling rewrites in the wings as well - finish up the pluggable admin console work and actually split the admin console into appropriate bits for the plugins - rearrange the build so it is organized by plugin - actually assemble the servers we ship using plugins, perhaps using gshell scripts - have more server-building tools. For instance, a "button" to push that spits out a server with just what is needed for a set of apps and nothing else. Clustering IIUC we have a lot of partial clustering solutions. For instance there's WADI, native tomcat clustering, a terracotta integration, and IIUC Jeff has been working on a clustering solution (my apologies if I left any out). I'd like to know where these efforts are in terms of actual functionality and reliability and what they can be extended to do. We also need some kind of cluster admin tools. Security jaspi triplesec administration beyond javaee security for jetspeed and roller There are some good things about javaee security such as the idea of using Permissions and evaluating them in a policy but there are also a lot of limitations and problems such as no support for restricting access to user generated content that didn't exist when the security was originally configured. At least roller and jetspeed have run into this problem. I think triplesec may provide a fairly generic solution and it might be interesting to see if other projects are interested in this. Other apps roller jetspeed proximity etc It would be great to get "all popular apps" available as geronimo plugins. Management and troubleshooting ARM "trace on error" facility. Have a list of info that each component can add to as the request moves through the system. If there's an error, we can show the entire path taken with all data. Otherwise we discared it. server farm management (gshell?) Transaction manager implement a "do work in a new tx" interface, hook it up to openjpa. IIUC IBM has proposed an interface that lets server pieces submit work to be done in a new transaction, thus eliminating the need to deal with suspend etc yourself. There's been some discussion on the openjpa lists, and we should definitely do this. There may be more commonj work to do also, but I've more or less lost track of that project. make sure recovery actually works Core Better Spring application management Investigate OSGI and figure out how it is different from what we are doing, what it can do better, and what is missing from it. Figure out an integration strategy whether it be "run OSGI as an application" or "replace the kernel with OSGI" Don't break stuff if we start using OSGI more :-) Figure out what to do with our "config.ser" in modules/ configurations. At least get it into real xml, maybe using something like jaxb with schema/gbean. Personally I'm interested in most of these projects but only have a finite amount of time. Right now I'm concentrating on triplesec and want to work on jetspeed integration after that. thanks david jencks
[BUILD] Trunk: Failed for Revision: 572398
OpenEJB trunk at 572396
Geronimo Revision: 572398 built with tests skipped
See the full build-1400.log file at
http://people.apache.org/~prasad/binaries/trunk/20070903/build-1400.log
[WARNING] Unable to get resource 'com.agical.rmock:rmock:pom:2.0.0-rc-6' from
repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/com/agical/rmock/rmock/2.0.0-rc-6/rmock-2.0.0-rc-6.pom
4K downloaded
Downloading: http://download.java.net/maven/1//cglib/poms/cglib-nodep-2.1_2.pom
[WARNING] Unable to get resource 'cglib:cglib-nodep:pom:2.1_2' from repository
java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//cglib/cglib-nodep/2.1_2/cglib-nodep-2.1_2.pom
[WARNING] Unable to get resource 'cglib:cglib-nodep:pom:2.1_2' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/cglib/cglib-nodep/2.1_2/cglib-nodep-2.1_2.pom
214b downloaded
Downloading:
http://download.java.net/maven/1//com.agical.rmock/jars/rmock-2.0.0-rc-6.jar
[WARNING] Unable to get resource 'com.agical.rmock:rmock:jar:2.0.0-rc-6' from
repository java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//com/agical/rmock/rmock/2.0.0-rc-6/rmock-2.0.0-rc-6.jar
[WARNING] Unable to get resource 'com.agical.rmock:rmock:jar:2.0.0-rc-6' from
repository apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/com/agical/rmock/rmock/2.0.0-rc-6/rmock-2.0.0-rc-6.jar
174K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 31 source files to
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] Building jar:
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/geronimo-cli-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-cli-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/trunk/modules/geronimo-cli/target/geronimo-cli-2.1-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-cli/2.1-SNAPSHOT/geronimo-cli-2.1-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: System
[INFO]task-segment: [install]
[INFO]
[INFO] artifact org.codehaus.mojo:jaxb2-maven-plugin: checking for updates from
central
Downloading:
http://repo1.maven.org/maven2/org/codehaus/mojo/jaxb2-maven-plugin/1.2/jaxb2-maven-plugin-1.2.pom
2K downloaded
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/mojo/11/mojo-11.pom
7K downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/mojo/jaxb2-maven-plugin/1.2/jaxb2-maven-plugin-1.2.jar
13K downloaded
Downloading:
http://download.java.net/maven/1//com.sun.xml.bind/poms/jaxb-impl-2.0.5.pom
656b downloaded
Downloading: http://download.java.net/maven/1//ognl/poms/ognl-2.6.9.pom
[WARNING] Unable to get resource 'ognl:ognl:pom:2.6.9' from repository java.net
(http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//ognl/ognl/2.6.9/ognl-2.6.9.pom
[WARNING] Unable to get resource 'ognl:ognl:pom:2.6.9' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading: http://repo1.maven.org/maven2/ognl/ognl/2.6.9/ognl-2.6.9.pom
792b downloaded
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository
java.net (http://download.java.net/maven/1/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository
central (http://repo1.maven.org/maven2)
Dow
[jira] Commented: (GERONIMO-3330) plugin schema for reducing redundancy in the catalog
[ https://issues.apache.org/jira/browse/GERONIMO-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524564 ] David Jencks commented on GERONIMO-3330: Most of this is done in rev 572395 but the cli and console plugin installers need a lot more work. Also all the car poms need to be fixed up so the generated geronimo-plugin.xml is reasonably accurate. > plugin schema for reducing redundancy in the catalog > > > Key: GERONIMO-3330 > URL: https://issues.apache.org/jira/browse/GERONIMO-3330 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 2.1 >Reporter: Paul McMahan >Assignee: David Jencks > Attachments: plugins-1.2.xsd > > > GERONIMO-2757 introduced some changes to the geronimo plugin schema to allow > more flexibility with specifying the geronimo version for a plugin. Further > refinements to the schema can provide even greater flexibility and reduce the > redundancy and complexity in plugin catalogs. Grouping the version and > container sensitive part of the plugin data into elements within > will help avoid separate catalog entries for tomcat and > jetty compatible plugins, and also associate the version sensitive data > closer to the geronimo-version element. I will attach a schema that > demonstrates how this can be implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3453) Generate geronimo-plugin.xml files with the car-maven-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524563 ] David Jencks commented on GERONIMO-3453: Base work done in rev 572395. However we now have to provide relevant info in each car pom to fill out the dependencies, prereqs, etc. That rev only did a few cars. > Generate geronimo-plugin.xml files with the car-maven-plugin > > > Key: GERONIMO-3453 > URL: https://issues.apache.org/jira/browse/GERONIMO-3453 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.0 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.1 > > > Generate geronimo-plugin.xml from info in the pom.xml. In particular list > the dependencies explicitly in the car-maven-plugin configuration and use > them for the dependencies in the plan also. Also move the plans under > src/main/plan from src/plan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Plugin stuff
I've committed what I have so far: - use new plugin schema - generate geronimo-plugin.xml files for each car from pom.xml - generate plan environment section from explicitly listed car-maven- plugin configuration instead of from maven dependencies. We check that each dependency listed in the maven plugin config is actually present in the maven dependencies section. - moved car plans to src/main/plan/plan.xml - include plan in the car for reference. Problems/left to do: - I haven't converted many of the car poms to actually generate the correct geronimo-plugin.xml or the correct plan, so most plans have the previously generated dependencies in them. There are a lot (nearly 100) so if anyone wants to help me update the poms that would be great. I did do a few of the cars with existing geronimo- plugin.xmls. - the xml configuration format in pom.xml is adapted for maven, not for jaxb. It would be great if we could figure out how to make the configuration in pom.xml look more like geronimo-plugins.xml or the environment element. - The cli search-plugins and console plugin installer work, but only sort of. For instance they don't show you which plugins are installed or would have problems due to prerequisite or obsoletes problems. I'm hoping someone less clueless about uis can help with this part. - in order to get this to work quickly I added jaxb dependencies to lib. I think this is really bad and hope we can figure out how to remove them again. Let me know if I've broken other stuff :-) thanks david jencks On Aug 31, 2007, at 10:28 AM, David Jencks wrote: So I have the code compiling but now all the geronimo-plugin.xml files are in the old format... :-( I'm going to look into generating them in the car-maven-plugin along with making a car-maven-plugin configuration that includes the dependencies more directly so we don't spend hours trying to generate them from the maven dependencies. thanks david jencks suffering from feature creep... On Aug 29, 2007, at 12:26 PM, David Jencks wrote: I'm going to take a couple days to see if I can get the plugin installer in better shape. My goals are: - new schema as in GERONIMO-3330 - jaxb based - easier to use the local maven repo as a plugin repo. This might be done by having a "scan repo and generate geronimo-plugins.xml from all the plugins we find" function. - let plugin xml contain more global bits. Right now it can contain config.xml bits, it should be able to modify other config.xml type files (offline deployer, etc) and artifact_aliases and config-substitutions properties files. The changes to the properties files need to be live so e.g. when the plugin is started the new entries get used. thanks david jencks
[VOTE] Release Geronimo Eclipse Plugin 2.0.0
Hi, Please review and vote on the release of the Geronimo Eclipse Plugin 2.0.0 (to correspond with the Geronimo 2.0.1 Server release): The deployable zip file is here: > http://people.apache.org/~mcconne/releases/g-eclipse-plugin-2.0.0-deployable.zip The current svn location is here: > https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.0.0 The future svn location will be here: > https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.0.0 The vote will conclude at 2:00 PM EST on Thursday, September 6th. -- Thanks, Tim McConnell
Testing --- please ignore
Re: Splitting up the server into a few more chunks
On Aug 29, 2007, at 10:12 AM, Prasad Kashyap wrote: Scenario 1: server/support/trunk server/framework/trunk server/plugins/trunk/ <--- jee5, non-jee5, samples etc are all here together. I'm not really convinced we need to have this intermediate "server" tree right now. IMO this is a bit over structured for a structure we haven't really gotten a good idea for what it looks like. I'd defer organizing the chunks we split off into smaller groups as an exercise for once we've actually gotten then chunks pulled off. Its easy enough to change later... --jason
Re: [Discuss] What next?
Oh, one more thing which I think is also critical path for the health of the server and its community... LOGGING REFORM We've talked about this here and there, most folks agree we need to reform our logging usage... but so far its yet to happen. It is a fairly simple task IMO, but its huge, since it pretty much touches almost everything. But its something that can be easily staged and then divided up amongst the surfs (and lords) for code weeding. IMO, we need to... 1) Decide on slf4j or commons-cli 2) Define a general logging usage policy 3) Implement said policy on existing logging usage 4) Improve, add, augment, whatever, existing logging to be more useful (for users and developers) For #1 I'm obviously for slf4j... for a few reasons which I've outlined in previous emails. I list this as the first step, as if we do go for it, then it has some slight impact on the policy and implementation work (like its varargs support instead of requiring log.isDebugEnabled() guarding). IMO, this is low handing fruit, which we can easily pick and which our users (and developers) can feast upon the juicy flesh of... yummy. --jason On Aug 30, 2007, at 5:12 PM, David Jencks wrote: Getting 2.0.1 out the door was a great step and now might be a good time to start discussing where we want geronimo to head next. Here are some ideas I've had or think are important. If I were to try to write actual sentences about all of this I'd probably never send the email so this is way too fragmentary but maybe can spark more discussion. I'm hoping everyone will chime in with their interests and viewpoints, this is just what I've been thinking about lately. Modularity. For a long time we've been on the brink of having an actually modular server, not just a conceptually modular server. As reflected in a lot of recent discussion on the dev list, I think we are so close we should really work hard to make this a pleasant reality. Some of the steps I see: - enhance the plugin framework so bits of more config files can be added, in particular artifact_aliases.properties and config_substitutions.properties. IIUC Paul has some schema changes and xml handling rewrites in the wings as well - finish up the pluggable admin console work and actually split the admin console into appropriate bits for the plugins - rearrange the build so it is organized by plugin - actually assemble the servers we ship using plugins, perhaps using gshell scripts - have more server-building tools. For instance, a "button" to push that spits out a server with just what is needed for a set of apps and nothing else. Clustering IIUC we have a lot of partial clustering solutions. For instance there's WADI, native tomcat clustering, a terracotta integration, and IIUC Jeff has been working on a clustering solution (my apologies if I left any out). I'd like to know where these efforts are in terms of actual functionality and reliability and what they can be extended to do. We also need some kind of cluster admin tools. Security jaspi triplesec administration beyond javaee security for jetspeed and roller There are some good things about javaee security such as the idea of using Permissions and evaluating them in a policy but there are also a lot of limitations and problems such as no support for restricting access to user generated content that didn't exist when the security was originally configured. At least roller and jetspeed have run into this problem. I think triplesec may provide a fairly generic solution and it might be interesting to see if other projects are interested in this. Other apps roller jetspeed proximity etc It would be great to get "all popular apps" available as geronimo plugins. Management and troubleshooting ARM "trace on error" facility. Have a list of info that each component can add to as the request moves through the system. If there's an error, we can show the entire path taken with all data. Otherwise we discared it. server farm management (gshell?) Transaction manager implement a "do work in a new tx" interface, hook it up to openjpa. IIUC IBM has proposed an interface that lets server pieces submit work to be done in a new transaction, thus eliminating the need to deal with suspend etc yourself. There's been some discussion on the openjpa lists, and we should definitely do this. There may be more commonj work to do also, but I've more or less lost track of that project. make sure recovery actually works Core Better Spring application management Investigate OSGI and figure out how it is different from what we are doing, what it can do better, and what is missing from it. Figure out an integration strategy whether it be "run OSGI as an application" or "replace the kernel with OSGI" Don't break stuff if we start using OSGI more :-) Figure out what to do with our "config.ser" in modules/ con
Re: Splitting up the server into a few more chunks
On Aug 6, 2007, at 8:03 PM, David Blevins wrote: On Aug 6, 2007, at 8:12 AM, David Jencks wrote: I certainly agree with your goal but am less sure about your proposed naming and organization. Also from looking at your list it took me a couple minutes to figure out what is removed from "server" I've been thinking that we could proceed by turning bits of the server into plugins. For instance I was planning to turn the directory bits I commented out recently into a plugin this week. I think we could fairly easiiy turn jetty, tomcat, and openejb into plugins. I wonder if, after turning the "easy stuff" into plugins what we will think about reorganizing the remaining stuff. So then the question might be how to organize the plugins? Haven't read the rest of the thread yet, but I'd like to backup the idea of pulling things out one at a time, like we did with connector and transaction, making them plugins if possible. It would be really great if people do things like upgrade OpenEJB when a new release came out -- which we're hoping is often. Do you know of any other bits which we can pull out nowish (or with a wee bit of work)? I'd really like to get the kernel and muck sucked out, but I've got a feeling that is a hugeish taskotron. --jason
Re: Splitting up the server into a few more chunks
On Aug 6, 2007, at 11:12 AM, Donald Woods wrote: Another thought (now that I had some lunch) What if we create a "builders/deployers" grouping, which contained the modules and configs needed for each builder, like - deployers myfaces modules geronimo-myfaces geronimo-myfaces-builder configs myfaces myfaces-deployers tomcat . . . jetty . . . Anything that didn't fit into a deployer/builder category, could go into a system grouping or the existing components group. I forget what I said about this before... but just in case I didn't say it... I'm really *not* fond of grouping things under a "deployer (s)" name. I think we have a core/framework, a set of reusable components (non-plugins, ie. tx manager, jndi provider or whatever), a set of plugins which provide additional functionality (could be deployment, could be daemon processes, whatever), a set of standard applications (like the web console), and a set of assemblies (which glue it all together). So, based on that I think that: framework|core/trunk components//trunk plugins//trunk apps//trunk server//trunk (where server is javaee/minimal/crackpipe/ etc) uberserver/trunk (uses svn:externals to make a workspace with all the bits to compile for those who like to watch paint dry as the beast builds) For now I'd like to see the components, plugins and apps trees contain separate sub-projects for each chunk of functionality, versioned and released independently. I'm guessing that these projects might contain anywhere from 2-10 modules or so, probably averaging at 4, maybe 3. Ya, I know its more moving parts to manage, but IMO, I think this will simplify many aspects of delivering a rock solid application server (and framework) to the world. And if we do it right we should be able to quickly adapt and fix bugs for faster turn around. And well, it will also make some of our lives a lot simpler since with *most* of the server being in separate smaller sub- projects which are released, there is a heck of a lot less code to build. Well, anyways... no matter how we slice it... we need to do something. And we should really get some yays and nays in the next week or so about the _general_ plan... and then start to stage the move... because it will affect developers, there will be oh-so-fun merges to be done, and someone is not going to be happy I'm sure... but we need to do it. And, well with my code slinging cowbow hat on I'd say lets just go balls out and do it. Once we have a general plan, implementing will take a week maybe (to get it all sorted and back to happy happy again), assuming there are no super-evil coupling points. /me will shutup now --jason
Re: Trouble with 2.0.1 main pom and building anything a G dependency
On 9/3/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > > IMO, we need to ween ourselves off of the local repository module > completely... and avoid future use of any such local repository. +1 When I (er we) did the main Maven 2 conversion I added some of these > local modules as short-term work arounds to problems... there was no > intention of leaving these in here for as long as they've been around. > > If we need to use some custom artifacts, then we really should > publish them under an org.apache.geronimo.thirdparty groupId (or > something) to the central repository and then treat them like normal > dependencies. We can of course setup a thirdparty sub-project which > has a local repository with the definitive source of the artifacts, > but only use that puppy to manage those artifacts pom's and then > publish them as we normally would anything else. > > This is... IMO... the *ONLY* solution to this problem, short of > removing the need for these custom artifacts. > > --jason > > > On Aug 30, 2007, at 3:05 PM, Jeff Genender wrote: > > > Hi, > > > > I was building a 3rd party application with a dependency on the > > Geronimo > > specs (jee)...and I could not get it to build because it was > > looking for > > > > axis-saaj-1.3-r562247 > > > > For the life of me, I thought I had that usual maven corrupt repo > > issues > > and I wiped out my local repo...a number of times. I began looking > > through repos and sure enough it didn't exist. Well..I decided to > > look > > in our pom and I found: > > > > 1.3-r562247 > > > > Further discussion with others resulted in finding that we have a > > "special" repository that pulls these special versions. (Ok I forgot > > about that). > > > > This is going to be a problem for anyone who has a dependency on our > > jars (ie. wanting to use the specs jars for a web applications, etc). > > If I (a committer) had to go through this much trouble trying to > > figure > > out how to get that dependency...I can't imagine what the standard > > user > > will go through when writing a web or webservices application. > > > > The point I am making here is if we are going to have special versions > > of jars, we need to make these more readily available. > > > > Here are some options I thought of: > > > > A) Place the special jars in central so they are automatically > > available > > to others. (Easiest approach for the user - but we are going to > > have to > > convince other projects to put them out into their locations - that > > may > > prove difficult). > > > > B) Heavily, heavily document how to get around this problem by adding > > our repo to their pom. This should be easily Googled and placed in a > > FAQ, because I would hazard to guess this will be a frequent question. > > (probably the easiest approach for us, but this needs to be a short > > term > > solution - and its still a PITA for our users). > > > > C) Convince the other projects to get their releases in order and get > > good versions of their product on central. (Should do this > > regardless of > > any other option). > > > > D) Rename our special versions to g-axis-saaj-1.3-r562247 and house > > those under our own control (org.apache.geronimo...) in central on our > > next build (2.0.2). (The easy and quick, and very temprary fix!) > > > > Thoughts? Comments? > > > > Thanks, > > > > Jeff > >
Re: Splitting up the server into a few more chunks
On Aug 6, 2007, at 9:59 AM, Donald Woods wrote: Anything more than 6 to 8 groupings could cause chaos (just like at our current release process which takes weeks to get everything voted and released...) After cleanup of server to move the samples to /samples and ApacheDS to /plugins, we should consider the more drastic changes, like moving the base Admin Console support (via Pluto 1.2) out to / plugins and start moving the Portlets into the actual modules/ configs that they administer Some other "grouping" that may make sense are - - core - renamed /server/modules directory promoted to a top-level grouping and only contains server modules - configs - current configs, which can be installed as plugins I'd really like to see the grouping of just configuration modules go away. I firmly believe that configuration modules should live right next to the code modules for which they are configuration for. - assemblies - current assemblies, which require the configs as input I'd like to see the main assembly configuration split off from the server/core/whatever stuff. Actually, I'd like to see the core/ framework as a sub-project, then have the server sub-project server only to configure the plugins to be pulled in and the assembly configurations for the javaee server distributions. --jason
Re: Trouble with 2.0.1 main pom and building anything a G dependency
IMO, we need to ween ourselves off of the local repository module completely... and avoid future use of any such local repository. When I (er we) did the main Maven 2 conversion I added some of these local modules as short-term work arounds to problems... there was no intention of leaving these in here for as long as they've been around. If we need to use some custom artifacts, then we really should publish them under an org.apache.geronimo.thirdparty groupId (or something) to the central repository and then treat them like normal dependencies. We can of course setup a thirdparty sub-project which has a local repository with the definitive source of the artifacts, but only use that puppy to manage those artifacts pom's and then publish them as we normally would anything else. This is... IMO... the *ONLY* solution to this problem, short of removing the need for these custom artifacts. --jason On Aug 30, 2007, at 3:05 PM, Jeff Genender wrote: Hi, I was building a 3rd party application with a dependency on the Geronimo specs (jee)...and I could not get it to build because it was looking for axis-saaj-1.3-r562247 For the life of me, I thought I had that usual maven corrupt repo issues and I wiped out my local repo...a number of times. I began looking through repos and sure enough it didn't exist. Well..I decided to look in our pom and I found: 1.3-r562247 Further discussion with others resulted in finding that we have a "special" repository that pulls these special versions. (Ok I forgot about that). This is going to be a problem for anyone who has a dependency on our jars (ie. wanting to use the specs jars for a web applications, etc). If I (a committer) had to go through this much trouble trying to figure out how to get that dependency...I can't imagine what the standard user will go through when writing a web or webservices application. The point I am making here is if we are going to have special versions of jars, we need to make these more readily available. Here are some options I thought of: A) Place the special jars in central so they are automatically available to others. (Easiest approach for the user - but we are going to have to convince other projects to put them out into their locations - that may prove difficult). B) Heavily, heavily document how to get around this problem by adding our repo to their pom. This should be easily Googled and placed in a FAQ, because I would hazard to guess this will be a frequent question. (probably the easiest approach for us, but this needs to be a short term solution - and its still a PITA for our users). C) Convince the other projects to get their releases in order and get good versions of their product on central. (Should do this regardless of any other option). D) Rename our special versions to g-axis-saaj-1.3-r562247 and house those under our own control (org.apache.geronimo...) in central on our next build (2.0.2). (The easy and quick, and very temprary fix!) Thoughts? Comments? Thanks, Jeff
Re: [Discuss] What next?
On Aug 30, 2007, at 5:12 PM, David Jencks wrote: Getting 2.0.1 out the door was a great step and now might be a good time to start discussing where we want geronimo to head next. Here are some ideas I've had or think are important. If I were to try to write actual sentences about all of this I'd probably never send the email so this is way too fragmentary but maybe can spark more discussion. I'm hoping everyone will chime in with their interests and viewpoints, this is just what I've been thinking about lately. Modularity. For a long time we've been on the brink of having an actually modular server, not just a conceptually modular server. As reflected in a lot of recent discussion on the dev list, I think we are so close we should really work hard to make this a pleasant reality. Some of the steps I see: - enhance the plugin framework so bits of more config files can be added, in particular artifact_aliases.properties and config_substitutions.properties. IIUC Paul has some schema changes and xml handling rewrites in the wings as well - finish up the pluggable admin console work and actually split the admin console into appropriate bits for the plugins - rearrange the build so it is organized by plugin - actually assemble the servers we ship using plugins, perhaps using gshell scripts - have more server-building tools. For instance, a "button" to push that spits out a server with just what is needed for a set of apps and nothing else. Yay... modularity is my friend... and enemy :-P More modular server means more build muck to assemble it :-P But IMO this is probably the most important feature (if you can call it that) which we need to implement to ensure the longevity and maintainability of Apache Geronimo. Clustering IIUC we have a lot of partial clustering solutions. For instance there's WADI, native tomcat clustering, a terracotta integration, and IIUC Jeff has been working on a clustering solution (my apologies if I left any out). I'd like to know where these efforts are in terms of actual functionality and reliability and what they can be extended to do. We also need some kind of cluster admin tools. Certainly a nice to have, and almost always on user's want to have list, though from past places I've worked we never have really made use (fully) of any application server's clustering facilities. I'd like to see this added, and I'm sure we will get it sooner rather than later, but I think that the modularity (and inevitable decoupling) work is vastly more important to the project (perhaps not users). Other apps roller jetspeed proximity etc It would be great to get "all popular apps" available as geronimo plugins. Ya, would be nice to get the main G distribution to a point where you can *easily* (as in my eyes are closed and I'm clicking the install some neat feature button) get a fully functional, kick ass, easy to use and admin server ;-) Management and troubleshooting ARM No LEG? Otherwise we discared it. server farm management (gshell?) This is definitely on my "in my head" roadmap for the shell, though we need those clustering bits first to give it something to work with. One thing we might want to add before then is some kind of reboot facility to the server, which is possible using the GShell launcher process. So a user can install some muck, tweak some configuration, then tell the server to reboot and basically pick up a pristine configuration and working environment. The same basic mechanism could be used to create a rollback configuration, or named configurations, etc. I've been working on simplifying the GShell framework for the past week, and will continue for a few more me thinks as I've been re- inspired by the positive feedback I've heard so far, as well as my renewed desire for GShell to rule the world and make me coffee in the morning. So expect to see some more GShell goodies on the way soon... Core Better Spring application management Investigate OSGI and figure out how it is different from what we are doing, what it can do better, and what is missing from it. Figure out an integration strategy whether it be "run OSGI as an application" or "replace the kernel with OSGI" Don't break stuff if we start using OSGI more :-) I think some investigate is defs in order here, though I'd really like to see the system split up into smaller manageable chunks before this is considered for implementation. I don't think that the current gbean framework is so inflexible to make that a non-option. So lets split up the server, learn from that exercise, keeping in mind how we can make it easier, require less code and perhaps even do more... then lets do it. I'd personally like to see us using annotations to define all those properties and operations and such on our components... I fricken love annotations. Figure out what to
