RE: Tests and forking

2004-09-06 Thread Alan D. Cabrera
I can take network and security.


Regards,
Alan

 -Original Message-
 From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
 Sent: Sunday, September 05, 2004 4:24 PM
 To: [EMAIL PROTECTED]
 Subject: Tests and forking
 
 Last night I changed the global (reactor) build to no longer fork unit
 tests by default.  The following modules have tests that will not
 complete without forking:
 
 axis
 j2ee
 j2ee-schema
 network
 remoting
 security
 system
 transaction
 
 Of these modules, I believe that only the system module has tests must
 be forked.  The rest of the modules seem to be failing because the
 tests assume that the vm has been launched in the module directory,
and
 open files using relative paths.
 
 I have already fixed the connector module which had this problem by
 introducing a new system property using these entries in module
 project.properties file:
 
 # Pass basedir of this module as a system property to tests
 maven.junit.sysproperties=geronimo.test.basedir
 geronimo.test.basedir=${basedir}
 
 Then in the tests, I use this entry to determine the base directory
 module:
 
 private static final File basedir = new File(
  System.getProperty(geronimo.test.basedir,
  System.getProperty(user.dir)));
 
 Using this, we should be able to execute the tests from the global
 (reactor) build, on an individual module basis, and from an ide
 (assuming the test runner is executed from the module dir or you
 explicitly set the geronimo.test.basedir system property).
 
 If you would like to help with the conversion to non-forked tests,
 please let everyone know which module you are working on.
 
 -dain
 
 --
 Dain Sundstrom
 Chief Architect
 Gluecode Software
 310.536.8355, ext. 26
 




Re: Tests and forking

2004-09-06 Thread Dain Sundstrom
Cool.  I'll try that out.
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Sep 5, 2004, at 5:19 PM, David Jencks wrote:
You should not need to define an extra sysproperty.
The test plugin already exposes basedir as a system property:
in the ant command:
sysproperty key=basedir value=${basedir}/
So, just this should be enough:
private static final File basedir = new File(
 System.getProperty(basedir,
 System.getProperty(user.dir)));

thanks
david jencks
On Sep 5, 2004, at 5:09 PM, Alan D. Cabrera wrote:
I can take network and security.
Regards,
Alan
-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 05, 2004 4:24 PM
To: [EMAIL PROTECTED]
Subject: Tests and forking
Last night I changed the global (reactor) build to no longer fork 
unit
tests by default.  The following modules have tests that will not
complete without forking:

axis
j2ee
j2ee-schema
network
remoting
security
system
transaction
Of these modules, I believe that only the system module has tests 
must
be forked.  The rest of the modules seem to be failing because the
tests assume that the vm has been launched in the module directory,
and
open files using relative paths.
I have already fixed the connector module which had this problem by
introducing a new system property using these entries in module
project.properties file:
# Pass basedir of this module as a system property to tests
maven.junit.sysproperties=geronimo.test.basedir
geronimo.test.basedir=${basedir}
Then in the tests, I use this entry to determine the base directory
module:
private static final File basedir = new File(
 System.getProperty(geronimo.test.basedir,
 System.getProperty(user.dir)));
Using this, we should be able to execute the tests from the global
(reactor) build, on an individual module basis, and from an ide
(assuming the test runner is executed from the module dir or you
explicitly set the geronimo.test.basedir system property).
If you would like to help with the conversion to non-forked tests,
please let everyone know which module you are working on.
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26




Re: Tests and forking

2004-09-06 Thread Dain Sundstrom
That works great.
I'm going to convert j2ee and j2ee-schema next.
-dain
On Sep 5, 2004, at 6:30 PM, Dain Sundstrom wrote:
Cool.  I'll try that out.
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Sep 5, 2004, at 5:19 PM, David Jencks wrote:
You should not need to define an extra sysproperty.
The test plugin already exposes basedir as a system property:
in the ant command:
sysproperty key=basedir value=${basedir}/
So, just this should be enough:
private static final File basedir = new File(
 System.getProperty(basedir,
 System.getProperty(user.dir)));

thanks
david jencks
On Sep 5, 2004, at 5:09 PM, Alan D. Cabrera wrote:
I can take network and security.
Regards,
Alan
-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 05, 2004 4:24 PM
To: [EMAIL PROTECTED]
Subject: Tests and forking
Last night I changed the global (reactor) build to no longer fork 
unit
tests by default.  The following modules have tests that will not
complete without forking:

axis
j2ee
j2ee-schema
network
remoting
security
system
transaction
Of these modules, I believe that only the system module has tests 
must
be forked.  The rest of the modules seem to be failing because the
tests assume that the vm has been launched in the module directory,
and
open files using relative paths.
I have already fixed the connector module which had this problem by
introducing a new system property using these entries in module
project.properties file:
# Pass basedir of this module as a system property to tests
maven.junit.sysproperties=geronimo.test.basedir
geronimo.test.basedir=${basedir}
Then in the tests, I use this entry to determine the base directory
module:
private static final File basedir = new File(
 System.getProperty(geronimo.test.basedir,
 System.getProperty(user.dir)));
Using this, we should be able to execute the tests from the global
(reactor) build, on an individual module basis, and from an ide
(assuming the test runner is executed from the module dir or you
explicitly set the geronimo.test.basedir system property).
If you would like to help with the conversion to non-forked tests,
please let everyone know which module you are working on.
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26




[jira] Updated: (GERONIMO-269) webservice deployment with ews

2004-09-06 Thread dev
The following issue has been updated:

Updater: Srinath Perera (mailto:[EMAIL PROTECTED])
   Date: Sun, 5 Sep 2004 11:46 PM
Comment:
this patch update the module class Names to XXManagers, make the code openejb 
independent and move the deploy() to AxisGBeans. Move all the Object Names to 
one place   
Changes:
 Attachment changed to patch.txt
-
For a full history of the issue, see:

  http://issues.apache.org/jira/browse/GERONIMO-269?page=history

-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-269

Here is an overview of the issue:
-
Key: GERONIMO-269
Summary: webservice deployment with ews
   Type: New Feature

 Status: Unassigned
   Priority: Major

Project: Apache Geronimo

   Assignee: 
   Reporter: Srinath Perera

Created: Wed, 21 Jul 2004 7:08 PM
Updated: Sun, 5 Sep 2004 11:46 PM
Environment: all

Description:
this patch has code to deploy the webservice in the geronimo.
there is a
1) WebServiceDeployerGbean and by calling deploy GBean  method one can
deploy a webservice. right now Axis service keep a seperate config-store
but that can be changed when we decide on the final thing

2)the Deployer accept a webservice jar file and generate the required code
using ews and deploy them. for time been the Axis GBean need to restart to
get the new deploymnet.

3)the complete senario is shown in the WebServiceTest.java test. But to
run this code need the JAVA_HOME/lib/tools.jar  in the classpth. Since
still can not get it in the classpath of maven I exclude the tests. If
somebody using IDE and add the tools.jar in the classpath they should work
fine :)

4) let me add some doc to the wiki about how this works.



-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Commented: (GERONIMO-269) webservice deployment with ews

2004-09-06 Thread dev
The following comment has been added to this issue:

 Author: Srinath Perera
Created: Sun, 5 Sep 2004 11:50 PM
   Body:
the patch added today update the module to XXManagers, make the code openejb 
independent and move the deploy() to AxisGBeans. Move all the Object Names to 
one place and make the All required GBeans loaded automatically.   
-
View this comment:
  http://issues.apache.org/jira/browse/GERONIMO-269?page=comments#action_52870

-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-269

Here is an overview of the issue:
-
Key: GERONIMO-269
Summary: webservice deployment with ews
   Type: New Feature

 Status: Unassigned
   Priority: Major

Project: Apache Geronimo

   Assignee: 
   Reporter: Srinath Perera

Created: Wed, 21 Jul 2004 7:08 PM
Updated: Sun, 5 Sep 2004 11:50 PM
Environment: all

Description:
this patch has code to deploy the webservice in the geronimo.
there is a
1) WebServiceDeployerGbean and by calling deploy GBean  method one can
deploy a webservice. right now Axis service keep a seperate config-store
but that can be changed when we decide on the final thing

2)the Deployer accept a webservice jar file and generate the required code
using ews and deploy them. for time been the Axis GBean need to restart to
get the new deploymnet.

3)the complete senario is shown in the WebServiceTest.java test. But to
run this code need the JAVA_HOME/lib/tools.jar  in the classpth. Since
still can not get it in the classpath of maven I exclude the tests. If
somebody using IDE and add the tools.jar in the classpath they should work
fine :)

4) let me add some doc to the wiki about how this works.



-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[status] build: SUCCESSFUL, test: SUCCESSFUL | Linux 2.4.26, 2004-09-06

2004-09-06 Thread dblevins
NIGHTLY BUILD/TEST
  Date: Mon Sep  6 05:32:13 EDT 2004
  Kernel: Linux 2.4.26
  Host: beaver.codehaus.org
  Java: 1.4.2_04-b05, mixed mode
  Maven: 1.0

CHECKOUT: incubator-geronimo

BUILDING: incubator-geronimo

BUILD SUCCESSFUL
Total time: 15 minutes 55 seconds
Finished at: Mon Sep 06 05:49:36 EDT 2004


The build is broken

2004-09-06 Thread Alan D. Cabrera








As happens when ever we embark on a project re-org, the
build is broken. Id like to suggest some of the following steps to
be performed before certifying that what has been done will not break the build:




 Remove the geronimo, ews, axis,
 and openejb repositories before doing a full rebuild.
 Build on a windoze box where
 your maven repository is in a path that has spaces in it.
 Build OpenEJB




Doing these three simple steps will cover about 95% of the
problems that I encounter whenever a project re-org takes place.





Thanks,

Alan












Re: The build is broken

2004-09-06 Thread Dain Sundstrom
This was my bad.  I have fixed one of the problems.  I removed the spec 
jars from the default build, and forgot to check that the modules were 
capable of downloading them from the repo.  Several modules were 
missing the remote repo location.

The second problem which I can't reproduce is the connector module 
breaks on windows.  Hopefully someone with a windows box can fix it.

-dain
On Sep 6, 2004, at 7:50 AM, Alan D. Cabrera wrote:
As happens when ever we embark on a project re-org, the build is 
broken. Id like to suggest some of the following steps to be 
performed before certifying that what has been done will not break the 
build:


	 	Remove the geronimo, ews, axis, and openejb repositories before 
doing a full rebuild.
	 	Build on a windoze box where your maven repository is in a path 
that has spaces in it.
	 	Build OpenEJB


Doing these three simple steps will cover about 95% of the problems 
that I encounter whenever a project re-org takes place.



Thanks,
Alan