[jira] Assigned: (GERONIMO-3705) Maven 2.0.8 causes build problems
[ https://issues.apache.org/jira/browse/GERONIMO-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned GERONIMO-3705: -- Assignee: David Jencks (was: Jason Dillon) Maven 2.0.8 causes build problems - Key: GERONIMO-3705 URL: https://issues.apache.org/jira/browse/GERONIMO-3705 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: Jason Dillon Assignee: David Jencks Priority: Critical -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3705) Maven 2.0.8 causes build problems
[ https://issues.apache.org/jira/browse/GERONIMO-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589433#action_12589433 ] David Jencks commented on GERONIMO-3705: Problem seems to be the car-maven-plugin use of DependencyHelper leaves out a whole lotta dependencies. I think this can also occur even with maven 2.0.7, servicemix seems to be encountering a similar problem. It's pretty easy to have our plugins use the ArtifactCollector more directly which allows building with maven 2.0.9 about to check about servicemix. Maven 2.0.8 causes build problems - Key: GERONIMO-3705 URL: https://issues.apache.org/jira/browse/GERONIMO-3705 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: Jason Dillon Assignee: David Jencks Priority: Critical -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3705) Maven 2.0.8 causes build problems
[ https://issues.apache.org/jira/browse/GERONIMO-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589434#action_12589434 ] David Jencks commented on GERONIMO-3705: Here's the servicemix trace, the one from geronimo looked similar: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Unable to create configuration for deployment Unable to resolve dependency org.apache.xbean/xbean-naming//jar [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Unable to create configuration for deployment at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to create configuration for deployment at org.apache.geronimo.genesis.MojoSupport.execute(MojoSupport.java:137) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.geronimo.common.DeploymentException: Unable to create configuration for deployment at org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:121) at org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:101) at org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:81) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:205) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:177) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$21e3cf17.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at
[jira] Commented: (GERONIMO-3440) DB2-XA: when trace file is not specified, it caused error when running the sample
[ https://issues.apache.org/jira/browse/GERONIMO-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589449#action_12589449 ] David Jencks commented on GERONIMO-3440: Fixed in 2.1 before the 2.1.1 branch in rev 648055. DB2-XA: when trace file is not specified, it caused error when running the sample - Key: GERONIMO-3440 URL: https://issues.apache.org/jira/browse/GERONIMO-3440 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1, 2.1.1 Reporter: Lin Sun Assignee: David Jencks Priority: Minor Fix For: 2.1.1 Attachments: tranql-tracefile.patch This is a tranql issue found when I plug the db2-xa rar into G's console. Basically, if a user leaves the tracefile property to empty (meaning dont want any trace), I can deploy my sample fine. But when I run the sample, I got - --- Got DataSource: [EMAIL PROTECTED] com.ibm.db2.jcc.b.SqlException: Unable to open file at com.ibm.db2.jcc.b.ig.a(ig.java:93) A simple fix in DB2XA is to only settrace when it is a valid value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3705) Maven 2.0.8 causes build problems
[ https://issues.apache.org/jira/browse/GERONIMO-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589450#action_12589450 ] David Jencks commented on GERONIMO-3705: Fixed in branches/2.1 (2.1.2-SNAPSHOT) rev 648584. trunk rev 648603 Maven 2.0.8 causes build problems - Key: GERONIMO-3705 URL: https://issues.apache.org/jira/browse/GERONIMO-3705 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: Jason Dillon Assignee: David Jencks Priority: Critical -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3440) DB2-XA: when trace file is not specified, it caused error when running the sample
[ https://issues.apache.org/jira/browse/GERONIMO-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3440. -- Resolution: Fixed Fix Version/s: 2.2 2.1.x Fixed in trunk before rev 648603. DB2-XA: when trace file is not specified, it caused error when running the sample - Key: GERONIMO-3440 URL: https://issues.apache.org/jira/browse/GERONIMO-3440 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1, 2.1.1 Reporter: Lin Sun Assignee: David Jencks Priority: Minor Fix For: 2.1.1, 2.1.x, 2.2 Attachments: tranql-tracefile.patch This is a tranql issue found when I plug the db2-xa rar into G's console. Basically, if a user leaves the tracefile property to empty (meaning dont want any trace), I can deploy my sample fine. But when I run the sample, I got - --- Got DataSource: [EMAIL PROTECTED] com.ibm.db2.jcc.b.SqlException: Unable to open file at com.ibm.db2.jcc.b.ig.a(ig.java:93) A simple fix in DB2XA is to only settrace when it is a valid value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-178) Deadlock! while stopping Geronimo server from within Eclipse
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R closed GERONIMODEVTOOLS-178. Fix Version/s: (was: 2.0.0) 2.1.0 This has been addressed in WTP itself (Bug 200715 in WTP) and the fix is available starting from WTP 2.0.1. The earlier temporary fix that was put into GEP has hence been removed. Completed: At revision: 648588 Deadlock! while stopping Geronimo server from within Eclipse Key: GERONIMODEVTOOLS-178 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-178 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.2.0, 1.2.1, 2.0.0 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Fix For: 2.1.0 Attachments: deadlockFix.patch, TestDeadlock.war An interesting deadlock scenario! Here are the steps to reproduce: 1. From within Eclipse start Geronimo server (say 2.0) 2. Deploy attached WAR 3. Access deployed servlet with url http://localhost:8080/TestDeadlock/Test; 4. From within Eclipse invoke Stop server You will see that Stop never returns and Eclipse freezes to respond. 5. Manually kill server process and Eclipse will resume. Here is what is happening: 1. When user invokes Stop on Geronimo server from within Eclipse, Geronimo Eclipse Plug-in invokes stopKernel() in the main Eclipse thread itself. (org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.java::stop()) 2. Server receives the shutdown call, and invokes the deployed WAR's servlet.destroy method, which in turn opens a big text file and starts printing the contents to standard output. 3. All the output buffers overflow because the main thread is the one that should push them to the console view at the end but it is blocked. 4. All the print operations on the server side are blocked waiting for somebody to read the output buffer. The shutdown call will never return. 5. The main Eclipse thread will never print the messages because it waits for the shutdown call to return. Here is one solution thought of: The Geronimo Eclipse plug-in should make the shutdown call in a worker thread not in the main Eclipse thread. In this case the main thread will be able to display all the messages triggered by the shutdown call and everything will work just fine. Attached patch implements this. Please see this also: http://www.eclipse.org/webtools/wst/api/org/eclipse/wst/server/core/model/ServerBehaviourDelegate.html#stop(boolean) It recommends that the plug-in should return from the ServerBehaviourDelegate.stop() method quickly and use the server listener to notify shutdown progress. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3705) Maven 2.0.8 causes build problems
[ https://issues.apache.org/jira/browse/GERONIMO-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-3705: --- Fix Version/s: 2.2 2.1.x 2.1.1 Bruce Snyder reported a very similar problem on a servicemix related project using maven 2.0.7. If this change fixes his problem I think we should apply this change to 2.1.1. Maven 2.0.8 causes build problems - Key: GERONIMO-3705 URL: https://issues.apache.org/jira/browse/GERONIMO-3705 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: Jason Dillon Assignee: David Jencks Priority: Critical Fix For: 2.1.1, 2.1.x, 2.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: branches/2.1.1 created
While the original manifestations of GERONIMO-3705 (build doesn't work with maven 2.0.8) appeared to only apply to maven 2.0.7, Bruce Snyder came up with a problem with identical symptoms using maven 2.0.7. I think if the fix for this issue also fixes the situation he has we should apply the change to 2.1.1. thanks david jencks On Apr 15, 2008, at 3:10 PM, Joe Bohn wrote: I created a branch for 2.1.1 that will be used to prepare for the release. At the moment it is still versioned as 2.1.1-SNAPSHOT. Just prior to this branch I published new 2.1.1-SNAPSHOT artifacts. I also updated the branches/2.1 to 2.1.2-SNAPSHOT. After the change I published 2.1.2-SNAPSHOT artifacts. At the moment the only remaining changes that I am aware of that are necessary for 2.1.1 prior to creating a release candidate are: - Updating to utilize OpenEJB 3.0 - Updating the README and RELEASE_NOTES Joe
Re: svn commit: r648588 - /geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.st.core/src/main/java/org/apache/geronimo/st/core/GeronimoServerBehaviourDelegate.java
On Wed, Apr 16, 2008 at 9:46 AM, [EMAIL PROTECTED] wrote: Author: shivahr Date: Wed Apr 16 00:46:53 2008 New Revision: 648588 URL: http://svn.apache.org/viewvc?rev=648588view=rev Log: GERONIMODEVTOOLS-178 Deadlock while stopping Geronimo server from within Eclipse - Now fixed in WTP itself - Hence undoing the earlier patch. Well, but it does require using the latest (patched) WTP, doesn't it? It's not available in the stable release, I guess. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: svn commit: r648588 - /geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.st.core/src/main/java/org/apache/geronimo/st/core/GeronimoServerBehaviourDelegate.java
On Wed, Apr 16, 2008 at 3:18 PM, Jacek Laskowski [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2008 at 9:46 AM, [EMAIL PROTECTED] wrote: Author: shivahr Date: Wed Apr 16 00:46:53 2008 New Revision: 648588 URL: http://svn.apache.org/viewvc?rev=648588view=rev Log: GERONIMODEVTOOLS-178 Deadlock while stopping Geronimo server from within Eclipse - Now fixed in WTP itself - Hence undoing the earlier patch. Well, but it does require using the latest (patched) WTP, doesn't it? It's not available in the stable release, I guess. Oh! I shld have mentioned that it is available starting from WTP 2.0.1 (and we mention WTP 2.0.2 as the pre-req for GEP 2.0.1). Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl -- Thanks, Shiva
Re: svn commit: r648588 - /geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.st.core/src/main/java/org/apache/geronimo/st/core/GeronimoServerBehaviourDelegate.java
On Wed, Apr 16, 2008 at 12:13 PM, Shiva Kumar H R [EMAIL PROTECTED] wrote: Oh! I shld have mentioned that it is available starting from WTP 2.0.1 (and we mention WTP 2.0.2 as the pre-req for GEP 2.0.1). GEP seems to be the source of information about Eclipse and its ecosystem so this and other information help a lot to stay up-to-date. Thanks. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: svn commit: r648603 - in /geronimo/server/trunk: ./ buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/
On Wed, Apr 16, 2008 at 9:52 AM, [EMAIL PROTECTED] wrote:
Author: djencks
Date: Wed Apr 16 00:52:51 2008
New Revision: 648603
URL: http://svn.apache.org/viewvc?rev=648603view=rev
Log:
GERONIMO-3705 fix build to work with maven 2.0.9
+if (log.isDebugEnabled()) {
+log.debug(Setting + name + = + value);
}
How should I run the plugin to see this printed out? Is -X enough?
(I'm asking before trying out myself hoping others might benefit too).
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
[jira] Commented: (GERONIMODEVTOOLS-256) Publish operation after an Eclipse restart deletes a deployed Web Service's server-config.wsdd file
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589520#action_12589520 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-256: -- Also refer this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=201061 Publish operation after an Eclipse restart deletes a deployed Web Service's server-config.wsdd file - Key: GERONIMODEVTOOLS-256 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-256 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Environment: AG 2.0.2 + Geronimo Eclipse Plug-in v2.0 + WTP 2.0.1 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Fix For: 2.1.0 Steps to recreate: 1) Create a Web Service as per the instructions at http://www.eclipse.org/webtools/jst/components/ws/1.5/tutorials/BottomUpWebService/BottomUpWebService.html 2) Test the web service using (the auto launched) Web Service Explorer. Everything works fine. 3) Shut down server and restart the server. Again launch the web service. It runs fine without any error. 4) Shut down server, close eclipse, restart eclipse, start server. This time try to access the web service and you will not be able to access it. An initial analysis shows that in Step-4 (after a Eclipse Server restart) the Publish operation of Eclipse is deleting server-config.wsdd from GERONIMO_HOME\repository\path-to-deployed-EAR\war name\WEB-INF directory. You will get the following error in the console: 17:01:56,218 ERROR [EngineConfigurationFactoryServlet] Unable to find config file. Creating new servlet engine config file: /WEB-INF/server-config.wsdd Is this related to the issue reported in http://mail-archive.ow2.org/jonas-team/2006-08/msg00046.html ? Needs to be explored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3957) Updating svn:ignore lists
[ https://issues.apache.org/jira/browse/GERONIMO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Zakharov updated GERONIMO-3957: -- Attachment: SVNPropPatch.java I've found no reasonable way to create a transferable patch containing SVN property changes, so I've created a script (SVNPropPatch.java, attached) converting the `svn diff` output to a shell script making the necessary changes. The script is supposed to work as follows: $ cd GeronimoTrunk $ cat Geronimo-3957-Trunk.patch | java SVNPropPatch Geronimo-3957-Trunk.sh $ chmod +x Geronimo-3957-Trunk.sh $ ./Geronimo-3957-Trunk.sh Updating svn:ignore lists - Key: GERONIMO-3957 URL: https://issues.apache.org/jira/browse/GERONIMO-3957 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.0.2, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3957-20.patch, Geronimo-3957-21.patch, Geronimo-3957-210.patch , Geronimo-3957-Trunk.patch, Geronimo-3957-Trunk.patch, SVNPropPatch.java When trying to create a patch in an already-built environment, a lot of build-generated directories get in the way. Probably they just need to be added to the corresponding SVN ignore list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3957) Updating svn:ignore lists
[ https://issues.apache.org/jira/browse/GERONIMO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589537#action_12589537 ] Vasily Zakharov commented on GERONIMO-3957: --- The issue has some discussion history since more than a year ago: http://thread.gmane.org/gmane.comp.java.geronimo.devel/44831 http://thread.gmane.org/gmane.comp.java.geronimo.devel/47357 http://thread.gmane.org/gmane.comp.java.geronimo.devel/61416 Updating svn:ignore lists - Key: GERONIMO-3957 URL: https://issues.apache.org/jira/browse/GERONIMO-3957 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.0.2, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3957-20.patch, Geronimo-3957-21.patch, Geronimo-3957-210.patch , Geronimo-3957-Trunk.patch, Geronimo-3957-Trunk.patch, SVNPropPatch.java When trying to create a patch in an already-built environment, a lot of build-generated directories get in the way. Probably they just need to be added to the corresponding SVN ignore list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[DISCUSS] setting svn:ignore properties
Hi, all, I've noticed that in many places in Geronimo repository the files and subdirectories generated by build scripts are put to svn:ignore properties of the corresponding directories, so that they do not get in the way when checking a working copy status and preparing a patch/commit. However in some other (newer?) places the build-generated files and subdirectories are not being added to svn:ignore properties. I think that it worths to have a consistent policy in this matter. Personally, I think that it makes sense to add all the known build-generated files and directories to the corresponding local svn:ignore, as svn:ignore idea is to mark the files and directories that are not going to be committed to repository. So if our build generates something somewhere and we know that it generates that, and we know we're not going to commit that (like 'build', 'target' directories, log files etc.) - let's mark it so. On the other hand, one can configure his own ~/.subversion/config [global-ignores] property to ignore some file patterns throughout the whole repository. However, this approach is good for some personal settings, and it has its disadvantages: first, it's needed to be done by each developer; second, it creates a risk of hiding some important files being hidden by some global wildcard; third, it's a global-only setting that can't go into details of particular build parts. Using local svn:ignore properties looks preferable as it only covers the particular files in particular directory. What would you people say? There's an issue created with proposed patches on this issue, it's http://issues.apache.org/jira/browse/GERONIMO-3957. Also, this issue already had some intensive discussions since a year ago, please check them also: http://thread.gmane.org/gmane.comp.java.geronimo.devel/44831 http://thread.gmane.org/gmane.comp.java.geronimo.devel/47357 http://thread.gmane.org/gmane.comp.java.geronimo.devel/61416 Thanks! Vasily
[jira] Commented: (GERONIMODEVTOOLS-312) Reimplement fixGeronimo*Schema() functions inside GeronimRuntime classes using JAXB
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589544#action_12589544 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-312: -- Redundant code after above fix has been deleted at revision: 648689 Reimplement fixGeronimo*Schema() functions inside GeronimRuntime classes using JAXB --- Key: GERONIMODEVTOOLS-312 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-312 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Shiva Kumar H R Assignee: Tim McConnell Priority: Critical Fix For: 2.1.0 The fixGeronimo*Schema() function inside GeronimRuntime classes is curently implemented using XMLBeans. As part of GERONIMODEVTOOLS-295, xmlbeans-2.3.0.jar has been removed from GEP's dependencies. Hence fixGeronimo*Schema() functionality needs to be reimplemented using JAXB. Classes to be changed: 1) org.apache.geronimo.st.core.IGeronimoRuntime 2) org.apache.geronimo.st.core.operations.ImportDeploymentPlanOperation 3) org.apache.geronimo.st.v11.core.GeronimoRuntime 4) org.apache.geronimo.st.v20.core.GeronimoRuntime 5) org.apache.geronimo.st.v21.core.GeronimoRuntime -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-190) Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc)
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589551#action_12589551 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-190: -- This has been finally resolved :) by following JIRAs: a) GERONIMODEVTOOLS-278 (Model framework for G deployment plans - Change from existing EMF to JAXB) b) GERONIMODEVTOOLS-312 (Reimplement fixGeronimo*Schema() functions inside GeronimRuntime classes using JAXB). Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc) --- Key: GERONIMODEVTOOLS-190 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Reporter: Shiva Kumar H R Assignee: Tim McConnell Fix For: 2.1.0 Attachments: HelloWorld.war Import the attached HelloWorld.war and double click on geronimo-web.xml. An error window will pop up saying .. elements in the plan may not be qualified ... This is caused by trying to parse v2.0 of Geronimo plans with v1.1 of schemas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3957) Updating svn:ignore lists
[ https://issues.apache.org/jira/browse/GERONIMO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589553#action_12589553 ] Vasily Zakharov commented on GERONIMO-3957: --- And the final discussion: http://thread.gmane.org/gmane.comp.java.geronimo.devel/61550 Updating svn:ignore lists - Key: GERONIMO-3957 URL: https://issues.apache.org/jira/browse/GERONIMO-3957 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.0.2, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3957-20.patch, Geronimo-3957-21.patch, Geronimo-3957-210.patch , Geronimo-3957-Trunk.patch, Geronimo-3957-Trunk.patch, SVNPropPatch.java When trying to create a patch in an already-built environment, a lot of build-generated directories get in the way. Probably they just need to be added to the corresponding SVN ignore list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-190) Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc)
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R closed GERONIMODEVTOOLS-190. Resolution: Fixed Assignee: Shiva Kumar H R (was: Tim McConnell) Fixed in trunk which will soon be released as GEP v2.1.0. Meanwhile anyone interested in trying it out can use the weekly builds available from http://people.apache.org/dist/geronimo/eclipse/unstable/2.1.0/ . Error opening v2.0 of Geronimo plans (which point to web-2.0, naming-1.2, security-2.0, deployment-1.2 etc) --- Key: GERONIMODEVTOOLS-190 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-190 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Fix For: 2.1.0 Attachments: HelloWorld.war Import the attached HelloWorld.war and double click on geronimo-web.xml. An error window will pop up saying .. elements in the plan may not be qualified ... This is caused by trying to parse v2.0 of Geronimo plans with v1.1 of schemas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-189) Error opening geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R resolved GERONIMODEVTOOLS-189. -- Resolution: Duplicate Assignee: Shiva Kumar H R (was: Tim McConnell) Duplicate of GERONIMODEVTOOLS-190. Error opening geronimo-web.xml -- Key: GERONIMODEVTOOLS-189 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-189 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.x Environment: Eclipse SDK Version: 3.3.0 Build id: I20070525-1350 Build id: I20070625-1500 Latest August 23 build from unstable Reporter: Shane Blake Assignee: Shiva Kumar H R Fix For: 2.1.0 Opening geronimo-web.xml getting the following stack trace: java.lang.IllegalArgumentException at org.eclipse.wst.server.core.internal.facets.FacetUtil.getRuntime(FacetUtil.java:61) at org.eclipse.jst.server.core.FacetUtil.getRuntime(FacetUtil.java:47) at org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.getLoader(SharedDeploymentPlanEditor.java:97) at org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.loadDeploymentPlan(SharedDeploymentPlanEditor.java:86) at org.apache.geronimo.st.ui.editors.AbstractGeronimoDeploymentPlanEditor.init(AbstractGeronimoDeploymentPlanEditor.java:181) at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:794) at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:643) at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592) at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299) at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179) at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:268) at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65) at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:400) at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256) at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209) at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604) at org.eclipse.ui.internal.PartStack.add(PartStack.java:499) at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103) at org.eclipse.ui.internal.PartStack.add(PartStack.java:485) at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112) at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63) at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217) at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207) at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774) at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673) at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633) at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625) at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2547) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:644) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:603) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:285) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:138) at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:194) at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:175) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:268) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:244) at org.eclipse.jdt.internal.ui.navigator.OpenAndExpand.run(OpenAndExpand.java:50)
[BUILD] branches/2.1: Failed for Revision: 648672
Geronimo Revision: 648672 built with tests included See the full build-0800.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080416/build-0800.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.1/20080416 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 32 minutes 3 seconds [INFO] Finished at: Wed Apr 16 08:45:57 EDT 2008 [INFO] Final Memory: 304M/1012M [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/20080416/logs-0800-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080416/logs-0800-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 76.131 sec FAILURE! Samples: branches/2.1 = Log: http://people.apache.org/builds/geronimo/server/binaries/2.1/20080416/samples-0800.log Build status: OK
[jira] Resolved: (GERONIMODEVTOOLS-192) Change configuration to module.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R resolved GERONIMODEVTOOLS-192. -- Resolution: Fixed Assignee: Shiva Kumar H R (was: Tim McConnell) Completed: At revision: 648705 Thanks Kan Ogawa for the patch. Change configuration to module. --- Key: GERONIMODEVTOOLS-192 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-192 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.1.0, 1.2.0 Reporter: Kan Ogawa Assignee: Shiva Kumar H R Fix For: 2.1.0 Attachments: GeronimoDevTools-192.patch, GeronimoDevTools-192_2.patch Since Geronimo server v1.1, the word configuration was replaced to the word module. See the GERONIMO-1987 issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-327) Unable to detect Geronimo V1.1 JAXB Models plugin.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R resolved GERONIMODEVTOOLS-327. -- Resolution: Fixed Assignee: Shiva Kumar H R (was: Kan Ogawa) Completed: At revision: 648702 Thanks Kan Ogawa for pointing this out. Unable to detect Geronimo V1.1 JAXB Models plugin. -- Key: GERONIMODEVTOOLS-327 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-327 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Kan Ogawa Assignee: Shiva Kumar H R Fix For: 2.1.0 Attachments: GeronimoDevTools-327.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[DISCUSS] Policy for granting write access to our Wiki
All, To properly protect the IP rights of our Wiki-based documentation, we need to stop allowing unrestricted write access to our Wiki. Wiki contributors should be required to have an ICLA on file with the ASF. I also think that we need to hold a PMC vote before granting this access. I'll also take this opportunity to remind the community that Wiki updates are sent to [EMAIL PROTECTED] These updates need to be reviewed by the community, just like all code updates. IMO, we don't want this to be a heavy-weight process. We don't want there to be a significant hurdle to contributing documentation. For code updates, patch files attached to Jira's with the Grant license to ASF button checked takes care of these IP concerns. To my knowledge, there's no patch file equivalent for updates to a Wiki. We could require that documentation updates be contributed in the form of simple ascii text files that are attached to a Jira. This would address our IP concerns, but is not ideal IMO. To keep this as light-weight as possible, I propose we formalize the concept of contributor. A contributor would have write access to our Wiki documentation as well as the ability to assign Jira's to him/ herself. I think the process would go something like this... 0. Reset write access to our wiki to be only the current set of committers on the project. 1. New documentation contributions from non-committers/contributors must be submitted via a Jira, with the Grant License to the ASF box checked. This is just like any code/bug-fix submission. 2. Once a new participant has expressed interest in contributing to the project and/or has contributed documentation or bug fixes, a PMC vote will be called to grant the new participant contributor rights. As all PMC votes, this vote is a majority vote, require a minimum of 3 +1 votes, and will last for a minimum of 72 hours. 3. Once a vote has passed, the participant will be invited to join the project as a 'contributor'. Assuming he/she accepts, the participant must then submit an ICLA to the ASF. Once the ICLA is on file, the new 'contributor' will give given write access to our wiki and the ability to assign Jira's. 4. The new contributor will be announced to the community. I've grouped Jira rights with wiki rights in the above. This is not strictly necessary, but grouping the two seems like a reasonable step. This is my first pass at a proposal. We can tweak this process in a number of ways and there are alternatives. I think the hard requirements are 1) the PMC must vote and 2) an ICLA must be filed with the ASF. Until we resolve this issue, we need to restrict Wiki write access to be the current set of Geronimo committers. --kevan
Re: branches/2.1.1 created
David Jencks wrote: While the original manifestations of GERONIMO-3705 (build doesn't work with maven 2.0.8) appeared to only apply to maven 2.0.7, Bruce Snyder came up with a problem with identical symptoms using maven 2.0.7. I think if the fix for this issue also fixes the situation he has we should apply the change to 2.1.1. thanks david jencks Do you have an idea when we will know if this does in fact resolve the issue? I'm not opposed to it if we will know fairly soon. I still have to work on the release notes (unless somebody else wants to do this :-) ) and ensure that I can create the necessary artifacts before I can create a release candidate. Joe On Apr 15, 2008, at 3:10 PM, Joe Bohn wrote: I created a branch for 2.1.1 that will be used to prepare for the release. At the moment it is still versioned as 2.1.1-SNAPSHOT. Just prior to this branch I published new 2.1.1-SNAPSHOT artifacts. I also updated the branches/2.1 to 2.1.2-SNAPSHOT. After the change I published 2.1.2-SNAPSHOT artifacts. At the moment the only remaining changes that I am aware of that are necessary for 2.1.1 prior to creating a release candidate are: - Updating to utilize OpenEJB 3.0 - Updating the README and RELEASE_NOTES Joe
[jira] Commented: (GERONIMO-3864) Security warning about installation a certificate from a CA claiming to represent: Me
[ https://issues.apache.org/jira/browse/GERONIMO-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589578#action_12589578 ] Rustam Abdullaev commented on GERONIMO-3864: Happens for me as well, on every start. Java 1.6.0_01-b06. Geronimo/Tomcat 2.1. Message is shown by CSRSS at: main prio=6 tid=0x00397400 nid=0xa00 runnable [0x009de000..0x009dfe5c] java.lang.Thread.State: RUNNABLE at sun.security.mscapi.KeyStore.storeCertificate(Native Method) at sun.security.mscapi.KeyStore.access$300(KeyStore.java:41) at sun.security.mscapi.KeyStore$KeyEntry.setCertificateChain(KeyStore.java:153) at sun.security.mscapi.KeyStore.engineSetCertificateEntry(KeyStore.java:482) at sun.security.mscapi.KeyStore$ROOT.engineSetCertificateEntry(KeyStore.java:49) at java.security.KeyStore.setCertificateEntry(KeyStore.java:941) at org.apache.geronimo.crypto.KeystoreUtil.clinit(KeystoreUtil.java:105) at org.apache.geronimo.tomcat.TomcatManagerImpl.addSslConnectorAttributes(TomcatManagerImpl.java:450) at org.apache.geronimo.tomcat.TomcatManagerImpl.clinit(TomcatManagerImpl.java:101) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:534) - locked 0x031deed8 (a org.apache.geronimo.kernel.config.EditableKernelConfigurationManager) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$9dce2cbf.startConfiguration(generated) at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:156) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30) Security warning about installation a certificate from a CA claiming to represent: Me - Key: GERONIMO-3864 URL: https://issues.apache.org/jira/browse/GERONIMO-3864 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Environment: C:\geronimo-tomcat6-javaee5-2.1 Mon 02/18/2008 23:53:25.17 ver Microsoft Windows XP [Version 5.1.2600] C:\geronimo-tomcat6-javaee5-2.1 Mon 02/18/2008 23:53:27.43 java -version java version 1.6.0_03 Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) C:\geronimo-tomcat6-javaee5-2.1 Mon 02/18/2008 23:53:30.79 echo %JAVA_HOME% c:\apps\java6
[jira] Issue Comment Edited: (GERONIMO-3864) Security warning about installation a certificate from a CA claiming to represent: Me
[ https://issues.apache.org/jira/browse/GERONIMO-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589578#action_12589578 ] rustamabd edited comment on GERONIMO-3864 at 4/16/08 7:33 AM: - Happens for me as well, on every start. Java 1.6.0_01-b06. Geronimo/Tomcat 2.1. Message is shown by CSRSS at: main prio=6 tid=0x00397400 nid=0xa00 runnable [0x009de000..0x009dfe5c] java.lang.Thread.State: RUNNABLE at sun.security.mscapi.KeyStore.storeCertificate(Native Method) at sun.security.mscapi.KeyStore.access$300(KeyStore.java:41) at sun.security.mscapi.KeyStore$KeyEntry.setCertificateChain(KeyStore.java:153) at sun.security.mscapi.KeyStore.engineSetCertificateEntry(KeyStore.java:482) at sun.security.mscapi.KeyStore$ROOT.engineSetCertificateEntry(KeyStore.java:49) at java.security.KeyStore.setCertificateEntry(KeyStore.java:941) at org.apache.geronimo.crypto.KeystoreUtil.clinit(KeystoreUtil.java:105) at org.apache.geronimo.tomcat.TomcatManagerImpl.addSslConnectorAttributes(TomcatManagerImpl.java:450) at org.apache.geronimo.tomcat.TomcatManagerImpl.clinit(TomcatManagerImpl.java:101) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:534) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$9dce2cbf.startConfiguration(generated) at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:156) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30) was (Author: rustamabd): Happens for me as well, on every start. Java 1.6.0_01-b06. Geronimo/Tomcat 2.1. Message is shown by CSRSS at: main prio=6 tid=0x00397400 nid=0xa00 runnable [0x009de000..0x009dfe5c] java.lang.Thread.State: RUNNABLE at sun.security.mscapi.KeyStore.storeCertificate(Native Method) at sun.security.mscapi.KeyStore.access$300(KeyStore.java:41) at sun.security.mscapi.KeyStore$KeyEntry.setCertificateChain(KeyStore.java:153) at sun.security.mscapi.KeyStore.engineSetCertificateEntry(KeyStore.java:482) at sun.security.mscapi.KeyStore$ROOT.engineSetCertificateEntry(KeyStore.java:49) at java.security.KeyStore.setCertificateEntry(KeyStore.java:941) at org.apache.geronimo.crypto.KeystoreUtil.clinit(KeystoreUtil.java:105) at org.apache.geronimo.tomcat.TomcatManagerImpl.addSslConnectorAttributes(TomcatManagerImpl.java:450) at
Geronimo specs jars in OSGi
In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Reopened: (GERONIMODEVTOOLS-246) Classpath Container Extension Point
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell reopened GERONIMODEVTOOLS-246: Classpath Container Extension Point --- Key: GERONIMODEVTOOLS-246 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-246 Project: Geronimo-Devtools Issue Type: New Feature Components: eclipse-plugin Affects Versions: 2.0.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-223) J2EE module dependencies losting
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-223: - Fix Version/s: 2.1.0 This might be a duplicate of GERONIMODEVTOOLS-251 J2EE module dependencies losting Key: GERONIMODEVTOOLS-223 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-223 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.2 Environment: Eclipse 3.3 + GEP (win32) Reporter: Tomasz Mazan Assignee: Tim McConnell Fix For: 2.1.0 I got J2EE project + 2 EJB projects. J2EE project has defined module dependencies - uses both of my ejb projects. From time to time it losts one of dependency and I have to set it again using project properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-246) Classpath Container Extension Point
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-246. -- Resolution: Duplicate Closing as a duplicate of https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-185 Classpath Container Extension Point --- Key: GERONIMODEVTOOLS-246 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-246 Project: Geronimo-Devtools Issue Type: New Feature Components: eclipse-plugin Affects Versions: 2.0.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r648603 - in /geronimo/server/trunk: ./ buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/
On Apr 16, 2008, at 2:47 AM, Jacek Laskowski wrote:
On Wed, Apr 16, 2008 at 9:52 AM, [EMAIL PROTECTED] wrote:
Author: djencks
Date: Wed Apr 16 00:52:51 2008
New Revision: 648603
URL: http://svn.apache.org/viewvc?rev=648603view=rev
Log:
GERONIMO-3705 fix build to work with maven 2.0.9
+if (log.isDebugEnabled()) {
+log.debug(Setting + name + = + value);
}
How should I run the plugin to see this printed out? Is -X enough?
(I'm asking before trying out myself hoping others might benefit too).
Yes! that works.
thanks
david jencks
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Geronimo specs jars in OSGi
I'd like to see an example in action before I commit myself but so far I don't see any problems with this. I assume you have already or will soon verify this doesn't cause problems with the tck :-) I wonder if a package name with osgi in it somewhere would be more appropriate? There are some specs (jacc for instance) that use a system property to figure out what to create. I've always thought this was a less than brilliant idea and wonder if we can do something similar for those. I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. I'm looking forward to seeing what you have in mind. thanks david jencks On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Updated: (GERONIMO-3957) Updating svn:ignore lists
[ https://issues.apache.org/jira/browse/GERONIMO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Zakharov updated GERONIMO-3957: -- Attachment: Geronimo-3957-210.patch Geronimo-3957-21.patch Geronimo-3957-20.patch Updating svn:ignore lists - Key: GERONIMO-3957 URL: https://issues.apache.org/jira/browse/GERONIMO-3957 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.0.2, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3957-20.patch, Geronimo-3957-20.patch, Geronimo-3957-21.patch, Geronimo-3957-21.patch, Geronimo-3957-210.patch, Geronimo-3957-210.patch , Geronimo-3957-Trunk.patch, Geronimo-3957-Trunk.patch, SVNPropPatch.java When trying to create a patch in an already-built environment, a lot of build-generated directories get in the way. Probably they just need to be added to the corresponding SVN ignore list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3957) Updating svn:ignore lists
[ https://issues.apache.org/jira/browse/GERONIMO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Zakharov updated GERONIMO-3957: -- Attachment: Geronimo-3957-21.sh Geronimo-3957-20.sh Geronimo-3957-Trunk.patch Updating svn:ignore lists - Key: GERONIMO-3957 URL: https://issues.apache.org/jira/browse/GERONIMO-3957 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.0.2, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3957-20.patch, Geronimo-3957-20.patch, Geronimo-3957-20.sh, Geronimo-3957-21.patch, Geronimo-3957-21.patch, Geronimo-3957-21.sh, Geronimo-3957-210.patch, Geronimo-3957-210.patch , Geronimo-3957-Trunk.patch, Geronimo-3957-Trunk.patch, Geronimo-3957-Trunk.patch, SVNPropPatch.java When trying to create a patch in an already-built environment, a lot of build-generated directories get in the way. Probably they just need to be added to the corresponding SVN ignore list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3957) Updating svn:ignore lists
[ https://issues.apache.org/jira/browse/GERONIMO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Zakharov updated GERONIMO-3957: -- Attachment: (was: Geronimo-3957-21.patch) Updating svn:ignore lists - Key: GERONIMO-3957 URL: https://issues.apache.org/jira/browse/GERONIMO-3957 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.0.2, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3957-20.patch, Geronimo-3957-20.sh, Geronimo-3957-21.patch, Geronimo-3957-21.sh, Geronimo-3957-210.patch, Geronimo-3957-210.sh, Geronimo-3957-Trunk.patch, Geronimo-3957-Trunk.sh, SVNPropPatch.java When trying to create a patch in an already-built environment, a lot of build-generated directories get in the way. Probably they just need to be added to the corresponding SVN ignore list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3957) Updating svn:ignore lists
[ https://issues.apache.org/jira/browse/GERONIMO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Zakharov updated GERONIMO-3957: -- Attachment: (was: Geronimo-3957-Trunk.patch) Updating svn:ignore lists - Key: GERONIMO-3957 URL: https://issues.apache.org/jira/browse/GERONIMO-3957 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.0.2, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3957-20.patch, Geronimo-3957-20.sh, Geronimo-3957-21.patch, Geronimo-3957-21.sh, Geronimo-3957-210.patch, Geronimo-3957-210.sh, Geronimo-3957-Trunk.patch, Geronimo-3957-Trunk.sh, SVNPropPatch.java When trying to create a patch in an already-built environment, a lot of build-generated directories get in the way. Probably they just need to be added to the corresponding SVN ignore list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3957) Updating svn:ignore lists
[ https://issues.apache.org/jira/browse/GERONIMO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Zakharov updated GERONIMO-3957: -- Attachment: (was: Geronimo-3957-20.patch) Updating svn:ignore lists - Key: GERONIMO-3957 URL: https://issues.apache.org/jira/browse/GERONIMO-3957 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.0.2, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3957-20.patch, Geronimo-3957-20.sh, Geronimo-3957-21.patch, Geronimo-3957-21.sh, Geronimo-3957-210.patch, Geronimo-3957-210.sh, Geronimo-3957-Trunk.patch, Geronimo-3957-Trunk.sh, SVNPropPatch.java When trying to create a patch in an already-built environment, a lot of build-generated directories get in the way. Probably they just need to be added to the corresponding SVN ignore list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3957) Updating svn:ignore lists
[ https://issues.apache.org/jira/browse/GERONIMO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Zakharov updated GERONIMO-3957: -- Attachment: (was: Geronimo-3957-210.patch ) Updating svn:ignore lists - Key: GERONIMO-3957 URL: https://issues.apache.org/jira/browse/GERONIMO-3957 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.0.2, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3957-20.patch, Geronimo-3957-20.sh, Geronimo-3957-21.patch, Geronimo-3957-21.sh, Geronimo-3957-210.patch, Geronimo-3957-210.sh, Geronimo-3957-Trunk.patch, Geronimo-3957-Trunk.sh, SVNPropPatch.java When trying to create a patch in an already-built environment, a lot of build-generated directories get in the way. Probably they just need to be added to the corresponding SVN ignore list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3957) Updating svn:ignore lists
[ https://issues.apache.org/jira/browse/GERONIMO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Zakharov updated GERONIMO-3957: -- Attachment: Geronimo-3957-Trunk.sh Geronimo-3957-210.sh Attached the updated patches and the generated scripts to apply. Updating svn:ignore lists - Key: GERONIMO-3957 URL: https://issues.apache.org/jira/browse/GERONIMO-3957 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.0.2, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3957-20.patch, Geronimo-3957-20.sh, Geronimo-3957-21.patch, Geronimo-3957-21.sh, Geronimo-3957-210.patch, Geronimo-3957-210.sh, Geronimo-3957-Trunk.patch, Geronimo-3957-Trunk.sh, SVNPropPatch.java When trying to create a patch in an already-built environment, a lot of build-generated directories get in the way. Probably they just need to be added to the corresponding SVN ignore list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3957) Updating svn:ignore lists
[ https://issues.apache.org/jira/browse/GERONIMO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Zakharov updated GERONIMO-3957: -- Attachment: (was: Geronimo-3957-Trunk.patch) Updating svn:ignore lists - Key: GERONIMO-3957 URL: https://issues.apache.org/jira/browse/GERONIMO-3957 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.0.2, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3957-20.patch, Geronimo-3957-20.sh, Geronimo-3957-21.patch, Geronimo-3957-21.sh, Geronimo-3957-210.patch, Geronimo-3957-210.sh, Geronimo-3957-Trunk.patch, Geronimo-3957-Trunk.sh, SVNPropPatch.java When trying to create a patch in an already-built environment, a lot of build-generated directories get in the way. Probably they just need to be added to the corresponding SVN ignore list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] setting svn:ignore properties
I agree that the current situation is bad. I would like to resolve it by: - removing all custom svn:ignore properties - providing some documentation on setting up your global ignores - making sure that we don't require any non-standard svn:ignore settings. Here's why: - having to set up svn:ignore for a new project is too hard. I never remember :-). Anyone using maven needs to have target in their global svn ignores anyway. - you need global svn ignores anyway for the IDE-specific files like .ipr for IDEA. Our checked-in svn:ignore settings definitely should not cater to any particular IDE - basic maven hygiene requires that everything except such IDE files and target be checked in. thanks david jencks On Apr 16, 2008, at 6:15 AM, Vasily Zakharov wrote: Hi, all, I've noticed that in many places in Geronimo repository the files and subdirectories generated by build scripts are put to svn:ignore properties of the corresponding directories, so that they do not get in the way when checking a working copy status and preparing a patch/commit. However in some other (newer?) places the build-generated files and subdirectories are not being added to svn:ignore properties. I think that it worths to have a consistent policy in this matter. Personally, I think that it makes sense to add all the known build-generated files and directories to the corresponding local svn:ignore, as svn:ignore idea is to mark the files and directories that are not going to be committed to repository. So if our build generates something somewhere and we know that it generates that, and we know we're not going to commit that (like 'build', 'target' directories, log files etc.) - let's mark it so. On the other hand, one can configure his own ~/.subversion/config [global-ignores] property to ignore some file patterns throughout the whole repository. However, this approach is good for some personal settings, and it has its disadvantages: first, it's needed to be done by each developer; second, it creates a risk of hiding some important files being hidden by some global wildcard; third, it's a global-only setting that can't go into details of particular build parts. Using local svn:ignore properties looks preferable as it only covers the particular files in particular directory. What would you people say? There's an issue created with proposed patches on this issue, it's http://issues.apache.org/jira/browse/GERONIMO-3957. Also, this issue already had some intensive discussions since a year ago, please check them also: http://thread.gmane.org/gmane.comp.java.geronimo.devel/44831 http://thread.gmane.org/gmane.comp.java.geronimo.devel/47357 http://thread.gmane.org/gmane.comp.java.geronimo.devel/61416 Thanks! Vasily
Re: [DISCUSS] Policy for granting write access to our Wiki
I agree that this should be as light-weight as possible. There are a couple of suggestions that I would make to the process: 1) Make sure that people are aware of the fact that they can submit an ICLA at any time (not just after we have voted). 2) We should standardize on the format of the documents to be attached to JIRA. Or at least suggest a preferred format. Without edit rights to the wiki, it is (for me at least) difficult to create 'wiki marked up' text from scratch. Having rich text be the preferred format would (almost) ensure that anyone would be able to create documents. 3) We should try to determine who has already contributed to the wiki but is not a committer and try to 'fast-track' getting those people's CLAs in and votes started. Lastly, I have a question. Do we need to go back and get the previous contributions resubmitted? I assume that we will. Jay Kevan Miller wrote: All, To properly protect the IP rights of our Wiki-based documentation, we need to stop allowing unrestricted write access to our Wiki. Wiki contributors should be required to have an ICLA on file with the ASF. I also think that we need to hold a PMC vote before granting this access. I'll also take this opportunity to remind the community that Wiki updates are sent to [EMAIL PROTECTED] These updates need to be reviewed by the community, just like all code updates. IMO, we don't want this to be a heavy-weight process. We don't want there to be a significant hurdle to contributing documentation. For code updates, patch files attached to Jira's with the Grant license to ASF button checked takes care of these IP concerns. To my knowledge, there's no patch file equivalent for updates to a Wiki. We could require that documentation updates be contributed in the form of simple ascii text files that are attached to a Jira. This would address our IP concerns, but is not ideal IMO. To keep this as light-weight as possible, I propose we formalize the concept of contributor. A contributor would have write access to our Wiki documentation as well as the ability to assign Jira's to him/herself. I think the process would go something like this... 0. Reset write access to our wiki to be only the current set of committers on the project. 1. New documentation contributions from non-committers/contributors must be submitted via a Jira, with the Grant License to the ASF box checked. This is just like any code/bug-fix submission. 2. Once a new participant has expressed interest in contributing to the project and/or has contributed documentation or bug fixes, a PMC vote will be called to grant the new participant contributor rights. As all PMC votes, this vote is a majority vote, require a minimum of 3 +1 votes, and will last for a minimum of 72 hours. 3. Once a vote has passed, the participant will be invited to join the project as a 'contributor'. Assuming he/she accepts, the participant must then submit an ICLA to the ASF. Once the ICLA is on file, the new 'contributor' will give given write access to our wiki and the ability to assign Jira's. 4. The new contributor will be announced to the community. I've grouped Jira rights with wiki rights in the above. This is not strictly necessary, but grouping the two seems like a reasonable step. This is my first pass at a proposal. We can tweak this process in a number of ways and there are alternatives. I think the hard requirements are 1) the PMC must vote and 2) an ICLA must be filed with the ASF. Until we resolve this issue, we need to restrict Wiki write access to be the current set of Geronimo committers. --kevan
Re: [DISCUSS] Policy for granting write access to our Wiki
Hey Kevan, Thanks for bringing this up. Potential IP issues with our documentation is a reality and I agree we need a process for controlling contributions. Some comments inline Kevan Miller wrote: All, To properly protect the IP rights of our Wiki-based documentation, we need to stop allowing unrestricted write access to our Wiki. Wiki contributors should be required to have an ICLA on file with the ASF. I also think that we need to hold a PMC vote before granting this access. Agreed, ICLA and vote should be a must but, how do we deal current contributors that are not so actively involved in the mailing lists? For example, there are contributors that are working (mostly off line) on translating content. How would we incorporate such translated content? I'll also take this opportunity to remind the community that Wiki updates are sent to [EMAIL PROTECTED] These updates need to be reviewed by the community, just like all code updates. yup, good reminder. I would like to see more feedback on the doc updates as well. IMO, we don't want this to be a heavy-weight process. We don't want there to be a significant hurdle to contributing documentation. For code updates, patch files attached to Jira's with the Grant license to ASF button checked takes care of these IP concerns. To my knowledge, there's no patch file equivalent for updates to a Wiki. We could require that documentation updates be contributed in the form of simple ascii text files that are attached to a Jira. This would address our IP concerns, but is not ideal IMO. I think you could do some wiki formatting in the JIRA itself but extracting the doc from the JIRA may be unpractical. Plain text files and images attached may work as long as the text file is using the wiki markup and following the [Tips for writing and formatting documentation|http://cwiki.apache.org/geronimo/tips-for-writing-and-formatting-documentation.html] Maybe we can use a staging space (sorta like the wiki sandbox) to develop the content there, then open a JIRA pointing to that page and specific version in the staging wiki space. The JIRA could include an abstract and where it should be placed within the official doc. In either case, we should always check the content for technical accuracy, relevance and formatting as well before incorporating it into the doc. To keep this as light-weight as possible, I propose we formalize the concept of contributor. A contributor would have write access to our Wiki documentation as well as the ability to assign Jira's to him/herself. I understand the point, this may help us get started but it will chase us down the road. I'm certainly not in favor of having multiple levels of Geronimo committers. We need to figure out another way to do this; otherwise becoming a contributor could potentially be a dead-end towards committership. I think the process would go something like this... 0. Reset write access to our wiki to be only the current set of committers on the project. 1. New documentation contributions from non-committers/contributors must be submitted via a Jira, with the Grant License to the ASF box checked. This is just like any code/bug-fix submission. 2. Once a new participant has expressed interest in contributing to the project and/or has contributed documentation or bug fixes, a PMC vote will be called to grant the new participant contributor rights. As all PMC votes, this vote is a majority vote, require a minimum of 3 +1 votes, and will last for a minimum of 72 hours. How would this work for existing contributors? 3. Once a vote has passed, the participant will be invited to join the project as a 'contributor'. Assuming he/she accepts, the participant must then submit an ICLA to the ASF. Once the ICLA is on file, the new 'contributor' will give given write access to our wiki and the ability to assign Jira's. Again, the contributor vs committer thingy doesn't look quite right to me. 4. The new contributor will be announced to the community. I've grouped Jira rights with wiki rights in the above. This is not strictly necessary, but grouping the two seems like a reasonable step. This is my first pass at a proposal. We can tweak this process in a number of ways and there are alternatives. I think the hard requirements are 1) the PMC must vote and 2) an ICLA must be filed with the ASF. Until we resolve this issue, we need to restrict Wiki write access to be the current set of Geronimo committers. So, are we talking of restricting a particular space or all GMOx...? We should at least leave the wiki sandbox (GMOxSBOX) out of this restriction This is not a trivial thing, there are currently a number of non-committers contributing to the documentation. I think we would do more harm than good if we suddenly stop them from contributing content. Again, I see the issue and agree we need to act rather sooner than later, but before we pull down the
Re: [DISCUSS] Policy for granting write access to our Wiki
Are we breaking new ground here? I'd suspect that the other projects that are using the Wiki may have already discussed this and may have a resolution. Thanks to Miller, Miller and Miller for their awareness of the legal ramifications; I missed it and its a good point. On Apr 16, 2008, at 10:00 AM, Kevan Miller wrote: All, To properly protect the IP rights of our Wiki-based documentation, we need to stop allowing unrestricted write access to our Wiki. Wiki contributors should be required to have an ICLA on file with the ASF. I also think that we need to hold a PMC vote before granting this access. I'll also take this opportunity to remind the community that Wiki updates are sent to [EMAIL PROTECTED] These updates need to be reviewed by the community, just like all code updates. IMO, we don't want this to be a heavy-weight process. We don't want there to be a significant hurdle to contributing documentation. For code updates, patch files attached to Jira's with the Grant license to ASF button checked takes care of these IP concerns. To my knowledge, there's no patch file equivalent for updates to a Wiki. We could require that documentation updates be contributed in the form of simple ascii text files that are attached to a Jira. This would address our IP concerns, but is not ideal IMO. To keep this as light-weight as possible, I propose we formalize the concept of contributor. A contributor would have write access to our Wiki documentation as well as the ability to assign Jira's to him/herself. I think the process would go something like this... 0. Reset write access to our wiki to be only the current set of committers on the project. 1. New documentation contributions from non-committers/contributors must be submitted via a Jira, with the Grant License to the ASF box checked. This is just like any code/bug-fix submission. 2. Once a new participant has expressed interest in contributing to the project and/or has contributed documentation or bug fixes, a PMC vote will be called to grant the new participant contributor rights. As all PMC votes, this vote is a majority vote, require a minimum of 3 +1 votes, and will last for a minimum of 72 hours. 3. Once a vote has passed, the participant will be invited to join the project as a 'contributor'. Assuming he/she accepts, the participant must then submit an ICLA to the ASF. Once the ICLA is on file, the new 'contributor' will give given write access to our wiki and the ability to assign Jira's. 4. The new contributor will be announced to the community. I've grouped Jira rights with wiki rights in the above. This is not strictly necessary, but grouping the two seems like a reasonable step. This is my first pass at a proposal. We can tweak this process in a number of ways and there are alternatives. I think the hard requirements are 1) the PMC must vote and 2) an ICLA must be filed with the ASF. Until we resolve this issue, we need to restrict Wiki write access to be the current set of Geronimo committers. --kevan
Re: [DISCUSS] Policy for granting write access to our Wiki
I agree that we definitely need to address IP issues around documentation/the wiki... but isn't there any way to accomplish this without adding barriers to users editing content? Can we do something like wikipedia does for editing content where there is a checkbox or a notice or something saying You agree to license your contributions under the Apache Software License (similar to how JIRA is currently) -- Erik B. Craig On Wed, Apr 16, 2008 at 9:00 AM, Kevan Miller [EMAIL PROTECTED] wrote: All, To properly protect the IP rights of our Wiki-based documentation, we need to stop allowing unrestricted write access to our Wiki. Wiki contributors should be required to have an ICLA on file with the ASF. I also think that we need to hold a PMC vote before granting this access. I'll also take this opportunity to remind the community that Wiki updates are sent to [EMAIL PROTECTED] These updates need to be reviewed by the community, just like all code updates. IMO, we don't want this to be a heavy-weight process. We don't want there to be a significant hurdle to contributing documentation. For code updates, patch files attached to Jira's with the Grant license to ASF button checked takes care of these IP concerns. To my knowledge, there's no patch file equivalent for updates to a Wiki. We could require that documentation updates be contributed in the form of simple ascii text files that are attached to a Jira. This would address our IP concerns, but is not ideal IMO. To keep this as light-weight as possible, I propose we formalize the concept of contributor. A contributor would have write access to our Wiki documentation as well as the ability to assign Jira's to him/herself. I think the process would go something like this... 0. Reset write access to our wiki to be only the current set of committers on the project. 1. New documentation contributions from non-committers/contributors must be submitted via a Jira, with the Grant License to the ASF box checked. This is just like any code/bug-fix submission. 2. Once a new participant has expressed interest in contributing to the project and/or has contributed documentation or bug fixes, a PMC vote will be called to grant the new participant contributor rights. As all PMC votes, this vote is a majority vote, require a minimum of 3 +1 votes, and will last for a minimum of 72 hours. 3. Once a vote has passed, the participant will be invited to join the project as a 'contributor'. Assuming he/she accepts, the participant must then submit an ICLA to the ASF. Once the ICLA is on file, the new 'contributor' will give given write access to our wiki and the ability to assign Jira's. 4. The new contributor will be announced to the community. I've grouped Jira rights with wiki rights in the above. This is not strictly necessary, but grouping the two seems like a reasonable step. This is my first pass at a proposal. We can tweak this process in a number of ways and there are alternatives. I think the hard requirements are 1) the PMC must vote and 2) an ICLA must be filed with the ASF. Until we resolve this issue, we need to restrict Wiki write access to be the current set of Geronimo committers. --kevan
Re: [DISCUSS] Policy for granting write access to our Wiki
I'd be more inclined to do something akin to what Erik suggested. I'm concerned that the process to gain access to editing the wiki would deter many of the people that add a page here and there that describes something they've done. A number of our contributions come from people who are just making a one time edit. I can't imagine many of them would go through the effort to gain contributor access to add a single page. On Wed, Apr 16, 2008 at 1:57 PM, Erik B. Craig [EMAIL PROTECTED] wrote: I agree that we definitely need to address IP issues around documentation/the wiki... but isn't there any way to accomplish this without adding barriers to users editing content? Can we do something like wikipedia does for editing content where there is a checkbox or a notice or something saying You agree to license your contributions under the Apache Software License (similar to how JIRA is currently) -- Erik B. Craig On Wed, Apr 16, 2008 at 9:00 AM, Kevan Miller [EMAIL PROTECTED] wrote: All, To properly protect the IP rights of our Wiki-based documentation, we need to stop allowing unrestricted write access to our Wiki. Wiki contributors should be required to have an ICLA on file with the ASF. I also think that we need to hold a PMC vote before granting this access. I'll also take this opportunity to remind the community that Wiki updates are sent to [EMAIL PROTECTED] These updates need to be reviewed by the community, just like all code updates. IMO, we don't want this to be a heavy-weight process. We don't want there to be a significant hurdle to contributing documentation. For code updates, patch files attached to Jira's with the Grant license to ASF button checked takes care of these IP concerns. To my knowledge, there's no patch file equivalent for updates to a Wiki. We could require that documentation updates be contributed in the form of simple ascii text files that are attached to a Jira. This would address our IP concerns, but is not ideal IMO. To keep this as light-weight as possible, I propose we formalize the concept of contributor. A contributor would have write access to our Wiki documentation as well as the ability to assign Jira's to him/herself. I think the process would go something like this... 0. Reset write access to our wiki to be only the current set of committers on the project. 1. New documentation contributions from non-committers/contributors must be submitted via a Jira, with the Grant License to the ASF box checked. This is just like any code/bug-fix submission. 2. Once a new participant has expressed interest in contributing to the project and/or has contributed documentation or bug fixes, a PMC vote will be called to grant the new participant contributor rights. As all PMC votes, this vote is a majority vote, require a minimum of 3 +1 votes, and will last for a minimum of 72 hours. 3. Once a vote has passed, the participant will be invited to join the project as a 'contributor'. Assuming he/she accepts, the participant must then submit an ICLA to the ASF. Once the ICLA is on file, the new 'contributor' will give given write access to our wiki and the ability to assign Jira's. 4. The new contributor will be announced to the community. I've grouped Jira rights with wiki rights in the above. This is not strictly necessary, but grouping the two seems like a reasonable step. This is my first pass at a proposal. We can tweak this process in a number of ways and there are alternatives. I think the hard requirements are 1) the PMC must vote and 2) an ICLA must be filed with the ASF. Until we resolve this issue, we need to restrict Wiki write access to be the current set of Geronimo committers. --kevan -- ~Jason Warner
Re: [DISCUSS] Policy for granting write access to our Wiki
Rereading this again, I think I might have misinterpreted a bit. To make sure I understand it now, a user could contribute a single page by providing a patch in a jira without needing to gain contributor status? On Wed, Apr 16, 2008 at 2:01 PM, Jason Warner [EMAIL PROTECTED] wrote: I'd be more inclined to do something akin to what Erik suggested. I'm concerned that the process to gain access to editing the wiki would deter many of the people that add a page here and there that describes something they've done. A number of our contributions come from people who are just making a one time edit. I can't imagine many of them would go through the effort to gain contributor access to add a single page. On Wed, Apr 16, 2008 at 1:57 PM, Erik B. Craig [EMAIL PROTECTED] wrote: I agree that we definitely need to address IP issues around documentation/the wiki... but isn't there any way to accomplish this without adding barriers to users editing content? Can we do something like wikipedia does for editing content where there is a checkbox or a notice or something saying You agree to license your contributions under the Apache Software License (similar to how JIRA is currently) -- Erik B. Craig On Wed, Apr 16, 2008 at 9:00 AM, Kevan Miller [EMAIL PROTECTED] wrote: All, To properly protect the IP rights of our Wiki-based documentation, we need to stop allowing unrestricted write access to our Wiki. Wiki contributors should be required to have an ICLA on file with the ASF. I also think that we need to hold a PMC vote before granting this access. I'll also take this opportunity to remind the community that Wiki updates are sent to [EMAIL PROTECTED] These updates need to be reviewed by the community, just like all code updates. IMO, we don't want this to be a heavy-weight process. We don't want there to be a significant hurdle to contributing documentation. For code updates, patch files attached to Jira's with the Grant license to ASF button checked takes care of these IP concerns. To my knowledge, there's no patch file equivalent for updates to a Wiki. We could require that documentation updates be contributed in the form of simple ascii text files that are attached to a Jira. This would address our IP concerns, but is not ideal IMO. To keep this as light-weight as possible, I propose we formalize the concept of contributor. A contributor would have write access to our Wiki documentation as well as the ability to assign Jira's to him/herself. I think the process would go something like this... 0. Reset write access to our wiki to be only the current set of committers on the project. 1. New documentation contributions from non-committers/contributors must be submitted via a Jira, with the Grant License to the ASF box checked. This is just like any code/bug-fix submission. 2. Once a new participant has expressed interest in contributing to the project and/or has contributed documentation or bug fixes, a PMC vote will be called to grant the new participant contributor rights. As all PMC votes, this vote is a majority vote, require a minimum of 3 +1 votes, and will last for a minimum of 72 hours. 3. Once a vote has passed, the participant will be invited to join the project as a 'contributor'. Assuming he/she accepts, the participant must then submit an ICLA to the ASF. Once the ICLA is on file, the new 'contributor' will give given write access to our wiki and the ability to assign Jira's. 4. The new contributor will be announced to the community. I've grouped Jira rights with wiki rights in the above. This is not strictly necessary, but grouping the two seems like a reasonable step. This is my first pass at a proposal. We can tweak this process in a number of ways and there are alternatives. I think the hard requirements are 1) the PMC must vote and 2) an ICLA must be filed with the ASF. Until we resolve this issue, we need to restrict Wiki write access to be the current set of Geronimo committers. --kevan -- ~Jason Warner -- ~Jason Warner
Re: [DISCUSS] Policy for granting write access to our Wiki
As one of the non-committers who has been active contributing to the Geronimo Wiki, I echo the preference for a lightweight process. I prefer the method whereby you can check a box Grant license to ASF as you do with JIRA contributions. However barring this, the proposed process looks acceptable to me. Kevan Miller wrote: 2. Once a new participant has expressed interest in contributing to the project and/or has contributed documentation or bug fixes, a PMC vote will be called to grant the new participant contributor rights. As all PMC votes, this vote is a majority vote, require a minimum of 3 +1 votes, and will last for a minimum of 72 hours. I hope you can add me to the first vote. I have continuing interest in contributing to the Wiki. -- Thanks, Dan Becker
Re: [DISCUSS] Policy for granting write access to our Wiki
Erik B. Craig wrote: I agree that we definitely need to address IP issues around documentation/the wiki... but isn't there any way to accomplish this without adding barriers to users editing content? Can we do something like wikipedia does for editing content where there is a checkbox or a notice or something saying You agree to license your contributions under the Apache Software License (similar to how JIRA is currently) We mention on the wiki front page, see second paragraph on http://cwiki.apache.org/geronimo ...Contributions to this wiki are managed the same way as code contributions, that means all content on this site (see Geronimo cwiki documentation architecture for a list of conforming spaces) is Apache Software Foundation copyrighted and available under the Apache License... In addition, every single page autoexported as HTML (the version we should all consume) has the following footer Copyright © 2003-2008, The Apache Software Foundation But I also understand we want something more than just a disclaimer, some additional step requiring a specific user action. An ICLA would do the trick, file it once and is good for all your contributions. The process for filing it and getting the appropriate access rights is the tricky one. Cheers! Hernan -- Erik B. Craig On Wed, Apr 16, 2008 at 9:00 AM, Kevan Miller [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: All, To properly protect the IP rights of our Wiki-based documentation, we need to stop allowing unrestricted write access to our Wiki. Wiki contributors should be required to have an ICLA on file with the ASF. I also think that we need to hold a PMC vote before granting this access. I'll also take this opportunity to remind the community that Wiki updates are sent to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]. These updates need to be reviewed by the community, just like all code updates. IMO, we don't want this to be a heavy-weight process. We don't want there to be a significant hurdle to contributing documentation. For code updates, patch files attached to Jira's with the Grant license to ASF button checked takes care of these IP concerns. To my knowledge, there's no patch file equivalent for updates to a Wiki. We could require that documentation updates be contributed in the form of simple ascii text files that are attached to a Jira. This would address our IP concerns, but is not ideal IMO. To keep this as light-weight as possible, I propose we formalize the concept of contributor. A contributor would have write access to our Wiki documentation as well as the ability to assign Jira's to him/herself. I think the process would go something like this... 0. Reset write access to our wiki to be only the current set of committers on the project. 1. New documentation contributions from non-committers/contributors must be submitted via a Jira, with the Grant License to the ASF box checked. This is just like any code/bug-fix submission. 2. Once a new participant has expressed interest in contributing to the project and/or has contributed documentation or bug fixes, a PMC vote will be called to grant the new participant contributor rights. As all PMC votes, this vote is a majority vote, require a minimum of 3 +1 votes, and will last for a minimum of 72 hours. 3. Once a vote has passed, the participant will be invited to join the project as a 'contributor'. Assuming he/she accepts, the participant must then submit an ICLA to the ASF. Once the ICLA is on file, the new 'contributor' will give given write access to our wiki and the ability to assign Jira's. 4. The new contributor will be announced to the community. I've grouped Jira rights with wiki rights in the above. This is not strictly necessary, but grouping the two seems like a reasonable step. This is my first pass at a proposal. We can tweak this process in a number of ways and there are alternatives. I think the hard requirements are 1) the PMC must vote and 2) an ICLA must be filed with the ASF. Until we resolve this issue, we need to restrict Wiki write access to be the current set of Geronimo committers. --kevan
[jira] Updated: (GERONIMODEVTOOLS-266) GEP automation testsuite
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B.J. Reed updated GERONIMODEVTOOLS-266: --- Attachment: GERONIMODEVTOOLS-259d.patch patch to add the test for all values for building an Application XML file. GEP automation testsuite Key: GERONIMODEVTOOLS-266 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-266 Project: Geronimo-Devtools Issue Type: Sub-task Reporter: Tim McConnell Assignee: Tim McConnell Attachments: GERONIMO-259a.patch, GERONIMODEVTOOLS-259b.patch, GERONIMODEVTOOLS-259c.patch, GERONIMODEVTOOLS-259d.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-272) Description of core feature confusing
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589715#action_12589715
]
Ted Kirby commented on GERONIMODEVTOOLS-272:
Can someone put this trivial patch in?
Description of core feature confusing
-
Key: GERONIMODEVTOOLS-272
URL:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-272
Project: Geronimo-Devtools
Issue Type: Improvement
Components: eclipse-plugin
Affects Versions: 2.0.0, 2.0.2, 2.0.x, 2.1.0, 2.1.x
Reporter: Ted Kirby
Assignee: Tim McConnell
Attachments: GD-272.patch
When you install the eclipse plugin with the eclipse update manager, you get
a choice of Geronimo WTP Server Adapters:
Geronimo Core Feature,
and a series of versioned server adapters of the form:
Geronimo vX.X Server Adapter
When you click on them, they all have the same descripton:
This feature provides the WTP Server Adapter and additional development
tools for the Apache Geronimo server.
This text might be customized to include the version number, or changed to:
This feature provides the WTP Server Adapter and additional development
tools for {color:red}this specific version of the{color} Apache Geronimo
server.
For the core feature, however, the text is quite misleading. Installing it
does not give you any working server adapter. So, it's description should be
changed to something like:
This feature provides core support required for the WTP Server Adapter for
specific versions of the Apache Geronimo server.
It would be nice if the core feature did not show up at all in the list to
install. It is included by those version-specific real server adapters that
need it.
Also, not sure what these additional development tools are, or where the
user finds out about them, but they can probably be removed from the core
feature, if that feature itself can't be removed from the install list.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Geronimo 2.1.1 RELEASE-NOTE README questions.
RELEASE_NOTES: 1) I've noticed that we actually have 2 RELEASE_NOTES-2.1.txt files in our source. They are both identical. One is in our root ... branches/2.1.1/RELEASE-NOTES-2.1.txt. The other is branches/2.1.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/RELEASE_NOTES-2.1.txt. Are both of these necessary? If not, which one is really required? 2) How elaborate do the release notes need to be for a maintenance release like 2.1.1? For example, our 2.1 release notes included a list of enhancements explaining each. I was just planning to list the JIRAs that were included in the release since most items are bug fixes and remove the 2.1 enhancement content. Is that sufficient and what we have done in the past? 3) Why is the version number in the name? I assume that I need to rename the current one to reflect that this is 2.1.1 ... but it might be better to just remove the version number completely when I rename it. README.txt: 4) As with the RELEASE_NOTES we also have 2 instances of the README.txt file in our source. One is in our root ... branches/2.1.1/README.txt. The other is branches/2.1.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/README.txt. There is one minor difference between the 2 files. Are both of these necessary and if not, which one is required? Thanks, Joe
Re: Geronimo 2.1.1 RELEASE-NOTE README questions.
Joe Bohn wrote: RELEASE_NOTES: 1) I've noticed that we actually have 2 RELEASE_NOTES-2.1.txt files in our source. They are both identical. One is in our root ... branches/2.1.1/RELEASE-NOTES-2.1.txt. The other is branches/2.1.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/RELEASE_NOTES-2.1.txt. Are both of these necessary? If not, which one is really required? 2) How elaborate do the release notes need to be for a maintenance release like 2.1.1? For example, our 2.1 release notes included a list of enhancements explaining each. I was just planning to list the JIRAs that were included in the release since most items are bug fixes and remove the 2.1 enhancement content. Is that sufficient and what we have done in the past? If it is only bug fixes then that should be the focus, no need to include the Geronimo 2.1 Enhancements again I guess. We need to make sure we clearly mention this is a maintenance release and that no new functionality has been introduced 3) Why is the version number in the name? I assume that I need to rename the current one to reflect that this is 2.1.1 ... but it might be better to just remove the version number completely when I rename it. For one, it help us develop/maintain the release notes in the wiki (can't have 2 files with the same name). Second, I guess it's the fastest way to know the installed version. Specially when you have multiple installs and have been chopping the geronimo_home directory to single characters to run worry free on certain platform ;-) Cheers! Hernan README.txt: 4) As with the RELEASE_NOTES we also have 2 instances of the README.txt file in our source. One is in our root ... branches/2.1.1/README.txt. The other is branches/2.1.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/README.txt. There is one minor difference between the 2 files. Are both of these necessary and if not, which one is required? Thanks, Joe
Re: [DISCUSS] Policy for granting write access to our Wiki
On Apr 16, 2008, at 2:36 PM, Hernan Cunico wrote: Erik B. Craig wrote: I agree that we definitely need to address IP issues around documentation/the wiki... but isn't there any way to accomplish this without adding barriers to users editing content? Can we do something like wikipedia does for editing content where there is a checkbox or a notice or something saying You agree to license your contributions under the Apache Software License (similar to how JIRA is currently) We mention on the wiki front page, see second paragraph on http://cwiki.apache.org/geronimo ...Contributions to this wiki are managed the same way as code contributions, that means all content on this site (see Geronimo cwiki documentation architecture for a list of conforming spaces) is Apache Software Foundation copyrighted and available under the Apache License... In addition, every single page autoexported as HTML (the version we should all consume) has the following footer Copyright © 2003-2008, The Apache Software Foundation But I also understand we want something more than just a disclaimer, some additional step requiring a specific user action. An ICLA would do the trick, file it once and is good for all your contributions. The process for filing it and getting the appropriate access rights is the tricky one. So, is a check box technically feasible? This might be an acceptable alternative. Probably still need to limit write access -- otherwise, we're open to hacks... But might not require a vote -- just a request to contribute. --kevan
Re: [DISCUSS] Policy for granting write access to our Wiki
Kevan Miller wrote: On Apr 16, 2008, at 2:36 PM, Hernan Cunico wrote: Erik B. Craig wrote: I agree that we definitely need to address IP issues around documentation/the wiki... but isn't there any way to accomplish this without adding barriers to users editing content? Can we do something like wikipedia does for editing content where there is a checkbox or a notice or something saying You agree to license your contributions under the Apache Software License (similar to how JIRA is currently) We mention on the wiki front page, see second paragraph on http://cwiki.apache.org/geronimo ...Contributions to this wiki are managed the same way as code contributions, that means all content on this site (see Geronimo cwiki documentation architecture for a list of conforming spaces) is Apache Software Foundation copyrighted and available under the Apache License... In addition, every single page autoexported as HTML (the version we should all consume) has the following footer Copyright © 2003-2008, The Apache Software Foundation But I also understand we want something more than just a disclaimer, some additional step requiring a specific user action. An ICLA would do the trick, file it once and is good for all your contributions. The process for filing it and getting the appropriate access rights is the tricky one. So, is a check box technically feasible? This might be an acceptable I know customization is possible but I don't know how to do it. So far I haven't found a way to customize Confluence native templates to include a checkbox before saving a page. Does anybody knows how to do this? Cheers! Hernan alternative. Probably still need to limit write access -- otherwise, we're open to hacks... But might not require a vote -- just a request to contribute. --kevan
Re: branches/2.1.1 created
On Apr 16, 2008, at 7:15 AM, Joe Bohn wrote: David Jencks wrote: While the original manifestations of GERONIMO-3705 (build doesn't work with maven 2.0.8) appeared to only apply to maven 2.0.7, Bruce Snyder came up with a problem with identical symptoms using maven 2.0.7. I think if the fix for this issue also fixes the situation he has we should apply the change to 2.1.1. thanks david jencks Do you have an idea when we will know if this does in fact resolve the issue? I'm not opposed to it if we will know fairly soon. I still have to work on the release notes (unless somebody else wants to do this :-) ) and ensure that I can create the necessary artifacts before I can create a release candidate. I checked against servicemix 3.2 branch and although I had to make quite a few changes to work with g. 2.1.x after those changes it did compile (at least the part that was giving problems). Therefore I think we should merge this in. I'm happy to do this if you want, otherwise I think svn merge -c 648584 https://svn.apache.org/repos/asf/geronimo/server/ branches/2.1 . should work thanks david jencks Joe On Apr 15, 2008, at 3:10 PM, Joe Bohn wrote: I created a branch for 2.1.1 that will be used to prepare for the release. At the moment it is still versioned as 2.1.1-SNAPSHOT. Just prior to this branch I published new 2.1.1-SNAPSHOT artifacts. I also updated the branches/2.1 to 2.1.2-SNAPSHOT. After the change I published 2.1.2-SNAPSHOT artifacts. At the moment the only remaining changes that I am aware of that are necessary for 2.1.1 prior to creating a release candidate are: - Updating to utilize OpenEJB 3.0 - Updating the README and RELEASE_NOTES Joe
Documentation woes
I think there is a major and unacceptable problem with the indexing of the current 2.1 docs. Some time ago I implemented a little feature for app-specific log4j configuration and actually wrote up some instructions on how to use it. Today I wanted to see what I had written and discovered that while it's possible to find using google search it isn't really possible to find from the top level documentation page. It ain't here: http://cwiki.apache.org/GMOxDOC21/documentation.html There are a whole lotta unwritten topics listed under Development and deployment planning, but not mine! If you click the link... you do get http://cwiki.apache.org/GMOxDOC21/ development-and-deployment-planning.html which has my little contribution. Perhaps I'm overreacting but this seems like an enormous problem to me. I'd far prefer that all the index pages be generated automatically from the page hierarchy even if this means the entries show up an a more random (alphabetical?) order as long as the indices are complete and up to date. I don't really get much from little green check marks when content that someone has actually gone to the trouble to write is not reflected and easily accessible. thanks david jencks
Re: Documentation woes
Fixed, I added a macro to automatically list all children pages of Development and deployment planning. These pages are now visible from http://cwiki.apache.org/GMOxDOC21/documentation.html Sorry it took this long to update this. The original TOC on the front page was put there as a guideline for developing some of the content; as we fill the doc with more content we need to update the corresponding sections. I still believe it looks a lot better if we force some structure on the front page compared to a having a massive list alphabetically ordered. Just compare 20 doc vs 21. Thanks for contributing to the doc ! Cheers! Hernan David Jencks wrote: I think there is a major and unacceptable problem with the indexing of the current 2.1 docs. Some time ago I implemented a little feature for app-specific log4j configuration and actually wrote up some instructions on how to use it. Today I wanted to see what I had written and discovered that while it's possible to find using google search it isn't really possible to find from the top level documentation page. It ain't here: http://cwiki.apache.org/GMOxDOC21/documentation.html There are a whole lotta unwritten topics listed under Development and deployment planning, but not mine! If you click the link... you do get http://cwiki.apache.org/GMOxDOC21/development-and-deployment-planning.html which has my little contribution. Perhaps I'm overreacting but this seems like an enormous problem to me. I'd far prefer that all the index pages be generated automatically from the page hierarchy even if this means the entries show up an a more random (alphabetical?) order as long as the indices are complete and up to date. I don't really get much from little green check marks when content that someone has actually gone to the trouble to write is not reflected and easily accessible. thanks david jencks
Re: branches/2.1.1 created
David Jencks wrote: On Apr 16, 2008, at 7:15 AM, Joe Bohn wrote: David Jencks wrote: While the original manifestations of GERONIMO-3705 (build doesn't work with maven 2.0.8) appeared to only apply to maven 2.0.7, Bruce Snyder came up with a problem with identical symptoms using maven 2.0.7. I think if the fix for this issue also fixes the situation he has we should apply the change to 2.1.1. thanks david jencks Do you have an idea when we will know if this does in fact resolve the issue? I'm not opposed to it if we will know fairly soon. I still have to work on the release notes (unless somebody else wants to do this :-) ) and ensure that I can create the necessary artifacts before I can create a release candidate. I checked against servicemix 3.2 branch and although I had to make quite a few changes to work with g. 2.1.x after those changes it did compile (at least the part that was giving problems). Therefore I think we should merge this in. I'm happy to do this if you want, otherwise I think svn merge -c 648584 https://svn.apache.org/repos/asf/geronimo/server/branches/2.1 . should work Thanks David. I'll take a look at merging it in. It would be nice to be able to leverage newer versions of maven of somebody wants to pick up and build 2.1.1. Joe thanks david jencks Joe On Apr 15, 2008, at 3:10 PM, Joe Bohn wrote: I created a branch for 2.1.1 that will be used to prepare for the release. At the moment it is still versioned as 2.1.1-SNAPSHOT. Just prior to this branch I published new 2.1.1-SNAPSHOT artifacts. I also updated the branches/2.1 to 2.1.2-SNAPSHOT. After the change I published 2.1.2-SNAPSHOT artifacts. At the moment the only remaining changes that I am aware of that are necessary for 2.1.1 prior to creating a release candidate are: - Updating to utilize OpenEJB 3.0 - Updating the README and RELEASE_NOTES Joe
[jira] Updated: (GERONIMODEVTOOLS-272) Description of core feature confusing
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shiva Kumar H R updated GERONIMODEVTOOLS-272:
-
Fix Version/s: 2.1.0
Assignee: Shiva Kumar H R (was: Tim McConnell)
Sure, thanks Ted for bringing it forth. I had mostly been looking at JIRAs with
Fix Version/s: 2.1.0 and since this JIRA hadn't specified it, I missed it out.
Description of core feature confusing
-
Key: GERONIMODEVTOOLS-272
URL:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-272
Project: Geronimo-Devtools
Issue Type: Improvement
Components: eclipse-plugin
Affects Versions: 2.0.0, 2.0.2, 2.0.x, 2.1.0, 2.1.x
Reporter: Ted Kirby
Assignee: Shiva Kumar H R
Fix For: 2.1.0
Attachments: GD-272.patch
When you install the eclipse plugin with the eclipse update manager, you get
a choice of Geronimo WTP Server Adapters:
Geronimo Core Feature,
and a series of versioned server adapters of the form:
Geronimo vX.X Server Adapter
When you click on them, they all have the same descripton:
This feature provides the WTP Server Adapter and additional development
tools for the Apache Geronimo server.
This text might be customized to include the version number, or changed to:
This feature provides the WTP Server Adapter and additional development
tools for {color:red}this specific version of the{color} Apache Geronimo
server.
For the core feature, however, the text is quite misleading. Installing it
does not give you any working server adapter. So, it's description should be
changed to something like:
This feature provides core support required for the WTP Server Adapter for
specific versions of the Apache Geronimo server.
It would be nice if the core feature did not show up at all in the list to
install. It is included by those version-specific real server adapters that
need it.
Also, not sure what these additional development tools are, or where the
user finds out about them, but they can probably be removed from the core
feature, if that feature itself can't be removed from the install list.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMODEVTOOLS-323) Eclipse as a top-level directory in GEP zip file
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Kirby reopened GERONIMODEVTOOLS-323: with this change, updatesite.zip doesn't work. In many cases, the only error message is: An exception occured while downloading feature from file:/C:/temp/eclipseUpdateSites/ag201RC1/eclipse/features/org.apache.geronimo.v20.feature_2.1.0.jar. Do you want to retry? In a few instances, I got a decent error log record: eclipse.buildId=M20070921-1145 java.fullversion=J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20071007 (JIT enabled) J9VM - 20071004_14218_lHdSMR JIT - 20070820_1846ifx1_r8 GC - 200708_10 BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86 Info Wed Apr 16 16:23:20 EDT 2008 An exception occured while downloading feature from file:/C:/temp/eclipseUpdateSites/ag201RC1/features/org.apache.geronimo.v20.feature_2.1.0.jar. java.io.FileNotFoundException: C:\temp\eclipseUpdateSites\ag201RC1\features\org.apache.geronimo.v20.feature_2.1.0.jar (The system cannot find the path specified.) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:135) at java.io.FileInputStream.init(FileInputStream.java:95) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:85) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:176) at java.net.URL.openStream(URL.java:1042) at org.eclipse.update.internal.core.connection.FileResponse.getInputStream(FileResponse.java:28) at org.eclipse.update.core.ContentReference.getInputStream(ContentReference.java:149) at org.eclipse.update.core.FeatureContentProvider.asLocalReference(FeatureContentProvider.java:268) at org.eclipse.update.internal.core.FeaturePackagedContentProvider.getFeatureEntryArchiveReferences(FeaturePackagedContentProvider.java:157) at org.eclipse.update.internal.core.FeaturePackagedContentProvider.getFeatureManifestReference(FeaturePackagedContentProvider.java:83) at org.eclipse.update.internal.core.FeaturePackagedFactory.createFeature(FeaturePackagedFactory.java:39) at org.eclipse.update.core.Site.createFeature(Site.java:534) at org.eclipse.update.core.FeatureReference.createFeature(FeatureReference.java:122) at org.eclipse.update.core.FeatureReference.getFeature(FeatureReference.java:110) at org.eclipse.update.core.FeatureReference.getFeature(FeatureReference.java:97) at org.eclipse.update.internal.search.SiteSearchCategory$FeatureDownloader.run(SiteSearchCategory.java:222) at java.lang.Thread.run(Thread.java:810) If I put the site.xml file with the eclipse/ removed from it, as it was before this patch, in the eclipse directory, it works. So, if you want to accept/implement this change, more work is required to make sure it works. I am not sure what else must be done, but what we have now doesn't work. Eclipse as a top-level directory in GEP zip file Key: GERONIMODEVTOOLS-323 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-323 Project: Geronimo-Devtools Issue Type: New Feature Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.0 Jacek recommends that we use eclipse as the top-level directory in the GEP assemblies to be more consistent with other Eclipse plugins -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: branches/2.1.1 created
Joe Bohn wrote: David Jencks wrote: On Apr 16, 2008, at 7:15 AM, Joe Bohn wrote: David Jencks wrote: While the original manifestations of GERONIMO-3705 (build doesn't work with maven 2.0.8) appeared to only apply to maven 2.0.7, Bruce Snyder came up with a problem with identical symptoms using maven 2.0.7. I think if the fix for this issue also fixes the situation he has we should apply the change to 2.1.1. thanks david jencks Do you have an idea when we will know if this does in fact resolve the issue? I'm not opposed to it if we will know fairly soon. I still have to work on the release notes (unless somebody else wants to do this :-) ) and ensure that I can create the necessary artifacts before I can create a release candidate. I checked against servicemix 3.2 branch and although I had to make quite a few changes to work with g. 2.1.x after those changes it did compile (at least the part that was giving problems). Therefore I think we should merge this in. I'm happy to do this if you want, otherwise I think svn merge -c 648584 https://svn.apache.org/repos/asf/geronimo/server/branches/2.1 . should work Thanks David. I'll take a look at merging it in. It would be nice to be able to leverage newer versions of maven of somebody wants to pick up and build 2.1.1. Actually on second thought, I'll let you go ahead and merge this change in David. I have too many local changes for the version updates and I don't want to commit those just yet. This will also let you go ahead and resolve the issue as well. Thanks, Joe Joe thanks david jencks Joe On Apr 15, 2008, at 3:10 PM, Joe Bohn wrote: I created a branch for 2.1.1 that will be used to prepare for the release. At the moment it is still versioned as 2.1.1-SNAPSHOT. Just prior to this branch I published new 2.1.1-SNAPSHOT artifacts. I also updated the branches/2.1 to 2.1.2-SNAPSHOT. After the change I published 2.1.2-SNAPSHOT artifacts. At the moment the only remaining changes that I am aware of that are necessary for 2.1.1 prior to creating a release candidate are: - Updating to utilize OpenEJB 3.0 - Updating the README and RELEASE_NOTES Joe
[jira] Commented: (GERONIMODEVTOOLS-272) Description of core feature confusing
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589820#action_12589820
]
Shiva Kumar H R commented on GERONIMODEVTOOLS-272:
--
Patch has been applied at revision: 648941 . Thanks again Ted.
But as you point out - it would be nice if the core feature did not show up at
all in the list to install. Any idea how to accomplish this?
Description of core feature confusing
-
Key: GERONIMODEVTOOLS-272
URL:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-272
Project: Geronimo-Devtools
Issue Type: Improvement
Components: eclipse-plugin
Affects Versions: 2.0.0, 2.0.2, 2.0.x, 2.1.0, 2.1.x
Reporter: Ted Kirby
Assignee: Shiva Kumar H R
Fix For: 2.1.0
Attachments: GD-272.patch
When you install the eclipse plugin with the eclipse update manager, you get
a choice of Geronimo WTP Server Adapters:
Geronimo Core Feature,
and a series of versioned server adapters of the form:
Geronimo vX.X Server Adapter
When you click on them, they all have the same descripton:
This feature provides the WTP Server Adapter and additional development
tools for the Apache Geronimo server.
This text might be customized to include the version number, or changed to:
This feature provides the WTP Server Adapter and additional development
tools for {color:red}this specific version of the{color} Apache Geronimo
server.
For the core feature, however, the text is quite misleading. Installing it
does not give you any working server adapter. So, it's description should be
changed to something like:
This feature provides core support required for the WTP Server Adapter for
specific versions of the Apache Geronimo server.
It would be nice if the core feature did not show up at all in the list to
install. It is included by those version-specific real server adapters that
need it.
Also, not sure what these additional development tools are, or where the
user finds out about them, but they can probably be removed from the core
feature, if that feature itself can't be removed from the install list.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-330) org.apache.geronimo.v21.feature\feature.xml incorrectly includes org.apache.geronimo.v11.feature
org.apache.geronimo.v21.feature\feature.xml incorrectly includes org.apache.geronimo.v11.feature Key: GERONIMODEVTOOLS-330 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-330 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Shiva Kumar H R Assignee: Tim McConnell Fix For: 2.1.0 \features\org.apache.geronimo.v21.feature\feature.xml has: includes id=org.apache.geronimo.v11.feature version=2.1.0 name=Geronimo v1.1.x Server Adapter/ That shouldn't be the case right? I guess it shld rather be: includes id=org.apache.geronimo.feature version=2.1.0 name=Geronimo Core Feature/ Same is the case with \features\org.apache.geronimo.v20.feature\feature.xml . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
