Re: AnnotationHelperTest failures in trunk

2010-12-16 Thread Ashish Jain 
Hi Rick,

I had been facing a similar problem. I have deleted xbean from my local repo
and now build
seems to  be running fine.

Thanks
Ashish

On Thu, Dec 16, 2010 at 3:50 PM, Rick McGuire  wrote:

> On 12/15/2010 9:49 AM, Rick McGuire wrote:
>
>> I was able to retrace my steps enough to track down the source of the
>> regression.  One of the things I had done late yesterday was build a new
>> version of XBean from trunk.  If I delete xbean from my local maven repo and
>> refresh the snapshot from the snapshot repository, the build problem goes
>> away.  The last xbean snapshot was deployed October 21st, so it's a bit on
>> the old side.  Some update since then appears to have introduced a
>> regression.
>>
> Managed to track this down.  The problem was caused by doing a local build
> of the xbean trunk.  The last set of changes to the ClassFinder had a couple
> of bugs and returned some information in a different order.  The bugs are
> fixed and the unit test has been adjusted to the new expected order.  I
> deployed a new xbean snapshot and also committed a fix to the unit test so
> that it matches.
>
> Rick
>
>
>
>> Rick
>>
>> On 12/15/2010 8:44 AM, Rick McGuire wrote:
>>
>>> After doing an svn up this morning, I started receiving test failures in
>>> AnnotationHelperTest while building.  Since there were only a few updates
>>> applied in the last day, I tried backing off each update to figure out what
>>> change caused the failure.  I backed off all the way to rev 1048998, but am
>>> still seeing the test failures.  I know I successfully built that revision
>>> yesterday (and I did multiple complete builds for the revisions I committed
>>> yesterday along the way).  So, I'm a bit at a loss for what is causing these
>>> failures now.  I suspect it's probably being caused by a new snapshot
>>> revision in some dependency, but I've not managed to locate the problem
>>> area.  Is anybody else seeing this problem?
>>>
>>> Rick
>>>
>>
>>
>

[jira] Created: (GERONIMO-5733) Maintain a jaxb tree for all the vender specific schemas

2010-12-16 Thread Ivan (JIRA) 
Maintain a jaxb tree for all the vender specific schemas


 Key: GERONIMO-5733
 URL: https://issues.apache.org/jira/browse/GERONIMO-5733
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 3.0
Reporter: Ivan


We enjoyed a lot for the spec xml parsing from openejb-jee module, think that 
we should also main a jaxb tree module contains all the jaxb classes generated 
from all the geronimo side schema files. With this, we would not need to 
generate those xmlbeans classes on the building time, also, GEP could use it 
for xml editor.
I know that GEP has maintained these similar jaxb classes, we might just need 
to move those classes to server side.

-- 
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: 1050139

2010-12-16 Thread gawor 
Geronimo Revision: 1050139 built with tests included
 
See the full build-1500.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216/build-1500.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 41 minutes 12 seconds
[INFO] Finished at: Thu Dec 16 15:47:27 EST 2010
[INFO] Final Memory: 537M/1007M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216/logs-1500-tomcat/
 
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.506 sec <<< 
FAILURE!
 
Assembly: jetty
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216/logs-1500-jetty/
 
Running TestSuite
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.533 sec <<< 
FAILURE!
--
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.605 sec <<< 
FAILURE!
 
Samples: trunk
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216/samples-1500.log
 
Build status: FAILED

[BUILD] branches/2.2: Failed for Revision: 1050089

2010-12-16 Thread gawor 
 
Samples: branches/2.2
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20101215/samples-1400.log
 
Build status: FAILED
 
Geronimo Revision: 1050089 built with tests included
 
See the full build-1400.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20101216/build-1400.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20101216/unit-test-reports
 
  ibiblio.org (http://maven.rtp.raleigh.ibm.com/nexus-proxy/),
  apache.snapshots (http://repository.apache.org/snapshots)


  org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.2.2-SNAPSHOT

from the specified remote repositories:
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  ibiblio.org (http://maven.rtp.raleigh.ibm.com/nexus-proxy/),
  apache.snapshots (http://repository.apache.org/snapshots)


[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Plugin could not be 
found - check that the goal name is correct: Unable to download the artifact 
from any repository

Try downloading the file manually from the project website.

Then, install it using the command: 
mvn install:install-file -DgroupId=org.apache.geronimo.buildsupport 
-DartifactId=car-maven-plugin -Dversion=2.2.2-SNAPSHOT -Dpackaging=maven-plugin 
-Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there: 
mvn deploy:deploy-file -DgroupId=org.apache.geronimo.buildsupport 
-DartifactId=car-maven-plugin -Dversion=2.2.2-SNAPSHOT -Dpackaging=maven-plugin 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]


  org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.2.2-SNAPSHOT

from the specified remote repositories:
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  ibiblio.org (http://maven.rtp.raleigh.ibm.com/nexus-proxy/),
  apache.snapshots (http://repository.apache.org/snapshots)


  org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.2.2-SNAPSHOT

from the specified remote repositories:
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  ibiblio.org (http://maven.rtp.raleigh.ibm.com/nexus-proxy/),
  apache.snapshots (http://repository.apache.org/snapshots)


at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions(DefaultLifecycleExecutor.java:238)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:178)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at 
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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:592)
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.plugin.PluginNotFoundException: Plugin could not be 
found - check that the goal name is correct: Unable to download the artifact 
from any repository

Try downloading the file manually from the project website.

Then, install it using the command: 
mvn install:install-file -DgroupId=org.apache.geronimo.buildsupport 
-DartifactId=car-maven-plugin -Dversion=2.2.2-SNAPSHOT -Dpackaging=maven-plugin 
-Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there: 
mvn deploy:deploy-file -DgroupId=org.apache.geronimo.buildsupport 
-DartifactId=car-maven-plugin -Dversion=2.2.2-SNAPSHOT -Dpackaging=maven-plugin 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]


  org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.2.2-SNAPSHOT

from the specified remote repositories:
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  ibiblio.org (http://maven.rtp.raleigh.ibm.com/nexus-proxy/),
  apache.snapshots (http://repository.apache.org/snapshots)


  org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.2.2-SNAPSHOT

from the specified remote repositories:
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  ibiblio.org (http://maven.rtp.raleigh.ibm.com/nexus-proxy/),
  apache.snapshots (http://repository.apache.org/snapshots)


at 
org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:253)
at

[BUILD] branches/2.1: Failed for Revision: 1049791

2010-12-16 Thread gawor 
Geronimo Revision: 1049791 built with tests included
 
See the full build-0200.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20101216/build-0200.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20101216/unit-test-reports
 
at java.lang.Object.wait(Object.java:474)
at 
hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
- locked <0x722e7840> (a 
hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
at 
hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
at 
hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
at 
hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
at java.lang.Thread.run(Thread.java:595)

"pool-1-thread-2" prio=1 tid=0x6005bfe8 nid=0x2c20 in Object.wait() 
[0x601fe000..0x601fef20]
at java.lang.Object.wait(Native Method)
- waiting on <0x722e7840> (a 
hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
at java.lang.Object.wait(Object.java:474)
at 
hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
- locked <0x722e7840> (a 
hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
at 
hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
at 
hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
at 
hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
at java.lang.Thread.run(Thread.java:595)

"pool-1-thread-1" prio=1 tid=0x6005c730 nid=0x2c1f in Object.wait() 
[0x60399000..0x60399ea0]
at java.lang.Object.wait(Native Method)
- waiting on <0x722e7840> (a 
hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
at java.lang.Object.wait(Object.java:474)
at 
hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
- locked <0x722e7840> (a 
hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
at 
hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
at 
hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
at 
hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
at java.lang.Thread.run(Thread.java:595)

"Low Memory Detector" daemon prio=1 tid=0x60b019a0 nid=0x2a39 runnable 
[0x..0x]

"CompilerThread1" daemon prio=1 tid=0x60b005c0 nid=0x2a38 waiting on condition 
[0x..0x609fc1c8]

"CompilerThread0" daemon prio=1 tid=0x08148f88 nid=0x2a37 waiting on condition 
[0x..0x60a7d348]

"AdapterThread" daemon prio=1 tid=0x08147ef0 nid=0x2a36 waiting on condition 
[0x..0x]

"Signal Dispatcher" daemon prio=1 tid=0x08147150 nid=0x2a35 runnable 
[0x..0x]

"Finalizer" daemon prio=1 tid=0x0813e100 nid=0x2a34 in Object.wait() 
[0x60d1f000..0x60d1fda0]
at java.lang.Object.wait(Native Method)
- waiting on <0x722626f0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
- locked <0x722626f0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=1 tid=0x0813ca90 nid=0x2a33 in Object.wait() 
[0x60da..0x60da0f20]
at java.lang.Object.wait(Native Method)
- waiting on <0x7216e250> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:474)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x7216e250> (a java.lang.ref.Reference$Lock)

"main" prio=1 tid=0x0805ce08 nid=0x2a29 in Object.wait() 
[0xbfffc000..0xbfffd818]
at java.lang.Object.wait(Native Method)
- waiting on <0xab9e4360> (a java.lang.UNIXProcess)
at java.lang.Object.wait(Object.java:474)
at java.lang.UNIXProcess.waitFor(UNIXProcess.java:165)
- locked <0xab9e4360> (a java.lang.

[BUILD] branches/2.2: Failed for Revision: 1049944

2010-12-16 Thread gawor 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20101216/unit-test-reports

[BUILD] trunk: Failed for Revision: 1049982

2010-12-16 Thread gawor 
Geronimo Revision: 1049982 built with tests included
 
See the full build-0900.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216/build-0900.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 48 minutes 47 seconds
[INFO] Finished at: Thu Dec 16 09:59:13 EST 2010
[INFO] Final Memory: 463M/1009M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216/logs-0900-tomcat/
 
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.566 sec <<< 
FAILURE!
--
Running TestSuite
Tests run: 14, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 32.124 sec <<< 
FAILURE!
 
Assembly: jetty
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216/logs-0900-jetty/
 
Running TestSuite
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.518 sec <<< 
FAILURE!
--
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.4 sec <<< 
FAILURE!
 
Samples: trunk
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216/samples-0900.log
 
Build status: FAILED

[jira] Commented: (GERONIMODEVTOOLS-661) Create JAXB model for geronimo-jaspi.xsd

2010-12-16 Thread Han Hong Fang (JIRA) 

[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972088#action_12972088
 ] 

Han Hong Fang commented on GERONIMODEVTOOLS-661:


I didn't see the changes in branch v22, so commit the changes for branch v22 at 
revision 1049987.

> Create JAXB model for geronimo-jaspi.xsd
> 
>
> Key: GERONIMODEVTOOLS-661
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-661
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>  Components: eclipse-plugin
>Affects Versions: 2.2.0
>Reporter: Delos Dai
>Assignee: Delos Dai
> Fix For: 2.2.1, 3.0
>
>
> Create JAXB model for geronimo-jaspi.xsd. We have generated the model in 
> trunk.
> First, create plugin v22.jaxbmodel;
> then, for 2.2 branch, copy the model from trunk into v22.jaxbmodel;for trunk, 
> copy the model from v30.jaxbmodel into v22.jaxbmodel

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

Re: [VOTE] Release new bundle components.

2010-12-16 Thread Ivan 
+1

2010/12/15 Rex Wang 

> +1
> build, source looks good to me. Thanks Rick!
>
> -Rex
>
> 2010/12/15 Rick McGuire 
>
> This is a single vote for releasing 4 new Geronimo bundles that are OSGi
>> versions of other jar files.  The wrappered jars are
>>
>> axiom 1.2.8
>> axis2 1.5
>> scout 1.2.2
>> json 20090211
>>
>> The components up for vote are:
>>
>>
>> org/apache/geronimo/bundles/axiom-api/1.2.8_1/axiom-api-1.2.8_1-source-release.tar.gz
>>
>> org/apache/geronimo/bundles/axiom-api/1.2.8_1/axiom-api-1.2.8_1-source-release.zip
>>
>> org/apache/geronimo/bundles/axis2/1.5_1/axis2-1.5_1-source-release.tar.gz
>> org/apache/geronimo/bundles/axis2/1.5_1/axis2-1.5_1-source-release.zip
>>
>>
>> org/apache/geronimo/bundles/scout/1.2.2_1/scout-1.2.2_1-source-release.tar.gz
>> org/apache/geronimo/bundles/scout/1.2.2_1/scout-1.2.2_1-source-release.zip
>>
>>
>> org/apache/geronimo/bundles/json/20090211_1/json-20090211_1-source-release.tar.gz
>>
>> org/apache/geronimo/bundles/json/20090211_1/json-20090211_1-source-release.zip
>>
>> from the staging repository at:
>>
>> https://repository.apache.org/content/repositories/orgapachegeronimo-024/
>>
>> The source repos are:
>>
>> https://svn.apache.org/repos/asf/geronimo/bundles/tags/axiom-api-1.2.8_1
>> https://svn.apache.org/repos/asf/geronimo/bundles/tags/axis2-1.5_1
>> https://svn.apache.org/repos/asf/geronimo/bundles/tags/scout-1.2.2_1
>> https://svn.apache.org/repos/asf/geronimo/bundles/tags/json-20090211_1
>>
>>  Vote will be open for 72 hours.
>>
>>  [ ] +1  approve
>>  [ ] +0  no opinion
>>  [ ] -1  disapprove (and reason why)
>>
>>
>> Rick
>>
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>



-- 
Ivan

Re: [VOTE] Release geronimo txmanager 3.1

2010-12-16 Thread Ivan 
+1

2010/12/15 Rex Wang 

> +1
>
> Build pass, rat:check pass, license/notice, signature looks good.
>
> -Rex
>
> 2010/11/12 Rick McGuire 
>
> This is a the 3.1 txmanager equivalent to the 2.2.1 version that's also up
>> for vote.  This is the version being used for Geronimo 3.0.  This includes
>> the same Jiras that are in the 2.2.1 version.
>>
>> GERONIMO-5649 txmanager could try to replace dead XAResources in commit
>> and rollback tasks
>> GERONIMO-5684 Some txmanager Timers are not being created as daemon
>> threads
>>
>> The components up for vote are:
>>
>> org/apache/geronimo/components/geronimo-txmanager-parent/3.1/geronimo-txmanager-parent-3.1-source-release.tar.gz
>>
>> org/apache/geronimo/components/geronimo-txmanager-parent/3.1/geronimo-txmanager-parent-3.1-source-release.zip
>>
>>
>> from the staging repository at:
>>
>> https://repository.apache.org/content/repositories/orgapachegeronimo-066/
>>
>> The source repo is:
>>
>>
>> https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-3.1
>>
>>  Vote will be open for 72 hours.
>>
>>  [ ] +1  approve
>>  [ ] +0  no opinion
>>  [ ] -1  disapprove (and reason why)
>>
>>
>> Rick
>>
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>



-- 
Ivan

[BUILD] trunk: Failed for Revision: 1049811

2010-12-16 Thread gawor 
Geronimo Revision: 1049811 built with tests included
 
See the full build-0300.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216/build-0300.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 43 minutes 56 seconds
[INFO] Finished at: Thu Dec 16 03:50:15 EST 2010
[INFO] Final Memory: 538M/1006M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216/logs-0300-tomcat/
 
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.524 sec <<< 
FAILURE!
--
Running TestSuite
Tests run: 14, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 33.191 sec <<< 
FAILURE!
 
Assembly: jetty
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216/logs-0300-jetty/
 
Running TestSuite
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.906 sec <<< 
FAILURE!
--
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.781 sec <<< 
FAILURE!
 
Samples: trunk
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101216/samples-0300.log
 
Build status: FAILED

Re: GEP version blues

2010-12-16 Thread Johannes Weberhofer 

Hello Kevan, hello Hang,

I started a discussion on that issue in March. See 
http://www.mail-archive.com/dev@geronimo.apache.org/msg77363.html

Unfortunately I did not have time later on to continue to do something on that 
issue, but I still think, it is still an issue. I think it should always only 
be necessary to have one stable and one parallel version together, whereas the 
stable version supports all versions released so far.

Currently, when you install GEP in geronimo, you have to know exactly which 
Geronimo version you'll develop for; At the moment you have also some stuff [G 
2.1.1 (Jetty/Tomcat) Runtime, Geronimo Core Feature] on the 
install-repositories which is IMHO not longer used. Additionally there are 
server-adapters for Geronimo v1.0/v.1.1.x/v.2.0/v2.1/v.2.2 and v.3.0, where 
some cover versions below, too, but not all.

In reality it should be enough to have a v1.1 - v.2.2 Server Adapter there 
(which should support all Versions up to G 2.2 and possibly an unstable version 
of the adapter which supports also the most recent development releases.

However, this would be some work which somebody would have to do... But it 
could also make thinks simpler, when only a head and one stable-branch must be 
serviced.

Johannes

PS: Sorry for cross-posting, but I think, this thread could be discussed on the 
devel-mailinglist?



Am 16.12.10 06:20, schrieb han hongfang:



On Wed, Dec 15, 2010 at 5:46 PM, KHAksnes mailto:khaks...@gmail.com>> wrote:


My environment: Helios with Geronimo 2.1.6 and 2.2.1.
My problem: Which GEP version to choose?

Each version seems to have their own serious problem:
GEP 2.1.x doesn't support 2.2.1 as far as I know.
GEP 2.2 have problems editing openejb-jar.xml

For this problem, can you open a JIRA in 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS, and describe the 
problem details. So it can be considerred in GEP 2.2.1 release.

GEP 3.0 fails to deploy EARs to Geronimo 2.2.1

The obvious solution is likely to be GEP 2.2.1. but unfortunately it isn't
released yet.

We started a project this summer using Geronimo 2.2 but had to switch to
2.1.x due to a couple of serious bugs in 2.2. Now when 2.2.1 is out we wan't
to switch to it checking for compatibility etc. To ease this process we need
support for both 2.1.6 and 2.2.1 in the same environment.
--
View this message in context: 
http://apache-geronimo.328035.n3.nabble.com/GEP-version-blues-tp2091121p2091121.html
Sent from the Users mailing list archive at Nabble.com.




--
Best regards,

Han Hong Fang (Janet)
hanhongfang AT apache.org 



--
Johannes Weberhofer
Weberhofer GmbH, Austria, Vienna

Re: AnnotationHelperTest failures in trunk

2010-12-16 Thread Rick McGuire 

On 12/15/2010 9:49 AM, Rick McGuire wrote:
I was able to retrace my steps enough to track down the source of the 
regression.  One of the things I had done late yesterday was build a 
new version of XBean from trunk.  If I delete xbean from my local 
maven repo and refresh the snapshot from the snapshot repository, the 
build problem goes away.  The last xbean snapshot was deployed October 
21st, so it's a bit on the old side.  Some update since then appears 
to have introduced a regression.
Managed to track this down.  The problem was caused by doing a local 
build of the xbean trunk.  The last set of changes to the ClassFinder 
had a couple of bugs and returned some information in a different 
order.  The bugs are fixed and the unit test has been adjusted to the 
new expected order.  I deployed a new xbean snapshot and also committed 
a fix to the unit test so that it matches.


Rick



Rick

On 12/15/2010 8:44 AM, Rick McGuire wrote:
After doing an svn up this morning, I started receiving test failures 
in AnnotationHelperTest while building.  Since there were only a few 
updates applied in the last day, I tried backing off each update to 
figure out what change caused the failure.  I backed off all the way 
to rev 1048998, but am still seeing the test failures.  I know I 
successfully built that revision yesterday (and I did multiple 
complete builds for the revisions I committed yesterday along the 
way).  So, I'm a bit at a loss for what is causing these failures 
now.  I suspect it's probably being caused by a new snapshot revision 
in some dependency, but I've not managed to locate the problem area.  
Is anybody else seeing this problem?


Rick