Re: Ubuntu Main Distribution
On Aug 6, 2008, at 8:36 PM, Kevan Miller wrote: On Aug 4, 2008, at 4:49 PM, Jacek Laskowski wrote: On Mon, Aug 4, 2008 at 2:06 AM, Kevan Miller [EMAIL PROTECTED] wrote: B) A maven build will access multiple, redundant, versions of the same artifact. We control the versions that will be included in our server assemblies. However, we don't really control the build-time dependencies that our build will require. Thus, the transitive dependencies accessed during a build may be much more than will actually be needed/used in the server assemblies. Is there some way we can help limit the number of artifacts which must be available during a build? Hi Kevan, Dave Blevins worked out a tool to limit the number of necessary deps in OpenEJB. I think it could be used in Geronimo as well. Hi Jacek, Thanks for the pointer. Perhaps David can comment on the possible utility of that tool. I'm not sure it would help. The tool simply creates a nested xml document representing the dependency graph making it easier to see where unwanted dependencies are getting pulled in so that the correct maven excludes can be added. I don't think we have any unwanted dependencies, so that might not be useful. I vaguely recall that some part of it reads in all the byte code for the given module and attempts to determine if there are any dependencies which aren't used -- at least not directly in code. That might be useful. -David
[BUILD] trunk: Failed for Revision: 683528
Geronimo Revision: 683528 built with tests included
See the full build-0300.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080807/build-0300.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080807
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 40 minutes 33 seconds
[INFO] Finished at: Thu Aug 07 03:50:02 EDT 2008
[INFO] Final Memory: 407M/899M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080807/logs-0300-tomcat/test.log
Assembly: jetty
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080807/logs-0300-jetty/test.log
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: jetty
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-jetty6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty6-javaee5/2.2-SNAPSHOT/geronimo-jetty6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:40.839
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 31 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:01.279)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:29.903)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:18.380)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:17.668)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:01:22.801) Java
returned: 1
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:51.586)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:44.069)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:49.823)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:45.739)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:31.464)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:29.054)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:30.302)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb
GEP and Java6
I have seen a number of problems with particularly new users running Geronimo with GEP, and having problems. They switch to Java 5, and things work for them. For GEP 2.1.2, which we want to get out ASAP now that G2.1.2 is released, I think GEP should detect Java 6 when a Geronimo server is defined, and warn the user of problems, and suggest they use Java 5. I am not clear on the Geronimo server's position on Java6. My understanding is that Geronimo is certified on Java 5, and will run on Java 6. We'll want GEP to support/work on Java6 ASAP. Perhaps we should have a task-list JIRA for Java 6 issues. Ted Kirby
Unable to download G runtime from Eclipse
HI, Trying to download the latest G V2.1.2 from my Eclipse workspace. These are the steps I follow 1) Downloaded the latest GEP source. 2) Build was successful. 3) Started another instance of Eclipse from my Eclipse workspace. 4) Adding a server runtime. 5) Clicked on Download and Install. 6) Got the license panel. Later I hit the following error. *org.eclipse.wst.server.core SEVERE07/08/08 17:57.57.531 Error installing feature org.eclipse.core.runtime.CoreException: Could not download and install update feature. at org.eclipse.wst.server.core.internal.InstallableRuntime.install(InstallableRuntime.java:260) at org.apache.geronimo.st.ui.internal.GeronimoRuntimeWizardFragment$1$2.run(GeronimoRuntimeWizardFragment.java:247) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) org.apache.geronimo.st.ui: Error installing runtime org.eclipse.core.runtime.CoreException: Error occurred installing server: Could not download and install update feature. at org.eclipse.wst.server.core.internal.InstallableRuntime.install(InstallableRuntime.java:271) at org.apache.geronimo.st.ui.internal.GeronimoRuntimeWizardFragment$1$2.run(GeronimoRuntimeWizardFragment.java:247) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) Caused by: org.eclipse.core.runtime.CoreException: Could not download and install update feature. at org.eclipse.wst.server.core.internal.InstallableRuntime.install(InstallableRuntime.java:260) ... 2 more * In my eclipse workspace .metadata/.log I have the followng error *!ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.406 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\.svn !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.406 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\bigG.gif !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.406 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\pom.xml !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.421 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\Thumbs.db *I also modified C:\gep_new\trunk\plugins\org.apache.geronimo.st.v21.core\plugin.xml as follows. This is the new staging site created by Tim. *extension point=org.eclipse.wst.server.core.installableRuntimes installableRuntime id=org.apache.geronimo.runtime.tomcat.21 featureVersion=2.1.2 featureId=org.apache.geronimo.server.tomcat.v21.feature featureSite= http://people.apache.org/~mcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/ path=geronimo-tomcat6-javaee5-2.1.2.zip /installableRuntime installableRuntime id=org.apache.geronimo.runtime.jetty.21 featureVersion=2.1.2 featureId=org.apache.geronimo.server.jetty.v21.feature featureSite= http://people.apache.org/~mcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/ path=geronimo-jetty6-javaee5-2.1.2.zip /installableRuntime /extension* I also created a new remote site in my Eclipse workspace which is same as the staging site(* http://people.apache.org/~mcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/ )* I am using Eclipse Ganymede however I hit the same error when I use Europa. I am using sun java 1.5.0_13 This error is somehow stopping me to work on GERONIMODEVTOOLS-325 wherein I need to recreate a error as pointed by Tim Please help!!! Thanks Ashish
[jira] Updated: (GERONIMO-4228) install plugin from deploy tool doesn't honor load=false
[ https://issues.apache.org/jira/browse/GERONIMO-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-4228: --- Patch Info: [Patch Available] install plugin from deploy tool doesn't honor load=false -- Key: GERONIMO-4228 URL: https://issues.apache.org/jira/browse/GERONIMO-4228 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1.1, 2.1.2, 2.1.3, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.3, 2.2 Attachments: G4228.patch When I configure my plugin to be not loaded, (see below in geronimo-plugin.xml) the deploy install-plugin command ignores it and still attempt to start the module: config-xml-content load=false/ This is an issue for app client, which we dont want to start in the server container. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4228) install plugin from deploy tool doesn't honor load=false
[ https://issues.apache.org/jira/browse/GERONIMO-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-4228: --- Fix Version/s: 2.1.3 Looks okay to me. Fix also needs to go into the 2.1 branch. install plugin from deploy tool doesn't honor load=false -- Key: GERONIMO-4228 URL: https://issues.apache.org/jira/browse/GERONIMO-4228 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1.1, 2.1.2, 2.1.3, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.3, 2.2 Attachments: G4228.patch When I configure my plugin to be not loaded, (see below in geronimo-plugin.xml) the deploy install-plugin command ignores it and still attempt to start the module: config-xml-content load=false/ This is an issue for app client, which we dont want to start in the server container. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-464) GEP build with clean M2 local repo
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620615#action_12620615 ] Donald Woods commented on GERONIMODEVTOOLS-464: --- This is also needed for the Samples subproject, as it also needs the private server artifacts under the server's repository directory. I think it's time we create a geronimo/repo branch in our SVN to hold these artifacts, given they are needed in 3 builds now (and possibly other geronimo/plugin builds.) GEP build with clean M2 local repo -- Key: GERONIMODEVTOOLS-464 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-464 Project: Geronimo-Devtools Issue Type: Sub-task Reporter: Tim McConnell Assignee: Tim McConnell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[DISCUSS] Time to create a geronimo/repo branch in svn for private depends
We have danced around the problem of not being able to build Samples, Plugins or GEP from a clean m2 repo without building the Server's repository subdir for long enough. I believe it is time to create the following location in SVN - geronimo/repo Which would hold our private patched artifacts of other projects (like Tomcat, Pluto, ...), just like the OpenEJB team has done for some of their private depends. I don't see this as a major hit to the svn infrastructure, given the jars (10 for 2.2.) will only be downloaded when starting with a clean m2 repo or when we publish any updated depends. Unless someone comes up with a better solution by Friday morning, I'll create the new repo branch and populate it with the latest 2.1.2 and 2.2 patched artifacts tomorrow. -Donald smime.p7s Description: S/MIME Cryptographic Signature
[jira] Created: (GERONIMODEVTOOLS-465) The 'Eclipse-LazyStart' header is deprecated, use 'Bundle-ActivationPolicy'
The 'Eclipse-LazyStart' header is deprecated, use 'Bundle-ActivationPolicy' --- Key: GERONIMODEVTOOLS-465 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-465 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.2 Reporter: Jacek Laskowski Assignee: Tim McConnell MANIFEST.MF from org.apache.geronimo.st.core plugin (and possibly others) uses Eclipse-LazyStart which is deprecated and OSGi's 'Bundle-ActivationPolicy' is recommended. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-461) Documentation updates
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620629#action_12620629 ] Ashish Jain commented on GERONIMODEVTOOLS-461: -- I wish to modify this for 2.1.x. Documentation updates - Key: GERONIMODEVTOOLS-461 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-461 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.2 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.2 These tutorials below need to be updated once GEP 2.1.2 is released: (X) http://cwiki.apache.org/GMOxDOC21/web-application-for-ejb-access.html (X) http://cwiki.apache.org/GMOxDOC21/quick-start-fast-and-easy-development.html (X) http://cwiki.apache.org/GMOxDOC21/development-environment.html#Developmentenvironment-InstallingEclipse (X) http://geronimo.apache.org/developing-the-geronimo-eclipse-plugin-in-eclipse.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Unable to download G runtime from Eclipse
Download and Install is very touchy. I have mostly never been able to get it to work when launching the plugin from eclipse, as you are doing. It worked for me for a little while when I first started working with Ganymede, but then stopped. I've pretty much had to give up on developing it this way. :-( So, you'll have to build the plugin, and install it via the eclipse update manager. :-( Ted Kirby On Thu, Aug 7, 2008 at 8:42 AM, Ashish Jain [EMAIL PROTECTED] wrote: HI, Trying to download the latest G V2.1.2 from my Eclipse workspace. These are the steps I follow 1) Downloaded the latest GEP source. 2) Build was successful. 3) Started another instance of Eclipse from my Eclipse workspace. 4) Adding a server runtime. 5) Clicked on Download and Install. 6) Got the license panel. Later I hit the following error. org.eclipse.wst.server.core SEVERE07/08/08 17:57.57.531 Error installing feature org.eclipse.core.runtime.CoreException: Could not download and install update feature. at org.eclipse.wst.server.core.internal.InstallableRuntime.install(InstallableRuntime.java:260) at org.apache.geronimo.st.ui.internal.GeronimoRuntimeWizardFragment$1$2.run(GeronimoRuntimeWizardFragment.java:247) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) org.apache.geronimo.st.ui: Error installing runtime org.eclipse.core.runtime.CoreException: Error occurred installing server: Could not download and install update feature. at org.eclipse.wst.server.core.internal.InstallableRuntime.install(InstallableRuntime.java:271) at org.apache.geronimo.st.ui.internal.GeronimoRuntimeWizardFragment$1$2.run(GeronimoRuntimeWizardFragment.java:247) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) Caused by: org.eclipse.core.runtime.CoreException: Could not download and install update feature. at org.eclipse.wst.server.core.internal.InstallableRuntime.install(InstallableRuntime.java:260) ... 2 more In my eclipse workspace .metadata/.log I have the followng error !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.406 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\.svn !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.406 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\bigG.gif !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.406 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\pom.xml !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.421 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\Thumbs.db I also modified C:\gep_new\trunk\plugins\org.apache.geronimo.st.v21.core\plugin.xml as follows. This is the new staging site created by Tim. extension point=org.eclipse.wst.server.core.installableRuntimes installableRuntime id=org.apache.geronimo.runtime.tomcat.21 featureVersion=2.1.2 featureId=org.apache.geronimo.server.tomcat.v21.feature featureSite=http://people.apache.org/~mcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/; path=geronimo-tomcat6-javaee5-2.1.2.zip /installableRuntime installableRuntime id=org.apache.geronimo.runtime.jetty.21 featureVersion=2.1.2 featureId=org.apache.geronimo.server.jetty.v21.feature featureSite=http://people.apache.org/~mcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/; path=geronimo-jetty6-javaee5-2.1.2.zip /installableRuntime /extension I also created a new remote site in my Eclipse workspace which is same as the staging site(http://people.apache.org/~mcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/) I am using Eclipse Ganymede however I hit the same error when I use Europa. I am using sun java 1.5.0_13 This error is somehow stopping me to work on GERONIMODEVTOOLS-325 wherein I need to recreate a error as pointed by Tim Please help!!! Thanks Ashish
[jira] Updated: (GERONIMODEVTOOLS-409) Upgrade GEP to support Java 1.6
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-409: --- Affects Version/s: 2.1.3 Fix Version/s: (was: 2.2.0) 2.1.3 Upgrade GEP to support Java 1.6 --- Key: GERONIMODEVTOOLS-409 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-409 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.3 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-421) Synchronize GEP trunk with the 2.1.2 version of the Geronimo server
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620631#action_12620631 ] Ashish Jain commented on GERONIMODEVTOOLS-421: -- Other than modifying the version of G from 2.1.2-snapshot what are other changes that are required on this. Just CO the latest source and it seems there are no snapshots available other than 2.2-snapshots which is acceptable I guess. Synchronize GEP trunk with the 2.1.2 version of the Geronimo server --- Key: GERONIMODEVTOOLS-421 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-421 Project: Geronimo-Devtools Issue Type: Bug Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Unable to download G runtime from Eclipse
Hi Ted, Thanks for your reply! Yes you are correct it works fine once you have installed it through Eclipse update manager. Somehow it worked for Tim day before yesterday. May be he can suggest something. Thanks Ashish On Thu, Aug 7, 2008 at 7:46 PM, Ted Kirby [EMAIL PROTECTED] wrote: Download and Install is very touchy. I have mostly never been able to get it to work when launching the plugin from eclipse, as you are doing. It worked for me for a little while when I first started working with Ganymede, but then stopped. I've pretty much had to give up on developing it this way. :-( So, you'll have to build the plugin, and install it via the eclipse update manager. :-( Ted Kirby On Thu, Aug 7, 2008 at 8:42 AM, Ashish Jain [EMAIL PROTECTED] wrote: HI, Trying to download the latest G V2.1.2 from my Eclipse workspace. These are the steps I follow 1) Downloaded the latest GEP source. 2) Build was successful. 3) Started another instance of Eclipse from my Eclipse workspace. 4) Adding a server runtime. 5) Clicked on Download and Install. 6) Got the license panel. Later I hit the following error. org.eclipse.wst.server.core SEVERE07/08/08 17:57.57.531 Error installing feature org.eclipse.core.runtime.CoreException: Could not download and install update feature. at org.eclipse.wst.server.core.internal.InstallableRuntime.install(InstallableRuntime.java:260) at org.apache.geronimo.st.ui.internal.GeronimoRuntimeWizardFragment$1$2.run(GeronimoRuntimeWizardFragment.java:247) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) org.apache.geronimo.st.ui: Error installing runtime org.eclipse.core.runtime.CoreException: Error occurred installing server: Could not download and install update feature. at org.eclipse.wst.server.core.internal.InstallableRuntime.install(InstallableRuntime.java:271) at org.apache.geronimo.st.ui.internal.GeronimoRuntimeWizardFragment$1$2.run(GeronimoRuntimeWizardFragment.java:247) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) Caused by: org.eclipse.core.runtime.CoreException: Could not download and install update feature. at org.eclipse.wst.server.core.internal.InstallableRuntime.install(InstallableRuntime.java:260) ... 2 more In my eclipse workspace .metadata/.log I have the followng error !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.406 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\.svn !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.406 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\bigG.gif !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.406 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\pom.xml !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.421 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\Thumbs.db I also modified C:\gep_new\trunk\plugins\org.apache.geronimo.st.v21.core\plugin.xml as follows. This is the new staging site created by Tim. extension point=org.eclipse.wst.server.core.installableRuntimes installableRuntime id=org.apache.geronimo.runtime.tomcat.21 featureVersion=2.1.2 featureId=org.apache.geronimo.server.tomcat.v21.feature featureSite= http://people.apache.org/~mcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/http://people.apache.org/%7Emcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/ path=geronimo-tomcat6-javaee5-2.1.2.zip /installableRuntime installableRuntime id=org.apache.geronimo.runtime.jetty.21 featureVersion=2.1.2 featureId=org.apache.geronimo.server.jetty.v21.feature featureSite= http://people.apache.org/~mcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/http://people.apache.org/%7Emcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/ path=geronimo-jetty6-javaee5-2.1.2.zip /installableRuntime /extension I also created a new remote site in my Eclipse workspace which is same as the staging site( http://people.apache.org/~mcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/http://people.apache.org/%7Emcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/ ) I am using Eclipse Ganymede however I hit the same error when I use Europa. I am using sun java 1.5.0_13 This error is somehow stopping me to work on GERONIMODEVTOOLS-325 wherein I need to recreate a error as pointed by Tim Please help!!! Thanks Ashish
Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
+1 I like it because we don't need to ask the users to install the private repo first. Lin On Thu, Aug 7, 2008 at 9:13 AM, Donald Woods [EMAIL PROTECTED] wrote: We have danced around the problem of not being able to build Samples, Plugins or GEP from a clean m2 repo without building the Server's repository subdir for long enough. I believe it is time to create the following location in SVN - geronimo/repo Which would hold our private patched artifacts of other projects (like Tomcat, Pluto, ...), just like the OpenEJB team has done for some of their private depends. I don't see this as a major hit to the svn infrastructure, given the jars (10 for 2.2.) will only be downloaded when starting with a clean m2 repo or when we publish any updated depends. Unless someone comes up with a better solution by Friday morning, I'll create the new repo branch and populate it with the latest 2.1.2 and 2.2 patched artifacts tomorrow. -Donald
Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
+1 Donald Woods wrote: We have danced around the problem of not being able to build Samples, Plugins or GEP from a clean m2 repo without building the Server's repository subdir for long enough. I believe it is time to create the following location in SVN - geronimo/repo Which would hold our private patched artifacts of other projects (like Tomcat, Pluto, ...), just like the OpenEJB team has done for some of their private depends. I don't see this as a major hit to the svn infrastructure, given the jars (10 for 2.2.) will only be downloaded when starting with a clean m2 repo or when we publish any updated depends. Unless someone comes up with a better solution by Friday morning, I'll create the new repo branch and populate it with the latest 2.1.2 and 2.2 patched artifacts tomorrow. -Donald -- Thanks, Tim McConnell
Re: Unable to download G runtime from Eclipse
Hi Ashish, it only worked for me the other day because I had first downloaded the GEP plugin via the Update Manager. It won't work correctly if you. Your scenario is only slightly different than the one we warned against in the following documentation. I investigated this problem back in 2.1.0 and have a very long writeup for why it won't work (which I'll try to find again). But for now, if you plan to use the Download and Install feature of the GEP just ensure you use the Update Manager first to download the plugin. Thanks. --- http://geronimo.apache.org/developing-the-geronimo-eclipse-plugin-in-eclipse.html Ashish Jain wrote: Hi Ted, Thanks for your reply! Yes you are correct it works fine once you have installed it through Eclipse update manager. Somehow it worked for Tim day before yesterday. May be he can suggest something. Thanks Ashish On Thu, Aug 7, 2008 at 7:46 PM, Ted Kirby [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Download and Install is very touchy. I have mostly never been able to get it to work when launching the plugin from eclipse, as you are doing. It worked for me for a little while when I first started working with Ganymede, but then stopped. I've pretty much had to give up on developing it this way. :-( So, you'll have to build the plugin, and install it via the eclipse update manager. :-( Ted Kirby On Thu, Aug 7, 2008 at 8:42 AM, Ashish Jain [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: HI, Trying to download the latest G V2.1.2 from my Eclipse workspace. These are the steps I follow 1) Downloaded the latest GEP source. 2) Build was successful. 3) Started another instance of Eclipse from my Eclipse workspace. 4) Adding a server runtime. 5) Clicked on Download and Install. 6) Got the license panel. Later I hit the following error. org.eclipse.wst.server.core SEVERE07/08/08 17:57.57.531 Error installing feature org.eclipse.core.runtime.CoreException: Could not download and install update feature. at org.eclipse.wst.server.core.internal.InstallableRuntime.install(InstallableRuntime.java:260) at org.apache.geronimo.st.ui.internal.GeronimoRuntimeWizardFragment$1$2.run(GeronimoRuntimeWizardFragment.java:247) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) org.apache.geronimo.st.ui: Error installing runtime org.eclipse.core.runtime.CoreException: Error occurred installing server: Could not download and install update feature. at org.eclipse.wst.server.core.internal.InstallableRuntime.install(InstallableRuntime.java:271) at org.apache.geronimo.st.ui.internal.GeronimoRuntimeWizardFragment$1$2.run(GeronimoRuntimeWizardFragment.java:247) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) Caused by: org.eclipse.core.runtime.CoreException: Could not download and install update feature. at org.eclipse.wst.server.core.internal.InstallableRuntime.install(InstallableRuntime.java:260) ... 2 more In my eclipse workspace .metadata/.log I have the followng error !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.406 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\.svn !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.406 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\bigG.gif !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.406 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\pom.xml !ENTRY org.eclipse.update.configurator 4 0 2008-08-07 17:56:45.421 !MESSAGE Unable to find feature.xml in directory: C:\gep_new\trunk\features\Thumbs.db I also modified C:\gep_new\trunk\plugins\org.apache.geronimo.st.v21.core\plugin.xml as follows. This is the new staging site created by Tim. extension point=org.eclipse.wst.server.core.installableRuntimes installableRuntime id=org.apache.geronimo.runtime.tomcat.21 featureVersion=2.1.2 featureId=org.apache.geronimo.server.tomcat.v21.feature featureSite=http://people.apache.org/~mcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/ http://people.apache.org/%7Emcconne/releases/2.1.2/RC1/staging_site/eclipse/updates/ path=geronimo-tomcat6-javaee5-2.1.2.zip /installableRuntime installableRuntime id=org.apache.geronimo.runtime.jetty.21 featureVersion=2.1.2
[jira] Closed: (GERONIMO-4228) install plugin from deploy tool doesn't honor load=false
[ https://issues.apache.org/jira/browse/GERONIMO-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun closed GERONIMO-4228. - install plugin from deploy tool doesn't honor load=false -- Key: GERONIMO-4228 URL: https://issues.apache.org/jira/browse/GERONIMO-4228 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1.1, 2.1.2, 2.1.3, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.3, 2.2 Attachments: G4228.patch When I configure my plugin to be not loaded, (see below in geronimo-plugin.xml) the deploy install-plugin command ignores it and still attempt to start the module: config-xml-content load=false/ This is an issue for app client, which we dont want to start in the server container. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4228) install plugin from deploy tool doesn't honor load=false
[ https://issues.apache.org/jira/browse/GERONIMO-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4228. --- Resolution: Fixed Patch committed (see subversion tab). Thanks Donald for reviewing it. Tested this with daytrader-tomcat, daytrader-ws-client and daytrader-streamer-client module. Lin install plugin from deploy tool doesn't honor load=false -- Key: GERONIMO-4228 URL: https://issues.apache.org/jira/browse/GERONIMO-4228 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1.1, 2.1.2, 2.1.3, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.3, 2.2 Attachments: G4228.patch When I configure my plugin to be not loaded, (see below in geronimo-plugin.xml) the deploy install-plugin command ignores it and still attempt to start the module: config-xml-content load=false/ This is an issue for app client, which we dont want to start in the server container. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Documentation of new 2.2 features in current wiki?
I agree in principle with creating a new location for 2.2 features to be documented. My only concern was that we are consistent so that the documentation will be easy for users to find and easy to integrate when we eventually do a mass merge from 2.1 to 2.2. So, I created a new space for 2.2 documentation to provide a consistent structure and to capture the enthusiasm to document 2.2 changes. I seeded it with a top level structure that matches our 2.1 doc but no actual content. You can find it here: http://cwiki.apache.org/GMOxDOC22/documentation.html I suggest that we create new content for 2.2 under this page for now: http://cwiki.apache.org/GMOxDOC22/what-changed-in-22.html I chose the current name to match what we had in 2.1. If a particular change has broad implications for documentation that is already available in 2.1, we can copy current 2.1 content into 2.2 and modify it accordingly. As David pointed out earlier, we do not have the ability to automatically merge the 2.1 content into the 2.2 content at a later time using this approach. Any merge will be a manual effort. The only alternative I am aware of would be to seed the new 2.2 space with the complete current 2.1 content. However, that brings about some maintenance issues of keeping things in sync and doesn't encourage 2.2 updates. When we last discussed this for 2.1 we decided to start with the empty space and so I took the same approach for this release. I hope this provides something that will serve as a good place for the 2.2 content for now. If we decide later that we should have started with a complete copy of 2.1 we can always create a copy and merge the new 2.2 documents back into the 2.1 copy. However, for now this at least provides a place we can use and it is obvious to our users where they can find 2.2 documentation. Joe Donald Woods wrote: Agree. We could just create a New Features in 2.2 page and people can create child pages to it for their new features as they are integrated into trunk -Donald Jarek Gawor wrote: I think it would be nicer to create pages with 2.2 specific content somewhere under http://cwiki.apache.org/GMOxDEV/index.html for now. Once we have 2.2 documentation space setup we can move the pages around. Or at least I don't think we should mix 2.2 content with 2.1 content. Jarek On Tue, Jul 29, 2008 at 1:52 PM, David Jencks [EMAIL PROTECTED] wrote: I've been playing around with openid and jaspi and would like to write up some documentation before I forget how it all works :-) I don't think we have enough people interested in documentation to pursue anything but the easiest-to-write path in documentation. In particular I think more than one active copy of the docs is asking for disaster. I'd like to suggest that feature documentation should generally start with a starting with version xxx comment. So, I'd put the openid/jaspi documentation in the current (2.1) wiki with a starting with 2.2 notice. Obviously there's the problem that the wiki has the 2.1 version in its name. I don't know if a wiki can have its name changed but don't regard this as critical. I'm going to start doing this pending comments and better ideas. At the rate I write I don't think I'll be causing significant damage before we have time for a full discussion :-) thanks david jencks
Re: Reducing the dojo footprint in Geronimo
I may be misunderstanding what your proposing, Donald, but I'm not sure if this suggestion would actually decrease the dojo footprint at all. From my understanding, the monitoring plugin that is included in the EE servers requires a dojox feature (charting). This would mean that the monitoring plugin would pull the dojo-full plugin into the EE server resulting in no actual decrease in dojo footprint. This idea would be nifty for custom server images, but my understanding was that this discussion was in relation to the EE distributions. I still like the idea, I'm just not sure it's going to accomplish what Shrey was suggesting. I'm inclined to side with Donald's idea, even though I don't think it will decrease the EE server's dojo footprint. It provides users who are building custom assemblies the option to include dojo easily in their server without worrying about dojox components they might have no intention of using. On Mon, Aug 4, 2008 at 10:59 AM, Donald Woods [EMAIL PROTECTED] wrote: What about a combination of #2 and #3 - We create a dojo-minimal (no dojox support) and dojo-full plugin under geronimo/plugins and only the console modules that need it pull in the dojo-minimal, while user apps or samples can pull in dojo-full if needed. -Donald Joseph Leong wrote: Hi everyone, So i'm building a little widget piece to run on AG and i've come to the point of deciding whether i'm going to incorporate any (if) dojo/dojox components into it. I know we've had varying discussions about reducing the dojo footprint. To summarize i believe the only thing we've agreed on so far is removing the unncessary /tests , but i'm wondering if the community had anymore input on keeping dojox around? To summarize it is my understanding these are the choices suggested so far: 1) Removing Dojo from AG and having users include their own optimized Dojo files for their apps. The downside is that we may be inefficient in aggregating multiple copies of Dojo. 2) Leave Dojo support in AG as is now. We can safely rely on the fact that their will be no duplicate instances of dojo for those who use it, but we must now rely on having that dojo overhead even for users who don't utilize it. 3) Creating a slim version of Dojo to support the features relying on it in AG, thus allowing users who want to demonstrate fundamental dojo features to utilize it - but however we incur the maintenance overhead of creating new builds of Dojo to incorporate with AG releases as new fundamental AG components with Dojo are included. Personally, I feel the functionality subset of DojoX captures a lot of what this Web2.0 era is looking for. Although it may make more sense to go with option 3, now, i feel it's only a matter of time before we switch over to option 2. To provide the community with a better grasp of what the DojoX functionalities are goto: http://dojocampus.org/explorer/#Dojox and you'll find yourself quite surprised at how innovative and integrated these technologies are influencing your favorite sites. Thanks, -Joseph Leong On Mon, Jun 30, 2008 at 7:29 AM, Shiva Kumar H R [EMAIL PROTECTED]mailto: [EMAIL PROTECTED] wrote: On Sat, Jun 28, 2008 at 12:04 AM, Donald Woods [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Sounds like the right solution, given that would allow our console to upgrade at a slower pace and would allow users to choose their own level... Other option, is to drop the /dojo webapp in 2.2, only ship what we need in the console and let users package the Dojo level and features they need within their own apps (which is more portable across different servers anyway) On http://cwiki.apache.org/GMOxDEV/using-dojo-in-geronimo.html we say: AJAX developers usually incorporate the Dojo library into their applications by making a copy of its static files (javascript, css, gifs, etc) in their webapp and referencing those files from their servlets and JSPs. The downside of this approach is that each application has a separate copy of the AJAX library, increasing the server's overall footprint and preventing browsers from using a single copy of the library files from their caches. Another downside is that the AJAX library can't be upgraded or otherwise managed independently from the web applications that contain it. For example, a web application deployed across a cluster might need to serve up the static Dojo files from a central location. Hosting the Dojo files in a separate webapp can help work around these problems. So asking users to package the Dojo level and features they need within their own apps would imply the downsides mentioned above. Providing an installable dojo plugin that's equivalent to the /dojo support we currently provide as suggested by Kevan seems to be an excellent alternative. -Donald
[jira] Resolved: (GERONIMODEVTOOLS-421) Synchronize GEP trunk with the 2.1.2 version of the Geronimo server
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell resolved GERONIMODEVTOOLS-421. Resolution: Fixed HI Ashish, actually I think that's all. It seems to be working and downloading the 2.1.2 server as expected.. Synchronize GEP trunk with the 2.1.2 version of the Geronimo server --- Key: GERONIMODEVTOOLS-421 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-421 Project: Geronimo-Devtools Issue Type: Bug Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4230) When installing a plugin that is already existed, we still give people confusing missingDependency message
When installing a plugin that is already existed, we still give people confusing missingDependency message -- Key: GERONIMO-4230 URL: https://issues.apache.org/jira/browse/GERONIMO-4230 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Plugins Affects Versions: 2.1.2, 2.1.3, 2.2 Reporter: Lin Sun Assignee: Lin Sun Priority: Minor Fix For: 2.2 For example, when I install the daytrader-streamer-client onto my server without knowing the module is already installed, the deployer gave me the following message: lin-suns-macbook-pro:bin linsun$ java install-plugin ~/daytrader/daytrader-tomcat/target/daytrader-streamer-client-2.2-SNAPSHOT.car Listening for transport dt_socket at address: 8011 Checking for status every 1000ms: Installation FAILED: Configuration org.apache.geronimo.daytrader/daytrader-streamer-client/2.2-SNAPSHOT/car is already installed. Missing dependency: org.apache.geronimo.daytrader/daytrader-streamer-client/2.2-SNAPSHOT/car The Missing Dependency message is rather confusing and should be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-461) Documentation updates
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-461: --- Assignee: Ashish Jain (was: Tim McConnell) Thanks Ashish, I'll assign to you Documentation updates - Key: GERONIMODEVTOOLS-461 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-461 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.2 Reporter: Tim McConnell Assignee: Ashish Jain Fix For: 2.1.2 These tutorials below need to be updated once GEP 2.1.2 is released: (X) http://cwiki.apache.org/GMOxDOC21/web-application-for-ejb-access.html (X) http://cwiki.apache.org/GMOxDOC21/quick-start-fast-and-easy-development.html (X) http://cwiki.apache.org/GMOxDOC21/development-environment.html#Developmentenvironment-InstallingEclipse (X) http://geronimo.apache.org/developing-the-geronimo-eclipse-plugin-in-eclipse.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Documentation of new 2.2 features in current wiki?
Hi Rebekah, I just posted a note about a new space that I created for the 2.2 documentation. The new space was really created just to get things moving for 2.2. It was not a statement of what the final structure should be ... so please feel free to continue to explore this area and receive comments. I personally haven't had a chance to consider the alternatives you presented below. However, my inclination is to keep the current structure as is unless there are obvious problems with the organization and there are resources willing to invest the time and effort to change things. Can you provide some more information on what is driving the changes that you are proposing? Thanks, Joe wei zhang wrote: Hi there, This is Rebekah and I've been reading through the documentation with my colleagues for a while. I think we can keep the current version of the documentation and create another space for v2.2, because there will be users who may want to track the previous information. Regarding the organization of information, we have worked out new documentation structures based on the 2.1 info using two different appraches: one is pretty much book based, keeping some of the current lookfeel; the other is info center based. If we are going to create a new space for v2.2, we can take either approach. As long as the structure is ready, people can take topics they are interested in and write up the content. If you have any ideas or comments on the proposed structures, feel free to let me know. Thanks. Information center based approach (all in one): 0 Geronimo information 1 What's new 1.1 New features 1.1.1 Custom server assemblies 1.1.2 Geronimo administration console 1.1.3 GShell 1.1.4 Clustering 1.1.5 Monitoring console plugin 1.1.6 Plan Creator 1.2 Enhanced features 1.2.1 Geronimo distributions 1.2.2 Configuration changes 1.3 Compatibility with earlier versions 2 Getting started with Apache Geronimo 2.1 Getting the software 2.1.1 Geronimo directory structure 2.2 Starting the server 2.3 Creating and deploying a sample application 3 Planning and installing 3.1 Installing prerequisite software 3.2 Getting Geronimo 3.2.1 Building Geronimo from source 3.2.1.1 http://3.2.1.1 Building Geronimo with Maven 3.2.1.2 http://3.2.1.2 Building Geronimo from Eclipse 3.3 Installing Geronimo 3.3.1 Installing Geronimo from binaries 3.4 Initial configuration 3.4.1 Available configuration files 3.4.2 Changing the default port numbers 3.4.3 Changing the username and password 3.5 Starting and stopping the server 3.5.1 Starting and Stopping Geronimo in GShell 3.6 Running Geronimo as a non-root user 3.7 Running multiple Geronimo instances 3.8 Running Geronimo as a Windows, or UINX service 4 Configuring and administering 4.1 Deploying and and administering assets in Geronimo 4.1.1 Deploying assets 4.1.1.1 http://4.1.1.1 Deploying assets via the administration console 4.1.1.2 http://4.1.1.2 Deploying assets from the command prompt 4.1.1.3 http://4.1.1.3 Deploying assets via GShell 4.1.1.4 http://4.1.1.4 Performing clustered deployment 4.1.1.5 http://4.1.1.5 Deploying plugins 4.1.1.6 http://4.1.1.6 Performing hot deployment 4.1.2 Administering applications 4.1.2.1 http://4.1.2.1 Installing and removing applications 4.1.2.2 http://4.1.2.2 Starting and stopping application modules 4.2 Configuring and administering the Apache Geronimo Server 4.2.1 Administering Geronimo using the Geronimo administration console 4.2.2 Administering Geronimo using command line tools 4.2.3 Add new listeners for Web containers 4.2.4 Aliasing modules 4.2.5 Configuring virtual host 4.2.5.1 http://4.2.5.1 Configuring virtual host in Jetty 4.2.5.2 http://4.2.5.2 Configuring virtual host in Tomcat 4.2.6 Configuring a remote Apache HTTP server 4.2.7 Configuring JAX-WS engine 4.2.8 Clustering 4.2.8.1 http://4.2.8.1 Farming 4.2.8.2 http://4.2.8.2 WADI clustering 4.2.9 Custom server assemblies 4.2.9.1 http://4.2.9.1 Plugin basics 4.2.9.2 http://4.2.9.2 Buidling,installing plugins and extracting a server from an exsiting server 4.2.9.3 http://4.2.9.3 Assembling a server using Maven 4.3 Congifuring services 4.3.1 Configuring multiple repositories 4.3.2 Adding archives to the Geronimo repository 4.3.3 Configuring database pools 4.3.4 Configuring JMS 4.4 Administering security 4.4.1 Basic Hints on Security Configuration 4.4.2 Configuring JavaEE application client security 4.4.3 Configuring login modules 4.4.4 Configuring run-as and Default Subjects, and
[jira] Updated: (GERONIMODEVTOOLS-433) GEP 2.1.2 Tasklist for Ganymede-specific problems
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-433: --- Summary: GEP 2.1.2 Tasklist for Ganymede-specific problems (was: GEP 2.1.2 Ganymede-specific problems:) GEP 2.1.2 Tasklist for Ganymede-specific problems -- Key: GERONIMODEVTOOLS-433 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-433 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.2 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-433) Tasklist for Ganymede-specific problems
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-433: --- Summary: Tasklist for Ganymede-specific problems (was: GEP 2.1.2 Tasklist for Ganymede-specific problems ) Tasklist for Ganymede-specific problems Key: GERONIMODEVTOOLS-433 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-433 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.2 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
Donald Woods wrote: We have danced around the problem of not being able to build Samples, Plugins or GEP from a clean m2 repo without building the Server's repository subdir for long enough. I believe it is time to create the following location in SVN - geronimo/repo Which would hold our private patched artifacts of other projects (like Tomcat, Pluto, ...), just like the OpenEJB team has done for some of their private depends. I don't see this as a major hit to the svn infrastructure, given the jars (10 for 2.2.) will only be downloaded when starting with a clean m2 repo or when we publish any updated depends. Can you provide some more details on how this would work? Would you require that the users checkout geronimo/repo rather than geronimo/server/repo and perform a build to get the artifacts into the local maven repo? If that is the case, then I don't see any benefit and it will in fact add an extra step to the Geronimo build process. I must not be understanding your proposal. Joe Unless someone comes up with a better solution by Friday morning, I'll create the new repo branch and populate it with the latest 2.1.2 and 2.2 patched artifacts tomorrow. -Donald
[jira] Created: (GERONIMODEVTOOLS-466) Taskslist for Java 6 specific problems
Taskslist for Java 6 specific problems -- Key: GERONIMODEVTOOLS-466 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-466 Project: Geronimo-Devtools Issue Type: Task Affects Versions: 2.1.2 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
Maybe I'm missing something, but aren't these artifacts already in svn under ../repository, e.g. http://svn.apache.org/repos/asf/geronimo/server/branches/2.1/repository/ (for the given release)? Are you proposing one main location for all version of the artifacts for all versions of Geronimo? Will that svn location be added to the repositories list in pom.xml? What I'm concerned about is that if we add that svn location to the repositories list, maven might pick that svn repository as the first repository to check for any artifacts and therefore you will get a lot more hits to that svn repository. I don't know if there is a way to tell maven to check a given repository last or only use it for specific artifacts/versions. Jarek On Thu, Aug 7, 2008 at 9:13 AM, Donald Woods [EMAIL PROTECTED] wrote: We have danced around the problem of not being able to build Samples, Plugins or GEP from a clean m2 repo without building the Server's repository subdir for long enough. I believe it is time to create the following location in SVN - geronimo/repo Which would hold our private patched artifacts of other projects (like Tomcat, Pluto, ...), just like the OpenEJB team has done for some of their private depends. I don't see this as a major hit to the svn infrastructure, given the jars (10 for 2.2.) will only be downloaded when starting with a clean m2 repo or when we publish any updated depends. Unless someone comes up with a better solution by Friday morning, I'll create the new repo branch and populate it with the latest 2.1.2 and 2.2 patched artifacts tomorrow. -Donald
Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
+1 quite useful Lin Sun wrote: +1 I like it because we don't need to ask the users to install the private repo first. On Thu, Aug 7, 2008 at 9:13 AM, Donald Woods [EMAIL PROTECTED] wrote: We have danced around the problem of not being able to build Samples, Plugins or GEP from a clean m2 repo without building the Server's repository subdir for long enough. I believe it is time to create the following location in SVN - geronimo/repo Which would hold our private patched artifacts of other projects (like Tomcat, Pluto, ...), just like the OpenEJB team has done for some of their private depends. I don't see this as a major hit to the svn infrastructure, given the jars (10 for 2.2.) will only be downloaded when starting with a clean m2 repo or when we publish any updated depends. Unless someone comes up with a better solution by Friday morning, I'll create the new repo branch and populate it with the latest 2.1.2 and 2.2 patched artifacts tomorrow. -- Thanks, Dan Becker
[jira] Updated: (GERONIMODEVTOOLS-466) Tasklist for Java 6 specific problems
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-466: --- Summary: Tasklist for Java 6 specific problems (was: Taskslist for Java 6 specific problems) Tasklist for Java 6 specific problems - Key: GERONIMODEVTOOLS-466 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-466 Project: Geronimo-Devtools Issue Type: Task Affects Versions: 2.1.2 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GEP and Java6
Hi Ted, good ideas. Actually the GEP already has that type of warning
message.
jvmWarning={0} is currently only certified on a 1.5 JVM. Use of any other version
is not currently supported.
Also, I've opened a task-list JIRA for Java 6 specific problems as you suggest.
Could you subtasks for the problem(s) you already know about ?? Thanks
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-466
Ted Kirby wrote:
I have seen a number of problems with particularly new users running
Geronimo with GEP, and having problems. They switch to Java 5, and
things work for them. For GEP 2.1.2, which we want to get out ASAP
now that G2.1.2 is released, I think GEP should detect Java 6 when a
Geronimo server is defined, and warn the user of problems, and suggest
they use Java 5. I am not clear on the Geronimo server's position on
Java6. My understanding is that Geronimo is certified on Java 5, and
will run on Java 6. We'll want GEP to support/work on Java6 ASAP.
Perhaps we should have a task-list JIRA for Java 6 issues.
Ted Kirby
--
Thanks,
Tim McConnell
Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
Great news Donald! I guess the idea to make this new repository branch to act as a geronimo specific maven repository that can be relied on and pointed to in geronimo project pom:s !?! This would (among other things) cut down the steps (and build instructions) needed for building special purpose assembles and plugins as you would no longer need to check out the vXXX gernonimo artifact subdir and manually do a mvn install into your local repos before you can scratch build your project. Simplicity is king! thanks peter petersson Donald Woods wrote: We have danced around the problem of not being able to build Samples, Plugins or GEP from a clean m2 repo without building the Server's repository subdir for long enough. I believe it is time to create the following location in SVN - geronimo/repo Which would hold our private patched artifacts of other projects (like Tomcat, Pluto, ...), just like the OpenEJB team has done for some of their private depends. I don't see this as a major hit to the svn infrastructure, given the jars (10 for 2.2.) will only be downloaded when starting with a clean m2 repo or when we publish any updated depends. Unless someone comes up with a better solution by Friday morning, I'll create the new repo branch and populate it with the latest 2.1.2 and 2.2 patched artifacts tomorrow. -Donald
Re: Documentation of new 2.2 features in current wiki?
IMHO, the 2.2 space must be seeded from the 2.1 space. The question is just when to do it. That's why I suggested creating 2.2 content under some temporary space. Once we have the actual 2.2 space setup (from 2.1 content) then we can move these new pages into 2.2 space. It will be a lot easier to move just a few pages of the new content then merge lots of pages of 2.1 content into 2.2 space. Jarek On Thu, Aug 7, 2008 at 11:02 AM, Joe Bohn [EMAIL PROTECTED] wrote: I agree in principle with creating a new location for 2.2 features to be documented. My only concern was that we are consistent so that the documentation will be easy for users to find and easy to integrate when we eventually do a mass merge from 2.1 to 2.2. So, I created a new space for 2.2 documentation to provide a consistent structure and to capture the enthusiasm to document 2.2 changes. I seeded it with a top level structure that matches our 2.1 doc but no actual content. You can find it here: http://cwiki.apache.org/GMOxDOC22/documentation.html I suggest that we create new content for 2.2 under this page for now: http://cwiki.apache.org/GMOxDOC22/what-changed-in-22.html I chose the current name to match what we had in 2.1. If a particular change has broad implications for documentation that is already available in 2.1, we can copy current 2.1 content into 2.2 and modify it accordingly. As David pointed out earlier, we do not have the ability to automatically merge the 2.1 content into the 2.2 content at a later time using this approach. Any merge will be a manual effort. The only alternative I am aware of would be to seed the new 2.2 space with the complete current 2.1 content. However, that brings about some maintenance issues of keeping things in sync and doesn't encourage 2.2 updates. When we last discussed this for 2.1 we decided to start with the empty space and so I took the same approach for this release. I hope this provides something that will serve as a good place for the 2.2 content for now. If we decide later that we should have started with a complete copy of 2.1 we can always create a copy and merge the new 2.2 documents back into the 2.1 copy. However, for now this at least provides a place we can use and it is obvious to our users where they can find 2.2 documentation. Joe Donald Woods wrote: Agree. We could just create a New Features in 2.2 page and people can create child pages to it for their new features as they are integrated into trunk -Donald Jarek Gawor wrote: I think it would be nicer to create pages with 2.2 specific content somewhere under http://cwiki.apache.org/GMOxDEV/index.html for now. Once we have 2.2 documentation space setup we can move the pages around. Or at least I don't think we should mix 2.2 content with 2.1 content. Jarek On Tue, Jul 29, 2008 at 1:52 PM, David Jencks [EMAIL PROTECTED] wrote: I've been playing around with openid and jaspi and would like to write up some documentation before I forget how it all works :-) I don't think we have enough people interested in documentation to pursue anything but the easiest-to-write path in documentation. In particular I think more than one active copy of the docs is asking for disaster. I'd like to suggest that feature documentation should generally start with a starting with version xxx comment. So, I'd put the openid/jaspi documentation in the current (2.1) wiki with a starting with 2.2 notice. Obviously there's the problem that the wiki has the 2.1 version in its name. I don't know if a wiki can have its name changed but don't regard this as critical. I'm going to start doing this pending comments and better ideas. At the rate I write I don't think I'll be causing significant damage before we have time for a full discussion :-) thanks david jencks
Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
On Aug 7, 2008, at 9:13 AM, Donald Woods wrote: We have danced around the problem of not being able to build Samples, Plugins or GEP from a clean m2 repo without building the Server's repository subdir for long enough. I believe it is time to create the following location in SVN - geronimo/repo Which would hold our private patched artifacts of other projects (like Tomcat, Pluto, ...), just like the OpenEJB team has done for some of their private depends. I don't see this as a major hit to the svn infrastructure, given the jars (10 for 2.2.) will only be downloaded when starting with a clean m2 repo or when we publish any updated depends. Unless someone comes up with a better solution by Friday morning, I'll create the new repo branch and populate it with the latest 2.1.2 and 2.2 patched artifacts tomorrow. Agree that this is a problem we need to fix... There's another option -- actually release the repository artifacts so that they'll be in normal maven repos. They could be under a geronimo groupid (e.g. org/apache/geronimo/patches or some meaningful name). This might be a cleaner solution... --kevan
Re: GEP and Java6
D'Oh! Thanks Tim. What does supported mean, anyway? Given that
users are hitting this problem, maybe we need to be more visible in
our warnings. Let's see where we get to with this Java 6 JIRA in the
next day or two, and adjust our documentation and possibly code
accordingly.
Thanks,
Ted Kirby
On Thu, Aug 7, 2008 at 11:40 AM, Tim McConnell [EMAIL PROTECTED] wrote:
Hi Ted, good ideas. Actually the GEP already has that type of warning
message.
jvmWarning={0} is currently only certified on a 1.5 JVM. Use of any other
version is not currently supported.
Also, I've opened a task-list JIRA for Java 6 specific problems as you
suggest. Could you subtasks for the problem(s) you already know about ??
Thanks
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-466
Ted Kirby wrote:
I have seen a number of problems with particularly new users running
Geronimo with GEP, and having problems. They switch to Java 5, and
things work for them. For GEP 2.1.2, which we want to get out ASAP
now that G2.1.2 is released, I think GEP should detect Java 6 when a
Geronimo server is defined, and warn the user of problems, and suggest
they use Java 5. I am not clear on the Geronimo server's position on
Java6. My understanding is that Geronimo is certified on Java 5, and
will run on Java 6. We'll want GEP to support/work on Java6 ASAP.
Perhaps we should have a task-list JIRA for Java 6 issues.
Ted Kirby
--
Thanks,
Tim McConnell
Re: Documentation of new 2.2 features in current wiki?
Resending somehow this never came through the first time: Hi Rebekah, I just posted a note about a new space that I created for the 2.2 documentation. The new space was really created just to get things moving for 2.2. It was not a statement of what the final structure should be ... so please feel free to continue to explore this area and receive comments. I personally haven't had a chance to consider the alternatives you presented below. However, my inclination is to keep the current structure as is unless there are obvious problems with the organization and there are resources willing to invest the time and effort to change things. Can you provide some more information on what is driving the changes that you are proposing? Thanks, Joe wei zhang wrote: Hi there, This is Rebekah and I've been reading through the documentation with my colleagues for a while. I think we can keep the current version of the documentation and create another space for v2.2, because there will be users who may want to track the previous information. Regarding the organization of information, we have worked out new documentation structures based on the 2.1 info using two different appraches: one is pretty much book based, keeping some of the current lookfeel; the other is info center based. If we are going to create a new space for v2.2, we can take either approach. As long as the structure is ready, people can take topics they are interested in and write up the content. If you have any ideas or comments on the proposed structures, feel free to let me know. Thanks. Information center based approach (all in one): 0 Geronimo information 1 What's new 1.1 New features 1.1.1 Custom server assemblies 1.1.2 Geronimo administration console 1.1.3 GShell 1.1.4 Clustering 1.1.5 Monitoring console plugin 1.1.6 Plan Creator 1.2 Enhanced features 1.2.1 Geronimo distributions 1.2.2 Configuration changes 1.3 Compatibility with earlier versions 2 Getting started with Apache Geronimo 2.1 Getting the software 2.1.1 Geronimo directory structure 2.2 Starting the server 2.3 Creating and deploying a sample application 3 Planning and installing 3.1 Installing prerequisite software 3.2 Getting Geronimo 3.2.1 Building Geronimo from source 3.2.1.1 http://3.2.1.1 Building Geronimo with Maven 3.2.1.2 http://3.2.1.2 Building Geronimo from Eclipse 3.3 Installing Geronimo 3.3.1 Installing Geronimo from binaries 3.4 Initial configuration 3.4.1 Available configuration files 3.4.2 Changing the default port numbers 3.4.3 Changing the username and password 3.5 Starting and stopping the server 3.5.1 Starting and Stopping Geronimo in GShell 3.6 Running Geronimo as a non-root user 3.7 Running multiple Geronimo instances 3.8 Running Geronimo as a Windows, or UINX service 4 Configuring and administering 4.1 Deploying and and administering assets in Geronimo 4.1.1 Deploying assets 4.1.1.1 http://4.1.1.1 Deploying assets via the administration console 4.1.1.2 http://4.1.1.2 Deploying assets from the command prompt 4.1.1.3 http://4.1.1.3 Deploying assets via GShell 4.1.1.4 http://4.1.1.4 Performing clustered deployment 4.1.1.5 http://4.1.1.5 Deploying plugins 4.1.1.6 http://4.1.1.6 Performing hot deployment 4.1.2 Administering applications 4.1.2.1 http://4.1.2.1 Installing and removing applications 4.1.2.2 http://4.1.2.2 Starting and stopping application modules 4.2 Configuring and administering the Apache Geronimo Server 4.2.1 Administering Geronimo using the Geronimo administration console 4.2.2 Administering Geronimo using command line tools 4.2.3 Add new listeners for Web containers 4.2.4 Aliasing modules 4.2.5 Configuring virtual host 4.2.5.1 http://4.2.5.1 Configuring virtual host in Jetty 4.2.5.2 http://4.2.5.2 Configuring virtual host in Tomcat 4.2.6 Configuring a remote Apache HTTP server 4.2.7 Configuring JAX-WS engine 4.2.8 Clustering 4.2.8.1 http://4.2.8.1 Farming 4.2.8.2 http://4.2.8.2 WADI clustering 4.2.9 Custom server assemblies 4.2.9.1 http://4.2.9.1 Plugin basics 4.2.9.2 http://4.2.9.2 Buidling,installing plugins and extracting a server from an exsiting server 4.2.9.3 http://4.2.9.3 Assembling a server using Maven 4.3 Congifuring services 4.3.1 Configuring multiple repositories 4.3.2 Adding archives to the Geronimo repository 4.3.3 Configuring database pools 4.3.4 Configuring JMS 4.4 Administering security 4.4.1 Basic Hints on Security Configuration 4.4.2 Configuring JavaEE application client security 4.4.3 Configuring login
Re: Documentation of new 2.2 features in current wiki?
If our goal is to have developers create documentation for new features when
the feature is integrate, then I don't see why we shouldn't just create the
2.2 space now and seed it with 2.1 right away. If no new features are added
yet, then the old documentation applies just as much to 2.2 as it does to
2.1, and if new features are added and documented appropriately, then people
can just use the appropriate documentation space for the appropriate
version. Basically, I'm saying I think we should seed the 2.2 documentation
space now and update it as we go along.
On Thu, Aug 7, 2008 at 11:43 AM, Jarek Gawor [EMAIL PROTECTED] wrote:
IMHO, the 2.2 space must be seeded from the 2.1 space. The question is
just when to do it. That's why I suggested creating 2.2 content under
some temporary space. Once we have the actual 2.2 space setup (from
2.1 content) then we can move these new pages into 2.2 space. It will
be a lot easier to move just a few pages of the new content then merge
lots of pages of 2.1 content into 2.2 space.
Jarek
On Thu, Aug 7, 2008 at 11:02 AM, Joe Bohn [EMAIL PROTECTED] wrote:
I agree in principle with creating a new location for 2.2 features to be
documented. My only concern was that we are consistent so that the
documentation will be easy for users to find and easy to integrate when
we
eventually do a mass merge from 2.1 to 2.2.
So, I created a new space for 2.2 documentation to provide a consistent
structure and to capture the enthusiasm to document 2.2 changes. I
seeded
it with a top level structure that matches our 2.1 doc but no actual
content. You can find it here:
http://cwiki.apache.org/GMOxDOC22/documentation.html
I suggest that we create new content for 2.2 under this page for now:
http://cwiki.apache.org/GMOxDOC22/what-changed-in-22.html
I chose the current name to match what we had in 2.1.
If a particular change has broad implications for documentation that is
already available in 2.1, we can copy current 2.1 content into 2.2 and
modify it accordingly.
As David pointed out earlier, we do not have the ability to automatically
merge the 2.1 content into the 2.2 content at a later time using this
approach. Any merge will be a manual effort. The only alternative I am
aware of would be to seed the new 2.2 space with the complete current 2.1
content. However, that brings about some maintenance issues of keeping
things in sync and doesn't encourage 2.2 updates. When we last discussed
this for 2.1 we decided to start with the empty space and so I took the
same
approach for this release.
I hope this provides something that will serve as a good place for the
2.2
content for now. If we decide later that we should have started with a
complete copy of 2.1 we can always create a copy and merge the new 2.2
documents back into the 2.1 copy. However, for now this at least
provides a
place we can use and it is obvious to our users where they can find 2.2
documentation.
Joe
Donald Woods wrote:
Agree. We could just create a New Features in 2.2 page and people can
create child pages to it for their new features as they are integrated
into
trunk
-Donald
Jarek Gawor wrote:
I think it would be nicer to create pages with 2.2 specific content
somewhere under http://cwiki.apache.org/GMOxDEV/index.html for now.
Once we have 2.2 documentation space setup we can move the pages
around. Or at least I don't think we should mix 2.2 content with 2.1
content.
Jarek
On Tue, Jul 29, 2008 at 1:52 PM, David Jencks [EMAIL PROTECTED]
wrote:
I've been playing around with openid and jaspi and would like to write
up
some documentation before I forget how it all works :-)
I don't think we have enough people interested in documentation to
pursue
anything but the easiest-to-write path in documentation. In
particular
I
think more than one active copy of the docs is asking for disaster.
I'd like to suggest that feature documentation should generally start
with a
starting with version xxx comment. So, I'd put the openid/jaspi
documentation in the current (2.1) wiki with a starting with 2.2
notice.
Obviously there's the problem that the wiki has the 2.1 version in
its
name. I don't know if a wiki can have its name changed but don't
regard
this
as critical.
I'm going to start doing this pending comments and better ideas. At
the
rate I write I don't think I'll be causing significant damage before
we
have
time for a full discussion :-)
thanks
david jencks
--
~Jason Warner
Re: Documentation of new 2.2 features in current wiki?
I agree that I don't really want to see a change of structure in
documentation unless someone can give a good reason to that. I feel
I just learned on how to locate some of the good information in the
doc and I don't want to go through that learning again.
The prob of seeding 2.2 space with 2.1 content right now is that 2.1
content isn't finished yet. If someone wants to make a change to 2.1
content, he'll have to change it in two places (both 2.1 and 2.2
docs).
Lin
On Thu, Aug 7, 2008 at 12:45 PM, Jason Warner [EMAIL PROTECTED] wrote:
If our goal is to have developers create documentation for new features when
the feature is integrate, then I don't see why we shouldn't just create the
2.2 space now and seed it with 2.1 right away. If no new features are added
yet, then the old documentation applies just as much to 2.2 as it does to
2.1, and if new features are added and documented appropriately, then people
can just use the appropriate documentation space for the appropriate
version. Basically, I'm saying I think we should seed the 2.2 documentation
space now and update it as we go along.
On Thu, Aug 7, 2008 at 11:43 AM, Jarek Gawor [EMAIL PROTECTED] wrote:
IMHO, the 2.2 space must be seeded from the 2.1 space. The question is
just when to do it. That's why I suggested creating 2.2 content under
some temporary space. Once we have the actual 2.2 space setup (from
2.1 content) then we can move these new pages into 2.2 space. It will
be a lot easier to move just a few pages of the new content then merge
lots of pages of 2.1 content into 2.2 space.
Jarek
On Thu, Aug 7, 2008 at 11:02 AM, Joe Bohn [EMAIL PROTECTED] wrote:
I agree in principle with creating a new location for 2.2 features to be
documented. My only concern was that we are consistent so that the
documentation will be easy for users to find and easy to integrate when
we
eventually do a mass merge from 2.1 to 2.2.
So, I created a new space for 2.2 documentation to provide a consistent
structure and to capture the enthusiasm to document 2.2 changes. I
seeded
it with a top level structure that matches our 2.1 doc but no actual
content. You can find it here:
http://cwiki.apache.org/GMOxDOC22/documentation.html
I suggest that we create new content for 2.2 under this page for now:
http://cwiki.apache.org/GMOxDOC22/what-changed-in-22.html
I chose the current name to match what we had in 2.1.
If a particular change has broad implications for documentation that is
already available in 2.1, we can copy current 2.1 content into 2.2 and
modify it accordingly.
As David pointed out earlier, we do not have the ability to
automatically
merge the 2.1 content into the 2.2 content at a later time using this
approach. Any merge will be a manual effort. The only alternative I am
aware of would be to seed the new 2.2 space with the complete current
2.1
content. However, that brings about some maintenance issues of keeping
things in sync and doesn't encourage 2.2 updates. When we last
discussed
this for 2.1 we decided to start with the empty space and so I took the
same
approach for this release.
I hope this provides something that will serve as a good place for the
2.2
content for now. If we decide later that we should have started with a
complete copy of 2.1 we can always create a copy and merge the new 2.2
documents back into the 2.1 copy. However, for now this at least
provides a
place we can use and it is obvious to our users where they can find 2.2
documentation.
Joe
Donald Woods wrote:
Agree. We could just create a New Features in 2.2 page and people
can
create child pages to it for their new features as they are integrated
into
trunk
-Donald
Jarek Gawor wrote:
I think it would be nicer to create pages with 2.2 specific content
somewhere under http://cwiki.apache.org/GMOxDEV/index.html for now.
Once we have 2.2 documentation space setup we can move the pages
around. Or at least I don't think we should mix 2.2 content with 2.1
content.
Jarek
On Tue, Jul 29, 2008 at 1:52 PM, David Jencks [EMAIL PROTECTED]
wrote:
I've been playing around with openid and jaspi and would like to
write
up
some documentation before I forget how it all works :-)
I don't think we have enough people interested in documentation to
pursue
anything but the easiest-to-write path in documentation. In
particular
I
think more than one active copy of the docs is asking for disaster.
I'd like to suggest that feature documentation should generally start
with a
starting with version xxx comment. So, I'd put the openid/jaspi
documentation in the current (2.1) wiki with a starting with 2.2
notice.
Obviously there's the problem that the wiki has the 2.1 version in
its
name. I don't know if a wiki can have its name changed but don't
regard
this
as critical.
I'm
Re: Documentation of new 2.2 features in current wiki?
On Aug 7, 2008, at 8:43 AM, Jarek Gawor wrote: IMHO, the 2.2 space must be seeded from the 2.1 space. The question is just when to do it. That's why I suggested creating 2.2 content under some temporary space. Once we have the actual 2.2 space setup (from 2.1 content) then we can move these new pages into 2.2 space. It will be a lot easier to move just a few pages of the new content then merge lots of pages of 2.1 content into 2.2 space. I agree. IMNSHO the approach we used in 2.1 of not copying the entire previous documentation verbatim and modifying it but rather moving each page one at a time set us back at least one month and I don't think we've fully recovered. I'd also like to request that in the 2.2 documentation there be _no_ hand maintained tables of contents, indexes, etc. My experience with them is that whatever the apparent benefit in terms of better ordering or nicer layout, the main effect they have is to conceal most of the newest documentation. This would require some editing after the 2.1 to 2.2 mass copy I'm hoping for. thanks david jencks Jarek On Thu, Aug 7, 2008 at 11:02 AM, Joe Bohn [EMAIL PROTECTED] wrote: I agree in principle with creating a new location for 2.2 features to be documented. My only concern was that we are consistent so that the documentation will be easy for users to find and easy to integrate when we eventually do a mass merge from 2.1 to 2.2. So, I created a new space for 2.2 documentation to provide a consistent structure and to capture the enthusiasm to document 2.2 changes. I seeded it with a top level structure that matches our 2.1 doc but no actual content. You can find it here: http://cwiki.apache.org/GMOxDOC22/documentation.html I suggest that we create new content for 2.2 under this page for now: http://cwiki.apache.org/GMOxDOC22/what-changed-in-22.html I chose the current name to match what we had in 2.1. If a particular change has broad implications for documentation that is already available in 2.1, we can copy current 2.1 content into 2.2 and modify it accordingly. As David pointed out earlier, we do not have the ability to automatically merge the 2.1 content into the 2.2 content at a later time using this approach. Any merge will be a manual effort. The only alternative I am aware of would be to seed the new 2.2 space with the complete current 2.1 content. However, that brings about some maintenance issues of keeping things in sync and doesn't encourage 2.2 updates. When we last discussed this for 2.1 we decided to start with the empty space and so I took the same approach for this release. I hope this provides something that will serve as a good place for the 2.2 content for now. If we decide later that we should have started with a complete copy of 2.1 we can always create a copy and merge the new 2.2 documents back into the 2.1 copy. However, for now this at least provides a place we can use and it is obvious to our users where they can find 2.2 documentation. Joe Donald Woods wrote: Agree. We could just create a New Features in 2.2 page and people can create child pages to it for their new features as they are integrated into trunk -Donald Jarek Gawor wrote: I think it would be nicer to create pages with 2.2 specific content somewhere under http://cwiki.apache.org/GMOxDEV/index.html for now. Once we have 2.2 documentation space setup we can move the pages around. Or at least I don't think we should mix 2.2 content with 2.1 content. Jarek On Tue, Jul 29, 2008 at 1:52 PM, David Jencks [EMAIL PROTECTED] wrote: I've been playing around with openid and jaspi and would like to write up some documentation before I forget how it all works :-) I don't think we have enough people interested in documentation to pursue anything but the easiest-to-write path in documentation. In particular I think more than one active copy of the docs is asking for disaster. I'd like to suggest that feature documentation should generally start with a starting with version xxx comment. So, I'd put the openid/jaspi documentation in the current (2.1) wiki with a starting with 2.2 notice. Obviously there's the problem that the wiki has the 2.1 version in its name. I don't know if a wiki can have its name changed but don't regard this as critical. I'm going to start doing this pending comments and better ideas. At the rate I write I don't think I'll be causing significant damage before we have time for a full discussion :-) thanks david jencks
[jira] Updated: (GERONIMODEVTOOLS-439) Download/install new server testcase
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-439: --- Component/s: eclipse-plugin Affects Version/s: 2.2.0 Fix Version/s: 2.2.0 Assignee: Ashish Jain (was: Tim McConnell) Download/install new server testcase Key: GERONIMODEVTOOLS-439 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-439 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.2.0 Reporter: Tim McConnell Assignee: Ashish Jain Fix For: 2.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] branches/2.1: Failed for Revision: 683659
Geronimo Revision: 683659 built with tests included See the full build-1400.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080807/build-1400.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.1/20080807 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 32 minutes 50 seconds [INFO] Finished at: Thu Aug 07 14:39:07 EDT 2008 [INFO] Final Memory: 305M/1015M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080807/logs-1400-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080807/logs-1400-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 77.758 sec FAILURE! Samples: branches/2.1 = Log: http://people.apache.org/builds/geronimo/server/binaries/2.1/20080807/samples-1400.log Build status: OK
Re: Documentation of new 2.2 features in current wiki?
This is some great information Dave. Thanks for the details. I experimented a little with export/restore but without much success. I wasn't able to restore an image with an updated entities.xml (that simply replaced the old space references with new space references). Each time I attempted to restore it always complained that the exportDescriptor.properties was either missing or invalid ... but when I checked the file did exist and I didn't see anything obvious in there that needed to be changed when the space name was updated (actually, it only has something like 3 lines that were exportType, buildnumber, and backupattaachements). It is really too bad that we can move an entire page tree but can only copy individual pages. If only we could do that then it would be easy to integrate the 2.1 documents into a 2.2 space that was partially complete. Joe David Blevins wrote: On Jul 31, 2008, at 12:20 AM, David Jencks wrote: My impression based on gossip is that while it's possible to copy an entire wiki space it isn't possible to move individual pages between spaces. Is this correct? On Jul 31, 2008, at 3:38 PM, David Jencks wrote: 3. Create a new space for Apache Geronimo 2.2 (similar to the spaces we have for 1.0, 1.1, 1.2, 2.0, and 2.1). Add new documents specific to 2.2 into this new space. It would be fairly sparse for now. When we complete the 2.1 docs we can clone them into the 2.2 space and integrate the 2.2 specific documents into the appropriate sections/structure. My impression from the 2.1 debacle of not starting by copying the existing documentation into a new 2.1 space was that after the space was created, you couldn't copy stuff from another space en mass. Hopefully I'm wrong. Anyway this hopefully mis-understanding is the basis for (1). What confluence can do: MOVE A PAGE AND IT'S CHILDREN - From a page's Edit tab, click the smaller edit link by Location. You can then change the space or parent page. If you select a new space, a checkbox becomes available that allows you to optionally change the space of all children pages. - Cascades to children: optional - Retains edit history: yes - Retains attachments: yes - Retains comments: yes - Retains labels: yes - Retains permissions: yes COPY A PAGE - From a page's Info tab, click the Copy link. You get a new edit screen with the current page content and a the title with Copy of prepended to it. All the normal things can be edited from this screen, including Location. - Cascades to children: no - Retains edit history: no - Retains attachments: yes - Retains comments: no - Retains labels: no - Retains permissions: no EXPORT / RESTORE - From a space's Advanced tab, click Export Space. You can select any pages you want and export as XML. Then you need to crack open the zip downloaded and exit the entities.xml to change the space name. Zip the whole thing up again and use the Restore option as a confluence administrator. Note you cannot use the restore option on spaces that already exist. - Retains edit history: yes - Retains attachments: yes - Retains comments: yes - Retains labels: no (didn't work for me) - Retains permissions: yes My thoughts: If we really want a separate space for each major version, then I'd recommend we use the EXPORT/RESTORE option to seed from the prior version's space (2.1). If we need to create any pages before then, which seems to be our current dilemma, then we can create a 2.2 page somewhere else (say DEV or SANDBOX or anywhere) and make all such new content a child of that page. Whenever we do eventually create a 2.2 space we can move then 2.2 page and all it's children from the temporary space to the 2.2 space in one operation. The two main reasons: 1. I think author/revision history is critical for oversight. 2. Efficiency. If N is the number of pages we have from the the prior version's space and X is the number pages that are new for the current version's space, N is going to always get bigger and bigger and more and more disproportionate to X. Mathematically starting with a space seeded from the N pages and moving in X pages requires less operations than starting with a new space for X and copying in N pages, which will only get worse over time. Further, the cost of moving X can be reduced to 1 if we use the parent page and move children trick. I understand that one of the motivations for starting blank and copying pages individually was to allow for review of the pages to see if they are still relevant. That's an orthogonal argument as a review process of review then copy would take an equal amount of time as a review then delete process. The real difference is in weather or not pages should be considered relevant or outdated by default and which risk is worse; the potential for missing valid documentation or the potential for present
Re: Documentation of new 2.2 features in current wiki?
Agree. -Donald Jarek Gawor wrote: IMHO, the 2.2 space must be seeded from the 2.1 space. The question is just when to do it. That's why I suggested creating 2.2 content under some temporary space. Once we have the actual 2.2 space setup (from 2.1 content) then we can move these new pages into 2.2 space. It will be a lot easier to move just a few pages of the new content then merge lots of pages of 2.1 content into 2.2 space. Jarek On Thu, Aug 7, 2008 at 11:02 AM, Joe Bohn [EMAIL PROTECTED] wrote: I agree in principle with creating a new location for 2.2 features to be documented. My only concern was that we are consistent so that the documentation will be easy for users to find and easy to integrate when we eventually do a mass merge from 2.1 to 2.2. So, I created a new space for 2.2 documentation to provide a consistent structure and to capture the enthusiasm to document 2.2 changes. I seeded it with a top level structure that matches our 2.1 doc but no actual content. You can find it here: http://cwiki.apache.org/GMOxDOC22/documentation.html I suggest that we create new content for 2.2 under this page for now: http://cwiki.apache.org/GMOxDOC22/what-changed-in-22.html I chose the current name to match what we had in 2.1. If a particular change has broad implications for documentation that is already available in 2.1, we can copy current 2.1 content into 2.2 and modify it accordingly. As David pointed out earlier, we do not have the ability to automatically merge the 2.1 content into the 2.2 content at a later time using this approach. Any merge will be a manual effort. The only alternative I am aware of would be to seed the new 2.2 space with the complete current 2.1 content. However, that brings about some maintenance issues of keeping things in sync and doesn't encourage 2.2 updates. When we last discussed this for 2.1 we decided to start with the empty space and so I took the same approach for this release. I hope this provides something that will serve as a good place for the 2.2 content for now. If we decide later that we should have started with a complete copy of 2.1 we can always create a copy and merge the new 2.2 documents back into the 2.1 copy. However, for now this at least provides a place we can use and it is obvious to our users where they can find 2.2 documentation. Joe Donald Woods wrote: Agree. We could just create a New Features in 2.2 page and people can create child pages to it for their new features as they are integrated into trunk -Donald Jarek Gawor wrote: I think it would be nicer to create pages with 2.2 specific content somewhere under http://cwiki.apache.org/GMOxDEV/index.html for now. Once we have 2.2 documentation space setup we can move the pages around. Or at least I don't think we should mix 2.2 content with 2.1 content. Jarek On Tue, Jul 29, 2008 at 1:52 PM, David Jencks [EMAIL PROTECTED] wrote: I've been playing around with openid and jaspi and would like to write up some documentation before I forget how it all works :-) I don't think we have enough people interested in documentation to pursue anything but the easiest-to-write path in documentation. In particular I think more than one active copy of the docs is asking for disaster. I'd like to suggest that feature documentation should generally start with a starting with version xxx comment. So, I'd put the openid/jaspi documentation in the current (2.1) wiki with a starting with 2.2 notice. Obviously there's the problem that the wiki has the 2.1 version in its name. I don't know if a wiki can have its name changed but don't regard this as critical. I'm going to start doing this pending comments and better ideas. At the rate I write I don't think I'll be causing significant damage before we have time for a full discussion :-) thanks david jencks smime.p7s Description: S/MIME Cryptographic Signature
Re: Documentation of new 2.2 features in current wiki?
David Jencks wrote: On Aug 7, 2008, at 8:43 AM, Jarek Gawor wrote: IMHO, the 2.2 space must be seeded from the 2.1 space. The question is just when to do it. That's why I suggested creating 2.2 content under some temporary space. Once we have the actual 2.2 space setup (from 2.1 content) then we can move these new pages into 2.2 space. It will be a lot easier to move just a few pages of the new content then merge lots of pages of 2.1 content into 2.2 space. I agree. IMNSHO the approach we used in 2.1 of not copying the entire previous documentation verbatim and modifying it but rather moving each page one at a time set us back at least one month and I don't think we've fully recovered. I'd also like to request that in the 2.2 documentation there be _no_ hand maintained tables of contents, indexes, etc. My experience with them is that whatever the apparent benefit in terms of better ordering or nicer layout, the main effect they have is to conceal most of the newest documentation. This would require some editing after the 2.1 to 2.2 mass copy I'm hoping for. thanks david jencks Alright. When I created the new space I was attempting to get things moving on the new documentation. I can see now that I didn't accomplish that given the dilemma on how to merge in the 2.1 content. Until we can resolve this I've done the following: - Removed the reference to the new GMOxDOC22 space from the main Geronimo wiki page. I did not yet delete this space in case we decide we can still leverage it in some fashion (it took a little time to setup the permissions, Geronimo banner, etc...). We can remove it at anytime if necessary to create the final 22 documentation space. - Created a Geronimo 2.2 New Features page to act as a parent for new 2.2 content under the GMOxDEV page (as suggested by Jarek) - Added a link to the new temporary page next to the release documents on the main documentation page. Yes, this means that there are 2 links to the Geronimo 2.2 New Features page on the main page ... but I thought it was important that this initial 2.2 doc be easy to find near all of the other G version doc links. I think the users will have less difficulty finding the doc and it will set a consistent expectation for where they can find the full documentation when it is all merged together. I hope that solves everybody's concerns and allows folks to start documenting 2.2 features now while we figure out the best way to handle the structure and mass population of the Geronimo 2.2 doc space. Joe Jarek On Thu, Aug 7, 2008 at 11:02 AM, Joe Bohn [EMAIL PROTECTED] wrote: I agree in principle with creating a new location for 2.2 features to be documented. My only concern was that we are consistent so that the documentation will be easy for users to find and easy to integrate when we eventually do a mass merge from 2.1 to 2.2. So, I created a new space for 2.2 documentation to provide a consistent structure and to capture the enthusiasm to document 2.2 changes. I seeded it with a top level structure that matches our 2.1 doc but no actual content. You can find it here: http://cwiki.apache.org/GMOxDOC22/documentation.html I suggest that we create new content for 2.2 under this page for now: http://cwiki.apache.org/GMOxDOC22/what-changed-in-22.html I chose the current name to match what we had in 2.1. If a particular change has broad implications for documentation that is already available in 2.1, we can copy current 2.1 content into 2.2 and modify it accordingly. As David pointed out earlier, we do not have the ability to automatically merge the 2.1 content into the 2.2 content at a later time using this approach. Any merge will be a manual effort. The only alternative I am aware of would be to seed the new 2.2 space with the complete current 2.1 content. However, that brings about some maintenance issues of keeping things in sync and doesn't encourage 2.2 updates. When we last discussed this for 2.1 we decided to start with the empty space and so I took the same approach for this release. I hope this provides something that will serve as a good place for the 2.2 content for now. If we decide later that we should have started with a complete copy of 2.1 we can always create a copy and merge the new 2.2 documents back into the 2.1 copy. However, for now this at least provides a place we can use and it is obvious to our users where they can find 2.2 documentation. Joe Donald Woods wrote: Agree. We could just create a New Features in 2.2 page and people can create child pages to it for their new features as they are integrated into trunk -Donald Jarek Gawor wrote: I think it would be nicer to create pages with 2.2 specific content somewhere under http://cwiki.apache.org/GMOxDEV/index.html for now. Once we have 2.2 documentation space setup we can move the pages around. Or at least I don't think we should mix 2.2 content with
Were SNAPSHOT artifacts cleaned recently?
I tried building the 2.1.3-SNAPSHOT release from a clean repo earlier today and was getting a build failure due to the following dependency in Genesis 1.3 no longer being in the m2 snapshot repo on people.apache - org.apache.geronimo.genesis.config:geronimo-skin:jar:1.2-SNAPSHOT So, I went back and rebuilt the missing depend and deployed only this one artifact back to snapshots by using the genesis-1.2 tag and changing the required pom to use version=1.2-SNAPSHOT. But, this points out a problem in the released genesis-1.3 artifacts, that we need to resolve for the 2.1 branch and trunk by either creating a Genesis 1.3.1 release to fix the following files - src/site/site.xml config/project-config/src/site/site.xml or move up to genesis-1.5-SNAPSHOT in genesis/branches/1.x Preferences? -Donald smime.p7s Description: S/MIME Cryptographic Signature
Re: Were SNAPSHOT artifacts cleaned recently?
On Aug 7, 2008, at 2:29 PM, Donald Woods wrote: I tried building the 2.1.3-SNAPSHOT release from a clean repo earlier today and was getting a build failure due to the following dependency in Genesis 1.3 no longer being in the m2 snapshot repo on people.apache - org.apache.geronimo.genesis.config:geronimo-skin:jar:1.2-SNAPSHOT So, I went back and rebuilt the missing depend and deployed only this one artifact back to snapshots by using the genesis-1.2 tag and changing the required pom to use version=1.2-SNAPSHOT. But, this points out a problem in the released genesis-1.3 artifacts, that we need to resolve for the 2.1 branch and trunk by either creating a Genesis 1.3.1 release to fix the following files - src/site/site.xml config/project-config/src/site/site.xml or move up to genesis-1.5-SNAPSHOT in genesis/branches/1.x Preferences? Jason Dillon was working on a genesis 2.0 recently. If he's able to finish it reasonably soon I think we should move to it. Otherwise I'll create a genesis 1.5 that has some of the simplifications I know about. I really don't want anything stuck on older versions of genesis. thanks david jencks -Donald
Re: Were SNAPSHOT artifacts cleaned recently?
Donald Woods wrote: I tried building the 2.1.3-SNAPSHOT release from a clean repo earlier today and was getting a build failure due to the following dependency in Genesis 1.3 no longer being in the m2 snapshot repo on people.apache - org.apache.geronimo.genesis.config:geronimo-skin:jar:1.2-SNAPSHOT So, I went back and rebuilt the missing depend and deployed only this one artifact back to snapshots by using the genesis-1.2 tag and changing the required pom to use version=1.2-SNAPSHOT. But, this points out a problem in the released genesis-1.3 artifacts, that we need to resolve for the 2.1 branch and trunk by either creating a Genesis 1.3.1 release to fix the following files - src/site/site.xml config/project-config/src/site/site.xml or move up to genesis-1.5-SNAPSHOT in genesis/branches/1.x Preferences? Donald, First off ... the answer to the subject questions is yes. It appears that we were running short of disk space and so anything on the snapshot repository that was older than 30 days (across all Apache projects) was deleted yesterday. As far as the genesis issue goes ... it appears that this is only an issue when building the site (is that correct? Jarek did some digging and discovered this). That would explain why I never noticed it with G 2.1.2 which also is dependent upon Genesis 1.3. I would propose that we move to Genesis 1.4 until 1.5 is released rather than being dependent on another snapshot which isn't really necessary at this point. Joe
Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
In-line. Jarek Gawor wrote: Maybe I'm missing something, but aren't these artifacts already in svn under ../repository, e.g. http://svn.apache.org/repos/asf/geronimo/server/branches/2.1/repository/ (for the given release)? True, maybe for now, pointing into tags for the required artifacts for samples and GEP will work and we can revisit a geronimo/repo branch later if needed. Only concern, would be updating the release process to look for these svn repo refs, as our samples and GEP builds will eventually have to use the artifacts from trunk and then be updated to point to tags Are you proposing one main location for all version of the artifacts for all versions of Geronimo? Will that svn location be added to the repositories list in pom.xml? What I'm concerned about is that if we add that svn location to the repositories list, maven might pick that svn repository as the first repository to check for any artifacts and therefore you will get a lot more hits to that svn repository. I don't know if there is a way to tell maven to check a given repository last or only use it for specific artifacts/versions. Was thinking we would keep the repositroy/pom.xml in the server build and it would be the only pom that would point to the svn backed files. We would add a similar repository/pom.xml in the other subprojects that need to pull in any of these jars. Jarek On Thu, Aug 7, 2008 at 9:13 AM, Donald Woods [EMAIL PROTECTED] wrote: We have danced around the problem of not being able to build Samples, Plugins or GEP from a clean m2 repo without building the Server's repository subdir for long enough. I believe it is time to create the following location in SVN - geronimo/repo Which would hold our private patched artifacts of other projects (like Tomcat, Pluto, ...), just like the OpenEJB team has done for some of their private depends. I don't see this as a major hit to the svn infrastructure, given the jars (10 for 2.2.) will only be downloaded when starting with a clean m2 repo or when we publish any updated depends. Unless someone comes up with a better solution by Friday morning, I'll create the new repo branch and populate it with the latest 2.1.2 and 2.2 patched artifacts tomorrow. -Donald smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
True, but wouldn't that introduce the overhead of our release process and voting? Would we create a geronimo/patches subproject arranged like our specs, where each artifact would be its own subdir and still check the patched artifacts in for the build to use and then move them to tags after they are released? Would we version the artifacts based on the originating project or with a double version like we specs (which would be hard to follow)? -Donald Kevan Miller wrote: On Aug 7, 2008, at 9:13 AM, Donald Woods wrote: We have danced around the problem of not being able to build Samples, Plugins or GEP from a clean m2 repo without building the Server's repository subdir for long enough. I believe it is time to create the following location in SVN - geronimo/repo Which would hold our private patched artifacts of other projects (like Tomcat, Pluto, ...), just like the OpenEJB team has done for some of their private depends. I don't see this as a major hit to the svn infrastructure, given the jars (10 for 2.2.) will only be downloaded when starting with a clean m2 repo or when we publish any updated depends. Unless someone comes up with a better solution by Friday morning, I'll create the new repo branch and populate it with the latest 2.1.2 and 2.2 patched artifacts tomorrow. Agree that this is a problem we need to fix... There's another option -- actually release the repository artifacts so that they'll be in normal maven repos. They could be under a geronimo groupid (e.g. org/apache/geronimo/patches or some meaningful name). This might be a cleaner solution... --kevan smime.p7s Description: S/MIME Cryptographic Signature
timestamped snapshots
There have recently been issues with the snapshot repository because it was running low on space and so any snapshot older than 30 days was deleted across the board. One reason given for the rapid growth in the repository size was due to projects using timestamped snapshots. It was stated that using timestamped repos in general was wrong for the apache snapshot repo. Geronimo uses timestamped snapshots. Myfaces was listed as an example of doing things the right way (http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3-SNAPSHOT/). Does anybody know how we can remove the timestamps (assuming they are not needed for any particular reason)? Joe
Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
On Aug 7, 2008, at 8:26 PM, Donald Woods wrote: True, but wouldn't that introduce the overhead of our release process and voting? I wouldn't call it overhead. I'd call it oversight. Our community is releasing the patches and publishing the binaries. Server release votes have covered this, to date. Any process changes must maintain this same level of oversight. Would we create a geronimo/patches subproject arranged like our specs, where each artifact would be its own subdir and still check the patched artifacts in for the build to use and then move them to tags after they are released? We could release them separately. Or, we could include them (as they are currently) in the server. The difference is that there would be org.apache.geronimo.patches artifacts in our release and snapshot repositories. Would we version the artifacts based on the originating project or with a double version like we specs (which would be hard to follow)? Either way would work. For simplicity, my tendency is to include them in our server tree. However, there may be differing opinions. I'm fine either way... --kevan
[jira] Created: (GERONIMO-4231) Build exception: java.net.MalformedURLException: no !/ in spec
Build exception: java.net.MalformedURLException: no !/ in spec -- Key: GERONIMO-4231 URL: https://issues.apache.org/jira/browse/GERONIMO-4231 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: general Affects Versions: 2.1 Environment: Linux Reporter: Cai Jun Jie Priority: Minor Fix For: 2.1.3 When building server in Linux, the following exceptions occurs several times in the build log: From: Jun Jie Cai/China/[EMAIL PROTECTED] To: Donald R Woods/Raleigh/[EMAIL PROTECTED] Cc: Lin Quan Jiang/China/[EMAIL PROTECTED] Date: 08/06/08 11:48 PM Subject:MalformedURLException in build log HI Donald, This looks like an old problem, which occured on both servers (builds21.rtp and ce21.cn). See some build log: http://ce21.cn.ibm.com:7080/luntbuild/publish/WASCE-2.1.0.0_server/OnDemand/20080806/build_log.html http://builds2.rtp.raleigh.ibm.com/luntbuild/app.do?service=direct/1/Home/builds.buildViewerComponent.$DirectLink I once spent some time on it and didn't work it out. Do we need to fix them? If yes, we will do more investigation. [INFO] Started deployer: org.apache.geronimo.configs/jasper-deployer/2.1.1/car java.net.MalformedURLException: no !/ in spec at java.net.URL.(URL.java:636) at java.net.URL.(URL.java:499) at java.net.URL.(URL.java:448) at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:181) at java.net.JarURLConnection.(JarURLConnection.java:164) at sun.net.www.protocol.jar.JarURLConnection.(JarURLConnection.java:93) at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:42) at java.net.URL.openConnection(URL.java:978) at sun.misc.URLClassPath$JarLoader.getJarFile(URLClassPath.java:856) at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:813) at sun.misc.URLClassPath$3.rtJarLoader(URLClassPath.java:588) at sun.misc.URLClassPath$3.run(URLClassPath.java:519) at java.security.AccessController.doPrivileged(AccessController.java:246) at sun.misc.URLClassPath.getLoader(URLClassPath.java:508) at sun.misc.URLClassPath.getLoader(URLClassPath.java:473) at sun.misc.URLClassPath.getResource(URLClassPath.java:322) at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1032) at java.security.AccessController.doPrivileged(AccessController.java:279) at java.net.URLClassLoader.findClass(URLClassLoader.java:491) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:470) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:456) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:456) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:407) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:595) at java.beans.Introspector.instantiate(Introspector.java:1482) at java.beans.PropertyEditorManager.findEditor(PropertyEditorManager.java:106) at org.apache.geronimo.common.propertyeditor.PropertyEditors.findEditor(PropertyEditors.java:63) at org.apache.geronimo.common.propertyeditor.PropertyEditors.findEditor(PropertyEditors.java:120) at org.apache.geronimo.deployment.service.SingleGBeanBuilder.setAttribute(SingleGBeanBuilder.java:78) at org.apache.geronimo.deployment.service.GBeanBuilder.addGBeanData(GBeanBuilder.java:113) at org.apache.geronimo.deployment.service.GBeanBuilder.build(GBeanBuilder.java:98) at org.apache.geronimo.deployment.NamespaceDrivenBuilderCollection.build(NamespaceDrivenBuilderCollection.java:48) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.basicInitContext(AbstractWebModuleBuilder.java:367) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.initContext(TomcatModuleBuilder.java:330) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.initContext(SwitchingModuleBuilder.java:159) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at sun.reflect.GeneratedMethodAccessor221.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at
