date:20081118

Geronimo Revision: 718518 built with tests included
 
See the full build-0300.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081118/build-0300.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081118/unit-test-reports
 
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository)


[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Missing:
--
1) oro:oro:jar:2.0.8

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=oro -DartifactId=oro -Dversion=2.0.8 
-Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=oro -DartifactId=oro -Dversion=2.0.8 
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.codehaus.groovy.maven:gmaven-plugin:maven-plugin:1.0-rc-2
2) org.apache.maven.reporting:maven-reporting-impl:jar:2.0.4.1
3) commons-validator:commons-validator:jar:1.2.0
4) oro:oro:jar:2.0.8

--
1 required artifact is missing.

for artifact: 
  org.codehaus.groovy.maven:gmaven-plugin:maven-plugin:1.0-rc-2

from the specified remote repositories:
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org),
  java.net (http://download.java.net/maven/1/),
  apache-incubator (http://people.apache.org/repo/m2-incubating-repository/),
  ibiblio.org (http://repo1.maven.org/maven2),
  codehaus.org (http://snapshots.repository.codehaus.org),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: 
org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing:
--
1) oro:oro:jar:2.0.8

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=oro -DartifactId=oro -Dversion=2.0.8 
-Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=oro -DartifactId=oro -Dversion=2.0.8 
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.codehaus.groovy.maven:gmaven-plugin:maven-plugin:1.0-rc-2
2) org.apache.maven.reporting:maven-reporting-impl:jar:2.0.4.1
3) commons-validator:commons-validator:jar:1.2.0
4) oro:oro:jar:2.0.8

--
1 required artifact is missing.

for artifact: 
  org.codehaus.groovy.maven:gmaven-plugin:maven-plugin:1.0-rc-2

from the specified remote repositories:
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org),
  java.net (http://download.java.net/maven/1/),
  apache-incubator (http://people.apache.org/repo/m2-incubating-repository/),
  ibiblio.org (http://repo1.maven.org/maven2),
  codehaus.org (http://snapshots.repository.codehaus.org),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository)

at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:324

[jira] Commented: (GERONIMODEVTOOLS-534) Fail to remove directory from repository after removing project from elicpse


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648569#action_12648569
 ] 

viola.lu commented on GERONIMODEVTOOLS-534:
---

Thanks Ted.I tried to deploy jar to G via deploy command, which behaves same as 
in WEP.Seems it's not a GEP problem.Should report it in G server not in GEP?

 Fail to remove directory from repository after removing project from elicpse
 

 Key: GERONIMODEVTOOLS-534
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.1.3
 Environment: OS:windows 2003
Reporter: viola.lu
Assignee: Tim McConnell
Priority: Minor
 Attachments: testejb.jar


 Steps:
 1.Create an ejb project in elicpse, and deploy it to geronimo server via WEP, 
 some errors output in console
 2.So i remove it from current server runtime.Do some modifcation, and 
 redeploy it
 3.But it tells me that 
 11:39:19,546 ERROR [RepositoryConfigurationStore] 
 C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car is 
 not an empty directory
 11:42:13,765 ERROR [RepositoryConfigurationStore] 
 C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car is 
 not an empty directory
 4.I should go to repository to remove default directory first and go on.

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

java.lang.LinkageError: Class org/apache/xbean/finder/ClassFinder violates loader constraints

2008-11-18 Thread Vamsavardhana Reddy

I am trying to invoke ClassFinder code from TuscanyModuleBuilderExtension I
am creating for the Tuscany plugin.  I have the following code
ClassFinder cf = module.getClassFinder();
ListClass annotatedClasses =
cf.findAnnotatedClasses(org.osoa.sca.annotations.Reference.class);

The call in the second line above is throwing a LinkageError.  Stack trace
is given below.

java.lang.LinkageError: Class org/apache/xbean/finder/ClassFinder
violates loader constraints
at 
org.apache.geronimo.tuscany.TuscanyModuleBuilderExtension.addGBeans(TuscanyModuleBuilderExtension.java:154)
at 
org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:497)
at 
org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165)
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at 
org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
at 
org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
at java.lang.Thread.run(Thread.java:595)

My guess is that it is some class loader issue.  Any ideas on how to fix
this problem?

--
Vamsi

[jira] Closed: (GERONIMO-4141) The war exported as a geronimo plugin in admin console cannot be installed with install-plugin command of deploy.bat|.sh


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

Donald Woods closed GERONIMO-4141.
--


Colsing, as Forrest confirmed the fix.

 The war exported as a geronimo plugin in admin console cannot be installed 
 with install-plugin command of deploy.bat|.sh
 

 Key: GERONIMO-4141
 URL: https://issues.apache.org/jira/browse/GERONIMO-4141
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3
 Environment: SLES 10 SP2, JDK 1.5.0
Reporter: Forrest Xia
Assignee: Lin Sun
Priority: Minor
 Fix For: 2.1.4

 Attachments: Geronimo-4141.patch, jsp-examples-2.1.0.0.war, 
 jsp-examples-war-2.1-SNAPSHOT.war


 Steps:
 1. install a war
 2. export the war as a G plugin with admin console's export plugin function
 3. undeploy it thru console, and use deployer install-plugin command to 
 install the exported war
 Results: The installation failed with message like this installation FAILED: 
 start of org.apache.geronimo.samples/cviewer/2.1.0.0/war failed.
 The server log includes these exceptions:
 17:12:38,335 ERROR [GBeanInstance] Problem in doFail of 
 samples/cviewer/2.1.0.0/war?J2EEApplication=null,j2eeType=WebModule,name=samples/cviewer/2.1.0.0/war
 java.lang.NullPointerException
 at 
 org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:380)
 at 
 org.apache.geronimo.tomcat.TomcatWebAppContext.doFail(TomcatWebAppContext.java:540)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1028)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541)
 at 
 org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
 at 
 org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
 at 
 org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
 at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
 at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
 at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555)
 at 
 org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
 at 
 org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456)
 at 
 org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
 at 
 org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)
 at 
 org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:543)
 at 
 org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:684)
 at 
 org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:877)
 at 
 org.apache.geronimo.system.plugin.PluginInstallerGBean$4.run(PluginInstallerGBean.java:787)
 at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214)
 at 
 org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
 at java.lang.Thread.run(Thread.java:810)
 17:12:38,338 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
 the FAILED state: 
 abstractName=samples/cviewer/2.1.0.0/war?J2EEApplication=null,j2eeType=WebModule,name=samples/cviewer/2.1.0.0/war
 java.lang.NullPointerException
 at java.io.File.init(File.java:220)
 at

Re: [jira] Commented: (GERONIMODEVTOOLS-534) Fail to remove directory from repository after removing project from elicpse

2008-11-18 Thread Ted Kirby

Yes please.  Thanks!   If you could include some more of the G log,
that would be great.  Hopefully, it mentions which files are in the
directory.  Can you report that too, by looking on the file system?
Also, was this run on one machine, or is remote deploy involved?  Is
the repository file system local or remote?  Thanks.

On Tue, Nov 18, 2008 at 5:31 AM, viola.lu (JIRA) [EMAIL PROTECTED] wrote:

[ 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648569#action_12648569
  ]

 viola.lu commented on GERONIMODEVTOOLS-534:
 ---

 Thanks Ted.I tried to deploy jar to G via deploy command, which behaves same 
 as in WEP.Seems it's not a GEP problem.Should report it in G server not in 
 GEP?

 Fail to remove directory from repository after removing project from elicpse
 

 Key: GERONIMODEVTOOLS-534
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.1.3
 Environment: OS:windows 2003
Reporter: viola.lu
Assignee: Tim McConnell
Priority: Minor
 Attachments: testejb.jar


 Steps:
 1.Create an ejb project in elicpse, and deploy it to geronimo server via 
 WEP, some errors output in console
 2.So i remove it from current server runtime.Do some modifcation, and 
 redeploy it
 3.But it tells me that
 11:39:19,546 ERROR [RepositoryConfigurationStore] 
 C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car 
 is not an empty directory
 11:42:13,765 ERROR [RepositoryConfigurationStore] 
 C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car 
 is not an empty directory
 4.I should go to repository to remove default directory first and go on.

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

Re: Monitoring console docs

2008-11-18 Thread Donald Woods

I really think topics such as building Geronimo from source, how to 
import/build/debug Geronimo in Eclipse, ... should remain in the GMOxDEV 
space, as those docs are really meant for Geronimo contributors and 
committers, not general users of released Geronimo assemblies.



-Donald


RunHua Chi wrote:


Hi David,

Thanks  for pointing this out.  We noticed there are lots of on-going
documents in the trunk(http://cwiki.apache.org/GMOxDEV/index.html). Right
now, we are moving some of them to G2.2 document.

For example, Building Geronimo with Maven is one of topics that perfectly
fits in our current G2.2 doc structure, so we moved this page to include it
within G2.2
Doc.(http://cwiki.apache.org/GMOxDOC22/building-geronimo-with-maven.html)

We believe that users will be glad to see more and more information about
Geronimo especially the new topic, we are also expecting new topics to be
included in G2.2 doc with well structured.

Also great appreciation on your working on improvements upon this topic, 
you may add this page to G2.2 index under appropriate parent and work on it

now. Or we can help you with this when you think the topic is closing to
completion(just drop a mail in the list).

Any comments, we'd be love to know.

Jeff


djencks wrote:
I've been trying to understand how the monitoring console works and  
found this documentation:


http://cwiki.apache.org/GMOxDEV/monitoring-and-management-service.html

While it doesn't appear completely consistent (the last sentence  
appears to predate the MRCJMX)  I think this should be moved to the  
2.2 docs?


Are there any other docs available?


BTW the current code doesn't appear very satisfactory to me, I'm  
working on some improvements.


thanks
david jencks

[jira] Closed: (GERONIMODEVTOOLS-531) Security Setting In UI doesn't completely reflect in source mode


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

Donald Woods closed GERONIMODEVTOOLS-531.
-

Resolution: Won't Fix

Closing as requested by Viola.

 Security Setting In UI doesn't completely reflect in source mode
 

 Key: GERONIMODEVTOOLS-531
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-531
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.1.3
 Environment: OS:WIndows 2003, Suse
Reporter: viola.lu
Assignee: Tim McConnell
Priority: Minor

 Steps:
 1.Create a web dynamic project, append its web.xml with below snippnet
 security-role
   role-namecontent-admin/role-name
   /security-role
 2.Open geronimo-web.xml, click Security tab, choose Role content-admin, 
 add a Realm principal, choose geronimo-admin, input name admin,domain name 
 admin, save it.
 3.Go to source mode, it just append a snippnet below
 sec:security
 sec:role-mappings
 sec:role role-name=content-admin
 sec:realm-principal 
 class=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal 
 domain-name=admin name=admin realm-name=geronimo-admin/
 /sec:role
 /sec:role-mappings
 /sec:security
 missing part:
 web:security-realm-namegeronimo-admin/web:security-realm-name
 4.So geronimo-web.xml marks as red with error. i should manally add above 
 missing part to make it work.

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

[jira] Created: (GERONIMO-4417) Enhance manifest classpath generation in ArchiveCarMojo

2008-11-18 Thread Jarek Gawor (JIRA)

Enhance manifest classpath generation in ArchiveCarMojo
---

 Key: GERONIMO-4417
 URL: https://issues.apache.org/jira/browse/GERONIMO-4417
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: car-maven-plugin
Affects Versions: 2.2
Reporter: Jarek Gawor


Add an option to ArchiveCarMojo to automatically generate classpath entries in 
the manifest file so that it uses the jar files under the repository 
directory of Geronimo installation. Right now, the jar file locations can be 
specified in the classpath entry but that is hard to maintain. With these 
feature, the jar file locations would be automatically generated (if enabled). 
Also, with this feature we should be able to get rid off some of the duplicated 
jar files under the lib directory.


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

[jira] Resolved: (GERONIMO-4417) Enhance manifest classpath generation in ArchiveCarMojo

2008-11-18 Thread Jarek Gawor (JIRA)


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

Jarek Gawor resolved GERONIMO-4417.
---

   Resolution: Fixed
Fix Version/s: 2.2
 Assignee: Jarek Gawor

Committed changes to trunk (revision 718644). 


 Enhance manifest classpath generation in ArchiveCarMojo
 ---

 Key: GERONIMO-4417
 URL: https://issues.apache.org/jira/browse/GERONIMO-4417
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: car-maven-plugin
Affects Versions: 2.2
Reporter: Jarek Gawor
Assignee: Jarek Gawor
 Fix For: 2.2


 Add an option to ArchiveCarMojo to automatically generate classpath entries 
 in the manifest file so that it uses the jar files under the repository 
 directory of Geronimo installation. Right now, the jar file locations can be 
 specified in the classpath entry but that is hard to maintain. With these 
 feature, the jar file locations would be automatically generated (if 
 enabled). Also, with this feature we should be able to get rid off some of 
 the duplicated jar files under the lib directory.

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

Re: svn commit: r718644 - in /geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car: ArchiveCarMojo.java ClasspathElement.java

2008-11-18 Thread David Jencks


-1, at least without some discussion.

One of the principles of geronimo is that we try to make components  
independent where possible.  For instance, we don't let the particular  
implementation of Repository leak into other parts of the server.   
This change firmly fixes our current repository structure into any  
plugin that uses this new functionality and makes it impossible to run  
such plugins on any other repository implementation.


thanks
david jencks

On Nov 18, 2008, at 8:33 AM, [EMAIL PROTECTED] wrote:


Author: gawor
Date: Tue Nov 18 08:33:38 2008
New Revision: 718644

URL: http://svn.apache.org/viewvc?rev=718644view=rev
Log:
improve manifest classpath generation (GERONIMO-4417)

Modified:
   geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/ 
org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java
   geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/ 
org/apache/geronimo/mavenplugins/car/ClasspathElement.java


Modified: geronimo/server/trunk/buildsupport/car-maven-plugin/src/ 
main/java/org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java

URL: 
http://svn.apache.org/viewvc/geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java?rev=718644r1=718643r2=718644view=diff
= 
= 
= 
= 
= 
= 
= 
= 
==
--- geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/ 
java/org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java  
(original)
+++ geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/ 
java/org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java Tue  
Nov 18 08:33:38 2008

@@ -133,6 +133,19 @@
 * @parameter
 */
private String classpathPrefix = null;
+
+/**
+ * Generate classpath prefix based on the artifactId and  
groupId. The generated classpath

+ * prefix will be in the following form:
+ * tt../repository/lt;groupIdgt;/lt;artifactIdgt;/ 
lt;versiongt;/tt.
+ * This is the default setting applied to all elements of the  
ttclasspath/tt which
+ * do not provide a prefix or do not set the  
generateClasspathPrefix parameter.  The
+ * classpath prefix will only be generated if the  
ttclasspathPrefix/tt parameter is not

+ * set.
+ *
+ * @parameter
+ */
+private boolean generateClasspathPrefix;

/**
 * Location of resources directory for additional content to  
include in the car.

@@ -243,7 +256,22 @@

String prefix = classpath[i].getClasspathPrefix();
if (prefix == null) {
-prefix = classpathPrefix;
+Boolean generatePrefix =  
classpath[i].getGenerateClasspathPrefix();

+if (generatePrefix == null) {
+// generatePrefix is not set - try defaults
+if (classpathPrefix == null) {
+if (generateClasspathPrefix) {
+prefix = generatePrefix(artifact);
+}
+} else {
+prefix = classpathPrefix;
+}
+} else if (Boolean.TRUE.equals(generatePrefix)) {
+// generatePrefix is explicitly set to true  
- generate prefix

+prefix = generatePrefix(artifact);
+} else {
+// generatePrefix is explicitly set to  
false - leave null prefix

+}
}

if (prefix != null) {
@@ -269,4 +297,8 @@
return buff.toString();
}

-}
\ No newline at end of file
+private static String generatePrefix(Artifact artifact) {
+return ../repository/ +  
artifact.getGroupId().replace('.', '/') + / +  
artifact.getArtifactId() + / + artifact.getVersion();

+}
+
+}

Modified: geronimo/server/trunk/buildsupport/car-maven-plugin/src/ 
main/java/org/apache/geronimo/mavenplugins/car/ClasspathElement.java

URL: 
http://svn.apache.org/viewvc/geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ClasspathElement.java?rev=718644r1=718643r2=718644view=diff
= 
= 
= 
= 
= 
= 
= 
= 
==
--- geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/ 
java/org/apache/geronimo/mavenplugins/car/ClasspathElement.java  
(original)
+++ geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/ 
java/org/apache/geronimo/mavenplugins/car/ClasspathElement.java Tue  
Nov 18 08:33:38 2008

@@ -78,6 +78,17 @@
 * @parameter
 */
private String entry;
+
+/**
+ * Generate classpath prefix based on the artifactId and  
groupId. The generated classpath

+ * prefix will be in the following form:
+ * tt../repository/lt;groupIdgt;/lt;artifactIdgt;/ 
lt;versiongt;/tt.
+ * The classpath

[jira] Reopened: (GERONIMO-4417) Enhance manifest classpath generation in ArchiveCarMojo

2008-11-18 Thread David Jencks (JIRA)


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

David Jencks reopened GERONIMO-4417:



I think this is a very bad idea as it lets the details of our particular 
repository layout leak into plugins.  I am -1 on this at least without some 
very strong justification well beyond convenience.

 Enhance manifest classpath generation in ArchiveCarMojo
 ---

 Key: GERONIMO-4417
 URL: https://issues.apache.org/jira/browse/GERONIMO-4417
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: car-maven-plugin
Affects Versions: 2.2
Reporter: Jarek Gawor
Assignee: Jarek Gawor
 Fix For: 2.2


 Add an option to ArchiveCarMojo to automatically generate classpath entries 
 in the manifest file so that it uses the jar files under the repository 
 directory of Geronimo installation. Right now, the jar file locations can be 
 specified in the classpath entry but that is hard to maintain. With these 
 feature, the jar file locations would be automatically generated (if 
 enabled). Also, with this feature we should be able to get rid off some of 
 the duplicated jar files under the lib directory.

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

[BUILD] trunk: Failed for Revision: 718597

Geronimo Revision: 718597 built with tests included
 
See the full build-0900.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081118/build-0900.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081118
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 140 minutes 40 seconds
[INFO] Finished at: Tue Nov 18 11:26:09 EST 2008
[INFO] Final Memory: 376M/1012M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081118/logs-0900-tomcat/test.log
 
 
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from apache-snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from codehaus-snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from apache.snapshots
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:46.581
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 33 test build(s)
[INFO] 
[INFO] 
---
[INFO] 
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:17.920) 
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:28.390) 
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.977) 
[INFO] commands-testsuite/shutdown  RUNNING
[INFO] commands-testsuite/shutdown  SUCCESS (0:00:15.837) 
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:14.393) 
[INFO] console-testsuite/advanced   RUNNING
[INFO] console-testsuite/advanced   SUCCESS (0:01:35.926) 
[INFO] console-testsuite/basic  RUNNING
[INFO] console-testsuite/basic  SUCCESS (0:01:44.324) 
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:43.102) 
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:01:05.851) 
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:45.041) 
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:31.790) 
[INFO] deployment-testsuite/jca-cms-tests   RUNNING
[INFO] deployment-testsuite/jca-cms-tests   SUCCESS (0:00:27.372) 
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:29.911) 
[INFO] enterprise-testsuite/ejb-tests   RUNNING
[INFO] enterprise-testsuite/ejb-tests   SUCCESS (0:00:45.710) 
[INFO] enterprise-testsuite/jms-tests   RUNNING
[INFO] enterprise-testsuite/jms-tests   SUCCESS (0:00:48.136) 
[INFO] enterprise-testsuite/jpa-tests   RUNNING
[INFO] enterprise-testsuite/jpa-tests   SUCCESS (0:04:17.978) 
[INFO] enterprise-testsuite/sec-client  RUNNING
[INFO] enterprise-testsuite/sec-client  SUCCESS (0:00:26.794) 
[INFO] enterprise-testsuite/sec-tests   RUNNING
[INFO] enterprise-testsuite/sec-tests   SUCCESS (0:00:51.075) 
[INFO] security-testsuite/test-security RUNNING
[INFO] security

[jira] Created: (GERONIMO-4418) Sample on how to setup app specific logging

Sample on how to setup app specific logging
---

 Key: GERONIMO-4418
 URL: https://issues.apache.org/jira/browse/GERONIMO-4418
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: sample apps
Reporter: Donald Woods
Priority: Minor
 Fix For: 2.2


From the user list at - 
http://www.nabble.com/Configuring-log4j-as-jvm-environment-variable-fails-to20378195s134.html#a20378195

We should create a new sample to show users how to setup custom logging for 
their web apps.


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

Re: svn commit: r718644 - in /geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car: ArchiveCarMojo.java ClasspathElement.java

2008-11-18 Thread Jarek Gawor

David,

Yes, the generated classpath manifest for the these plugins would
assume a certain directory structure. But a certain directory
structure was already assumed before my changes. Before the plugins
assumed that all the depended files lived under the ../lib
directory. How is that different?
My changes were intended to be used by the plugins that serve as
command line clients (executed via java -jar) and not any other
plugins. I wanted to avoid copying more files into the lib directory
and instead using the jar files directly from the repository
directory. I think we had a similar issue with GShell before.

Jarek

On Tue, Nov 18, 2008 at 12:12 PM, David Jencks [EMAIL PROTECTED] wrote:
 -1, at least without some discussion.

 One of the principles of geronimo is that we try to make components
 independent where possible.  For instance, we don't let the particular
 implementation of Repository leak into other parts of the server.  This
 change firmly fixes our current repository structure into any plugin that
 uses this new functionality and makes it impossible to run such plugins on
 any other repository implementation.

 thanks
 david jencks

 On Nov 18, 2008, at 8:33 AM, [EMAIL PROTECTED] wrote:

 Author: gawor
 Date: Tue Nov 18 08:33:38 2008
 New Revision: 718644

 URL: http://svn.apache.org/viewvc?rev=718644view=rev
 Log:
 improve manifest classpath generation (GERONIMO-4417)

 Modified:

 geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java

 geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ClasspathElement.java

 Modified:
 geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java
 URL:
 http://svn.apache.org/viewvc/geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java?rev=718644r1=718643r2=718644view=diff

 ==
 ---
 geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java
 (original)
 +++
 geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java
 Tue Nov 18 08:33:38 2008
 @@ -133,6 +133,19 @@
 * @parameter
 */
private String classpathPrefix = null;
 +
 +/**
 + * Generate classpath prefix based on the artifactId and groupId. The
 generated classpath
 + * prefix will be in the following form:
 + *
 tt../repository/lt;groupIdgt;/lt;artifactIdgt;/lt;versiongt;/tt.
 + * This is the default setting applied to all elements of the
 ttclasspath/tt which
 + * do not provide a prefix or do not set the generateClasspathPrefix
 parameter.  The
 + * classpath prefix will only be generated if the
 ttclasspathPrefix/tt parameter is not
 + * set.
 + *
 + * @parameter
 + */
 +private boolean generateClasspathPrefix;

/**
 * Location of resources directory for additional content to include in
 the car.
 @@ -243,7 +256,22 @@

String prefix = classpath[i].getClasspathPrefix();
if (prefix == null) {
 -prefix = classpathPrefix;
 +Boolean generatePrefix =
 classpath[i].getGenerateClasspathPrefix();
 +if (generatePrefix == null) {
 +// generatePrefix is not set - try defaults
 +if (classpathPrefix == null) {
 +if (generateClasspathPrefix) {
 +prefix = generatePrefix(artifact);
 +}
 +} else {
 +prefix = classpathPrefix;
 +}
 +} else if (Boolean.TRUE.equals(generatePrefix)) {
 +// generatePrefix is explicitly set to true -
 generate prefix
 +prefix = generatePrefix(artifact);
 +} else {
 +// generatePrefix is explicitly set to false -
 leave null prefix
 +}
}

if (prefix != null) {
 @@ -269,4 +297,8 @@
return buff.toString();
}

 -}
 \ No newline at end of file
 +private static String generatePrefix(Artifact artifact) {
 +return ../repository/ + artifact.getGroupId().replace('.', '/')
 + / + artifact.getArtifactId() + / + artifact.getVersion();
 +}
 +
 +}

 Modified:
 geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ClasspathElement.java
 URL:
 http://svn.apache.org/viewvc/geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ClasspathElement.java?rev=718644r1=718643r2=718644view=diff

[jira] Created: (GERONIMO-4419) Create a TomcatUsersLoginModule that can use unmodified tomcat-users.xml files

Create a TomcatUsersLoginModule that can use unmodified tomcat-users.xml files
--

 Key: GERONIMO-4419
 URL: https://issues.apache.org/jira/browse/GERONIMO-4419
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: security
Reporter: Donald Woods
Priority: Minor
 Fix For: 2.2


Allow Tomcat users to use their tomcat-users.xml unmodified in Geronimo by 
creating a new LoginModule security provider.
See http://www.nabble.com/Geronimo-security-question-to20244202s134.html


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

Re: svn commit: r718644 - in /geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car: ArchiveCarMojo.java ClasspathElement.java

2008-11-18 Thread David Jencks



On Nov 18, 2008, at 10:09 AM, Jarek Gawor wrote:


David,

Yes, the generated classpath manifest for the these plugins would
assume a certain directory structure. But a certain directory
structure was already assumed before my changes. Before the plugins
assumed that all the depended files lived under the ../lib
directory. How is that different?
My changes were intended to be used by the plugins that serve as
command line clients (executed via java -jar) and not any other
plugins. I wanted to avoid copying more files into the lib directory
and instead using the jar files directly from the repository
directory. I think we had a similar issue with GShell before.


The previous way we did this was to keep the minimal possible stuff in  
lib and fire up a geronimo kernel with a repository gbean in it to  
abstract the actual structure of the repo for command line clients.   
My (quite possibly wrong) understanding is that gshell is doing  
something similar using some ivy classes.


Can you write these plugins to depend on the client-system plugin and  
run them as app clients?


I have to say I'm not very happy about the current state of geronimo  
startup.  IIUC gshell is using spring, ivy, and ant to set up the jvm  
for geronimo which is then using the geronimo kernel to set up a whole  
other set of classloaders using imitation maven classes.  I surely  
don't have a solution but this seems just too complex with too much  
duplicated functionality to me.


thanks
david jencks




Jarek

On Tue, Nov 18, 2008 at 12:12 PM, David Jencks  
[EMAIL PROTECTED] wrote:

-1, at least without some discussion.

One of the principles of geronimo is that we try to make components
independent where possible.  For instance, we don't let the  
particular
implementation of Repository leak into other parts of the server.   
This
change firmly fixes our current repository structure into any  
plugin that
uses this new functionality and makes it impossible to run such  
plugins on

any other repository implementation.

thanks
david jencks

On Nov 18, 2008, at 8:33 AM, [EMAIL PROTECTED] wrote:


Author: gawor
Date: Tue Nov 18 08:33:38 2008
New Revision: 718644

URL: http://svn.apache.org/viewvc?rev=718644view=rev
Log:
improve manifest classpath generation (GERONIMO-4417)

Modified:

geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/ 
org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java


geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/ 
org/apache/geronimo/mavenplugins/car/ClasspathElement.java


Modified:
geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/ 
org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java

URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java?rev=718644r1=718643r2=718644view=diff

= 
= 
= 
= 
= 
= 
= 
= 
= 
= 


---
geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/ 
org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java

(original)
+++
geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/ 
org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java

Tue Nov 18 08:33:38 2008
@@ -133,6 +133,19 @@
   * @parameter
   */
  private String classpathPrefix = null;
+
+/**
+ * Generate classpath prefix based on the artifactId and  
groupId. The

generated classpath
+ * prefix will be in the following form:
+ *
tt../repository/lt;groupIdgt;/lt;artifactIdgt;/ 
lt;versiongt;/tt.

+ * This is the default setting applied to all elements of the
ttclasspath/tt which
+ * do not provide a prefix or do not set the  
generateClasspathPrefix

parameter.  The
+ * classpath prefix will only be generated if the
ttclasspathPrefix/tt parameter is not
+ * set.
+ *
+ * @parameter
+ */
+private boolean generateClasspathPrefix;

  /**
   * Location of resources directory for additional content to  
include in

the car.
@@ -243,7 +256,22 @@

  String prefix = classpath[i].getClasspathPrefix();
  if (prefix == null) {
-prefix = classpathPrefix;
+Boolean generatePrefix =
classpath[i].getGenerateClasspathPrefix();
+if (generatePrefix == null) {
+// generatePrefix is not set - try defaults
+if (classpathPrefix == null) {
+if (generateClasspathPrefix) {
+prefix = generatePrefix(artifact);
+}
+} else {
+prefix = classpathPrefix;
+}
+} else if  
(Boolean.TRUE.equals(generatePrefix)) {
+// generatePrefix is explicitly set to  
true -

generate prefix
+prefix = generatePrefix(artifact);

[jira] Resolved: (GERONIMODEVTOOLS-400) editing and saving the deployment plan XML doesn't get reflected back into the editor pages.

2008-11-18 Thread B.J. Reed (JIRA)


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

B.J. Reed resolved GERONIMODEVTOOLS-400.


Resolution: Fixed

Fixed with revision 718691.  Had to create a new class that inherits from the 
StructuredTextEditor (XML Source page editor) to add a call back to the editor 
to do a reload after the save has occurred.  The reload goes through each page 
and has them update themselves to reflect the new deployment plan data.

 editing and saving the deployment plan XML doesn't get reflected back into 
 the editor pages.
 

 Key: GERONIMODEVTOOLS-400
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-400
 Project: Geronimo-Devtools
  Issue Type: Sub-task
  Components: eclipse-plugin
Affects Versions: 2.1.3
Reporter: B.J. Reed
Assignee: B.J. Reed
Priority: Minor
 Fix For: 2.2.0


 If a user goes to the deployment plan editor xml file and makes updates 
 there, they do not get reflected back into the other editor pages.  For the 
 user to see the changes reflected, they must close and reopen the editor.  
 This is a problem with all 5 editors.

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

Re: svn commit: r712326 - in /geronimo/server/trunk: framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/ framework/modules/geronimo-kernel/src/main/java/org/apache/

2008-11-18 Thread David Jencks




On Nov 18, 2008, at 12:39 PM, Gianny Damour wrote:


On 19/11/2008, at 5:19 AM, Joe Bohn wrote:


Joe Bohn wrote:
Just a heads up that I *think* there are still some issues with  
this change.
It appears that the hiddenResource processing from the  
MultiParentClassloader was removed.


Correction ... it was not removed but rather changed and  
relocated.  I'm still looking to understand why this is causing a  
problem.


Hi,

Indeed, I changed the implementation to properly encapsulate class  
loading rules. The new implementation is way cleaner this way; when  
my frustration coming from reported issues will reduce, I may use  
this better encapsulation to add import and export class loading  
rules.




I think this has resulted in some
testsuite failures involving tld processing.  There are failures  
in the web-testsuite/test-2.1-jsps and web-testsuite/test-myfaces  
tests.  I'm looking at what would be necessary to add in the  
hiddenResource logic again hoping that will resolve the issue.
This is a really nice feature and it is great to have the  
capability. However could you please run the testsuite in the  
future to avoid problems like this (especially when introducing  
fundamental changes like this)?


If this is indeed a bug related to this change, then let's ensure  
that we have a proper unit test to prevent regression. Let's also  
ensure that this test is collocated with the proper component to  
improve cohesion. I have been observing various changes, many of  
them do not have proper unit tests and this causes problems further  
down the path as other developers can not safely change code.


Regarding private-classes, the current Geronimo - OpenEJB DD  
coupling is unfortunate. Does the OpenEJB deployer needs to know  
about the Geronimo environment? If it does not need to know about  
it, then let's strip from the DD the environment element and pass to  
OpenEJB the stripped version. This will reduce a little bit  
coupling. Another approach is to transform the Geronimo DD into an  
OpenEJB supported DD when it is handed over to OpenEJB (in this  
case, we simply remove the private-classes). The creation of a  
canonical DD representation between Geronimo and OpenEJB will reduce  
coupling.


I think the problem is caused by mismatch between our xmlbeans plan  
handling and the openejb jaxb plan handling.  Maybe we should consider  
moving the jaxb classes to a more neutral location?  This will  
probably take some work though.


thanks
david jencks



I let you re-revert the private-classes change.

Thanks,
Gianny

Re: svn commit: r718644 - in /geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car: ArchiveCarMojo.java ClasspathElement.java

2008-11-18 Thread Jarek Gawor

On Tue, Nov 18, 2008 at 1:51 PM, David Jencks [EMAIL PROTECTED] wrote:

 The previous way we did this was to keep the minimal possible stuff in lib
 and fire up a geronimo kernel with a repository gbean in it to abstract the
 actual structure of the repo for command line clients.  My (quite possibly
 wrong) understanding is that gshell is doing something similar using some
 ivy classes.

 Can you write these plugins to depend on the client-system plugin and run
 them as app clients?

Well, I can fix my particular problem by either dumping
geronimo-system.jar into the lib dir or by moving some classes (e.g.
RepositoryConfigurationStore.java) from geronimo-system to
geronimo-kernel. Let me if either of these sounds good to you.
I don't really want to start up a whole app container just to execute
some command line tool. I did look into booting a basic kernel with a
repo gbean (sort of what deployer or client does) but that will
require a separate plugin. And I already have two plugins just to
deploy and install the jaxws tooling. I guess I should re-consider
this option.

 I have to say I'm not very happy about the current state of geronimo
 startup.  IIUC gshell is using spring, ivy, and ant to set up the jvm for
 geronimo which is then using the geronimo kernel to set up a whole other set
 of classloaders using imitation maven classes.  I surely don't have a
 solution but this seems just too complex with too much duplicated
 functionality to me.

Btw, the version of GShell used in Geronimo trunk just loads the jar
files from the lib or the repository directory as specified in the
etc/gsh-classworlds.conf file.

Jarek

[jira] Closed: (GERONIMO-4417) Enhance manifest classpath generation in ArchiveCarMojo

2008-11-18 Thread Jarek Gawor (JIRA)


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

Jarek Gawor closed GERONIMO-4417.
-

Resolution: Fixed

I reverted the changes.

 Enhance manifest classpath generation in ArchiveCarMojo
 ---

 Key: GERONIMO-4417
 URL: https://issues.apache.org/jira/browse/GERONIMO-4417
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: car-maven-plugin
Affects Versions: 2.2
Reporter: Jarek Gawor
Assignee: Jarek Gawor
 Fix For: 2.2


 Add an option to ArchiveCarMojo to automatically generate classpath entries 
 in the manifest file so that it uses the jar files under the repository 
 directory of Geronimo installation. Right now, the jar file locations can be 
 specified in the classpath entry but that is hard to maintain. With these 
 feature, the jar file locations would be automatically generated (if 
 enabled). Also, with this feature we should be able to get rid off some of 
 the duplicated jar files under the lib directory.

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

[jira] Assigned: (GERONIMO-3838) memory (probably related to sessions) leak

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

Donald Woods reassigned GERONIMO-3838:
--

Assignee: Donald Woods

memory (probably related to sessions) leak
--

Key: GERONIMO-3838
URL: https://issues.apache.org/jira/browse/GERONIMO-3838
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Memory Leaks, Tomcat
Affects Versions: 2.0.2, 2.1.1
Environment: tested with JDK 1.5 running on Windows XP and FreeBSD6.2
Reporter: Radim Kolar
Assignee: Donald Woods
Priority: Critical
Fix For: 2.1.4, 2.2

Attachments: Geronimo-3838-11-16.patch

There is memory leak and it can be repeated very easily, so it should be very
easy to catch
Install Geronimo and then run some kind of benchmarking software against its
admin UI login page, for example
program ab from Apache HTTP. This is realistic attack scenario, because lot
of denial of service attacks are doing this (requesting one page many times).
Watching memory used graph in admin console shows free memory slowly
decreasing. After all available memory is exhausted, application server stops
serving new requests and never restores ifself back to working state.
I think that it is caused by allocating sessions without limiting total
number of sessions to keep in memory and possibly to swap sessions out to
file. There needs to be user-configurable setting for preventing this, it
would be nice to add such setting to Admin console.
Its very important to get this bug fixed.

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

[jira] Updated: (GERONIMO-3838) memory (probably related to sessions) leak

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

Donald Woods updated GERONIMO-3838:
---

Patch Info: [Patch Available]
Fix Version/s: 2.1.4

memory (probably related to sessions) leak
--

Attachments: Geronimo-3838-11-16.patch

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

[BUILD] trunk: Failed for Revision: 718704

Geronimo Revision: 718704 built with tests included
 
See the full build-1500.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081118/build-1500.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081118
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 40 minutes 23 seconds
[INFO] Finished at: Tue Nov 18 15:46:35 EST 2008
[INFO] Final Memory: 387M/1011M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081118/logs-1500-tomcat/test.log
 
 
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from apache-snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from codehaus-snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from apache.snapshots
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:44.117
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 33 test build(s)
[INFO] 
[INFO] 
---
[INFO] 
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:15.407) 
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:28.594) 
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.540) 
[INFO] commands-testsuite/shutdown  RUNNING
[INFO] commands-testsuite/shutdown  SUCCESS (0:00:15.802) 
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:18.928) 
[INFO] console-testsuite/advanced   RUNNING
[INFO] console-testsuite/advanced   SUCCESS (0:01:38.070) 
[INFO] console-testsuite/basic  RUNNING
[INFO] console-testsuite/basic  SUCCESS (0:01:44.279) 
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:45.625) 
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:47.069) 
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:45.341) 
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:31.248) 
[INFO] deployment-testsuite/jca-cms-tests   RUNNING
[INFO] deployment-testsuite/jca-cms-tests   SUCCESS (0:00:26.919) 
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:28.932) 
[INFO] enterprise-testsuite/ejb-tests   RUNNING
[INFO] enterprise-testsuite/ejb-tests   SUCCESS (0:00:47.588) 
[INFO] enterprise-testsuite/jms-tests   RUNNING
[INFO] enterprise-testsuite/jms-tests   SUCCESS (0:00:47.528) 
[INFO] enterprise-testsuite/jpa-tests   RUNNING
[INFO] enterprise-testsuite/jpa-tests   SUCCESS (0:00:52.348) 
[INFO] enterprise-testsuite/sec-client  RUNNING
[INFO] enterprise-testsuite/sec-client  SUCCESS (0:00:26.765) 
[INFO] enterprise-testsuite/sec-tests   RUNNING
[INFO] enterprise-testsuite/sec-tests   SUCCESS (0:00:49.844) 
[INFO] security-testsuite/test-security RUNNING
[INFO] security

[jira] Commented: (GERONIMODEVTOOLS-534) Fail to remove directory from repository after removing project from elicpse


[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648901#action_12648901
 ] 

viola.lu commented on GERONIMODEVTOOLS-534:
---

This a g problem, so i will open a defect for G server, pls close this one.

 Fail to remove directory from repository after removing project from elicpse
 

 Key: GERONIMODEVTOOLS-534
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.1.3
 Environment: OS:windows 2003
Reporter: viola.lu
Assignee: Tim McConnell
Priority: Minor
 Attachments: testejb.jar


 Steps:
 1.Create an ejb project in elicpse, and deploy it to geronimo server via WEP, 
 some errors output in console
 2.So i remove it from current server runtime.Do some modifcation, and 
 redeploy it
 3.But it tells me that 
 11:39:19,546 ERROR [RepositoryConfigurationStore] 
 C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car is 
 not an empty directory
 11:42:13,765 ERROR [RepositoryConfigurationStore] 
 C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car is 
 not an empty directory
 4.I should go to repository to remove default directory first and go on.

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

[jira] Created: (GERONIMO-4420) Create Files under repository even if fail to deploy a jar having problems.

Create Files under repository even if fail to deploy a jar having problems.
---

 Key: GERONIMO-4420
 URL: https://issues.apache.org/jira/browse/GERONIMO-4420
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 2.1.3
 Environment: OS:Any platform
Reporter: viola.lu
Priority: Minor
 Attachments: testejb.jar

Defect transfers from GEP:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534

Steps:
1.Deploy attached testejb.jar, and this jar has some problems in it.So when 
deploy it via command or admin console, errors exist.
2.But in repository, files for this deployed jar are created already.If i 
redeploy this jar or deploy it second time, it will inform me : it exists in 
repository, i should remove it manually from repository.

no log in server.log.





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

[jira] Updated: (GERONIMO-4420) Create Files under repository even if fail to deploy a jar having problems.


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

viola.lu updated GERONIMO-4420:
---

Attachment: testejb.jar

 Create Files under repository even if fail to deploy a jar having problems.
 ---

 Key: GERONIMO-4420
 URL: https://issues.apache.org/jira/browse/GERONIMO-4420
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 2.1.3
 Environment: OS:Any platform
Reporter: viola.lu
Priority: Minor
 Attachments: testejb.jar


 Defect transfers from GEP:
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534
 Steps:
 1.Deploy attached testejb.jar, and this jar has some problems in it.So when 
 deploy it via command or admin console, errors exist.
 2.But in repository, files for this deployed jar are created already.If i 
 redeploy this jar or deploy it second time, it will inform me : it exists in 
 repository, i should remove it manually from repository.
 no log in server.log.

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

[jira] Closed: (GERONIMODEVTOOLS-534) Fail to remove directory from repository after removing project from elicpse


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

Ted Kirby closed GERONIMODEVTOOLS-534.
--

Resolution: Fixed

This is a server issue.  See GERONIMO-4420,

 Fail to remove directory from repository after removing project from elicpse
 

 Key: GERONIMODEVTOOLS-534
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.1.3
 Environment: OS:windows 2003
Reporter: viola.lu
Assignee: Tim McConnell
Priority: Minor
 Attachments: testejb.jar


 Steps:
 1.Create an ejb project in elicpse, and deploy it to geronimo server via WEP, 
 some errors output in console
 2.So i remove it from current server runtime.Do some modifcation, and 
 redeploy it
 3.But it tells me that 
 11:39:19,546 ERROR [RepositoryConfigurationStore] 
 C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car is 
 not an empty directory
 11:42:13,765 ERROR [RepositoryConfigurationStore] 
 C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car is 
 not an empty directory
 4.I should go to repository to remove default directory first and go on.

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

[jira] Commented: (GERONIMO-4420) Create Files under repository even if fail to deploy a jar having problems.


[ 
https://issues.apache.org/jira/browse/GERONIMO-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648907#action_12648907
 ] 

Ted Kirby commented on GERONIMO-4420:
-

See link another instance of  GERONIMO-3489.

Viola, any special considerations, like remote deploy, or any kind of remote 
file system?

 Create Files under repository even if fail to deploy a jar having problems.
 ---

 Key: GERONIMO-4420
 URL: https://issues.apache.org/jira/browse/GERONIMO-4420
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 2.1.3
 Environment: OS:Any platform
Reporter: viola.lu
Priority: Minor
 Attachments: testejb.jar


 Defect transfers from GEP:
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534
 Steps:
 1.Deploy attached testejb.jar, and this jar has some problems in it.So when 
 deploy it via command or admin console, errors exist.
 2.But in repository, files for this deployed jar are created already.If i 
 redeploy this jar or deploy it second time, it will inform me : it exists in 
 repository, i should remove it manually from repository.
 no log in server.log.

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

[jira] Reopened: (GERONIMODEVTOOLS-534) Fail to remove directory from repository after removing project from elicpse


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

Ted Kirby reopened GERONIMODEVTOOLS-534:



The issue was not fixed.  I am reopening to to assign a more appropriate 
resolution.

 Fail to remove directory from repository after removing project from elicpse
 

 Key: GERONIMODEVTOOLS-534
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.1.3
 Environment: OS:windows 2003
Reporter: viola.lu
Assignee: Tim McConnell
Priority: Minor
 Attachments: testejb.jar


 Steps:
 1.Create an ejb project in elicpse, and deploy it to geronimo server via WEP, 
 some errors output in console
 2.So i remove it from current server runtime.Do some modifcation, and 
 redeploy it
 3.But it tells me that 
 11:39:19,546 ERROR [RepositoryConfigurationStore] 
 C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car is 
 not an empty directory
 11:42:13,765 ERROR [RepositoryConfigurationStore] 
 C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car is 
 not an empty directory
 4.I should go to repository to remove default directory first and go on.

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

[BUILD] trunk: Failed for Revision: 718843

Geronimo Revision: 718843 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081118/build-2100.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081118
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 46 minutes 2 seconds
[INFO] Finished at: Tue Nov 18 21:51:20 EST 2008
[INFO] Final Memory: 374M/1014M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081118/logs-2100-tomcat/test.log
 
 
[INFO] snapshot 
org.apache.geronimo.framework:geronimo-deploy-jsr88:2.2-SNAPSHOT: checking for 
updates from apache.snapshots
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from apache-snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from codehaus-snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from apache.snapshots
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:45.616
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 33 test build(s)
[INFO] 
[INFO] 
---
[INFO] 
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:12.416) 
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:29.025) 
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.601) 
[INFO] commands-testsuite/shutdown  RUNNING
[INFO] commands-testsuite/shutdown  SUCCESS (0:00:15.851) 
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:15.384) 
[INFO] console-testsuite/advanced   RUNNING
[INFO] console-testsuite/advanced   SUCCESS (0:01:40.866) 
[INFO] console-testsuite/basic  RUNNING
[INFO] console-testsuite/basic  SUCCESS (0:01:45.898) 
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:45.785) 
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:01:28.468) 
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:45.025) 
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:30.863) 
[INFO] deployment-testsuite/jca-cms-tests   RUNNING
[INFO] deployment-testsuite/jca-cms-tests   SUCCESS (0:00:27.741) 
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:29.201) 
[INFO] enterprise-testsuite/ejb-tests   RUNNING
[INFO] enterprise-testsuite/ejb-tests   SUCCESS (0:00:44.943) 
[INFO] enterprise-testsuite/jms-tests   RUNNING
[INFO] enterprise-testsuite/jms-tests   SUCCESS (0:00:49.643) 
[INFO] enterprise-testsuite/jpa-tests   RUNNING
[INFO] enterprise-testsuite/jpa-tests   SUCCESS (0:00:49.346) 
[INFO] enterprise-testsuite/sec-client  RUNNING
[INFO] enterprise-testsuite/sec-client  SUCCESS (0:00:26.169) 
[INFO] enterprise-testsuite/sec-tests   RUNNING
[INFO] enterprise

[jira] Closed: (GERONIMODEVTOOLS-534) Fail to remove directory from repository after removing project from elicpse