Re: Java EE 5.0 Report Card updated
Thanks for updating this Dave...I'll probably add a link for M1 status / comments on another page. On Dec 19, 2006, at 3:06 PM, Dave Colasurdo wrote: The Java EE 5.0 Report card has been updated on the project wiki. This update incorporates all the recent 2.0-M1 activity and other recent developments relating to Java EE 5.0. Please take a second to review it for accuracy. http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+Java+EE +5.0+Report+Card Thanks -Dave- Matt Hogstrom [EMAIL PROTECTED]
Re: Java EE 5.0
On Nov 8, 2006, at 6:53 AM, Matt Hogstrom wrote: I'll be helping with 1.2 this week and next. However, if we're not near a release next Friday I am planning on branching trunk into branches/javaee5 and focusing on that. If that effort dies then so be it. If it moves forward then great. The community will decide. Matt, this seems like a strong statement for what seems to be an active thread. Regards, ALan
Re: Java EE 5.0
David Jencks wrote: I think the debate over what to do about jee 5 is hurrying down a path that only compounds and exacerbates many of the problems we have now. I really hope we can step back a little bit and find a way to solve more problems than we create and perpetuate. IIRC the main activities actually postponed until 1.2 are out the door are: - reorganize the build/svn tree so it has a core server bit and a bunch of optional bits (I think this is jdillons description) Is this the discussion about organization by function rather than type (so instead of Jetty pieces in modules and configs we would put all of the jetty pieces into a jetty plugin location)? If so, then I'm all for it but I'm not sure if it affects this discussion. - reorganize the build to build by plugin (my description of the same thing) - make maven dependencies and geronimo dependencies match (a consequence of the preceding reorganization) - make the console plugin based so each plugin includes a console bit to administer it. - make the users view of the server plugin based. IMO not solving these problems keeps our build and architecture very unpleasant to deal with, and solving most of them should not be very hard. IMO we should introduce the jee5 features according to this model. Doing so will entirely avoid the need to branch or keep 2 copies of any code. I agree with the ideas presented earlier. However, this last point is where I no longer follow. Doesn't organizing around plugins *and* supporting both j2ee 1.4 and javaee5 in the same Geronimo branch/release ensure that there *will be* duplicate code? Right now we have code to integrate Jetty 5.x in trunk. IIUC correctly that code has been duplicated and modified for Jetty 6 in the javaee5 sandbox you created. With the plugin organization approach and supporting both version of j2ee we would end up with two Jetty plugins for the same Geronimo release. Is this correct? Actually, it seems that the way we distinguish the j2ee1.4 vs. javaee5 jetty plugins is potentially problematic at the moment. A portion of the jetty version is actually included in the artifact name (geronimo-jetty6) for javaee5. This seems like it could cause problems in the future. What happens when Jetty 7 is released? We are no longer endorsing a single version of Jetty for a release of Geronimo - rather we are attempting to support multiple Jetty releases and I have to wonder what the value of this is. If we were to branch and only support javaee5 within that branch then we could just upgrade the existing jetty components as necessary with a specific version of jetty. In addition, I think several people have expressed the opinion that supporting j2ee 1.4 and jee5 code simultaneously is going to introduce some kind of code complexity or difficulty. I think I've been the only person to address this (correct me if I'm wrong) Not only are you the only person to address this but I think you are also the only person who has been able to this to build using trunk and the sparse tree. (at least I have yet to be able to get a successful build) ;-) and so far the changes I've made for this have been IMO unequivocal architectural improvements that have simplified and clarified the code base and made it easier to extend and maintain. They also haven't been that difficult. The main place this is a problem is deployment code: it's still a big mess, but its better than it was. I think that at this point most of the flexibility we'd need to support mixed j2ee 1.4/ jee5 deployments is probably in place, but I hope that as we work on more jee5 features we can considerably simplify the structure of the deployment components. To reiterate over and over again, IMO -- branching is a bad solution to the wrong problem and we should work very hard to avoid it -- supporting various j2ee 1.4- jee5 feature mixes is not hard and leads to improved architecture and simpler code. I still see complexity here for both Geronimo developers and more importantly our users. Even if it is easier then I think it will be ... what value is there in mixing j2ee1.4 and jee5 features? A javaee5 server should still be able to run applications built for j2ee1.4, right (downward capability and all that)? Why would a user have a need for a j2ee1.4 image of Geronimo 2.0? Thanks, Joe
Re: Java EE 5.0
On 11/8/06, David Jencks <[EMAIL PROTECTED]> wrote: I think we're basically going to need to solve the question of, if geronimo is completely plugin based, exactly what do we release. If we could answer that well I think the current debate would get much easier. How far is trunk from a completely plugin based server ? -- Cheers, Guillaume Nodet
Re: Java EE 5.0
On Nov 8, 2006, at 11:30 AM, Matt Hogstrom wrote: On Nov 8, 2006, at 1:58 PM, David Jencks wrote: To reiterate over and over again, IMO -- branching is a bad solution to the wrong problem and we should work very hard to avoid it Agreed -- supporting various j2ee 1.4- jee5 feature mixes is not hard and leads to improved architecture and simpler code. I think this is where we probably separate ways. In order to get reorganized and moving forward as you indicated in the re- organization of the tree 1.2 needs to be released. As such...trunk is in a holding pattern in terms of disruption. There are lots of things that need to be done on 1.2 to release it and IMHO there are precious few people that are interested in another 1.4 certified version. So I think investing a lot of time and effort in getting another 1.4 release out the door is not what I would like to work on. I believed the drum beat of release early and release often back in September but its now mid-November and there are miles to go before we get there. I'm not so sure there are so many miles to go that we wouldn't do anyway for a 2.0 beta1. Unfortunately we can't discuss tck details here, but the remaining problems in 1.2 need to get fixed for jee5 anyway. If there's anything else I'm not aware of it. What I'm suggesting is that we change the goal for trunk from a Geronimo 1.2 to a 2.0-beta1 which includes JPA support, Global JNDI, Java 1.5 and the other cool things that are in there. I think we should include jpa support in 1.2. The others you mention are already in trunk you're going to need to be specific about anything else you want :-) We liberate ourselves from certification as a precursor to releasing as its a beta (yes the work still needs to be done but it doesn't have to be the gate) and we are fully on a path towards Java EE 5.0. Personally, I don't care if we ever release another 1.4 version. If someone really wants to there is always the branches/1.x line and they are free to step up and release one. 1.4 is old news in the industry and I've never once heard anyone ask when the next 1.4 version is coming out. Users want to see OpenJPA (which is there mostly), and the other things above. I think the previous goal of 1.2 was right at the time and I think now its time to reconsider if that is the best use of our time. Personally, I don't think so but I'm a single rain drop in a storm of opinions :) What is your opinion on migrating from 1.2 to 2.0 and putting out a beta in December? I think its almost the same thing but closer to user's expectations. I think we should figure out how to include jpa support in 1.2. I think this is the only jee5 feature likely to be ready by december anyway. OpenJPA doesn't use the new tm feature so running with the j2ee 1.4 tm will have no effects. It would also be nice to include jetty 6. I think we're basically going to need to solve the question of, if geronimo is completely plugin based, exactly what do we release. If we could answer that well I think the current debate would get much easier. thanks david jencks thanks david jencks Matt Hogstrom [EMAIL PROTECTED]
Re: Java EE 5.0
On Nov 8, 2006, at 1:58 PM, David Jencks wrote: To reiterate over and over again, IMO -- branching is a bad solution to the wrong problem and we should work very hard to avoid it Agreed -- supporting various j2ee 1.4- jee5 feature mixes is not hard and leads to improved architecture and simpler code. I think this is where we probably separate ways. In order to get reorganized and moving forward as you indicated in the re- organization of the tree 1.2 needs to be released. As such...trunk is in a holding pattern in terms of disruption. There are lots of things that need to be done on 1.2 to release it and IMHO there are precious few people that are interested in another 1.4 certified version. So I think investing a lot of time and effort in getting another 1.4 release out the door is not what I would like to work on. I believed the drum beat of release early and release often back in September but its now mid-November and there are miles to go before we get there. What I'm suggesting is that we change the goal for trunk from a Geronimo 1.2 to a 2.0-beta1 which includes JPA support, Global JNDI, Java 1.5 and the other cool things that are in there. We liberate ourselves from certification as a precursor to releasing as its a beta (yes the work still needs to be done but it doesn't have to be the gate) and we are fully on a path towards Java EE 5.0. Personally, I don't care if we ever release another 1.4 version. If someone really wants to there is always the branches/1.x line and they are free to step up and release one. 1.4 is old news in the industry and I've never once heard anyone ask when the next 1.4 version is coming out. Users want to see OpenJPA (which is there mostly), and the other things above. I think the previous goal of 1.2 was right at the time and I think now its time to reconsider if that is the best use of our time. Personally, I don't think so but I'm a single rain drop in a storm of opinions :) What is your opinion on migrating from 1.2 to 2.0 and putting out a beta in December? I think its almost the same thing but closer to user's expectations. thanks david jencks Matt Hogstrom [EMAIL PROTECTED]
Re: Java EE 5.0
I think the debate over what to do about jee 5 is hurrying down a path that only compounds and exacerbates many of the problems we have now. I really hope we can step back a little bit and find a way to solve more problems than we create and perpetuate. IIRC the main activities actually postponed until 1.2 are out the door are: - reorganize the build/svn tree so it has a core server bit and a bunch of optional bits (I think this is jdillons description) - reorganize the build to build by plugin (my description of the same thing) - make maven dependencies and geronimo dependencies match (a consequence of the preceding reorganization) - make the console plugin based so each plugin includes a console bit to administer it. - make the users view of the server plugin based. IMO not solving these problems keeps our build and architecture very unpleasant to deal with, and solving most of them should not be very hard. IMO we should introduce the jee5 features according to this model. Doing so will entirely avoid the need to branch or keep 2 copies of any code. In addition, I think several people have expressed the opinion that supporting j2ee 1.4 and jee5 code simultaneously is going to introduce some kind of code complexity or difficulty. I think I've been the only person to address this (correct me if I'm wrong) and so far the changes I've made for this have been IMO unequivocal architectural improvements that have simplified and clarified the code base and made it easier to extend and maintain. They also haven't been that difficult. The main place this is a problem is deployment code: it's still a big mess, but its better than it was. I think that at this point most of the flexibility we'd need to support mixed j2ee 1.4/ jee5 deployments is probably in place, but I hope that as we work on more jee5 features we can considerably simplify the structure of the deployment components. To reiterate over and over again, IMO -- branching is a bad solution to the wrong problem and we should work very hard to avoid it -- supporting various j2ee 1.4- jee5 feature mixes is not hard and leads to improved architecture and simpler code. thanks david jencks
Re: Java EE 5.0
I like the idea of branching out 1.2 and making trunk 2.0. It will bring isolated java EE5 code out of the different people's sandbox. We can get a headstart on integrating them all together and also getting our builds and tests to work on jdk 1.5. (IMO, a sparse tree for Java EE5 won't generate that not that much interest either, esp. when we ask folks to go and builds two trees.) However, we should also make a serious effort to roll up the bug fixes from the 1.2 branch to the Java EE5 branch (or trunk or whatever you want to call it). Just recently we had to tag a trunk as dead and re-do a lot of work. Let history not repeat in this case. Top 3 reasons to have a Java EE5 branch: 1. The race is on. 2. demand from the industry/users 3. interest in the development community to work on it. These reasons are strong enough to outweigh the cons (all and any) in not doing so. +1 Cheers Prasad On 11/8/06, Kevan Miller <[EMAIL PROTECTED]> wrote: On Nov 8, 2006, at 11:01 AM, Matt Hogstrom wrote: > > 4) Change trunk to 2.0-SNAPSHOT and turn it into M1 as it stands. > No TCK required...incremental move towards Java EE 5.0 (due to > JPA), greater relevance to our users, and its a win for everyone. > > Personally, I don't think branching is the optimal solution and in > reality I think its suboptimal. However, based on the feedback > from the JUGs, the performance report on the TSS and talking to > people they are more interested in Java 1.5 and Java EE 5.0 than > another 1.4 certified release. This also means that we don't have > to invest effort in a 1.2 release which is always time consuming. Didn't mean to ignore your previous note... My mail must have been out-of-sync... That certainly works for me... I'm interested to hear from others -- especially those who have been working on 1.2... They've made a tremendous amount of progress (which greatly benefits JEE5, btw...). --kevan
Re: Java EE 5.0
On 11/8/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: 4) Change trunk to 2.0-SNAPSHOT and turn it into M1 as it stands. No TCK required...incremental move towards Java EE 5.0 (due to JPA), greater relevance to our users, and its a win for everyone. Personally, I don't think branching is the optimal solution and in reality I think its suboptimal. However, based on the feedback from the JUGs, the performance report on the TSS and talking to people they are more interested in Java 1.5 and Java EE 5.0 than another 1.4 certified release. This also means that we don't have to invest effort in a 1.2 release which is always time consuming. If everyone rallies around 1.2 then can we estimate how much longer will it take to release it? From what I understand here are some current issues that affect our ability to release what's in trunk as 1.2: - completing the TCK - specs versioning issue (all one version vs. multiple versions) - number of open JIRAs - console startup time on jetty - pending merges from 1.2-dead - fit and finish I can't speak for others but for my part I'm willing to temporarily put aside my JEE5 fetish ;-) and focus on the 1.2 release if we can make it happen very soon. Otherwise I'm +1 on Matt's new proposal for changing trunk to 2.0-SNAPSHOT and releasing it as M1 because it allows us to focus on JEE5 right away while still providing something useful to our users. Putting out an M1 also has the added benefit of sending a very clear signal that we're on the move towards JEE5. Best wishes, Paul
Re: Java EE 5.0
On Nov 8, 2006, at 12:17 PM, Kevan Miller wrote: That certainly works for me... I'm interested to hear from others -- especially those who have been working on 1.2... They've made a tremendous amount of progress (which greatly benefits JEE5, btw...). --kevan Absolutely, there isn't a thing that is in 1.2 that doesn't benefit Java EE 5.0. I think Dain and others have moved the ball forward and positioned us for the first milestone for EE 5 functionality. Major +1. If I implied anything different that wasn't my intention. Matt Hogstrom [EMAIL PROTECTED]
Re: Java EE 5.0
On Nov 8, 2006, at 11:01 AM, Matt Hogstrom wrote: 4) Change trunk to 2.0-SNAPSHOT and turn it into M1 as it stands. No TCK required...incremental move towards Java EE 5.0 (due to JPA), greater relevance to our users, and its a win for everyone. Personally, I don't think branching is the optimal solution and in reality I think its suboptimal. However, based on the feedback from the JUGs, the performance report on the TSS and talking to people they are more interested in Java 1.5 and Java EE 5.0 than another 1.4 certified release. This also means that we don't have to invest effort in a 1.2 release which is always time consuming. Didn't mean to ignore your previous note... My mail must have been out-of-sync... That certainly works for me... I'm interested to hear from others -- especially those who have been working on 1.2... They've made a tremendous amount of progress (which greatly benefits JEE5, btw...). --kevan
Re: Java EE 5.0
+1I think this would be the right approach. Having trunk become 2.0 would make a strong statement to the community and our users toward our drive for JEE 5 certification. Also it will greatly simplify our development having a full JEE 5 stream that everyone is focused working on stabilizing rather then a set of scattered sparse trees as people are already struggling with building and trying to work on JEE5.On Nov 8, 2006, at 11:01 AM, Matt Hogstrom wrote:4) Change trunk to 2.0-SNAPSHOT and turn it into M1 as it stands. No TCK required...incremental move towards Java EE 5.0 (due to JPA), greater relevance to our users, and its a win for everyone. Personally, I don't think branching is the optimal solution and in reality I think its suboptimal. However, based on the feedback from the JUGs, the performance report on the TSS and talking to people they are more interested in Java 1.5 and Java EE 5.0 than another 1.4 certified release. This also means that we don't have to invest effort in a 1.2 release which is always time consuming. -sachin
Re: Java EE 5.0
On Nov 8, 2006, at 11:04 AM, Joe Bohn wrote: Kevan Miller wrote: 2) Develop in a sparse source tree. The source tree only contains the new code that is being developed. The hope is that this reduces the overhead of merging changes. However, it will also complicate the build process -- it seems that Joe has been having problems building using this technique. It isn't just a problem of building via a sparse tree (though it does make the build process more complex). I don't think it is feasible to manage a sparse tree for when "common components" that already live in trunk need to be updated as a result of some changes for a component in the sparse tree ... see my earlier response to David. If you really want to try the sparse tree approach then I think you need to move *all* configs out of trunk and into the sparse tree which will be disruptive to trunk (and hence 1.2). Well, I'm assuming that "building" means building new jars, new/ modified configs, and new/modified assemblies. You'd have merge overhead for any overlapping components. I don't really understand why you'd move configs out of trunk... However, if a sparse tree doesn't work, then it doesn't work. I certainly haven't spent any time looking at it... --kevan
Re: Java EE 5.0
Matt Hogstrom wrote: 4) Change trunk to 2.0-SNAPSHOT and turn it into M1 as it stands.No TCK required...incremental move towards Java EE 5.0 (due to JPA), greater relevance to our users, and its a win for everyone. Personally, I don't think branching is the optimal solution and in reality I think its suboptimal. However, based on the feedback from the JUGs, the performance report on the TSS and talking to people they are more interested in Java 1.5 and Java EE 5.0 than another 1.4 certified release. This also means that we don't have to invest effort in a 1.2 release which is always time consuming. This is an interesting take on the issue. I agree that it seems like more users are interested in Java EE 5 and less interested in another 1.4 certified release. I think it might be valuable to rename trunk to be 2.0 and deliver what was originally targeted as "1.2" as the first milestone along that path. It seems that this is the best of both worlds ... we get the functional improvements of 1.2 out sooner and we begin to get traction in the community toward Java EE 5. +1 Joe
Re: Java EE 5.0
Kevan Miller wrote: 2) Develop in a sparse source tree. The source tree only contains the new code that is being developed. The hope is that this reduces the overhead of merging changes. However, it will also complicate the build process -- it seems that Joe has been having problems building using this technique. It isn't just a problem of building via a sparse tree (though it does make the build process more complex). I don't think it is feasible to manage a sparse tree for when "common components" that already live in trunk need to be updated as a result of some changes for a component in the sparse tree ... see my earlier response to David. If you really want to try the sparse tree approach then I think you need to move *all* configs out of trunk and into the sparse tree which will be disruptive to trunk (and hence 1.2). Joe
Re: Java EE 5.0
On Nov 8, 2006, at 10:39 AM, Kevan Miller wrote: On Nov 7, 2006, at 7:16 PM, David Jencks wrote: My objection to putting the jee5 work into a branch is that it's not a branch! It is currently and IMO will always remain additional code that can happily run side by side with all our current code. Creating the jee5 workspace is not going to involve copying any existing geronimo server branch: its going to involve adding new modules for new functionality. After reading ken's comments I agree that keeping it in the sandbox carries an unwanted implication that it's not ready for prime time. Seems useful to review the options: 1) Create a full branch (e.g. server/branches/jee5) which is a copy of current trunk. And develop there. Once server/branches/1.2 has been created. server/branches/jee5 could be merged onto trunk. The problem with this approach is that the overhead of merging vs. problem resolution. Either you work diligently to keep the codebases in sync, or you potentially debug problems on two codebases, and pay merge costs later... 2) Develop in a sparse source tree. The source tree only contains the new code that is being developed. The hope is that this reduces the overhead of merging changes. However, it will also complicate the build process -- it seems that Joe has been having problems building using this technique. 3) Create server/branches/1.2, now. This seems pretty much equivalent to 1). Similar merging concerns... Most changes made to branches/1.2 will require merging onto trunk. 4) Change trunk to 2.0-SNAPSHOT and turn it into M1 as it stands. No TCK required...incremental move towards Java EE 5.0 (due to JPA), greater relevance to our users, and its a win for everyone. Personally, I don't think branching is the optimal solution and in reality I think its suboptimal. However, based on the feedback from the JUGs, the performance report on the TSS and talking to people they are more interested in Java 1.5 and Java EE 5.0 than another 1.4 certified release. This also means that we don't have to invest effort in a 1.2 release which is always time consuming. If people can make reasonable progress on jee5 using 2), then that seems as close as we'll get to a win-win... --kevan Matt Hogstrom [EMAIL PROTECTED]
Re: Java EE 5.0
On Nov 7, 2006, at 7:16 PM, David Jencks wrote: My objection to putting the jee5 work into a branch is that it's not a branch! It is currently and IMO will always remain additional code that can happily run side by side with all our current code. Creating the jee5 workspace is not going to involve copying any existing geronimo server branch: its going to involve adding new modules for new functionality. After reading ken's comments I agree that keeping it in the sandbox carries an unwanted implication that it's not ready for prime time. I agree with David that we should not be putting a "sparse" branch in server/branches/. I don't necessarily agree with "will always remain additional code that can happily run side by side with all our current code", but I think that can be a future discussion... IMO, "sandbox" development does not imply "toy". It does imply "temporary location" or "experimental work" and sometimes "toy". If modules, configs, and assemblies can be built reliably from a sandbox, then I don't think that the fact that the code is in "sandbox" is a significant barrier. The code will be important, if those working on it make it so... If there's too much stigma associated with sandbox, then let's establish a convention for hosting "sparse" branches (e.g. server/ sparse/jee5 or server/sparse/jpa, etc). This all assumes that a sparse development branch is a viable solution... Seems useful to review the options: 1) Create a full branch (e.g. server/branches/jee5) which is a copy of current trunk. And develop there. Once server/branches/1.2 has been created. server/branches/jee5 could be merged onto trunk. The problem with this approach is that the overhead of merging vs. problem resolution. Either you work diligently to keep the codebases in sync, or you potentially debug problems on two codebases, and pay merge costs later... 2) Develop in a sparse source tree. The source tree only contains the new code that is being developed. The hope is that this reduces the overhead of merging changes. However, it will also complicate the build process -- it seems that Joe has been having problems building using this technique. 3) Create server/branches/1.2, now. This seems pretty much equivalent to 1). Similar merging concerns... Most changes made to branches/1.2 will require merging onto trunk. If people can make reasonable progress on jee5 using 2), then that seems as close as we'll get to a win-win... --kevan
Re: Java EE 5.0
On Nov 8, 2006, at 9:04 AM, Joe Bohn wrote: David Jencks wrote: On Nov 7, 2006, at 1:50 PM, Jacek Laskowski wrote: On 11/7/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: Whow! Very well written! I like it. It should be part of our documentation somewhere. I was leaning towards Dain's and Dave's views and thought to withdraw my +1, but now it won't happen at all. Thanks Ken! My objection to putting the jee5 work into a branch is that it's not a branch! I think that we would need to make the Java EE 5 work a true branch rather than a sparse tree. It would need to end up being a branch IMHO. It will be significantly different enough that trying to make 1.4 and 5.0 assemblies will most likely be hard and most probably a continuing source of pain. I prefer to sunset 1.4 (no one really cares about it anymore) and focus solely on 5.0. If our project is going to be relevant in the field we need something for Java EE 5.0 next year. Two years late makes us last to the game and playing catchup. I was all for 1.2 two months ago when we were on a release early and release often drum beat (which is the right one). We are now in mid- November, and I don't see 1.2 getting out of trunk anytime soon. If we wait till December January to start 5.0 then we're going to miss our opportunity to be out there for Java One. My personal prefrence if 1.2 isn't ready to branch by the end of next week is to retask 1.2 as 2.0...plan on a beta with JPA in December and put all our effort into focusing on Java EE 5.0 and leave J2EE 1.4 in the branches. If someone wants to enhance 1.4 then they are free to focus their effort there. I get the sense that Dain is pushing 1.2 but the overall community is not as interested in a 1.2 release, otherwise there would be a lot more activity on it. (No reflection on Dain as he's been turning out weekly builds as well as pulling TCK along with some help from others). I'll be helping with 1.2 this week and next. However, if we're not near a release next Friday I am planning on branching trunk into branches/javaee5 and focusing on that. If that effort dies then so be it. If it moves forward then great. The community will decide. Matt Hogstrom [EMAIL PROTECTED]
Re: Java EE 5.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Jencks wrote: > > After reading ken's comments I agree that keeping it in the sandbox > carries an unwanted implication that it's not ready for prime time. I think that's pitching it a bit strongly, depending on what you mean by 'prime time.' When I meant to convey was that while something is in the sandbox, its presence there can give the impression that it's just a toy or thought-experiment for a small (possibly single) number of people, or perhaps a proof-of-concept. When it's gotten past that point and become something that multiple people want to have persist, then a home for it should be found outside the sandbox. It sounds like the EE 5 stuff falls into that category now: something that isn't just a toy, and that people expect will have a future. Where it should go outside the sandbox is the next question, and one I'm too ignorant of the technology to have an opinion about. :-) - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRVHkx5rNPMCpn3XdAQJDlwQAmMSVK8adpetruJ3dKypewqeLl+sOfClW R+RMD+sZhV3xKZwORL/dQJGdChZi8sM1KLEU/NLl2sJzNNJDyCiZxPEfMcPz4Jyn Hrxej5XxjAoRLLzVEZOJhcRSz47MRxU3yJRjSfVUpYpH292Q124eOBaKP3CG/JPE WwGNpr8hA/A= =+A99 -END PGP SIGNATURE-
Re: Java EE 5.0
David Jencks wrote: On Nov 7, 2006, at 1:50 PM, Jacek Laskowski wrote: On 11/7/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: The implicit assumption there is that the 'developers' all have the same interests. That's not necessarily how it works. If there are some people who are interested in EE 5 but not in the work on trunk, then they probably aren't contributing anything there now. So creating a branch won't be sucking those people away from trunk, whereas *not* creating it won't advance the trunk work and *does* present an obstacle for those people. The uncertainty element here is people who are currently contributing to trunk but would switch over to an EE 5 branch if one were created. Those individuals would be happy, but the trunk work would suffer. On the other hand, part of what contributes to community is individual empowerment. If there's insufficient interest in the trunk work to advance it, then that's pretty much all she wrote. It becomes a dead horse. Trying to mandate that people put aside their own interests and work on stuff that *doesn't* interest them isn't an Apache paradigm. It has a lot more in common with commercial meet-the-deadline models. Whow! Very well written! I like it. It should be part of our documentation somewhere. I was leaning towards Dain's and Dave's views and thought to withdraw my +1, but now it won't happen at all. Thanks Ken! My objection to putting the jee5 work into a branch is that it's not a branch! I think that we would need to make the Java EE 5 work a true branch rather than a sparse tree. It is currently and IMO will always remain additional code that can happily run side by side with all our current code. Do I understand correctly that you are proposing to maintain both 1.4 assemblies and Java EE 5 assemblies from the same branch? I'm not convinced this is possible. If it is then it will probably come at a significant cost for little value. Items like the console will most likely have to change to support Java EE 5. If we are attempting to maintain compatibility with the 1.4 build then we would need to have two console images (4 configs when you factor the tomcat/jetty split). Couldn't this result in a number of confusing, mutually exclusive plugins? I think we should make a clean break from 1.4 to 1.5 and Java EE 5. Creating the jee5 workspace is not going to involve copying any existing geronimo server branch: its going to involve adding new modules for new functionality. After reading ken's comments I agree that keeping it in the sandbox carries an unwanted implication that it's not ready for prime time. The sandbox is also treated as ... well, a "sandbox" ... a play area where it doesn't really matter if things work or not at the moment. Making it a branch brings more focus and hopefully greater collaboration as it is now something that all of the developers are responsible to maintain rather than just a few interested parties. The only solution that comes close to seeming appropriate to me is to reorganize the jee5 work into plugins and move each one into an appropriate plugin area. I'm worried that this will cause build system disruption but I think we have to deal with that soon anyway. It would be great to make plugins from much of the Java EE 5 functions in any case (and we'll need them as we continue to push the modularity of Geronimo and the RYO server capabilities we want to make easier in the future). However, I'm not sure this will be possible of all of the Java EE 5 capabilities. thanks david jencks Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: Java EE 5.0
On Nov 7, 2006, at 1:50 PM, Jacek Laskowski wrote: On 11/7/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: The implicit assumption there is that the 'developers' all have the same interests. That's not necessarily how it works. If there are some people who are interested in EE 5 but not in the work on trunk, then they probably aren't contributing anything there now. So creating a branch won't be sucking those people away from trunk, whereas *not* creating it won't advance the trunk work and *does* present an obstacle for those people. The uncertainty element here is people who are currently contributing to trunk but would switch over to an EE 5 branch if one were created. Those individuals would be happy, but the trunk work would suffer. On the other hand, part of what contributes to community is individual empowerment. If there's insufficient interest in the trunk work to advance it, then that's pretty much all she wrote. It becomes a dead horse. Trying to mandate that people put aside their own interests and work on stuff that *doesn't* interest them isn't an Apache paradigm. It has a lot more in common with commercial meet-the-deadline models. Whow! Very well written! I like it. It should be part of our documentation somewhere. I was leaning towards Dain's and Dave's views and thought to withdraw my +1, but now it won't happen at all. Thanks Ken! My objection to putting the jee5 work into a branch is that it's not a branch! It is currently and IMO will always remain additional code that can happily run side by side with all our current code. Creating the jee5 workspace is not going to involve copying any existing geronimo server branch: its going to involve adding new modules for new functionality. After reading ken's comments I agree that keeping it in the sandbox carries an unwanted implication that it's not ready for prime time. The only solution that comes close to seeming appropriate to me is to reorganize the jee5 work into plugins and move each one into an appropriate plugin area. I'm worried that this will cause build system disruption but I think we have to deal with that soon anyway. thanks david jencks Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: Java EE 5.0
On 11/7/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: The implicit assumption there is that the 'developers' all have the same interests. That's not necessarily how it works. If there are some people who are interested in EE 5 but not in the work on trunk, then they probably aren't contributing anything there now. So creating a branch won't be sucking those people away from trunk, whereas *not* creating it won't advance the trunk work and *does* present an obstacle for those people. The uncertainty element here is people who are currently contributing to trunk but would switch over to an EE 5 branch if one were created. Those individuals would be happy, but the trunk work would suffer. On the other hand, part of what contributes to community is individual empowerment. If there's insufficient interest in the trunk work to advance it, then that's pretty much all she wrote. It becomes a dead horse. Trying to mandate that people put aside their own interests and work on stuff that *doesn't* interest them isn't an Apache paradigm. It has a lot more in common with commercial meet-the-deadline models. Whow! Very well written! I like it. It should be part of our documentation somewhere. I was leaning towards Dain's and Dave's views and thought to withdraw my +1, but now it won't happen at all. Thanks Ken! Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: Java EE 5.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Jencks wrote: > > I think this is a bad idea: it breaks the model that anything in > server/** is a complete server and provides no advantage I can see to > working in the sandbox. I am strongly against this. One advantage is that it formalises the effort so it's no longer people playing in the sandbox, but a legitimate shared initiative. If the 'server/** is only complete servers' model is, in fact, generally accepted, I don't see that it also means 'is only complete WORKING servers.' But if that model obtains and the EE 5 work proposed doesn't constitute a 'complete server,' then putting the work there probably doesn't make sense. But it's also reasonable for it to come out of the sandbox if people want to pursue it as more than a toy. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRVC6QJrNPMCpn3XdAQKQkQP/ev4sMFFcAo1K7NJOaCCtx+NIxWU4ZGvn BiPBzhiCHNZWov26/Z/PM2uhEjGyJT/aSuh4g6NBnHhHhzQtiOm/dfkYFmZTNOk9 2W/QprERe3eFd4X9AstZyZZrTT6QMGYhZRV/dCJZpwduVYLImcxYqMDfQoH92+mG 9zdFu+c6L6I= =4HgX -END PGP SIGNATURE-
Re: Java EE 5.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: > Do you mean that we will have two active development trees? Sounds like it. > If so, I'm against that (-1). We have tried that in the past and it > has never worked out for us. We split our developers when we need > focus the most (the end of a release), The implicit assumption there is that the 'developers' all have the same interests. That's not necessarily how it works. If there are some people who are interested in EE 5 but not in the work on trunk, then they probably aren't contributing anything there now. So creating a branch won't be sucking those people away from trunk, whereas *not* creating it won't advance the trunk work and *does* present an obstacle for those people. The uncertainty element here is people who are currently contributing to trunk but would switch over to an EE 5 branch if one were created. Those individuals would be happy, but the trunk work would suffer. On the other hand, part of what contributes to community is individual empowerment. If there's insufficient interest in the trunk work to advance it, then that's pretty much all she wrote. It becomes a dead horse. Trying to mandate that people put aside their own interests and work on stuff that *doesn't* interest them isn't an Apache paradigm. It has a lot more in common with commercial meet-the-deadline models. > and we have never successfully > kept the fixes in sync. Keeping them in sync isn't necessary. Being able to have rendezvous points at which they can be sync'd is better. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRVC4+JrNPMCpn3XdAQK71AP/UZBRhj55QUCEg+HdKAWmUl0WLyJJj7G5 eFROEG2vd3D3EF3b+KhFVtlBh9W3035Iig49cC50QO1xh5Su+ZNLRykBhpnCwRNr 0+ZvEPkvEY8nX7OcDvi5jDcXjphP/u3U+9ClqcFoY+eYKwy13tlguNm8M8xyHS6h R7F5NLSq+xk= =+8vE -END PGP SIGNATURE-
Re: Java EE 5.0
I agree that if we're building a config for the JavaEE5 item then we can create a plugin. I think the problem will come from those items that don't have a strong service-like runtime characteristics (such as the common annotations or JSTL) and therefore wouldn't normally be configs. Perhaps we can/should force these to be configs just so that we can deliver them as plugins? Joe Guillaume Nodet wrote: There is no real difference between a plugin and a car. So if Geronimo can be built using cars, it surely can be built using plugins. You just need to define the needed dependencies between the cars. One problem will come from the console, which is not pluggable yet, but the portlets could be slightly enhanced to display nicely if a needed car (gbeans) is not available. On 11/6/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 11/6/06, David Jencks <[EMAIL PROTECTED]> wrote: > I would much prefer that we develop each jee5 feature as a plugin and > put each one -- modules and configs -- into a plugin in a (new) > plugins area. Then we can move each current trunk feature into the > plugins area one by one and actually get an improved organization. > We could base assembly on the micro-g or have a separate jee5 > assembly area. Is the plugin feature strong enough to let us build one plugin for each jee5 feature? Can we divide jee on such small parts that can be represented as plugins? Won't there be any overlapping features that won't be able to be build as plugins? Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: Java EE 5.0
On 11/6/06, David Jencks <[EMAIL PROTECTED]> wrote: I would much prefer that we develop each jee5 feature as a plugin and put each one -- modules and configs -- into a plugin in a (new) plugins area. Then we can move each current trunk feature into the plugins area one by one and actually get an improved organization. We could base assembly on the micro-g or have a separate jee5 assembly area. How would that work with the J2EE 1.4 features ? I guess they all need to be pluginized too, so that you can choose between both versions. -- Cheers, Guillaume Nodet
Re: Java EE 5.0
There is no real difference between a plugin and a car. So if Geronimo can be built using cars, it surely can be built using plugins. You just need to define the needed dependencies between the cars. One problem will come from the console, which is not pluggable yet, but the portlets could be slightly enhanced to display nicely if a needed car (gbeans) is not available. On 11/6/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 11/6/06, David Jencks <[EMAIL PROTECTED]> wrote: > I would much prefer that we develop each jee5 feature as a plugin and > put each one -- modules and configs -- into a plugin in a (new) > plugins area. Then we can move each current trunk feature into the > plugins area one by one and actually get an improved organization. > We could base assembly on the micro-g or have a separate jee5 > assembly area. Is the plugin feature strong enough to let us build one plugin for each jee5 feature? Can we divide jee on such small parts that can be represented as plugins? Won't there be any overlapping features that won't be able to be build as plugins? Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl -- Cheers, Guillaume Nodet
Re: Java EE 5.0
On 11/6/06, David Jencks <[EMAIL PROTECTED]> wrote: I would much prefer that we develop each jee5 feature as a plugin and put each one -- modules and configs -- into a plugin in a (new) plugins area. Then we can move each current trunk feature into the plugins area one by one and actually get an improved organization. We could base assembly on the micro-g or have a separate jee5 assembly area. Is the plugin feature strong enough to let us build one plugin for each jee5 feature? Can we divide jee on such small parts that can be represented as plugins? Won't there be any overlapping features that won't be able to be build as plugins? Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: Java EE 5.0
+1 Anita --- Matt Hogstrom <[EMAIL PROTECTED]> wrote: We could follow David's existing > methodology in sandbox where we build trunk and have an incremental > build on top of that in branches/javaee5 and it would be visibile to > > others that wanted to start getting involved. Thoughts? > > > Matt Hogstrom > [EMAIL PROTECTED] > > > > Sponsored Link Mortgage rates near historic lows: $150,000 loan as low as $579/mo. Intro-*Terms https://www2.nextag.com/
Re: Java EE 5.0
On Nov 6, 2006, at 9:09 AM, Matt Hogstrom wrote: As far as 2.0 goes it sounds like there is work in progress here and it seems to make sense to define a home for this work. I expect that server/trunk would be destabilizing to the release Dain and Alan are working on as it involves Java 1.5 and newer spec levels. Sandbox has worked so far but I think it would help people understand the process of we had a place to start incorporating Java EE 5.0 and they could grab it and build it. I think a location in server/branches/javaee5 makes sense as a rallying point. What do other people think about bringing this the Java EE 5.0 story together in that location? We could follow David's existing methodology in sandbox where we build trunk and have an incremental build on top of that in branches/javaee5 and it would be visibile to others that wanted to start getting involved. Thoughts? I think this is a bad idea: it breaks the model that anything in server/** is a complete server and provides no advantage I can see to working in the sandbox. I am strongly against this. I would much prefer that we develop each jee5 feature as a plugin and put each one -- modules and configs -- into a plugin in a (new) plugins area. Then we can move each current trunk feature into the plugins area one by one and actually get an improved organization. We could base assembly on the micro-g or have a separate jee5 assembly area. thanks david jencks Matt Hogstrom [EMAIL PROTECTED]
Re: Java EE 5.0
On 11/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: What do other people think about bringing this the Java EE 5.0 story together in that location? We could follow David's existing methodology in sandbox where we build trunk and have an incremental build on top of that in branches/javaee5 and it would be visibile to others that wanted to start getting involved. Thoughts? Do you mean that we will have two active development trees? If so, I'm against that (-1). We have tried that in the past and it has never worked out for us. We split our developers when we need focus the most (the end of a release), and we have never successfully kept the fixes in sync. -dain
Re: Java EE 5.0
Matt Hogstrom wrote: What do other people think about bringing this the Java EE 5.0 story together in that location? We could follow David's existing methodology in sandbox where we build trunk and have an incremental build on top of that in branches/javaee5 and it would be visibile to others that wanted to start getting involved. Thoughts? +1 ... It would be great to have a branch for this that is more official than the sandbox. I would prefer to have a full branch rather than an delta branch but I understand the maintenance issues that come along with that. Joe
Re: Java EE 5.0
Matt Hogstrom wrote: What do other people think about bringing this the Java EE 5.0 story together in that location? We could follow David's existing methodology in sandbox where we build trunk and have an incremental build on top of that in branches/javaee5 and it would be visibile to others that wanted to start getting involved. Thoughts? +1 chris
Re: Java EE 5.0
On 11/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: What do other people think about bringing this the Java EE 5.0 story together in that location? We could follow David's existing methodology in sandbox where we build trunk and have an incremental build on top of that in branches/javaee5 and it would be visibile to others that wanted to start getting involved. Thoughts? +1 Paul
Re: Java EE 5.0
On 11/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: What do other people think about bringing this the Java EE 5.0 story together in that location? We could follow David's existing methodology in sandbox where we build trunk and have an incremental build on top of that in branches/javaee5 and it would be visibile to others that wanted to start getting involved. Thoughts? +1 Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
