[GitHub] geronimo-xbean pull request: [XBEAN-264] ignore git files so that ...
GitHub user mbenson opened a pull request: https://github.com/apache/geronimo-xbean/pull/7 [XBEAN-264] ignore git files so that checkout from git mirror can actual... ...ly build You can merge this pull request into a Git repository by running: $ git pull https://github.com/mbenson/geronimo-xbean trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/geronimo-xbean/pull/7.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #7 commit e90ef75baca4e618344334350e70f216e641db59 Author: Matt Benson Date: 2014-04-30T22:02:39Z [XBEAN-264] ignore git files so that checkout from git mirror can actually build --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at [email protected] or file a JIRA ticket with INFRA. ---
[GitHub] geronimo-xbean pull request: ignore git files so that checkout fro...
GitHub user mbenson opened a pull request: https://github.com/apache/geronimo-xbean/pull/5 ignore git files so that checkout from git mirror can actually build You can merge this pull request into a Git repository by running: $ git pull https://github.com/mbenson/geronimo-xbean mjb Alternatively you can review and apply these changes as the patch at: https://github.com/apache/geronimo-xbean/pull/5.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5 commit 87fd56428a110ccdda062a38a4e16be3b8af86da Author: Matt Benson Date: 2014-04-30T22:02:39Z ignore git files so that checkout from git mirror can actually build --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at [email protected] or file a JIRA ticket with INFRA. ---
ignore rules for geronimo-specs
Hi folks! I'll set the following ignorerules for geronimo-specs target .metadata .classpath .project .settings *.iml *.ipr *.iws .idea .git .gitignore maven.log mvn.log junit*.properties Previously this has been wildly different for a lot projects (most times only having 'target' ignored) LieGrue, strub
[jira] [Commented] (GERONIMO-5902) Ignore web service from web application side if it is also an EJB web service
[ https://issues.apache.org/jira/browse/GERONIMO-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019818#comment-13019818 ] Ivan commented on GERONIMO-5902: Commit changes to trunk at revision: 1092215 > Ignore web service from web application side if it is also an EJB web service > - > > Key: GERONIMO-5902 > URL: https://issues.apache.org/jira/browse/GERONIMO-5902 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 3.0 >Reporter: Ivan >Assignee: Ivan > Fix For: 3.0 > > > In JavaEE 6, it is allowed to ship EJB in the web application, so once one > EJB bean is annotated as web service, it should be ignored from web > application side, or we would create two service endpoint, one is from web > application, another is from EJB side. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-5902) Ignore web service from web application side if it is also an EJB web service
[ https://issues.apache.org/jira/browse/GERONIMO-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan resolved GERONIMO-5902. Resolution: Fixed Fix Version/s: 3.0 > Ignore web service from web application side if it is also an EJB web service > - > > Key: GERONIMO-5902 > URL: https://issues.apache.org/jira/browse/GERONIMO-5902 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 3.0 >Reporter: Ivan >Assignee: Ivan > Fix For: 3.0 > > > In JavaEE 6, it is allowed to ship EJB in the web application, so once one > EJB bean is annotated as web service, it should be ignored from web > application side, or we would create two service endpoint, one is from web > application, another is from EJB side. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5902) Ignore web service from web application side if it is also an EJB web service
[ https://issues.apache.org/jira/browse/GERONIMO-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019653#comment-13019653 ] Ivan commented on GERONIMO-5902: Commit first step changes to trunk at revision: 1091981 > Ignore web service from web application side if it is also an EJB web service > - > > Key: GERONIMO-5902 > URL: https://issues.apache.org/jira/browse/GERONIMO-5902 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 3.0 >Reporter: Ivan >Assignee: Ivan > > In JavaEE 6, it is allowed to ship EJB in the web application, so once one > EJB bean is annotated as web service, it should be ignored from web > application side, or we would create two service endpoint, one is from web > application, another is from EJB side. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-5902) Ignore web service from web application side if it is also an EJB web service
Ignore web service from web application side if it is also an EJB web service - Key: GERONIMO-5902 URL: https://issues.apache.org/jira/browse/GERONIMO-5902 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: webservices Affects Versions: 3.0 Reporter: Ivan Assignee: Ivan In JavaEE 6, it is allowed to ship EJB in the web application, so once one EJB bean is annotated as web service, it should be ignored from web application side, or we would create two service endpoint, one is from web application, another is from EJB side. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
[ https://issues.apache.org/jira/browse/GERONIMO-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire updated GERONIMO-4907: --- Fix Version/s: 3.0-M1 (was: 2.2) (was: 3.0) > GBeanInstance to Ignore Missing Setters > --- > > Key: GERONIMO-4907 > URL: https://issues.apache.org/jira/browse/GERONIMO-4907 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 >Reporter: Quintin Beukes >Assignee: David Jencks > Fix For: 3.0-M1 > > Attachments: ignore-missing-accessors.patch > > > Related to GERONIMO-4903 > I submitted a patch which fixes the problem by removing the attributes which > don't have setters. > After reading the OpenEJB source I noticed an XBean feature which would be a > more correct fix for the problem. > Instead of removing the attributes which won't have setters in the class > being instantiated as a GBean, configure the ObjectRecipe to rather ignore > those properties which don't have setters. This has 2 benefits > 1) Those properties can still be included for "read" access > 2) If such a property exists for any other GBean, or is added in the future, > this will help that those don't possibly create fatal bugs - which the > JettyConnector bug almost was (you couldn't edit a connector - ever). > This is achieved by adding the following line after the ObjectRecipe was > created: > objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); > This permissions merely removes the property from the list of properties to > "create the object with", if the accessor wasn't found. > Since those properties are still available, they can be accessed by the GBean > API, and thus it doesn't become a requirement to have setter accessors for > all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
[ https://issues.apache.org/jira/browse/GERONIMO-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4907. -- Resolution: Fixed fixed in 2.2. rev 831109 trunk rev 831112 This change still does not allow trying to set non-existent properties, but tells you about all the problems at once rather than just the first one.. > GBeanInstance to Ignore Missing Setters > --- > > Key: GERONIMO-4907 > URL: https://issues.apache.org/jira/browse/GERONIMO-4907 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 >Reporter: Quintin Beukes >Assignee: David Jencks > Fix For: 2.2, 3.0 > > Attachments: ignore-missing-accessors.patch > > > Related to GERONIMO-4903 > I submitted a patch which fixes the problem by removing the attributes which > don't have setters. > After reading the OpenEJB source I noticed an XBean feature which would be a > more correct fix for the problem. > Instead of removing the attributes which won't have setters in the class > being instantiated as a GBean, configure the ObjectRecipe to rather ignore > those properties which don't have setters. This has 2 benefits > 1) Those properties can still be included for "read" access > 2) If such a property exists for any other GBean, or is added in the future, > this will help that those don't possibly create fatal bugs - which the > JettyConnector bug almost was (you couldn't edit a connector - ever). > This is achieved by adding the following line after the ObjectRecipe was > created: > objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); > This permissions merely removes the property from the list of properties to > "create the object with", if the accessor wasn't found. > Since those properties are still available, they can be accessed by the GBean > API, and thus it doesn't become a requirement to have setter accessors for > all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
[ https://issues.apache.org/jira/browse/GERONIMO-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reopened GERONIMO-4907: David Blevins pointed out that we should first try to create the object, then get the set of unset properties, and if there are any, complain about all of them at once. > GBeanInstance to Ignore Missing Setters > --- > > Key: GERONIMO-4907 > URL: https://issues.apache.org/jira/browse/GERONIMO-4907 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 >Reporter: Quintin Beukes >Assignee: David Jencks > Fix For: 2.2, 3.0 > > Attachments: ignore-missing-accessors.patch > > > Related to GERONIMO-4903 > I submitted a patch which fixes the problem by removing the attributes which > don't have setters. > After reading the OpenEJB source I noticed an XBean feature which would be a > more correct fix for the problem. > Instead of removing the attributes which won't have setters in the class > being instantiated as a GBean, configure the ObjectRecipe to rather ignore > those properties which don't have setters. This has 2 benefits > 1) Those properties can still be included for "read" access > 2) If such a property exists for any other GBean, or is added in the future, > this will help that those don't possibly create fatal bugs - which the > JettyConnector bug almost was (you couldn't edit a connector - ever). > This is achieved by adding the following line after the ObjectRecipe was > created: > objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); > This permissions merely removes the property from the list of properties to > "create the object with", if the accessor wasn't found. > Since those properties are still available, they can be accessed by the GBean > API, and thus it doesn't become a requirement to have setter accessors for > all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
[ https://issues.apache.org/jira/browse/GERONIMO-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4907. -- Resolution: Won't Fix Assignee: David Jencks I don't think we should fix this. I think it's better to know when we are trying to set a non-settable property and fix it, otherwise we may think info is getting into the gbeans when it is not. Possibly the error message could be improvied, its something like Missing accessor for property: x of class y > GBeanInstance to Ignore Missing Setters > --- > > Key: GERONIMO-4907 > URL: https://issues.apache.org/jira/browse/GERONIMO-4907 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 >Reporter: Quintin Beukes >Assignee: David Jencks > Fix For: 2.2, 3.0 > > Attachments: ignore-missing-accessors.patch > > > Related to GERONIMO-4903 > I submitted a patch which fixes the problem by removing the attributes which > don't have setters. > After reading the OpenEJB source I noticed an XBean feature which would be a > more correct fix for the problem. > Instead of removing the attributes which won't have setters in the class > being instantiated as a GBean, configure the ObjectRecipe to rather ignore > those properties which don't have setters. This has 2 benefits > 1) Those properties can still be included for "read" access > 2) If such a property exists for any other GBean, or is added in the future, > this will help that those don't possibly create fatal bugs - which the > JettyConnector bug almost was (you couldn't edit a connector - ever). > This is achieved by adding the following line after the ObjectRecipe was > created: > objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); > This permissions merely removes the property from the list of properties to > "create the object with", if the accessor wasn't found. > Since those properties are still available, they can be accessed by the GBean > API, and thus it doesn't become a requirement to have setter accessors for > all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
[ https://issues.apache.org/jira/browse/GERONIMO-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765962#action_12765962 ] Quintin Beukes commented on GERONIMO-4907: -- If this is applied, GERONIMO-4903 could possibly be reversed. > GBeanInstance to Ignore Missing Setters > --- > > Key: GERONIMO-4907 > URL: https://issues.apache.org/jira/browse/GERONIMO-4907 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 >Reporter: Quintin Beukes > Fix For: 2.2, 3.0 > > Attachments: ignore-missing-accessors.patch > > > Related to GERONIMO-4903 > I submitted a patch which fixes the problem by removing the attributes which > don't have setters. > After reading the OpenEJB source I noticed an XBean feature which would be a > more correct fix for the problem. > Instead of removing the attributes which won't have setters in the class > being instantiated as a GBean, configure the ObjectRecipe to rather ignore > those properties which don't have setters. This has 2 benefits > 1) Those properties can still be included for "read" access > 2) If such a property exists for any other GBean, or is added in the future, > this will help that those don't possibly create fatal bugs - which the > JettyConnector bug almost was (you couldn't edit a connector - ever). > This is achieved by adding the following line after the ObjectRecipe was > created: > objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); > This permissions merely removes the property from the list of properties to > "create the object with", if the accessor wasn't found. > Since those properties are still available, they can be accessed by the GBean > API, and thus it doesn't become a requirement to have setter accessors for > all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
[ https://issues.apache.org/jira/browse/GERONIMO-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4907: - Attachment: ignore-missing-accessors.patch Attached patch to add the IGNORE_MISSING_ACCESSOR option to the ObjectRecipe. > GBeanInstance to Ignore Missing Setters > --- > > Key: GERONIMO-4907 > URL: https://issues.apache.org/jira/browse/GERONIMO-4907 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 >Reporter: Quintin Beukes > Fix For: 2.2, 3.0 > > Attachments: ignore-missing-accessors.patch > > > Related to GERONIMO-4903 > I submitted a patch which fixes the problem by removing the attributes which > don't have setters. > After reading the OpenEJB source I noticed an XBean feature which would be a > more correct fix for the problem. > Instead of removing the attributes which won't have setters in the class > being instantiated as a GBean, configure the ObjectRecipe to rather ignore > those properties which don't have setters. This has 2 benefits > 1) Those properties can still be included for "read" access > 2) If such a property exists for any other GBean, or is added in the future, > this will help that those don't possibly create fatal bugs - which the > JettyConnector bug almost was (you couldn't edit a connector - ever). > This is achieved by adding the following line after the ObjectRecipe was > created: > objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); > This permissions merely removes the property from the list of properties to > "create the object with", if the accessor wasn't found. > Since those properties are still available, they can be accessed by the GBean > API, and thus it doesn't become a requirement to have setter accessors for > all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
GBeanInstance to Ignore Missing Setters --- Key: GERONIMO-4907 URL: https://issues.apache.org/jira/browse/GERONIMO-4907 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Reporter: Quintin Beukes Fix For: 2.2, 3.0 Related to GERONIMO-4903 I submitted a patch which fixes the problem by removing the attributes which don't have setters. After reading the OpenEJB source I noticed an XBean feature which would be a more correct fix for the problem. Instead of removing the attributes which won't have setters in the class being instantiated as a GBean, configure the ObjectRecipe to rather ignore those properties which don't have setters. This has 2 benefits 1) Those properties can still be included for "read" access 2) If such a property exists for any other GBean, or is added in the future, this will help that those don't possibly create fatal bugs - which the JettyConnector bug almost was (you couldn't edit a connector - ever). This is achieved by adding the following line after the ObjectRecipe was created: objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); This permissions merely removes the property from the list of properties to "create the object with", if the accessor wasn't found. Since those properties are still available, they can be accessed by the GBean API, and thus it doesn't become a requirement to have setter accessors for all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Test dev mail - ignore
This is the one i ve received... Hey.. may be my registration to usrlist is not done properly... I will do it.. and let u know if i need any thing required... On 03/03/2008, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: > > Test dev mail - please ignore. > -- Regards, Praveena Chalamcharla, Securview
Test dev mail - ignore
Test dev mail - please ignore.
ignore
test please ignore
[jira] Closed: (GERONIMO-3724) car-maven-plugin needs to ignore scope when computing dependency filter.
[ https://issues.apache.org/jira/browse/GERONIMO-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3724. -- Resolution: Fixed rev 607675. Also uses the new RecordingLifecycleMonitor. > car-maven-plugin needs to ignore scope when computing dependency filter. > > > Key: GERONIMO-3724 > URL: https://issues.apache.org/jira/browse/GERONIMO-3724 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.1 >Reporter: David Jencks > Fix For: 2.1 > > > The car-maven-plugin creates a filter on the maven repo of what dependencies > are visible. It needs to ignore the scope of the dependencies in the current > maven project so it can get the deps of the deployers it needs to load -- > these are typically supplied with scope provided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3724) car-maven-plugin needs to ignore scope when computing dependency filter.
car-maven-plugin needs to ignore scope when computing dependency filter. Key: GERONIMO-3724 URL: https://issues.apache.org/jira/browse/GERONIMO-3724 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: David Jencks Fix For: 2.1 The car-maven-plugin creates a filter on the maven repo of what dependencies are visible. It needs to ignore the scope of the dependencies in the current maven project so it can get the deps of the deployers it needs to load -- these are typically supplied with scope provided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-88) Source command does not ignore empty lines or does not support comments
[ https://issues.apache.org/jira/browse/GSHELL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-88. -- Resolution: Fixed > Source command does not ignore empty lines or does not support comments > --- > > Key: GSHELL-88 > URL: https://issues.apache.org/jira/browse/GSHELL-88 > Project: GShell > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Commands - Builtins >Reporter: Jarek Gawor >Assignee: Jason Dillon > Fix For: 1.0-alpha-1 > > Attachments: GSHELL-88.patch > > > Source command does not ignore empty lines or does not support comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-88) Source command does not ignore empty lines or does not support comments
[ https://issues.apache.org/jira/browse/GSHELL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GSHELL-88: --- Fix Version/s: 1.0-alpha-1 > Source command does not ignore empty lines or does not support comments > --- > > Key: GSHELL-88 > URL: https://issues.apache.org/jira/browse/GSHELL-88 > Project: GShell > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Commands - Builtins >Reporter: Jarek Gawor >Assignee: Jason Dillon > Fix For: 1.0-alpha-1 > > Attachments: GSHELL-88.patch > > > Source command does not ignore empty lines or does not support comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-88) Source command does not ignore empty lines or does not support comments
[ https://issues.apache.org/jira/browse/GSHELL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548068 ] Jason Dillon commented on GSHELL-88: I had planned to put this into the grammar, but for now this will work fine. Thx, will apply shortly. > Source command does not ignore empty lines or does not support comments > --- > > Key: GSHELL-88 > URL: https://issues.apache.org/jira/browse/GSHELL-88 > Project: GShell > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Commands - Builtins >Reporter: Jarek Gawor >Assignee: Jason Dillon > Attachments: GSHELL-88.patch > > > Source command does not ignore empty lines or does not support comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-88) Source command does not ignore empty lines or does not support comments
[
https://issues.apache.org/jira/browse/GSHELL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor updated GSHELL-88:
--
Attachment: GSHELL-88.patch
Added a patch that adds support for comments ('#') and ignores empty lines.
> Source command does not ignore empty lines or does not support comments
> ---
>
> Key: GSHELL-88
> URL: https://issues.apache.org/jira/browse/GSHELL-88
> Project: GShell
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Commands - Builtins
>Reporter: Jarek Gawor
>Assignee: Jason Dillon
> Attachments: GSHELL-88.patch
>
>
> Source command does not ignore empty lines or does not support comments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-88) Source command does not ignore empty lines or does not support comments
Source command does not ignore empty lines or does not support comments --- Key: GSHELL-88 URL: https://issues.apache.org/jira/browse/GSHELL-88 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Commands - Builtins Reporter: Jarek Gawor Assignee: Jason Dillon Source command does not ignore empty lines or does not support comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Testing --- please ignore
[jira] Closed: (GERONIMO-2956) Ignore @HandlerChain annotation at class-level
[ https://issues.apache.org/jira/browse/GERONIMO-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMO-2956. --- Resolution: Fixed Per Jarek, @HandlerChain annotations at class-level are processed elsewhere and should be ignored by Geronimo. As such, the previously commented-out code has been removed and this defect can be closed. > Ignore @HandlerChain annotation at class-level > -- > > Key: GERONIMO-2956 > URL: https://issues.apache.org/jira/browse/GERONIMO-2956 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: Tim McConnell > Assigned To: Tim McConnell > Fix For: 2.0-M5 > > Attachments: GERONIMO-2956.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-2956) Ignore @HandlerChain annotation at class-level
[ https://issues.apache.org/jira/browse/GERONIMO-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell reopened GERONIMO-2956: - > Ignore @HandlerChain annotation at class-level > -- > > Key: GERONIMO-2956 > URL: https://issues.apache.org/jira/browse/GERONIMO-2956 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: Tim McConnell > Assigned To: Tim McConnell > Fix For: 2.0 > > Attachments: GERONIMO-2956.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2956) Ignore @HandlerChain annotation at class-level
[ https://issues.apache.org/jira/browse/GERONIMO-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMO-2956. --- Resolution: Fixed Fix Version/s: 2.0 Resolved with GERONIMO-3002 > Ignore @HandlerChain annotation at class-level > -- > > Key: GERONIMO-2956 > URL: https://issues.apache.org/jira/browse/GERONIMO-2956 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: Tim McConnell > Assigned To: Tim McConnell > Fix For: 2.0 > > Attachments: GERONIMO-2956.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
test - ignore
-sachin
test - ignore
-sachin
[jira] Commented: (GERONIMO-2956) Ignore @HandlerChain annotation at class-level
[ https://issues.apache.org/jira/browse/GERONIMO-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480156 ] David Jencks commented on GERONIMO-2956: patch applied in rev 517304. When we figure out whether to remove the commented code or implement something for class level handler chains we can close this. > Ignore @HandlerChain annotation at class-level > -- > > Key: GERONIMO-2956 > URL: https://issues.apache.org/jira/browse/GERONIMO-2956 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: Tim McConnell > Assigned To: Tim McConnell > Attachments: GERONIMO-2956.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2956) Ignore @HandlerChain annotation at class-level
[ https://issues.apache.org/jira/browse/GERONIMO-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMO-2956: Attachment: GERONIMO-2956.patch Patch to fix cases where @HandlerChain annotations are provided at a classlevel. At this point we'll ignore them, but will need to revisit to ensure they should not be processed in conjunction with other annotations. > Ignore @HandlerChain annotation at class-level > -- > > Key: GERONIMO-2956 > URL: https://issues.apache.org/jira/browse/GERONIMO-2956 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: Tim McConnell > Assigned To: Tim McConnell > Attachments: GERONIMO-2956.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2956) Ignore @HandlerChain annotation at class-level
Ignore @HandlerChain annotation at class-level -- Key: GERONIMO-2956 URL: https://issues.apache.org/jira/browse/GERONIMO-2956 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Tim McConnell Assigned To: Tim McConnell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Test Ignore
Testing gmail filter and forward
Test Ignore
Testing gmail filter and forward
Test Ignore Build Revision
Testing gmail filter and forward
[jira] Closed: (XBEAN-50) Strategy to ignore properties that are not in the object
[ https://issues.apache.org/jira/browse/XBEAN-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins closed XBEAN-50. -- Resolution: Fixed Fix Version/s: 2.8 this was done in 2.8 if i recall > Strategy to ignore properties that are not in the object > > > Key: XBEAN-50 > URL: https://issues.apache.org/jira/browse/XBEAN-50 > Project: XBean > Issue Type: New Feature > Components: reflect >Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5 >Reporter: David Blevins > Fix For: 2.8 > > > Should be possible to put properties into the ObjectRecipe without prior > knowledge if the class actually has that property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Test - please ignore
Matt Hogstrom [EMAIL PROTECTED]
[jira] Commented: (GERONIMO-2151) geronino should ignore .DS_Store files in the deploy dir
[ http://issues.apache.org/jira/browse/GERONIMO-2151?page=comments#action_12417806 ] Mario Ruebsam commented on GERONIMO-2151: - Geronimo should igrone all files and directories starting with '.' and for some apps and compaibility issues "_" in the deploy dir. Some people like to checkout their apps so ".svn" or ".cvs" directories could also ignored this way. > geronino should ignore .DS_Store files in the deploy dir > > > Key: GERONIMO-2151 > URL: http://issues.apache.org/jira/browse/GERONIMO-2151 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: Hot Deploy Dir > Versions: 1.1 > Environment: osx > Reporter: Christoph Sturm > Priority: Minor > > osx stores extended file attributes in a dir called .DS_Store. > after copying a war file to the geronimo deploy dir with the finder it > creates the .DS_Store file, and geronimo tries to deploy it: > 14:47:48,065 INFO [Hot Deployer] Deploying .DS_Store > 14:47:48,284 ERROR [Hot Deployer] Unable to deploy: > org.apache.xmlbeans.XmlException: > /Users/christophsturm/Projects/geronimo-1.1/deploy/.DS_Store:1: error: > Illegal XML character: 0x0 > org.apache.xmlbeans.impl.piccolo.io.IllegalCharException: Illegal XML > character: 0x0 > at > org.apache.xmlbeans.impl.piccolo.xml.UTF8XMLDecoder.decode(UTF8XMLDecoder.java:196) > at > org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader$FastStreamDecoder.read(XMLStreamReader.java:762) > at > org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader.read(XMLStreamReader.java:162) > at > org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yy_refill(PiccoloLexer.java:3469) > at > org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yylex(PiccoloLexer.java:3953) > at > org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yylex(Piccolo.java:1290) > at > org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yyparse(Piccolo.java:1400) > at > org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:714) > at > org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3354) > at > org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1267) > at > org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1254) > at > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345) > at > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:309) > at org.apache.xmlbeans.XmlObject$Factory.parse(XmlObject.java:656) > at > org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.parse(XmlBeansUtil.java:74) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:326) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:263) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() > 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:817) > 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$$f226e5bd.getDeploymentPlan() > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) > at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() > 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:852) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) > at > org.apache.geronimo.deploymen
[jira] Updated: (GERONIMO-2151) geronino should ignore .DS_Store files in the deploy dir
[ http://issues.apache.org/jira/browse/GERONIMO-2151?page=all ] Christoph Sturm updated GERONIMO-2151: -- type: Improvement (was: Bug) oops, i created this a bug instead of improvement by mistake. sorry :) > geronino should ignore .DS_Store files in the deploy dir > > > Key: GERONIMO-2151 > URL: http://issues.apache.org/jira/browse/GERONIMO-2151 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: Hot Deploy Dir > Versions: 1.1 > Environment: osx > Reporter: Christoph Sturm > Priority: Minor > > osx stores extended file attributes in a dir called .DS_Store. > after copying a war file to the geronimo deploy dir with the finder it > creates the .DS_Store file, and geronimo tries to deploy it: > 14:47:48,065 INFO [Hot Deployer] Deploying .DS_Store > 14:47:48,284 ERROR [Hot Deployer] Unable to deploy: > org.apache.xmlbeans.XmlException: > /Users/christophsturm/Projects/geronimo-1.1/deploy/.DS_Store:1: error: > Illegal XML character: 0x0 > org.apache.xmlbeans.impl.piccolo.io.IllegalCharException: Illegal XML > character: 0x0 > at > org.apache.xmlbeans.impl.piccolo.xml.UTF8XMLDecoder.decode(UTF8XMLDecoder.java:196) > at > org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader$FastStreamDecoder.read(XMLStreamReader.java:762) > at > org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader.read(XMLStreamReader.java:162) > at > org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yy_refill(PiccoloLexer.java:3469) > at > org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yylex(PiccoloLexer.java:3953) > at > org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yylex(Piccolo.java:1290) > at > org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yyparse(Piccolo.java:1400) > at > org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:714) > at > org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3354) > at > org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1267) > at > org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1254) > at > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345) > at > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:309) > at org.apache.xmlbeans.XmlObject$Factory.parse(XmlObject.java:656) > at > org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.parse(XmlBeansUtil.java:74) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:326) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:263) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() > 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:817) > 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$$f226e5bd.getDeploymentPlan() > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) > at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() > 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:852) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) >
[jira] Created: (GERONIMO-2151) geronino should ignore .DS_Store files in the deploy dir
geronino should ignore .DS_Store files in the deploy dir Key: GERONIMO-2151 URL: http://issues.apache.org/jira/browse/GERONIMO-2151 Project: Geronimo Type: Bug Security: public (Regular issues) Components: Hot Deploy Dir Versions: 1.1 Environment: osx Reporter: Christoph Sturm Priority: Minor osx stores extended file attributes in a dir called .DS_Store. after copying a war file to the geronimo deploy dir with the finder it creates the .DS_Store file, and geronimo tries to deploy it: 14:47:48,065 INFO [Hot Deployer] Deploying .DS_Store 14:47:48,284 ERROR [Hot Deployer] Unable to deploy: org.apache.xmlbeans.XmlException: /Users/christophsturm/Projects/geronimo-1.1/deploy/.DS_Store:1: error: Illegal XML character: 0x0 org.apache.xmlbeans.impl.piccolo.io.IllegalCharException: Illegal XML character: 0x0 at org.apache.xmlbeans.impl.piccolo.xml.UTF8XMLDecoder.decode(UTF8XMLDecoder.java:196) at org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader$FastStreamDecoder.read(XMLStreamReader.java:762) at org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader.read(XMLStreamReader.java:162) at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yy_refill(PiccoloLexer.java:3469) at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yylex(PiccoloLexer.java:3953) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yylex(Piccolo.java:1290) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yyparse(Piccolo.java:1400) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:714) at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3354) at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1267) at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1254) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:309) at org.apache.xmlbeans.XmlObject$Factory.parse(XmlObject.java:656) at org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.parse(XmlBeansUtil.java:74) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:326) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:263) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() 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:817) 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$$f226e5bd.getDeploymentPlan() at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() 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:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:613) I think it would be best if the auto deployer would just ignore all files starting with a dot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1903) Add Spring to default class ignore list
[ http://issues.apache.org/jira/browse/GERONIMO-1903?page=all ] Jeff Genender closed GERONIMO-1903: --- Resolution: Fixed Added filters for spring and antlr (since this affects hibernate too) Sendingconfigs/jetty-deployer/src/plan/plan.xml Sendingconfigs/tomcat-deployer/src/plan/plan.xml Transmitting file data .. Committed revision 396947. > Add Spring to default class ignore list > --- > > Key: GERONIMO-1903 > URL: http://issues.apache.org/jira/browse/GERONIMO-1903 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: web > Versions: 1.1 > Reporter: Aaron Mulder > Assignee: Jeff Genender > Priority: Blocker > Fix For: 1.1 > > It's pretty dumb that anyone deploying a Spring app has to manually add > classloader excludes to their Geronimo plan. We should support Spring out of > the box. Which until we improve our CL structure means that we need to add > default excludes for Spring itself plus potentially any libraries commonly > shared between Spring/Acegi/etc. and Geronimo. > I guess we need a test app for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1903) Add Spring to default class ignore list
[ http://issues.apache.org/jira/browse/GERONIMO-1903?page=all ] Jeff Genender reassigned GERONIMO-1903: --- Assign To: Jeff Genender > Add Spring to default class ignore list > --- > > Key: GERONIMO-1903 > URL: http://issues.apache.org/jira/browse/GERONIMO-1903 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: web > Versions: 1.1 > Reporter: Aaron Mulder > Assignee: Jeff Genender > Priority: Blocker > Fix For: 1.1 > > It's pretty dumb that anyone deploying a Spring app has to manually add > classloader excludes to their Geronimo plan. We should support Spring out of > the box. Which until we improve our CL structure means that we need to add > default excludes for Spring itself plus potentially any libraries commonly > shared between Spring/Acegi/etc. and Geronimo. > I guess we need a test app for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (GERONIMO-1903) Add Spring to default class ignore list
If you can do it today that would be great. Thanks, Aaron On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > Aaron, > > Ok..I agree...lets filter antlr and Spring for 1.1 and fix the > classloaders post 1.1. Do you want to take this one (filter) or should > I? If you don't think you can get to it today, I am happy to put in the > filters. > > Jeff > > Aaron Mulder wrote: > > I don't think the class loaders are fixable for 1.1, whereas the > > exclude list is. > > > > Dain and David J have some ideas for how to fix the classloaders to > > separate apps from server internals, which I'd like to do shortly post > > 1.1. I think there's a separate JIRA for that. > > > > Are there other things we know of beyond Spring, Commons Logging, Antlr? > > > > Thanks, > > Aaron > > > > On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > >> This goes beyond Spring (and Commons Logging). It affects antlr too > >> when using Hibernate. I am sure there are a plethora of other > >> jar/packages this will affect too. > >> > >> Should we take a closer look at our classloaders and figure out why we > >> need to do this? > >> > >> Jeff > >> > >> Aaron Mulder (JIRA) wrote: > >>> Add Spring to default class ignore list > >>> --- > >>> > >>> Key: GERONIMO-1903 > >>> URL: http://issues.apache.org/jira/browse/GERONIMO-1903 > >>> Project: Geronimo > >>> Type: Bug > >>> Security: public (Regular issues) > >>> Components: web > >>> Versions: 1.1 > >>> Reporter: Aaron Mulder > >>> Priority: Blocker > >>> Fix For: 1.1 > >>> > >>> > >>> It's pretty dumb that anyone deploying a Spring app has to manually add > >>> classloader excludes to their Geronimo plan. We should support Spring > >>> out of the box. Which until we improve our CL structure means that we > >>> need to add default excludes for Spring itself plus potentially any > >>> libraries commonly shared between Spring/Acegi/etc. and Geronimo. > >>> > >>> I guess we need a test app for this. > >>> >
Re: [jira] Created: (GERONIMO-1903) Add Spring to default class ignore list
Aaron, Ok..I agree...lets filter antlr and Spring for 1.1 and fix the classloaders post 1.1. Do you want to take this one (filter) or should I? If you don't think you can get to it today, I am happy to put in the filters. Jeff Aaron Mulder wrote: > I don't think the class loaders are fixable for 1.1, whereas the > exclude list is. > > Dain and David J have some ideas for how to fix the classloaders to > separate apps from server internals, which I'd like to do shortly post > 1.1. I think there's a separate JIRA for that. > > Are there other things we know of beyond Spring, Commons Logging, Antlr? > > Thanks, > Aaron > > On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >> This goes beyond Spring (and Commons Logging). It affects antlr too >> when using Hibernate. I am sure there are a plethora of other >> jar/packages this will affect too. >> >> Should we take a closer look at our classloaders and figure out why we >> need to do this? >> >> Jeff >> >> Aaron Mulder (JIRA) wrote: >>> Add Spring to default class ignore list >>> --- >>> >>> Key: GERONIMO-1903 >>> URL: http://issues.apache.org/jira/browse/GERONIMO-1903 >>> Project: Geronimo >>> Type: Bug >>> Security: public (Regular issues) >>> Components: web >>> Versions: 1.1 >>> Reporter: Aaron Mulder >>> Priority: Blocker >>> Fix For: 1.1 >>> >>> >>> It's pretty dumb that anyone deploying a Spring app has to manually add >>> classloader excludes to their Geronimo plan. We should support Spring out >>> of the box. Which until we improve our CL structure means that we need to >>> add default excludes for Spring itself plus potentially any libraries >>> commonly shared between Spring/Acegi/etc. and Geronimo. >>> >>> I guess we need a test app for this. >>>
Re: [jira] Created: (GERONIMO-1903) Add Spring to default class ignore list
I don't think the class loaders are fixable for 1.1, whereas the exclude list is. Dain and David J have some ideas for how to fix the classloaders to separate apps from server internals, which I'd like to do shortly post 1.1. I think there's a separate JIRA for that. Are there other things we know of beyond Spring, Commons Logging, Antlr? Thanks, Aaron On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > This goes beyond Spring (and Commons Logging). It affects antlr too > when using Hibernate. I am sure there are a plethora of other > jar/packages this will affect too. > > Should we take a closer look at our classloaders and figure out why we > need to do this? > > Jeff > > Aaron Mulder (JIRA) wrote: > > Add Spring to default class ignore list > > --- > > > > Key: GERONIMO-1903 > > URL: http://issues.apache.org/jira/browse/GERONIMO-1903 > > Project: Geronimo > > Type: Bug > > Security: public (Regular issues) > > Components: web > > Versions: 1.1 > > Reporter: Aaron Mulder > > Priority: Blocker > > Fix For: 1.1 > > > > > > It's pretty dumb that anyone deploying a Spring app has to manually add > > classloader excludes to their Geronimo plan. We should support Spring out > > of the box. Which until we improve our CL structure means that we need to > > add default excludes for Spring itself plus potentially any libraries > > commonly shared between Spring/Acegi/etc. and Geronimo. > > > > I guess we need a test app for this. > > >
Re: [jira] Created: (GERONIMO-1903) Add Spring to default class ignore list
This goes beyond Spring (and Commons Logging). It affects antlr too when using Hibernate. I am sure there are a plethora of other jar/packages this will affect too. Should we take a closer look at our classloaders and figure out why we need to do this? Jeff Aaron Mulder (JIRA) wrote: > Add Spring to default class ignore list > --- > > Key: GERONIMO-1903 > URL: http://issues.apache.org/jira/browse/GERONIMO-1903 > Project: Geronimo > Type: Bug > Security: public (Regular issues) > Components: web > Versions: 1.1 > Reporter: Aaron Mulder > Priority: Blocker > Fix For: 1.1 > > > It's pretty dumb that anyone deploying a Spring app has to manually add > classloader excludes to their Geronimo plan. We should support Spring out of > the box. Which until we improve our CL structure means that we need to add > default excludes for Spring itself plus potentially any libraries commonly > shared between Spring/Acegi/etc. and Geronimo. > > I guess we need a test app for this. >
[jira] Created: (GERONIMO-1903) Add Spring to default class ignore list
Add Spring to default class ignore list --- Key: GERONIMO-1903 URL: http://issues.apache.org/jira/browse/GERONIMO-1903 Project: Geronimo Type: Bug Security: public (Regular issues) Components: web Versions: 1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1 It's pretty dumb that anyone deploying a Spring app has to manually add classloader excludes to their Geronimo plan. We should support Spring out of the box. Which until we improve our CL structure means that we need to add default excludes for Spring itself plus potentially any libraries commonly shared between Spring/Acegi/etc. and Geronimo. I guess we need a test app for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1685) Need to ignore .DS_Store files in deployment dirs
Need to ignore .DS_Store files in deployment dirs - Key: GERONIMO-1685 URL: http://issues.apache.org/jira/browse/GERONIMO-1685 Project: Geronimo Type: Bug Components: deployment Versions: 1.0 Environment: Mac OS X Reporter: Matt Bishop Priority: Trivial Mac OS X creates a little file in every directory that the user views in the Finder (Think Windows Explorer) called ".DS_Store". Geronimo, upon seeing such a file, tries to open it as if it were a deployable app, leading to the following stack traces: 09:03:00,995 WARN [DirectoryMonitor] Unable to calculate module ID for module /Library/Geronimo/Home/deploy/.DS_Store [/Library/Geronimo/Home/deploy/.DS_Store is neither a JAR file nor a directory!] 09:03:05,004 INFO [Hot Deployer] Deploying .DS_Store 09:03:05,299 ERROR [Hot Deployer] Unable to deploy: Cound not open module file: /Library/Geronimo/Home/var/temp/geronimo-deployer32634.tmpdir/.DS_Store org.apache.geronimo.common.DeploymentException: Cound not open module file: /Library/Geronimo/Home/var/temp/geronimo-deployer32634.tmpdir/.DS_Store at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:209) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:59) at java.lang.Thread.run(Thread.java:552) Caused by: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.(ZipFile.java:111) at java.util.jar.JarFile.(JarFile.java:127) at java.util.jar.JarFile.(JarFile.java:92) at org.apache.geronimo.deployment.util.DeploymentUtil.createJarFile(DeploymentUtil.java:164) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:207) ... 10 more It would be nice if Geronimo would ignore .DS_Store files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Test Mail....Please Ignore
test mail for geir - please ignore
Test mail - please ignore
testing
ignore
test
[jira] Closed: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
[ http://issues.apache.org/jira/browse/GERONIMO-823?page=all ] Gianny Damour closed GERONIMO-823: -- Resolution: Fixed Assign To: Gianny Damour (was: David Jencks) Sending axis-builder\src\java\org\apache\geronimo\axis\builder\HeavyweightTypeInfoBuilder.java Transmitting file data . Committed revision 263837. > We should accept (and ignore) simple type mappings in a jaxrpc-mapping file > --- > > Key: GERONIMO-823 > URL: http://issues.apache.org/jira/browse/GERONIMO-823 > Project: Geronimo > Type: Bug > Components: webservices > Versions: 1.0-M4, 1.0-M5 > Reporter: David Jencks > Assignee: Gianny Damour > Fix For: 1.0-M5 > > The IBM jaxrpc mapping generator likes to produce redundant unneccesary type > mappings for built in simple types such as > > java.math.BigDecimal > xmlns:rtq="http://www.w3.org/2001/XMLSchema";>rtq:decimal > simpleType > > The spec doesn't appear to mention or prohibit these. In the interests of > portability we should ignore these rather than objecting to them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
[ http://issues.apache.org/jira/browse/GERONIMO-823?page=all ] David Jencks reassigned GERONIMO-823: - Assign To: David Jencks > We should accept (and ignore) simple type mappings in a jaxrpc-mapping file > --- > > Key: GERONIMO-823 > URL: http://issues.apache.org/jira/browse/GERONIMO-823 > Project: Geronimo > Type: Bug > Components: webservices > Versions: 1.0-M4, 1.0-M5 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.0-M5 > > The IBM jaxrpc mapping generator likes to produce redundant unneccesary type > mappings for built in simple types such as > > java.math.BigDecimal > xmlns:rtq="http://www.w3.org/2001/XMLSchema";>rtq:decimal > simpleType > > The spec doesn't appear to mention or prohibit these. In the interests of > portability we should ignore these rather than objecting to them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Closed: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
...meaning you want me to open 823 and close 824? On Jul 27, 2005, at 3:16 PM, Matt Hogstrom wrote: Oops...my JIRA was 824 :) - Original Message - From: "David Blevins (JIRA)" To: Sent: Wednesday, July 27, 2005 3:55 PM Subject: [jira] Closed: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file [ http://issues.apache.org/jira/browse/GERONIMO-823?page=all ] David Blevins closed GERONIMO-823: -- Resolution: Fixed Checked into OpenEJB by Matt Hogstrom. Closing the issue for him as he doesn't have Geronimo access. We should accept (and ignore) simple type mappings in a jaxrpc- mapping file - - - Key: GERONIMO-823 URL: http://issues.apache.org/jira/browse/GERONIMO-823 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Fix For: 1.0-M5 The IBM jaxrpc mapping generator likes to produce redundant unneccesary type mappings for built in simple types such as java.math.BigDecimal xmlns:rtq="http://www.w3.org/2001/XMLSchema";>rtq:decimalqname> simpleType The spec doesn't appear to mention or prohibit these. In the interests of portability we should ignore these rather than objecting to them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
[ http://issues.apache.org/jira/browse/GERONIMO-823?page=all ] David Jencks reopened GERONIMO-823: --- read carefully before closing, Matt fixed GERONIMO-824 > We should accept (and ignore) simple type mappings in a jaxrpc-mapping file > --- > > Key: GERONIMO-823 > URL: http://issues.apache.org/jira/browse/GERONIMO-823 > Project: Geronimo > Type: Bug > Components: webservices > Versions: 1.0-M4, 1.0-M5 > Reporter: David Jencks > Fix For: 1.0-M5 > > The IBM jaxrpc mapping generator likes to produce redundant unneccesary type > mappings for built in simple types such as > > java.math.BigDecimal > xmlns:rtq="http://www.w3.org/2001/XMLSchema";>rtq:decimal > simpleType > > The spec doesn't appear to mention or prohibit these. In the interests of > portability we should ignore these rather than objecting to them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Closed: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
Oops...my JIRA was 824 :) - Original Message - From: "David Blevins (JIRA)" To: Sent: Wednesday, July 27, 2005 3:55 PM Subject: [jira] Closed: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file > [ http://issues.apache.org/jira/browse/GERONIMO-823?page=all ] > > David Blevins closed GERONIMO-823: > -- > > Resolution: Fixed > > Checked into OpenEJB by Matt Hogstrom. Closing the issue for him as he doesn't have Geronimo access. > > > We should accept (and ignore) simple type mappings in a jaxrpc-mapping file > > -- - > > > > Key: GERONIMO-823 > > URL: http://issues.apache.org/jira/browse/GERONIMO-823 > > Project: Geronimo > > Type: Bug > > Components: webservices > > Versions: 1.0-M4, 1.0-M5 > > Reporter: David Jencks > > Fix For: 1.0-M5 > > > > > The IBM jaxrpc mapping generator likes to produce redundant unneccesary type mappings for built in simple types such as > > > > java.math.BigDecimal > > http://www.w3.org/2001/XMLSchema";>rtq:decimal > > simpleType > > > > The spec doesn't appear to mention or prohibit these. In the interests of portability we should ignore these rather than objecting to them. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: >http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: >http://www.atlassian.com/software/jira > > > >
[jira] Closed: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
[ http://issues.apache.org/jira/browse/GERONIMO-823?page=all ] David Blevins closed GERONIMO-823: -- Resolution: Fixed Checked into OpenEJB by Matt Hogstrom. Closing the issue for him as he doesn't have Geronimo access. > We should accept (and ignore) simple type mappings in a jaxrpc-mapping file > --- > > Key: GERONIMO-823 > URL: http://issues.apache.org/jira/browse/GERONIMO-823 > Project: Geronimo > Type: Bug > Components: webservices > Versions: 1.0-M4, 1.0-M5 > Reporter: David Jencks > Fix For: 1.0-M5 > > The IBM jaxrpc mapping generator likes to produce redundant unneccesary type > mappings for built in simple types such as > > java.math.BigDecimal > xmlns:rtq="http://www.w3.org/2001/XMLSchema";>rtq:decimal > simpleType > > The spec doesn't appear to mention or prohibit these. In the interests of > portability we should ignore these rather than objecting to them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
[ http://issues.apache.org/jira/browse/GERONIMO-823?page=comments#action_12316950 ] David Jencks commented on GERONIMO-823: --- Thanks for volunteering! For now I'll stick with what I think I can implement :-) > We should accept (and ignore) simple type mappings in a jaxrpc-mapping file > --- > > Key: GERONIMO-823 > URL: http://issues.apache.org/jira/browse/GERONIMO-823 > Project: Geronimo > Type: Bug > Components: webservices > Versions: 1.0-M4, 1.0-M5 > Reporter: David Jencks > Fix For: 1.0-M5 > > The IBM jaxrpc mapping generator likes to produce redundant unneccesary type > mappings for built in simple types such as > > java.math.BigDecimal > xmlns:rtq="http://www.w3.org/2001/XMLSchema";>rtq:decimal > simpleType > > The spec doesn't appear to mention or prohibit these. In the interests of > portability we should ignore these rather than objecting to them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
[ http://issues.apache.org/jira/browse/GERONIMO-823?page=comments#action_12316948 ] Dain Sundstrom commented on GERONIMO-823: - Why not allow them to override the default "built in simple types"? > We should accept (and ignore) simple type mappings in a jaxrpc-mapping file > --- > > Key: GERONIMO-823 > URL: http://issues.apache.org/jira/browse/GERONIMO-823 > Project: Geronimo > Type: Bug > Components: webservices > Versions: 1.0-M4, 1.0-M5 > Reporter: David Jencks > Fix For: 1.0-M5 > > The IBM jaxrpc mapping generator likes to produce redundant unneccesary type > mappings for built in simple types such as > > java.math.BigDecimal > xmlns:rtq="http://www.w3.org/2001/XMLSchema";>rtq:decimal > simpleType > > The spec doesn't appear to mention or prohibit these. In the interests of > portability we should ignore these rather than objecting to them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
We should accept (and ignore) simple type mappings in a jaxrpc-mapping file --- Key: GERONIMO-823 URL: http://issues.apache.org/jira/browse/GERONIMO-823 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Fix For: 1.0-M5 The IBM jaxrpc mapping generator likes to produce redundant unneccesary type mappings for built in simple types such as java.math.BigDecimal http://www.w3.org/2001/XMLSchema";>rtq:decimal simpleType The spec doesn't appear to mention or prohibit these. In the interests of portability we should ignore these rather than objecting to them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-530) Migration test - please ignore
[ http://nagoya.apache.org/jira/browse/GERONIMO-530?page=history ] Jeremy Boynes closed GERONIMO-530: -- Resolution: Invalid > Migration test - please ignore > -- > > Key: GERONIMO-530 > URL: http://nagoya.apache.org/jira/browse/GERONIMO-530 > Project: Apache Geronimo > Type: Test > Reporter: Jeremy Boynes > > Opened in real instance to avoid confusion with id -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-530) Migration test - please ignore
Migration test - please ignore -- Key: GERONIMO-530 URL: http://nagoya.apache.org/jira/browse/GERONIMO-530 Project: Apache Geronimo Type: Test Reporter: Jeremy Boynes Opened in real instance to avoid confusion with id -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: Questions/Proposed changes to BUILDING.txt file - correction, please ignore previous message
[EMAIL PROTECTED] wrote: If the proposed changes make sense, should I create a JIRA issue and attach a patch? It's not necessary now as the changes have been committed :) Many thanks! The next time, please submit a issue in JIRA so that it won't disappear. If the issue is irrelevant (= doesn't make sense) it will simply be closed. Q1. If maven has already been run to build all of geronimo (see line 19), then it appears there is no need to run maven again (see line 24). Maybe the doco could be reworded to make it clearer on the two different ways Geronimo can be built? Absolutelly. Please propose a change and it'll be applied. Thanks, John Sisson Jacek
Questions/Proposed changes to BUILDING.txt file - correction, please ignore previous message
Hi, I'm a newbie to the project and have been reading the instructions in the BUILDING.txt file (taken from CVS) and have some questions: The following is an extract of the text in the BUILDING.txt file: 01 Welcome to Geronimo 02 === 03 04 To build me please install Maven from here - version b10 or later. 05 06 http://maven.apache.org/ 07 08 In addition you should have JDK 1.4.x installed with JAVA_HOME 09 environment defined to point to this JDK. 10 11 In the following examples, '$>' is your prompt, so if you see 12 '$>maven', at your prompt, type in 'maven' (without the quotes) 13 and then press [enter]. 14 15 To build Geronimo running all of the unit test cases, compiling 16 all the Geronimo sources and installing them in your local maven 17 repository: 18 19 $>maven 20 21 To build and run the server, change into the assembly directory and 22 type: 23 24 $>maven 25 $>cd target 26 $>java -jar bin/server.jar org/apache/geronimo/Server == Assuming I haven't misinterpreted the instructions in BUILDING.txt (extract shown above), I propose the following changes: A). Change sentence at lines 15-17 to read: To build Geronimo running all of the unit test cases, compiling all the Geronimo sources and installing them in your local maven repository, simply type maven in the root of the Geronimo source tree B). Insert a line before line 24 to show the location of the assembly directory: cd modules/assembly C) The directory name for the server.jar file in the command at line 26 is incorrect. Line 26 needs to be changed to: java -jar target/geronimo-1.0-SNAPSHOT/bin/server.jar org/apache/geronimo/Server If the proposed changes make sense, should I create a JIRA issue and attach a patch? ** Questions: Q1. If maven has already been run to build all of geronimo (see line 19), then it appears there is no need to run maven again (see line 24). Maybe the doco could be reworded to make it clearer on the two different ways Geronimo can be built? Thanks, John Sisson
