Is anything in README.txt relevant anymore?
I think we need to clean up the main README.txt. Looks like most of the content is relatively dated and should be updated or removed. Also, a bunch of this information is about to use the server... when I think that the README.txt at this level should be more focused on how to build the server and run tests. This should not be the same README.txt that we provide with the assembly, so we can focus the content in each README.txt for its expected users. Below is what we currently have. What parts of it are still relevant, which parts do we want to keep and which should go? Even further down is a little snip of how to build, which I think we need to add... with some other details eventually too, and probably a link back to a more compressive page on cwiki. == Apache Geronimo milestone build M4 (August 10, 2005) http://geronimo.apache.org/ -- ___ Documentation === This README serves as five minute overview of Geronimo, but better documentation can be found here: - http://geronimo.apache.org/documentation.html ___ Release Notes === Please read the RELEASE_NOTES for a complete list of things that are not yet functional. We wrote those up to save you time trying to get things to work we know are not implemented. ___ Installation === If you've downloaded and unpacked a binary distribution of Geronimo, then you are finished with installation. You can also use the installer JAR to customize things like network ports and the administrative login during installation. ___ Geronimo Home === The GERONIMO_HOME directory, is the directory where the Geronimo binary was unpacked or the it is the 'target' directory created by Maven from a source distribution. If you unpacked the binary into the directory C:\geronimo, for example, than this directory is your GERONIMO_HOME directory. The GERONIMO_HOME directory is referred to in various parts of the documentation, so it's good to remember where it is. ___ Starting === The main server class is also packed in an executable jar, bin/server.jar, and can be ran in a way similar to the deploy tool. C:\geronimo> java -jar bin\server.jar Once the server has started, you can access the welcome page by pointing your browser to: http://localhost:8080/ You can also visit the web management console at: http://localhost:8080/console/ To access the console, use the administrative account, which is username "system" and password "manager" by default. ___ Deploying === The Geronimo deployment tool is packaged in the executable jar bin/deployer.jar under the GERONIMO_HOME and can be executed like this (assuming the server is already running): C:\geronimo> java -jar bin\deployer.jar deploy myDataSource.rar C:\geronimo> java -jar bin\deployer.jar deploy myEJB.jar C:\geronimo> java -jar bin\deployer.jar deploy myWebapp.war C:\geronimo> java -jar bin\deployer.jar deploy myApp.ear Notice that the deployer.jar is capable of handling a number of different archive types; rar, war, ejb jar, and EAR. The deployer will prompt you for a username and password; the default administrative account has username "system" and password "manager". ___ Support === Any problems with this release can be reported to the Geronimo mailing list or Jira issue tracker. Mailing list archive: http://mail-archives.apache.org/mod_mbox/geronimo-user/ Mailing list subscription: [EMAIL PROTECTED] Jira: http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10220 ++ | Bootstrapping and Building | ++ Geronimo currently must be bootstrapped, which will checkout and build all required thirdparty projects and then build all modules that are used by plugin extentions. To perform a clean bootstrap simply run: ./bootstrap Once bootstrapped once, repeated staged builds can be run with: ./build Both will run a multi-stage build. When making changes it is recommended to run `bootstrap` to ensure that no locally installed artifacts are interfearing with a clean build and that all thordparty projects are built from the latest sources. --jason
Re: svn commit: r420418 - in /geronimo/specs/trunk: ./ geronimo-spec-commonj/src/main/java/commonj/timers/ geronimo-spec-commonj/src/main/java/commonj/work/
You know... every field in an interface is by default public static
and final. Adding these modifiers is redundant.
--jason
On Jul 9, 2006, at 9:23 PM, [EMAIL PROTECTED] wrote:
Author: kevan
Date: Sun Jul 9 21:23:46 2006
New Revision: 420418
URL: http://svn.apache.org/viewvc?rev=420418&view=rev
Log:
GERONIMO-2179 Fix multiple signature problems with commonj specs
Modified:
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/timers/TimerManager.java
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/RemoteWorkItem.java
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkCompletedException.java
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkEvent.java
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkItem.java
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkManager.java
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkRejectedException.java
geronimo/specs/trunk/pom.xml
Modified: geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/timers/TimerManager.java
URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-
spec-commonj/src/main/java/commonj/timers/TimerManager.java?
rev=420418&r1=420417&r2=420418&view=diff
==
--- geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/timers/TimerManager.java (original)
+++ geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/timers/TimerManager.java Sun Jul 9 21:23:46 2006
@@ -35,12 +35,12 @@
*/
public interface TimerManager {
-static long IMMEDIATE = 0;
-static long INDEFINITE = java.lang.Long.MAX_VALUE;
+static final long IMMEDIATE = 0;
+static final long INDEFINITE = java.lang.Long.MAX_VALUE;
-boolean isStopped() throws IllegalStateException;
+boolean isStopped();
-boolean isStopping() throws IllegalStateException;
+boolean isStopping();
boolean isSuspended() throws IllegalStateException;
Modified: geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/RemoteWorkItem.java
URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-
spec-commonj/src/main/java/commonj/work/RemoteWorkItem.java?
rev=420418&r1=420417&r2=420418&view=diff
==
--- geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/RemoteWorkItem.java (original)
+++ geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/RemoteWorkItem.java Sun Jul 9 21:23:46 2006
@@ -33,7 +33,7 @@
/**
* @version $Rev: 46019 $ $Date: 2004-09-14 05:56:06 -0400 (Tue,
14 Sep 2004) $
*/
-public interface RemoteWorkItem extends Comparable, WorkItem {
+public interface RemoteWorkItem extends WorkItem {
WorkManager getPinnedWorkManager();
void release();
Modified: geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkCompletedException.java
URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-
spec-commonj/src/main/java/commonj/work/WorkCompletedException.java?
rev=420418&r1=420417&r2=420418&view=diff
==
--- geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkCompletedException.java (original)
+++ geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkCompletedException.java Sun Jul 9 21:23:46 2006
@@ -28,22 +28,45 @@
package commonj.work;
+import java.util.List;
+import java.util.ArrayList;
+import java.util.Collections;
+
/**
* @version $Rev: 46019 $ $Date: 2004-09-14 05:56:06 -0400 (Tue,
14 Sep 2004) $
*/
-public class WorkCompletedException extends Exception {
+public class WorkCompletedException extends WorkException {
+
+private final List exceptionList;
public WorkCompletedException() {
super();
+exceptionList = Collections.EMPTY_LIST;
}
public WorkCompletedException(String message) {
super(message);
+exceptionList = Collections.EMPTY_LIST;
}
public WorkCompletedException(String message, Throwable cause) {
super(message, cause);
+exceptionList = Collections.singletonList(cause);
}
public WorkCompletedException(Throwable cause) {
super(cause);
+exceptionList = Collections.singletonList(cause);
+}
+public WorkCompletedException(String message, List list) {
+super(message);
+if ((list != null) && (list.size() > 0)) {
+initCause((Throwable) list.get(0));
+exceptionList = Collections.unmodifiableList(new
ArrayList(list));
+} else {
+exceptionList = Collections.EMPTY_LIST;
+}
+}
+
+public List getExceptionList() {
+return ex
Re: [jira] Updated: (TUSCANY-527) First cut of the work scheduler implementation
On Jul 9, 2006, at 3:00 PM, Jeremy Boynes wrote: On Jul 9, 2006, at 11:08 AM, Jeremy Boynes wrote: On Jul 9, 2006, at 9:16 AM, David Jencks wrote: There's a geronimo version of the commonj spec at org.apache.geronimo.specs:geronimo-commonj_1.1_spec:1.0:jar at ibiblio. I'm not entirely sure what auspices this was published under since geronimo doesn't have a tck for commonj. If there are any problems with this jar please speak up on the geronimo dev list. David, I'm not sure what you mean by "what auspices"... Thanks David, I'll use that for now. There is also a version in the Apache WebServices WSRF project but they don't seem to have published it. I found a couple of problems in Geronimo's version with the signatures (e.g. exceptions missing). I modified the Geronimo source to match the spec javadoc I downloaded and it seems to compile now. Attached is a patch for geronimo-spec (from https:// svn.apache.org/repos/asf/geronimo/specs/trunk) This bumps the commonj spec jar version to 1.0.1-SNAPSHOT - hope that's the right version. Dave, if this works for you can you get a snapshot version uploaded so that Tuscany folk won't have to build from source. Jeremy, Thanks for pointing these problems out. I'll start working on getting a SNAPSHOT... A few comments: TimerManager.isSuspended(), isSuspending(), waitForStop(), and waitForSuspend() look correct to me. The javadoc for TimerManager.suspend() gives mixed messages. I'm going to keep the "suspend() throws IllegalStateException" for now... Let me know if you have evidence as to what it should be. Your WorkCompletedException used a few Java 5 methods, I backed it down so it will build under 1.4. --kevan
[jira] Created: (GERONIMO-2179) fix signature problems in the commonj specs
fix signature problems in the commonj specs --- Key: GERONIMO-2179 URL: http://issues.apache.org/jira/browse/GERONIMO-2179 Project: Geronimo Type: Bug Security: public (Regular issues) Components: specs Reporter: Kevan Miller As reported by Jeremy Boynes, the commonj specs has multiple signature problems (mostly missing exceptions). -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Project M2 POM for Geronimo
FYI, I implemented what I had described before on this branch: https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/ m2migration/ Using this branch/project for the shared configuration: https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/genesis/ --jason On Jul 9, 2006, at 9:30 AM, Alan D. Cabrera wrote: At the moment we have a root POM that contains lots of version information. I propose that we have a root POM that is insensitive to version releases and just contains project information like mailing lists, etc. This root POM could then be shared by specs and the regular geronimo root as well as anything else we decide to spin off into its own SVN root. Thoughts? Regards, Alan
Re: A few tests need some help
FYI, looks like rev #420384 should be solid to `bootstrap` off of the
svkmerge/m2migration branch.
I found the problem with commons-logging not getting picked up.
Looks like there maybe a little bug in m2 w/how it handles
. I've fixed the problem, but should eventually follow
up with the maven folks to see how to fix the problem.
Anyways, the only failures that I have seen so far with this branch
+rev are transient remote repository failures ("Error transferring
file", etc)... all problems which re-running the build fixes...
assuming that you can reach the remote repository.
Seems like http://repo1.maven.org/maven2... aka m2 central is down,
or unreachable from my local network... which basically means than no
online m2 builds will function.
Remote repositories that we don't have control over really, really,
really suck.
--jason
On Jul 9, 2006, at 3:14 PM, Jacek Laskowski wrote:
On 7/10/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
Note, svkmerge/m2migration is in a bit of flux at the moment...
results may vary.
It seems to be fine so far.
esis-1.0.0-SNAPSHOT.pom
[INFO]
[INFO]
[INFO]
--
--
[INFO] Reactor Summary:
[INFO]
--
--
[INFO] Genesis Configuration :: Clover ...
SUCCESS [48.094s]
[INFO] Genesis Configuration :: Checkstyle ...
SUCCESS [0.078s]
[INFO] Genesis ... SUCCESS
[2:41.047s]
[INFO]
--
--
[INFO]
--
--
[INFO] BUILD SUCCESSFUL
[INFO]
--
--
[INFO] Total time: 3 minutes 30 seconds
[INFO] Finished at: Mon Jul 10 00:12:36 CEST 2006
[INFO] Final Memory: 5M/254M
[INFO]
--
--
Ping me if you run into anything.
Will do, but don't know how long I'll stay awake ;-)
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Geronimo Eclipse Plugin FAQ
I've started a eclipse plugin FAQ at http://cwiki.apache.org/confluence/display/GMOxDOC11/Geronimo+Eclipse +Plugin+FAQ
[jira] Updated: (GERONIMO-1384) Provide default security realm for web-apps with secured pages deployed without a plan
[ http://issues.apache.org/jira/browse/GERONIMO-1384?page=all ] David Jencks updated GERONIMO-1384: --- Summary: Provide default security realm for web-apps with secured pages deployed without a plan (was: Web app with no Geronimo plan makes all secure pages insecure) type: New Feature (was: Bug) Fix Version: Wish List (was: 1.1.1) Priority: Minor (was: Trivial) Changed subject, target version since the original problem is fixed and perhaps the goal of having a default security realm could be debated. > Provide default security realm for web-apps with secured pages deployed > without a plan > -- > > Key: GERONIMO-1384 > URL: http://issues.apache.org/jira/browse/GERONIMO-1384 > Project: Geronimo > Type: New Feature > Security: public(Regular issues) > Components: security, web > Versions: 1.0-M5 > Reporter: Aaron Mulder > Priority: Minor > Fix For: Wish List > Attachments: security-reject.patch > > If you deploy a web application with certain pages/URLs protected by a login, > but you don't include a Geronimo deployment plan, all those pages/URLs are > unprotected. To replicate: > Deploy this with no plan: > http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap-demo-1.0-SNAPSHOT.war > and then visit http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and > click the links to "secure" and "forbidden". Both links work, with no login > prompt. Instead, you should get a login prompt and (since no realm was > configured) all logins should fail. > The web.xml in this case contains: > > > Admin Role > /protect/* > > > content-administrator > > > > > > No Access > /forbidden/* > > > > > FORM > MYREALM > > /auth/logon.html?param=test > /auth/logonError.html?param=test > > > > content-administrator > -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2125) Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path
[ http://issues.apache.org/jira/browse/GERONIMO-2125?page=all ] David Jencks updated GERONIMO-2125: --- Attachment: manifestcp-itest-v2.jar ear-1.0-SNAPSHOT.ear I extended my example to include a base jar, jar2, that both the servlet and ejb require, and my example still seems to work fine. The "jar" jar has no manifest classpath, and the war and ejb jar include both jar and jar2 in their manifest classpath. So, I still can't reproduce the problem you are seeing. > Classpath entries in the web app archive META-INF/MANIFEST.MF are not added > to the wep app class path > - > > Key: GERONIMO-2125 > URL: http://issues.apache.org/jira/browse/GERONIMO-2125 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Environment: 1.1 release > Reporter: Mario Ruebsam > Assignee: David Jencks > Priority: Blocker > Fix For: 1.2, 1.1.1 > Attachments: ear-1.0-SNAPSHOT.ear, ear-1.0-SNAPSHOT.ear, > manifestcp-itest-v2.jar, manifestcp-itest.jar > > A working EAR for Geronimo 1.0 with this structure: > app.ear/ > app.jar > cpa.jar > found.jar > webclient.war > The util JARs are referenced from the webclient.war/META-INF/MANIFEST.MF > Class-Path: app.jar cpa.jar found.jar > Deployment of this EAR in G 1.1-rc1 result in ClassNotFoundExceptions because > of the missing classes in the JARs which are not found. > Putting the JARs into the webclient.war/WEB-INF/lib worked. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
On Jul 9, 2006, at 6:12 PM, Jacek Laskowski wrote:On 7/9/06, Sachin Patel <[EMAIL PROTECTED]> wrote: The following distributions of the Geronimo Eclipse plugin are readyto be voted on for final release. Since binding votes are needed,each PMC member if possible, please cast your vote within 72 hours. Why has the 72-hour vote period been set?No critical reason, just a time frame on when I'll upload the driver to the distribution size if no -1's have been casted. http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC4.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC4.zip What's the difference between them? The first one just unzips into your ECLIPSE_HOME. Once released, the second is the distribution that gets unzipped into the update manager site. The packaging is a little different. The second one can also be tested by unzipping anywhere on your filesystem and creating a "local" update site to it. The site.xml is not really needed to test it.Which one do I need to downloadand what are the steps to test it out? Just unpack to $ECLIPSE_HOMEdir? Just downloaded Eclipse 3.2 and am ready to give it a whirl.You can start with Eclipse 3.2 but will need to go to the update manager to add WTP and its requirements. Or you can download the WTP-all in one package. I'm working as-we speak on a eclipse-plugin FAQ for the wiki that will contain further detailed info. Jacek-- Jacek Laskowskihttp://www.laskowski.net.pl -sachin
Re: A few tests need some help
On 7/10/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Note, svkmerge/m2migration is in a bit of flux at the moment... results may vary. It seems to be fine so far. esis-1.0.0-SNAPSHOT.pom [INFO] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Genesis Configuration :: Clover ... SUCCESS [48.094s] [INFO] Genesis Configuration :: Checkstyle ... SUCCESS [0.078s] [INFO] Genesis ... SUCCESS [2:41.047s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 3 minutes 30 seconds [INFO] Finished at: Mon Jul 10 00:12:36 CEST 2006 [INFO] Final Memory: 5M/254M [INFO] Ping me if you run into anything. Will do, but don't know how long I'll stay awake ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
On 7/9/06, Sachin Patel <[EMAIL PROTECTED]> wrote: The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours. Why has the 72-hour vote period been set? http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse- plugin-1.1-deployable-RC4.zip http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse- plugin-1.1-updatesite-RC4.zip What's the difference between them? Which one do I need to download and what are the steps to test it out? Just unpack to $ECLIPSE_HOME dir? Just downloaded Eclipse 3.2 and am ready to give it a whirl. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: A few tests need some help
Note, svkmerge/m2migration is in a bit of flux at the moment... results may vary. Ping me if you run into anything. --jason On Jul 9, 2006, at 3:03 PM, Jacek Laskowski wrote: On 7/9/06, Jason Dillon <[EMAIL PROTECTED]> wrote: You should be able to just: ./bootstrap This should build all of the bits that are currently not available in any repo and then run the staged build in the proper order. Doing it now. Thanks! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2125) Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path
[ http://issues.apache.org/jira/browse/GERONIMO-2125?page=comments#action_12419936 ] Mario Ruebsam commented on GERONIMO-2125: - I analyzed my problem a bit further with your example. In 1.0 you could add one or more utility jars to the ear. If one of these files depend on another jar, you don't have to add a classpath entry into the manifest file of this utility jar. The entry must only exist in the war or the ejb-jar referencing the jar on top of the other utlity jars. In 1.1 it works only if every utility jar contain a classpath entry to the other used jar's. Extending your example with two new jars: web.war depends on tools.jar in the ear root, tools.jar depends on found.jar also in the ear root in 1.0 you need a classpath entry in web.war too tools.jar in 1.1 you need a classpath entry in web.war too tools.jar and an entry in tools.jar too found.jar If the new behaviour in 1.1 is correct (I'm not familiar with the spec), then it is difficult to include 3rd party jars which depend on each other but doesn't have a correct classpath entry. The only way then is to use the repository and dependecies or path the manifest in the 3rd party jars. > Classpath entries in the web app archive META-INF/MANIFEST.MF are not added > to the wep app class path > - > > Key: GERONIMO-2125 > URL: http://issues.apache.org/jira/browse/GERONIMO-2125 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Environment: 1.1 release > Reporter: Mario Ruebsam > Assignee: David Jencks > Priority: Blocker > Fix For: 1.2, 1.1.1 > Attachments: ear-1.0-SNAPSHOT.ear, manifestcp-itest.jar > > A working EAR for Geronimo 1.0 with this structure: > app.ear/ > app.jar > cpa.jar > found.jar > webclient.war > The util JARs are referenced from the webclient.war/META-INF/MANIFEST.MF > Class-Path: app.jar cpa.jar found.jar > Deployment of this EAR in G 1.1-rc1 result in ClassNotFoundExceptions because > of the missing classes in the JARs which are not found. > Putting the JARs into the webclient.war/WEB-INF/lib worked. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: A few tests need some help
On 7/9/06, Jason Dillon <[EMAIL PROTECTED]> wrote: You should be able to just: ./bootstrap This should build all of the bits that are currently not available in any repo and then run the staged build in the proper order. Doing it now. Thanks! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2168) NPE when deploying RAR
[
http://issues.apache.org/jira/browse/GERONIMO-2168?page=comments#action_12419934
]
Tim Howe commented on GERONIMO-2168:
Donald, thanks for your input.
I haven't yet. Currently I'm rebuilding Geronimo from source and adding
debugging statements. However if I can't quickly and obviously find the
problem I'll try that. Regardless, I'll update with the results.
Are your suggestions related to known issues or just an attempt to get rid of
possible trouble spots?
I thought I'd seen spaces in some of the names of sample applications, and
Geronimo seems to be escaping them properly. Where should they be removed
from? The deployment plan, ra.xml, or both?
As far as the version number, is Maven used for deployment as well? I thought
it was only used for building Geronimo itself. In fact, before beginning to
build from source, I didn't even have Maven installed.
> NPE when deploying RAR
> --
>
> Key: GERONIMO-2168
> URL: http://issues.apache.org/jira/browse/GERONIMO-2168
> Project: Geronimo
> Type: Bug
> Security: public(Regular issues)
> Versions: 1.1
> Environment: Solaris 9 (Sparc), Java 1.5.0_06 (also appears in 1.4.2_05)
> Reporter: Tim Howe
> Priority: Critical
>
> I've been using Geronimo 1.0, and now 1.1, as the app server for the
> development of a JCA connector for our proprietary EIS and generally
> been very happy with it.
> I've had no problem running servlets, deploying WARs, and the like.
> However, I've run into a problem deploying a RAR that I built. I view
> it as highly probably that there's a bug somewhere in my resource
> adapter, but it seems to be triggering a bug in Geronimo, which appears
> in both Java 1.4.2 and 1.5:
> {quote}
> {{23:52:38,091 ERROR [GBeanInstanceState] Error while starting; GBean is now
> in the FAILED state:
> abstractName="com.celebrityresorts/rcc/0/rar?J2EEApplication=null,JCAConnectionFactory=Celebrity%20Resorts%20RCC%20development%20instance,JCAResource=com.celebrityresorts/rcc/0/rar,ResourceAdapter=com.celebrityresorts/rcc/0/rar,ResourceAdapterModule=com.celebrityresorts/rcc/0/rar,j2eeType=JCAManagedConnectionFactory,name=Celebrity%20Resorts%20RCC%20development%20instance"
> java.lang.NullPointerException
> at java.io.PrintWriter.write(PrintWriter.java:401)
> at java.io.PrintWriter.print(PrintWriter.java:546)
> at java.io.PrintWriter.println(PrintWriter.java:683)
> at java.lang.Throwable.printStackTrace(Throwable.java:510)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.printException(GBeanInstance.java:1047)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:983)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526)
> 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:173)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292)
> 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:540)}}
> {quote}
> and so on. The only thing I can figure is that somehow the Exception
> getting thrown is null, but I can't see how, as it seems to stem from
> bq. {{throw new Exception("A reference has failed so construction can not
> complete");}}
> so I'm very confused. Of course it's also quite late for me and I may
> be reading the stack trace wrong.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Fwd: [Vote] Geronimo Eclipse Plugin v1.1.0
Resending to fix links.Begin forwarded message:From: Sachin Patel <[EMAIL PROTECTED]>Date: July 9, 2006 4:24:40 PM EDTTo: dev@geronimo.apache.orgSubject: [Vote] Geronimo Eclipse Plugin v1.1.0 The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC4.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC4.zipHere is my +1.- sachin -sachin
Re: A few tests need some help
I have not run the m1 build in a long time. I'm not sure if these tests fail under that build or not. --jason On Jul 9, 2006, at 9:26 AM, Alan D. Cabrera wrote: Jason Dillon wrote: I've reconfigured all modules to us the latest surefire plugin, and most tests work... except for a few exceptions: system/**/PluginInstallerTest.java security/**/LoginKerberosTest.java connector-builder/**/Connector15DCBTest.java mail/**/MailcapTest.java Each of these fail in someway that was not obvious to me why, so I configured these specific tests to be excluded. I've removed all of the maven.test.skip=true bits from poms and recommend that they never be re-added. IMO, the tests must always pass and they should be quick enough to run and thus not force people to disable them to run builds. All of this work is in this branch: https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/ m2migration/ I've given up on submitting patches for the moment, but I plan on creating an RTC issue when there is significant change to be applied back to trunk... and will provide a patch for clarity, but recommend that folks use this branch to test/validate on top of scanning the patch. I would appreciate some help in resoling why the above listed tests are failing. Do you know if these are failing in trunk under m1 as well? Regards, Alan
[Vote] Geronimo Eclipse Plugin v1.1.0
The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours. http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse- plugin-1.1-deployable-RC4.zip http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse- plugin-1.1-updatesite-RC4.zip Here is my +1. - sachin
Why do tests show Log4j debug?
Anyone know why (some) tests spit out Log4j debug messages like this: log4j: Parsing for [root] with value=[WARN, LOGFILE]. log4j: Level token is [WARN]. log4j: Category root set to WARN log4j: Parsing appender named "LOGFILE". log4j: Parsing layout options for "LOGFILE". log4j: Setting property [dateFormat] to [ISO8601]. log4j: Setting property [contextPrinting] to [true]. log4j: End of parsing for "LOGFILE". log4j: Setting property [maxBackupIndex] to [3]. log4j: Setting property [maxFileSize] to [10MB]. log4j: Setting property [file] to [scout.log]. log4j: setFile called: scout.log, true log4j: setFile ended log4j: Parsed "LOGFILE" options. log4j: Parsing for [org.apache.axis.enterprise] with value=[FATAL, CONSOLE]. log4j: Level token is [FATAL]. log4j: Category org.apache.axis.enterprise set to FATAL log4j: Parsing appender named "CONSOLE". log4j: Parsing layout options for "CONSOLE". log4j: Setting property [conversionPattern] to [- %m%n]. log4j: End of parsing for "CONSOLE". log4j: Setting property [threshold] to [INFO]. log4j: Parsed "CONSOLE" options. log4j: Handling log4j.additivity.org.apache.axis.enterprise=[null] log4j: Finished configuring. I think we should remove this... as it is cluttering up the test output with... IMO rather useless information. --jason
Re: A few tests need some help
You should be able to just: ./bootstrap This should build all of the bits that are currently not available in any repo and then run the staged build in the proper order. We need the OpenEJB jars built with m2, which is not yet published anywhere. TranQL used to be need to build OpenEJB, but there might be jars published for this now... need to check, but it does not hurt anything (except the time to wait) for this to build. Also, recently bootstrap also builds the new Genesis branch that contains shared build plugins, as none of these modules are published anywhere yet either. NOTE: Use of the bootstrap script is very temporary, and will be dropped once required dependencies are in repos. The build script, which simply runs the staged build in order is also temporary until Maven can handle building extentions in the same cycle in which they are used. --jason On Jul 9, 2006, at 2:24 AM, Jacek Laskowski wrote: On 7/8/06, Jason Dillon <[EMAIL PROTECTED]> wrote: All of this work is in this branch: https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/ m2migration/ How can I build the branch? What's the command sequence? Do I need to check out OpenEJB? If so, why? mvn bootstrap keeps failing for me because of OpenEJB not being checked out. If I don't do that step, the build fails with g-p-p not being found. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Project M2 POM for Geronimo
This is what I recommend... though from what I have tried so far, this root pom probably don't really be a root, but a child pom of a separate project and then uses as the parent of other projects root pom. I have started to setup a container project for build related modules called Genesis, currently under: https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/genesis/ This project has two major trees: config and plugins. The config modules are used to pull in common build configuration., and plugins are regular plugins and support modules for plugins for common G plugins. I recommend that we create a project-config module here, that defines the basic elements that will be shared by all Geronimo projects built with m2. I also recommend that we enumerate commonly used plugins and their versions here. I've run into problems before using RELEASE plugins when a new release is pushed out that breaks builds (configuration change or functionality change). This is also a good place to put the common release profiles with distro configuration as well as the basic site generation configuration, which all projects should ideally share. --jason On Jul 9, 2006, at 9:30 AM, Alan D. Cabrera wrote: At the moment we have a root POM that contains lots of version information. I propose that we have a root POM that is insensitive to version releases and just contains project information like mailing lists, etc. This root POM could then be shared by specs and the regular geronimo root as well as anything else we decide to spin off into its own SVN root. Thoughts? Regards, Alan
Re: [jira] Updated: (TUSCANY-527) First cut of the work scheduler implementation
On Jul 9, 2006, at 11:08 AM, Jeremy Boynes wrote: On Jul 9, 2006, at 9:16 AM, David Jencks wrote: There's a geronimo version of the commonj spec at org.apache.geronimo.specs:geronimo-commonj_1.1_spec:1.0:jar at ibiblio. I'm not entirely sure what auspices this was published under since geronimo doesn't have a tck for commonj. If there are any problems with this jar please speak up on the geronimo dev list. Thanks David, I'll use that for now. There is also a version in the Apache WebServices WSRF project but they don't seem to have published it. I found a couple of problems in Geronimo's version with the signatures (e.g. exceptions missing). I modified the Geronimo source to match the spec javadoc I downloaded and it seems to compile now. Attached is a patch for geronimo-spec (from https://svn.apache.org/ repos/asf/geronimo/specs/trunk) geronimo-commonj.patch Description: Binary data This bumps the commonj spec jar version to 1.0.1-SNAPSHOT - hope that's the right version. Dave, if this works for you can you get a snapshot version uploaded so that Tuscany folk won't have to build from source. Thanks -- Jeremy
[jira] Erstellt: (GERONIMO-2178) JSP Taglibs accessed via a global context
JSP Taglibs accessed via a global context - Key: GERONIMO-2178 URL: http://issues.apache.org/jira/browse/GERONIMO-2178 Project: Geronimo Type: Wish Security: public (Regular issues) Components: Tomcat Versions: Wish List Environment: all geronimo platforms Reporter: D. Strauss Priority: Minor First: this is a wish, not a bug :P When developing webpages with JSP a usual JSP hacker will face the easiness of taglibs one day. Taglibs are a summary of JSP tags that someone has created one day to ease the development of JSP pages. My wish: Geronimo may contain some standard taglibs. A famous example: the Jakarta Taglib. For now, I must ship that library with all my WAR files. Instead, Geronimo may have that library and give me access to its tags. This can be done using the 1.1 dependency system. In a usual JSP page I simply may refer to that lib using the uri of that lib (the JSTL uri is already standardized). So, it would mean a smaller size of WAR files :P However, I don't know if this is JEE compatible or not :/ it's just an idea. Post your opinion about this. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo/Equinox integration status?
toby cabot wrote: Hi folks, What's the status of the Geronimo/Equinox (OSGi server) integration? I see some list traffic from last year that looks pretty hopeful[1][2] but a cursory look at the code doesn't reveal any hooks yet. I could have easily missed it, though. If anyone's got any updates I'd appreciate it. I'm going to have to run both Equinox and Geronimo in a single machine so I'd rather have them integrated than not. Thanks, Toby ps. Implicit in the above request is an offer to help ;) [1] http://mail-archives.apache.org/mod_mbox/geronimo-dev/200510.mbox/[EMAIL PROTECTED] [2] http://dev.eclipse.org/newslists/news.eclipse.technology.ohf/msg00078.html XBean is built on Spring and Spring is coming out w/ OSGi support. Dain has some other XBean <-> OSGi stuff in the oven as well. So, I would say that yes, Geronimo booting inside an OSGi kernel is a real possibility. Regards, Alan
Re: Tag 1.1 issue?
David Jencks wrote: On Jul 8, 2006, at 2:08 PM, David Blevins wrote: On Jul 8, 2006, at 2:54 AM, Bruce Snyder wrote: On 7/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote: I still believe there is value getting the state of OpenEJB at tagged level and accessing it with m:co. Here is an example... I am trying to research some classloading issues regarding OpenEJB and Geronimo 1.1. It behooves me to have source level access to both OpenEJB and Geronimo for the state of the Geronimo 1.1 release so I can accurately debug the problem. It would be nice to have the m:co checkout the tagged version of OpenEJB since we are not really supposed to have any snapshots in there. I'll do you one even better, Jeff ... I've just discovered that geronimo/tags/1.1.0 depends on openejb 2.1 branch which depends on geronimo-1.1.1-SNAPSHOT. Right, geronimo-1.1-SNAPSHOT (not 1.1.1-SNAPSHOT). This means that any user with a clean environment who is interested in building Geronimo 1.1 from source and somehow figures out that Geronimo 1.1resides in geronimo/tags/1.1.0 and follows the bulid instructions on the wiki will wind up with the following error: I'm fine documenting this as long as it's made completely clear it isn't at all necessary. One can build Geronimo just fine when skipping the optional 'm:co' step. Those are missing deps on Geronimo 1.1.1 while building Geronimo 1.1. In other words, geronimo/tags/1.1.0 is permanently broken. IMO, this issue is worse than we originally thought. Not that I don't agree it's a screwed up situation, but geronimo/tags/1.1.0 is perfectly fine -- building openejb is optional. It's openejb/tags/v2_1/ that's permanently broken. In fact all the openejb 2x tags are broken in exactly the same way. All openejb 2.x releases are cut before Geronimo releases so a given Geronimo release doesn't have to have a snapshot dependency on openejb. To fix this issue, I changed m:checkout to grab the openejb 2.1 tag. Then I changed the geronimo_version in my local copy of the openejb 2.1 tag from 1.1-SNAPSHOT to 1.1. After this, Geronimo 1.1 built successfully for me. At a minimum this solution should be documented in the appropriate locations. Maximally, we should consider fixing 1.1. What would you recommend? I think that we need to release like this: geronimo jars (and possibly non-openejb configs) (possibly also non-openejb assemblies such as minimal) openejb jars (and possibly openejb configs) other configs ( perhaps these should all be independently released plugins) assemblies. I don't think we can realistically do this on the 1.1/2.1 branches but it might be a realistic goal for 1.2/2.2 Do you think that things could be simplified if we broke up Geronimo into separate "product lines" instead of having a trunk that's a big bucket-o-stuff? Regards, Alan
Re: Geronimo specs pre-RTC
Jacek Laskowski wrote: On 7/6/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I had an "ah ha" experience after my fourth beer, before my third hamburger, yesterday. One word, branch. I'll cook something up in geronimo/specs/branch. I'll include Jason's suggestions. Yeah, it happened to me as well, but it was way faster than after the proverbial fourth beer - I couldn't survive after the second not mentioning the following ones ;-) May I read it as you being a not-yet-but-soon proponent of using branches before a commit to trunk with RTC? That would be great to hear a friendly soul nearby. ;-) I think that branches are great for RTC. I think that the case for m2 conversion is uniquely different. Regards, Alan
Project M2 POM for Geronimo
At the moment we have a root POM that contains lots of version information. I propose that we have a root POM that is insensitive to version releases and just contains project information like mailing lists, etc. This root POM could then be shared by specs and the regular geronimo root as well as anything else we decide to spin off into its own SVN root. Thoughts? Regards, Alan
Re: A few tests need some help
Jason Dillon wrote: I've reconfigured all modules to us the latest surefire plugin, and most tests work... except for a few exceptions: system/**/PluginInstallerTest.java security/**/LoginKerberosTest.java connector-builder/**/Connector15DCBTest.java mail/**/MailcapTest.java Each of these fail in someway that was not obvious to me why, so I configured these specific tests to be excluded. I've removed all of the maven.test.skip=true bits from poms and recommend that they never be re-added. IMO, the tests must always pass and they should be quick enough to run and thus not force people to disable them to run builds. All of this work is in this branch: https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/m2migration/ I've given up on submitting patches for the moment, but I plan on creating an RTC issue when there is significant change to be applied back to trunk... and will provide a patch for clarity, but recommend that folks use this branch to test/validate on top of scanning the patch. I would appreciate some help in resoling why the above listed tests are failing. Do you know if these are failing in trunk under m1 as well? Regards, Alan
[jira] Commented: (GERONIMO-2173) Fix branches/1.1 (1.1.1-SNAPSHOT) build
[ http://issues.apache.org/jira/browse/GERONIMO-2173?page=comments#action_12419918 ] Kevan Miller commented on GERONIMO-2173: Yes. geronimo/trunk has already been moved to 1.2-SNAPSHOT. This change was finishing the move to 1.1.1-SNAPSHOT (there were no corresponding changes needed in trunk). > Fix branches/1.1 (1.1.1-SNAPSHOT) build > --- > > Key: GERONIMO-2173 > URL: http://issues.apache.org/jira/browse/GERONIMO-2173 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: buildsystem > Versions: 1.1.1 > Reporter: Kevan Miller > Assignee: Kevan Miller > Fix For: 1.1.1 > > Multiple dependencies need to be fixed for 1.1.1-SNAPSHOT build... -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Geronimo v1.1.1 issues
There are many issues that are slated for v1.1.1 that have not also been slated for v1.2. I wonder if this is by design since I think that there are few issues that one would want to fix for v1.1.x that would not also go into future releases, i.e. v1.2. Regards, Alan
[jira] Commented: (GERONIMO-2173) Fix branches/1.1 (1.1.1-SNAPSHOT) build
[ http://issues.apache.org/jira/browse/GERONIMO-2173?page=comments#action_12419914 ] Alan Cabrera commented on GERONIMO-2173: Is there any reason why you didn't also fix geronimo/trunk? > Fix branches/1.1 (1.1.1-SNAPSHOT) build > --- > > Key: GERONIMO-2173 > URL: http://issues.apache.org/jira/browse/GERONIMO-2173 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: buildsystem > Versions: 1.1.1 > Reporter: Kevan Miller > Assignee: Kevan Miller > Fix For: 1.1.1 > > Multiple dependencies need to be fixed for 1.1.1-SNAPSHOT build... -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo v1.1.1 release
Jacek Laskowski wrote: On 7/8/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > Who's a release manager/coordinator? Alan? Congrats! ;-) Sure. I'll be happy to help. Do we know what the release will contain? Version upgrades only? I imagine what ever people have time to put into this micro release. Regard,s Alan
Re: Tag 1.1 issue?
On 7/8/06, David Blevins <[EMAIL PROTECTED]> wrote:
On Jul 8, 2006, at 2:54 AM, Bruce Snyder wrote:
> On 7/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
>
>> I still believe there is value getting the state of OpenEJB at tagged
>> level and accessing it with m:co. Here is an example...
>>
>> I am trying to research some classloading issues regarding OpenEJB
>> and
>> Geronimo 1.1. It behooves me to have source level access to both
>> OpenEJB and Geronimo for the state of the Geronimo 1.1 release so
>> I can
>> accurately debug the problem. It would be nice to have the m:co
>> checkout the tagged version of OpenEJB since we are not really
>> supposed
>> to have any snapshots in there.
>
> I'll do you one even better, Jeff ...
>
> I've just discovered that geronimo/tags/1.1.0 depends on openejb 2.1
> branch which depends on geronimo-1.1.1-SNAPSHOT.
Right, geronimo-1.1-SNAPSHOT (not 1.1.1-SNAPSHOT).
> This means that any
> user with a clean environment who is interested in building Geronimo
> 1.1 from source and somehow figures out that Geronimo 1.1resides in
> geronimo/tags/1.1.0 and follows the bulid instructions on the wiki
> will wind up with the following error:
I'm fine documenting this as long as it's made completely clear it
isn't at all necessary. One can build Geronimo just fine when
skipping the optional 'm:co' step.
My apologies, I stand corrected.
> Those are missing deps on Geronimo 1.1.1 while building Geronimo 1.1.
> In other words, geronimo/tags/1.1.0 is permanently broken. IMO, this
> issue is worse than we originally thought.
Not that I don't agree it's a screwed up situation, but geronimo/tags/
1.1.0 is perfectly fine -- building openejb is optional. It's
openejb/tags/v2_1/ that's permanently broken. In fact all the
openejb 2x tags are broken in exactly the same way. All openejb 2.x
releases are cut before Geronimo releases so a given Geronimo release
doesn't have to have a snapshot dependency on openejb.
> To fix this issue, I changed m:checkout to grab the openejb 2.1 tag.
> Then I changed the geronimo_version in my local copy of the openejb
> 2.1 tag from 1.1-SNAPSHOT to 1.1. After this, Geronimo 1.1 built
> successfully for me.
>
> At a minimum this solution should be documented in the appropriate
> locations. Maximally, we should consider fixing 1.1.
What would you recommend?
Documented the issue with m:co on tags/1.1.0 is all that is needed.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: A few tests need some help
On 7/8/06, Jason Dillon <[EMAIL PROTECTED]> wrote: All of this work is in this branch: https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/ m2migration/ How can I build the branch? What's the command sequence? Do I need to check out OpenEJB? If so, why? mvn bootstrap keeps failing for me because of OpenEJB not being checked out. If I don't do that step, the build fails with g-p-p not being found. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Tag 1.1 issue?
On Jul 8, 2006, at 2:08 PM, David Blevins wrote: On Jul 8, 2006, at 2:54 AM, Bruce Snyder wrote: On 7/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote: I still believe there is value getting the state of OpenEJB at tagged level and accessing it with m:co. Here is an example... I am trying to research some classloading issues regarding OpenEJB and Geronimo 1.1. It behooves me to have source level access to both OpenEJB and Geronimo for the state of the Geronimo 1.1 release so I can accurately debug the problem. It would be nice to have the m:co checkout the tagged version of OpenEJB since we are not really supposed to have any snapshots in there. I'll do you one even better, Jeff ... I've just discovered that geronimo/tags/1.1.0 depends on openejb 2.1 branch which depends on geronimo-1.1.1-SNAPSHOT. Right, geronimo-1.1-SNAPSHOT (not 1.1.1-SNAPSHOT). This means that any user with a clean environment who is interested in building Geronimo 1.1 from source and somehow figures out that Geronimo 1.1resides in geronimo/tags/1.1.0 and follows the bulid instructions on the wiki will wind up with the following error: I'm fine documenting this as long as it's made completely clear it isn't at all necessary. One can build Geronimo just fine when skipping the optional 'm:co' step. Those are missing deps on Geronimo 1.1.1 while building Geronimo 1.1. In other words, geronimo/tags/1.1.0 is permanently broken. IMO, this issue is worse than we originally thought. Not that I don't agree it's a screwed up situation, but geronimo/ tags/1.1.0 is perfectly fine -- building openejb is optional. It's openejb/tags/v2_1/ that's permanently broken. In fact all the openejb 2x tags are broken in exactly the same way. All openejb 2.x releases are cut before Geronimo releases so a given Geronimo release doesn't have to have a snapshot dependency on openejb. To fix this issue, I changed m:checkout to grab the openejb 2.1 tag. Then I changed the geronimo_version in my local copy of the openejb 2.1 tag from 1.1-SNAPSHOT to 1.1. After this, Geronimo 1.1 built successfully for me. At a minimum this solution should be documented in the appropriate locations. Maximally, we should consider fixing 1.1. What would you recommend? I think that we need to release like this: geronimo jars (and possibly non-openejb configs) (possibly also non- openejb assemblies such as minimal) openejb jars (and possibly openejb configs) other configs ( perhaps these should all be independently released plugins) assemblies. I don't think we can realistically do this on the 1.1/2.1 branches but it might be a realistic goal for 1.2/2.2 thanks david jencks -David
