Re: Consolidating the community
I think it's a good idea, but I'm curious - what changed your mind? We've been talking about this on and off for a while now, and I know that you were dead-set against it. On Oct 29, 2005, at 1:46 PM, Dain Sundstrom wrote: Why not consolidate the entire Geronimo community, or as much as possible, into the Geronimo project itself? I bounced this idea off a few people and the feedback I got was very positive. This idea keeps popping up and before it gets to far along I want to bring it to the dev list. One thing you should really think about is this requires a big commitment from the Geronimo community. There are a lot of projects, code and committers that we will need to integrate into our community. Most of the projects will have to go through incubation, which as you all know is not easy. On the positive side, we already work closely with these projects, and are very familiar with the communities and code. As you can tell, I'm very excited about this. What do you think? Who would want to come? -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: TCCL in doStart
+1 from me to clean up the rest. thanks, dims On 10/29/05, Dain Sundstrom [EMAIL PROTECTED] wrote: On Oct 29, 2005, at 11:57 AM, David Jencks wrote: On Oct 29, 2005, at 11:51 AM, Dain Sundstrom wrote: Setting the TCCL around lifecycle methods is one of the changes I made in XBean. It turns out that there is a lot of code out there that assumes the TCCL is properly set, so instead of requiring everyone to write a wrapper class, I just set it. The reason we removed most of the TCCL setting code from Geronimo was because it was a major performance impact. I just think we went a little to far :) The life cycle methods are rarely called and don't happen in code paths where performance is critical. I think we should change the GBeanInstance code to set the TCCL around doStart and doStop. What do you think? Fine with me. Do you agree that setting the TCCL while deserializing attribute values is unnecessary? I think the ObjectInputStreamEx handles all of our cases with an explicit class loader, but we may want to leave the code there in case a readObject or readReplace implementation tries to get the TCCL. So I think it is unnecessary, but I see no harm is just leaving that one there. -dain -- Davanum Srinivas : http://wso2.com/blogs/
Re: Can we have an IRC Bot mail the chat logs: was Weekly confrence call - thoughts
Cool, I wonder how hard it would be to get Drone to auto email the logs to the dev list? Regards, Hiram On Oct 29, 2005, at 6:46 PM, Dain Sundstrom wrote: We have been logging the chats for a while here: http://servlet.uwyn.com/drone/log/bevinbot/geronimo There is a link on our website, but it is not in an obvious location: http://geronimo.apache.org/get-involved.html -dain On Oct 29, 2005, at 12:33 PM, Bruce Snyder wrote: On 10/29/05, Hiram Chirino [EMAIL PROTECTED] wrote: As tangent on the Weekly conference call thought, I was thinking it might be nice if we had a IRC bot that would mail the dev list with periodic log of the IRC conversations. That way folks on the mailing list could stay up to date with any conversations on IRC. Do you folks think this would be a nice feature to have? I think it would certainly make it more OK to have the IRC conversations that are already taking place. :) Yet another wonderful idea! Geez, what's everybody on today? Can I have some? ;-) I think offering an IRC log from the website using Drone or something similar would be great. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED \!G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
[jira] Resolved: (GERONIMO-477) Deployer should not auto-connect if not asked to
[ http://issues.apache.org/jira/browse/GERONIMO-477?page=all ] Aaron Mulder resolved GERONIMO-477: --- Resolution: Fixed Added --offline flag. The tool will not attempt to connect to a running server if --offline is specified, and it will not fall back to the offline behavior if --offline is not specified. Revision 329596. Deployer should not auto-connect if not asked to Key: GERONIMO-477 URL: http://issues.apache.org/jira/browse/GERONIMO-477 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M4 Reporter: Jeremy Boynes Assignee: Aaron Mulder Fix For: 1.0 Before dropping back to offline mode, the new deployer tries to auto-connect to a server running on the local machine. Since this feature was added I have run into a problem where it is connecting to the wrong server. For example, the Geronimo build will just hang during assembly if there is another server running in the background. There has been talk about splitting the online and offline functions into two tools; if this is done I don't think this will continue to be an issue as the online one could try and connect but the offline one which is used during the build won't. If we stick with one tool them I think we should add a --offline option that stops the deployer from trying to connect. It seems to me that one tool approach is getting confusing. -- 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] Created: (GERONIMO-1119) Web apps should know what container they're in
Web apps should know what container they're in -- Key: GERONIMO-1119 URL: http://issues.apache.org/jira/browse/GERONIMO-1119 Project: Geronimo Type: Improvement Components: management Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.0 In order for certain console output to work correctly (both CLI console and web console) we need to know which web container is hosting a particular web app. -- 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] Closed: (GERONIMO-1119) Web apps should know what container they're in
[ http://issues.apache.org/jira/browse/GERONIMO-1119?page=all ] Aaron Mulder closed GERONIMO-1119: -- Resolution: Fixed Assign To: Aaron Mulder Revision 329605 Web apps should know what container they're in -- Key: GERONIMO-1119 URL: http://issues.apache.org/jira/browse/GERONIMO-1119 Project: Geronimo Type: Improvement Components: management Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Fix For: 1.0 In order for certain console output to work correctly (both CLI console and web console) we need to know which web container is hosting a particular web app. -- 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 specs break out
On Oct 28, 2005, at 12:59 AM, David Jencks wrote: +1 I think the spec version should be part of the artifactId and then we need a version as well, e.g. artifactIdservlet-2.4/artifactId versionIdrc4/versionId I think we should talk to all the other apache projects with specs and make an apache specs project that we all use. +1 Jacek
Re: Weekly conference call - thoughts
Fair enough...I'm travelling this week and will be spotty on my own e-mail. I'll let it bake and do some research in the interim. I understand the issue of excluding folks and the idea of the call was definitely no intended to do that. The nice thing is we have people all over the world doing development and that is one huge drawback of conference calls. Let's see what bakes :) Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote: Ok, I give. I personally hate typing and was looking for an alternative for folks. Sounds like there is moderate interest and strong disdain so I'll withdraw the proposal. Something I meant to mention earlier but forgot: don't be hasty! The proposal's only been on the list for 24 hours; give it a couple of days. The canonical interval is three days to let people catch up, come home, or whatever. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ2QHOZrNPMCpn3XdAQI9yQP/czXfUZ1M3TBYYnOBTJflfEWU6T88ntBR EH5r/iySdTs8hm4uXyVfxBuDubt0ZAzkDDP5Qkez2q6uBHLwvGqqFpuHc1JbNaeF 0x1wnlKd4Zcu6uqoyKtp5zp92VF4o30NZanG28Rj7SWPk9CyzJujum+xIW6Lu8vV QehLIr2zVmw= =F3VB -END PGP SIGNATURE-
[jira] Updated: (GERONIMO-973) Add security to /console-standard
[ http://issues.apache.org/jira/browse/GERONIMO-973?page=all ] Aaron Mulder updated GERONIMO-973: -- Priority: Blocker (was: Major) Can't release with no security on core admin console functionality Add security to /console-standard - Key: GERONIMO-973 URL: http://issues.apache.org/jira/browse/GERONIMO-973 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.0 Currently there are no web app security settings on /console-standard. Either security needs to be added to it, or if that proves to be impossible, it needs to be rolled into a single web app with /console -- 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] Resolved: (GERONIMO-1032) Deploy reports an improper port number for a newly deployed web app
[ http://issues.apache.org/jira/browse/GERONIMO-1032?page=all ] Aaron Mulder resolved GERONIMO-1032: Fix Version: 1.0 Resolution: Fixed Assign To: Aaron Mulder Revision 329699 Deploy reports an improper port number for a newly deployed web app --- Key: GERONIMO-1032 URL: http://issues.apache.org/jira/browse/GERONIMO-1032 Project: Geronimo Type: Bug Components: deployment Versions: 1.0 Environment: Windows XP Reporter: Kevan Miller Assignee: Aaron Mulder Priority: Minor Fix For: 1.0 I ran maven tomcat to create a Tomcat-default web container configuration. When I deploy Struts applications, deploy helpfully reports the url of the deployed application. However, the reported url is incorrect. It seems that the Jetty port number is being used instead of the Tomcat port number. For example: %JAVA_HOME%\bin\java.exe -jar %GERONIMO_HOME%\bin\deployer.jar --user system --password manager deploy struts-documentation.war Deployed struts-documentation @ http://coltrane:8090/struts-documentation In fact, struts-documentation is available on port 8080. -- 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-web.xml, container-config, container-specific namespaces
David J, I thought when you added the separate Tomcat and Jetty namespaces, you were going to remove the container-config section from the generic geronimo-web.xml, but it seems that it's still there. Jeff thinks maybe it's for something like the console, where we want it to work in both Tomcat and Jetty yet we might still require some container-specific extensions (makes sense to me). If we're going to keep the generic geronimo-web.xml and keep the container-config section in it, can we drop the container-specific namespaces? I think you favored the namespaces because if you use a container-specific namespace then any container-specific settings could be validated in XML, but I think that's pretty useless if it only applies if you're willing to force your app to only deploy in one container or the other. (That is to say, if you want your web app to run in either Tomcat or Jetty -- which is probably the normal case, then you can't use a container-specific namespace so it doesn't matter what the benefits of container-specific namespaces are.) The only way I can see the container-specific namespaces being beneficial is if the container-config became an any and then we namespaced the content that went within it -- so the overall file always used the generic namespace but then you used a container-specific one for the contents of the container-config element only. Am I missing something? Thanks, Aaron
Remote Deployment
So I think the strategy for remote deployment is to create a servlet to accept file uploads, so we can stream the application/module archive to the servlet and it will save it to the server filesystem, and then we can issue the normal commands where the server expects the files to be on the local filesystem. The only question then is how the deploy tool should locate the servlet. We now have the capability to construct an accurate URL to a web application (no matter how many containers are running). I assume we'd put this servlet in the console web app for now, rather than create a whole new web app just for supporting remote deployment. Which makes the question, how can the server-side of the JSR-88 plumbing figure out which module contains the/a running console? I'm thinking of doing something cheesy, like adding an empty GBean to the console module, and then having the JSR-88 plumbing do a gbean query to locate that GBean, then from there use the dependency manager to figure out what Configuration it's in, and use that to find the web module and construct the URL. Anyone have a better idea? Thanks, Aaron
[jira] Updated: (GERONIMO-804) Redeploy should calculate ModuleID to replace if not provided
[ http://issues.apache.org/jira/browse/GERONIMO-804?page=all ] Aaron Mulder updated GERONIMO-804: -- Component: deployment Assign To: Aaron Mulder Redeploy should calculate ModuleID to replace if not provided - Key: GERONIMO-804 URL: http://issues.apache.org/jira/browse/GERONIMO-804 Project: Geronimo Type: Improvement Components: deployment Versions: 1.0-M3 Reporter: Aaron Mulder Assignee: Aaron Mulder Fix For: 1.0 When you redeploy, it would be nice to pull the configId or archive name or whatever we usually do to generate the moduleID. That way if you redeploy the same archive, it would automatically know what ModuleIDs to replace, instead of you needing to specify them on the command line. Of course this may be a little tricky since the configId is on a different XML file for every module type... As a workaround, it would be possible for the deployer to remember the module IDs generated for the archive name used for each distribute or deploy operation, and prompt you based on that if you neglect to specify a module ID on the command line (Last time you deployed 'foo.war' it was called 'MyFooWebApp'. Replace 'MyFooWebApp' (Y/n)?) -- 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] Resolved: (GERONIMO-463) CLI Deployer doesn't give login prompt for non-Geronimo server
[ http://issues.apache.org/jira/browse/GERONIMO-463?page=all ] Aaron Mulder resolved GERONIMO-463: --- Resolution: Fixed Assign To: Aaron Mulder Revision 329716 CLI Deployer doesn't give login prompt for non-Geronimo server -- Key: GERONIMO-463 URL: http://issues.apache.org/jira/browse/GERONIMO-463 Project: Geronimo Type: Improvement Components: deployment Versions: 1.0-M3 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Minor Fix For: 1.0 The CLI tool only prompts the user for authentication if it detects a Geronimo authentication failure. It should detect when a non-Geronimo URI is being used, and prompt for authentication before attempting to connect (unless the info was provided on the command line). An argument could be made that it should always prompt (Geronimo or not), but then it would prompt even if it was ultimately going to fall back on operating in offline mode, which would be a little weird. -- 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] Created: (GERONIMO-1120) Auto-detect config ID for a deployable archive
Auto-detect config ID for a deployable archive -- Key: GERONIMO-1120 URL: http://issues.apache.org/jira/browse/GERONIMO-1120 Project: Geronimo Type: Improvement Components: deployment Versions: 1.0-M3 Reporter: Aaron Mulder Fix For: 1.0 Given an application/module/service archive, or an archive and a plan, we need a routine to pull out what the configuration name will be for it. In other words, we need to peek into the deployment plan and look for the configId attribute, the catch being that we don't know up front what the name of the plan file is if it's embedded in the JAR. This is necessary to be able to redeploy without explicitly naming the configuration to replace, which is necessary to do redeploy operations in a hot deploy directory. It seems like it'd be easy to write a bit of code to do this by hardcoding the locations of all known deployment types, but it would be a little more elegant if the deployers coughed up the required information and it could be handled on a more pluggable basis. -- 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: Consolidating the community
Hi John, On Oct 29, 2005, at 11:54 PM, John Sisson wrote: Sounds like a great idea. OpenEJB, TranQL, ActiveMQ would be great to have as part of the community. I noticed that Xbean was suggested. How is Xbean currently related to Geronimo? Is this the Spring based gbean.org project with a new name (www.gbean.org now takes me to the Codehaus main page)? If so, what are the pros and cons to moving to this? xbean is what activemq 4.x and servicemix 2.x are using for wiring up it's components. I think the the openejb folks are also jumping on and starting to use it too. Seems like Dan from xfire, has started to also drive requirements into so I guess xfire may start using it soon too. Does OSGi compete with/overlap Xbean functionality? If so is it premature to consider Xbean before we have considered OSGi? I've got a feeling it's complimentary. ActiveMQ and servicemix only uses xbean for configuration wiring. The one thing I'm keeping an eye on OSGi is for it's classpath/native library management (would come in handy for servicemix). Regards, Hiram I did a search for xbean on the Geronimo dev mailing list and haven't found anything, except for references to XMLBeans. XMLBeans jars are named xbean-2.x.x AFAIK. Thanks, John Dain Sundstrom wrote: Why not consolidate the entire Geronimo community, or as much as possible, into the Geronimo project itself? I bounced this idea off a few people and the feedback I got was very positive. This idea keeps popping up and before it gets to far along I want to bring it to the dev list. One thing you should really think about is this requires a big commitment from the Geronimo community. There are a lot of projects, code and committers that we will need to integrate into our community. Most of the projects will have to go through incubation, which as you all know is not easy. On the positive side, we already work closely with these projects, and are very familiar with the communities and code. As you can tell, I'm very excited about this. What do you think? Who would want to come? -dain
Re: Remote Deployment
Are you referring to the situation when multiple Web Containers are running in the server and the console is running in only one of them? Is this a scenario that you've seen users requesting? I think more than one web container in a user deployment (apart from server development) is an unlikely scenario. I'm open to it but I haven't seen any demand for it so I'm trying to understand the demand. thanks. Matt Aaron Mulder wrote: So I think the strategy for remote deployment is to create a servlet to accept file uploads, so we can stream the application/module archive to the servlet and it will save it to the server filesystem, and then we can issue the normal commands where the server expects the files to be on the local filesystem. The only question then is how the deploy tool should locate the servlet. We now have the capability to construct an accurate URL to a web application (no matter how many containers are running). I assume we'd put this servlet in the console web app for now, rather than create a whole new web app just for supporting remote deployment. Which makes the question, how can the server-side of the JSR-88 plumbing figure out which module contains the/a running console? I'm thinking of doing something cheesy, like adding an empty GBean to the console module, and then having the JSR-88 plumbing do a gbean query to locate that GBean, then from there use the dependency manager to figure out what Configuration it's in, and use that to find the web module and construct the URL. Anyone have a better idea? Thanks, Aaron
[jira] Updated: (GERONIMO-1118) memory leak deploying web services caused by java.bean.Introspector.getBeanInfo()
[ http://issues.apache.org/jira/browse/GERONIMO-1118?page=all ] Kevan Miller updated GERONIMO-1118: --- Attachment: IntrospectorFix.patch Thanks Dain. Works great. Attached fix calls Introspector.flushCaches() during destroy. We could make this behavior configurable. Default to call flushCaches(), but allow this behavior to be inhibited. I just don't see much reason to add the complexity. I don't think there's much caching going on... Unfortunately, we're not out-of-the-woods, yet. We're freeing up some of our MultiParentClassLoaders, but not all. We're currently holding on to 2 class loaders per deploy/undeploy cycle. Current culprits are: Axis -- o.a.a.utils.JavaUtils.enumMap is a HashMap which is holding onto some Classes. Looks like making this a WeakHashMap would fix the problem. Axis -- o.a.a.utils.TypeDesc (looks like this was fixed by Axis between 1.3_Snapshot and 1.3. I'll be confirming...) Geronimo -- o.a.g.connector.outbound.TCCLInterceptor is being maintained in a list of ConnectionInterceptors. Need to figure out when it should be removed from the list... I'll be working on addressing the above problems in separate Jira issues. memory leak deploying web services caused by java.bean.Introspector.getBeanInfo() - Key: GERONIMO-1118 URL: http://issues.apache.org/jira/browse/GERONIMO-1118 Project: Geronimo Type: Bug Components: webservices Versions: 1.0 Environment: Sun JDK 1.4.2/Win XP Reporter: Kevan Miller Attachments: IntrospectorFix.patch If you deploy and undeploy DayTrader several times, your server will run out of Permanent Generation space. I've tracked down a problem which is caused by java.bean.Introspector (there may be other problems, but it's hard to tell until this problem is fixed). The basic problem is described here -- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5102804. To summarize, the static method java.bean.Introspector.getBeanInfo(Class) computes a BeanInfo object to describe the given Class. The computed BeanInfo data is cached in a WeakHashMap called beanInfoCache. There's one fatal flaw in this approach. There's nothing weak at all about beanInfoCache. The key for the Map is the Class object. The value object is the BeanInfo data. Unfortunately, the BeanInfo data strongly references the Class. This strong reference will prevent the Class from being identified as available for GC via the WeakHashMap. Since java.bean.Introspector is loaded by the system class loader (and is thus a GC root), this means that Bean classes (e.g. org.apache.geronimo.samples.daytrader.client.ws.AccountDataBean), their MultiParentClassLoader, and all classes loaded by the MultiParentClassLoader will be kept alive until you kill your server... Luckily (or because of this problem?), Introspector also has flushCaches() and flushFromCaches(Class) methods which perform predictable functions. Several projects, including Tomcat and Spring, use these methods to prevent Introspector from causing memory leaks in their environments. Geronimo has the following usages of getBeanInfo() axis-builder/src/java/org/apache/geronimo/axis/builder/HeavyweightTypeInfoBuilder.java:389 axis-builder/src/java/org/apache/geronimo/axis/builder/LightweightTypeInfoBuilder.java:131 service-builder/src/java/org/apache/geronimo/deployment/service/JavaBeanXmlAttributeBuilder.java:66 A non-scientific search (e.g. I don't have all the source), showed calls to Introspector.getBeanInfo() by the following projects: axis, cglib, commons-collections, tomcat (but calls flushCache), log4j I've thought of the following options for fixing this problem (alternative proposals welcome): 1. Follow all calls to getBeanInfo(Class) with a flushFromCaches(Class). This seems fragile and impractical (we can't insure that other projects/apps follow this rule). 2. Force java.Bean.Introspector to be loaded by MultiParentClassLoader. This would prevent the Introspector class from being a GC root. Would work, but is counter to the current class loader implementation... 3. Call Introspector.flushCaches() at appropriate times (i.e. when a ClassLoader is going out of scope -- when a GBean is stopped?). I need a little help here in knowing when/where this should be... Although this is a bit heavy-handed, it seems like a safe approach. 4. (just thought of this one). Instead of calling flushCaches() as described in 3, we could instead loop through all classes loaded by the appropriate MultiParentClassLoaders and call flushFromCaches(Class) (or a subset of the classes). This would work, but doesn't seem necessary. I doubt we have very much caching going on... I'll work on 3 and see how things improve... -- This message is automatically generated by JIRA. - If you think it was sent
Re: Specs directory structure
I think this versioning has potential to be confusing, and the omission of version/ below doesn't actually do that - though it is probably possible with a version of (,) that includes everything. Personally, I'd prefer to have: servlet-api-2.4 servlet-api-2.4-1 servlet-api-2.4-2 or similar. (Technically, the last build number is used for rebuilding the same source code, not patching, but I think the alternative of 2.4.x creates some more confusion and the above will work as intended). Ideally, once 2.4 is compliant you don't need to release it again anyway :) Perhaps when we have proper spec-dependency handling in Maven it might be less confusing to use the geronimo-spec version number instead of the spec number. My 2cents... - Brett On 10/30/05, Dain Sundstrom [EMAIL PROTECTED] wrote: I know this has been talked about before on this list, but I'd like to get the proposal in one place. With the help of Alan and Jason, this is what I got: Normally we just have this directory structure: specs/trunk/servlet-2.2/src/ specs/trunk/servlet-2.4/src/ specs/trunk/jsp-2.4/src/ When we are happy with the specs we make a tag: specs/tags/1.0/servlet-2.2/src/ specs/tags/1.0/servlet-2.4/src/ specs/tags/1.0/javamail-2.2-r2/src/ specs/tags/1.1/servlet-2.2/src/ specs/tags/1.1/servlet-2.4/src/ specs/tags/1.1/javamail-2.2-r2/src/ The pom for the specs would be like this: groupIdorg.apache.geronimo.specs/groupId artifactIdservlet-2.4/artifactId nameGeronimo :: Servlet API/name version1.0/version With maven 2 version ranges a user can just have the following and maven will pick the most resent release of our spec automatically: dependency groupIdorg.apache.geronimo.specs/groupId artifactIdservlet-2.4/artifactId dependency The current directory structure in https://svn.apache.org/repos/asf/ geronimo/specs is very close to this. The only big change will be to add the version number of the specification to the directory name. What do yo think? -dain
