Re: Java One?
On May 29, 2005, at 6:46 PM, Jeff Genender wrote: -1 on Saturday. +1 on Sunday. I get in Sunday. The only issue on Sunday is that we have J2EE Licensee Day that afternoon, and I assume that many doing the J2EE certification work will wish to attend that. I suppose we can shoot for later in the evening... +1 on Beers + Coding ;-) Thank goodness for version control... geir Aaron Mulder wrote: How about a coding/planning meeting on Saturday or Sunday? Not that there's anything wrong with beers, but if a lot of us are going to be there, perhaps we can do more. Aaorn On Sun, 29 May 2005, Alan D. Cabrera wrote: Geir Magnusson Jr. wrote, On 5/28/2005 5:32 PM: On May 28, 2005, at 1:43 PM, Jeff Genender wrote: Its getting close to the big event... Should we be thinking about a small Geronimo get-together for some beers? How about a big Geronimo get together for some beers? I'm in. I shall be there too! Regards, Alan -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
I'm too dim to figure out how, because no matter what, since there is no notion of a tag or branch, no matter how you slice and dice, either you branch to a different root when you cut a version, or you have to get the whole history anytime you checkout anything... geir On May 28, 2005, at 11:25 AM, Jeff Genender wrote: Actually, SVN's repo for geronimo could have been set up in a modular approach instead of a monolithic trunk, and act similarly to CVS. Alan D. Cabrera wrote: Geir Magnusson Jr. wrote, On 5/28/2005 7:10 AM: On May 27, 2005, at 7:46 PM, Alan D. Cabrera wrote: Jeremy Boynes wrote, On 5/27/2005 7:38 PM: Alan D. Cabrera wrote: Jeremy Boynes wrote, On 5/27/2005 7:26 PM: David Blevins wrote: This one ../repos/asf/geronimo/unstable/modules/transaction ../repos/asf/geronimo/stable/modules/transaction Why would we have two versions of transaction? I actually think there are going to be additional ones but was keeping it simple to indicate that stable came higher up than transaction. Ultimately we might end up with (hypothetically) .../geronimo/stable/1.0/modules/transaction .../geronimo/stable/1.2/modules/transaction .../geronimo/stable/2.0/modules/transaction .../geronimo/unstable/1.3/modules/transaction .../geronimo/unstable/2.1/modules/transaction Where, for example, 1.x is J2EE1.4 requiring JDK1.4 and 2.x is J2EE1.5 requiring JDK1.5. I don't particularly care for odd/even designations for stable/ unstable. Maybe that was a coincidence in your example. We can easily support your scenario and keep w/ standard SVN usage by doing: geronimo/transaction/branches geronimo/transaction/tags/1_0 geronimo/transaction/tags/1_2 geronimo/transaction/tags/1_3 geronimo/transaction/tags/2_0 geronimo/transaction/tags/2_3 geronimo/transaction/trunk The problem here is when you do a co of geronimo/ to get all the modules, you get a major hose of bits... everything that was ever done. I hate to say it (and Fitz will prollie flog me with a trout...) but I can now identify one feature of CVS that I miss... Boy, I'm glad you said that. I gotta say, I kinda miss CVS. Regards, Alan -- Jeff Genender http://geronimo.apache.org -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Geronimo subprojects?
On May 28, 2005, at 1:20 PM, Brian K. Wallace wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: | I just read through the long Module restructure thread, and it to me | is seems like many people are talking about how we break Geronimo into | subprojects without using the word subproject. The goals of the | Module restructure thread seem to be: | | 1) allow modules to branch to unstable without requiring the geronimo | trunk to take unstable code | 2) allow modules to have independent release cycles so they don't have | to wait for geronimo trunk | | Regardless what we call it, that is a sub project. I think we should | bite the bullet and talk about what sets of functionality make sense as | a subproject. For example, I think there is a demonstrated desire to | have a TX/JCA subproject in Geronimo. | | -dain | | Agreed. And this, if properly combined with 'common deployments', could be a major step toward getting new users more interested. Undoubtedly it will require a shift in developer processes, but in the long run it would (in theory - application of that theory being more in procedure than possibility) make fixes and enhancements swifter. My questions at the root of this are: ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of a 'minimal' Geronimo? Is it able to claim anything with regard to the TCK? No. Nothing. The binary that passes the TCK is the only thing about which claims can be made. ~ 2. In stating there is a demonstrated desire, what roadblocks or opposition is there to having each of the current modules (short of the kernel, common, core and presumably deployment - and anything else needed for the server to start-up and do nothing) each be 'self-contained'? Obviously the 'base' server would have to know what it's really capable of (unless you go off the deep end with discovery), but over and above that base it seems that a WebConnector - be it Jetty for user 1 or Tomcat for user 2 may be used with or without Naming, with or without Spring and/or Transactions, etc. Why would there be a need to limit modules just to what there is a demonstrated desire to have? Making everything as small and self-contained (even if they don't 'run' on their own) seems to be a smart move in allowing a bug in one module to be fixed and made available without waiting on anything else (how many times have we wanted a typo fixed that had to wait for a completely new feature to be implemented?). I think that the most logical partitioning, which we've talked about for a lng long time, is having the server framework separate, done in a way that's easily reusable by others, free of J2EE cruft, etc. Then the other parts that are J2EE - in entirety, like the J2EE assembly - or in parts, like TX, could be separate. geir My thoughts... Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCmKh6aCoPKRow/gARAmOpAKCVANxfB36tX36emF6nLvKy+a/IkACghrzo nG3rKqN5K3CNVFIEWPDSKjg= =BFcE -END PGP SIGNATURE- -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Geronimo subprojects?
On May 28, 2005, at 1:41 PM, Jeff Genender wrote: I think I wrote something a little confusing...let me clarify... What we do to a subset of Geronimo has impact on the whether it passes. However if Geronimo passes the TCK, then a subset would include the features that passed. Technically speaking, you couldn't make that claim. However, as it stands, passing is an all-or-nothing propsition. Yes. We do have licenses for stand-alone TCKs for projects that we have. I'd be hard-pressed to argue that we should be able to get TCks for things we don't have, like JMS. geir I hope that was less confuusing. Jeff Genender wrote: Brian K. Wallace wrote: ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of a 'minimal' Geronimo? Is it able to claim anything with regard to the TCK? TCK is all or nothing. You pass all tests or you don't pass certification. A minimal Geronimo would clearly be a subset of the whole tomato, so TCK has no bearing on this, nor should there be concern. A minimal Geronimo is just disconnecting the features you don't want from the configuration. TCK and minimal Geronimo are mutually exclusive and do not impact each other in any way. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Geronimo subprojects?
On May 28, 2005, at 2:02 PM, Brian K. Wallace wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: | | My questions at the root of this are: | ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of | a 'minimal' Geronimo? Is it able to claim anything with regard to the | TCK? | | | It depends on the specifications the subproject is implementing and if | Sun has a stand-alone tck for the specifications. For example, if it | were the Geronimo 'just a webserver edition' we could certify it for | servlets and jsp because they have standalone tcks, but if it were tx | and jca we could not certify it since there are no standalone tcks for | those specs. Understood. My main question was if there was some sort of 'prohibition' on the use of 'full system' pass/fail statistics for those pieces that do, in fact, have their own tcks. [I don't view this as a roadblock to anything, but a definite plus if each individual piece that was able (due to having and passing their own tcks) could state it passes.] Yes. If you want to know if the servlet part works on it's own, you need to test it on it's own geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Geronimo subprojects?
On May 29, 2005, at 2:08 AM, Bruce Snyder wrote: On 5/28/05, Dain Sundstrom [EMAIL PROTECTED] wrote: Each subproject has an inherent amount of overhead. For example, each subproject needs a separate project management committee, each one will need to produce releases (not an easy task) and so on. I would sat that there is a demonstrated desire when we have enough people showing up to handle the overhead and work on the code. I personally would say one person is not enough, and seven is more then enough. I don't think that every subproject needs it's own PMC unless it's a subproject wholly separate from the existing Geronimo modules. For example, if the Spring kernel were brought in as a subproject, it would need its own PMC, but I don't think splitting up the existing modules and forming individual PMCs is necessary. Right. I don't think we need sub-projects or want sub-projects. I think we just need to modularize better and be able to have a stable J2EE assembly tree to help the push towards a certified 1.0 Geronimo release. geir 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/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
On May 30, 2005, at 4:18 PM, Bruce Snyder wrote: On 5/30/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'm too dim to figure out how, because no matter what, since there is no notion of a tag or branch, no matter how you slice and dice, either you branch to a different root when you cut a version, or you have to get the whole history anytime you checkout anything... On many other projects, I have always relied heavily on tagging. Me too - and then converting tags into branches if need be. But you can't do that in SVN. All work is conducted on the HEAD unless it's highly experimental and then it occurs in its own branch. Once the HEAD is ready for a release I tag it and do the release. But I can see the value in keeping things separate as in trunk and sandbox. The tagging can then take care of stable vs. unstable. Bruce... there is no tagging in SVN :) That's the problem. geir 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/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Java One?
On May 30, 2005, at 4:49 PM, Dain Sundstrom wrote: On May 30, 2005, at 11:13 AM, Geir Magnusson Jr. wrote: On May 29, 2005, at 6:46 PM, Jeff Genender wrote: -1 on Saturday. +1 on Sunday. I get in Sunday. The only issue on Sunday is that we have J2EE Licensee Day that afternoon, and I assume that many doing the J2EE certification work will wish to attend that. I suppose we can shoot for later in the evening... Considering how useless last year's licensee day was, I don't plan on going. Do they have something interesting planned for this year? I have no way of knowing. I'd suspect that it's going to be more of the same, with the addition of a riveting discussion about brand and naming changes. Hopefully, there's going to be more detailed discussion of EJB3 as well. geir -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Geronimo subprojects?
On May 30, 2005, at 3:28 PM, Jeff Genender wrote: Geir Magnusson Jr. wrote: On May 28, 2005, at 1:41 PM, Jeff Genender wrote: I think I wrote something a little confusing...let me clarify... What we do to a subset of Geronimo has impact on the whether it passes. However if Geronimo passes the TCK, then a subset would include the features that passed. Technically speaking, you couldn't make that claim. Does the law of transitivity not apply here? If Jetty passes the TCK, would its use on its own in a Geronimo Lite (i.e. G + Jetty only) not mean that we are using the passed component for web? Strangely enough, apparently not, unless we used Jetty in exactly the way it was packaged when it passed. My point was: Full G Change (where it passes) --- G Lite contains passed code. but G Lite is changed - May impact full G's passing of TCK. Please clarify how this claim may not be valid. I don't quite understand. Your reasoning is logical, but the TCK is a simple statement about the binary tested. It passes, or it doesn't pass. That information isn't transitive to other binaries that aren't the same. You need to test those too... Jeff -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
On May 30, 2005, at 6:59 PM, Bruce Snyder wrote: On 5/30/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On May 30, 2005, at 4:18 PM, Bruce Snyder wrote: On 5/30/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'm too dim to figure out how, because no matter what, since there is no notion of a tag or branch, no matter how you slice and dice, either you branch to a different root when you cut a version, or you have to get the whole history anytime you checkout anything... On many other projects, I have always relied heavily on tagging. Me too - and then converting tags into branches if need be. But you can't do that in SVN. All work is conducted on the HEAD unless it's highly experimental and then it occurs in its own branch. Once the HEAD is ready for a release I tag it and do the release. But I can see the value in keeping things separate as in trunk and sandbox. The tagging can then take care of stable vs. unstable. Bruce... there is no tagging in SVN :) That's the problem. There most certainly is tagging in SVN. agreed. the revision # :) Albeit the concept of tagging in SVN is very different from CVS. Yes. That's why I say it isn't tagging. It's just copying. The same is true for branches in SVN as well. SVN just makes copies of everything because the SVN developers made the assumption that disk space is cheap. This doesn't mean that we can't continue to utilize tagging just the way we have with the mileston releases so far. Well, it does if you want to avoid getting the entire history of the project when you do a co. That's really the issue. geir 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/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
On May 30, 2005, at 8:10 PM, Aaron Mulder wrote: On Mon, 30 May 2005, Geir Magnusson Jr. wrote: Well, it does if you want to avoid getting the entire history of the project when you do a co. That's really the issue. That's really a layout issue. You put the trunk, branches, and tags, somewhere. If you put them all under the same parent, and check out the parent, then sure, you get a lot. If we want to avoid that problem, we need to find a layout with better parents so you if you grab the right parent(s), you get only what you want and nothing else. Right - and it's not an issue w/ CVS, which is how most of us think about this. We forget (or I do) that you have to change model w/ SVN. That's why it's become a layout issue. The bigger issue, which started this, was jeremy's suggestion that we get a stable track for things that doesn't interfere w/ people experimenting. geir So I guess the place to start is, what do we want you to get (and want you to not get) in a single checkout? I'm also not tied to using a single parent, since I always use Maven to checkout anyway, so we could have 20 separate dirs it checks out for different modules -- one to get the main Maven scripts and admin stuff, then you run that to grab the correct configuration of everything else that you're after. Aaron -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
On May 27, 2005, at 7:46 PM, Alan D. Cabrera wrote: Jeremy Boynes wrote, On 5/27/2005 7:38 PM: Alan D. Cabrera wrote: Jeremy Boynes wrote, On 5/27/2005 7:26 PM: David Blevins wrote: This one ../repos/asf/geronimo/unstable/modules/transaction ../repos/asf/geronimo/stable/modules/transaction Why would we have two versions of transaction? I actually think there are going to be additional ones but was keeping it simple to indicate that stable came higher up than transaction. Ultimately we might end up with (hypothetically) .../geronimo/stable/1.0/modules/transaction .../geronimo/stable/1.2/modules/transaction .../geronimo/stable/2.0/modules/transaction .../geronimo/unstable/1.3/modules/transaction .../geronimo/unstable/2.1/modules/transaction Where, for example, 1.x is J2EE1.4 requiring JDK1.4 and 2.x is J2EE1.5 requiring JDK1.5. I don't particularly care for odd/even designations for stable/ unstable. Maybe that was a coincidence in your example. We can easily support your scenario and keep w/ standard SVN usage by doing: geronimo/transaction/branches geronimo/transaction/tags/1_0 geronimo/transaction/tags/1_2 geronimo/transaction/tags/1_3 geronimo/transaction/tags/2_0 geronimo/transaction/tags/2_3 geronimo/transaction/trunk The problem here is when you do a co of geronimo/ to get all the modules, you get a major hose of bits... everything that was ever done. I hate to say it (and Fitz will prollie flog me with a trout...) but I can now identify one feature of CVS that I miss... geir Regards, Alan -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Java One?
On May 28, 2005, at 1:43 PM, Jeff Genender wrote: Its getting close to the big event... Should we be thinking about a small Geronimo get-together for some beers? How about a big Geronimo get together for some beers? I'm in. geir I hear the IBM guys are celebrating by buying a night of libations (j/k)! It would be great to meet everyone. Should we plan a place and meeting time? Jeff -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
Clearly, we need something like this to get organized around the final push for certification and the 1.0 release, by why not just branch for the stable, and head is unstable? geir On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote: Stefan brings up the question of whether we want to release sub- modules of Geronimo separately. I think this is a good idea and would propose the following restructure of the tree to move in this direction. Rather than trunk in the root, we have three separate trees: stablesimilar to even-numbered versions of Linux, this tree would contain stable code intended for production use and operates with a focus on stability (i.e. well documented stable APIs, backward compatibility, no SNAPSHOT dependencies etc.) There will be multiple branches as needed. unstable similar to odd-numbered versions this is where new development is done and APIs etc. are much more likely to change. We may still do releases from here but they are quite likely to be incompatible; it may be all we package from here are nightlies. sandbox as now, a free-for-all area for trying out new ideas and experimenting with new technologies Given the size of the codebase, we need to preserve the module structure that we have in the current trunk. However, even now some modules are more stable than others (e.g. the transaction and connector ones Thierry is looking to use) and I think are in a position where they can be versioned separately. With the structure above in place, we can move modules into the stable or unstable trees as appropriate. For those that we consider stable (e.g. transaction) we can cut numbered releases that people can use standalone. This will also speed the unstable build as we won't need to check SNAPSHOTs for everything all the time. I would suggest we start on this as part of packaging for M4 and would be willing to co-ordinate. -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
BTW, however we resolve stable and unstable, I really do like the idea of a separate sandbox tree. That will make things very clear to people. geir On May 27, 2005, at 12:18 PM, Geir Magnusson Jr. wrote: Clearly, we need something like this to get organized around the final push for certification and the 1.0 release, by why not just branch for the stable, and head is unstable? geir On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote: Stefan brings up the question of whether we want to release sub- modules of Geronimo separately. I think this is a good idea and would propose the following restructure of the tree to move in this direction. Rather than trunk in the root, we have three separate trees: stablesimilar to even-numbered versions of Linux, this tree would contain stable code intended for production use and operates with a focus on stability (i.e. well documented stable APIs, backward compatibility, no SNAPSHOT dependencies etc.) There will be multiple branches as needed. unstable similar to odd-numbered versions this is where new development is done and APIs etc. are much more likely to change. We may still do releases from here but they are quite likely to be incompatible; it may be all we package from here are nightlies. sandbox as now, a free-for-all area for trying out new ideas and experimenting with new technologies Given the size of the codebase, we need to preserve the module structure that we have in the current trunk. However, even now some modules are more stable than others (e.g. the transaction and connector ones Thierry is looking to use) and I think are in a position where they can be versioned separately. With the structure above in place, we can move modules into the stable or unstable trees as appropriate. For those that we consider stable (e.g. transaction) we can cut numbered releases that people can use standalone. This will also speed the unstable build as we won't need to check SNAPSHOTs for everything all the time. I would suggest we start on this as part of packaging for M4 and would be willing to co-ordinate. -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
On May 27, 2005, at 12:40 PM, Jeremy Boynes wrote: Geir Magnusson Jr. wrote: Clearly, we need something like this to get organized around the final push for certification and the 1.0 release, by why not just branch for the stable, and head is unstable? The names are just suggestions - trunk, head, unstable, whatever. The important thing is that you can easily checkout and build each tree on its own so we can't have both stable and unstable branches of modules (e.g. transaction) under trunk. right - this is SVN, so the standard branching model actually doesn't work. We'll need the branches outside of /trunk anyway so we have /trunk and /branches/stable and /branches/unstable, the former for release work, and the latter for really nutty stuff that people want to work on, and head is where mainline development continues? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
On May 27, 2005, at 12:48 PM, Geir Magnusson Jr. wrote: On May 27, 2005, at 12:40 PM, Jeremy Boynes wrote: Geir Magnusson Jr. wrote: Clearly, we need something like this to get organized around the final push for certification and the 1.0 release, by why not just branch for the stable, and head is unstable? The names are just suggestions - trunk, head, unstable, whatever. The important thing is that you can easily checkout and build each tree on its own so we can't have both stable and unstable branches of modules (e.g. transaction) under trunk. right - this is SVN, so the standard branching model actually doesn't work. We'll need the branches outside of /trunk anyway so we have /trunk and /branches/stable and /branches/unstable, the former for release work, and the latter for really nutty stuff that people want to work on, and head is where mainline development continues? (What I'm saying is that I agree with you... we have no real choice because of how SVN does branches. We clearly need to separate stable from unstable ongoing work) geir geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
On May 27, 2005, at 4:25 PM, David Blevins wrote: Yea, I was just about to post that. Stable/unstable refers to branches. But jeremy is right here (but forgot to say it) - because we're using SVN, you want to keep the branches in a separate root so that svn co geronimo doesn't bring down every branch, but just gets you the current head. As long as we're in the same SVN repo, the fact that we have different roots is irrelevant from the POV of making copies (aka branching), but it's a big help for users. geir -David On Fri, May 27, 2005 at 12:18:03PM -0400, Geir Magnusson Jr. wrote: Clearly, we need something like this to get organized around the final push for certification and the 1.0 release, by why not just branch for the stable, and head is unstable? geir On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote: Stefan brings up the question of whether we want to release sub- modules of Geronimo separately. I think this is a good idea and would propose the following restructure of the tree to move in this direction. Rather than trunk in the root, we have three separate trees: stablesimilar to even-numbered versions of Linux, this tree would contain stable code intended for production use and operates with a focus on stability (i.e. well documented stable APIs, backward compatibility, no SNAPSHOT dependencies etc.) There will be multiple branches as needed. unstable similar to odd-numbered versions this is where new development is done and APIs etc. are much more likely to change. We may still do releases from here but they are quite likely to be incompatible; it may be all we package from here are nightlies. sandbox as now, a free-for-all area for trying out new ideas and experimenting with new technologies Given the size of the codebase, we need to preserve the module structure that we have in the current trunk. However, even now some modules are more stable than others (e.g. the transaction and connector ones Thierry is looking to use) and I think are in a position where they can be versioned separately. With the structure above in place, we can move modules into the stable or unstable trees as appropriate. For those that we consider stable (e.g. transaction) we can cut numbered releases that people can use standalone. This will also speed the unstable build as we won't need to check SNAPSHOTs for everything all the time. I would suggest we start on this as part of packaging for M4 and would be willing to co-ordinate. -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Spanish Documentation Avaible
On May 14, 2005, at 7:21 AM, Katia Aresti Gonzalez wrote: Hello everybody!!! I have finished my spanish documentation about Geronimo. I have included the following parts: - Install and building from source - Configuration of Database pool - Configuration of JMS - Configuration en Deploy of EJBs, all types JAR - WAR applications - EAR application - Client Applications JAR The documentation is about 100 pages, and i have done some code examplesas well. How coud I send the documentation so its avaible from Geronimo Web page? And somedoy could have a look. Thank you!! You wrote 100 pages of documentation for Geronimo, in Spanish? That's great. Now we have the strange situation of needing an english translation. The way to contribute... Well, it's big - 100 pages. I suppose that a software grant is the right thing to do in this case. I'll figure out if we need that, or if you can just post to the JIRA. Great! geir Katia Descubre la descarga digital segura. Medio millón de canciones en MSN Music. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: IBM buys Gluecode
On May 10, 2005, at 9:17 PM, Sanjiva Weerawarana wrote: On Tue, 2005-05-10 at 11:36 -0700, Craig Johannsen wrote: Hey! This is a surprise. Is this ultimately good for Geronimo? Will IBM's business objectives for Websphere distort or limit the vision of the Geronimo project? The key for Geronimo's success as an Apache project lies with the Geronimo community. If the Geronimo developer community == Gluecode employees then Geronimo was already in trouble with poor community diversity! So IBM buying Geronimo does not make any change on that front. Yes. This is all about community and participation. We have been working, and will be working to increase the community diversity... However, now that IBM too will have folks working on Geronimo (along with the new IBMers from the old Gluecode) that somewhat increases the challenge to Geronimo's leaders to make sure the community grows and stays healthy in terms of having good diversity. I have no doubt Geir, Jeremy and the other leaders of Geronimo realize this and will act with their Apache hats on to help ensure's Geronimo's success. That's my hope. Apache Geronimo is Apache Geronimo - an Apache project in which all participants are welcome. We leave our employer hats at the door when it comes to building community and working with others. IMO IBM will succeed in the Geronimo effort IFF Geronimo succeeds to its full potential in Apache .. that means it becomes/remains a true community project. However, there's no doubt that's not easy to do .. witness Xerces. I know the IBM folks realize the challenges and I have no doubt Geir and crew will avoid the pitfalls. Sanjiva. (an IBMer until a few weeks ago) :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Spring cleaning
+1 On Apr 8, 2005, at 12:34 PM, Jeremy Boynes wrote: It has been a very long time since we went around and cleaned up some of the things that seemed like good ideas at the time. I would like to propose a spring-cleaning exercise. For example, if we look in the sandbox we moved a lot of things there over a year ago on the basis that they might be useful later; this includes mail, remoting and explorer which have all been implemented differently in the trunk. I would suggest we remove everything from there except Gianny's webdav stuff (unless he thinks that should go too). There is also some utility stuff in the common, core and system modules that is not being used and which can be removed to reduce clutter and footprint. Finally, I'd like to revisit the dependencies we have. For example, I recently came across the case where we were using a RC version of the velocity jellybean but then they had cut the final release and we just had not upgraded. We should go back and see if there are more instances of this. We may also find that by removing some of the clutter some dependencies can also be removed entirely. Any thoughts, objections, or additional stuff that could be cleaned up? -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: John Sisson - new Apache Geronimo committer
On Apr 6, 2005, at 12:38 PM, Jeff Genender wrote: This fascinates me...do people actually have to get permission to become a committer or member of the ASF? Depends on your situation. Many employers in the US have as part of the employment agreement terms that establish ownership of development work you do. The terms of this vary by company. So we offer the CCLA as a vehicle in which the committer can get explicit permission from his/her employer, as a way of protecting that committer from their employer taking issue with it later. It's never good to just go on a wink and a nod from a manager, if that manager many not be around later... geir Enquiring minds want to know! Jeff Geir Magnusson Jr wrote: On Apr 5, 2005, at 8:56 PM, [EMAIL PROTECTED] wrote: Thanks everyone! I would like to accept and I am waiting for approval from corporate legal. BTW, if you need any help explaining or discussing, let us know. We've been through this before with other companies. geir -- Jeff Genender http://geronimo.apache.org -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: John Sisson - new Apache Geronimo committer
On Apr 5, 2005, at 8:56 PM, [EMAIL PROTECTED] wrote: Thanks everyone! I would like to accept and I am waiting for approval from corporate legal. BTW, if you need any help explaining or discussing, let us know. We've been through this before with other companies. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
On Apr 4, 2005, at 7:12 PM, Dain Sundstrom wrote: On Apr 4, 2005, at 3:53 PM, Geir Magnusson Jr wrote: On Apr 4, 2005, at 5:48 PM, David Blevins wrote: Even further, I don't think pressuring projects into giving us an officially named version of our SNAPSHOT when they aren't ready to release is a solution either. Then we are just turning a blind eye and saying, not my problem. Well, if we are working closely with a project (like OpenEJB, ActiveMQ, HOWL, etc) and they do that it's time to reconsider working so closely with them, IMO. I'm not saying that projects should release for us on a whim because they are independent and have other parts of their community to cater to, and I know things will settle down, but there are lots of users that wouldn't take things seriously until the pedigree of the OSS we're using is clear, and it wouldn't be if we were issuing our own snapshots of external dependencies. Geir, I think your comments are way too hard of a line to take. This is a fairly common line with other open source projects, and commercial and corporate development as well. We can be (gawd, it hurts to use this word) professional. People want to know what is in the the software they are deploying, that they are building products and business on. They want to know where it comes from. They want to know that others are using the same thing (safety in numbers) and they want to know that if there is a bug or patch, they can go to the source and get it. Let's put this back in context. David originally wrote the following: -- You do realize we are talking about two different things here. No one in their right mind would propose SNAPSHOT dependencies are a good idea for releases of any kind. Not only do I strongly agree, I think we shouldn't switch something back to SNAPSHOT after a release. Even further, I don't think pressuring projects into giving us an officially named version of our SNAPSHOT when they aren't ready to release is a solution either. Then we are just turning a blind eye and saying, not my problem. -- And before that, he said : Seems like we are going in circles on this one. Can we reasonable agree that it isn't practical to hold up a Geronimo release till every project we have a snapshot depenency on is able to hand us some sort of official release of their own? So I was confused. I do think he cleared it up. The reality is our timeline are not likely to align with most projects. There will be tough times when a project is focused on another task and not ready to cut a release (much like geronimo is now focused on certification). In times like that, how do you propose we reconsider working so closely with them. Would we fork a project because they wanted to wait a 3 weeks for an official release? Would we replace the project? Most of the projects you listed are simply irreplaceable. The fact is that when we do a release, and are telling people that we declare the software safe and ready to use, with the standard conventions of dependencies on other software, that I'd like to be sure that there is the absolute minimum of strangeness about what we release, and that we have the minimum of objections for adoption. Cutting our own releases of dependencies is going to be a barrier. I think you need to be more flexible. This is especially true when dealing with a volunteer organization. I think you are making a mountain out of a molehill. We have great relationships with those projects (we have many cross-committers), so I'm not terribly worried, especially if we do a bit of coordination, planning and help. geir -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
On Apr 1, 2005, at 12:01 PM, Alan D. Cabrera wrote: Hiram Chirino wrote: On Apr 1, 2005, at 4:53 AM, Geir Magnusson Jr. wrote: On Mar 31, 2005, at 11:17 PM, Jeremy Boynes wrote: Geir Magnusson Jr wrote: No, but I worry about just bundling random whatever from outside the project with our releases. It would help to use the svn revision on the jar, but we should really make it clear that it's something the geronimo project created for it's use, rather than confuse people that it might be an artifact from ActiveMQ. The word 'SNAPSHOT' would help. SNAPSHOT has a specific meaning to Maven - it will cause it to check the remote repo for a newer version (by timestamp) even if a copy exists in the local repo. This is good for daily builds, a nightmare for anything where consistency is required. So when we decide to do a milestone (or release) we need to ensure there are no dependencies on versions with SNAPSHOT in them and instead use ones that contain a SVN revision number or a CVS timestamp: bad:foo-bar-1.3-SNAPSHOT.jar ok: foo-bar-1.3-20050401.jar better: foo-bar-1.3-158653.jar Going back to the original issue of an external project not wishing to do a release, we want to make it clear that this is something that we threw together ad hoc, and not something published by the external project. The upside to having a geronimo committer build the artifact himself from source is that you have a better oversight in knowing from what source code a binary was produced. Perhaps we should tag the file name with something, so it obvious it's an ad hoc build that an apache committer through together. foo-bar-1.3-adhoc-geronimo-158653.jar works for me This way it's clear that this jar was specifically for an ad hoc geronimo snapshot. Another nice thing about having adhoc-geronimo in the name is that when you browse your local repo, it's easy to spot the ad hoc geronimo jars. Finding these jars using the find command is simplified when jars are taged with these tokens in their jar names. I'm not married to the token adhoc-geronimo but, you get the idea. Actually as I think about it, would one want to make the tag name as unweldy as possible to deter non-geronimo projects from relying on our maven repo as a means of distribution? Yes. We should ensure that they are outside of the 7bit ASCII space. Maybe foo-bar-1.3-ådhøc-gérönîmó-158653.jar if we could get an unprintable character in there too, we'd be done. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Geronimo and Cargo: sharing code for J2EE module parsing/writing?
Feature request : What also would be cool is going in reverse - having an API to take a (Geronimo|WebSphere|Weblogic|JBoss) (WAR|EAR) and get the info out for deployment. Would make it easy then for us to support migration from other platforms... geir On Mar 15, 2005, at 4:31 PM, Vincent Massol wrote: Hi David, -Original Message- From: David Blevins [mailto:[EMAIL PROTECTED] Sent: mardi 15 mars 2005 17:18 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Geronimo and Cargo: sharing code for J2EE module parsing/writing? You've pretty much quoted the mission statements of JSR 77 and 88. I think JSR77/88 are broader in that they include deployment and management. However the API I mention was only about reading/writing J2EE Modules. I simply wanted to know if Geronimo is already using such code. If not then we'll continue developing it. If Geronimo has such code we'd like to evaluate the possibility of dropping our home-grown solution and using the Geronimo code instead (because this is reading/writing of J2EE Modules is not at our core and if some other project is more advanced we might as well use it instead of competing). I personally would be thrilled to see a project serisouly take on the tool side of that spec. We already have providers for the server's role in those specs. You should be able to get something running that will work will all the vendors. It is true that writing client side support for JSR77/88 is on our roadmap (see http://cargo.codehaus.org/Roadmap) but my previous email was about something a bit different: simply reading/writing J2EE archive files. I do agree that reading/writing J2EE archive files is probably a subset of what is required for implementing JSR77. Thanks -Vincent -David On Tue, Mar 15, 2005 at 10:13:59AM +0100, Vincent Massol wrote: Hi Geronimo developers, I'm working on the Cargo project (http://cargo.codehaus.org) which is offering a Java API to manipulate J2EE containers (configure, start, stop, etc). As part of Cargo, we have an API for parsing and creating J2EE Archive files (WAR and EAR only ATM), including container-specific extensions (jboss-web.xml, Tomcat's context.xml file, etc). Source files can be seen here: http://tinyurl.com/6tupy This API is currently separated from Cargo core which uses it for reading container-specific deployment files. It is also used by Jakarta Cactus for cactifying WARs and EARs (i.e. automatically modifying an existing WAR or EAR file to add items to its web.xml file, gather data from container-specific deployment files, add news file to the WAR, etc). It dawned on us yesterday (yeah, we're slow-thinkers ;-)) that a big part of such a library would be needed by anyone implementing a container. Hence my email to you and the following question: Is there in Geronimo land an existing library for parsing/writing J2EE Archive files that we could reuse instead of our home-grown one? Would that library allow extensions like container-specific descriptor files? Thanks a lot -Vincent -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
John Sisson - new Apache Geronimo committer
Dear John, The Apache Geronimo PMC has voted to offer you commit status on the Apache Geronimo project. Thank you for your participation so far in the project, and we all are excited to have you as a committer. Please let us know if you wish to accept this offer. If you accept, we need the following : 0) your preferred username (sissonj?, jsisson?) for your apache account and email address 1) You need to sign an Individual Contributor License Agreement, found here : http://www.apache.org/licenses/icla.txt http://www.apache.org/licenses/icla.pdf (PDF looks nicer) This document is required for commit access. Please fax that to the FAX # found on the form. You have a chance of things going faster if you ALSO fax to +1-203-665-6400. 2) If possible, get your employer to sign a Corporate Contributor License Agreement, found here : http://www.apache.org/licenses/cla-corporate.txt This is optional, but encouraged. This document shows that your employer knows and accepts that you are contributing to the project. There are lots of good reasons to get this done if you can. Congratulations! geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Incompatible API change in Configuration
On Apr 4, 2005, at 2:17 PM, Dain Sundstrom wrote: I personally think this is way way way too early to be worried about binary compatability between configuration objects build with pervious releases and builds. Also, are you taking only about the official M1, M2 and M3 releases or builds from code? What do you, the community, think about us spending time thinking about binary compatibility between milestone releases? I hate milestone releases and wish we would switch to 0.x leading to 1.0 :) I think that breaking binary compatibility at this point should be for a darn good reason, and only after discussion - we want to get into the habit to avoid it at all costs. geir -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 On Apr 4, 2005, at 3:08 AM, Gianny Damour wrote: My bad :( I must admit that this is a side effect that I have not duly considered. I considered the source and binary compatibility and I missed this serialization specific incompatibility. Gianny On 3/04/2005 6:15 AM, Jeremy Boynes wrote: On 3/22 in revision 158589 the API for Configuration changed in that the return type from getConfigurationClassLoader() changed from ClassLoader to a ConfigurationClassLoader. This means all configurations built before then are now inoperable with the current tree as the attribute type in the persisted GBeanData does not match the new signature. I can't find any discussion on the list around then that would alert users to this change. It is critical that we let people know when this kind of change is made. -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
On Apr 4, 2005, at 2:20 PM, Dain Sundstrom wrote: On Apr 4, 2005, at 9:59 AM, David Blevins wrote: Seems like we are going in circles on this one. Can we reasonable agree that it isn't practical to hold up a Geronimo release till every project we have a snapshot depenency on is able to hand us some sort of official release of their own? +1 We do our best to eliminate the SNAPSHOTs, but the reality is we can't always eliminate all of them. You guys are crazy. We have to be able to eliminate them, especially for production releases. Even before we're 1.0, I would expect that our 0.8 and 0.9 stuff are becoming good enough for some dependable use, and thus we should only depend on released software. My USD0.02 geir -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
On Apr 4, 2005, at 4:45 PM, David Blevins wrote: On Mon, Apr 04, 2005 at 03:10:55PM -0400, Geir Magnusson Jr wrote: On Apr 4, 2005, at 2:20 PM, Dain Sundstrom wrote: On Apr 4, 2005, at 9:59 AM, David Blevins wrote: Seems like we are going in circles on this one. Can we reasonable agree that it isn't practical to hold up a Geronimo release till every project we have a snapshot depenency on is able to hand us some sort of official release of their own? +1 We do our best to eliminate the SNAPSHOTs, but the reality is we can't always eliminate all of them. You guys are crazy. We have to be able to eliminate them, especially for production releases. Even before we're 1.0, I would expect that our 0.8 and 0.9 stuff are becoming good enough for some dependable use, and thus we should only depend on released software. What is 0.8 and 0.9? Oh, sorry. I keep thinking in terms of versions leading up to a 1.0 release. I know we don't do that here (yet), but just think of things that way. IOW, I think that a 1.0 should be fairly dependable, and thus the fractional releases leading up to 1.0 should be the kind of code you can work with some reasonable amount of trust. In any event, having snapshots of external projects is something we should avoid. geir -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
On Apr 4, 2005, at 5:48 PM, David Blevins wrote: On Mon, Apr 04, 2005 at 03:10:55PM -0400, Geir Magnusson Jr wrote: On Apr 4, 2005, at 2:20 PM, Dain Sundstrom wrote: On Apr 4, 2005, at 9:59 AM, David Blevins wrote: Seems like we are going in circles on this one. Can we reasonable agree that it isn't practical to hold up a Geronimo release till every project we have a snapshot depenency on is able to hand us some sort of official release of their own? +1 We do our best to eliminate the SNAPSHOTs, but the reality is we can't always eliminate all of them. You guys are crazy. We have to be able to eliminate them, especially for production releases. Even before we're 1.0, I would expect that our 0.8 and 0.9 stuff are becoming good enough for some dependable use, and thus we should only depend on released software. You do realize we are talking about two different things here. No one in their right mind would propose SNAPSHOT dependencies are a good idea for releases of any kind. Not only do I strongly agree, I think we shouldn't switch something back to SNAPSHOT after a release. Sorry - I must have misunderstood the following : On Apr 4, 2005, at 9:59 AM, David Blevins wrote: Seems like we are going in circles on this one. Can we reasonable agree that it isn't practical to hold up a Geronimo release till every project we have a snapshot depenency on is able to hand us some sort of official release of their own? Even further, I don't think pressuring projects into giving us an officially named version of our SNAPSHOT when they aren't ready to release is a solution either. Then we are just turning a blind eye and saying, not my problem. Well, if we are working closely with a project (like OpenEJB, ActiveMQ, HOWL, etc) and they do that it's time to reconsider working so closely with them, IMO. I'm not saying that projects should release for us on a whim because they are independent and have other parts of their community to cater to, and I know things will settle down, but there are lots of users that wouldn't take things seriously until the pedigree of the OSS we're using is clear, and it wouldn't be if we were issuing our own snapshots of external dependencies. Our current reality is that we do have over a dozen SNAPSHOT dependencies and we will need to release soon enough. I only see two solutions to this releasing issue: 1. Use date stamped (cvs) or revision stamped (svn) jars in place of SNAPSHOTs on releases. 2. Not release until we can truly eliminate all SNAPSHOT usage--not just get other projects to relabel our SNAPSHOTs so we feel warm and fuzzy. My long term preference is 2, though I'm ok with 1 in the very short term. For the very short term I can live with #1, but this should be a priority to get under control, somehow. geir -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Drop Axion configuration?
+1 On Apr 2, 2005, at 2:04 PM, Jeremy Boynes wrote: Any objections to dropping the Axion configuration (default-database-plan.xml) from the distribution? This has been retained up to now for backward compatibility but the primary database has been Derby for quite a while now. Axion will still be usable via normal JDBC configuration. -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
On Mar 31, 2005, at 6:30 PM, Hiram Chirino wrote: On Mar 31, 2005, at 6:17 PM, Geir Magnusson Jr wrote: On Mar 31, 2005, at 6:14 PM, Hiram Chirino wrote: I think we should keep as much history as possible, at least the dependencies for all maintained branches. I would say, we never remove a jar. A SNAPSHOT jar should just be a simlink to a numbered jar (this is what maven does already). Re the snapshots, doesn't that result in piles of useless crap? I mean, why keep the old numbered jars around? The build conditions for them are variable at best, and I can't think of situations where you'd need to go and use an old one. ? It could. But the main argument to keep old numbered snapshot jars is so that you can build an old source release of of geronimo that might depend on a old numbered snapshot release. How? do we ever list the snapshot number in project.xml? I think for a release, yes.. we should take the effort and specify the snapshot number. I'm confused, and want to make sure we're not just talking past each other accidentally. For a release, we don't use snapshots anyway, right? We'd generate a set of jars all with the release version number in the filename. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
On Mar 31, 2005, at 8:15 PM, Hiram Chirino wrote: On Mar 31, 2005, at 7:35 PM, Geir Magnusson Jr wrote: On Mar 31, 2005, at 6:30 PM, Hiram Chirino wrote: On Mar 31, 2005, at 6:17 PM, Geir Magnusson Jr wrote: On Mar 31, 2005, at 6:14 PM, Hiram Chirino wrote: I think we should keep as much history as possible, at least the dependencies for all maintained branches. I would say, we never remove a jar. A SNAPSHOT jar should just be a simlink to a numbered jar (this is what maven does already). Re the snapshots, doesn't that result in piles of useless crap? I mean, why keep the old numbered jars around? The build conditions for them are variable at best, and I can't think of situations where you'd need to go and use an old one. ? It could. But the main argument to keep old numbered snapshot jars is so that you can build an old source release of of geronimo that might depend on a old numbered snapshot release. How? do we ever list the snapshot number in project.xml? I think for a release, yes.. we should take the effort and specify the snapshot number. I'm confused, and want to make sure we're not just talking past each other accidentally. For a release, we don't use snapshots anyway, right? We'd generate a set of jars all with the release version number in the filename. Not sure why you think we would not use snapshots. For example, if we were releasing M4, it would have to ship with a SNAPSHOT of activemq 3.0 since it's not ready to be released yet. We would generate numbered snapshot using the svn revision number of the activemq sources. Ah - of other stuff. I figured there was something missing. Interesting question. Could we ask ActiveMQ to do a ActiveMQ-3.0-pre-alpha-don'tuse.jar (or whatever they wanted to call it)? yes, that would be a snapshot, but since it better be a functional snapshot (rather than somewhat random), couldn't that be a milestone release from ActiveMQ if we asked really, really nicely? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
On Mar 31, 2005, at 8:40 PM, Hiram Chirino wrote: It could. But the main argument to keep old numbered snapshot jars is so that you can build an old source release of of geronimo that might depend on a old numbered snapshot release. How? do we ever list the snapshot number in project.xml? I think for a release, yes.. we should take the effort and specify the snapshot number. I'm confused, and want to make sure we're not just talking past each other accidentally. For a release, we don't use snapshots anyway, right? We'd generate a set of jars all with the release version number in the filename. Not sure why you think we would not use snapshots. For example, if we were releasing M4, it would have to ship with a SNAPSHOT of activemq 3.0 since it's not ready to be released yet. We would generate numbered snapshot using the svn revision number of the activemq sources. Ah - of other stuff. I figured there was something missing. Interesting question. Could we ask ActiveMQ to do a ActiveMQ-3.0-pre-alpha-don'tuse.jar (or whatever they wanted to call it)? yes, that would be a snapshot, but since it better be a functional snapshot (rather than somewhat random), couldn't that be a milestone release from ActiveMQ if we asked really, really nicely? What's the difference between that and me building a ActiveMQ-3.0-20050115-SNAPSHOT.jar ?? It's the same in my eyes. The ActiveMQ folks don't want to keep snapshots like that around since that just increases the release management overhead. ActiveMQ likes to keep it simple... we don't do mile stones or release candidates or alphas or betas or any of that stuff. I think we just need to be flexible. Other projects in the future may not be able to do a release just for a Milestone release of Geronimo. No, but I worry about just bundling random whatever from outside the project with our releases. It would help to use the svn revision on the jar, but we should really make it clear that it's something the geronimo project created for it's use, rather than confuse people that it might be an artifact from ActiveMQ. The word 'SNAPSHOT' would help. I also would have thought that the ActiveMQ project wouldn't want activeMQ-*.jar floating around out there where they didn't choose *... We'll figure it out... geir Regards, Hiram geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
On Mar 31, 2005, at 11:17 PM, Jeremy Boynes wrote: Geir Magnusson Jr wrote: No, but I worry about just bundling random whatever from outside the project with our releases. It would help to use the svn revision on the jar, but we should really make it clear that it's something the geronimo project created for it's use, rather than confuse people that it might be an artifact from ActiveMQ. The word 'SNAPSHOT' would help. SNAPSHOT has a specific meaning to Maven - it will cause it to check the remote repo for a newer version (by timestamp) even if a copy exists in the local repo. This is good for daily builds, a nightmare for anything where consistency is required. So when we decide to do a milestone (or release) we need to ensure there are no dependencies on versions with SNAPSHOT in them and instead use ones that contain a SVN revision number or a CVS timestamp: bad:foo-bar-1.3-SNAPSHOT.jar ok: foo-bar-1.3-20050401.jar better: foo-bar-1.3-158653.jar Going back to the original issue of an external project not wishing to do a release, we want to make it clear that this is something that we threw together ad hoc, and not something published by the external project. And I'm still not comfortable doing something like that in a real geronimo release. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: maven repo
On Apr 1, 2005, at 4:59 AM, Hari Kodungallur wrote: I read through the discussion about the need for a maven repository containing all the dependency jar files. I totally agree with that fact. In addition, I have a suggestion. Most likely users are going to be building from the latest code (tip of the trunk) or a milestone release (tip of a tag/branch). I am, obviously, assuming that the number of users needing to build from a particular revision in the past (and that revision being a non-milestone revision) is pretty small. I'm hoping that most likely users are going to be using our releases, and not building anything. How many people build tomcat, maven, hibernate, etc? So with that in mind, in addition to the central maven repository, each milestone revision can also zip up the maven repository that is needed by the release -- downlaodable separately or as part of the geronimo binary. If the build is done on a clean box (with nothing in ~/.maven/repositroy before the start of the build), then this repository is simply an archive of ~/.maven/repository directory. That way if there are any jar files that change overtime (like the SNAPSHOT jar files), they are archived. A user wanting to build a milestone source can just unzip the maven repository archive into his/her .maven/repository and then just do an offline build. The user who is building from the latest code just relies on whatever is the latest in the central maven repository. It does add a bit of redundancy, but I just wanted to throw the idea out there to see if its practical/viable. I think the phrase would be needed to *build* the release, as our milestones [aside : I think these will stop - we treated milestone as just a formal unsupported code-drop event, and it's time we start doing something more regular and usable...] and releases should have all dependencies needed to run included in the distribution. I hoping above all that this period of large change distributed across Geronimo and dependencies will come to an end, and we can start treating OpenEJB and Axis like external dependencies with their own independent lifecycle, so we can just use stable release artifacts published by those projects. I do suspect though that it really isn't going to happen until we modularize a bit so that Axis and OpenEJB are just plug-in providers of functionality needed by Geronimo, and we're a long way from that as that hasn't been the focus or a requirement for our near-term goal of certification. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Dedicated maven repo
On Mar 30, 2005, at 5:09 PM, Dain Sundstrom wrote: On Mar 30, 2005, at 3:37 AM, Geir Magnusson Jr. wrote: On Mar 30, 2005, at 5:57 AM, Dirk-Willem van Gulik wrote: All - For now, we could make a first step by just putting the geronimo build artifacts on geronimo.apache.org/maven - namely the spec jars (for now, more on that laster), the geronimo-* jars from modules. If we make publishing snapshot jars the custom whenever a change is committed (manually via maven deploy now, auto later), we can probably go a long way towards reducing some of the build misery that we go through. We've had this forever http://cvs.apache.org/repository/ Great. I'm +1, and happy to limit the ASF-hosted repo to our build artifacts to get started, and use the external proposed repo at Gluecode as a replacement for ibiblio as our primary source for external dependencies, because iBiblio is so slow and painful at times. I don't think we should move our repo just because someone believes there might possibly be a policy against it at Apache. It's discouraged because it really puts us in the distribution business for non ASF code. Yes, we do release non-ASF code as part of the release process, and there are jars in svn/cvs. The world isn't perfect. This simply too common of an excuse here. An excuse for what? I think that if you really believe there is a policy against it, then we should ask the board for an official ruling on it. I think you'd find a spectrum of answers, leaning towards no distribution of other software outside of a distribution. The world isn't perfect here. I don't like the Well, they do it too! approach, but we can try to be proactive here, and I'm willing to try the following argument if the Geronimo PMC supports it : Because we do distribute 3rd party binaries as part of our release products, we would like to make the same third party binaries available via maven download for our build. We as a PMC will treat additions or updates of third party binaries to the repo (which we will manage) with the same oversight process that we do for releases - we would do it after PMC votes. We would setup http://geronimo.apache.org/projectrepo (or some other color of the bikeshed) to do this. If this was successful, we should consider talking to other PMCs to expand the effort. I'm willing to try and sell that. We should also insist that any policy is universally enforced as there are tons of projects that have all their dependencies in cvs or an Apache hosted repo. My guess there is no policy against this (or someone has a lot of enforcement in front of them ;) I think you'd find it to be a consensus POV rather than Apache Policy #2041 the board tries to avoid setting strict policy. My order preference is cvs.apache.org/repository, geronimo.apache.org/maven, or ibiblio. ibiblio is awful and you know it. If we don't have the resources here on ASF machines, we need an alternative to make life easier for us and our users. geir -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
Here's a proposal for the Geronimo PMC regarding running a maven repository for the project here at the ASF. The basic problem is that there are many at the ASF, including board members, that believe that we shouldn't publish or distribute software that isn't created at the ASF. I was one of those until yesterday, when I thought it through for a bit. I've started some private conversations with those I know have issues with the idea to get feedback early, and in parallel we can work out a plan and incorporate their feedback if this has a chance of acceptance (I think it should...). Note that there is a slippery-slope argument against this for which there is no good answer other than the pragmatic lets minimize risk and see what happens Motivation -- I) We want a fast, controlled source of project dependencies to make it easy and fast to build Geronimo. We are able to include binary jars from other outside projects in our official releases, because a) it's clear that we are the publisher of the combined work that is our release b) there has been sufficient oversight by the releasing PMC to ensure that the licenses and re-distribution terms for the third party jars are appropriate In order to do have a maven repo that includes third party jars, we must a) make it clear that we are *NOT* the publisher of the third party jars, but we are just redistributing it under appropriate terms as defined by the publisher b) we can demonstrate that the PMC had oversight and control over the contents of the repository to monitor the content, license and re-dist terms II) For any community member that is interested in tracking the external dependencies (and there is an increased awareness in commercial users due to liability and indemnification issues), the following proposal provides a clear stream of specific messages never buried in commit noise to allow an observer to track changes in project dependencies. So the proposal is then to create a maven repository for the use of the Geronimo project. If the basic idea is sound, lets iron out the details. Here's a start : Structure - - maven structure - include a license file for each third-party artifact we have - include a INFO file for each third-party artifact containing - source of jar - source's statement about redistribution Contents - top-level index page clearly describing purpose and intent of repository (0) - all third-party dependencies needed by current and recent-in-time build (1) - snapshot versions of Geronimo build artifacts for sister projects like OpenEJB that have a [soon-to-go-away] tight dependency on core geronimo code - release versions of Geronimo build artifacts (maybe not..) (0) can we add a short note put into our maven output that says Geronimmo 3rd party dependencies will be sourced from the project-specific geronimo repository or such? (1) Do we want to keep old stuff? I think not - I think we'd want to be good ASF citizens to keep disk space usage to what is really needed. If you need an older version, for some reason, you can slog it out of ibiblio or the original source. Oversight and Process - - writable by all Geronimo committers only - openly readable (2) - any addition or update to the repo requires that - INFO and LICENSE are added/updated if needed - email sent to dev@ to inform community (3) - change accepted by PMC by lazy consensus - any third-party jar that is not an official release (like OpenEJB these days) but built from source by a Geronimo developer (w/ or w/o patches) must be marked with SNAPSHOT to make it clear that jar isn't a release from the originating project, nor an attempt by the Geronimo project to create a release or a distributable for another project. - infrastructure will be informed when we create this to ensure that in the event someone has a problem with something coming from our repo, they'll be aware and can just yank offending artifact, and know to inform the geronimo PMC about the issue (2) for now... (3) we can find technology solutions to reduce the work later - lets focus on the oversight process I think that covers the basics. Comments? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
On Mar 31, 2005, at 3:54 PM, Jeremy Boynes wrote: I think this is a good start in the right direction. The need for demonstrable oversight is clear and if anything I would like to strengthen those processes not loosen them. Some of that is already built into Maven and we should use those capabilities. More comments inline, all fine tuning. -- Jeremy Geir Magnusson Jr. wrote: Here's a proposal for the Geronimo PMC regarding running a maven repository for the project here at the ASF. The basic problem is that there are many at the ASF, including board members, that believe that we shouldn't publish or distribute software that isn't created at the ASF. I was one of those until yesterday, when I thought it through for a bit. I've started some private conversations with those I know have issues with the idea to get feedback early, and in parallel we can work out a plan and incorporate their feedback if this has a chance of acceptance (I think it should...). Note that there is a slippery-slope argument against this for which there is no good answer other than the pragmatic lets minimize risk and see what happens Motivation -- I) We want a fast, controlled source of project dependencies to make it easy and fast to build Geronimo. We are able to include binary jars from other outside projects in our official releases, because a) it's clear that we are the publisher of the combined work that is our release b) there has been sufficient oversight by the releasing PMC to ensure that the licenses and re-distribution terms for the third party jars are appropriate In order to do have a maven repo that includes third party jars, we must a) make it clear that we are *NOT* the publisher of the third party jars, but we are just redistributing it under appropriate terms as defined by the publisher b) we can demonstrate that the PMC had oversight and control over the contents of the repository to monitor the content, license and re-dist terms II) For any community member that is interested in tracking the external dependencies (and there is an increased awareness in commercial users due to liability and indemnification issues), the following proposal provides a clear stream of specific messages never buried in commit noise to allow an observer to track changes in project dependencies. So the proposal is then to create a maven repository for the use of the Geronimo project. If the basic idea is sound, lets iron out the details. Here's a start : Structure - - maven structure - include a license file for each third-party artifact we have This is a normal feature of a Maven repo. We should also require that an appropriate POM is installed so that contributors can be identified. Right - I thought of that, but the strong wish is that we make it screamingly obvious to the casual browser about the license (I guess them being in a directory called license should be a clue, but never underestimate a fool...). Same w/ copyright and contributors. This seems like an implementation detail at this point though. - include a INFO file for each third-party artifact containing - source of jar - source's statement about redistribution We should also include INFO for each release identifying the third-party jars that it uses. This means there is an easier place to look than the content of a distribution. Do you mean our releases, or the third party jars? Contents - top-level index page clearly describing purpose and intent of repository (0) - all third-party dependencies needed by current and recent-in-time build (1) - snapshot versions of Geronimo build artifacts for sister projects like OpenEJB that have a [soon-to-go-away] tight dependency on core geronimo code - release versions of Geronimo build artifacts (maybe not..) (0) can we add a short note put into our maven output that says Geronimmo 3rd party dependencies will be sourced from the project-specific geronimo repository or such? (1) Do we want to keep old stuff? I think not - I think we'd want to be good ASF citizens to keep disk space usage to what is really needed. If you need an older version, for some reason, you can slog it out of ibiblio or the original source. I think we should keep as much history as possible, at least the dependencies for all maintained branches. Ok. I'm not so sure since they should be out there in ibiblio unless they have been yanked for some reason, which would imply an administrative burden on us. If that isn't clear, a contrived example... go forward in time, a few years, and suppose some old dependency that we no longer use, care or think about has to be pulled from availability due to something - maybe SCO sues someone else. Unless it's big news, we may not ever know, and thus keep making it available for no reason other than the unlikely event someone wants to go back and rebuild
Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
On Mar 31, 2005, at 4:15 PM, Dain Sundstrom wrote: On Mar 31, 2005, at 12:54 PM, Jeremy Boynes wrote: - include a license file for each third-party artifact we have This is a normal feature of a Maven repo. We should also require that an appropriate POM is installed so that contributors can be identified. This will be a problem for ant based projects. I propose we have a minimal pom we use for these types of projects. Y - include a INFO file for each third-party artifact containing - source of jar - source's statement about redistribution We should also include INFO for each release identifying the third-party jars that it uses. This means there is an easier place to look than the content of a distribution. Can't we use the pom dependencies section for this, or are you thinking of something else? As long as it's easy and obvious to to a browser who doen't grok maven... Contents - top-level index page clearly describing purpose and intent of repository (0) - all third-party dependencies needed by current and recent-in-time build (1) - snapshot versions of Geronimo build artifacts for sister projects like OpenEJB that have a [soon-to-go-away] tight dependency on core geronimo code - release versions of Geronimo build artifacts (maybe not..) (0) can we add a short note put into our maven output that says Geronimmo 3rd party dependencies will be sourced from the project-specific geronimo repository or such? (1) Do we want to keep old stuff? I think not - I think we'd want to be good ASF citizens to keep disk space usage to what is really needed. If you need an older version, for some reason, you can slog it out of ibiblio or the original source. I think we should keep as much history as possible, at least the dependencies for all maintained branches. I would say, we never remove a jar. A SNAPSHOT jar should just be a simlink to a numbered jar (this is what maven does already). Re the snapshots, doesn't that result in piles of useless crap? I mean, why keep the old numbered jars around? The build conditions for them are variable at best, and I can't think of situations where you'd need to go and use an old one. ? Actually, the only SNAPSHOTs I think we should have in our repo are for OpenEJB because of the overhead that would be involved in using versioned releases. Once we clean up the interfaces between Geronimo and OpenEJB, I think we should switch to fully versioned jars (this is what happened with activeMQ once we got the interfaces cleaned up). I thought we also might have geronimo snapshots, because then non-geronimo openejb developers (if there are such that are active ;) could build openejb w/o having to have HEAD of G locally and built... That's the only reason I can think of (and it applies to any project that wants to tie closely to us...) geir -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: mx4j 3.0.1 dependency
if not on repos, maybe just get from project and put in your local maven repository? You can also find it here. I thought that openejb was in the maven repos list. http://openejb.codehaus.org/maven/mx4j/jars/ On Mar 31, 2005, at 6:17 PM, Hari Kodungallur wrote: FYI: I am not sure but I might have sent an email regarding this a few weeks back. The mx4j-3.0.1.jar file is not found for downloading by maven. I had downloaded it myself and put that in the .maven/repository/mx4j/jars directory. So it was building fine without any problems. But today I tried to build geronimo as a newly created user and it failed with the same problem. The build breaks in the ./specs/j2ee-management module + | Executing default Geronimo :: J2EE Application Management Specification | Memory: 20M/22M + Attempting to download mx4j-3.0.1.jar. WARNING: Failed to download mx4j-3.0.1.jar. BUILD FAILED File.. /home/newuser/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly Element... maven:reactor Line.. 217 Column 9 The build cannot continue because of the following unsatisfied dependency: mx4j-3.0.1.jar (try downloading from http://mx4j.sourceforge.net) Thanks! -Hari -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Dedicated maven repo
On Mar 30, 2005, at 5:57 AM, Dirk-Willem van Gulik wrote: This does not per-see preclde the ASF from allowing non ASF code to be distributed from ASF environments. However we do try to avoid it as it dillute our message:. Ideally we want to say 'anything you download from here is under the ASF license and has peer review and the full backing of the ASF community). While not encouraged -do- feel free to propose a structure in which this is possible; which has URLs and webpages clearly denoting the status of the alien code, etc. Dirk - We are looking to use a mechanical system (maven0 to fetch the jars, so a user wouldn't necessarily know if the source the jars that were being used to build/run came from Apache or iBiblio or another repository - they aren't reading a web page. It just happens when they build. All - For now, we could make a first step by just putting the geronimo build artifacts on geronimo.apache.org/maven - namely the spec jars (for now, more on that laster), the geronimo-* jars from modules. If we make publishing snapshot jars the custom whenever a change is committed (manually via maven deploy now, auto later), we can probably go a long way towards reducing some of the build misery that we go through. I'm +1, and happy to limit the ASF-hosted repo to our build artifacts to get started, and use the external proposed repo at Gluecode as a replacement for ibiblio as our primary source for external dependencies, because iBiblio is so slow and painful at times. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Two deployment tools
do you want comments from any of us? On Mar 30, 2005, at 5:58 PM, Dain Sundstrom wrote: Aaron, A while back we had a discussion about one vs. two deployment tools. IIRC, you wanted two tools because the command line options for the package command did not fit well into JSR88, and I thought having multiple deploy tools would be confusing. After working with the deploy code and thinking about the problem, I have come to the conclusion that you were right and *I was wrong*. I think we should break out the package command and merge it with the bootstrap deployer to create a new tool that is only available via maven and which we use to bootstrap our server during assembly. This tool would only be capable of deploying service plan files, and could either create an executable jar or an entry in a local config store. In addition, I think the tool should let us specify an ant style manifest, so we can remove all the funky arguments to the deploy command that creates a manifest. This new tool could considerably speed up the assembly process. What do you think? -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[PROPOSAL] Next milestone release (M4?)
(From a tangential discussion on pmc@, this came up and Alan noted this would be better discussed here, so I'm just moving it here) It's been 5 months since the M3 milestone release, and a *tremendous* work has gone into the project since then. We think we're functionally complete (or very close), so is now a good time to do a milestone? I'm willing to help with the mechanics to keep Dain and David (and others) cranking on certification work... Comments? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Next milestone release (M4?)
On Mar 29, 2005, at 10:40 AM, Jeremy Boynes wrote: -1 We'll ignore this as it isn't a vote :) Whilst I agree with the intention, we do not have a process defined that would allow us to generate a reproducable release. This led to several of the issues with the last M3 release that ultimately made is unusable. We must fix this before we can release another version. Specific things I think we need include in such a process: * an mechanical process for producing the candidate binaries that can be executed against any SVN tag. This would reduce the potential for minor variations by people doing the release that would result in potentially different binaries Yes * elimination of SNAPSHOT dependencies - these are by nature ephemeral making it impossible to later regenerate the same distribution Yes * a testing/review period that is at least comprehensive enough to catch the blaring defects that plagued M3 yes * verification that the src bundle actually builds and results in the same binary as we are distibuting Yes All of these were the standard way for other projects I've been involved with. No argument. But can we, with this in mind, first discuss going forward w/ a release? We're going to have to bang out a real release process for 1.0, and this is a good opportunity to get started. I volunteer to help. geir I am sure there are more -- Jeremy Geir Magnusson Jr. wrote: (From a tangential discussion on pmc@, this came up and Alan noted this would be better discussed here, so I'm just moving it here) It's been 5 months since the M3 milestone release, and a *tremendous* work has gone into the project since then. We think we're functionally complete (or very close), so is now a good time to do a milestone? I'm willing to help with the mechanics to keep Dain and David (and others) cranking on certification work... Comments? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Next milestone release (M4?)
Thoughts on naming : How about stopping with the M* convention, and do something like Geronimo 0.8. It reflects our nearness to a released version, it is not a 1.0 so no one should have expectations of 1.0 functionality, and we can rapidly get to 1.0 in the next month or -ish. geir On Mar 29, 2005, at 9:10 AM, Geir Magnusson Jr. wrote: (From a tangential discussion on pmc@, this came up and Alan noted this would be better discussed here, so I'm just moving it here) It's been 5 months since the M3 milestone release, and a *tremendous* work has gone into the project since then. We think we're functionally complete (or very close), so is now a good time to do a milestone? I'm willing to help with the mechanics to keep Dain and David (and others) cranking on certification work... Comments? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Next milestone release (M4?)
On Mar 29, 2005, at 11:33 AM, Alan D. Cabrera wrote: Geir Magnusson Jr. wrote: On Mar 29, 2005, at 10:40 AM, Jeremy Boynes wrote: -1 We'll ignore this as it isn't a vote :) Whilst I agree with the intention, we do not have a process defined that would allow us to generate a reproducable release. This led to several of the issues with the last M3 release that ultimately made is unusable. We must fix this before we can release another version. Specific things I think we need include in such a process: * an mechanical process for producing the candidate binaries that can be executed against any SVN tag. This would reduce the potential for minor variations by people doing the release that would result in potentially different binaries Yes * elimination of SNAPSHOT dependencies - these are by nature ephemeral making it impossible to later regenerate the same distribution Yes * a testing/review period that is at least comprehensive enough to catch the blaring defects that plagued M3 yes * verification that the src bundle actually builds and results in the same binary as we are distibuting Yes All of these were the standard way for other projects I've been involved with. No argument. But can we, with this in mind, first discuss going forward w/ a release? We're going to have to bang out a real release process for 1.0, and this is a good opportunity to get started. I volunteer to help. Is now a good time to talk about how Geornimo needs its own remote maven repo? Heh. I was just thinking about that, and also about the subject of OpenEJB - would there be good benefit into bringing it to Geronimo? We seem to be so interdependent... geir Regards, Alan -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [PROPOSAL] Next milestone release (M4?)
On Mar 29, 2005, at 12:16 PM, Alan D. Cabrera wrote: Geir Magnusson Jr. wrote: Heh. I was just thinking about that, and also about the subject of OpenEJB - would there be good benefit into bringing it to Geronimo? We seem to be so interdependent... Well, hopefully that will change. I would be very much opposed to including OpenEJB into Geronimo. Can I ask why? I'm just curious since we seem so interdependent on one another. I'm not a part of OpenEJB, so I don't know who else is using it, what part of the committer base is independent of Geronimo, stuff like that. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Nightly Releases
Should we target this to be the same as the release process, but use latest revision tag rather than a version #? Two birds? On Mar 29, 2005, at 2:03 PM, Dain Sundstrom wrote: +1000 Anyone that has time, please help with this one. This would be a huge help to the whole community. -dain On Mar 29, 2005, at 10:39 AM, David Blevins wrote: If there are some people with extra time, committer or not, we could *really* use nightly releases. Strike that, developers build Geronimo several times daily, it's the community that needs nightly releases. We need a bash, jelly, or even java program that can: NIGHTLY-RELEASE (run if build/test passed) checkout current date (cvs) or current rev (svn) (using 48765 as example svn rev for explanation) update the geronimo_version in etc/project.properties to 1.0-48765 zip geronimo-1.0-48765 dir into geronimo-1.0-48765-src.zip again for tar build with no tests--testing should have already been done. zip modules/assembly/target/geronimo-1.0-48765 dir into geronimo-1.0-48765.zip again for tar create MD5 files for src/bin tars and zips with openssl again but with SHA instead of MD5 create 1.0-48765 dir on nightly release server using ssh copy tar.gz, zip, md5, and sha files into 1.0-48765 using scp publish jars to remote maven repo delete any previous nightly releases over a week old. As an added bonus, I actaully had something close once and here it is: http://people.apache.org/~dblevins/svn-release.sh Ugly as heck. Someting in java or jelly would be the best option as everyone could maintain it. Maybe we can formally thank the person who get's this done by putting their name in a THANK_YOU file in every nightly release for a month or on the website for a while. -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Mark DeLaFranier - new Apache Geronimo committer
I think by definition he kicks you out of the rookie club, and you graduate to old hand :) geir On Mar 25, 2005, at 11:18 AM, Jeff Genender wrote: Congrats! Now you can join me in the rookie club! Jeff Jeremy Boynes wrote: Congratulations Mark. -- Jeremy Geir Magnusson Jr. wrote: Dear Mark, The Apache Geronimo PMC has voted to offer you commit status on the Apache Geronimo project, as I believe that Alan and others are tired of having to commit your excellent patches :) Thank you for your participation so far in the project, and we all are excited to have you as a committer. Please let us know if you wish to accept this offer. geir -- Jeff Genender http://geronimo.apache.org -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Moving to xmlbeans v2
On Mar 3, 2005, at 11:03 AM, David Jencks wrote: I have geronimo running with xmlbeans v 2. I discovered 3 problems in xmlbeans v2, one a blocker, for which I submitted a bug report and patch http://issues.apache.org/jira/browse/XMLBEANS-116 The other two problems have fairly simple workarounds. Advantages of v2: 1. bug in namespace of reference to group fixed, simplifying our plan schemas for env references 2. bug in unique key constraints fixed, allowing us to use the spec ws-client schema unmodified 3. better handling of any elements, simplifying code in service-builder for xml-attributes that uses an any element. I would like to move to v2 as soon as possible to avoid trying to maintain my patched version. +1 choices: 1. Move now, using a privately built copy of xmlbeans including my patch. 2. Move as soon as XMLBEANS-116 is fixed in xmlbeans source using a snapshot we build (unless xmlbeans is providing snapshots) 3. Move when the next beta including XMLBEANS-116 is released. Comments? I'd prefer 1, 2, and 3 in that order. thanks david jencks -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: svn commit: r155882 - geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/ReferenceMap.java
I think the copyright year in the header should be 2005. :)
geir
On Mar 1, 2005, at 9:50 PM, [EMAIL PROTECTED] wrote:
Author: dblevins
Date: Tue Mar 1 21:50:40 2005
New Revision: 155882
URL: http://svn.apache.org/viewcvs?view=revrev=155882
Log:
Handy little implementation of map that indexes instances in a
ReferenceCollection by a key of your choosing.
Added:
geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
ReferenceMap.java
Added:
geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
ReferenceMap.java
URL:
http://svn.apache.org/viewcvs/geronimo/trunk/modules/kernel/src/java/
org/apache/geronimo/gbean/ReferenceMap.java?view=autorev=155882
===
===
---
geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
ReferenceMap.java (added)
+++
geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
ReferenceMap.java Tue Mar 1 21:50:40 2005
@@ -0,0 +1,123 @@
+/**
+ *
+ * Copyright 2003-2004 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions
and
+ * limitations under the License.
+ */
+package org.apache.geronimo.gbean;
+
+import java.util.*;
+
+public class ReferenceMap implements Map, ReferenceCollectionListener
{
+private final ReferenceCollection collection;
+private final Map map;
+private final Key key;
+
+/**
+ * Constructs the ReferenceMap using a new instance of
+ * HashMap as the internal map.
+ *
+ * @param collection Must be an instance of ReferenceCollection
+ * @param map The map instance to which references will be
added/removed
+ * @param key
+ */
+public ReferenceMap(Collection collection, Map map, Key key) {
+this.collection = (ReferenceCollection) collection;
+this.map = map;
+this.key = key;
+for (Iterator iterator = this.collection.iterator();
iterator.hasNext();) {
+Object object = iterator.next();
+map.put(key.getKey(object), object);
+}
+this.collection.addReferenceCollectionListener(this);
+}
+
+/**
+ * Constructs the ReferenceMap using a new instance of
+ * HashMap as the internal map.
+ *
+ * @param collection Must be an instance of ReferenceCollection
+ * @param key
+ */
+public ReferenceMap(Collection collection, Key key) {
+this(collection, new HashMap(), key);
+}
+
+public void memberAdded(ReferenceCollectionEvent event) {
+map.put(key.getKey(event.getMember()), event.getMember());
+}
+
+public void memberRemoved(ReferenceCollectionEvent event) {
+map.remove(key.getKey(event.getMember()));
+}
+
+public interface Key {
+public Object getKey(Object object);
+}
+
+public int size() {
+return map.size();
+}
+
+public boolean isEmpty() {
+return map.isEmpty();
+}
+
+public boolean containsKey(Object key) {
+return map.containsKey(key);
+}
+
+public boolean containsValue(Object value) {
+return map.containsValue(value);
+}
+
+public Object get(Object key) {
+return map.get(key);
+}
+
+public Object put(Object key, Object value) {
+return map.put(key, value);
+}
+
+public Object remove(Object key) {
+return map.remove(key);
+}
+
+public void putAll(Map t) {
+map.putAll(t);
+}
+
+public void clear() {
+map.clear();
+}
+
+public Set keySet() {
+return map.keySet();
+}
+
+public Collection values() {
+return map.values();
+}
+
+public Set entrySet() {
+return map.entrySet();
+}
+
+public boolean equals(Object o) {
+return map.equals(o);
+}
+
+public int hashCode() {
+return map.hashCode();
+}
+}
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
Re: GBeanName [was: svn commit: r154723...]
. IMNHO, a console respecting 77 should sort the 77 names into a tree based on the hierarchy laid out in the spec. On the other hand, if you supply the properties using a Map, they are sorted into lexical order when constructing the String representation on the assumption that most Maps will be non-deterministically ordered (i.e. that in most cases the Map supplied will be a Properties object) and this provides a representation that is consistent between VMs/architectures. Playing devils advocate, what if I provide you a LinkedHashMap containing a meaningful order. Because in most cases the Map supplied will be a Properties object. We could of course check for LinkedHashMap but, also playing devil's advocate, the user could have their own implementation of Map. Or, we can add an ordered constructor e.g. GBeanName(String domain, ListString keys, ListString values) GBeanName(String domain, String[] keys, String[] values) Or, we can have two Map-type constructors e.g. GBeanName(String domain, Properties props) // we reorder GBeanName(String domain, Map props) // use order from iterator() The behaviour currently is clear and simple, and if they want a specific order they can always use the String constructor (because it preserves the value they supply). We don't need to overcomplicate this. I'm not going to press this point, other then to say I believe your analysis supports my point. Also I would hope the canonical form is the same as object name. That assumes a need for canonical name. One other thing, it doesn't look like this is escaping key values, or checking for illegal characters. Nope - there is a significant performance overhead with javax.management.ObjectName in all the validation and esacaping it does of key/value pairs. We can avoid all of that by imposing the condition that ':', ',' and '=' are reserved characters and should not be used. That is fine with me because it is further restriction on the type. But we must also include asterisk and question mark to not conflict with object name patterns (and it would allow for really ugly names). Also we should disallow the quote character to not conflict with quoted object names. Patterns work differently - ObjectName's overloading of real names and patterns is an abomination and we don't need to continue using it. That is for another discussion. If we don't restrict asterisk and question, we are expanding on the type which I am definitely -1 for as it would make it impossible to mount some names into an mbean server. So are you going to add a validation phase to scan the string for illegal characters? We don't create names in critical sections of code, so I wouldn't mind the over head. Also it should be pretty fast. I still don't see the need. The JMXGBeanRegistry will need to convert the names to valid ObjectName's to register/unregister instances with the MBeanServer but that is a very specific circumstance, and IMO a JMX problem. The BasicGBeanRegistry need not care. If we restrict characters, we should enforce the restriction. Otherwise, names will be created that can not be mounted into JMX. That means that someone could have a perfectly working system, turn on jmx and nothing works. I personally don't ever want to be in that situation. Any GBean can be registered with an MBeanServer simply by quoting the name, making escaping a JMX issue not a GBean one which should be handled in the JMX registry. If we take the restrictions above, there will not be need to escape at all. -dain Can we be done with this bikeshed now? This is not a bikeshead; these are important decisions that should be discussed. Your decisions could break seamless integration with JMX, and could require redesign of OpenEJB, ActiveMQ gbeans, and gbeans in geronimo itself. If you want, I'll implement the class and make the changes. -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: GBeanName [was: svn commit: r154723...]
On Feb 23, 2005, at 10:14 AM, Dain Sundstrom wrote: On Feb 23, 2005, at 9:24 AM, Geir Magnusson Jr wrote: On Feb 23, 2005, at 12:23 AM, David Jencks wrote: +1 on canonical name as internal string representation -1 on attempting to preserve whatever string is used to construct the gbean name I've been following from the peanut gallery, and like deployment, this seems to be a required topic for participation, so I need to ask : Why not preserve the string? it has no intrinsic meaning, does it? And thus, why not let it be preserved as a convenience for the user? That way, JSR77 name retain their conventional structure, for example... You're assuming that we build JSR77 names in a canonical format, and we don't. It is the job of the console to format a name into something readable by a user. IMO this is a tree and not a list of 200 character names. But I don't assume that geronimo is only used for things where JSR77 is relevant... I think it's really important that we remember how useful the Geronimo container is w/o J2EE... geir -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: A couple of modest proposals
On Feb 9, 2005, at 1:38 PM, David Jencks wrote: After this mornings build fiasco I estimate that I personally have spent between 5 and 10 hours dealing with the surprising behavior of the geronimo build, i.e. don't build it all unless you remember an obscure switch I'l like to suggest two things: 1. The default top level build target should reliably build all of geronimo. Special targets can be provided for those who wish to build only parts. Perhaps the project/maven files for these sub-builds could live in the directory of the part being built. 2. The addition of new modules, especially those that impact several existing modules, be preceded by discussion or at least announcement on the dev list. I'd like to volunteer some Gluecode resources (non-Geronimo-committer!) to setup a simple CI-like system - it just moronically does a clean checkout, build and email if failure to the dev list, and keeps trying until success, in which case also an email to dev list then you could look at the dev list to see where we are... (This isn't an original idea...) geir thanks david jencks -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: A couple of modest proposals
On Feb 9, 2005, at 3:02 PM, Dain Sundstrom wrote: On Feb 9, 2005, at 11:59 AM, Geir Magnusson Jr wrote: On Feb 9, 2005, at 1:38 PM, David Jencks wrote: I'd like to volunteer some Gluecode resources (non-Geronimo-committer!) to setup a simple CI-like system - it just moronically does a clean checkout, build and email if failure to the dev list, and keeps trying until success, in which case also an email to dev list then you could look at the dev list to see where we are... (This isn't an original idea...) I would call that a fire alarm. What we really need is people to be more careful with the matches. Helps prevents accidents from happening mistakes happen... -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
we now have a dep on Apache Scout
Because of recent JAXR work, we now have a dependency on Apache Scout. It turns out that at the moment, scout is not publishing snapshots to apache repo (and hence not to ibiblio), but I've brought this up w/ the project, and they will. I assume this means that everyone needs to get scout and build it to have the jars locally until the publishing happens. I don't like doing this to people - what should I do? I'd prefer a solution that didn't require me to back out my dependency additions, but will if that's the only way. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Fwd: we now have a dep on Apache Scout
Mail client senior moment... Begin forwarded message: From: Geir Magnusson Jr. [EMAIL PROTECTED] Date: February 8, 2005 7:14:16 AM EST To: [EMAIL PROTECTED] Subject: we now have a dep on Apache Scout Reply-To: [EMAIL PROTECTED] Because of recent JAXR work, we now have a dependency on Apache Scout. It turns out that at the moment, scout is not publishing snapshots to apache repo (and hence not to ibiblio), but I've brought this up w/ the project, and they will. I assume this means that everyone needs to get scout and build it to have the jars locally until the publishing happens. I don't like doing this to people - what should I do? I'd prefer a solution that didn't require me to back out my dependency additions, but will if that's the only way. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: deployment (oh, how I hate to go here...)
On Feb 7, 2005, at 11:22 AM, Aaron Mulder wrote: If I can try to summarize briefly, here's the main problem with featureful offline support: The deployer doesn't know where the server is storing things it deploys, and doesn't know what configuration engine the server is using to decide where it is storing things and what should be loaded at startup and so on. To get this information, the deployer would need to load a non-trivial amount of the server, at which point this practically *is* an online deployment. (Also: how would it work remotely?) Ok - I understand what you are saying, but we're talking about offline, and I have a slightly different POV of what that means. To me, it doesn't mean the server that I have access to is just simply turned off. I don't need to know anything about where the server stores anything. I should have no clue where the server is. IOW, I should be able to, in a parallel universe where no Geronimo server exists, run the deployer and produce a instance-independent artifact (I think they have been called 'configuration archives') that I can then transport through a rift in the time-space continuum and give to you to deploy on your machine. Now, if you don't buy the parallel universe schtick, imagine a regular production environment where developers have absolutely zero access to the production machine, and are probably separated by 1-2 layers of QA and testing, either something like dev - QA - prod or dev - QA - stage/client eval - prod In my past, deployment to QA systems came from tagged CVS. After passing QA, it was deployed to staging system from a tag in CVS... same w/ prod. Ops didn't get to modify things, like where to find the database and ish. For a default setup, these things are well-known and we could solve the most common case by simply supporting the default. It would, however, totally break for a non-default server configuration (e.g. storing deployments in database), and someone strongly objected to this. There was some talk of if you change your config store you must rebuild your deploy tool but that never really went anywhere. I think that the config store should be indep of the deployment. The deploy tool spits out a config_archive.jar, and that is given to a server for 'internal deployment'. IOW, I shouldn't care one bit about the internals of the server. I think of this in the 'unix way' - simple toolchain to create a thingy, and then another tool to send the thingy where it needs to go. Maybe this is what was intended, that the module+plan is config-store agnostic, and we just lost the plot somewhere such that deployment can happen w/o any server nearby. or maybe I just don't grok how to deploy w/o a server, and it's just a matter of documentation. As we left ApacheCon, there was a strategy established for the best way to handle deployment, and specifically offline deployment -- I think David J understood it best. I assume it was a procedure for loading just enough of the server to get the correct config store, etc., but I'd have to look at the mail trail myself. Aaron P.S. I think JSR-88 is a red herring. It has offline and online modes. I know you're an 88 expert, and I know that I'm not. I just got the sense glancing over the spec that the offline mode was fairly useless for the kind of thing we're talking about here. If we solve both problems, we can support them both in JSR-88. The main problem with JSR-88 and Geronimo is that JSR-88 doesn't have a facility for building CAR files or the executable JARs used to start the server, deploy tool, client container, etc. So our deploy tool, if it will be used for those purposes, must support more than JSR-88 does, and thus cannot restrict itself to using only the JSR-88 API to talk to the server. Right. But the 88 language is somewhat confusing, given the lack of symmetry (distribute/undeploy) and lack of a viable offline mode. I don't think of the offline problem as a weakness in 88 as much as we're applying the wrong tool for the job - we're looking at doing something beyond the scope of 88, right? geir On Mon, 7 Feb 2005, Geir Magnusson Jr. wrote: I'm missing some important clue about deployment. It seems I can deploy to a running server and distribute to a non-running server. I understand the technical difference, but I don't grok why we need this difference, and more importantly, why I can't undistribute in the event of a mistake... I'd hate to distribute the ImmediatelyScramNuclearReactorGBean and have to start the server to remove it. I was perusing JSR88, and it seems to indicate that distribute, start, stop, undeploy and redeploy are the verbs, all applying to a running server. There seems to be no concept of offline for JSR88 that's useful. I remember the Deployment Semantics Wars of 2004 with much dread, and don't wish to rekindle especially now as we're focused on J2EE functionality, but can we revisit
Re: deployment (oh, how I hate to go here...)
On Feb 7, 2005, at 12:10 PM, Aaron Mulder wrote: Ah, right. I guess we need to start every conversation by clarifying the terminology. :) Cool! I think your scenario makes sense. As far as I know, we don't have robust handling for CAR files (fully baked content, configuration, etc.) right now. There are also some issues such as if you create it based on one server environment (map resource refs, etc.), what happens if you deploy to a different server with different stuff running? Sure. I think JSR-88 envisioned that the code + deployment plan was the abstract instance-independent module that you could later deploy, undeploy, move, etc. The problem I have is that JSR-88 is J2EE specific, so what do we do for people who don't care about J2EE and want to use Geronimo The Container for other purposes? You seem to be envisioning a processed instance-specific module that you could later deploy, undeploy, move, etc. Not sure about undeploy and move, but certainly move around and deploy to any server that could meet it's dependency and resource needs. The advantage of yours is that more validation and pre-processing is done up front. The advantage of JSR-88 is that it isn't assuming that the server you delpoy to is the same as the server you packaged for. In other words, if you have to repeat all the validation and code generation and stuff just to ensure that the server you deploy to won't barf on the assumptions made by the pre-packaging tool, what's the advantage of the pre-packaging? That makes sense if we are just trying to do a generic JSR-88 tool - which I think would be nice to have around - but if we then can't take advantage of Geronimo features that aren't part of J2EE or JSR-88, then we have a problem. In any case, it would be great if you could make a list of the features that you're looking for (e.g. the requirements) so we can talk about what is or should be implemented. I'll do that. First one that comes to mind is what triggered this, namely undistribute. :) geir Aaron On Mon, 7 Feb 2005, Geir Magnusson Jr. wrote: On Feb 7, 2005, at 11:22 AM, Aaron Mulder wrote: If I can try to summarize briefly, here's the main problem with featureful offline support: The deployer doesn't know where the server is storing things it deploys, and doesn't know what configuration engine the server is using to decide where it is storing things and what should be loaded at startup and so on. To get this information, the deployer would need to load a non-trivial amount of the server, at which point this practically *is* an online deployment. (Also: how would it work remotely?) Ok - I understand what you are saying, but we're talking about offline, and I have a slightly different POV of what that means. To me, it doesn't mean the server that I have access to is just simply turned off. I don't need to know anything about where the server stores anything. I should have no clue where the server is. IOW, I should be able to, in a parallel universe where no Geronimo server exists, run the deployer and produce a instance-independent artifact (I think they have been called 'configuration archives') that I can then transport through a rift in the time-space continuum and give to you to deploy on your machine. Now, if you don't buy the parallel universe schtick, imagine a regular production environment where developers have absolutely zero access to the production machine, and are probably separated by 1-2 layers of QA and testing, either something like dev - QA - prod or dev - QA - stage/client eval - prod In my past, deployment to QA systems came from tagged CVS. After passing QA, it was deployed to staging system from a tag in CVS... same w/ prod. Ops didn't get to modify things, like where to find the database and ish. For a default setup, these things are well-known and we could solve the most common case by simply supporting the default. It would, however, totally break for a non-default server configuration (e.g. storing deployments in database), and someone strongly objected to this. There was some talk of if you change your config store you must rebuild your deploy tool but that never really went anywhere. I think that the config store should be indep of the deployment. The deploy tool spits out a config_archive.jar, and that is given to a server for 'internal deployment'. IOW, I shouldn't care one bit about the internals of the server. I think of this in the 'unix way' - simple toolchain to create a thingy, and then another tool to send the thingy where it needs to go. Maybe this is what was intended, that the module+plan is config-store agnostic, and we just lost the plot somewhere such that deployment can happen w/o any server nearby. or maybe I just don't grok how to deploy w/o a server, and it's just a matter of documentation. As we left ApacheCon, there was a strategy established for the best way to handle deployment
Re: deployment (oh, how I hate to go here...)
On Feb 7, 2005, at 1:04 PM, Dain Sundstrom wrote: On Feb 7, 2005, at 7:34 AM, Geir Magnusson Jr. wrote: It seems I can deploy to a running server and distribute to a non-running server. I understand the technical difference, but I don't grok why we need this difference, and more importantly, why I can't undistribute in the event of a mistake... This has bugged me for a while I've come to the conclusion that we have, from a users POV a) live server deployment - can deploy to a running server somewhere, local or remote b) local stopped server installation - seems to add files and update an index in the local servers config-store and what I was thinking of as 'offline deployment' doesn't exist. That's fine. We can just add it at some point when we have time. I was perusing JSR88, and it seems to indicate that distribute, start, stop, undeploy and redeploy are the verbs, all applying to a running server. There seems to be no concept of offline for JSR88 that's useful. Just because spec choose to ignore offline deployment doesn't mean that the verbs applied to a stopped server don't have meaning to the average joe. What does stop, applied to a stopped server, mean to the average joe? Or undeploy? Right now, we can't undeploy from a stopped server. (Nor do I think we should... the only thing I would suggest to do this to avoid having to dork w/ the servers private files is some sort of 'command object' that one could leave around for the server to pick up that gets it to undeploy or -ish when it wakes up. And lets distinguish between what seems to be the definition of offline here, meaning I can do stuff locally to the file system because if have access and know the layout and what I think disconnected means in 88 (since offline doesn't appear to be a defined concept). I think that disconnected is a limited functional set, described as A DeploymentManager running disconnected from its J2EE product can only configure modules but not perform administrative operations. It might not have access to any product resources. If any of the administrative operations, distribute, start, stop, undeploy, or redeploy are called, an IllegalStateException must be thrown. (JSR-88, 4.1, bullet # 3) Maybe Aaron can shed more light on this. 1) A JSR-88 compliant tool that is strict in it's support of the spec, asymmetry and all. 2) A Geronimo-specific tool that lets me have the nifty things you guys designed into this, like a redistributable configuration archive. I'll go re-read the threads... I an definitely against having more then one deploy tool. To me, the issue isn't the number of them, because we're talking about two different functional requirements. The JSR-88 tool is designed for J2EE specifically, and can't by definition do things that are Geronimo's value add to the J2EE specification. I'm all for having a generic JSR-88 tool, but I don't see why the existence of that would prohibit us from having our own Geronimo-specific tool. It is like having a mail reader to read internet mail and a separate mail tool to read corporate mail. Mail is mail and deployment is deployment. That's reasonable if you are talking about /usr/bin/mail on a unix system, reading the local mbox file, but for any modern mail client, there are separate handlers for the protocols. For example, reading the local mbox, accessing POP3, accessing IMAP are all different, handled by subsystems. I don't care if we have only one Official Deployment Tool, but it can easily be a wrapper around handlers for the different kinds of deployment. I assume that would be ok, unless you require there be only one deployer Class or something, but i don't think that's what you mean. I knew I didn't want to go here :) geir On Feb 7, 2005, at 8:22 AM, Aaron Mulder wrote: As we left ApacheCon, there was a strategy established for the best way to handle deployment, and specifically offline deployment -- I think David J understood it best. I assume it was a procedure for loading just enough of the server to get the correct config store, etc., but I'd have to look at the mail trail myself. I remember everyone liking the strategy, but I can't remember it myself anymore :) Maybe David, can jog our memories. On Feb 7, 2005, at 8:28 AM, Geir Magnusson Jr. wrote: IOW, I should be able to, in a parallel universe where no Geronimo server exists, run the deployer and produce a instance-independent artifact (I think they have been called 'configuration archives') that I can then transport through a rift in the time-space continuum and give to you to deploy on your machine. Now, if you don't buy the parallel universe schtick, imagine a regular production environment where developers have absolutely zero access to the production machine, and are probably separated by 1-2 layers of QA and testing, either something like dev - QA - prod or dev - QA - stage/client eval - prod In my past, deployment
Jonas...
http://news.com.com/Open-source+software+gets+J2EE+nod/2110-7344_3 -5557582.html?part=rsstag=5557582subj=news.7344.5 -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
http://jonas.objectweb.org/
http://jonas.objectweb.org/ Lets catch them... -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Offering Assitance for Transaction
On Jan 26, 2005, at 5:16 PM, Sandip Ghayal wrote: So let me jump into this and see I will try to provide you with working Tx interop, actually it will be non-working Tx Interop :-) Go go go! :) geir Cheers, Sandip --- Jeremy Boynes [EMAIL PROTECTED] wrote: Sandip Ghayal wrote: Hi Jeremy, For J2EE1.4 certification Geronimo Server does need to pass Transaction Interop tests. At minimum Geronimo does need a facility to inform other Application Server that Geronimo Server does not support Transaction Interop. (This is minimum requirement as per section 19.6.1 and 19.6.2 of EJB 2.1 specifications) Yeah - sorry, I was jumping to an actual working impl rather than just saying we don't do that :-) That sounds like a good area to jump in. -- Jeremy __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Is this really the correct svn certificate?
On Jan 26, 2005, at 5:26 PM, Jeremy Boynes wrote: David Jencks wrote: I am now getting a non-expired certificate: Error validating server certificate for 'https://svn.apache.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: svn.apache.org - Valid: from Jan 26 14:18:55 2005 GMT until Jan 26 14:18:55 2007 GMT - Issuer: http://www.starfieldtech.com/repository, Starfield Technologies, Inc., Scottsdale, Arizona, US - Fingerprint: 19:51:6b:9b:03:78:2b:4b:0f:02:77:ed:2a:85:ef:93:ed:b6:ff:95 Is this still apache or has svn been hijacked? thanks david jencks I believe so - at least the cert is recognized by both Firefox and IE. My guess would be that SVN does not have the appropriate root CA (http://www.valicert.com) available. Weird - my svn client thinks it's just peachy... -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: The end year in Copyright 2003-2004
On Jan 2, 2005, at 5:41 PM, Jacek Laskowski wrote: Hi, I don't remember how it's decided in the past year. Did we decide we will change the end year at commit or was it handled once and for all? Now, it's: Copyright 2003-2004 The Apache Software Foundation Do it at commit time. There is no real need to update if it hasn't changed since 2004 geir Jacek -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [Ticket System] Invalid Email
fixed. the problem should stop now On Dec 7, 2004, at 9:00 AM, David Jencks wrote: I'm getting these for every message I send. Can we spam them equally or at least unsubscribe them? thanks david jencks Begin forwarded message: From: [EMAIL PROTECTED] Date: December 7, 2004 7:55:00 AM PST To: [EMAIL PROTECTED] Subject: [Ticket System] Invalid Email You recently attempted to send an email to the Ticket-System. Sadly it failed. The reasons may include: [-] Invalid Ticket ID [-] Invalid Project [-] Poorly formatted email Please refer to the ticket page for the correct ID number. Refer to the project page for the correct email for creating a new ticket. --- Incoming Email Details Subject: Re: jetty-deployer branch will be merged back to trunk shortly Date: Tue, 7 Dec 2004 15:50:13 --- Do not reply to this email http://public.ticket-system.com/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
The Geronimo Effect
http://www.eweek.com/article2/0,1759,1728802,00.asp -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Announcement : Apache Geronimo welcomes Srinath Perera as committer
On Nov 11, 2004, at 7:15 PM, Srinath Perera wrote: Thanks Geir, Thanks everybody :) Is there any place(some one I should contact so) that I can find the information I should know being a Geronimo committer, to clarify my account access rights etc? I added the appropriate karma for you. Let us know if you have problems - do a test checkin on somethign harmles (like maven.xml)... cheers Srinath On Thu, 11 Nov 2004 13:03:33 -0800, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On behalf of the Apache Geronimo PMC, I'm pleased to announce that Srinath Perera has been granted committer status for the Apache Geronimo project. Congratulations, Srinath! -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Logging problems
On Nov 10, 2004, at 12:29 AM, Dain Sundstrom wrote: On Nov 5, 2004, at 1:29 PM, Dain Sundstrom wrote: Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. I just committed this. We now have var/log/*-log4j.properties to control the server, client and deployer logs. I'd appreciate any feed back quickly, as we are going to (try to) cut M3 tomorrow afternoon. What are the repercussions for existing users? -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: What hidden agenda?
I think that this is an important issue, but not the important one for this thread, and we're getting caught in a rathole. The conversation in question started on the dev list, had a phone call between two individuals that really respect each other and wanted to figure out where the crossed wire was, and came back to the email list. From my POV, the phone call was a non-event. The issue contained in the message that triggered this thread was that a member of the community has a problem with the spirit in which we're interacting as a community, not the mechanism through which we are. I think it's important that we all think about and discuss this specific issue. geir On Nov 8, 2004, at 8:24 AM, Jim Jagielski wrote: Within the ASF, the use of the development mailing list is *the* method of development discussion. That's the reason for it. Wikis are good for after the fact documentation. IRC is good when a small subset of developers need to get together quickly to talk about some aspects of development, but it should quickly and completely migrate to email after the pressing matters have been dealt with. Same with thinks like meetings over beer and stuff like that. The reason, of course, should be obvious: it excludes by its very nature other developers. And you can't have collaborative development when that happens. Also, in-the-open development via Email makes it easy to prevent such claims as back door activity. How can it be back door when it's openly discussed in the primary development scheme? In general, however, such things as we discussed this on IRC and we decided to do this and we'll post a summary on Email when we can is never a good idea, and can result in kindly words that development is always done on the mailing list to fiery words that people are trying to have their cake and eat it too by riding on the ASF name without adhering to its standard practices. This is an issue that every ASF project has had to deal with in one way or another. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: What hidden agenda?
On Nov 7, 2004, at 2:39 PM, Bruce Snyder wrote: Geir Magnusson Jr. wrote: On Nov 7, 2004, at 1:21 PM, Bruce Snyder wrote: Per these disagreements, I think that we should address them before we move on simply because I don't want to be bitten by these same issues again. I suggest that we learn from this issue and set forth some guidelines for the future. As for the discussion being taken offline, ASF project management and collaboration within the ASF is clearly spelled out here: http://apache.org/foundation/how-it-works.html#management and sets forth a rule that email will be the communication medium of choice, but also allows for IRC and IM. I suggest that we either: a) only use the email lists for dicussions b) use email and IRC for discussions (and post IRC server logs) c) use email, IRC and IM for dicussions (and post IRC and IM logs) This doesn't mean that you can't talk to humans when you need to go faster, need to be sure that they understand you, or just happen to be physically near them. IMO, fostering inter-human communication is *good* for the project, as we get to know each other as people. That can help strengthen the community. In the case of Aaron and Jeremy, I think it did. They felt comfortable enough to just talk. They came back to the list telling people they had a chat, and that the result was that Aaron wasn't convinced (showing that no nefarious secret plans were hatched), and Jeremy promised to explain fully when he gets time. I don't see any downside. Jeremy clearly stated that he would post a summary of the discussion but others disgreed (wanting to be part of the discussion, I gather). And they are part of it - it's all being done on the list, isn't it? We can't keep people from talking - in fact, I think that it's bad if we do. Dain and David sit next to each other, physically. Can they not talk about Geronimo? The fact is that they do, and I don't think anyone has a problem with it. So why have a problem w/ Aaron and Jeremy talking? The summary after the fact still allows for comment, but disallows being part of the actual discussion. It seems that this is another point where we should agree on a guideline for the future. I suggest that we either: a) allow offline discussions with a summary after the fact b) disallow offline discussions with a summary after the fact You can't stop a), and you can't enforce b). We'd have to scrap anything we are going to do at ApacheCon, for example, if we adopted b). a) is our de-facto operating mode. We may have to *gently* remind each other to bring things to the list when we're approaching a decision, or have some difference of opinion, but I think we don't really have a big problem with this. I agree with everything you've said, Geir. My suggestion was that others wanted to be part of the actual discussion, not an after-the-fact summary of the the discussion. I think some people view such a summary as exclusion. It certainly is an exclusion of sorts, but that's what two people chatting can be. And in this case, it wasn't an intentional action to keep people out - it's usually an intentional action just to get a point across to an individual, or discover what someone is saying. I saw it as Aaron and Jeremy were having a rough time synching on the email discussion. They had a quick call (I think it was initiated by Aaron, which I interpret to mean that he realized that there was a comm problem, and really wanted to understand what Jeremy was trying to say... and if I'm wrong about the initiator, flip the names and it's equally as positive...), and they came back and summarized [sort of]. And Jeremy said he'd explain when he had a free moment... They both were open and honest about having it, and open and honest about the contents and results. So, I understand and support the principle - to have it all open and here on the email list - but sometimes it's helpful to fallback to these 'legacy' communication systems... geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: SVN Branches
On Nov 4, 2004, at 4:09 PM, Dain Sundstrom wrote: On Nov 4, 2004, at 3:51 PM, Geir Magnusson Jr wrote: On Nov 4, 2004, at 3:45 PM, Dain Sundstrom wrote: It is covered in the subversion book http://svnbook.red-bean.com/ Can understand why you would want to branch for security, but I think you should keep working on your deployment stuff in the main trunk. If it's easy to fold back in, why not do in a branch? There's clearly a difference of opinion here, one in which both sides feel pretty strongly. Out of respect and courtesy, why not do in a branch if the downside costs of having to bring it back to trunk are so low? If there are differences they should be aired on this list. I see this as a back channel to not have Aaron implement a feature everyone liked except Jeremy. They are being aired on the list. Doing the code in a branch (which seems to have no real extra cost) is also as transparent as can be. With no added work, with everything in public, how is this a back channel, and how would this prevent, discourage or otherwise influence Aaron to not implement anything he wishes? It's rather traditional in some other projects I've been in to demonstrate contrary ideas in a way that guarantees good exposure to the community, with little disruption. For a stable project that is not under active development, I understand, but everything in geronimo is changing quickly. Should I have implemented disabled gbeans in another branch? Should Alan implement CORBA in a branch? Since this is the first time for someone to branch, I suspicious of the motivations. You might then suggest what my motivations would be for trying to diffuse this in a way that everything can be done in the open. geir -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: SVN Branches
On Nov 4, 2004, at 3:45 PM, Dain Sundstrom wrote: It is covered in the subversion book http://svnbook.red-bean.com/ Can understand why you would want to branch for security, but I think you should keep working on your deployment stuff in the main trunk. If it's easy to fold back in, why not do in a branch? There's clearly a difference of opinion here, one in which both sides feel pretty strongly. Out of respect and courtesy, why not do in a branch if the downside costs of having to bring it back to trunk are so low? It's rather traditional in some other projects I've been in to demonstrate contrary ideas in a way that guarantees good exposure to the community, with little disruption. geir -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 On Nov 4, 2004, at 3:11 PM, Aaron Mulder wrote: Is there a way to branch a few files or directories and leave the rest of the server tracking with the trunk? For example, if I wanted to branch security or deployment, in such a way that you could check out my branch and get the most current versions of everything, except my versions of security or deployment. The best I've heard is to branch everything, apply my changes, and then continually merge changes from trunk to branch. This has 2 problems: 1) I have to keep track of the last trunk rev I merged to the branch so that next time I can only merge from that point to the current rev 2) I have to resolve conflicts in my branched code, if there were any trunk changes to that Thanks, Aaron -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
JBoss response sent, posted to our news section on site
Just as an FYI to the community : http://geronimo.apache.org/news.html We had resolved the questions and concerns a while ago, and this formally finishes the matter for us. We are all happy to simply move on and put this behind us as we continue our work towards certification. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [VOTE] M3 pre ApacheCon
+1 What's in it? On Nov 3, 2004, at 8:48 AM, Jeremy Boynes wrote: On the belief we need to formally vote on making a release, should we produce a M3 release? -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: new geronimo logo contribution
On Oct 21, 2004, at 11:30 AM, Stefan Groschupf wrote: Hi, This is a very well crafted logo however; it violates one of the rules about imagery, any imagery that is stereotypical or caricatured in nature. Please remove the entry with the Indian caricature. I'm sorry, Ok, we already removed the webpage, I will change the wiki as well, I'm very sorry. I was working a long time for a company that was doing animated cartoon for TV, under a caricature I understand something different then we had contributed. I'm a bit confused and asking myself why the ASF use names and already use symbolics of indians but don't wish to see anything more. We don't symbolize human beings with the logos and images. Again sorry if someone feel we didn't respect anything, our goal was to show something positive and not show disrespect. I think thats understood by all - that no disrespect was intended. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Documentation Update
Is this project documentation? Cool! Can we get it into the project svn? On Oct 18, 2004, at 8:49 PM, Aaron Mulder wrote: I've put a couple more chapters online for the book. It now covers the basics of the product, JDBC and JMS resources, and configuring web application deployment plans. As usual, any comments would be welcome. http://chariotsolutions.com/geronimo/ Thanks, Aaron -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: CAN WE PLEASE MAKE THE BLOODY BUILD WORK
What exactly are you asking for here? it wasn't clear from the subject... On Oct 18, 2004, at 1:43 PM, Jeremy Boynes wrote: To all those who have been making improvements to the build over the last month, can we please please get back to a situation where it works reliably, every time on Windows, Linux and OSX. No magic, no mystical plugin downloads, no arcane sequences to rebuild, no patches to apply, simply: * Clear instructions on building on a clean machine * Clear instructions on rebuilding a working copy * The ability to build online without taking hours AND THEN STOP MESSING WITH IT! -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Praise Gianny
bravo! On Oct 14, 2004, at 9:19 PM, Dain Sundstrom wrote: I'd like to take a moment to praise Gianny for all his hard work on the CMP implementation. Gianny has quietly been working hard on the CMP implementation and has just completed a major chunk of CMP 2. I haven't reviewed the entire patch yet, but it looks like we now have CMR support, CMP to SQL mapping, compound primary key support, and unknown (auto-generated) primary key support. This is an amazing amount of work, especially given the complexity of the TranQL codebase. I know that others are equally impressed with all of the work that Gianny has done, and that he has recently been given commit on OpenEJB and TranQL. So thanks, Gianny, for a job well done! -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: JavaMail API
On Oct 9, 2004, at 11:23 AM, Jeremy Boynes wrote: David Jencks wrote: If I remember the discussions correctly, it is in the sandbox because it is incomplete, is not currently spec compliant, and the javamail api is not well separated from implementing javamail itself, so you would essentially have to implement all of the javamail functionality to make it usable. I could be wrong on this, I haven't looked into these issues myself. I'm sure if you finish it up everyone will be thrilled. There are also concerns about whether this API can actually be implemented from the specification - there are a lot of concrete classes in the API whose behaviour may not be sufficiently documented. I remember extensive discussions last year on the correctness of equals vs. what the RI actually does. On the other hand, we have to have an implementation of both the JavaMail and Activation APIs and we cannot redistribute Sun's due to licensing restrictions. Perhaps the time as come to finish this work, run it through the CTS and then work with Sun to clarify the Specifications. Another issue is that the JAXR specification depends on Activation so procuding its spec API will have a dependency issue. I'd say let's move these back out of the sandbox and get going. I'll be happy to take these on as my own and get started. I can use this to help work the JavaMail issue with Sun. I've been working on that for a while, and I think the licensing change is hopeless at this point, being that the removal of indemnification is probably impossible. However, there is possible strategy that worked with JAXP, and that is to not have them totally 'hand over' the software, but instead give us a copy to be the core of our 'independent implementation'. That way, they keep the RI, are the source for the technology, and we get a functional copy to keep going with. Until our version is function (or we get JavaMail and JAF from Sun), lets do this - because this is needed for our certification testing, and not currently for general users, lets just use the real JM and JAF jars from sun privately on our local machines. It's a minor pain for those of us that care, and doesn't affect the rest of the world. geir -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: unsubscribe dev@genronimo.apache.org
done In the future, please use the standard [EMAIL PROTECTED] geir On Oct 10, 2004, at 6:36 AM, Vaughn Bullard wrote: unsubscribe [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Frontend tools
On Oct 2, 2004, at 2:44 PM, Dondi Imperial wrote: I'd like to help out with frontend tools (web and desktop based) for administration and deployment. Who do I get in touch with? If there is no need or it is too early, for work on this end just ignore this email. There's always a need if you see one, and it's never too early :) Take a look at the existing 'debug console' web app, and see what you think needs to be done there. It certainly needs to be de-uglified. Also, I think that there are some people working on other tools - maybe you could start by documenting via a wiki page what's going on? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Build Succeeded-- WIKI updated
On Oct 1, 2004, at 5:20 PM, karan singh malhi wrote: Build Succeeded, I have modified the for the impatient section of the wiki. Please correct it , if i am wrong. http://wiki.apache.org/geronimo/Building#head- bfda3b0490aa0721b5b3d94d1652a563cc16e6f6 Hey! Thanks for doing this! Document on! geir karan -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Silent Connector Work Failure
On Oct 3, 2004, at 12:30 PM, Dain Sundstrom wrote:
On Oct 2, 2004, at 7:49 PM, Aaron Mulder wrote:
I hesitate to admit how much time I just spent debugging a failure
with my connector. The problem was that I was creating a Work that
was
getting a NoClassDefFoundError while it ran, and I hadn't set a
WorkListener on it, so the exception was never reported. (See
WorkerContext:290 where the only thing done with the exception is to
pass
it to a listener).
Does anyone mind if I put a message in there so if an exception
arises, the console prints Exception while running Work:
+e.getMessage()
or something along those lines? If we want to minimize output, I can
do
that if and only if workListener == NULL_WORK_ADAPTER, but however
it's
done, it would really help to get some indication from the server that
something went wrong with the application.
I propose we simple change the declaration of NULL_WORK_ADAPTER to
something like this:
private static final WorkListener NULL_WORK_LISTENER = new
WorkAdapter(){
public void workRejected(WorkEvent event) {
log.error(event.getWork().toString(), event.getException());
}
};
I was going to suggest something along those lines...
+1
geir
-dain
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
Re: svn commit: rev 47239 - in geronimo/trunk/modules: client-builder/src/java/org/apache/geronimo/client/builder connector/src/java/org/apache/geronimo/connector/deployment connector/src/test/org/apache/geronimo/connector/deployment deployment/src/java/org/apache/geronimo/deployment deployment/src/java/org/apache/geronimo/deployment/plugin deployment/src/java/org/apache/geronimo/deployment/service deployment/src/java/org/apache/geronimo/deployment/util j2ee/src/java/org/apache/geronimo/j2ee j2ee/src/java/org/apache/geronimo/j2ee/deployment j2ee/src/test/org/apache/geronimo/j2ee/deployment jetty/src/java/org/apache/geronimo/jetty/deployment
Style question... why have the param Object planFile, rather than overload with real types? On Sep 26, 2004, at 1:27 PM, Dain Sundstrom wrote: On Sep 26, 2004, at 3:55 AM, David Jencks wrote: This might be moving in a good direction overall, but one aspect totally sucks, namely that in the ModuleBuilder interface in the Module createModule(String name, Object planFile, JarFile moduleFile, URL specDDUrl, String targetPath) throws DeploymentException; method the planFile can be either a File or an XmlObject from an embedded plan. Personally I think at this point passing XmlObjects around rather than file-like objects is a better idea. The planFile parameter can either be a File, XmlBean Object or null. I thought about parsing the file directly in the EarConfigBuilder, but that would require the builder to know about all the XmlBeans schemas used in module deployers (or XmlBeans parses it into a typeless thing that looks like a DOM). I prefer to simply pass the location through to the module builder so it can handle it like it does for a standalone module with an external plan (6 one way, half a dozen the other) -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
TCK Testing Update
Hi All, I want to give a quick update about TCK testing. Things have been moving, led by Jeremy, Dain, David Blevins, David Jencks, Greg and Alan, and we have just gotten the resources organized. One is a private geronimo-tck mail list that is for NDA-signers only that are working on Geronimo J2EE TCK testing, and meant to discuss testing information that can't be discussed on the public list. The intent is to bring as much to public lists as possible, be it here or at the projects we work with (like Jetty, Apache Tomcat, OpenEJB, etc), so that the wide community can participate as much as possible. Contents of that list are of course considered confidential as it includes % of tests passed, etc, something we cannot reveal until we reach 100%. The other thing is a private svn repo for TCK testing-related materials. The intent is to put a configured TCK tree in there to make it easer for committers to bootstrap into helping, but right now it's just odds and ends needed for the testing work, like geronimo specific configuration. Access to these resources is for committers that have signed NDAs. If you wish access, please let me know. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [Vote] Confluence
On Sep 11, 2004, at 2:41 AM, Dain Sundstrom wrote: If there's a volunteer or two, I guess the next steps would be to hold a (PMC-ratified) vote and send a mail off to infrastructure@ for advice. They may wish to delay installation until a successor to nagoya is ready. MoinMoin is driving me nuts... I propose we ask Apache infrastructure team to install the Confluence wiki. Confluence is produced by the same people that made Jira, and is heavily used by other OpenSource projects such as Spring and everything at Codehaus. [ ] Yes, ask Apache infrastructure to install confluence [ ] No, don't ask Apache infrastructure to install confluence [X] I want to use Confluence, and am willing to work with the ASF Infrastructure team to get this done, including volunteering to help install, administrate and maintain. geir -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
Re: What's missing for Tomcat integration?
On Sep 10, 2004, at 9:45 AM, Shapira, Yoav wrote: Hi, After a bit of talking with Geir regarding the 1.0 M2 release still not supporting Tomcat, I thought I'd jump in and ask: what's missing for Tomcat integration, and how can I help? Yoav - thanks for coming! I've gone over the archives, but there's nothing significant on this matter since I raised this issue last March (thread titled Does Geronimo use tomcat? in the archives). Incidentally, in that thread N. Alex Rupp also said he was working on articles in this area (http://marc.theaimsgroup.com/?l=geronimo-devm=108015237832228w=2). I've yet to see them: have they been published somewhere? I've read his articles/blogs on the MVC pattern, the servlet antipattern, and how Tomcat is similar to the Irish Elk, but I haven't seen anything addressing what the problems were in integrating Tomcat into Geronimo. Anyways, since then I see Geronimo has evolved, getting closer to a release. So has Tomcat, including the (presumably) relevant area of JMX and JSR77 compliance. So I'd like an updated list of what's missing, what needs to be done, in order for Geronimo to accept Tomcat as easily/natively as it does Jetty. That should be a good start, and it's a pretty good time as far as Tomcat is concerned to make some tweaks, with the 5.5 branch still in very active development. THis is great. I think that while our goal is perfect integration, I think getting it working - not perfectly integrated, but working - is an excellent first step. It will give us feedback about what we need in Geronimo to help Tomcat integrate, and what Tomcat needs to do to become more integratable. (integrable?) geir By the way, this is no slight of offense to Jetty or any of its developers. It's a good product and I have no problems with it. I'm looking to improve both Tomcat and Geronimo with this effort. And a good weekend to all ;) Yoav Shapira Millennium Research Informatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
Re: Thread pool strategy
On Jul 13, 2004, at 5:39 PM, toby cabot wrote: On Tue, Jul 13, 2004 at 03:33:35PM -0400, Geir Magnusson Jr wrote: Is it really now as in if you don't have to wait for a thread, do it - otherwise return w/ a status indicating now wasn't possible or now as in wait until there's a thread, do it, and then return to me? three choices: doWork() - block until it's done startWork() - block until it starts and then return scheduleWork() - return now and do the work whenever. http://java.sun.com/j2ee/1.4/docs/api/javax/resource/spi/work/ WorkManager.html Reading the javadoc, all three have a param which lets me specify that the work must start immediately or be rejected. Perfect :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
Re: Thread pool strategy
On Jul 13, 2004, at 5:39 PM, toby cabot wrote: On Tue, Jul 13, 2004 at 03:33:35PM -0400, Geir Magnusson Jr wrote: Is it really now as in if you don't have to wait for a thread, do it - otherwise return w/ a status indicating now wasn't possible or now as in wait until there's a thread, do it, and then return to me? three choices: doWork() - block until it's done startWork() - block until it starts and then return scheduleWork() - return now and do the work whenever. http://java.sun.com/j2ee/1.4/docs/api/javax/resource/spi/work/ WorkManager.html Thx. needs one more : doWorkNow() :) -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
Re: Thread pool strategy
On Jul 13, 2004, at 11:47 AM, David Jencks wrote: On Tuesday, July 13, 2004, at 06:36 AM, Geir Magnusson Jr wrote: On Jul 11, 2004, at 12:40 PM, Hiram Chirino wrote: Hi David, If I remember correctly, setting a maxsize on the PooledExecutor can cause deadlocks IF your not careful with the work you give the executor to run. For example, if the executor is given some work that puts it at maxsize, and that work in turn requests that executor to do some 'other' work and waits for the work to finish, then you get a deadlock since the 'other' work does not run since it's sitting in the LinkedQueue. So the moral of the story is just be careful with what you ask the PooledExecutor to execute. Also - I haven't looked at the interface, but is there a way of figuring out out the depth of queue so you can decide not to queue up work if it wouldn't happen 'now'? Not with the plain ThreadPool. With the jca WorkManager you can request the work be done now (returns after work completes), started, (returns when thread pool starts executing the task), or scheduled (returns immediately, executes at unknown time in future). I don't know about the workmanager, or if the following makes any real sense : Is it really now as in if you don't have to wait for a thread, do it - otherwise return w/ a status indicating now wasn't possible or now as in wait until there's a thread, do it, and then return to me? geir david jencks Regards, Hiram David Jencks wrote: What I have now is a gbean that: --interface: you can either use Executor through the GBean calling mechanism or if you think that is too slow get the underlying Executor itself. --implementation Uses a PooledExecutor with a fixed minsize = maxsize and a LinkedQueue to put waiting requests on. This will keep creating threads until it is full, then put tasks on the queue and freed up threads will take them off. This uses standard Concurrent classes only. As far as I can tell any other behavior would require us to write some code, which I would expect to contain some bugs. Until we see an actual problem with this strategy I'l like to leave well enough alone. My original question was whether anyone knew of problems we would be likely to run into using this strategy. I plan to modify the JCA WorkManager to use this thread pool gbean. I'm not quite sure how thread pools are used in network/remoting, but I'd imagine they are used as gbeans, so you can replace them with another gbean with a different Executor configuration with no problems. thanks david jencks On Friday, July 9, 2004, at 10:34 AM, Dain Sundstrom wrote: On Jul 9, 2004, at 10:32 AM, Aaron Mulder wrote: There is an interface for this in 1.5 (based heavily on Doug's, it seems)... Not surprising considering Doug wrote the stuff in 1.5 :) We may want to accomodate that later, even if we use the standalone version for now. I guess that suggests that we use our own Executor interface that happens to be the same as Doug's, so that if we later switch the underlying mechanics to JDK 1.5 then we can drop the dependency on the standalone concurrency library. The nice thing about GBeans is you can have a proxy to a GBean that implements an interface that the GBean does not. We simply match up the method signatures of proxy interface with the signatures of the operations and attributes exposed from the GBean. So in Geronimo code we can use our own interface (or the one in concurrent) and if users want to use 1.5 interfaces it will still work. -dain -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
Re: Release?
Milestone me, baby. +1 On Jun 24, 2004, at 1:40 AM, Jeremy Boynes wrote: Hot deployment thing was the big thing I was waiting for in the next milestone - is there anything else imminent or should we put out another milestone release? +1 from me for a milestone. -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
Re: Special attributes
On Jun 7, 2004, at 7:49 AM, Eric Le Goff wrote: Dain Sundstrom wrote: On Jun 4, 2004, at 6:09 PM, Dain Sundstrom wrote: As part of this change the use of GBeanContext.getObjectName() and GBeanMBeanContext.getServer() are now deprecated and will be removed soon. Once they are removed I plan on renaming GBeanContext to GBeanLifecycleController and the setGBeanContext method will be removed from GBean. At that point, GBean will only have doStart(), doStop(), and doFail(), so I will rename the GBean interface to GBeanLifecycle. Done -dain Which name is better : GBeanLifecycleController or GBeanLifeCycleController ? (same for GBeanLifecycle and GBeanLifeCycle) ? English is not my native language so I was just guessing if there could be some naming issue here. I think a LifeCycle is a cardiovascular fitness machine. :) geir Eric -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
