[status] build: SUCCESSFUL, test: SUCCESSFUL | Linux 2.4.26, 2004-08-03
NIGHTLY BUILD/TEST Date: Tue Aug 3 05:30:45 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: 13 minutes 3 seconds Finished at: Tue Aug 03 05:45:32 EDT 2004
[jira] Assigned: (GERONIMO-281) Optional packages support
Message:
The following issue has been re-assigned.
Assignee: Jacek Laskowski (mailto:[EMAIL PROTECTED])
-
View the issue:
http://issues.apache.org/jira/browse/GERONIMO-281
Here is an overview of the issue:
-
Key: GERONIMO-281
Summary: Optional packages support
Type: New Feature
Status: Open
Priority: Major
Project: Apache Geronimo
Components:
deployment
OpenEJB
Assignee: Jacek Laskowski
Reporter: Jacek Laskowski
Created: Tue, 3 Aug 2004 4:37 AM
Updated: Tue, 3 Aug 2004 4:37 AM
Description:
Add optional packages support. Optional packages are resources listed in
META-INF/MANIFEST.MF as a value of the Class-Path main attribute.
As a workaround it's possible to copy the resources to repository directory and
specify them in a vendor specific way/DD, e.g. META-INF/openejb-jar.xml.
The suggested approach to handle it is (Dain's email to OpenEJB dev mailing
list):
[...]Instead I would create a lib directory in the config-store directory for
the module (i.e., a config-store/${number}/lib directory). Then, just read in
the manifest class path entries for the ejb jar, copy them into the lib dir and
add them to the configuration class-path. One trick is you must repeat this
for each jar copied into the lib as each of these can have manifest class path
entries. Also watch out for circular dependencies in the manifest class path
entries.[...]
-
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
Re: Unit/Stress Tests
Before we jump off the cliff here, just how long do the stress tests currently take? I don't think it is a significant fraction of the build time. I recall trying this idea of isolating stress tests in jboss builds and it turned into a real mess. Noone likes maintaining the test system, lets keep it as simple as possible. I think setting up damage control would be more useful. Also I have set up all the projects we are collectively involved in in a single build environment (tranql, howl, geronimo, openejb, activemq). I suggest we set up something like this to be run by dc. david jencks On Aug 3, 2004, at 9:10 AM, Dain Sundstrom wrote: On Aug 3, 2004, at 7:41 AM, Alan D. Cabrera wrote: 1) There is a maven build flag that lets builds complete, regardless of the tests' completion status. IMHO, if something breaks for them, then something is broken for their configuration and they should know about it; this is the raison d'etre of unit tests. People who cannot handle this should be directed to pre-built jars, though I suspect that most responsible shops will run the unit tests on their target platforms. However, if it takes a long time, then this is a different matter; I like David Jenks' idea of running smaller, quicker, tests. Although that is an good idea, I think the implementation is much more difficult. Until we have parameterized stress tests, I'd say the best plan is to isolate stress tests and only run them during the nightly build. -dain
Re: Unit/Stress Tests
On Tue, Aug 03, 2004 at 09:19:54AM -0700, David Jencks wrote: Before we jump off the cliff here, just how long do the stress tests currently take? Ok, never mind, I retract the idea. I just ran some comparisons and came out with some interesting numbers. On my 3Ghz WinXP/Cygwin box, these are the numbers I get: $ maven clean; maven -Dmaven.test.failure.ignore=true build1.log BUILD SUCCESSFUL Total time: 26 minutes 54 seconds Totalling up the actual Time elapsed numbers accounts for only 4.5 minutes (274 seconds) of that time. $ maven clean; maven -Dmaven.test.skip=true build2.log BUILD SUCCESSFUL Total time: 6 minutes 49 seconds That's basically a 20 minute difference with only 4.5 minutes reportedly spend on our tests. What is taking up the other 15 minutes? Is setUp/tearDown not counted in the test time? -David
Re: Unit/Stress Tests
I think the reason our stress tests don't take very long, is we are limiting them because we don't want the build to take a long time. I think once we remove this limitation the test time will grow and we will get actual stress testing. -dain On Aug 3, 2004, at 11:19 AM, David Jencks wrote: Before we jump off the cliff here, just how long do the stress tests currently take? I don't think it is a significant fraction of the build time. I recall trying this idea of isolating stress tests in jboss builds and it turned into a real mess. Noone likes maintaining the test system, lets keep it as simple as possible. I think setting up damage control would be more useful. Also I have set up all the projects we are collectively involved in in a single build environment (tranql, howl, geronimo, openejb, activemq). I suggest we set up something like this to be run by dc. david jencks On Aug 3, 2004, at 9:10 AM, Dain Sundstrom wrote: On Aug 3, 2004, at 7:41 AM, Alan D. Cabrera wrote: 1) There is a maven build flag that lets builds complete, regardless of the tests' completion status. IMHO, if something breaks for them, then something is broken for their configuration and they should know about it; this is the raison d'etre of unit tests. People who cannot handle this should be directed to pre-built jars, though I suspect that most responsible shops will run the unit tests on their target platforms. However, if it takes a long time, then this is a different matter; I like David Jenks' idea of running smaller, quicker, tests. Although that is an good idea, I think the implementation is much more difficult. Until we have parameterized stress tests, I'd say the best plan is to isolate stress tests and only run them during the nightly build. -dain
