Re: TCK access

[Jay D. McHugh]

I'm guessing still no news, eh?

Here is a link to the email where Geir acknowledged receiving my NDA.

http://mail-archives.apache.org/mod_mbox/www-jcp-open/200708.mbox/[EMAIL 
PROTECTED]

If I need to resend it though, let me know and I'll try to find the 
original.


Thanks,

Jay

Matt Hogstrom wrote:

no, I'll try again.


On Nov 2, 2007, at 1:46 PM, Jay D. McHugh wrote:


Just curious - Any news on this?

Jay

Matt Hogstrom wrote:

I sent him a private ping as well just as a heads up.


On Oct 27, 2007, at 10:52 AM, Alan D. Cabrera wrote:



On Oct 27, 2007, at 5:13 AM, Kevan Miller wrote:



On Oct 26, 2007, at 11:57 PM, Alan D. Cabrera wrote:

I think that Geir has to ACK that the paperwork was completed.  
Has he done so?


I don't see an ACK on our tck list. I recall that Tim had a lot of 
problems getting the NDA acked.


Geir,
Do you have an NDA on file for Jay McHugh? If not, what's the best 
way for him to get this to you?


He may not be reading this list intently.  I'll forward to the TCK 
list.



Regards,
Alan

[jira] Commented: (GSHELL-16) New command: ssh

[Jason Dillon (JIRA)]

[ 
https://issues.apache.org/jira/browse/GSHELL-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541220
 ] 

Jason Dillon commented on GSHELL-16:


Cool.  Post a patch on this issue when you have something for review/submission 
:-)

> New command: ssh
> 
>
> Key: GSHELL-16
> URL: https://issues.apache.org/jira/browse/GSHELL-16
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Commands
>Reporter: Jason Dillon
>Priority: Minor
> Fix For: 1.0-alpha-2
>
>
> Can wrap the Jsch API to make a ssh command

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GSHELL-16) New command: ssh

[Ken Treiman (JIRA)]

[ 
https://issues.apache.org/jira/browse/GSHELL-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541219
 ] 

Ken Treiman commented on GSHELL-16:
---

Got it working now.  I just need to clean up my code a bit and add some 
comments.  How would I submit this for review?

> New command: ssh
> 
>
> Key: GSHELL-16
> URL: https://issues.apache.org/jira/browse/GSHELL-16
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Commands
>Reporter: Jason Dillon
>Priority: Minor
> Fix For: 1.0-alpha-2
>
>
> Can wrap the Jsch API to make a ssh command

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-16) New command: ssh

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-16:
---

Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2

> New command: ssh
> 
>
> Key: GSHELL-16
> URL: https://issues.apache.org/jira/browse/GSHELL-16
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Commands
>Reporter: Jason Dillon
>Priority: Minor
> Fix For: 1.0-alpha-2
>
>
> Can wrap the Jsch API to make a ssh command

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [ANNOUNCE] Apache ServiceMix 3.2 released !

[Freeman Fang]

The missing parent module is already in the central repo now.

Cheers

Freeman

Freeman Fang wrote:

I will fix it and upload the missing parent module soon.
 
Freeman


 
On 11/8/07, *Guillaume Nodet* <[EMAIL PROTECTED] 
> wrote:


Freeman, it seems this bit is missing from the repo and from your
staging are too.
Do you have a copy locally that we could upload ?


-- Forwarded message --
From: *Daryl Richter* < [EMAIL PROTECTED] >
Date: Nov 8, 2007 2:15 PM
Subject: Re: [ANNOUNCE] Apache ServiceMix 3.2 released !
To: [EMAIL PROTECTED]

Cc: [EMAIL PROTECTED]



Ok.  So I changed the servicmix-version references in my project from
"3.2-incubating-SNAPSHOT" to "3.2" and tried to rebuild, but got the
following:

Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/

serviceengines/3.2/serviceengines-3.2.pom
1K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/
parent/3.2/parent-3.2.pom
[INFO]

[ERROR] BUILD ERROR
[INFO]


[INFO] Failed to resolve artifact.

GroupId: org.apache.servicemix
ArtifactId: parent
Version: 3.2

Reason: Unable to download the artifact from any repository

  org.apache.servicemix:parent:pom:3.2

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)


[INFO]


[INFO] For more information, run Maven with the -e switch
[INFO]


[INFO] Total time: 1 minute 58 seconds
[INFO] Finished at: Thu Nov 08 08:12:31 EST 2007
[INFO] Final Memory: 4M/8M
[INFO]


I dumped by .m2/repository/ but same result.

What am I doing wrong?

Thanks!


On Nov 7, 2007, at 8:43 PM, Freeman Fang wrote:

> The Apache ServiceMix team is proud to announce the availability of
> the 3.2 release!
>
> Apache ServiceMix is a TLP (Top Level Project under Apache), which
> is an open source distributed Enterprise
> Service Bus (ESB)
> and SOA toolkit built from the ground up on the semantics and APIs
> of the Java
> Business Integration (JBI) specification JSR 208 and released under
> the Apache
> 2.0 license.
>
> Apache ServiceMix is lightweight and easily embeddable, has
> integrated Spring
> support and can be run at the edge of the network (inside a client
> or server),
> as a standalone ESB provider or as a service within another ESB.
> You can use ServiceMix in Java SE or a Java EE application server.
>
> This release includes a number of important fixes and a few
> enhancements.
> For more information see:
> * Website: http://servicemix.apache.org/
> * Release Notes: http://servicemix.apache.org/servicemix-32.html
> * Mailing lists: http://servicemix.apache.org/mailing-lists.html
>
> If you have feedback, questions or would like to get involved in the
> ServiceMix project please join the mailing lists and let us know your
> thoughts.
>
>
> The Apache ServiceMix Team
> http://servicemix.apache.org/team.html
>

 
--

Daryl
http://itsallsemantics.com 

"Hell, there are no rules here-- we're trying to accomplish
something."
-- Thomas A. Edison






-- 
Cheers,

Guillaume Nodet

Blog: http://gnodet.blogspot.com/

[jira] Updated: (GSHELL-19) New command: vfs/browse

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-19:
---

Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2

> New command: vfs/browse
> ---
>
> Key: GSHELL-19
> URL: https://issues.apache.org/jira/browse/GSHELL-19
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Commands
>Reporter: Jason Dillon
>Priority: Minor
> Fix For: 1.0-alpha-2
>
>
> Implement a filesystem browser command with VFS to augment the current VFS 
> copy command.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-52) Expose real SSL configuration bits

[Jason Dillon (JIRA)]

Expose real SSL configuration bits
--

 Key: GSHELL-52
 URL: https://issues.apache.org/jira/browse/GSHELL-52
 Project: GShell
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: Whisper
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
 Fix For: 1.0-alpha-2


Right now for SSL, the {{BogusSSLContextFactory}} is used.  This works, but 
isn't very nice for folks that want to use their own certs and/or configure 
client-auth and such.  So we should create a new factory which is more 
configurable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-51) Generalize the transport access on per-thread bases

[Jason Dillon (JIRA)]

Generalize the transport access on per-thread bases
---

 Key: GSHELL-51
 URL: https://issues.apache.org/jira/browse/GSHELL-51
 Project: GShell
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: Whisper
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
 Fix For: 1.0-alpha-2


Need to generalize how something gets a holf of the current whisper transport.  
Many different things need it which can not be injected, like JAAS or rfile:// 
handlers, etc.  So we need to provide a _secure_ way to allow these components 
access to the current transport in use to allow them to communicate.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-50) Make the XMLLayoutLoader more configurable

[Jason Dillon (JIRA)]

Make the XMLLayoutLoader more configurable
--

 Key: GSHELL-50
 URL: https://issues.apache.org/jira/browse/GSHELL-50
 Project: GShell
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: Core
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
 Fix For: 1.0-alpha-1


Right now the XML layout loader is hard-coded to load {{etc/layout.xml}} from 
the shell's home dir (resolved from {{ShellInfo}}).  Need to clean up this API 
and make it easier for applications to configure.

Probably also need to have a default/fall-back loaded from a resource too.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-49) When --language is not given and we have a file/URL try and figure out the lang to use

[Jason Dillon (JIRA)]

When --language is not given and we have a file/URL try and figure out the lang 
to use
--

 Key: GSHELL-49
 URL: https://issues.apache.org/jira/browse/GSHELL-49
 Project: GShell
  Issue Type: Sub-task
  Security Level: public (Regular issues)
  Components: Commands - BSF
Reporter: Jason Dillon
Priority: Trivial
 Fix For: 1.0-alpha-2




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-48) Add file/URL support to the script command

[Jason Dillon (JIRA)]

Add file/URL support to the script command
--

 Key: GSHELL-48
 URL: https://issues.apache.org/jira/browse/GSHELL-48
 Project: GShell
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: Commands - BSF
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Priority: Minor
 Fix For: 1.0-alpha-2


Should be able to give the BSF {{script}} command a file or URL to execute.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-47) Add flag (and support) to capture the output of a gsh run to a log-file configured on the cli

[Jason Dillon (JIRA)]

Add flag (and support) to capture the output of a gsh run to a log-file 
configured on the cli
-

 Key: GSHELL-47
 URL: https://issues.apache.org/jira/browse/GSHELL-47
 Project: GShell
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: CLI
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Priority: Minor
 Fix For: 1.0-alpha-2


Should be able to specify something like:

{noformat}
./bin/gsh --logfile output.log
{noformat}

And have all of the output captured to a file named {{output.log}}, or whatever 
was given to the {{--logfile}} option.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-46) Add flag to show exception stacktraces

[Jason Dillon (JIRA)]

Add flag to show exception stacktraces
--

 Key: GSHELL-46
 URL: https://issues.apache.org/jira/browse/GSHELL-46
 Project: GShell
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: CLI
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Priority: Trivial
 Fix For: 1.0-alpha-2


Add a flag to the main CLI to show exception stacktraces (like mvn -e)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-45) Figure out why some test-related dependencies are included in to the assembly

[Jason Dillon (JIRA)]

Figure out why some test-related dependencies are included in to the assembly
-

 Key: GSHELL-45
 URL: https://issues.apache.org/jira/browse/GSHELL-45
 Project: GShell
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Build
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Priority: Trivial
 Fix For: 1.0-alpha-1


Right now a few test-related artifacts are included into the assembly by 
default and we have to exclude them.  The {{dependencyManagement}} section 
should have excludes for artifacts with bunk deps (in the wrong scope) so this 
exclude should not be needed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GSHELL-33) Finish integration of JAAS for rsh -> rsh-server authentication

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon closed GSHELL-33.
--

Resolution: Fixed

This is done mostly... need to get someone who knows JAAS more than I do to see 
if the implementation is sane though.

> Finish integration of JAAS for rsh -> rsh-server authentication
> ---
>
> Key: GSHELL-33
> URL: https://issues.apache.org/jira/browse/GSHELL-33
> Project: GShell
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Remote Shell
>Reporter: Jason Dillon
>Assignee: Jason Dillon
> Fix For: 1.0-alpha-1
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-31) Revisit using Modello for the gshell-layout xml handling instead of XStream

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-31:
---

Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2

> Revisit using Modello for the gshell-layout xml handling instead of XStream
> ---
>
> Key: GSHELL-31
> URL: https://issues.apache.org/jira/browse/GSHELL-31
> Project: GShell
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Reporter: Jason Dillon
>Assignee: Jason Dillon
>Priority: Trivial
> Fix For: 1.0-alpha-2
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GSHELL-16) New command: ssh

[Jason Dillon (JIRA)]

[ 
https://issues.apache.org/jira/browse/GSHELL-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541208
 ] 

Jason Dillon commented on GSHELL-16:


Howz this going?

> New command: ssh
> 
>
> Key: GSHELL-16
> URL: https://issues.apache.org/jira/browse/GSHELL-16
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Commands
>Reporter: Jason Dillon
>Priority: Minor
> Fix For: 1.0-alpha-1
>
>
> Can wrap the Jsch API to make a ssh command

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-44) Update help command to display name/alias instead of command id and support options for command tree display

[Jason Dillon (JIRA)]

Update help command to display name/alias instead of command id and support 
options for command tree display


 Key: GSHELL-44
 URL: https://issues.apache.org/jira/browse/GSHELL-44
 Project: GShell
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: Commands - Builtins, Core
Reporter: Jason Dillon
Assignee: Jason Dillon
 Fix For: 1.0-alpha-1




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GSHELL-42) Abstract the layout of commands available to users for application customization

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon closed GSHELL-42.
--

Resolution: Fixed

> Abstract the layout of commands available to users for application 
> customization
> 
>
> Key: GSHELL-42
> URL: https://issues.apache.org/jira/browse/GSHELL-42
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Core
>Reporter: Jason Dillon
>Assignee: Jason Dillon
> Fix For: 1.0-alpha-1
>
>
> Need to provide an abstraction of the layout of commands in the shell to 
> allow applications to customize the view for users.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GSHELL-42) Abstract the layout of commands available to users for application customization

[Jason Dillon (JIRA)]

[ 
https://issues.apache.org/jira/browse/GSHELL-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541204
 ] 

Jason Dillon commented on GSHELL-42:


This is done, just need to update the help command to show the name/alias 
instead of the command's id.  Also need to figure out what to do about 
rendering the tree of commands.  Right now we display all commands, might only 
want to show those in context, or all children, etc.  Probably need some more 
flags on {{help}} to control what is displayed and default to displaying all in 
context er something.

> Abstract the layout of commands available to users for application 
> customization
> 
>
> Key: GSHELL-42
> URL: https://issues.apache.org/jira/browse/GSHELL-42
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Core
>Reporter: Jason Dillon
>Assignee: Jason Dillon
> Fix For: 1.0-alpha-1
>
>
> Need to provide an abstraction of the layout of commands in the shell to 
> allow applications to customize the view for users.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-43) Add role-based layout selection

[Jason Dillon (JIRA)]

Add role-based layout selection
---

 Key: GSHELL-43
 URL: https://issues.apache.org/jira/browse/GSHELL-43
 Project: GShell
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: Core
Reporter: Jason Dillon
Priority: Minor
 Fix For: 1.0-alpha-2


Add support to select a different layout based on the user who is logged in.  
Some users might need only basic commands while others might need a full range 
(of admin or potentially harmful commands).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-42) Abstract the layout of commands available to users for application customization

[Jason Dillon (JIRA)]

Abstract the layout of commands available to users for application customization


 Key: GSHELL-42
 URL: https://issues.apache.org/jira/browse/GSHELL-42
 Project: GShell
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: Core
Reporter: Jason Dillon
Assignee: Jason Dillon
 Fix For: 1.0-alpha-1


Need to provide an abstraction of the layout of commands in the shell to allow 
applications to customize the view for users.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-8) SSH support for rshd

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-8:
--

Summary: SSH support for rshd  (was: SSH support)

> SSH support for rshd
> 
>
> Key: GSHELL-8
> URL: https://issues.apache.org/jira/browse/GSHELL-8
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Remote Shell
>Affects Versions: 0.0.1
>Reporter: Jason Dillon
>Assignee: Jason Dillon
> Fix For: 1.0-alpha-1
>
>
> Can Jsch do this or not?  or maybe:
> http://sourceforge.net/projects/sshtools/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-41) Add i18n message support

[Jason Dillon (JIRA)]

Add i18n message support


 Key: GSHELL-41
 URL: https://issues.apache.org/jira/browse/GSHELL-41
 Project: GShell
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: Support - I18n
Reporter: Jason Dillon
Priority: Minor
 Fix For: 1.0-alpha-2


Need to create a simple API to allow commands to _easily_ internationalize 
messages.

Probably need to:

 * create an annotation injection system for i18n messages
 * hook up i18n to clp
 * hook up i18n to prefs
 * create a rendering system (like the ansi renderer) to insert i18n messages 
in place of tokens

A skeleton project is setup for i18n here:

 * 
https://svn.apache.org/repos/asf/geronimo/gshell/trunk/gshell-support/gshell-i18n/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-40) Add annotation-based preferences injection support

[Jason Dillon (JIRA)]

Add annotation-based preferences injection support
--

 Key: GSHELL-40
 URL: https://issues.apache.org/jira/browse/GSHELL-40
 Project: GShell
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: Support - Prefs
Reporter: Jason Dillon
Priority: Minor
 Fix For: 1.0-alpha-2


Add a simple annotation-based API to allow the preferences API to be used by 
commands (similar to how the CLP stuff makes it simple to handle command-line 
options and arguments).

A skeleton project is setup here for the prefs stuff:

 * 
https://svn.apache.org/repos/asf/geronimo/gshell/trunk/gshell-support/gshell-prefs/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-20) `set foo="bar"` does not work as expected

[Jason Warner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Warner updated GSHELL-20:
---

Affects Version/s: 0.0.1

> `set foo="bar"` does not work as expected
> -
>
> Key: GSHELL-20
> URL: https://issues.apache.org/jira/browse/GSHELL-20
> Project: GShell
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Commands, Core
>Affects Versions: 0.0.1
>Reporter: Jason Dillon
>Assignee: Jason Warner
>Priority: Critical
> Fix For: 1.0-alpha-2
>
>
> Due to the way parsing happens, this line:
> {noformat}
> set foo="bar"
> {noformat}
> Ends up calling the command with 2 arguments: "foo=" and "bar", which is not 
> what the command expects, which is one argument of: "foo=bar"

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-20) `set foo="bar"` does not work as expected

[Jason Warner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Warner updated GSHELL-20:
---

Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2
Affects Version/s: (was: 0.0.1)

> `set foo="bar"` does not work as expected
> -
>
> Key: GSHELL-20
> URL: https://issues.apache.org/jira/browse/GSHELL-20
> Project: GShell
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Commands, Core
>Reporter: Jason Dillon
>Assignee: Jason Warner
>Priority: Critical
> Fix For: 1.0-alpha-2
>
>
> Due to the way parsing happens, this line:
> {noformat}
> set foo="bar"
> {noformat}
> Ends up calling the command with 2 arguments: "foo=" and "bar", which is not 
> what the command expects, which is one argument of: "foo=bar"

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-39) Add dependencies configuration for command.xml (in similar fashion to how Maven plugin.xml has this)

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-39:
---

Description: Need to add repository support (probably via 
{{maven-artifact}}) and allow a {{}} configuration for 
{{commands.xml}} to setup the classpath for a command w/o needing to pull in 
_every_ command's dependencies into the lib/* dir.  (was: Need to add 
repository support (probably via {{maven-artifact}}) and allow a 
{{}} configuration for {{commands.xml}} to setup the classpath 
for a command w/o needing to pull in _every) command's dependencies into the 
lib/* dir.)

> Add dependencies configuration for command.xml (in similar fashion to how 
> Maven plugin.xml has this)
> 
>
> Key: GSHELL-39
> URL: https://issues.apache.org/jira/browse/GSHELL-39
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Commands, Core
>Affects Versions: 1.0-alpha-1
>Reporter: Jason Dillon
> Fix For: 1.0-alpha-2
>
>
> Need to add repository support (probably via {{maven-artifact}}) and allow a 
> {{}} configuration for {{commands.xml}} to setup the classpath 
> for a command w/o needing to pull in _every_ command's dependencies into the 
> lib/* dir.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-39) Add dependencies configuration for command.xml (in similar fashion to how Maven plugin.xml has this)

[Jason Dillon (JIRA)]

Add dependencies configuration for command.xml (in similar fashion to how Maven 
plugin.xml has this)


 Key: GSHELL-39
 URL: https://issues.apache.org/jira/browse/GSHELL-39
 Project: GShell
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: Commands, Core
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
 Fix For: 1.0-alpha-2


Need to add repository support (probably via {{maven-artifact}}) and allow a 
{{}} configuration for {{commands.xml}} to setup the classpath 
for a command w/o needing to pull in _every) command's dependencies into the 
lib/* dir.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-3) Hook up backtick and execute assign bits... foo=`echo bar`

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-3:
--

Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2

> Hook up backtick and execute assign bits... foo=`echo bar`
> --
>
> Key: GSHELL-3
> URL: https://issues.apache.org/jira/browse/GSHELL-3
> Project: GShell
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 0.0.1
>Reporter: Jason Dillon
>Priority: Critical
> Fix For: 1.0-alpha-2
>
>
> Hook up backtick and execute assign bits... foo=`echo bar`
> Dunno if this captures the output of 'echo bar' or the return of the command
> Might need to have both?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-1) Add ${...} parsing to the CommandLineParser; remove VariableExpressionParser

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-1:
--

Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2

> Add ${...} parsing to the CommandLineParser; remove VariableExpressionParser
> 
>
> Key: GSHELL-1
> URL: https://issues.apache.org/jira/browse/GSHELL-1
> Project: GShell
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 0.0.1
>Reporter: Jason Dillon
>Priority: Critical
> Fix For: 1.0-alpha-2
>
>
> Currently variable references are post-parsed because that was easier to get 
> implemented.  The CL parser should be able to handle all parsing.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-24) Support background commands

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-24:
---

Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2
 Priority: Minor  (was: Major)

> Support background commands
> ---
>
> Key: GSHELL-24
> URL: https://issues.apache.org/jira/browse/GSHELL-24
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Core
>Reporter: Jason Dillon
>Priority: Minor
> Fix For: 1.0-alpha-2
>
>
> Should be able to background a command using the {{&}} token.
> Also need to be able to {{bg}}, {{fg}} and enumerate {{jobs}}.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-25) Sub-shell syntax support

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-25:
---

Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2
 Priority: Minor  (was: Major)

> Sub-shell syntax support
> 
>
> Key: GSHELL-25
> URL: https://issues.apache.org/jira/browse/GSHELL-25
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Core
>Reporter: Jason Dillon
>Priority: Minor
> Fix For: 1.0-alpha-2
>
>
> Support constructs like:
> {noformat}
> set a=b ; (set a=c; echo $a); echo $a
> {noformat}
> This should create 2 shells. and result in:
> {noformat}
> c
> b
> {noformat}
> Executes as follows:
>  * set a=b
>  ** set a=c
>  ** echo $a
>  * echo $a
> Intenally the sub-shell is delegated to the builtin subshell command.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-17) New command: subshell

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-17:
---

Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2
 Priority: Minor  (was: Major)

> New command: subshell
> -
>
> Key: GSHELL-17
> URL: https://issues.apache.org/jira/browse/GSHELL-17
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Commands
>Reporter: Jason Dillon
>Priority: Minor
> Fix For: 1.0-alpha-2
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-23) Command pipe-lines

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-23:
---

  Component/s: Parser
Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2

> Command pipe-lines
> --
>
> Key: GSHELL-23
> URL: https://issues.apache.org/jira/browse/GSHELL-23
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Core, Parser
>Reporter: Jason Dillon
> Fix For: 1.0-alpha-2
>
>
> Add support for piping the output of one command into another, as in:
> {noformat}
> echo "hi" | cat > /tmp/foo
> {noformat}
> This should write "hi" to the /tmp/foo file.
> Follow zsh style, allowing |& to concat both stdout+stderr

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-22) Input/output redirection

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-22:
---

  Component/s: Parser
Fix Version/s: (was: 1.0-alpha-1)
   1.0-alpha-2

> Input/output redirection
> 
>
> Key: GSHELL-22
> URL: https://issues.apache.org/jira/browse/GSHELL-22
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Core, Parser
>Reporter: Jason Dillon
> Fix For: 1.0-alpha-2
>
>
> Support input and output redirection with < and > tokens.
> These will hook up to standard input and output commands (like cat, and read) 
> and the CL builder will hook them up as endpoints on the pipe-line.
> Follow zsh style, allowing >& to concat both stdout+stderr

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-31) Revisit using Modello for the gshell-layout xml handling instead of XStream

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-31:
---

Component/s: Core

> Revisit using Modello for the gshell-layout xml handling instead of XStream
> ---
>
> Key: GSHELL-31
> URL: https://issues.apache.org/jira/browse/GSHELL-31
> Project: GShell
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Reporter: Jason Dillon
>Assignee: Jason Dillon
> Fix For: 1.0-alpha-1
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GSHELL-31) Revisit using Modello for the gshell-layout xml handling instead of XStream

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-31:
---

Priority: Trivial  (was: Major)

> Revisit using Modello for the gshell-layout xml handling instead of XStream
> ---
>
> Key: GSHELL-31
> URL: https://issues.apache.org/jira/browse/GSHELL-31
> Project: GShell
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Reporter: Jason Dillon
>Assignee: Jason Dillon
>Priority: Trivial
> Fix For: 1.0-alpha-1
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [ANNOUNCE] Apache ServiceMix 3.2 released !

[Freeman Fang]

I will fix it and upload the missing parent module soon.

Freeman


On 11/8/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>
> Freeman, it seems this bit is missing from the repo and from your staging
> are too.
> Do you have a copy locally that we could upload ?
>
> -- Forwarded message --
> From: Daryl Richter <[EMAIL PROTECTED]>
> Date: Nov 8, 2007 2:15 PM
> Subject: Re: [ANNOUNCE] Apache ServiceMix 3.2 released !
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
>
>
> Ok.  So I changed the servicmix-version references in my project from
> "3.2-incubating-SNAPSHOT" to "3.2" and tried to rebuild, but got the
> following:
>
> Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/
> serviceengines/3.2/serviceengines-3.2.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/
> parent/3.2/parent-3.2.pom
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Failed to resolve artifact.
>
> GroupId: org.apache.servicemix
> ArtifactId: parent
> Version: 3.2
>
> Reason: Unable to download the artifact from any repository
>
>   org.apache.servicemix:parent:pom:3.2
>
> from the specified remote repositories:
>   central (http://repo1.maven.org/maven2)
>
>
> [INFO]
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> 
> [INFO] Total time: 1 minute 58 seconds
> [INFO] Finished at: Thu Nov 08 08:12:31 EST 2007
> [INFO] Final Memory: 4M/8M
> [INFO]
> 
>
> I dumped by .m2/repository/ but same result.
>
> What am I doing wrong?
>
> Thanks!
>
>
> On Nov 7, 2007, at 8:43 PM, Freeman Fang wrote:
>
> > The Apache ServiceMix team is proud to announce the availability of
> > the 3.2 release!
> >
> > Apache ServiceMix is a TLP (Top Level Project under Apache), which
> > is an open source distributed Enterprise
> > Service Bus (ESB)
> > and SOA toolkit built from the ground up on the semantics and APIs
> > of the Java
> > Business Integration (JBI) specification JSR 208 and released under
> > the Apache
> > 2.0 license.
> >
> > Apache ServiceMix is lightweight and easily embeddable, has
> > integrated Spring
> > support and can be run at the edge of the network (inside a client
> > or server),
> > as a standalone ESB provider or as a service within another ESB.
> > You can use ServiceMix in Java SE or a Java EE application server.
> >
> > This release includes a number of important fixes and a few
> > enhancements.
> > For more information see:
> > * Website: http://servicemix.apache.org/
> > * Release Notes: http://servicemix.apache.org/servicemix-32.html
> > * Mailing lists: http://servicemix.apache.org/mailing-lists.html
> >
> > If you have feedback, questions or would like to get involved in the
> > ServiceMix project please join the mailing lists and let us know your
> > thoughts.
> >
> >
> > The Apache ServiceMix Team
> > http://servicemix.apache.org/team.html
> >
>
>
> --
> Daryl
> http://itsallsemantics.com
>
> "Hell, there are no rules here-- we're trying to accomplish something."
> -- Thomas A. Edison
>
>
>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
>

[jira] Updated: (GSHELL-38) Add rfile:// remote-file support to allow rsh clients to access files from the local machine

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon updated GSHELL-38:
---

Fix Version/s: 1.0-alpha-2

> Add rfile:// remote-file support to allow rsh clients to access files from 
> the local machine
> 
>
> Key: GSHELL-38
> URL: https://issues.apache.org/jira/browse/GSHELL-38
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Remote Shell, Whisper
>Affects Versions: 1.0-alpha-1
>Reporter: Jason Dillon
> Fix For: 1.0-alpha-2
>
>
> Need to provide a _simple_ way for files on a local machine (one where an rsh 
> originates from) on the remote machine (where the rshd is accepting 
> connections).
> Probably want to implement a URLConnection handler, perhaps using VFS too, so 
> provide even richer remote file access to commands via URLs.
> Skeleton classes for the URL muck and Whisper protocol messages are here:
>  * 
> https://svn.apache.org/repos/asf/geronimo/gshell/trunk/gshell-whisper/src/main/java/org/apache/geronimo/gshell/whisper/rfile

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GSHELL-38) Add rfile:// remote-file support to allow rsh clients to access files from the local machine

[Jason Dillon (JIRA)]

[ 
https://issues.apache.org/jira/browse/GSHELL-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541160
 ] 

Jason Dillon commented on GSHELL-38:


ie.

{noformat}
echo "hi" > /tmp/foo.txt
gsh rsh ssl://remote:
...
 GShell (1.0-alpha-1-SNAPSHOT)

Type 'help' for more information.

[EMAIL PROTECTED]:/> cat rfile:/tmp/foo.txt
hi
[EMAIL PROTECTED]:/> exit
{noformat}

> Add rfile:// remote-file support to allow rsh clients to access files from 
> the local machine
> 
>
> Key: GSHELL-38
> URL: https://issues.apache.org/jira/browse/GSHELL-38
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Remote Shell, Whisper
>Affects Versions: 1.0-alpha-1
>Reporter: Jason Dillon
>
> Need to provide a _simple_ way for files on a local machine (one where an rsh 
> originates from) on the remote machine (where the rshd is accepting 
> connections).
> Probably want to implement a URLConnection handler, perhaps using VFS too, so 
> provide even richer remote file access to commands via URLs.
> Skeleton classes for the URL muck and Whisper protocol messages are here:
>  * 
> https://svn.apache.org/repos/asf/geronimo/gshell/trunk/gshell-whisper/src/main/java/org/apache/geronimo/gshell/whisper/rfile

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GSHELL-38) Add rfile:// remote-file support to allow rsh clients to access files from the local machine

[Jason Dillon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Dillon reassigned GSHELL-38:
--

Assignee: (was: Jason Dillon)

> Add rfile:// remote-file support to allow rsh clients to access files from 
> the local machine
> 
>
> Key: GSHELL-38
> URL: https://issues.apache.org/jira/browse/GSHELL-38
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Remote Shell, Whisper
>Affects Versions: 1.0-alpha-1
>Reporter: Jason Dillon
>
> Need to provide a _simple_ way for files on a local machine (one where an rsh 
> originates from) on the remote machine (where the rshd is accepting 
> connections).
> Probably want to implement a URLConnection handler, perhaps using VFS too, so 
> provide even richer remote file access to commands via URLs.
> Skeleton classes for the URL muck and Whisper protocol messages are here:
>  * 
> https://svn.apache.org/repos/asf/geronimo/gshell/trunk/gshell-whisper/src/main/java/org/apache/geronimo/gshell/whisper/rfile

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GSHELL-38) Add rfile:// remote-file support to allow rsh clients to access files from the local machine

[Jason Dillon (JIRA)]

Add rfile:// remote-file support to allow rsh clients to access files from the 
local machine


 Key: GSHELL-38
 URL: https://issues.apache.org/jira/browse/GSHELL-38
 Project: GShell
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: Remote Shell, Whisper
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Dillon


Need to provide a _simple_ way for files on a local machine (one where an rsh 
originates from) on the remote machine (where the rshd is accepting 
connections).

Probably want to implement a URLConnection handler, perhaps using VFS too, so 
provide even richer remote file access to commands via URLs.

Skeleton classes for the URL muck and Whisper protocol messages are here:

 * 
https://svn.apache.org/repos/asf/geronimo/gshell/trunk/gshell-whisper/src/main/java/org/apache/geronimo/gshell/whisper/rfile

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GSHELL-20) `set foo="bar"` does not work as expected

[Jason Dillon (JIRA)]

[ 
https://issues.apache.org/jira/browse/GSHELL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541149
 ] 

Jason Dillon commented on GSHELL-20:


This is probably going to require some changes to the grammar to parse things 
correctly.

> `set foo="bar"` does not work as expected
> -
>
> Key: GSHELL-20
> URL: https://issues.apache.org/jira/browse/GSHELL-20
> Project: GShell
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Commands, Core
>Affects Versions: 0.0.1
>Reporter: Jason Dillon
>Assignee: Jason Warner
>Priority: Critical
> Fix For: 1.0-alpha-1
>
>
> Due to the way parsing happens, this line:
> {noformat}
> set foo="bar"
> {noformat}
> Ends up calling the command with 2 arguments: "foo=" and "bar", which is not 
> what the command expects, which is one argument of: "foo=bar"

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[BUILD] 2.1: Failed for Revision: 593051

[prasad]

OpenEJB trunk at 593255
Geronimo Revision: 593285 built with tests included
 
See the full build-1500.log file at 
http://people.apache.org/~prasad/binaries/trunk/20071108/build-1500.log
 
 T E S T S
---
Running org.apache.geronimo.deployment.service.ServiceConfigBuilderTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec
Running org.apache.geronimo.deployment.service.EnvironmentBuilderTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec

Results :

Tests run: 5, Failures: 0, Errors: 0, Skipped: 0

[INFO] [jar:jar]
[INFO] Building jar: 
/home/prasad/geronimo/trunk/framework/modules/geronimo-service-builder/target/geronimo-service-builder-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-service-builder-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing 
/home/prasad/geronimo/trunk/framework/modules/geronimo-service-builder/target/geronimo-service-builder-2.1-SNAPSHOT.jar
 to 
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-service-builder/2.1-SNAPSHOT/geronimo-service-builder-2.1-SNAPSHOT.jar
[INFO] 

[INFO] Building Geronimo Modules :: Deploy :: CLI Tool
[INFO]task-segment: [install]
[INFO] 

[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: 
/home/prasad/geronimo/trunk/framework/modules/geronimo-deploy-tool/target/classes/META-INF
[INFO] Copying 2 files to 
/home/prasad/geronimo/trunk/framework/modules/geronimo-deploy-tool/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 22 source files to 
/home/prasad/geronimo/trunk/framework/modules/geronimo-deploy-tool/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar: 
/home/prasad/geronimo/trunk/framework/modules/geronimo-deploy-tool/target/geronimo-deploy-tool-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-deploy-tool-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing 
/home/prasad/geronimo/trunk/framework/modules/geronimo-deploy-tool/target/geronimo-deploy-tool-2.1-SNAPSHOT.jar
 to 
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-deploy-tool/2.1-SNAPSHOT/geronimo-deploy-tool-2.1-SNAPSHOT.jar
[INFO] 

[INFO] Building Geronimo Maven2 Plugins
[INFO]task-segment: [install]
[INFO] 

Downloading: 
http://download.java.net/maven/1//org.apache.maven/jars/maven-profile-2.0.4.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/maven/maven-profile/2.0.4/maven-profile-2.0.4.jar
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/maven-profile/2.0.4/maven-profile-2.0.4.jar
29K downloaded
Downloading: 
http://download.java.net/maven/1//org.apache.maven/jars/maven-repository-metadata-2.0.4.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/maven/maven-repository-metadata/2.0.4/maven-repository-metadata-2.0.4.jar
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/maven-repository-metadata/2.0.4/maven-repository-metadata-2.0.4.jar
19K downloaded
Downloading: 
http://download.java.net/maven/1//org.apache.maven/jars/maven-artifact-2.0.4.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/maven/maven-artifact/2.0.4/maven-artifact-2.0.4.jar
Downloading: 
http://repository.codehaus.org/org/apache/maven/maven-artifact/2.0.4/maven-artifact-2.0.4.jar
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/maven-artifact/2.0.4/maven-artifact-2.0.4.jar
78K downloaded
Downloading: 
http://download.java.net/maven/1//org.apache.maven/jars/maven-plugin-api-2.0.4.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/maven/maven-plugin-api/2.0.4/maven-plugin-api-2.0.4.jar
Downloading: 
http://repository.codehaus.org/org/apache/maven/maven-plugin-api/2.0.4/maven-plugin-api-2.0.4.jar
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/maven-plugin-api/2.0.4/maven-plugin-api-2.0.4.jar
8K downloaded
Downloading: 
http://download.java.net/maven/1//org.apache.maven/jars/maven-model-2.0.4.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/maven/maven-model/2.0.4/maven-model-2.0.4.jar
Downloading

[BUILD] 2.1: Failed for Revision: 593285

[prasad]

OpenEJB trunk at 593255
Geronimo Revision: 593285 built with tests included
 
See the full build-1500.log file at 
http://people.apache.org/~prasad/binaries/trunk/20071108/build-1500.log
 
 T E S T S
---
Running org.apache.geronimo.deployment.service.ServiceConfigBuilderTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec
Running org.apache.geronimo.deployment.service.EnvironmentBuilderTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec

Results :

Tests run: 5, Failures: 0, Errors: 0, Skipped: 0

[INFO] [jar:jar]
[INFO] Building jar: 
/home/prasad/geronimo/trunk/framework/modules/geronimo-service-builder/target/geronimo-service-builder-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-service-builder-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing 
/home/prasad/geronimo/trunk/framework/modules/geronimo-service-builder/target/geronimo-service-builder-2.1-SNAPSHOT.jar
 to 
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-service-builder/2.1-SNAPSHOT/geronimo-service-builder-2.1-SNAPSHOT.jar
[INFO] 

[INFO] Building Geronimo Modules :: Deploy :: CLI Tool
[INFO]task-segment: [install]
[INFO] 

[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: 
/home/prasad/geronimo/trunk/framework/modules/geronimo-deploy-tool/target/classes/META-INF
[INFO] Copying 2 files to 
/home/prasad/geronimo/trunk/framework/modules/geronimo-deploy-tool/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 22 source files to 
/home/prasad/geronimo/trunk/framework/modules/geronimo-deploy-tool/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar: 
/home/prasad/geronimo/trunk/framework/modules/geronimo-deploy-tool/target/geronimo-deploy-tool-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-deploy-tool-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing 
/home/prasad/geronimo/trunk/framework/modules/geronimo-deploy-tool/target/geronimo-deploy-tool-2.1-SNAPSHOT.jar
 to 
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-deploy-tool/2.1-SNAPSHOT/geronimo-deploy-tool-2.1-SNAPSHOT.jar
[INFO] 

[INFO] Building Geronimo Maven2 Plugins
[INFO]task-segment: [install]
[INFO] 

Downloading: 
http://download.java.net/maven/1//org.apache.maven/jars/maven-profile-2.0.4.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/maven/maven-profile/2.0.4/maven-profile-2.0.4.jar
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/maven-profile/2.0.4/maven-profile-2.0.4.jar
29K downloaded
Downloading: 
http://download.java.net/maven/1//org.apache.maven/jars/maven-repository-metadata-2.0.4.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/maven/maven-repository-metadata/2.0.4/maven-repository-metadata-2.0.4.jar
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/maven-repository-metadata/2.0.4/maven-repository-metadata-2.0.4.jar
19K downloaded
Downloading: 
http://download.java.net/maven/1//org.apache.maven/jars/maven-artifact-2.0.4.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/maven/maven-artifact/2.0.4/maven-artifact-2.0.4.jar
Downloading: 
http://repository.codehaus.org/org/apache/maven/maven-artifact/2.0.4/maven-artifact-2.0.4.jar
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/maven-artifact/2.0.4/maven-artifact-2.0.4.jar
78K downloaded
Downloading: 
http://download.java.net/maven/1//org.apache.maven/jars/maven-plugin-api-2.0.4.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/maven/maven-plugin-api/2.0.4/maven-plugin-api-2.0.4.jar
Downloading: 
http://repository.codehaus.org/org/apache/maven/maven-plugin-api/2.0.4/maven-plugin-api-2.0.4.jar
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/maven-plugin-api/2.0.4/maven-plugin-api-2.0.4.jar
8K downloaded
Downloading: 
http://download.java.net/maven/1//org.apache.maven/jars/maven-model-2.0.4.jar
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/maven/maven-model/2.0.4/maven-model-2.0.4.jar
Downloading

Re: [DISCUSS] 2.1 Release

[Hernan Cunico]

Hey y'all,
I started to map some of the new features/functions to the 2.1 documentation.

I just created a new wiki space http://cwiki.apache.org/GMOxDOC21
and created some initial entries. Pls chime in with your ideas for topics to 
cover but don't stop just there,
feel free to start working out some content too if you feel compelled to do so 
;-)

Help with the documentation is GREATLY APPRECIATED!!!

I will be starting a separate thread on user@ for user feedback as well.

Cheers!
Hernan

Hernan Cunico wrote:

Agreed, we seem to have enough new stuff to call for a release.

Here is a list trying to consolidate these new functions/improvements

- GShell
- Console enhancements (dep plan generation, grouping/collapsing?)
- Monitoring
- Plugin infrastructure
- Pluggable console
- Security
- Configuration (config.xml, config-subst, etc)
- Deployment plans
- Tooling
- ...?

We will also need a whole new set of documentation to cover these in 
GMOxDOC21.
Anybody in desperate need for contributing docs for these features? ;-) 
it will be very much appreciated.


Cheers!
Hernan

Kevan Miller wrote:

I think it's time to start discussing the particulars of a 2.1 release.

There's been a lot of advancements made in our plugin infrastructure. 
There's also been the pluggable console enhancements. It would be good 
to get a release out, with these capabilities. They provide a more 
solid platform for future enhancements, I think.


There's also GShell and new monitoring capabilities. I'm probably 
missing a few other new functions.


Finally, IIUC, 2.1 would be able to support a Terracotta plugin. I'd 
also be very interested to hear what WADI capabilities that could be 
exposed.


I'm willing to bang the release manager drum. I see that Joe has 
already started tugging on the TCK chain


What do others think? How close are we to a 2.1 release? What 
additional capabilities and bug fixes are needed? Can we wrap up 
development activities in the next week or two?


--kevan

[jira] Commented: (GERONIMO-3502) Module conditions when installed as a plugin

[Jarek Gawor (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541132
 ] 

Jarek Gawor commented on GERONIMO-3502:
---

Thanks David. I looked into the config-substitution idea. 

I added JAXWSProvider=axs2 or JAXWSProvider=cxf in 
config-substitutions.properties file and changed the axis2/cxf module 
conditions to

props.getProperty('org.apache.geronimo.jaxws.provider', 
subst.get('JAXWSProvider')) == 'axis2' 
and
props.getProperty('org.apache.geronimo.jaxws.provider', 
subst.get('JAXWSProvider')) == 'cxf'

I also had to modify the code slightly to expose the config substitution 
properties to the condition evaluator to make this work. And also, the 
jetty6/tomcat6 plans need to change to add in the appropriate JAXWSProvider 
property. 

Does this looks/sounds ok to you?


> Module conditions when installed as a plugin
> 
>
> Key: GERONIMO-3502
> URL: https://issues.apache.org/jira/browse/GERONIMO-3502
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.1
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
>
> Currently, I don't think there is a way to specify module conditions in the 
> geronimo-plugin.xml. That creates problem in certain situations where two 
> modules can be installed at the same time but only one can be running at a 
> time. For example, as in case of Axis2 and CXF. Before, the assembly's 
> config.xml file specified the appropriate module conditions which prevented 
> the two modules from running at the same time. Right now, the deployment of 
> applications will fail if both both Axis2 and CXF modules are running at the 
> same time.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Geronimo IRC logs

[Kevan Miller]

On Nov 8, 2007 8:55 AM, Anita Kulshreshtha <[EMAIL PROTECTED]> wrote:

>   Does anyone know why IRC is not being logged?
>

I think this should be fixed, now... Somebody needs to start an IRC
conversation, before we know for sure... ;-)

--kevan

[jira] Closed: (GERONIMO-3593) URLName getFile() processing not consistent with reference version.

[Rick McGuire (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick McGuire closed GERONIMO-3593.
--

Resolution: Fixed

Committed revision 593290.

> URLName getFile() processing not consistent with reference version.
> ---
>
> Key: GERONIMO-3593
> URL: https://issues.apache.org/jira/browse/GERONIMO-3593
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>Reporter: Rick McGuire
>Assignee: Rick McGuire
>
> The URLName handling of getFile() is not consistent with the Sun reference 
> implementation.  For example, 
> url = new URLName("http://www.apache.org/file/file1#ref";); 
> System.out.println("> URLNAME: " + url); 
> System.out.println("> URLNAME file: " + url.getFile()); 
> will display "/file/file1" with the Geronimo version and "file/file1" with 
> the Sun version. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3593) URLName getFile() processing not consistent with reference version.

[Rick McGuire (JIRA)]

URLName getFile() processing not consistent with reference version.
---

 Key: GERONIMO-3593
 URL: https://issues.apache.org/jira/browse/GERONIMO-3593
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: mail
Reporter: Rick McGuire
Assignee: Rick McGuire


The URLName handling of getFile() is not consistent with the Sun reference 
implementation.  For example, 

url = new URLName("http://www.apache.org/file/file1#ref";); 
System.out.println("> URLNAME: " + url); 
System.out.println("> URLNAME file: " + url.getFile()); 

will display "/file/file1" with the Geronimo version and "file/file1" with the 
Sun version. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3592) javamail Service.toString() method should not include password information.

[Rick McGuire (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick McGuire closed GERONIMO-3592.
--

Resolution: Fixed

Committed revision 593268.

> javamail Service.toString() method should not include password information.
> ---
>
> Key: GERONIMO-3592
> URL: https://issues.apache.org/jira/browse/GERONIMO-3592
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>Reporter: Rick McGuire
>Assignee: Rick McGuire
>Priority: Minor
>
> The javax.mail.Service.toString() method displays the Service URLName, if it 
> has one.  The Sun version removes the password information from the URL, but 
> the Geronimo version does not. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3592) javamail Service.toString() method should not include password information.

[Rick McGuire (JIRA)]

javamail Service.toString() method should not include password information.
---

 Key: GERONIMO-3592
 URL: https://issues.apache.org/jira/browse/GERONIMO-3592
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: mail
Reporter: Rick McGuire
Assignee: Rick McGuire
Priority: Minor


The javax.mail.Service.toString() method displays the Service URLName, if it 
has one.  The Sun version removes the password information from the URL, but 
the Geronimo version does not. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3591) javamail URLName() class does not HTTP encode URL username elements

[Rick McGuire (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick McGuire closed GERONIMO-3591.
--

Resolution: Fixed

Committed revision 593244.

> javamail URLName() class does not HTTP encode URL username elements
> ---
>
> Key: GERONIMO-3591
> URL: https://issues.apache.org/jira/browse/GERONIMO-3591
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Rick McGuire
>Assignee: Rick McGuire
>
> The URLName class needs to apply HTTP encoding rules to the username and 
> password elements of the URLName.  For example, a username of "[EMAIL 
> PROTECTED]" should show up as "john%40gmail.com" in the string version of the 
> URLName. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3591) javamail URLName() class does not HTTP encode URL username elements

[Rick McGuire (JIRA)]

javamail URLName() class does not HTTP encode URL username elements
---

 Key: GERONIMO-3591
 URL: https://issues.apache.org/jira/browse/GERONIMO-3591
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Reporter: Rick McGuire
Assignee: Rick McGuire


The URLName class needs to apply HTTP encoding rules to the username and 
password elements of the URLName.  For example, a username of "[EMAIL 
PROTECTED]" should show up as "john%40gmail.com" in the string version of the 
URLName. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Geronimo Project Management

[Kevan Miller]

On Nov 7, 2007 6:47 PM, khaldi hinda <[EMAIL PROTECTED]> wrote:

> Hi,
>  I have to represent the Project " Apache Geronimo " during a lecture
> of  Software Project Management.
>  It is possible to send me the "Geronimo Project Management" Documents
> (more  precisely : aim of the architecture, all about the stepps of
> development,  development constraints, logical context, development
> environment)
>
Hinda,
http://cwiki.apache.org/GMOxDEV/index.html contains some general
documentation of geronimo.

I realize that this isn't in a form that is very useful for your purposes,
but everything else is in our dev lists which can be browsed here --
http://mail-archives.apache.org/mod_mbox/geronimo-dev/ or here --
http://www.nabble.com/Apache-Geronimo---Dev-f136.html

--kevan

Re: Geronimo IRC logs

[Kevan Miller]

On Nov 8, 2007 8:55 AM, Anita Kulshreshtha <[EMAIL PROTECTED]> wrote:

>   Does anyone know why IRC is not being logged?
>

Don't know why, but I've pinged the contact we've used in the past at
uwyn.com. Hopefully we can get it restarted...

--kevan

Re: Can we deal generically with container specific jsr77 statistics?

[Paul McMahan]

I hadn't really thought about footprint issues, but that's a good point.

Put another way, my concern is:
Can a component's management interface be modified without also  
replacing g-mangement?



Best wishes,
Paul

On Nov 8, 2007, at 11:56 AM, Anita Kulshreshtha wrote:


--- Paul McMahan <[EMAIL PROTECTED]> wrote:


While I think that technically Anita is correct this approach
produces some practical challenges.
If all the *StatsImpl classes for all components in the server are
gathered in g-management then how can the *StatsImpl classes be
upgraded, modified, or replaced without also replacing g-
management?


Paul,
We are talking about few classes (e.g. 3 each for tomcat/Jetty)  
per

component not few jars. I do not think it is worth having separate
g-management for each assembly. Especially when we still ship all  
specs

_jars_ in the smallest assembly.
   I hope this answers your concerns..
Thanks
Anita

 The g-management module would become a major source of


contention as various components fix and improve their management
interfaces (and we hope they do).


  And since g-management is part of


the core framework I think replacing it would require recycling the
server (not verified).

Let's weigh this out against the overhead of maintaining separate
configs for each of the various assembly configurations, which is
certainly no trivial matter.


Best wishes,
Paul

On Nov 8, 2007, at 10:10 AM, Anita Kulshreshtha wrote:



--- "Erik B. Craig" <[EMAIL PROTECTED]> wrote:

 say, openEJB or somesuch

would also
reside here rather than within our openEJB package? If so, how

would

this
all play into the pluggable server/framework design?


Since these classes ONLY depend on management classes and not

on

openEJB or somesuch, it does not affect the pluggable

server/framework

design. I do not think we are planning to strip down classes from
g-management to cater to pluggable framework and add classes as we
upgrade to a higher assembly.

Thanks
Anita


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com






__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Re: Can we deal generically with container specific jsr77 statistics?

[Anita Kulshreshtha]

--- Paul McMahan <[EMAIL PROTECTED]> wrote:

> While I think that technically Anita is correct this approach  
> produces some practical challenges.
> If all the *StatsImpl classes for all components in the server are  
> gathered in g-management then how can the *StatsImpl classes be  
> upgraded, modified, or replaced without also replacing g- 
> management?
 
Paul,
We are talking about few classes (e.g. 3 each for tomcat/Jetty) per
component not few jars. I do not think it is worth having separate
g-management for each assembly. Especially when we still ship all specs
_jars_ in the smallest assembly.
   I hope this answers your concerns..
Thanks
Anita

 The g-management module would become a major source of 
> 
> contention as various components fix and improve their management  
> interfaces (and we hope they do). 

  And since g-management is part of
>  
> the core framework I think replacing it would require recycling the  
> server (not verified).
> 
> Let's weigh this out against the overhead of maintaining separate  
> configs for each of the various assembly configurations, which is  
> certainly no trivial matter.
> 
> 
> Best wishes,
> Paul
> 
> On Nov 8, 2007, at 10:10 AM, Anita Kulshreshtha wrote:
> 
> >
> > --- "Erik B. Craig" <[EMAIL PROTECTED]> wrote:
> >
> >  say, openEJB or somesuch
> >> would also
> >> reside here rather than within our openEJB package? If so, how
> would
> >> this
> >> all play into the pluggable server/framework design?
> >>
> > Since these classes ONLY depend on management classes and not
> on
> > openEJB or somesuch, it does not affect the pluggable
> server/framework
> > design. I do not think we are planning to strip down classes from
> > g-management to cater to pluggable framework and add classes as we
> > upgrade to a higher assembly.
> >
> > Thanks
> > Anita
> >
> >
> > __
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Can we deal generically with container specific jsr77 statistics?

[David Jencks]

On Nov 8, 2007, at 8:33 AM, David Jencks wrote:



On Nov 8, 2007, at 7:10 AM, Anita Kulshreshtha wrote:



--- "Erik B. Craig" <[EMAIL PROTECTED]> wrote:

 say, openEJB or somesuch

would also
reside here rather than within our openEJB package? If so, how would
this
all play into the pluggable server/framework design?


Since these classes ONLY depend on management classes and not on
openEJB or somesuch, it does not affect the pluggable server/ 
framework

design. I do not think we are planning to strip down classes from
g-management to cater to pluggable framework and add classes as we
upgrade to a higher assembly.


I agree with you that it is possible to include the Jetty/Tomcat  
Stats classes in g-management without pulling in any jetty or  
tomcat classes, and similarly all the named geronimo specific stats  
classes don't require classes from the components they are for.   
Similarly I think its pretty clear my proposal will work and  
clients can get the StatsImpl objects and deal with them by finding  
out what they support.


I'm wondering if it is a good idea to expose classes that turn the  
set of Statistics exposed by some particular geronimo component  
into a type, or if it is a better idea for clients to use the  
generic interface.  IIRC when we introduced these classes they  
seemed like a good idea but I'm wondering if they have any real  
use.  AFAICT the classes names w/jetty/tomcat aren't used anywhere  
outside the jetty/tomcat modules which makes me think that we  
should consider removing all of the non-generic types from g- 
management, starting with the Tomcat ones and continuing as time  
allows.


So to me this is pretty much a philosophical question.  I'm leaning  
towards only exposing generic classes.  What do others think?  Why  
is it a good idea to have the non-generic classes?


talking with pmcmahon I think there are 3 choices let me try to  
make them more explicit.


1. Only generic interfaces in g-management, and we pretty much insist  
that clients use the generic interfaces only.  If they want something  
else its up to them to figure out how to find it, and it might not  
exist.


2. Only generic interfaces in g-management, specific interfaces in  
the component modules (such as jetty/tomcat) and we expect clients to  
use the specific interfaces, thus they will need to import the  
component modules to get the interfaces


3. Specific interfaces in g-management, and we expect clients to use  
the specific interfaces.


Hope this clarifies what we are talking about.

david jencks



thanks
david jencks


Thanks
Anita


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Re: Can we deal generically with container specific jsr77 statistics?

[David Jencks]

On Nov 8, 2007, at 7:10 AM, Anita Kulshreshtha wrote:



--- "Erik B. Craig" <[EMAIL PROTECTED]> wrote:

 say, openEJB or somesuch

would also
reside here rather than within our openEJB package? If so, how would
this
all play into the pluggable server/framework design?


Since these classes ONLY depend on management classes and not on
openEJB or somesuch, it does not affect the pluggable server/framework
design. I do not think we are planning to strip down classes from
g-management to cater to pluggable framework and add classes as we
upgrade to a higher assembly.


I agree with you that it is possible to include the Jetty/Tomcat  
Stats classes in g-management without pulling in any jetty or tomcat  
classes, and similarly all the named geronimo specific stats classes  
don't require classes from the components they are for.  Similarly I  
think its pretty clear my proposal will work and clients can get the  
StatsImpl objects and deal with them by finding out what they support.


I'm wondering if it is a good idea to expose classes that turn the  
set of Statistics exposed by some particular geronimo component into  
a type, or if it is a better idea for clients to use the generic  
interface.  IIRC when we introduced these classes they seemed like a  
good idea but I'm wondering if they have any real use.  AFAICT the  
classes names w/jetty/tomcat aren't used anywhere outside the jetty/ 
tomcat modules which makes me think that we should consider removing  
all of the non-generic types from g-management, starting with the  
Tomcat ones and continuing as time allows.


So to me this is pretty much a philosophical question.  I'm leaning  
towards only exposing generic classes.  What do others think?  Why is  
it a good idea to have the non-generic classes?


thanks
david jencks


Thanks
Anita


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Re: Can we deal generically with container specific jsr77 statistics?

[Paul McMahan]

While I think that technically Anita is correct this approach  
produces some practical challenges.
If all the *StatsImpl classes for all components in the server are  
gathered in g-management then how can the *StatsImpl classes be  
upgraded, modified, or replaced without also replacing g- 
management?   The g-management module would become a major source of  
contention as various components fix and improve their management  
interfaces (and we hope they do).   And since g-management is part of  
the core framework I think replacing it would require recycling the  
server (not verified).


Let's weigh this out against the overhead of maintaining separate  
configs for each of the various assembly configurations, which is  
certainly no trivial matter.



Best wishes,
Paul

On Nov 8, 2007, at 10:10 AM, Anita Kulshreshtha wrote:



--- "Erik B. Craig" <[EMAIL PROTECTED]> wrote:

 say, openEJB or somesuch

would also
reside here rather than within our openEJB package? If so, how would
this
all play into the pluggable server/framework design?


Since these classes ONLY depend on management classes and not on
openEJB or somesuch, it does not affect the pluggable server/framework
design. I do not think we are planning to strip down classes from
g-management to cater to pluggable framework and add classes as we
upgrade to a higher assembly.

Thanks
Anita


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[BUILD] 2.1: Failed for Revision: 593158

[prasad]

OpenEJB trunk at 593146
Geronimo Revision: 593158 built with tests included
 
See the full build-0900.log file at 
http://people.apache.org/~prasad/binaries/trunk/20071108/build-0900.log
 
Download the binaries from 
http://people.apache.org/~prasad/binaries/trunk/20071108
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 29 minutes 35 seconds
[INFO] Finished at: Thu Nov 08 09:33:02 EST 2007
[INFO] Final Memory: 279M/993M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/~prasad/testsuite/ResultsSummary.html
See the full test.log file at 
http://people.apache.org/~prasad/binaries/trunk/20071108/logs-0900/test.log
 
[INFO] Running console-testsuite.basic-console
[INFO] Tests run: 110, Failures: 3, Errors: 0, Skipped: 107, Time elapsed: 
0.832 sec <<< FAILURE!
[INFO] Running console-testsuite.advance-test
[INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 3.369 
sec <<< FAILURE!
--
[INFO] Running enterprise-testsuite.ejbtests
[INFO] Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 0.132 
sec <<< FAILURE!
 

Re: Can we deal generically with container specific jsr77 statistics?

[Anita Kulshreshtha]

--- "Erik B. Craig" <[EMAIL PROTECTED]> wrote:

 say, openEJB or somesuch
> would also
> reside here rather than within our openEJB package? If so, how would
> this
> all play into the pluggable server/framework design?
> 
Since these classes ONLY depend on management classes and not on
openEJB or somesuch, it does not affect the pluggable server/framework
design. I do not think we are planning to strip down classes from
g-management to cater to pluggable framework and add classes as we
upgrade to a higher assembly.

Thanks
Anita


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Can we deal generically with container specific jsr77 statistics?

[Anita Kulshreshtha]

   We do not control what openEJB or somesuch ship with. We need to
make all StatsImpl available via g-management.

Thanks
Anita
 
--- "Erik B. Craig" <[EMAIL PROTECTED]> wrote:

> At the risk of getting caught in the crossfire here...
> 
> So, lets say the classes for jetty or tomcat that extend those in
> o/a/g/management/geronimo/stats reside within same package... are we
> then
> saying that classes extending those for, say, openEJB or somesuch
> would also
> reside here rather than within our openEJB package? If so, how would
> this
> all play into the pluggable server/framework design?
> 
> 
> -Erik
> 
> On Nov 8, 2007 9:31 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:
> 
> >
> >
> > Anita Kulshreshtha wrote:
> > > David,
> > > Please see
> > >
> https://issues.apache.org/jira/browse/GERONIMO-3586#action_12540957
> > > To summarize, the question is whether Tomcat*Stats (and
> > > Tomcat*StatsImpl) is a management interface or a tomcat
> interface. To
> > > me, if it imports only management classes, it is a management
> interface
> > > and its implementation which also imports ONLY management classes
> > > belongs in g-management.
> > > Given that all management interfaces and their 33
> implementations
> > > are in g-management,
> >
> > Just to clarify the structure and the history:
> >
> > The standard Stats from the the JSR77 spec are in
> o/a/g/management/stats
> >
> > The "generic" Geronimo Stats which are extensions to the spec are
> in
> > o/a/g/management/geronimo/stats
> >
> > Until recently, the o/a/g/management/geronimo/stats package only
> > included generic stats classes (meaning they were not supposed to
> be
> > specific to the implementation of the component such as Jetty or
> > Tomcat).  Jetty specific classes which extended these generic
> classes
> > were in o/a/g/jetty and the intention was that tomcat specific
> classes
> > would be included in tomcat.
> >
> > Joe
> >
> >
> 
> 
> -- 
> Erik B. Craig
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Can we deal generically with container specific jsr77 statistics?

[Anita Kulshreshtha]

--- Joe Bohn <[EMAIL PROTECTED]> wrote:

> 
> 
> Anita Kulshreshtha wrote:
> > David,
> > Please see
> > https://issues.apache.org/jira/browse/GERONIMO-3586#action_12540957
> > To summarize, the question is whether Tomcat*Stats (and
> > Tomcat*StatsImpl) is a management interface or a tomcat interface.
> To
> > me, if it imports only management classes, it is a management
> interface
> > and its implementation which also imports ONLY management classes
> > belongs in g-management. 
> > Given that all management interfaces and their 33
> implementations
> > are in g-management, 

I stand corrected, 30 implementations.

Thanks
Anita

> 
> Just to clarify the structure and the history:
> 
> The standard Stats from the the JSR77 spec are in
> o/a/g/management/stats
> 
> The "generic" Geronimo Stats which are extensions to the spec are in 
> o/a/g/management/geronimo/stats
> 
> Until recently, the o/a/g/management/geronimo/stats package only 
> included generic stats classes (meaning they were not supposed to be 
> specific to the implementation of the component such as Jetty or 
> Tomcat).  Jetty specific classes which extended these generic classes
> 
> were in o/a/g/jetty and the intention was that tomcat specific
> classes 
> would be included in tomcat.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [BUILD] 2.1: Failed for Revision: 592996

[Prasad Kashyap]

Hi Jacek,

The testsuite runs only after a successful build. So yes, the build
here too has had no failures.

To run the testsuite-
cd ${geronimo}/testsuite
mvn [-DassemblyId=tomcat] [-DinstallDirectory=c:\apache]

The -DinstallDirectory option is useful on a windows machine to
circumvent the long path problem. Without this, it will install the
server in testsuite/${foo}-testsuite/target dir.

Cheers
Prasad

On 11/8/07, Jacek Laskowski <[EMAIL PROTECTED]> wrote:
> On 8 Nov 2007 03:21:12 -,  <[EMAIL PROTECTED]> wrote:
>
> > TESTSUITE RESULTS (Failures only)
> > =
> > See detailed results at 
> > http://people.apache.org/~prasad/testsuite/ResultsSummary.html
> > See the full test.log file at 
> > http://people.apache.org/~prasad/binaries/trunk/20071107/logs-2100/test.log
> >
> > [INFO] Running console-testsuite.basic-console
> > [INFO] Tests run: 110, Failures: 3, Errors: 0, Skipped: 107, Time elapsed: 
> > 0.872 sec <<< FAILURE!
> > [INFO] Running console-testsuite.advance-test
> > [INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 
> > 3.452 sec <<< FAILURE!
> > --
> > [INFO] Running enterprise-testsuite.ejbtests
> > [INFO] Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 
> > 0.125 sec <<< FAILURE!
>
> How can I run the tests on my computer? I could build geronimo fine
> yesterday with no failures.
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>

Re: Can we deal generically with container specific jsr77 statistics?

[Erik B. Craig]

At the risk of getting caught in the crossfire here...

So, lets say the classes for jetty or tomcat that extend those in
o/a/g/management/geronimo/stats reside within same package... are we then
saying that classes extending those for, say, openEJB or somesuch would also
reside here rather than within our openEJB package? If so, how would this
all play into the pluggable server/framework design?


-Erik

On Nov 8, 2007 9:31 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:

>
>
> Anita Kulshreshtha wrote:
> > David,
> > Please see
> > https://issues.apache.org/jira/browse/GERONIMO-3586#action_12540957
> > To summarize, the question is whether Tomcat*Stats (and
> > Tomcat*StatsImpl) is a management interface or a tomcat interface. To
> > me, if it imports only management classes, it is a management interface
> > and its implementation which also imports ONLY management classes
> > belongs in g-management.
> > Given that all management interfaces and their 33 implementations
> > are in g-management,
>
> Just to clarify the structure and the history:
>
> The standard Stats from the the JSR77 spec are in o/a/g/management/stats
>
> The "generic" Geronimo Stats which are extensions to the spec are in
> o/a/g/management/geronimo/stats
>
> Until recently, the o/a/g/management/geronimo/stats package only
> included generic stats classes (meaning they were not supposed to be
> specific to the implementation of the component such as Jetty or
> Tomcat).  Jetty specific classes which extended these generic classes
> were in o/a/g/jetty and the intention was that tomcat specific classes
> would be included in tomcat.
>
> Joe
>
>


-- 
Erik B. Craig

[jira] Assigned: (GSHELL-20) `set foo="bar"` does not work as expected

[Jason Warner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GSHELL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Warner reassigned GSHELL-20:
--

Assignee: Jason Warner

> `set foo="bar"` does not work as expected
> -
>
> Key: GSHELL-20
> URL: https://issues.apache.org/jira/browse/GSHELL-20
> Project: GShell
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Commands, Core
>Affects Versions: 0.0.1
>Reporter: Jason Dillon
>Assignee: Jason Warner
>Priority: Critical
> Fix For: 1.0-alpha-1
>
>
> Due to the way parsing happens, this line:
> {noformat}
> set foo="bar"
> {noformat}
> Ends up calling the command with 2 arguments: "foo=" and "bar", which is not 
> what the command expects, which is one argument of: "foo=bar"

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Can we deal generically with container specific jsr77 statistics?

[Joe Bohn]

Anita Kulshreshtha wrote:

David,
Please see
https://issues.apache.org/jira/browse/GERONIMO-3586#action_12540957
To summarize, the question is whether Tomcat*Stats (and
Tomcat*StatsImpl) is a management interface or a tomcat interface. To
me, if it imports only management classes, it is a management interface
and its implementation which also imports ONLY management classes
belongs in g-management. 
Given that all management interfaces and their 33 implementations
are in g-management, 


Just to clarify the structure and the history:

The standard Stats from the the JSR77 spec are in o/a/g/management/stats

The "generic" Geronimo Stats which are extensions to the spec are in 
o/a/g/management/geronimo/stats


Until recently, the o/a/g/management/geronimo/stats package only 
included generic stats classes (meaning they were not supposed to be 
specific to the implementation of the component such as Jetty or 
Tomcat).  Jetty specific classes which extended these generic classes 
were in o/a/g/jetty and the intention was that tomcat specific classes 
would be included in tomcat.


Joe

Geronimo IRC logs

[Anita Kulshreshtha]

   Does anyone know why IRC is not being logged?

Thanks
Anita

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Can we deal generically with container specific jsr77 statistics?

[Anita Kulshreshtha]

David,
Please see
https://issues.apache.org/jira/browse/GERONIMO-3586#action_12540957
To summarize, the question is whether Tomcat*Stats (and
Tomcat*StatsImpl) is a management interface or a tomcat interface. To
me, if it imports only management classes, it is a management interface
and its implementation which also imports ONLY management classes
belongs in g-management. 
Given that all management interfaces and their 33 implementations
are in g-management, I do not think it is worth the effort maintaining
duplicate classes just for Jetty. I suggest that we move Jetty*Stats
classes to g-management for now. If we start having 2 EJB
implementations, 2 Transaction managers or 2 JMS providers, then we
should implement the alternative suggested by you. 

More inline...
   
--- David Jencks <[EMAIL PROTECTED]> wrote:

> There's been some discussion on
> https://issues.apache.org/jira/browse/ 
> GERONIMO-3586 and https://issues.apache.org/jira/browse/GERONIMO-3587
>  
> about how to deal with the jetty and tomcat jsr77 statistics.  It  
... an idea to 
> 
> suggest that might keep the container specific code in the containers
>  
> and allow management code to avoid needing any container specific  
> classes.

These implementations DO NOT need any container specific classes. 
Until we come across one that needs one, we should put them in
g-management.

> 
.  IIUC the  
> problems start when you try to send e.g. a JettyWebConnectorStatsImpl
>  
> over the wire to a monitoring app, and the object can't be
> deserialized.

   Yes, and we must make sure that all StatsImpl (standard and geronimo
specific) are available via g-management to someone who might want to
write a stand alone client, use jconsole or any similar tool to get to
stats.

Thanks
Anita

 
> 
> I suggest we have in geronimo-management a StatsImpl class similar to
>  
> the existing one but taking the name-statistic map in its constructor
>  
> and being immutable.
> 
> Then the jetty/tomcat specific stats classes won't implement Stats at
>  
> all but just the container specific method.  Instead of extending  
> StatsImpl they will delegate to an instance they create in their  
> constructor.
> 
> The MEJB can return the delegate StatsImpl objects, thus avoiding any
>  
> need for any container specific classes, and the container specific  
> adapters can be in with the containers.
> 
> Comments?
> 
> thanks
> david jencks
> 
> 
> 
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [ANNOUNCE] Apache ServiceMix 3.2 released !

[Daryl Richter]

Ok.  So I changed the servicmix-version references in my project from  
"3.2-incubating-SNAPSHOT" to "3.2" and tried to rebuild, but got the  
following:


Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/ 
serviceengines/3.2/serviceengines-3.2.pom

1K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/servicemix/ 
parent/3.2/parent-3.2.pom
[INFO]  


[ERROR] BUILD ERROR
[INFO]  


[INFO] Failed to resolve artifact.

GroupId: org.apache.servicemix
ArtifactId: parent
Version: 3.2

Reason: Unable to download the artifact from any repository

  org.apache.servicemix:parent:pom:3.2

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)


[INFO]  


[INFO] For more information, run Maven with the -e switch
[INFO]  


[INFO] Total time: 1 minute 58 seconds
[INFO] Finished at: Thu Nov 08 08:12:31 EST 2007
[INFO] Final Memory: 4M/8M
[INFO]  



I dumped by .m2/repository/ but same result.

What am I doing wrong?

Thanks!


On Nov 7, 2007, at 8:43 PM, Freeman Fang wrote:


The Apache ServiceMix team is proud to announce the availability of
the 3.2 release!

Apache ServiceMix is a TLP (Top Level Project under Apache), which  
is an open source distributed Enterprise

Service Bus (ESB)
and SOA toolkit built from the ground up on the semantics and APIs  
of the Java
Business Integration (JBI) specification JSR 208 and released under  
the Apache

2.0 license.

Apache ServiceMix is lightweight and easily embeddable, has
integrated Spring
support and can be run at the edge of the network (inside a client  
or server),

as a standalone ESB provider or as a service within another ESB.
You can use ServiceMix in Java SE or a Java EE application server.

This release includes a number of important fixes and a few  
enhancements.

For more information see:
* Website: http://servicemix.apache.org/
* Release Notes: http://servicemix.apache.org/servicemix-32.html
* Mailing lists: http://servicemix.apache.org/mailing-lists.html

If you have feedback, questions or would like to get involved in the
ServiceMix project please join the mailing lists and let us know your
thoughts.


The Apache ServiceMix Team
http://servicemix.apache.org/team.html



--
Daryl
http://itsallsemantics.com

"Hell, there are no rules here-- we're trying to accomplish something."
-- Thomas A. Edison

[jira] Closed: (GERONIMO-3590) javamail TextHandler fails when content stream is ByteArrayInputStream.

[Rick McGuire (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick McGuire closed GERONIMO-3590.
--

Resolution: Fixed

Committed revision 593128.

> javamail TextHandler fails when content stream is ByteArrayInputStream.
> ---
>
> Key: GERONIMO-3590
> URL: https://issues.apache.org/jira/browse/GERONIMO-3590
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>Reporter: Rick McGuire
>Assignee: Rick McGuire
>
> The TextHandler included with the javamail spec code gets an I/O failure when 
> the contentStream() used to read the text is a ByteArrayInputStream.  The 
> read method for ByteArrayInputStream does not appear to return a -1 value for 
> an EOF (it returns 0), so the InputStreamReader wrappered around the stream 
> is throwing an exception on the first 0 return.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3590) javamail TextHandler fails when content stream is ByteArrayInputStream.

[Rick McGuire (JIRA)]

javamail TextHandler fails when content stream is ByteArrayInputStream.
---

 Key: GERONIMO-3590
 URL: https://issues.apache.org/jira/browse/GERONIMO-3590
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: mail
Reporter: Rick McGuire
Assignee: Rick McGuire


The TextHandler included with the javamail spec code gets an I/O failure when 
the contentStream() used to read the text is a ByteArrayInputStream.  The read 
method for ByteArrayInputStream does not appear to return a -1 value for an EOF 
(it returns 0), so the InputStreamReader wrappered around the stream is 
throwing an exception on the first 0 return.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [BUILD] 2.1: Failed for Revision: 592996

[Jacek Laskowski]

On 8 Nov 2007 03:21:12 -,  <[EMAIL PROTECTED]> wrote:

> TESTSUITE RESULTS (Failures only)
> =
> See detailed results at 
> http://people.apache.org/~prasad/testsuite/ResultsSummary.html
> See the full test.log file at 
> http://people.apache.org/~prasad/binaries/trunk/20071107/logs-2100/test.log
>
> [INFO] Running console-testsuite.basic-console
> [INFO] Tests run: 110, Failures: 3, Errors: 0, Skipped: 107, Time elapsed: 
> 0.872 sec <<< FAILURE!
> [INFO] Running console-testsuite.advance-test
> [INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 
> 3.452 sec <<< FAILURE!
> --
> [INFO] Running enterprise-testsuite.ejbtests
> [INFO] Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 0.125 
> sec <<< FAILURE!

How can I run the tests on my computer? I could build geronimo fine
yesterday with no failures.

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl