You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jacek Laskowski <ja...@laskowski.net.pl> on 2006/11/06 18:12:46 UTC
Re: Java EE 5.0
On 11/6/06, Matt Hogstrom <ma...@hogstrom.org> 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
Re: Java EE 5.0
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----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. :-)
- --
#ken P-)}
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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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 <Ke...@golux.com> 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
matt@hogstrom.org
Re: Java EE 5.0
Posted by Joe Bohn <jo...@earthlink.net>.
David Jencks wrote:
>
> On Nov 7, 2006, at 1:50 PM, Jacek Laskowski wrote:
>
>> On 11/7/06, Rodent of Unusual Size <Ke...@golux.com> 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
Posted by Sachin Patel <sp...@gmail.com>.
+1
I 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
Posted by Joe Bohn <jo...@earthlink.net>.
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
Posted by Paul McMahan <pa...@gmail.com>.
On 11/8/06, Matt Hogstrom <ma...@hogstrom.org> 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
Posted by Guillaume Nodet <gn...@gmail.com>.
On 11/8/06, David Jencks <da...@yahoo.com> 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
Posted by David Jencks <da...@yahoo.com>.
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
> matt@hogstrom.org
>
>
>
Re: Java EE 5.0
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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
matt@hogstrom.org
Re: Java EE 5.0
Posted by Joe Bohn <jo...@earthlink.net>.
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
Posted by David Jencks <da...@yahoo.com>.
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
Posted by Prasad Kashyap <go...@gmail.com>.
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 <ke...@gmail.com> 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
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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
matt@hogstrom.org
Re: Java EE 5.0
Posted by Kevan Miller <ke...@gmail.com>.
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
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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
matt@hogstrom.org
Re: Java EE 5.0
Posted by Kevan Miller <ke...@gmail.com>.
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
Posted by Joe Bohn <jo...@earthlink.net>.
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
Posted by Kevan Miller <ke...@gmail.com>.
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
Posted by David Jencks <da...@yahoo.com>.
On Nov 7, 2006, at 1:50 PM, Jacek Laskowski wrote:
> On 11/7/06, Rodent of Unusual Size <Ke...@golux.com> 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
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 11/7/06, Rodent of Unusual Size <Ke...@golux.com> 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
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----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.
- --
#ken P-)}
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
Posted by Dain Sundstrom <da...@iq80.com>.
On 11/6/06, Matt Hogstrom <ma...@hogstrom.org> 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