You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Matt Hogstrom <ma...@hogstrom.org> on 2007/06/21 18:34:18 UTC
[DISCUSS] 2.0 Release Criteria
We've gone through the CTS grind and came out victorious http://
java.sun.com/javaee/overview/compatibility.jsp
OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
working that way too.
All in all its been an excellent six months.
So, what are we going to do for 2.0 and getting it out the door?
Here are my thoughts and we can use this thread to gather everyone
else's and come to a consensus.
2.0 Ship Criteria
Date: mid to end of July (a target only...depends on content)
Certified Assemblies
Tomcat, Axis 2 and OpenJPA
Jetty, CXF and OpenJPA
Other assemblies would be the minimal assemblies but cert doesn't
apply to them.
Work on fit and finish stuff (cleaning up error messages, improving
diagnostics, reducing footprint).
Personally, I'd like to see the full G have a footprint of about 40MB
(that's a little over 5MB larger than 1.1.1) and Minimal be around
20MB. Need to do some research on this (volunteers?)
I'm not sure how the WADI clustering presents itself across the two
different assemblies (Gianny, comments?)
Post 2.0 Items
What to do about OSGi? Seems like there has been discussion but no
real movement in this area.
Flexible Server (there has been some discussion on the list about
allowing users without a PhD in G to create their own custom assemblies.
Would be neat to Create a minimal assemblie that included ServiceMix
for a lightweight ESB endpoint
Better monitoring and diagnosis
Thoughts?
Re: [DISCUSS] 2.0 Release Criteria
Posted by Gianny Damour <gi...@optusnet.com.au>.
Hello Donald,
Indeed, this is only for the Jetty assembly, and even for the jee5
one as WADI is not enabled for the minimal one.
WADI does not depend on CXF. The problem is that the admin console
uses Spring 2.0, which discovers NamespaceHandler implementations
from specific resource files. A cxf JAR declares
org.apache.cxf.clustering.spring.NamespaceHandler as a
NamespaceHandler and this declaration is wrong. I believe this a
problem with any Web-application using Spring 2.0. I will do a full
build with a clean repo and see if it comes from me using an old
version of a cxf JAR.
Thanks,
Gianny
On 26/06/2007, at 3:19 PM, Donald Woods wrote:
> I assume this will only be for the Jetty assembly, given WADI is
> not used for the Tomcat assembly?
>
> Also, you mention a CXF depend, but can your WADI changes be used
> if the user chooses Axis2 instead of CXF for the Jetty assembly?
>
>
> -Donald
>
> Gianny Damour wrote:
>> On 22/06/2007, at 2:34 AM, Matt Hogstrom wrote:
>>> We've gone through the CTS grind and came out victorious http://
>>> java.sun.com/javaee/overview/compatibility.jsp
>>>
>>> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
>>> working that way too.
>>>
>>> All in all its been an excellent six months.
>>>
>>> So, what are we going to do for 2.0 and getting it out the door?
>>>
>>> Here are my thoughts and we can use this thread to gather
>>> everyone else's and come to a consensus.
>>>
>>> 2.0 Ship Criteria
>>> Date: mid to end of July (a target only...depends on content)
>>>
>>> Certified Assemblies
>>> Tomcat, Axis 2 and OpenJPA
>>> Jetty, CXF and OpenJPA
>>>
>>> Other assemblies would be the minimal assemblies but cert doesn't
>>> apply to them.
>>>
>>> Work on fit and finish stuff (cleaning up error messages,
>>> improving diagnostics, reducing footprint).
>>>
>>> Personally, I'd like to see the full G have a footprint of about
>>> 40MB (that's a little over 5MB larger than 1.1.1) and Minimal be
>>> around 20MB. Need to do some research on this (volunteers?)
>>>
>>> I'm not sure how the WADI clustering presents itself across the
>>> two different assemblies (Gianny, comments?)
>> Sorry for this late reply. I would like to enable the WADI admin
>> console for 2.0. I have some local changes that I will commit
>> after having sorted out a problem with a cxf JAR. In a few words,
>> I cannot start the admin console within Geronimo due to an
>> IllegalArgumentException: "Class
>> [org.apache.cxf.clustering.spring.NamespaceHandler] does not
>> implement the NamespaceHandler interface". The console works fine
>> in standalone Jetty, which is the out-of-the-box servlet container
>> of grails (Groovy on Rails, which is the framework of the admin
>> console).
>> Unfortunately, I will not be able to complete field level and
>> method level state replication. However, nothing will have to be
>> done within Geronimo except adding the aspectj javaagent to
>> benefit from load-time-weaving of aspects used to track POJO
>> instantiation and modification. On this point, if people are
>> interested to give me a hand, then please feel free to ask and I
>> will check in the new wadi-aop module.
>> Thanks,
>> Gianny
>>>
>>> Post 2.0 Items
>>>
>>> What to do about OSGi? Seems like there has been discussion but
>>> no real movement in this area.
>>> Flexible Server (there has been some discussion on the list about
>>> allowing users without a PhD in G to create their own custom
>>> assemblies.
>>> Would be neat to Create a minimal assemblie that included
>>> ServiceMix for a lightweight ESB endpoint
>>> Better monitoring and diagnosis
>>>
>>>
>>> Thoughts?
Re: [DISCUSS] 2.0 Release Criteria
Posted by Donald Woods <dw...@apache.org>.
I assume this will only be for the Jetty assembly, given WADI is not used for
the Tomcat assembly?
Also, you mention a CXF depend, but can your WADI changes be used if the user
chooses Axis2 instead of CXF for the Jetty assembly?
-Donald
Gianny Damour wrote:
> On 22/06/2007, at 2:34 AM, Matt Hogstrom wrote:
>
>> We've gone through the CTS grind and came out victorious
>> http://java.sun.com/javaee/overview/compatibility.jsp
>>
>> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
>> working that way too.
>>
>> All in all its been an excellent six months.
>>
>> So, what are we going to do for 2.0 and getting it out the door?
>>
>> Here are my thoughts and we can use this thread to gather everyone
>> else's and come to a consensus.
>>
>> 2.0 Ship Criteria
>> Date: mid to end of July (a target only...depends on content)
>>
>> Certified Assemblies
>> Tomcat, Axis 2 and OpenJPA
>> Jetty, CXF and OpenJPA
>>
>> Other assemblies would be the minimal assemblies but cert doesn't
>> apply to them.
>>
>> Work on fit and finish stuff (cleaning up error messages, improving
>> diagnostics, reducing footprint).
>>
>> Personally, I'd like to see the full G have a footprint of about 40MB
>> (that's a little over 5MB larger than 1.1.1) and Minimal be around
>> 20MB. Need to do some research on this (volunteers?)
>>
>> I'm not sure how the WADI clustering presents itself across the two
>> different assemblies (Gianny, comments?)
>
> Sorry for this late reply. I would like to enable the WADI admin console
> for 2.0. I have some local changes that I will commit after having
> sorted out a problem with a cxf JAR. In a few words, I cannot start the
> admin console within Geronimo due to an IllegalArgumentException:
> "Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not
> implement the NamespaceHandler interface". The console works fine in
> standalone Jetty, which is the out-of-the-box servlet container of
> grails (Groovy on Rails, which is the framework of the admin console).
>
> Unfortunately, I will not be able to complete field level and method
> level state replication. However, nothing will have to be done within
> Geronimo except adding the aspectj javaagent to benefit from
> load-time-weaving of aspects used to track POJO instantiation and
> modification. On this point, if people are interested to give me a hand,
> then please feel free to ask and I will check in the new wadi-aop module.
>
> Thanks,
> Gianny
>
>>
>> Post 2.0 Items
>>
>> What to do about OSGi? Seems like there has been discussion but no
>> real movement in this area.
>> Flexible Server (there has been some discussion on the list about
>> allowing users without a PhD in G to create their own custom assemblies.
>> Would be neat to Create a minimal assemblie that included ServiceMix
>> for a lightweight ESB endpoint
>> Better monitoring and diagnosis
>>
>>
>> Thoughts?
>
>
>
Re: [DISCUSS] 2.0 Release Criteria
Posted by Gianny Damour <gi...@optusnet.com.au>.
On 22/06/2007, at 2:34 AM, Matt Hogstrom wrote:
> We've gone through the CTS grind and came out victorious http://
> java.sun.com/javaee/overview/compatibility.jsp
>
> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
> working that way too.
>
> All in all its been an excellent six months.
>
> So, what are we going to do for 2.0 and getting it out the door?
>
> Here are my thoughts and we can use this thread to gather everyone
> else's and come to a consensus.
>
> 2.0 Ship Criteria
> Date: mid to end of July (a target only...depends on content)
>
> Certified Assemblies
> Tomcat, Axis 2 and OpenJPA
> Jetty, CXF and OpenJPA
>
> Other assemblies would be the minimal assemblies but cert doesn't
> apply to them.
>
> Work on fit and finish stuff (cleaning up error messages, improving
> diagnostics, reducing footprint).
>
> Personally, I'd like to see the full G have a footprint of about
> 40MB (that's a little over 5MB larger than 1.1.1) and Minimal be
> around 20MB. Need to do some research on this (volunteers?)
>
> I'm not sure how the WADI clustering presents itself across the two
> different assemblies (Gianny, comments?)
Sorry for this late reply. I would like to enable the WADI admin
console for 2.0. I have some local changes that I will commit after
having sorted out a problem with a cxf JAR. In a few words, I cannot
start the admin console within Geronimo due to an
IllegalArgumentException: "Class
[org.apache.cxf.clustering.spring.NamespaceHandler] does not
implement the NamespaceHandler interface". The console works fine in
standalone Jetty, which is the out-of-the-box servlet container of
grails (Groovy on Rails, which is the framework of the admin console).
Unfortunately, I will not be able to complete field level and method
level state replication. However, nothing will have to be done within
Geronimo except adding the aspectj javaagent to benefit from load-
time-weaving of aspects used to track POJO instantiation and
modification. On this point, if people are interested to give me a
hand, then please feel free to ask and I will check in the new wadi-
aop module.
Thanks,
Gianny
>
> Post 2.0 Items
>
> What to do about OSGi? Seems like there has been discussion but no
> real movement in this area.
> Flexible Server (there has been some discussion on the list about
> allowing users without a PhD in G to create their own custom
> assemblies.
> Would be neat to Create a minimal assemblie that included
> ServiceMix for a lightweight ESB endpoint
> Better monitoring and diagnosis
>
>
> Thoughts?
Re: [DISCUSS] 2.0 Release Criteria
Posted by Paul McMahan <pa...@gmail.com>.
Short answer:
The plan is to pick up Tomcat 6.1.0 when it becomes available. Right
now that branch is undergoing significant rework for comet support so
I wouldn't expect a release until it stabilizes.
Long answer:
GERONIMO-3206 describes how Geronimo's Tomcat component is currently
built. It is based on Tomcat's 6.0.13 release which is missing two
things that Geronimo needs in order to pass all tests:
- My patch for bugzilla 42436. It's applied to 6.0.x trunk but not
released yet.
- David Jencks' annotation patch, which they decided to apply to
6.1.0 (trunk) instead of their 6.0.x maintenance stream. It should
be available in 6.1.0.
I saw where you had posted in Vamsi's bugzilla asking them to make
his patch available in a 6.0.x release in time for Geronimo 2.0.
Please keep in mind that even if they apply that patch and vote a new
6.0.x release in the time frame you requested (July) we would still
need to merge David's annotation patch since they did not apply it to
6.0.x. That is unless you would rather request that they apply
Vamsi's patch to trunk and release 6.1.0. In that case they would
also need to apply my patch for the regression problem in bugzilla
42559 (I think Remy plans to do that eventually since he already
applied it to 6.0.x).
Best wishes,
Paul
On Jul 9, 2007, at 1:24 PM, Donald Woods wrote:
> What's the status of a new Tomcat release before we release 2.0?
>
> We still have the private patches/build from GERONIMO-3010/3206 and
> another bug opened by Vamsi in GERONIMO-3273.
>
>
> -Donald
>
> Matt Hogstrom wrote:
>> We've gone through the CTS grind and came out victorious http://
>> java.sun.com/javaee/overview/compatibility.jsp
>> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
>> working that way too.
>> All in all its been an excellent six months.
>> So, what are we going to do for 2.0 and getting it out the door?
>> Here are my thoughts and we can use this thread to gather everyone
>> else's and come to a consensus.
>> 2.0 Ship Criteria
>> Date: mid to end of July (a target only...depends on content)
>> Certified Assemblies
>> Tomcat, Axis 2 and OpenJPA
>> Jetty, CXF and OpenJPA
>> Other assemblies would be the minimal assemblies but cert doesn't
>> apply to them.
>> Work on fit and finish stuff (cleaning up error messages,
>> improving diagnostics, reducing footprint).
>> Personally, I'd like to see the full G have a footprint of about
>> 40MB (that's a little over 5MB larger than 1.1.1) and Minimal be
>> around 20MB. Need to do some research on this (volunteers?)
>> I'm not sure how the WADI clustering presents itself across the
>> two different assemblies (Gianny, comments?)
>> Post 2.0 Items
>> What to do about OSGi? Seems like there has been discussion but
>> no real movement in this area.
>> Flexible Server (there has been some discussion on the list about
>> allowing users without a PhD in G to create their own custom
>> assemblies.
>> Would be neat to Create a minimal assemblie that included
>> ServiceMix for a lightweight ESB endpoint
>> Better monitoring and diagnosis
>> Thoughts?
Re: [DISCUSS] 2.0 Release Criteria
Posted by Donald Woods <dw...@apache.org>.
What's the status of a new Tomcat release before we release 2.0?
We still have the private patches/build from GERONIMO-3010/3206 and another
bug opened by Vamsi in GERONIMO-3273.
-Donald
Matt Hogstrom wrote:
> We've gone through the CTS grind and came out victorious
> http://java.sun.com/javaee/overview/compatibility.jsp
>
> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
> working that way too.
>
> All in all its been an excellent six months.
>
> So, what are we going to do for 2.0 and getting it out the door?
>
> Here are my thoughts and we can use this thread to gather everyone
> else's and come to a consensus.
>
> 2.0 Ship Criteria
> Date: mid to end of July (a target only...depends on content)
>
> Certified Assemblies
> Tomcat, Axis 2 and OpenJPA
> Jetty, CXF and OpenJPA
>
> Other assemblies would be the minimal assemblies but cert doesn't apply
> to them.
>
> Work on fit and finish stuff (cleaning up error messages, improving
> diagnostics, reducing footprint).
>
> Personally, I'd like to see the full G have a footprint of about 40MB
> (that's a little over 5MB larger than 1.1.1) and Minimal be around
> 20MB. Need to do some research on this (volunteers?)
>
> I'm not sure how the WADI clustering presents itself across the two
> different assemblies (Gianny, comments?)
>
> Post 2.0 Items
>
> What to do about OSGi? Seems like there has been discussion but no real
> movement in this area.
> Flexible Server (there has been some discussion on the list about
> allowing users without a PhD in G to create their own custom assemblies.
> Would be neat to Create a minimal assemblie that included ServiceMix for
> a lightweight ESB endpoint
> Better monitoring and diagnosis
>
>
> Thoughts?
>
>
Re: [DISCUSS] 2.0 Release Criteria
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Jun 21, 2007, at 8:49 PM, Jay D. McHugh wrote:
> Has anyone checked to see if the ConcurrentModificationException
> that blocked 1.2 is affecting 2.0?
On the list...
I've recreated the environment but I'm getting a connection error
where we run out of connections. I owe this to Dain and it may be
an issue for 2.0...we'll see.
>
> If it is, we should probably make sure that it gets fixed before
> doing a final release on 2.0 (plus, then 1.2 will finally be able
> to get released too).
>
Re: [DISCUSS] 2.0 Release Criteria
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
Has anyone checked to see if the ConcurrentModificationException that
blocked 1.2 is affecting 2.0?
If it is, we should probably make sure that it gets fixed before doing a
final release on 2.0 (plus, then 1.2 will finally be able to get
released too).
Jay
Matt Hogstrom wrote:
> We've gone through the CTS grind and came out victorious
> http://java.sun.com/javaee/overview/compatibility.jsp
>
> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
> working that way too.
>
> All in all its been an excellent six months.
>
> So, what are we going to do for 2.0 and getting it out the door?
>
> Here are my thoughts and we can use this thread to gather everyone
> else's and come to a consensus.
>
> 2.0 Ship Criteria
> Date: mid to end of July (a target only...depends on content)
>
> Certified Assemblies
> Tomcat, Axis 2 and OpenJPA
> Jetty, CXF and OpenJPA
>
> Other assemblies would be the minimal assemblies but cert doesn't
> apply to them.
>
> Work on fit and finish stuff (cleaning up error messages, improving
> diagnostics, reducing footprint).
>
> Personally, I'd like to see the full G have a footprint of about 40MB
> (that's a little over 5MB larger than 1.1.1) and Minimal be around
> 20MB. Need to do some research on this (volunteers?)
>
> I'm not sure how the WADI clustering presents itself across the two
> different assemblies (Gianny, comments?)
>
> Post 2.0 Items
>
> What to do about OSGi? Seems like there has been discussion but no
> real movement in this area.
> Flexible Server (there has been some discussion on the list about
> allowing users without a PhD in G to create their own custom assemblies.
> Would be neat to Create a minimal assemblie that included ServiceMix
> for a lightweight ESB endpoint
> Better monitoring and diagnosis
>
>
> Thoughts?
>
>
>
Re: [DISCUSS] 2.0 Release Criteria
Posted by Prasad Kashyap <go...@gmail.com>.
On 6/21/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> We've gone through the CTS grind and came out victorious http://
> java.sun.com/javaee/overview/compatibility.jsp
>
> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
> working that way too.
>
> All in all its been an excellent six months.
>
> So, what are we going to do for 2.0 and getting it out the door?
>
> Here are my thoughts and we can use this thread to gather everyone
> else's and come to a consensus.
>
> 2.0 Ship Criteria
> Date: mid to end of July (a target only...depends on content)
>
> Certified Assemblies
> Tomcat, Axis 2 and OpenJPA
> Jetty, CXF and OpenJPA
>
> Other assemblies would be the minimal assemblies but cert doesn't
> apply to them.
>
> Work on fit and finish stuff (cleaning up error messages, improving
> diagnostics, reducing footprint).
>
> Personally, I'd like to see the full G have a footprint of about 40MB
> (that's a little over 5MB larger than 1.1.1) and Minimal be around
> 20MB. Need to do some research on this (volunteers?)
Another thing that comes to mind is the runtime footprint. Isn't that
another thing that we should evaluate as a metric ? Thoughts ?
Cheers
Prasad
>
> I'm not sure how the WADI clustering presents itself across the two
> different assemblies (Gianny, comments?)
>
> Post 2.0 Items
>
> What to do about OSGi? Seems like there has been discussion but no
> real movement in this area.
> Flexible Server (there has been some discussion on the list about
> allowing users without a PhD in G to create their own custom assemblies.
> Would be neat to Create a minimal assemblie that included ServiceMix
> for a lightweight ESB endpoint
> Better monitoring and diagnosis
>
>
> Thoughts?
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Prasad Kashyap <go...@gmail.com>.
Yeah.. That is what I had last night. But it had many duplicates.
Maybe I should go back to that version
Cheers
Prasad
On 6/28/07, Donald Woods <dw...@apache.org> wrote:
> Better, but can you create a table that excludes the version?
> That would allow us to compare similar artifacts, like
> repository/org/codehaus/castor/castor
> which would show us any growth between Castor 0.9.5.3 to 1.0.5.
>
> -Donald
>
> Prasad Kashyap wrote:
> > Here is a spreadsheet of the comparison between the disk usage (du -k)
> > values of v1.2 and v2.0.
> >
> > http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ&gid=0
> >
> > There are 2 sheets. The first sheet stops at the ${version} dir in the
> > repo structure. The 2nd sheet goes all the way into the repo tree.
> >
> > It's a google spreadsheet. I don't know how I can share this so that
> > all can edit it. But just ask me and I will give you permission.
> >
> > Cheers
> > Prasad
> >
> > On 6/28/07, Jay D. McHugh <ja...@joyfulnoisewebdesign.com> wrote:
> >> You are right Prasad,
> >>
> >> I messed something up when I was building my tables.
> >> "repository/geronimo" is in the installed directory but not in my
> >> database.
> >>
> >> I'll rebuild the table and see what comes out. Also, I'll 'map' the
> >> "repository/geronimo" to "repository/org/apache/geronimo" so that the
> >> table makes sense.
> >>
> >>
> >> Jay
> >>
> >> Prasad Kashyap wrote:
> >> > Matt, Jay,
> >> >
> >> > The repository shifted from repository/geronimo to repository/o.a.g
> >> > from v1.2 onwards. We'd have to compare it against that directory to
> >> > get a good picture.. I added the same comments to your wiki page.
> >> >
> >> >
> >> http://cwiki.apache.org/confluence/display/GMOxDEV/Installed+size+comparison+%281.1.1%2C+1.2%2C+2.0%29?focusedCommentId=60511#comment-60511
> >>
> >> >
> >> >
> >> > Please check out a similar comparison between just 1.2 and 2.0.
> >> > http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ
> >> >
> >> > This can be tuned further.
> >> >
> >> > Cheers
> >> > Prasad
> >> >
> >> > On 6/27/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> >> >>
> >> >> On Jun 26, 2007, at 10:57 PM, Jay D. McHugh wrote:
> >> >>
> >> >> > In order to (hopefully) simplify finding where the increase in
> >> >> > footprint size comes from, I made a new page on the wiki:
> >> >> >
> >> >> > http://cwiki.apache.org/confluence/x/TOw
> >> >> >
> >> >> > Jay
> >> >> >>
> >> >>
> >> >> Jay, this is excellent. Clearly the pesky repository is a major
> >> >> contributor. It is interesting that the growth from 1.1.1 to 1.2 and
> >> >> beyond. I'm wondering if the Maven transient dependencies have
> >> >> anything to do with this ?
> >> >>
> >> >> >> Me ! Me ! Me !
> >> >> >>
> >> >> >> Cheers
> >> >> >> Prasad
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >
> >
>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Prasad Kashyap <go...@gmail.com>.
Try this now.
http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ
It could add some more finer touches. But it gives a lot of info as is.
Cheers
Prasad
On 6/28/07, Donald Woods <dw...@apache.org> wrote:
> Better, but can you create a table that excludes the version?
> That would allow us to compare similar artifacts, like
> repository/org/codehaus/castor/castor
> which would show us any growth between Castor 0.9.5.3 to 1.0.5.
>
> -Donald
>
> Prasad Kashyap wrote:
> > Here is a spreadsheet of the comparison between the disk usage (du -k)
> > values of v1.2 and v2.0.
> >
> > http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ&gid=0
> >
> > There are 2 sheets. The first sheet stops at the ${version} dir in the
> > repo structure. The 2nd sheet goes all the way into the repo tree.
> >
> > It's a google spreadsheet. I don't know how I can share this so that
> > all can edit it. But just ask me and I will give you permission.
> >
> > Cheers
> > Prasad
> >
> > On 6/28/07, Jay D. McHugh <ja...@joyfulnoisewebdesign.com> wrote:
> >> You are right Prasad,
> >>
> >> I messed something up when I was building my tables.
> >> "repository/geronimo" is in the installed directory but not in my
> >> database.
> >>
> >> I'll rebuild the table and see what comes out. Also, I'll 'map' the
> >> "repository/geronimo" to "repository/org/apache/geronimo" so that the
> >> table makes sense.
> >>
> >>
> >> Jay
> >>
> >> Prasad Kashyap wrote:
> >> > Matt, Jay,
> >> >
> >> > The repository shifted from repository/geronimo to repository/o.a.g
> >> > from v1.2 onwards. We'd have to compare it against that directory to
> >> > get a good picture.. I added the same comments to your wiki page.
> >> >
> >> >
> >> http://cwiki.apache.org/confluence/display/GMOxDEV/Installed+size+comparison+%281.1.1%2C+1.2%2C+2.0%29?focusedCommentId=60511#comment-60511
> >>
> >> >
> >> >
> >> > Please check out a similar comparison between just 1.2 and 2.0.
> >> > http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ
> >> >
> >> > This can be tuned further.
> >> >
> >> > Cheers
> >> > Prasad
> >> >
> >> > On 6/27/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> >> >>
> >> >> On Jun 26, 2007, at 10:57 PM, Jay D. McHugh wrote:
> >> >>
> >> >> > In order to (hopefully) simplify finding where the increase in
> >> >> > footprint size comes from, I made a new page on the wiki:
> >> >> >
> >> >> > http://cwiki.apache.org/confluence/x/TOw
> >> >> >
> >> >> > Jay
> >> >> >>
> >> >>
> >> >> Jay, this is excellent. Clearly the pesky repository is a major
> >> >> contributor. It is interesting that the growth from 1.1.1 to 1.2 and
> >> >> beyond. I'm wondering if the Maven transient dependencies have
> >> >> anything to do with this ?
> >> >>
> >> >> >> Me ! Me ! Me !
> >> >> >>
> >> >> >> Cheers
> >> >> >> Prasad
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >
> >
>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Donald Woods <dw...@apache.org>.
Better, but can you create a table that excludes the version?
That would allow us to compare similar artifacts, like
repository/org/codehaus/castor/castor
which would show us any growth between Castor 0.9.5.3 to 1.0.5.
-Donald
Prasad Kashyap wrote:
> Here is a spreadsheet of the comparison between the disk usage (du -k)
> values of v1.2 and v2.0.
>
> http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ&gid=0
>
> There are 2 sheets. The first sheet stops at the ${version} dir in the
> repo structure. The 2nd sheet goes all the way into the repo tree.
>
> It's a google spreadsheet. I don't know how I can share this so that
> all can edit it. But just ask me and I will give you permission.
>
> Cheers
> Prasad
>
> On 6/28/07, Jay D. McHugh <ja...@joyfulnoisewebdesign.com> wrote:
>> You are right Prasad,
>>
>> I messed something up when I was building my tables.
>> "repository/geronimo" is in the installed directory but not in my
>> database.
>>
>> I'll rebuild the table and see what comes out. Also, I'll 'map' the
>> "repository/geronimo" to "repository/org/apache/geronimo" so that the
>> table makes sense.
>>
>>
>> Jay
>>
>> Prasad Kashyap wrote:
>> > Matt, Jay,
>> >
>> > The repository shifted from repository/geronimo to repository/o.a.g
>> > from v1.2 onwards. We'd have to compare it against that directory to
>> > get a good picture.. I added the same comments to your wiki page.
>> >
>> >
>> http://cwiki.apache.org/confluence/display/GMOxDEV/Installed+size+comparison+%281.1.1%2C+1.2%2C+2.0%29?focusedCommentId=60511#comment-60511
>>
>> >
>> >
>> > Please check out a similar comparison between just 1.2 and 2.0.
>> > http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ
>> >
>> > This can be tuned further.
>> >
>> > Cheers
>> > Prasad
>> >
>> > On 6/27/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>> >>
>> >> On Jun 26, 2007, at 10:57 PM, Jay D. McHugh wrote:
>> >>
>> >> > In order to (hopefully) simplify finding where the increase in
>> >> > footprint size comes from, I made a new page on the wiki:
>> >> >
>> >> > http://cwiki.apache.org/confluence/x/TOw
>> >> >
>> >> > Jay
>> >> >>
>> >>
>> >> Jay, this is excellent. Clearly the pesky repository is a major
>> >> contributor. It is interesting that the growth from 1.1.1 to 1.2 and
>> >> beyond. I'm wondering if the Maven transient dependencies have
>> >> anything to do with this ?
>> >>
>> >> >> Me ! Me ! Me !
>> >> >>
>> >> >> Cheers
>> >> >> Prasad
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>> >
>> >
>>
>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Prasad Kashyap <go...@gmail.com>.
Here is a spreadsheet of the comparison between the disk usage (du -k)
values of v1.2 and v2.0.
http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ&gid=0
There are 2 sheets. The first sheet stops at the ${version} dir in the
repo structure. The 2nd sheet goes all the way into the repo tree.
It's a google spreadsheet. I don't know how I can share this so that
all can edit it. But just ask me and I will give you permission.
Cheers
Prasad
On 6/28/07, Jay D. McHugh <ja...@joyfulnoisewebdesign.com> wrote:
> You are right Prasad,
>
> I messed something up when I was building my tables.
> "repository/geronimo" is in the installed directory but not in my database.
>
> I'll rebuild the table and see what comes out. Also, I'll 'map' the
> "repository/geronimo" to "repository/org/apache/geronimo" so that the
> table makes sense.
>
>
> Jay
>
> Prasad Kashyap wrote:
> > Matt, Jay,
> >
> > The repository shifted from repository/geronimo to repository/o.a.g
> > from v1.2 onwards. We'd have to compare it against that directory to
> > get a good picture.. I added the same comments to your wiki page.
> >
> > http://cwiki.apache.org/confluence/display/GMOxDEV/Installed+size+comparison+%281.1.1%2C+1.2%2C+2.0%29?focusedCommentId=60511#comment-60511
> >
> >
> > Please check out a similar comparison between just 1.2 and 2.0.
> > http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ
> >
> > This can be tuned further.
> >
> > Cheers
> > Prasad
> >
> > On 6/27/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> >>
> >> On Jun 26, 2007, at 10:57 PM, Jay D. McHugh wrote:
> >>
> >> > In order to (hopefully) simplify finding where the increase in
> >> > footprint size comes from, I made a new page on the wiki:
> >> >
> >> > http://cwiki.apache.org/confluence/x/TOw
> >> >
> >> > Jay
> >> >>
> >>
> >> Jay, this is excellent. Clearly the pesky repository is a major
> >> contributor. It is interesting that the growth from 1.1.1 to 1.2 and
> >> beyond. I'm wondering if the Maven transient dependencies have
> >> anything to do with this ?
> >>
> >> >> Me ! Me ! Me !
> >> >>
> >> >> Cheers
> >> >> Prasad
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> >
> >
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Prasad Kashyap <go...@gmail.com>.
David "Master Yoda" Jencks,
When you went through the list of artifacts in our G repo, did you see
any that looked like we may not need it but it may have been picked up
as a M2 transitive dep ?
Cheers
Prasad
On 7/1/07, David Jencks <da...@yahoo.com> wrote:
>
> On Jun 28, 2007, at 10:38 AM, Kevan Miller wrote:
>
> >
> > On Jun 28, 2007, at 12:35 PM, Jay D. McHugh wrote:
> >
> >> The page has been updated to move the contents of repository/
> >> geronimo to repository/org/apache/geronimo.
> >>
> >> I found a couple of other places where contents of the repository
> >> moved (tranql -> org/tranql, etc) and fixed those as well.
> >>
> >> If anyone sees a module that moved (that I missed) let me know and
> >> I'll rework the table.
> >>
> >> I already caught org/apache/geronimo/activemq-broker(1.2) s/b org/
> >> apache/geronimo/configs/activemq-broker but haven't fixed it yet.
> >> For sizing purposes, that will not affect the following results.
> >>
> >> Here are the places that I am seeing that the repository has grown
> >> (between 1.1.1 and 2.0):
> >>
> >> Added (size rounded to nearest Meg)
> >> com/sun/xml (5M)
> >> commons-codec (1M)
> >> commons-fileupload (1M)
> >> commons-httpclient (1M)
> >> commons-io (1M)
> >> commons-jexl (1M)
> >> commons-lang (1M)
> >> commons-primitives (1M)
> >> directory (1M)
> >> directory-asn1 (1M)
> >> directory-network (1M)
> >> directory-protocols (1M)
> >> directory-shared (1M)
> >> dwr (1M)
> >> javax (1M)
> >> jaxen (1M)
> >> jdbm (1M)
> >> jline (1M)
> >> jstl (1M)
> >> net (1M)
> >> ognl (1M)
> >> org/apache/axis2 (3M)
> >> org/apache/bcel (1M)
> >> org/apache/cxf (2M)
> >> org/apache/httpcomponents (1M)
> >> org/apache/myfaces (1M)
> >> org/apache/neethi (1M)
> >> org/apache/openjpa (3M)
> >> org/apache/ws/commons/axiom (1M)
> >> org/apache/yoko (4M)
> >> org/codehaus/castor (3M)
> >> org/codehaus/swizzle (1M)
> >> org/sl4j (1M)
> >> org/springframework (1)
> >> oro (1M)
> >> regexp (1M)
> >> woodstox (1M)
> >> xml-resolver (1M)
> >>
> >> Grew (growth rounded to nearest Meg)
> >> org/apache/activemq (1M)
> >> org/apache/geronimo (Some additions, some reductions: 8M overall -
> >> ~5M of this is dojo)
> >> org/apache/tomcat (1M)
> >> org/apache/xbean (1M) - We have 3.0 snapshot and 3.1 snapshot in 2.0
> >>
> >> Those are only the increases. There may be more, but these were
> >> the ones that I caught (there are still some moved module issues
> >> yet to be found). As best as I could tell, upgrades between
> >> versions of the same component did not significantly contribute to
> >> the increase in footprint. Additional components is where we got
> >> hit the hardest.
> >
> > Nice. Thanks for doing this Jay and Prasad...
> >
> > Nothing really jumps out at me as being unnecessary... Just
> > scanning that list for the big hitters...
> >
> > com/sun (5M) is new
> > org/apache/yoko (4M) is new
> > org/apache/castor (3M) is new. OpenEJB is no longer dependent on
> > castor (IIRC) We could look to see who else is dependent on it...
> > org/apache/openjpa (3M) is new.
> > org/apache/axis2 (3M)
> > org/apache/cxf (2M) is new.
> >
> > All, except perhaps castor, are needed...
> >
> >
> > If we really wanted to cut down on carbs, we could ask ourselves if
> > we really need to package Dojo. That would save 5 megs.
> >
> > The only thing worth spending much time on, IMO, are Geronimo
> > configs. By my count, configs in 2.0 is 15 Meg. In 1.1.1 they were
> > 3.5 Megs (repository/geronimo/geronimo-*)
> >
> > Should definitely look at is moving jar files (especially the
> > redundant ones) out of org/apache/geronimo/configs. As in:
> >
> > ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/
> > activemq-core-4.1.1.jar
> > ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/
> > activemq-ra-4.1.1.jar
> > ./ca-helper-jetty/2.0-SNAPSHOT/ca-helper-jetty-2.0-SNAPSHOT.car/WEB-
> > INF/lib/geronimo-ca-helper-2.0-SNAPSHOT.jar
> > ./dojo-jetty6/2.0-SNAPSHOT/dojo-jetty6-2.0-SNAPSHOT.car/WEB-INF/lib/
> > geronimo-dojo-2.0-SNAPSHOT.jar
> > ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> > SNAPSHOT.car/WEB-INF/lib/asm-2.2.3.jar
> > ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> > SNAPSHOT.car/WEB-INF/lib/asm-commons-2.2.3.jar
> > ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> > SNAPSHOT.car/WEB-INF/lib/asm-tree-2.2.3.jar
> > ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> > SNAPSHOT.car/WEB-INF/lib/cglib-nodep-2.1_3.jar
> > ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> > SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar
> > ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> > SNAPSHOT.car/WEB-INF/lib/geronimo-kernel-2.0-SNAPSHOT.jar
> > ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> > SNAPSHOT.car/WEB-INF/lib/geronimo-remote-deploy-2.0-SNAPSHOT.jar
> > ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> > SNAPSHOT.car/WEB-INF/lib/log4j-1.2.14.jar
> > ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> > SNAPSHOT.car/WEB-INF/lib/xpp3-1.1.3.3.jar
> > ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> > SNAPSHOT.car/WEB-INF/lib/xstream-1.1.3.jar
> > ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/
> > tranql-connector-1.3.jar
> > ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/
> > tranql-connector-derby-common-1.3.jar
> > ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
> > tranql-connector-1.3.jar
> > ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
> > tranql-connector-derby-common-1.3.jar
> > ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-jetty/
> > WEB-INF/lib/geronimo-uddi-server-2.0-SNAPSHOT.jar
> > ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/
> > framework.war/WEB-INF/lib/geronimo-console-framework-2.0-SNAPSHOT.jar
> > ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/
> > standard.war/WEB-INF/lib/geronimo-console-standard-2.0-SNAPSHOT.jar
> > ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/
> > lib/geronimo-servlet_2.5_spec-1.1-20070613.151247-4.jar
> > ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/
> > lib/geronimo-welcome-2.0-SNAPSHOT.jar
>
> I suspect a lot of these are due to m2 war plugin pulling in stuff we
> don't expect: this should be easy and a good idea to fix.
>
> The connectors (and maybe amq) are a bit trickier. The standard war
> packaging results in pulling copies of the jars in each time you
> deploy another instance of a connector. I wonder if it would be
> worthwhile to create tranql rars with no jars inside, just the
> ra.xmls, and have configurations with the classes (and driver
> classes). So we'd have a derby-connector car with the tranql
> connector and tranql-derby-connector jar and the derby jars and that
> would be a parent of system-database (which would use the no-classes
> tranql derby connector rar). Especially with embedded drivers its
> pretty much necessary to make sure everyone is loading derby classes
> from the same classloader so this would mean we no longer have to use
> system-database as a parent, we could use the "classes only" module
> instead.
>
> Not sure how much space this would save...
>
> thanks
> david jencks
>
> >
> > --kevan
> >
>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Donald Woods <dw...@apache.org>.
+1 as this would provide a common schema for other vendor implementations
(like MySQL, Oracle, DB2, ...)
-Donald
David Jencks wrote:
>
> On Jun 28, 2007, at 10:38 AM, Kevan Miller wrote:
>
>>
>> On Jun 28, 2007, at 12:35 PM, Jay D. McHugh wrote:
>>
>>> The page has been updated to move the contents of repository/geronimo
>>> to repository/org/apache/geronimo.
>>>
>>> I found a couple of other places where contents of the repository
>>> moved (tranql -> org/tranql, etc) and fixed those as well.
>>>
>>> If anyone sees a module that moved (that I missed) let me know and
>>> I'll rework the table.
>>>
>>> I already caught org/apache/geronimo/activemq-broker(1.2) s/b
>>> org/apache/geronimo/configs/activemq-broker but haven't fixed it
>>> yet. For sizing purposes, that will not affect the following results.
>>>
>>> Here are the places that I am seeing that the repository has grown
>>> (between 1.1.1 and 2.0):
>>>
>>> Added (size rounded to nearest Meg)
>>> com/sun/xml (5M)
>>> commons-codec (1M)
>>> commons-fileupload (1M)
>>> commons-httpclient (1M)
>>> commons-io (1M)
>>> commons-jexl (1M)
>>> commons-lang (1M)
>>> commons-primitives (1M)
>>> directory (1M)
>>> directory-asn1 (1M)
>>> directory-network (1M)
>>> directory-protocols (1M)
>>> directory-shared (1M)
>>> dwr (1M)
>>> javax (1M)
>>> jaxen (1M)
>>> jdbm (1M)
>>> jline (1M)
>>> jstl (1M)
>>> net (1M)
>>> ognl (1M)
>>> org/apache/axis2 (3M)
>>> org/apache/bcel (1M)
>>> org/apache/cxf (2M)
>>> org/apache/httpcomponents (1M)
>>> org/apache/myfaces (1M)
>>> org/apache/neethi (1M)
>>> org/apache/openjpa (3M)
>>> org/apache/ws/commons/axiom (1M)
>>> org/apache/yoko (4M)
>>> org/codehaus/castor (3M)
>>> org/codehaus/swizzle (1M)
>>> org/sl4j (1M)
>>> org/springframework (1)
>>> oro (1M)
>>> regexp (1M)
>>> woodstox (1M)
>>> xml-resolver (1M)
>>>
>>> Grew (growth rounded to nearest Meg)
>>> org/apache/activemq (1M)
>>> org/apache/geronimo (Some additions, some reductions: 8M overall -
>>> ~5M of this is dojo)
>>> org/apache/tomcat (1M)
>>> org/apache/xbean (1M) - We have 3.0 snapshot and 3.1 snapshot in 2.0
>>>
>>> Those are only the increases. There may be more, but these were the
>>> ones that I caught (there are still some moved module issues yet to
>>> be found). As best as I could tell, upgrades between versions of the
>>> same component did not significantly contribute to the increase in
>>> footprint. Additional components is where we got hit the hardest.
>>
>> Nice. Thanks for doing this Jay and Prasad...
>>
>> Nothing really jumps out at me as being unnecessary... Just scanning
>> that list for the big hitters...
>>
>> com/sun (5M) is new
>> org/apache/yoko (4M) is new
>> org/apache/castor (3M) is new. OpenEJB is no longer dependent on
>> castor (IIRC) We could look to see who else is dependent on it...
>> org/apache/openjpa (3M) is new.
>> org/apache/axis2 (3M)
>> org/apache/cxf (2M) is new.
>>
>> All, except perhaps castor, are needed...
>>
>>
>> If we really wanted to cut down on carbs, we could ask ourselves if we
>> really need to package Dojo. That would save 5 megs.
>>
>> The only thing worth spending much time on, IMO, are Geronimo configs.
>> By my count, configs in 2.0 is 15 Meg. In 1.1.1 they were 3.5 Megs
>> (repository/geronimo/geronimo-*)
>>
>> Should definitely look at is moving jar files (especially the
>> redundant ones) out of org/apache/geronimo/configs. As in:
>>
>> ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/activemq-core-4.1.1.jar
>>
>> ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/activemq-ra-4.1.1.jar
>>
>> ./ca-helper-jetty/2.0-SNAPSHOT/ca-helper-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-ca-helper-2.0-SNAPSHOT.jar
>>
>> ./dojo-jetty6/2.0-SNAPSHOT/dojo-jetty6-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-dojo-2.0-SNAPSHOT.jar
>>
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/asm-2.2.3.jar
>>
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/asm-commons-2.2.3.jar
>>
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/asm-tree-2.2.3.jar
>>
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/cglib-nodep-2.1_3.jar
>>
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar
>>
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-kernel-2.0-SNAPSHOT.jar
>>
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-remote-deploy-2.0-SNAPSHOT.jar
>>
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/log4j-1.2.14.jar
>>
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/xpp3-1.1.3.3.jar
>>
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/xstream-1.1.3.jar
>>
>> ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/tranql-connector-1.3.jar
>>
>> ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/tranql-connector-derby-common-1.3.jar
>>
>> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/tranql-connector-1.3.jar
>>
>> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/tranql-connector-derby-common-1.3.jar
>>
>> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-jetty/WEB-INF/lib/geronimo-uddi-server-2.0-SNAPSHOT.jar
>>
>> ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/framework.war/WEB-INF/lib/geronimo-console-framework-2.0-SNAPSHOT.jar
>>
>> ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/standard.war/WEB-INF/lib/geronimo-console-standard-2.0-SNAPSHOT.jar
>>
>> ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-servlet_2.5_spec-1.1-20070613.151247-4.jar
>>
>> ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-welcome-2.0-SNAPSHOT.jar
>>
>
> I suspect a lot of these are due to m2 war plugin pulling in stuff we
> don't expect: this should be easy and a good idea to fix.
>
> The connectors (and maybe amq) are a bit trickier. The standard war
> packaging results in pulling copies of the jars in each time you deploy
> another instance of a connector. I wonder if it would be worthwhile to
> create tranql rars with no jars inside, just the ra.xmls, and have
> configurations with the classes (and driver classes). So we'd have a
> derby-connector car with the tranql connector and tranql-derby-connector
> jar and the derby jars and that would be a parent of system-database
> (which would use the no-classes tranql derby connector rar). Especially
> with embedded drivers its pretty much necessary to make sure everyone is
> loading derby classes from the same classloader so this would mean we no
> longer have to use system-database as a parent, we could use the
> "classes only" module instead.
>
> Not sure how much space this would save...
>
> thanks
> david jencks
>
>>
>> --kevan
>>
>
>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by David Jencks <da...@yahoo.com>.
On Jun 28, 2007, at 10:38 AM, Kevan Miller wrote:
>
> On Jun 28, 2007, at 12:35 PM, Jay D. McHugh wrote:
>
>> The page has been updated to move the contents of repository/
>> geronimo to repository/org/apache/geronimo.
>>
>> I found a couple of other places where contents of the repository
>> moved (tranql -> org/tranql, etc) and fixed those as well.
>>
>> If anyone sees a module that moved (that I missed) let me know and
>> I'll rework the table.
>>
>> I already caught org/apache/geronimo/activemq-broker(1.2) s/b org/
>> apache/geronimo/configs/activemq-broker but haven't fixed it yet.
>> For sizing purposes, that will not affect the following results.
>>
>> Here are the places that I am seeing that the repository has grown
>> (between 1.1.1 and 2.0):
>>
>> Added (size rounded to nearest Meg)
>> com/sun/xml (5M)
>> commons-codec (1M)
>> commons-fileupload (1M)
>> commons-httpclient (1M)
>> commons-io (1M)
>> commons-jexl (1M)
>> commons-lang (1M)
>> commons-primitives (1M)
>> directory (1M)
>> directory-asn1 (1M)
>> directory-network (1M)
>> directory-protocols (1M)
>> directory-shared (1M)
>> dwr (1M)
>> javax (1M)
>> jaxen (1M)
>> jdbm (1M)
>> jline (1M)
>> jstl (1M)
>> net (1M)
>> ognl (1M)
>> org/apache/axis2 (3M)
>> org/apache/bcel (1M)
>> org/apache/cxf (2M)
>> org/apache/httpcomponents (1M)
>> org/apache/myfaces (1M)
>> org/apache/neethi (1M)
>> org/apache/openjpa (3M)
>> org/apache/ws/commons/axiom (1M)
>> org/apache/yoko (4M)
>> org/codehaus/castor (3M)
>> org/codehaus/swizzle (1M)
>> org/sl4j (1M)
>> org/springframework (1)
>> oro (1M)
>> regexp (1M)
>> woodstox (1M)
>> xml-resolver (1M)
>>
>> Grew (growth rounded to nearest Meg)
>> org/apache/activemq (1M)
>> org/apache/geronimo (Some additions, some reductions: 8M overall -
>> ~5M of this is dojo)
>> org/apache/tomcat (1M)
>> org/apache/xbean (1M) - We have 3.0 snapshot and 3.1 snapshot in 2.0
>>
>> Those are only the increases. There may be more, but these were
>> the ones that I caught (there are still some moved module issues
>> yet to be found). As best as I could tell, upgrades between
>> versions of the same component did not significantly contribute to
>> the increase in footprint. Additional components is where we got
>> hit the hardest.
>
> Nice. Thanks for doing this Jay and Prasad...
>
> Nothing really jumps out at me as being unnecessary... Just
> scanning that list for the big hitters...
>
> com/sun (5M) is new
> org/apache/yoko (4M) is new
> org/apache/castor (3M) is new. OpenEJB is no longer dependent on
> castor (IIRC) We could look to see who else is dependent on it...
> org/apache/openjpa (3M) is new.
> org/apache/axis2 (3M)
> org/apache/cxf (2M) is new.
>
> All, except perhaps castor, are needed...
>
>
> If we really wanted to cut down on carbs, we could ask ourselves if
> we really need to package Dojo. That would save 5 megs.
>
> The only thing worth spending much time on, IMO, are Geronimo
> configs. By my count, configs in 2.0 is 15 Meg. In 1.1.1 they were
> 3.5 Megs (repository/geronimo/geronimo-*)
>
> Should definitely look at is moving jar files (especially the
> redundant ones) out of org/apache/geronimo/configs. As in:
>
> ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/
> activemq-core-4.1.1.jar
> ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/
> activemq-ra-4.1.1.jar
> ./ca-helper-jetty/2.0-SNAPSHOT/ca-helper-jetty-2.0-SNAPSHOT.car/WEB-
> INF/lib/geronimo-ca-helper-2.0-SNAPSHOT.jar
> ./dojo-jetty6/2.0-SNAPSHOT/dojo-jetty6-2.0-SNAPSHOT.car/WEB-INF/lib/
> geronimo-dojo-2.0-SNAPSHOT.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/asm-2.2.3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/asm-commons-2.2.3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/asm-tree-2.2.3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/cglib-nodep-2.1_3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/geronimo-kernel-2.0-SNAPSHOT.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/geronimo-remote-deploy-2.0-SNAPSHOT.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/log4j-1.2.14.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/xpp3-1.1.3.3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/xstream-1.1.3.jar
> ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/
> tranql-connector-1.3.jar
> ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/
> tranql-connector-derby-common-1.3.jar
> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
> tranql-connector-1.3.jar
> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
> tranql-connector-derby-common-1.3.jar
> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-jetty/
> WEB-INF/lib/geronimo-uddi-server-2.0-SNAPSHOT.jar
> ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/
> framework.war/WEB-INF/lib/geronimo-console-framework-2.0-SNAPSHOT.jar
> ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/
> standard.war/WEB-INF/lib/geronimo-console-standard-2.0-SNAPSHOT.jar
> ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/
> lib/geronimo-servlet_2.5_spec-1.1-20070613.151247-4.jar
> ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/
> lib/geronimo-welcome-2.0-SNAPSHOT.jar
I suspect a lot of these are due to m2 war plugin pulling in stuff we
don't expect: this should be easy and a good idea to fix.
The connectors (and maybe amq) are a bit trickier. The standard war
packaging results in pulling copies of the jars in each time you
deploy another instance of a connector. I wonder if it would be
worthwhile to create tranql rars with no jars inside, just the
ra.xmls, and have configurations with the classes (and driver
classes). So we'd have a derby-connector car with the tranql
connector and tranql-derby-connector jar and the derby jars and that
would be a parent of system-database (which would use the no-classes
tranql derby connector rar). Especially with embedded drivers its
pretty much necessary to make sure everyone is loading derby classes
from the same classloader so this would mean we no longer have to use
system-database as a parent, we could use the "classes only" module
instead.
Not sure how much space this would save...
thanks
david jencks
>
> --kevan
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Jarek Gawor <jg...@gmail.com>.
I think we can remove our Xerces dependency too. That's 1.2M. Last
time I checked only Castor needed it. So if we don't need Castor
anymore (or we upgrade to Castor 1.1+) we should be able to drop the
Xerces jar file.
Jarek
On 6/28/07, Kevan Miller <ke...@gmail.com> wrote:
>
> On Jun 28, 2007, at 12:35 PM, Jay D. McHugh wrote:
>
> > The page has been updated to move the contents of repository/
> > geronimo to repository/org/apache/geronimo.
> >
> > I found a couple of other places where contents of the repository
> > moved (tranql -> org/tranql, etc) and fixed those as well.
> >
> > If anyone sees a module that moved (that I missed) let me know and
> > I'll rework the table.
> >
> > I already caught org/apache/geronimo/activemq-broker(1.2) s/b org/
> > apache/geronimo/configs/activemq-broker but haven't fixed it yet.
> > For sizing purposes, that will not affect the following results.
> >
> > Here are the places that I am seeing that the repository has grown
> > (between 1.1.1 and 2.0):
> >
> > Added (size rounded to nearest Meg)
> > com/sun/xml (5M)
> > commons-codec (1M)
> > commons-fileupload (1M)
> > commons-httpclient (1M)
> > commons-io (1M)
> > commons-jexl (1M)
> > commons-lang (1M)
> > commons-primitives (1M)
> > directory (1M)
> > directory-asn1 (1M)
> > directory-network (1M)
> > directory-protocols (1M)
> > directory-shared (1M)
> > dwr (1M)
> > javax (1M)
> > jaxen (1M)
> > jdbm (1M)
> > jline (1M)
> > jstl (1M)
> > net (1M)
> > ognl (1M)
> > org/apache/axis2 (3M)
> > org/apache/bcel (1M)
> > org/apache/cxf (2M)
> > org/apache/httpcomponents (1M)
> > org/apache/myfaces (1M)
> > org/apache/neethi (1M)
> > org/apache/openjpa (3M)
> > org/apache/ws/commons/axiom (1M)
> > org/apache/yoko (4M)
> > org/codehaus/castor (3M)
> > org/codehaus/swizzle (1M)
> > org/sl4j (1M)
> > org/springframework (1)
> > oro (1M)
> > regexp (1M)
> > woodstox (1M)
> > xml-resolver (1M)
> >
> > Grew (growth rounded to nearest Meg)
> > org/apache/activemq (1M)
> > org/apache/geronimo (Some additions, some reductions: 8M overall -
> > ~5M of this is dojo)
> > org/apache/tomcat (1M)
> > org/apache/xbean (1M) - We have 3.0 snapshot and 3.1 snapshot in 2.0
> >
> > Those are only the increases. There may be more, but these were
> > the ones that I caught (there are still some moved module issues
> > yet to be found). As best as I could tell, upgrades between
> > versions of the same component did not significantly contribute to
> > the increase in footprint. Additional components is where we got
> > hit the hardest.
>
> Nice. Thanks for doing this Jay and Prasad...
>
> Nothing really jumps out at me as being unnecessary... Just scanning
> that list for the big hitters...
>
> com/sun (5M) is new
> org/apache/yoko (4M) is new
> org/apache/castor (3M) is new. OpenEJB is no longer dependent on
> castor (IIRC) We could look to see who else is dependent on it...
> org/apache/openjpa (3M) is new.
> org/apache/axis2 (3M)
> org/apache/cxf (2M) is new.
>
> All, except perhaps castor, are needed...
>
>
> If we really wanted to cut down on carbs, we could ask ourselves if
> we really need to package Dojo. That would save 5 megs.
>
> The only thing worth spending much time on, IMO, are Geronimo
> configs. By my count, configs in 2.0 is 15 Meg. In 1.1.1 they were
> 3.5 Megs (repository/geronimo/geronimo-*)
>
> Should definitely look at is moving jar files (especially the
> redundant ones) out of org/apache/geronimo/configs. As in:
>
> ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/activemq-
> core-4.1.1.jar
> ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/activemq-
> ra-4.1.1.jar
> ./ca-helper-jetty/2.0-SNAPSHOT/ca-helper-jetty-2.0-SNAPSHOT.car/WEB-
> INF/lib/geronimo-ca-helper-2.0-SNAPSHOT.jar
> ./dojo-jetty6/2.0-SNAPSHOT/dojo-jetty6-2.0-SNAPSHOT.car/WEB-INF/lib/
> geronimo-dojo-2.0-SNAPSHOT.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/asm-2.2.3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/asm-commons-2.2.3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/asm-tree-2.2.3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/cglib-nodep-2.1_3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/geronimo-kernel-2.0-SNAPSHOT.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/geronimo-remote-deploy-2.0-SNAPSHOT.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/log4j-1.2.14.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/xpp3-1.1.3.3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/xstream-1.1.3.jar
> ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/
> tranql-connector-1.3.jar
> ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/
> tranql-connector-derby-common-1.3.jar
> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
> tranql-connector-1.3.jar
> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
> tranql-connector-derby-common-1.3.jar
> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-jetty/
> WEB-INF/lib/geronimo-uddi-server-2.0-SNAPSHOT.jar
> ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/
> framework.war/WEB-INF/lib/geronimo-console-framework-2.0-SNAPSHOT.jar
> ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/
> standard.war/WEB-INF/lib/geronimo-console-standard-2.0-SNAPSHOT.jar
> ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/
> lib/geronimo-servlet_2.5_spec-1.1-20070613.151247-4.jar
> ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/
> lib/geronimo-welcome-2.0-SNAPSHOT.jar
>
> --kevan
>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Prasad Kashyap <go...@gmail.com>.
Another thing to remember is that M2 builds gave us transitive
dependencies. So it could quite be possible that we picked up some
unneeded artifacts.
We bloated by 20+M from 1.1 to 1.2.
Cheers
Prasad
On 6/28/07, Kevan Miller <ke...@gmail.com> wrote:
>
> On Jun 28, 2007, at 12:35 PM, Jay D. McHugh wrote:
>
> > The page has been updated to move the contents of repository/
> > geronimo to repository/org/apache/geronimo.
> >
> > I found a couple of other places where contents of the repository
> > moved (tranql -> org/tranql, etc) and fixed those as well.
> >
> > If anyone sees a module that moved (that I missed) let me know and
> > I'll rework the table.
> >
> > I already caught org/apache/geronimo/activemq-broker(1.2) s/b org/
> > apache/geronimo/configs/activemq-broker but haven't fixed it yet.
> > For sizing purposes, that will not affect the following results.
> >
> > Here are the places that I am seeing that the repository has grown
> > (between 1.1.1 and 2.0):
> >
> > Added (size rounded to nearest Meg)
> > com/sun/xml (5M)
> > commons-codec (1M)
> > commons-fileupload (1M)
> > commons-httpclient (1M)
> > commons-io (1M)
> > commons-jexl (1M)
> > commons-lang (1M)
> > commons-primitives (1M)
> > directory (1M)
> > directory-asn1 (1M)
> > directory-network (1M)
> > directory-protocols (1M)
> > directory-shared (1M)
> > dwr (1M)
> > javax (1M)
> > jaxen (1M)
> > jdbm (1M)
> > jline (1M)
> > jstl (1M)
> > net (1M)
> > ognl (1M)
> > org/apache/axis2 (3M)
> > org/apache/bcel (1M)
> > org/apache/cxf (2M)
> > org/apache/httpcomponents (1M)
> > org/apache/myfaces (1M)
> > org/apache/neethi (1M)
> > org/apache/openjpa (3M)
> > org/apache/ws/commons/axiom (1M)
> > org/apache/yoko (4M)
> > org/codehaus/castor (3M)
> > org/codehaus/swizzle (1M)
> > org/sl4j (1M)
> > org/springframework (1)
> > oro (1M)
> > regexp (1M)
> > woodstox (1M)
> > xml-resolver (1M)
> >
> > Grew (growth rounded to nearest Meg)
> > org/apache/activemq (1M)
> > org/apache/geronimo (Some additions, some reductions: 8M overall -
> > ~5M of this is dojo)
> > org/apache/tomcat (1M)
> > org/apache/xbean (1M) - We have 3.0 snapshot and 3.1 snapshot in 2.0
> >
> > Those are only the increases. There may be more, but these were
> > the ones that I caught (there are still some moved module issues
> > yet to be found). As best as I could tell, upgrades between
> > versions of the same component did not significantly contribute to
> > the increase in footprint. Additional components is where we got
> > hit the hardest.
>
> Nice. Thanks for doing this Jay and Prasad...
>
> Nothing really jumps out at me as being unnecessary... Just scanning
> that list for the big hitters...
>
> com/sun (5M) is new
> org/apache/yoko (4M) is new
> org/apache/castor (3M) is new. OpenEJB is no longer dependent on
> castor (IIRC) We could look to see who else is dependent on it...
> org/apache/openjpa (3M) is new.
> org/apache/axis2 (3M)
> org/apache/cxf (2M) is new.
>
> All, except perhaps castor, are needed...
>
>
> If we really wanted to cut down on carbs, we could ask ourselves if
> we really need to package Dojo. That would save 5 megs.
>
> The only thing worth spending much time on, IMO, are Geronimo
> configs. By my count, configs in 2.0 is 15 Meg. In 1.1.1 they were
> 3.5 Megs (repository/geronimo/geronimo-*)
>
> Should definitely look at is moving jar files (especially the
> redundant ones) out of org/apache/geronimo/configs. As in:
>
> ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/activemq-
> core-4.1.1.jar
> ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/activemq-
> ra-4.1.1.jar
> ./ca-helper-jetty/2.0-SNAPSHOT/ca-helper-jetty-2.0-SNAPSHOT.car/WEB-
> INF/lib/geronimo-ca-helper-2.0-SNAPSHOT.jar
> ./dojo-jetty6/2.0-SNAPSHOT/dojo-jetty6-2.0-SNAPSHOT.car/WEB-INF/lib/
> geronimo-dojo-2.0-SNAPSHOT.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/asm-2.2.3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/asm-commons-2.2.3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/asm-tree-2.2.3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/cglib-nodep-2.1_3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/geronimo-kernel-2.0-SNAPSHOT.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/geronimo-remote-deploy-2.0-SNAPSHOT.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/log4j-1.2.14.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/xpp3-1.1.3.3.jar
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
> SNAPSHOT.car/WEB-INF/lib/xstream-1.1.3.jar
> ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/
> tranql-connector-1.3.jar
> ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/
> tranql-connector-derby-common-1.3.jar
> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
> tranql-connector-1.3.jar
> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
> tranql-connector-derby-common-1.3.jar
> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-jetty/
> WEB-INF/lib/geronimo-uddi-server-2.0-SNAPSHOT.jar
> ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/
> framework.war/WEB-INF/lib/geronimo-console-framework-2.0-SNAPSHOT.jar
> ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/
> standard.war/WEB-INF/lib/geronimo-console-standard-2.0-SNAPSHOT.jar
> ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/
> lib/geronimo-servlet_2.5_spec-1.1-20070613.151247-4.jar
> ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/
> lib/geronimo-welcome-2.0-SNAPSHOT.jar
>
> --kevan
>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Paul McMahan <pa...@gmail.com>.
Like Jay says, several recent additions to the admin console use dojo:
Classloader Viewer
JMX Viewer
Dependency Viewer
LDAP Viewer
JNDI Viewer
The typical way of using dojo in a webapp is to include it in your
WAR. Dojo provides some tooling to trim their js library down to
just the parts that your webapp needs.
Instead of doing that we made the entire js library available at the
context "/dojo" so that other webapps besides the admin console could
share it. We could look into trimming some of the fat out of that
js library by identifying which parts are less useful.
Another idea would be to zip the dojo js library in a jar and serve
up files from it on demand using a servlet. That could have a
performance impact on applications that use dojo more heavily because
they load lots of js files on initial bringup.
Longer term, we're working on a pluggable admin console that will
allow users to add these spiffy new viewers (and the dojo prereq) to
their admin console on demand.
Best wishes,
Paul
On Jun 28, 2007, at 1:58 PM, Jay D. McHugh wrote:
> Right now, I don't think we can remove dojo. Some of the more
> recent additions to the admin console are using it.
>
> Those would either have to be removed, changed to plugins, or be
> completely rewritten.
>
> I would say that if there is redundancy in the configs, that would
> be the place to look (at least for now).
>
> BTW, do we need both versions of xbean (3.0 and 3.1)?
>
> Jay
>
> Kevan Miller wrote:
>>
>> On Jun 28, 2007, at 12:35 PM, Jay D. McHugh wrote:
>>
>>> The page has been updated to move the contents of repository/
>>> geronimo to repository/org/apache/geronimo.
>>>
>>> I found a couple of other places where contents of the repository
>>> moved (tranql -> org/tranql, etc) and fixed those as well.
>>>
>>> If anyone sees a module that moved (that I missed) let me know
>>> and I'll rework the table.
>>>
>>> I already caught org/apache/geronimo/activemq-broker(1.2) s/b org/
>>> apache/geronimo/configs/activemq-broker but haven't fixed it
>>> yet. For sizing purposes, that will not affect the following
>>> results.
>>>
>>> Here are the places that I am seeing that the repository has
>>> grown (between 1.1.1 and 2.0):
>>>
>>> Added (size rounded to nearest Meg)
>>> com/sun/xml (5M)
>>> commons-codec (1M)
>>> commons-fileupload (1M)
>>> commons-httpclient (1M)
>>> commons-io (1M)
>>> commons-jexl (1M)
>>> commons-lang (1M)
>>> commons-primitives (1M)
>>> directory (1M)
>>> directory-asn1 (1M)
>>> directory-network (1M)
>>> directory-protocols (1M)
>>> directory-shared (1M)
>>> dwr (1M)
>>> javax (1M)
>>> jaxen (1M)
>>> jdbm (1M)
>>> jline (1M)
>>> jstl (1M)
>>> net (1M)
>>> ognl (1M)
>>> org/apache/axis2 (3M)
>>> org/apache/bcel (1M)
>>> org/apache/cxf (2M)
>>> org/apache/httpcomponents (1M)
>>> org/apache/myfaces (1M)
>>> org/apache/neethi (1M)
>>> org/apache/openjpa (3M)
>>> org/apache/ws/commons/axiom (1M)
>>> org/apache/yoko (4M)
>>> org/codehaus/castor (3M)
>>> org/codehaus/swizzle (1M)
>>> org/sl4j (1M)
>>> org/springframework (1)
>>> oro (1M)
>>> regexp (1M)
>>> woodstox (1M)
>>> xml-resolver (1M)
>>>
>>> Grew (growth rounded to nearest Meg)
>>> org/apache/activemq (1M)
>>> org/apache/geronimo (Some additions, some reductions: 8M overall
>>> - ~5M of this is dojo)
>>> org/apache/tomcat (1M)
>>> org/apache/xbean (1M) - We have 3.0 snapshot and 3.1 snapshot in 2.0
>>>
>>> Those are only the increases. There may be more, but these were
>>> the ones that I caught (there are still some moved module issues
>>> yet to be found). As best as I could tell, upgrades between
>>> versions of the same component did not significantly contribute
>>> to the increase in footprint. Additional components is where we
>>> got hit the hardest.
>>
>> Nice. Thanks for doing this Jay and Prasad...
>>
>> Nothing really jumps out at me as being unnecessary... Just
>> scanning that list for the big hitters...
>>
>> com/sun (5M) is new
>> org/apache/yoko (4M) is new
>> org/apache/castor (3M) is new. OpenEJB is no longer dependent on
>> castor (IIRC) We could look to see who else is dependent on it...
>> org/apache/openjpa (3M) is new.
>> org/apache/axis2 (3M)
>> org/apache/cxf (2M) is new.
>>
>> All, except perhaps castor, are needed...
>>
>>
>> If we really wanted to cut down on carbs, we could ask ourselves
>> if we really need to package Dojo. That would save 5 megs.
>>
>> The only thing worth spending much time on, IMO, are Geronimo
>> configs. By my count, configs in 2.0 is 15 Meg. In 1.1.1 they were
>> 3.5 Megs (repository/geronimo/geronimo-*)
>>
>> Should definitely look at is moving jar files (especially the
>> redundant ones) out of org/apache/geronimo/configs. As in:
>>
>> ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/
>> activemq-core-4.1.1.jar
>> ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/
>> activemq-ra-4.1.1.jar
>> ./ca-helper-jetty/2.0-SNAPSHOT/ca-helper-jetty-2.0-SNAPSHOT.car/
>> WEB-INF/lib/geronimo-ca-helper-2.0-SNAPSHOT.jar
>> ./dojo-jetty6/2.0-SNAPSHOT/dojo-jetty6-2.0-SNAPSHOT.car/WEB-INF/
>> lib/geronimo-dojo-2.0-SNAPSHOT.jar
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
>> SNAPSHOT.car/WEB-INF/lib/asm-2.2.3.jar
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
>> SNAPSHOT.car/WEB-INF/lib/asm-commons-2.2.3.jar
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
>> SNAPSHOT.car/WEB-INF/lib/asm-tree-2.2.3.jar
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
>> SNAPSHOT.car/WEB-INF/lib/cglib-nodep-2.1_3.jar
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
>> SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
>> SNAPSHOT.car/WEB-INF/lib/geronimo-kernel-2.0-SNAPSHOT.jar
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
>> SNAPSHOT.car/WEB-INF/lib/geronimo-remote-deploy-2.0-SNAPSHOT.jar
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
>> SNAPSHOT.car/WEB-INF/lib/log4j-1.2.14.jar
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
>> SNAPSHOT.car/WEB-INF/lib/xpp3-1.1.3.3.jar
>> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
>> SNAPSHOT.car/WEB-INF/lib/xstream-1.1.3.jar
>> ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/
>> rar/tranql-connector-1.3.jar
>> ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/
>> rar/tranql-connector-derby-common-1.3.jar
>> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
>> tranql-connector-1.3.jar
>> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
>> tranql-connector-derby-common-1.3.jar
>> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-jetty/
>> WEB-INF/lib/geronimo-uddi-server-2.0-SNAPSHOT.jar
>> ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-
>> SNAPSHOT.car/framework.war/WEB-INF/lib/geronimo-console-
>> framework-2.0-SNAPSHOT.jar
>> ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-
>> SNAPSHOT.car/standard.war/WEB-INF/lib/geronimo-console-
>> standard-2.0-SNAPSHOT.jar
>> ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-
>> INF/lib/geronimo-servlet_2.5_spec-1.1-20070613.151247-4.jar
>> ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-
>> INF/lib/geronimo-welcome-2.0-SNAPSHOT.jar
>>
>> --kevan
>>
>>
>>
>>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Kevan Miller <ke...@gmail.com>.
On Jun 28, 2007, at 1:58 PM, Jay D. McHugh wrote:
> Right now, I don't think we can remove dojo. Some of the more
> recent additions to the admin console are using it.
Ya, I know it would take a little work. I'm not really advocating
removal, but putting it on the table...
>
> Those would either have to be removed, changed to plugins, or be
> completely rewritten.
>
> I would say that if there is redundancy in the configs, that would
> be the place to look (at least for now).
Agreed.
>
> BTW, do we need both versions of xbean (3.0 and 3.1)?
Don't think so. Should work on getting down to a single version...
--kevan
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
Right now, I don't think we can remove dojo. Some of the more recent
additions to the admin console are using it.
Those would either have to be removed, changed to plugins, or be
completely rewritten.
I would say that if there is redundancy in the configs, that would be
the place to look (at least for now).
BTW, do we need both versions of xbean (3.0 and 3.1)?
Jay
Kevan Miller wrote:
>
> On Jun 28, 2007, at 12:35 PM, Jay D. McHugh wrote:
>
>> The page has been updated to move the contents of repository/geronimo
>> to repository/org/apache/geronimo.
>>
>> I found a couple of other places where contents of the repository
>> moved (tranql -> org/tranql, etc) and fixed those as well.
>>
>> If anyone sees a module that moved (that I missed) let me know and
>> I'll rework the table.
>>
>> I already caught org/apache/geronimo/activemq-broker(1.2) s/b
>> org/apache/geronimo/configs/activemq-broker but haven't fixed it
>> yet. For sizing purposes, that will not affect the following results.
>>
>> Here are the places that I am seeing that the repository has grown
>> (between 1.1.1 and 2.0):
>>
>> Added (size rounded to nearest Meg)
>> com/sun/xml (5M)
>> commons-codec (1M)
>> commons-fileupload (1M)
>> commons-httpclient (1M)
>> commons-io (1M)
>> commons-jexl (1M)
>> commons-lang (1M)
>> commons-primitives (1M)
>> directory (1M)
>> directory-asn1 (1M)
>> directory-network (1M)
>> directory-protocols (1M)
>> directory-shared (1M)
>> dwr (1M)
>> javax (1M)
>> jaxen (1M)
>> jdbm (1M)
>> jline (1M)
>> jstl (1M)
>> net (1M)
>> ognl (1M)
>> org/apache/axis2 (3M)
>> org/apache/bcel (1M)
>> org/apache/cxf (2M)
>> org/apache/httpcomponents (1M)
>> org/apache/myfaces (1M)
>> org/apache/neethi (1M)
>> org/apache/openjpa (3M)
>> org/apache/ws/commons/axiom (1M)
>> org/apache/yoko (4M)
>> org/codehaus/castor (3M)
>> org/codehaus/swizzle (1M)
>> org/sl4j (1M)
>> org/springframework (1)
>> oro (1M)
>> regexp (1M)
>> woodstox (1M)
>> xml-resolver (1M)
>>
>> Grew (growth rounded to nearest Meg)
>> org/apache/activemq (1M)
>> org/apache/geronimo (Some additions, some reductions: 8M overall -
>> ~5M of this is dojo)
>> org/apache/tomcat (1M)
>> org/apache/xbean (1M) - We have 3.0 snapshot and 3.1 snapshot in 2.0
>>
>> Those are only the increases. There may be more, but these were the
>> ones that I caught (there are still some moved module issues yet to
>> be found). As best as I could tell, upgrades between versions of the
>> same component did not significantly contribute to the increase in
>> footprint. Additional components is where we got hit the hardest.
>
> Nice. Thanks for doing this Jay and Prasad...
>
> Nothing really jumps out at me as being unnecessary... Just scanning
> that list for the big hitters...
>
> com/sun (5M) is new
> org/apache/yoko (4M) is new
> org/apache/castor (3M) is new. OpenEJB is no longer dependent on
> castor (IIRC) We could look to see who else is dependent on it...
> org/apache/openjpa (3M) is new.
> org/apache/axis2 (3M)
> org/apache/cxf (2M) is new.
>
> All, except perhaps castor, are needed...
>
>
> If we really wanted to cut down on carbs, we could ask ourselves if we
> really need to package Dojo. That would save 5 megs.
>
> The only thing worth spending much time on, IMO, are Geronimo configs.
> By my count, configs in 2.0 is 15 Meg. In 1.1.1 they were 3.5 Megs
> (repository/geronimo/geronimo-*)
>
> Should definitely look at is moving jar files (especially the
> redundant ones) out of org/apache/geronimo/configs. As in:
>
> ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/activemq-core-4.1.1.jar
>
> ./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/activemq-ra-4.1.1.jar
>
> ./ca-helper-jetty/2.0-SNAPSHOT/ca-helper-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-ca-helper-2.0-SNAPSHOT.jar
>
> ./dojo-jetty6/2.0-SNAPSHOT/dojo-jetty6-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-dojo-2.0-SNAPSHOT.jar
>
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/asm-2.2.3.jar
>
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/asm-commons-2.2.3.jar
>
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/asm-tree-2.2.3.jar
>
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/cglib-nodep-2.1_3.jar
>
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar
>
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-kernel-2.0-SNAPSHOT.jar
>
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-remote-deploy-2.0-SNAPSHOT.jar
>
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/log4j-1.2.14.jar
>
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/xpp3-1.1.3.3.jar
>
> ./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/xstream-1.1.3.jar
>
> ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/tranql-connector-1.3.jar
>
> ./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/tranql-connector-derby-common-1.3.jar
>
> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/tranql-connector-1.3.jar
>
> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/tranql-connector-derby-common-1.3.jar
>
> ./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-jetty/WEB-INF/lib/geronimo-uddi-server-2.0-SNAPSHOT.jar
>
> ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/framework.war/WEB-INF/lib/geronimo-console-framework-2.0-SNAPSHOT.jar
>
> ./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/standard.war/WEB-INF/lib/geronimo-console-standard-2.0-SNAPSHOT.jar
>
> ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-servlet_2.5_spec-1.1-20070613.151247-4.jar
>
> ./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/lib/geronimo-welcome-2.0-SNAPSHOT.jar
>
>
> --kevan
>
>
>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Kevan Miller <ke...@gmail.com>.
On Jul 3, 2007, at 12:16 AM, Matt Hogstrom wrote:
>
>>> org/apache/axis2 (3M)
>>> org/apache/cxf (2M) is new.
>>>
>>
>
> Isn't Axis 1 piece parts required regardless its just CXF / Axis
> 2? Wasn't sure if the Axis2 above included the 1 parts.
Yes, Axis 1 is required, regardless. No, the "Axis2" size did not
include "Axis1".
--kevan
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Matt Hogstrom <ma...@hogstrom.org>.
>> org/apache/axis2 (3M)
>> org/apache/cxf (2M) is new.
>>
>
Isn't Axis 1 piece parts required regardless its just CXF / Axis 2?
Wasn't sure if the Axis2 above included the 1 parts.
> I know this is ugly but should we consider splitting the assembly
> further based on the webservices ? Just axis/axis2 artifacts alone
> account for approx 5MB. It's other transitive deps may add up to
> another 1K.
>
> Or do we need to bundle both webservices packs in the same server at
> all ? Do users prefer to switch webservices midstream ?
>
> I know we would like to go for a pluggable component solution. But
> until we actually get there, we have the following options -
>
> 1. work on the pluggable option right away
> 2. split assemblies further
> 3. live with bloated size due to the duplicate components till we
> achieve #1
>
> Cheers
> Prasad
>
>>
>> --kevan
>>
>>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Prasad Kashyap <go...@gmail.com>.
On 6/28/07, Kevan Miller <ke...@gmail.com> wrote:
>
> Nice. Thanks for doing this Jay and Prasad...
>
> Nothing really jumps out at me as being unnecessary... Just scanning
> that list for the big hitters...
>
> com/sun (5M) is new
> org/apache/yoko (4M) is new
> org/apache/castor (3M) is new. OpenEJB is no longer dependent on
> castor (IIRC) We could look to see who else is dependent on it...
> org/apache/openjpa (3M) is new.
> org/apache/axis2 (3M)
> org/apache/cxf (2M) is new.
>
I know this is ugly but should we consider splitting the assembly
further based on the webservices ? Just axis/axis2 artifacts alone
account for approx 5MB. It's other transitive deps may add up to
another 1K.
Or do we need to bundle both webservices packs in the same server at
all ? Do users prefer to switch webservices midstream ?
I know we would like to go for a pluggable component solution. But
until we actually get there, we have the following options -
1. work on the pluggable option right away
2. split assemblies further
3. live with bloated size due to the duplicate components till we achieve #1
Cheers
Prasad
>
> --kevan
>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Kevan Miller <ke...@gmail.com>.
On Jun 28, 2007, at 12:35 PM, Jay D. McHugh wrote:
> The page has been updated to move the contents of repository/
> geronimo to repository/org/apache/geronimo.
>
> I found a couple of other places where contents of the repository
> moved (tranql -> org/tranql, etc) and fixed those as well.
>
> If anyone sees a module that moved (that I missed) let me know and
> I'll rework the table.
>
> I already caught org/apache/geronimo/activemq-broker(1.2) s/b org/
> apache/geronimo/configs/activemq-broker but haven't fixed it yet.
> For sizing purposes, that will not affect the following results.
>
> Here are the places that I am seeing that the repository has grown
> (between 1.1.1 and 2.0):
>
> Added (size rounded to nearest Meg)
> com/sun/xml (5M)
> commons-codec (1M)
> commons-fileupload (1M)
> commons-httpclient (1M)
> commons-io (1M)
> commons-jexl (1M)
> commons-lang (1M)
> commons-primitives (1M)
> directory (1M)
> directory-asn1 (1M)
> directory-network (1M)
> directory-protocols (1M)
> directory-shared (1M)
> dwr (1M)
> javax (1M)
> jaxen (1M)
> jdbm (1M)
> jline (1M)
> jstl (1M)
> net (1M)
> ognl (1M)
> org/apache/axis2 (3M)
> org/apache/bcel (1M)
> org/apache/cxf (2M)
> org/apache/httpcomponents (1M)
> org/apache/myfaces (1M)
> org/apache/neethi (1M)
> org/apache/openjpa (3M)
> org/apache/ws/commons/axiom (1M)
> org/apache/yoko (4M)
> org/codehaus/castor (3M)
> org/codehaus/swizzle (1M)
> org/sl4j (1M)
> org/springframework (1)
> oro (1M)
> regexp (1M)
> woodstox (1M)
> xml-resolver (1M)
>
> Grew (growth rounded to nearest Meg)
> org/apache/activemq (1M)
> org/apache/geronimo (Some additions, some reductions: 8M overall -
> ~5M of this is dojo)
> org/apache/tomcat (1M)
> org/apache/xbean (1M) - We have 3.0 snapshot and 3.1 snapshot in 2.0
>
> Those are only the increases. There may be more, but these were
> the ones that I caught (there are still some moved module issues
> yet to be found). As best as I could tell, upgrades between
> versions of the same component did not significantly contribute to
> the increase in footprint. Additional components is where we got
> hit the hardest.
Nice. Thanks for doing this Jay and Prasad...
Nothing really jumps out at me as being unnecessary... Just scanning
that list for the big hitters...
com/sun (5M) is new
org/apache/yoko (4M) is new
org/apache/castor (3M) is new. OpenEJB is no longer dependent on
castor (IIRC) We could look to see who else is dependent on it...
org/apache/openjpa (3M) is new.
org/apache/axis2 (3M)
org/apache/cxf (2M) is new.
All, except perhaps castor, are needed...
If we really wanted to cut down on carbs, we could ask ourselves if
we really need to package Dojo. That would save 5 megs.
The only thing worth spending much time on, IMO, are Geronimo
configs. By my count, configs in 2.0 is 15 Meg. In 1.1.1 they were
3.5 Megs (repository/geronimo/geronimo-*)
Should definitely look at is moving jar files (especially the
redundant ones) out of org/apache/geronimo/configs. As in:
./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/activemq-
core-4.1.1.jar
./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/activemq-
ra-4.1.1.jar
./ca-helper-jetty/2.0-SNAPSHOT/ca-helper-jetty-2.0-SNAPSHOT.car/WEB-
INF/lib/geronimo-ca-helper-2.0-SNAPSHOT.jar
./dojo-jetty6/2.0-SNAPSHOT/dojo-jetty6-2.0-SNAPSHOT.car/WEB-INF/lib/
geronimo-dojo-2.0-SNAPSHOT.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/asm-2.2.3.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/asm-commons-2.2.3.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/asm-tree-2.2.3.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/cglib-nodep-2.1_3.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/geronimo-kernel-2.0-SNAPSHOT.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/geronimo-remote-deploy-2.0-SNAPSHOT.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/log4j-1.2.14.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/xpp3-1.1.3.3.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/xstream-1.1.3.jar
./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/
tranql-connector-1.3.jar
./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/
tranql-connector-derby-common-1.3.jar
./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
tranql-connector-1.3.jar
./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
tranql-connector-derby-common-1.3.jar
./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-jetty/
WEB-INF/lib/geronimo-uddi-server-2.0-SNAPSHOT.jar
./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/
framework.war/WEB-INF/lib/geronimo-console-framework-2.0-SNAPSHOT.jar
./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/
standard.war/WEB-INF/lib/geronimo-console-standard-2.0-SNAPSHOT.jar
./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/
lib/geronimo-servlet_2.5_spec-1.1-20070613.151247-4.jar
./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/
lib/geronimo-welcome-2.0-SNAPSHOT.jar
--kevan
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
The page has been updated to move the contents of repository/geronimo to
repository/org/apache/geronimo.
I found a couple of other places where contents of the repository moved
(tranql -> org/tranql, etc) and fixed those as well.
If anyone sees a module that moved (that I missed) let me know and I'll
rework the table.
I already caught org/apache/geronimo/activemq-broker(1.2) s/b
org/apache/geronimo/configs/activemq-broker but haven't fixed it yet.
For sizing purposes, that will not affect the following results.
Here are the places that I am seeing that the repository has grown
(between 1.1.1 and 2.0):
Added (size rounded to nearest Meg)
com/sun/xml (5M)
commons-codec (1M)
commons-fileupload (1M)
commons-httpclient (1M)
commons-io (1M)
commons-jexl (1M)
commons-lang (1M)
commons-primitives (1M)
directory (1M)
directory-asn1 (1M)
directory-network (1M)
directory-protocols (1M)
directory-shared (1M)
dwr (1M)
javax (1M)
jaxen (1M)
jdbm (1M)
jline (1M)
jstl (1M)
net (1M)
ognl (1M)
org/apache/axis2 (3M)
org/apache/bcel (1M)
org/apache/cxf (2M)
org/apache/httpcomponents (1M)
org/apache/myfaces (1M)
org/apache/neethi (1M)
org/apache/openjpa (3M)
org/apache/ws/commons/axiom (1M)
org/apache/yoko (4M)
org/codehaus/castor (3M)
org/codehaus/swizzle (1M)
org/sl4j (1M)
org/springframework (1)
oro (1M)
regexp (1M)
woodstox (1M)
xml-resolver (1M)
Grew (growth rounded to nearest Meg)
org/apache/activemq (1M)
org/apache/geronimo (Some additions, some reductions: 8M overall - ~5M
of this is dojo)
org/apache/tomcat (1M)
org/apache/xbean (1M) - We have 3.0 snapshot and 3.1 snapshot in 2.0
Those are only the increases. There may be more, but these were the
ones that I caught (there are still some moved module issues yet to be
found). As best as I could tell, upgrades between versions of the same
component did not significantly contribute to the increase in
footprint. Additional components is where we got hit the hardest.
Jay
Jay D. McHugh wrote:
> You are right Prasad,
>
> I messed something up when I was building my tables.
> "repository/geronimo" is in the installed directory but not in my
> database.
>
> I'll rebuild the table and see what comes out. Also, I'll 'map' the
> "repository/geronimo" to "repository/org/apache/geronimo" so that the
> table makes sense.
>
>
> Jay
>
> Prasad Kashyap wrote:
>> Matt, Jay,
>>
>> The repository shifted from repository/geronimo to repository/o.a.g
>> from v1.2 onwards. We'd have to compare it against that directory to
>> get a good picture.. I added the same comments to your wiki page.
>>
>> http://cwiki.apache.org/confluence/display/GMOxDEV/Installed+size+comparison+%281.1.1%2C+1.2%2C+2.0%29?focusedCommentId=60511#comment-60511
>>
>>
>> Please check out a similar comparison between just 1.2 and 2.0.
>> http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ
>>
>> This can be tuned further.
>>
>> Cheers
>> Prasad
>>
>> On 6/27/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>>
>>> On Jun 26, 2007, at 10:57 PM, Jay D. McHugh wrote:
>>>
>>> > In order to (hopefully) simplify finding where the increase in
>>> > footprint size comes from, I made a new page on the wiki:
>>> >
>>> > http://cwiki.apache.org/confluence/x/TOw
>>> >
>>> > Jay
>>> >>
>>>
>>> Jay, this is excellent. Clearly the pesky repository is a major
>>> contributor. It is interesting that the growth from 1.1.1 to 1.2 and
>>> beyond. I'm wondering if the Maven transient dependencies have
>>> anything to do with this ?
>>>
>>> >> Me ! Me ! Me !
>>> >>
>>> >> Cheers
>>> >> Prasad
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>>
>>
>
>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
You are right Prasad,
I messed something up when I was building my tables.
"repository/geronimo" is in the installed directory but not in my database.
I'll rebuild the table and see what comes out. Also, I'll 'map' the
"repository/geronimo" to "repository/org/apache/geronimo" so that the
table makes sense.
Jay
Prasad Kashyap wrote:
> Matt, Jay,
>
> The repository shifted from repository/geronimo to repository/o.a.g
> from v1.2 onwards. We'd have to compare it against that directory to
> get a good picture.. I added the same comments to your wiki page.
>
> http://cwiki.apache.org/confluence/display/GMOxDEV/Installed+size+comparison+%281.1.1%2C+1.2%2C+2.0%29?focusedCommentId=60511#comment-60511
>
>
> Please check out a similar comparison between just 1.2 and 2.0.
> http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ
>
> This can be tuned further.
>
> Cheers
> Prasad
>
> On 6/27/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>
>> On Jun 26, 2007, at 10:57 PM, Jay D. McHugh wrote:
>>
>> > In order to (hopefully) simplify finding where the increase in
>> > footprint size comes from, I made a new page on the wiki:
>> >
>> > http://cwiki.apache.org/confluence/x/TOw
>> >
>> > Jay
>> >>
>>
>> Jay, this is excellent. Clearly the pesky repository is a major
>> contributor. It is interesting that the growth from 1.1.1 to 1.2 and
>> beyond. I'm wondering if the Maven transient dependencies have
>> anything to do with this ?
>>
>> >> Me ! Me ! Me !
>> >>
>> >> Cheers
>> >> Prasad
>> >>
>> >>
>> >>
>> >
>>
>>
>
>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Great work ... I'll sniff both. Anything pop out at y'all from this
exercise ?
On Jun 27, 2007, at 11:04 PM, Prasad Kashyap wrote:
> Matt, Jay,
>
> The repository shifted from repository/geronimo to repository/o.a.g
> from v1.2 onwards. We'd have to compare it against that directory to
> get a good picture.. I added the same comments to your wiki page.
>
> http://cwiki.apache.org/confluence/display/GMOxDEV/Installed+size
> +comparison+%281.1.1%2C+1.2%2C+2.0%29?
> focusedCommentId=60511#comment-60511
>
> Please check out a similar comparison between just 1.2 and 2.0.
> http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ
>
> This can be tuned further.
>
> Cheers
> Prasad
>
> On 6/27/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>
>> On Jun 26, 2007, at 10:57 PM, Jay D. McHugh wrote:
>>
>> > In order to (hopefully) simplify finding where the increase in
>> > footprint size comes from, I made a new page on the wiki:
>> >
>> > http://cwiki.apache.org/confluence/x/TOw
>> >
>> > Jay
>> >>
>>
>> Jay, this is excellent. Clearly the pesky repository is a major
>> contributor. It is interesting that the growth from 1.1.1 to 1.2 and
>> beyond. I'm wondering if the Maven transient dependencies have
>> anything to do with this ?
>>
>> >> Me ! Me ! Me !
>> >>
>> >> Cheers
>> >> Prasad
>> >>
>> >>
>> >>
>> >
>>
>>
>
Re: Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Prasad Kashyap <go...@gmail.com>.
Matt, Jay,
The repository shifted from repository/geronimo to repository/o.a.g
from v1.2 onwards. We'd have to compare it against that directory to
get a good picture.. I added the same comments to your wiki page.
http://cwiki.apache.org/confluence/display/GMOxDEV/Installed+size+comparison+%281.1.1%2C+1.2%2C+2.0%29?focusedCommentId=60511#comment-60511
Please check out a similar comparison between just 1.2 and 2.0.
http://spreadsheets.google.com/pub?key=pZVJhnHN3LjuF5FjgmXnrRQ
This can be tuned further.
Cheers
Prasad
On 6/27/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>
> On Jun 26, 2007, at 10:57 PM, Jay D. McHugh wrote:
>
> > In order to (hopefully) simplify finding where the increase in
> > footprint size comes from, I made a new page on the wiki:
> >
> > http://cwiki.apache.org/confluence/x/TOw
> >
> > Jay
> >>
>
> Jay, this is excellent. Clearly the pesky repository is a major
> contributor. It is interesting that the growth from 1.1.1 to 1.2 and
> beyond. I'm wondering if the Maven transient dependencies have
> anything to do with this ?
>
> >> Me ! Me ! Me !
> >>
> >> Cheers
> >> Prasad
> >>
> >>
> >>
> >
>
>
Atkins for Geronimo - was Re: [DISCUSS] 2.0 Release Criteria
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Jun 26, 2007, at 10:57 PM, Jay D. McHugh wrote:
> In order to (hopefully) simplify finding where the increase in
> footprint size comes from, I made a new page on the wiki:
>
> http://cwiki.apache.org/confluence/x/TOw
>
> Jay
>>
Jay, this is excellent. Clearly the pesky repository is a major
contributor. It is interesting that the growth from 1.1.1 to 1.2 and
beyond. I'm wondering if the Maven transient dependencies have
anything to do with this ?
>> Me ! Me ! Me !
>>
>> Cheers
>> Prasad
>>
>>
>>
>
Re: [DISCUSS] 2.0 Release Criteria
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
In order to (hopefully) simplify finding where the increase in footprint
size comes from, I made a new page on the wiki:
http://cwiki.apache.org/confluence/x/TOw
Jay
Prasad Kashyap wrote:
> On 6/21/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>> We've gone through the CTS grind and came out victorious http://
>> java.sun.com/javaee/overview/compatibility.jsp
>>
>> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
>> working that way too.
>>
>> All in all its been an excellent six months.
>>
>> So, what are we going to do for 2.0 and getting it out the door?
>>
>> Personally, I'd like to see the full G have a footprint of about 40MB
>> (that's a little over 5MB larger than 1.1.1) and Minimal be around
>> 20MB. Need to do some research on this (volunteers?)
>
> Me ! Me ! Me !
>
> Cheers
> Prasad
>
>
>
Re: [DISCUSS] 2.0 Release Criteria
Posted by Prasad Kashyap <go...@gmail.com>.
On 6/21/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> We've gone through the CTS grind and came out victorious http://
> java.sun.com/javaee/overview/compatibility.jsp
>
> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
> working that way too.
>
> All in all its been an excellent six months.
>
> So, what are we going to do for 2.0 and getting it out the door?
>
> Personally, I'd like to see the full G have a footprint of about 40MB
> (that's a little over 5MB larger than 1.1.1) and Minimal be around
> 20MB. Need to do some research on this (volunteers?)
Me ! Me ! Me !
Cheers
Prasad
Re: [DISCUSS] 2.0 Release Criteria
Posted by David Blevins <da...@visi.com>.
On Jul 16, 2007, at 3:18 PM, Jeff Genender wrote:
> Prasad Kashyap wrote:
>>
>> Theoretically it shouldn't matter at all. If they don't, let's just
>> release our existing combination of quad assemblies. There's a pack
>> for everybody.
>>
>
> +1
>
So where are things on the web container front with regards to the
console? IIRC, that was the only thing that prevented us from
shipping one big all-in-one assembly with say four config.xml files
in it for each combination. Theoretically we could even put up for
download one big non-certified binary followed by four separately
downloadable config.xml files, some certified and some not.
-David
Re: [DISCUSS] 2.0 Release Criteria
Posted by Jeff Genender <jg...@apache.org>.
Prasad Kashyap wrote:
> Jeff mentioned that people feel strongly about their webservices pack
> much like they would about religion. Does anybody have an idea on how
> these are most commonly used ?
>
> 1. Do people preferring one webservices pack also prefer one
> webcontainer over another ? Eg. do axis2 folks prefer Jetty over
> Tomcat ? Or they don't care ? Another way to look at it is, does one
> webcontainer go well with one webservices pack ? Eg. Is Tomcat better
> with CXF than with Axis2 ?
>
> Theoretically it shouldn't matter at all. If they don't, let's just
> release our existing combination of quad assemblies. There's a pack
> for everybody.
>
+1
> 2. I'm also curious to know if people commonly switch the packs
> midstream. Or do they just pick a pack and stick with it.
>
> Some enlightenment appreciated.
>
> Cheers
> Prasad
Re: [DISCUSS] 2.0 Release Criteria
Posted by Prasad Kashyap <go...@gmail.com>.
Jeff mentioned that people feel strongly about their webservices pack
much like they would about religion. Does anybody have an idea on how
these are most commonly used ?
1. Do people preferring one webservices pack also prefer one
webcontainer over another ? Eg. do axis2 folks prefer Jetty over
Tomcat ? Or they don't care ? Another way to look at it is, does one
webcontainer go well with one webservices pack ? Eg. Is Tomcat better
with CXF than with Axis2 ?
Theoretically it shouldn't matter at all. If they don't, let's just
release our existing combination of quad assemblies. There's a pack
for everybody.
2. I'm also curious to know if people commonly switch the packs
midstream. Or do they just pick a pack and stick with it.
Some enlightenment appreciated.
Cheers
Prasad
Re: [DISCUSS] 2.0 Release Criteria
Posted by Joe Bohn <jo...@earthlink.net>.
Jeff Genender wrote:
> Joe Bohn wrote:
>> That looks like a lot of assemblies to me. I'd personally prefer to
>> ship just 4 (or 5) assemblies total with just 2 javaee5 assemblies. We
>> could still certify all 4 javaee5 permutations even if we don't ship
>> unique assemblies. However, I think this is a "nice to have" rather
>> than critical ... time and severity of problems would push us to claim
>> certification for just 2 (maybe even just 1) configuration.
>>
>> Anybody have any idea/guess how many users are mostly concerned with the
>> minimal assemblies? If most users (or a significant number) are on
>> minimal then we might be spending too much energy trying to decide how
>> many javaee5 permutations to deliver for very little user benefit. Even
>> if we deliver just the 2 javaee5 assemblies the users that have a strong
>> opinion can easily reconfigure the server. My hunch is that most of the
>> strong opinions are developer opinions rather than opinions based upon
>> user needs.
>
> Then lets ask the community and get feedback. I personally am speaking
> to the CTS releases. The minimals seem as a no-brainer to me. I really
> think the quad release is the way to go.
Yes, we should try to get the users' opinion. I was speaking to all of
the assemblies because I was trying to look at things from the user's
perspective when they first go to the Geronimo download page. With the
quad JavaEE5 releases we're giving the user the choice of 7 assemblies
on the download page.
>
> I think running the CTS 2 additional times will not create much of a
> delay. If it looks like it will, then we drop the 2 additional. We
> also are setting our sites on Tomcat/Axis2 and Jetty/CXF. If we *can*
> deliver that, then I think its safe to say that all 4 will pass.
> However, its possible that it may end up as Jetty/Tomcat/CXF, because
> that one works.
I think we are in agreement on the certification objective:
- We target Tomcat/Axis2 & Jetty/CXF for certification with a target
deadline.
- If we beat our deadline with runway to spare we attempt to certify the
other 2 configurations. If we get it all done then great ... we claim
certification on all 4 configurations. Otherwise we just claim the 2
target configurations as certified. We could do all 4 certifications in
parallel but that would mean less machines available to certify the
target configurations more quickly. It takes close to 3 days for the
tests on a dedicated, fast machine with potential re-runs for the
strange failures that seem to happen in the harness. I was able to
speed this up some last time by splitting the tests on several identical
machines. Given that we don't have an infinite number of machines
running twice the number of tests will most likely double the time to
certify which is why I would prefer to certify the target configurations
and then certify the additional configs with the remaining time.
- If we have problems meeting the deadline for some reason we look for
the most likely configuration to pass and certify that configuration.
>
> I guess to get closer to Kevan's point (and Kevan, correct me if I am
> off base here), is...we have a certified stack. Do we want to set a
> date and draw a line in the sand for *some* release, whether its, 2 or 4
> certified versions, and the mix of configuration is dependent on who
> shows up as certified...and then have 2.0.1 be the official release of
> all 4? Or do we wait for Axis2 to catch up before an official 2.0 release?
This is where the discussion moves beyond certifying configurations to
the assemblies we create and make available for download.
- If we meet our target (dual) then we ship assemblies of the 2
configurations that passed certification (tomcat/axis2 & jetty/cxf).
- If we fail to meet our target we ship the 1 configuration that passed
as an assembly. This configuration may be neither of the target
configurations (most like it would be Tomcat/CXF that we certified on
previously). IMO we should have at least one assembly that has passed
CTS without any additional configuration necessary so we should
definitely ship this as an assembly. It it wasn't one of the targets
then we should re-evaluate what additional assemblies to ship. It would
seem logical to ship an assembly with the opposite components in the
configuration. (lots of words for an unlikely scenario)
- If we surpass our target and certify on all 4 configurations we could
choose to distribute all 4 assemblies. However, I personally don't
think that is necessary and it may not even be desirable. My initial
reaction is in favor of simplification over giving the user all these
choices when they first go to the Geronimo download page. I think we're
already overly complex with duplicate assemblies based on the web server
impl. Adding the web services impl to the mix and filling out the
matrix just makes it worse. Users that have a strong preference on the
web services impl can easily change the configuration (we could even put
a note on the download page about this). However, since we don't have
data on the user preference one way or the other I think this all comes
down to what we think most users want/need. I think the most users want
simplicity but I'll go along with the group consensus.
>
> Joe, may I ask why you are not up to a quad release if its just running
> the tests 2 additional times and causing very little delay?
I ended up answering this above. I hope that helps clarify my opinion.
But it really is just my opinion at this point so I'm open to hearing
other opinions.
Re: [DISCUSS] 2.0 Release Criteria
Posted by Jeff Genender <jg...@apache.org>.
Joe Bohn wrote:
> That looks like a lot of assemblies to me. I'd personally prefer to
> ship just 4 (or 5) assemblies total with just 2 javaee5 assemblies. We
> could still certify all 4 javaee5 permutations even if we don't ship
> unique assemblies. However, I think this is a "nice to have" rather
> than critical ... time and severity of problems would push us to claim
> certification for just 2 (maybe even just 1) configuration.
>
> Anybody have any idea/guess how many users are mostly concerned with the
> minimal assemblies? If most users (or a significant number) are on
> minimal then we might be spending too much energy trying to decide how
> many javaee5 permutations to deliver for very little user benefit. Even
> if we deliver just the 2 javaee5 assemblies the users that have a strong
> opinion can easily reconfigure the server. My hunch is that most of the
> strong opinions are developer opinions rather than opinions based upon
> user needs.
Then lets ask the community and get feedback. I personally am speaking
to the CTS releases. The minimals seem as a no-brainer to me. I really
think the quad release is the way to go.
I think running the CTS 2 additional times will not create much of a
delay. If it looks like it will, then we drop the 2 additional. We
also are setting our sites on Tomcat/Axis2 and Jetty/CXF. If we *can*
deliver that, then I think its safe to say that all 4 will pass.
However, its possible that it may end up as Jetty/Tomcat/CXF, because
that one works.
I guess to get closer to Kevan's point (and Kevan, correct me if I am
off base here), is...we have a certified stack. Do we want to set a
date and draw a line in the sand for *some* release, whether its, 2 or 4
certified versions, and the mix of configuration is dependent on who
shows up as certified...and then have 2.0.1 be the official release of
all 4? Or do we wait for Axis2 to catch up before an official 2.0 release?
Joe, may I ask why you are not up to a quad release if its just running
the tests 2 additional times and causing very little delay?
Jeff
Re: [DISCUSS] 2.0 Release Criteria
Posted by Joe Bohn <jo...@earthlink.net>.
Jeff Genender wrote:
>
> Kevan Miller wrote:
>> We don't know what (if any) delay that we're looking at. To date, our
>> discussions have been that we'll certify both Tomcat/Axis *AND*
>> Jetty/CXF. That's a perfectly valid plan. As you point out, there's a
>> decent chance that the alternate permutations are compliant as well, and
>> we have a certification testing overhead. However, what if some
>> permutations are not compliant? What if one or more technologies are not
>> compliant in any permutation? Do we delay release? Or release with a
>> subset of compliant configurations?
>
> I think we should give it a shot and if it looks like its going to pass
> or a small fix, then lets do it. If it shows major errors, then sweep
> it under the rug for the time being and drop the 4 idea. Lets certainly
> not delay, but lets run 'em. Best case scenario is they pass and we
> have 4 releases. Worst is they don't pass and we fall back to the
> original plan.
>
>> So, our meets-max criteria is certify all permutations of web container
>> and web services technologies. What's meets-min? If we're delaying
>> making a decision on our meets-min criteria, then lets say we'll make
>> this decision at some future date.
>
> Meets-min == original plan.
>
>> With regards to what assemblies do we make available? I like your idea
>> of making it easy to switch web services technologies. Continue to
>> deliver Tomcat and Jetty assemblies. The Tomcat assembly defaults to
>> Axis2 for the Web Services implementation. The Jetty assembly defaults
>> to CXF. However, by editing the config.xml, either assembly can be
>> configured to use the alternate Web Services implementation.
>>
>
> Yep, but I think its a better sell at the end of the day to have all 4
> to met the religious needs. Again, we can always fall back to what you
> stated above.
>
Just to be clear ... the "4" assembly solution actually involves 6
(maybe 7 assemblies) of which we would only certify 4.
- tomcat javaee5 with axis2
- tomcat javaee5 with cxf
- jetty javaee5 with axis2
- jetty javaee5 with cxf
- tomcat minimal
- jetty minimal
- micro-G (Geronimo framework) is still included in the build as an
assembly as well. We could choose to skip this assembly for the release
as our plugin story still isn't complete ... but we delivered this in 1.2
That looks like a lot of assemblies to me. I'd personally prefer to
ship just 4 (or 5) assemblies total with just 2 javaee5 assemblies. We
could still certify all 4 javaee5 permutations even if we don't ship
unique assemblies. However, I think this is a "nice to have" rather
than critical ... time and severity of problems would push us to claim
certification for just 2 (maybe even just 1) configuration.
Anybody have any idea/guess how many users are mostly concerned with the
minimal assemblies? If most users (or a significant number) are on
minimal then we might be spending too much energy trying to decide how
many javaee5 permutations to deliver for very little user benefit. Even
if we deliver just the 2 javaee5 assemblies the users that have a strong
opinion can easily reconfigure the server. My hunch is that most of the
strong opinions are developer opinions rather than opinions based upon
user needs.
>
>>> What kind of testing are we talking about. Certainly not a CTS ;-)
>>> Again, by transitivity, if the big ones run, the little ones should too.
>>> This should be a relatively small obstacle IMHO.
>> Server starts, you can deploy web apps, the apps work, and the server
>> can be stopped... Something along those lines. Agreed that this is
>> small, but do you agree it's a must-have?
>>
>
> Yep...was just commenting on the criticality level ;-)
Agreed here as well. It sounds like a lot of our users are using
minimal so we want to make sure we don't break them.
>
>>>> 7. Eclipse Plugin. This won't release concurrently with 2.0. However, we
>>>> should insure that it's on target for release shortly after the server
>>>> release.
>>> +0...since they are on different schedules, I wouldn't hold up one for
>>> the other.
>> They are different schedules, but IMO there should be some level of
>> assurance that the plugin can be made to work. If some part of the
>> server implementation prevents the Eclipse plugin from working with a
>> 2.0 server, is that a stop-release issue?
>>
>
> IMNSHO..no. I still see them as 2 separate products...and not everyone
> uses Eclipse (well I do), so I would be against holding up G for the
> Eclipse plugin.
>
> Jeff
>
Re: [DISCUSS] 2.0 Release Criteria
Posted by Jeff Genender <jg...@apache.org>.
Kevan Miller wrote:
> We don't know what (if any) delay that we're looking at. To date, our
> discussions have been that we'll certify both Tomcat/Axis *AND*
> Jetty/CXF. That's a perfectly valid plan. As you point out, there's a
> decent chance that the alternate permutations are compliant as well, and
> we have a certification testing overhead. However, what if some
> permutations are not compliant? What if one or more technologies are not
> compliant in any permutation? Do we delay release? Or release with a
> subset of compliant configurations?
I think we should give it a shot and if it looks like its going to pass
or a small fix, then lets do it. If it shows major errors, then sweep
it under the rug for the time being and drop the 4 idea. Lets certainly
not delay, but lets run 'em. Best case scenario is they pass and we
have 4 releases. Worst is they don't pass and we fall back to the
original plan.
>
> So, our meets-max criteria is certify all permutations of web container
> and web services technologies. What's meets-min? If we're delaying
> making a decision on our meets-min criteria, then lets say we'll make
> this decision at some future date.
Meets-min == original plan.
>
> With regards to what assemblies do we make available? I like your idea
> of making it easy to switch web services technologies. Continue to
> deliver Tomcat and Jetty assemblies. The Tomcat assembly defaults to
> Axis2 for the Web Services implementation. The Jetty assembly defaults
> to CXF. However, by editing the config.xml, either assembly can be
> configured to use the alternate Web Services implementation.
>
Yep, but I think its a better sell at the end of the day to have all 4
to met the religious needs. Again, we can always fall back to what you
stated above.
>> What kind of testing are we talking about. Certainly not a CTS ;-)
>> Again, by transitivity, if the big ones run, the little ones should too.
>> This should be a relatively small obstacle IMHO.
>
> Server starts, you can deploy web apps, the apps work, and the server
> can be stopped... Something along those lines. Agreed that this is
> small, but do you agree it's a must-have?
>
Yep...was just commenting on the criticality level ;-)
>>
>>>
>>> 7. Eclipse Plugin. This won't release concurrently with 2.0. However, we
>>> should insure that it's on target for release shortly after the server
>>> release.
>>
>> +0...since they are on different schedules, I wouldn't hold up one for
>> the other.
>
> They are different schedules, but IMO there should be some level of
> assurance that the plugin can be made to work. If some part of the
> server implementation prevents the Eclipse plugin from working with a
> 2.0 server, is that a stop-release issue?
>
IMNSHO..no. I still see them as 2 separate products...and not everyone
uses Eclipse (well I do), so I would be against holding up G for the
Eclipse plugin.
Jeff
Re: [DISCUSS] 2.0 Release Criteria
Posted by Kevan Miller <ke...@gmail.com>.
Hey Jeff,
Thanks for the comments. Followups below...
--kevan
On Jul 13, 2007, at 9:24 AM, Jeff Genender wrote:
>
>
> Kevan Miller wrote:
>> 1. Certification. For M6 we certified a Tomcat/CXF configuration of
>> Geronimo. We'd like to certify 2.0 using Jetty and Axis2, also. What
>> configuration combinations *must* be certified? Is a single certified
>> configuration sufficient? Or do we want to certify with multiple
>> configurations? In an ideal world, I think we'd certify all 4
>> combinations of Web Container and Web Services implementations.
>> What's
>> our must have set? From discussions to date, it seems to be Tomcat/
>> Axis2
>> and Jetty/CXF. However, are we willing to delay a 2.0 release
>> until both
>> configurations are certified?
>
> But what kind of a delay are we really looking at? If Axis certifies
> with Tomcat, and Jetty certifies with CXF, by the rules of
> transitivity,
> there is a pretty good chance Tomcat/CXF and Jetty/Axis will certify
> just as easily. If we are not up for releasing 4 (which IMHO is not a
> big deal), then we really need to monitor the lists for what
> configurations users want. Religious wars abound on web service
> containers just as fiercely as the servlet containers do. Why not
> consider a quad release for 2.0 and see if it was painful/painless to
> run 4 certification runs? Based on the pain threshold, let the
> download
> count decide at the end of the day for what are default builds?
We don't know what (if any) delay that we're looking at. To date, our
discussions have been that we'll certify both Tomcat/Axis *AND* Jetty/
CXF. That's a perfectly valid plan. As you point out, there's a
decent chance that the alternate permutations are compliant as well,
and we have a certification testing overhead. However, what if some
permutations are not compliant? What if one or more technologies are
not compliant in any permutation? Do we delay release? Or release
with a subset of compliant configurations?
So, our meets-max criteria is certify all permutations of web
container and web services technologies. What's meets-min? If we're
delaying making a decision on our meets-min criteria, then lets say
we'll make this decision at some future date.
With regards to what assemblies do we make available? I like your
idea of making it easy to switch web services technologies. Continue
to deliver Tomcat and Jetty assemblies. The Tomcat assembly defaults
to Axis2 for the Web Services implementation. The Jetty assembly
defaults to CXF. However, by editing the config.xml, either assembly
can be configured to use the alternate Web Services implementation.
>
> As a side note (because I know it will be brought up), I do not
> think we
> are going down a slippery slope regarding certifying *any*
> configuration, and I think we are hitting just the major religious
> tones.
Agreed.
>
>>
>> 2. Fit and Finish. The "must-have" list would include Release Notes,
>> appropriately licensed source files, and up-to-date license and
>> notice
>> files. Other "Fit-and-Finish" items have been proposed. All are good
>> ideas. However, in my book, they fall into the "nice-to-have"
>> category
>> and are included below. I'd like to be careful with this category.
>> Otherwise, we end up with an always shifting target
>
> +1
>
>>
>> 3. Additional Features. With Gianni's latest WADI updates, I believe
>> that people are happy with the current set of functionality. Now
>> would
>> be a really good time to voice any disagreements. ;-) This also
>> implies
>> that we should be careful about starting new function development on
>> trunk. Also begs the question of when we move "2.0" off of trunk and
>> into a branch... I know some people are holding off new function
>> until
>> 2.0 has been branched.
>
> +1
>
>>
>> 4. Bug Fixes. Recent testing with DayTrader has identified several
>> deployment and memory-related problems which seem to fall into the
>> must-fix category. David J had a problem with manifest classpaths
>> that
>> he was fixing. If we have other must-fix bugs, we should call them
>> out
>> now. Naturally new must-fix problems may be raised prior to release.
>> However, we should avoid last minute surprises.
>>
>
> +1
>
>> 5. Dependencies. A number of our dependencies are SNAPSHOT
>> dependencies.
>> Many of these projects have or are in the process of being released.
>> Very difficult/impossible to get *all* projects lined up on a release
>> train. Also, likely that we'll have to Geronimo specific builds of
>> some
>> projects (e.g. Tomcat).
>
> Those that are SNAPSHOT will need a good prodding and we should
> probably
> begin that process now.
That process has already begun.
>
>>
>> 6. Little-G. I don't know of much testing that's occurred of our
>> Little-G configurations. We need to perform a basic validation of
>> these
>> assemblies.
>
> What kind of testing are we talking about. Certainly not a CTS ;-)
> Again, by transitivity, if the big ones run, the little ones should
> too.
> This should be a relatively small obstacle IMHO.
Server starts, you can deploy web apps, the apps work, and the server
can be stopped... Something along those lines. Agreed that this is
small, but do you agree it's a must-have?
>
>>
>> 7. Eclipse Plugin. This won't release concurrently with 2.0.
>> However, we
>> should insure that it's on target for release shortly after the
>> server
>> release.
>
> +0...since they are on different schedules, I wouldn't hold up one for
> the other.
They are different schedules, but IMO there should be some level of
assurance that the plugin can be made to work. If some part of the
server implementation prevents the Eclipse plugin from working with a
2.0 server, is that a stop-release issue?
>
>>
>> Nice-to-Haves
>
> +1 on the rest of these.
>
>>
>> 1. Fit and Finish. Reducing download and runtime size have been
>> proposed
>> as potential improvements. There was a fair amount of discussion
>> regarding download size. However, I don't see much active work
>> occurring. Improving performance is always nice... ;-) There was also
>> discussion of removing duplicate artifacts from our assemblies (i.e.
>> being smarter about what artifacts are being included by the
>> maven2 war
>> plugin and cleaning up some of our configurations) -- it would be
>> great
>> to see some of these issues fixed. However, IMO, it need not hold
>> up a
>> release.
>>
>> 2. Usability. There are a number of usability improvements (e.g.
>> improved messages and diagnostics) which have been proposed. There
>> has
>> been progress in this area already. My sense is we're ready to go
>> with
>> what we've got. We can make incremental improvements, of course.
>> However, I don't see a complete overhaul prior to 2.0 in the works...
>>
>> 3. Additional Features. As mentioned previously, we want to be
>> careful
>> about introducing new instabilities (I mean features ;-).
>>
>> 4. Bug Fixes. We can be a bit more aggressive, here. However, I
>> think we
>> need to still weigh potential instabilities against the anticipated
>> benefits.
>>
>> --kevan
>>
>>
Re: [DISCUSS] 2.0 Release Criteria
Posted by Jeff Genender <jg...@apache.org>.
Kevan Miller wrote:
> 1. Certification. For M6 we certified a Tomcat/CXF configuration of
> Geronimo. We'd like to certify 2.0 using Jetty and Axis2, also. What
> configuration combinations *must* be certified? Is a single certified
> configuration sufficient? Or do we want to certify with multiple
> configurations? In an ideal world, I think we'd certify all 4
> combinations of Web Container and Web Services implementations. What's
> our must have set? From discussions to date, it seems to be Tomcat/Axis2
> and Jetty/CXF. However, are we willing to delay a 2.0 release until both
> configurations are certified?
But what kind of a delay are we really looking at? If Axis certifies
with Tomcat, and Jetty certifies with CXF, by the rules of transitivity,
there is a pretty good chance Tomcat/CXF and Jetty/Axis will certify
just as easily. If we are not up for releasing 4 (which IMHO is not a
big deal), then we really need to monitor the lists for what
configurations users want. Religious wars abound on web service
containers just as fiercely as the servlet containers do. Why not
consider a quad release for 2.0 and see if it was painful/painless to
run 4 certification runs? Based on the pain threshold, let the download
count decide at the end of the day for what are default builds?
As a side note (because I know it will be brought up), I do not think we
are going down a slippery slope regarding certifying *any*
configuration, and I think we are hitting just the major religious tones.
>
> 2. Fit and Finish. The "must-have" list would include Release Notes,
> appropriately licensed source files, and up-to-date license and notice
> files. Other "Fit-and-Finish" items have been proposed. All are good
> ideas. However, in my book, they fall into the "nice-to-have" category
> and are included below. I'd like to be careful with this category.
> Otherwise, we end up with an always shifting target
+1
>
> 3. Additional Features. With Gianni's latest WADI updates, I believe
> that people are happy with the current set of functionality. Now would
> be a really good time to voice any disagreements. ;-) This also implies
> that we should be careful about starting new function development on
> trunk. Also begs the question of when we move "2.0" off of trunk and
> into a branch... I know some people are holding off new function until
> 2.0 has been branched.
+1
>
> 4. Bug Fixes. Recent testing with DayTrader has identified several
> deployment and memory-related problems which seem to fall into the
> must-fix category. David J had a problem with manifest classpaths that
> he was fixing. If we have other must-fix bugs, we should call them out
> now. Naturally new must-fix problems may be raised prior to release.
> However, we should avoid last minute surprises.
>
+1
> 5. Dependencies. A number of our dependencies are SNAPSHOT dependencies.
> Many of these projects have or are in the process of being released.
> Very difficult/impossible to get *all* projects lined up on a release
> train. Also, likely that we'll have to Geronimo specific builds of some
> projects (e.g. Tomcat).
Those that are SNAPSHOT will need a good prodding and we should probably
begin that process now.
>
> 6. Little-G. I don't know of much testing that's occurred of our
> Little-G configurations. We need to perform a basic validation of these
> assemblies.
What kind of testing are we talking about. Certainly not a CTS ;-)
Again, by transitivity, if the big ones run, the little ones should too.
This should be a relatively small obstacle IMHO.
>
> 7. Eclipse Plugin. This won't release concurrently with 2.0. However, we
> should insure that it's on target for release shortly after the server
> release.
+0...since they are on different schedules, I wouldn't hold up one for
the other.
>
> Nice-to-Haves
+1 on the rest of these.
>
> 1. Fit and Finish. Reducing download and runtime size have been proposed
> as potential improvements. There was a fair amount of discussion
> regarding download size. However, I don't see much active work
> occurring. Improving performance is always nice... ;-) There was also
> discussion of removing duplicate artifacts from our assemblies (i.e.
> being smarter about what artifacts are being included by the maven2 war
> plugin and cleaning up some of our configurations) -- it would be great
> to see some of these issues fixed. However, IMO, it need not hold up a
> release.
>
> 2. Usability. There are a number of usability improvements (e.g.
> improved messages and diagnostics) which have been proposed. There has
> been progress in this area already. My sense is we're ready to go with
> what we've got. We can make incremental improvements, of course.
> However, I don't see a complete overhaul prior to 2.0 in the works...
>
> 3. Additional Features. As mentioned previously, we want to be careful
> about introducing new instabilities (I mean features ;-).
>
> 4. Bug Fixes. We can be a bit more aggressive, here. However, I think we
> need to still weigh potential instabilities against the anticipated
> benefits.
>
> --kevan
>
>
[DISCUSS] 2.0 Release Criteria
Posted by Kevan Miller <ke...@gmail.com>.
On Jun 21, 2007, at 12:34 PM, Matt Hogstrom wrote:
> We've gone through the CTS grind and came out victorious http://
> java.sun.com/javaee/overview/compatibility.jsp
>
> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
> working that way too.
>
> All in all its been an excellent six months.
>
> So, what are we going to do for 2.0 and getting it out the door?
>
> Here are my thoughts and we can use this thread to gather everyone
> else's and come to a consensus.
>
> 2.0 Ship Criteria
> Date: mid to end of July (a target only...depends on content)
>
> Certified Assemblies
> Tomcat, Axis 2 and OpenJPA
> Jetty, CXF and OpenJPA
>
> Other assemblies would be the minimal assemblies but cert doesn't
> apply to them.
>
> Work on fit and finish stuff (cleaning up error messages, improving
> diagnostics, reducing footprint).
>
> Personally, I'd like to see the full G have a footprint of about
> 40MB (that's a little over 5MB larger than 1.1.1) and Minimal be
> around 20MB. Need to do some research on this (volunteers?)
>
> I'm not sure how the WADI clustering presents itself across the two
> different assemblies (Gianny, comments?)
Beneficial, I think, to conclude/summarize this discussion as we move
forward to finalizing release plans and dates. Since I'm introducing
some potentially "new" categorizations, I'm not calling this a
summary, yet...
In release discussions, like this, I'd like to see us be a little
clearer with regard to our "must-haves" and "nice-to-haves". In that
regard, the following is my evaluation of the criteria that we've
been discussing:
Must-Haves
1. Certification. For M6 we certified a Tomcat/CXF configuration of
Geronimo. We'd like to certify 2.0 using Jetty and Axis2, also. What
configuration combinations *must* be certified? Is a single certified
configuration sufficient? Or do we want to certify with multiple
configurations? In an ideal world, I think we'd certify all 4
combinations of Web Container and Web Services implementations.
What's our must have set? From discussions to date, it seems to be
Tomcat/Axis2 and Jetty/CXF. However, are we willing to delay a 2.0
release until both configurations are certified?
2. Fit and Finish. The "must-have" list would include Release Notes,
appropriately licensed source files, and up-to-date license and
notice files. Other "Fit-and-Finish" items have been proposed. All
are good ideas. However, in my book, they fall into the "nice-to-
have" category and are included below. I'd like to be careful with
this category. Otherwise, we end up with an always shifting target
3. Additional Features. With Gianni's latest WADI updates, I believe
that people are happy with the current set of functionality. Now
would be a really good time to voice any disagreements. ;-) This also
implies that we should be careful about starting new function
development on trunk. Also begs the question of when we move "2.0"
off of trunk and into a branch... I know some people are holding off
new function until 2.0 has been branched.
4. Bug Fixes. Recent testing with DayTrader has identified several
deployment and memory-related problems which seem to fall into the
must-fix category. David J had a problem with manifest classpaths
that he was fixing. If we have other must-fix bugs, we should call
them out now. Naturally new must-fix problems may be raised prior to
release. However, we should avoid last minute surprises.
5. Dependencies. A number of our dependencies are SNAPSHOT
dependencies. Many of these projects have or are in the process of
being released. Very difficult/impossible to get *all* projects lined
up on a release train. Also, likely that we'll have to Geronimo
specific builds of some projects (e.g. Tomcat).
6. Little-G. I don't know of much testing that's occurred of our
Little-G configurations. We need to perform a basic validation of
these assemblies.
7. Eclipse Plugin. This won't release concurrently with 2.0. However,
we should insure that it's on target for release shortly after the
server release.
Nice-to-Haves
1. Fit and Finish. Reducing download and runtime size have been
proposed as potential improvements. There was a fair amount of
discussion regarding download size. However, I don't see much active
work occurring. Improving performance is always nice... ;-) There was
also discussion of removing duplicate artifacts from our assemblies
(i.e. being smarter about what artifacts are being included by the
maven2 war plugin and cleaning up some of our configurations) -- it
would be great to see some of these issues fixed. However, IMO, it
need not hold up a release.
2. Usability. There are a number of usability improvements (e.g.
improved messages and diagnostics) which have been proposed. There
has been progress in this area already. My sense is we're ready to go
with what we've got. We can make incremental improvements, of course.
However, I don't see a complete overhaul prior to 2.0 in the works...
3. Additional Features. As mentioned previously, we want to be
careful about introducing new instabilities (I mean features ;-).
4. Bug Fixes. We can be a bit more aggressive, here. However, I think
we need to still weigh potential instabilities against the
anticipated benefits.
--kevan
Re: [DISCUSS] 2.0 Release Criteria
Posted by Hernan Cunico <hc...@gmail.com>.
We have done that in the past and then put it back again. IIRC the ldap bits were under 1 mb.
Cheers!
Hernan
Donald Woods wrote:
> For footprint, we could shave 4-5MB by removing ApacheDS and a couple
> sample apps that are getting installed. Given there is a ApacheDS 1.0
> and 1.5 release stream, we should move this out to the
> geronimo/plugins/trunk and allow users to choose which level they want
> to install from our plugin site.....
>
>
> -Donald
>
> Jay D. McHugh wrote:
>> I agree that 'fit and finish' and tooling are probably the most
>> important things to clean up before the final 2.0.0 release.
>>
>> As far as footprint - on my system, tomcat-jee5 is about 75M
>> installed. Getting this down to 40M seems like a huge task to try to
>> accomplish before releasing. When we added Dojo to the server, that
>> was an additional 6M right there - So maybe trying to cut 20-25M
>> rather than 35M would be more realistic.
>>
>> Jay
>>
>> Jacek Laskowski wrote:
>>> On 6/21/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>>> We've gone through the CTS grind and came out victorious http://
>>>> java.sun.com/javaee/overview/compatibility.jsp
>>>>
>>>> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
>>>> working that way too.
>>>>
>>>> All in all its been an excellent six months.
>>>>
>>>> So, what are we going to do for 2.0 and getting it out the door?
>>>
>>> I think you narrowed it down to the acceptable minimum and the sooner
>>> Geronimo 2.0 sees the light the better. No need to wait for anything
>>> else but bugs and only those that prevent us from releasing Geronimo.
>>> I know that having a Java EE 5 certified release as RC is not a good
>>> option for many people. A Java EE 5 certified and final release is
>>> what people seem to be waiting for - me at very least.
>>>
>>> Of course, tooling is another factor why people would choose Geronimo
>>> over...ekhm...other app servers so Eclipse and NetBeans support with
>>> M2 plugins would be a great bonus to offer. Eclipse plugin is almost
>>> ready whereas NetBeans IDE...hmm....more to come soon. I had some
>>> minor issues with geronimo m2 plugin so when Geronimo gets appropriate
>>> attention being able to boot up a fully Java EE 5 certified
>>> application server and test out ears is another differentiator. So,
>>> let's polish it and put on the shelves...asap - 07/15 the very least.
>>>
>>> Jacek
>>>
>>
>>
Re: [DISCUSS] 2.0 Release Criteria
Posted by Donald Woods <dw...@apache.org>.
For footprint, we could shave 4-5MB by removing ApacheDS and a couple sample
apps that are getting installed. Given there is a ApacheDS 1.0 and 1.5
release stream, we should move this out to the geronimo/plugins/trunk and
allow users to choose which level they want to install from our plugin site.....
-Donald
Jay D. McHugh wrote:
> I agree that 'fit and finish' and tooling are probably the most
> important things to clean up before the final 2.0.0 release.
>
> As far as footprint - on my system, tomcat-jee5 is about 75M installed.
> Getting this down to 40M seems like a huge task to try to accomplish
> before releasing. When we added Dojo to the server, that was an
> additional 6M right there - So maybe trying to cut 20-25M rather than
> 35M would be more realistic.
>
> Jay
>
> Jacek Laskowski wrote:
>> On 6/21/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>> We've gone through the CTS grind and came out victorious http://
>>> java.sun.com/javaee/overview/compatibility.jsp
>>>
>>> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
>>> working that way too.
>>>
>>> All in all its been an excellent six months.
>>>
>>> So, what are we going to do for 2.0 and getting it out the door?
>>
>> I think you narrowed it down to the acceptable minimum and the sooner
>> Geronimo 2.0 sees the light the better. No need to wait for anything
>> else but bugs and only those that prevent us from releasing Geronimo.
>> I know that having a Java EE 5 certified release as RC is not a good
>> option for many people. A Java EE 5 certified and final release is
>> what people seem to be waiting for - me at very least.
>>
>> Of course, tooling is another factor why people would choose Geronimo
>> over...ekhm...other app servers so Eclipse and NetBeans support with
>> M2 plugins would be a great bonus to offer. Eclipse plugin is almost
>> ready whereas NetBeans IDE...hmm....more to come soon. I had some
>> minor issues with geronimo m2 plugin so when Geronimo gets appropriate
>> attention being able to boot up a fully Java EE 5 certified
>> application server and test out ears is another differentiator. So,
>> let's polish it and put on the shelves...asap - 07/15 the very least.
>>
>> Jacek
>>
>
>
Re: [DISCUSS] 2.0 Release Criteria
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
I agree that 'fit and finish' and tooling are probably the most
important things to clean up before the final 2.0.0 release.
As far as footprint - on my system, tomcat-jee5 is about 75M installed.
Getting this down to 40M seems like a huge task to try to accomplish
before releasing. When we added Dojo to the server, that was an
additional 6M right there - So maybe trying to cut 20-25M rather than
35M would be more realistic.
Jay
Jacek Laskowski wrote:
> On 6/21/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>> We've gone through the CTS grind and came out victorious http://
>> java.sun.com/javaee/overview/compatibility.jsp
>>
>> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
>> working that way too.
>>
>> All in all its been an excellent six months.
>>
>> So, what are we going to do for 2.0 and getting it out the door?
>
> I think you narrowed it down to the acceptable minimum and the sooner
> Geronimo 2.0 sees the light the better. No need to wait for anything
> else but bugs and only those that prevent us from releasing Geronimo.
> I know that having a Java EE 5 certified release as RC is not a good
> option for many people. A Java EE 5 certified and final release is
> what people seem to be waiting for - me at very least.
>
> Of course, tooling is another factor why people would choose Geronimo
> over...ekhm...other app servers so Eclipse and NetBeans support with
> M2 plugins would be a great bonus to offer. Eclipse plugin is almost
> ready whereas NetBeans IDE...hmm....more to come soon. I had some
> minor issues with geronimo m2 plugin so when Geronimo gets appropriate
> attention being able to boot up a fully Java EE 5 certified
> application server and test out ears is another differentiator. So,
> let's polish it and put on the shelves...asap - 07/15 the very least.
>
> Jacek
>
Re: [DISCUSS] 2.0 Release Criteria
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/21/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> We've gone through the CTS grind and came out victorious http://
> java.sun.com/javaee/overview/compatibility.jsp
>
> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
> working that way too.
>
> All in all its been an excellent six months.
>
> So, what are we going to do for 2.0 and getting it out the door?
I think you narrowed it down to the acceptable minimum and the sooner
Geronimo 2.0 sees the light the better. No need to wait for anything
else but bugs and only those that prevent us from releasing Geronimo.
I know that having a Java EE 5 certified release as RC is not a good
option for many people. A Java EE 5 certified and final release is
what people seem to be waiting for - me at very least.
Of course, tooling is another factor why people would choose Geronimo
over...ekhm...other app servers so Eclipse and NetBeans support with
M2 plugins would be a great bonus to offer. Eclipse plugin is almost
ready whereas NetBeans IDE...hmm....more to come soon. I had some
minor issues with geronimo m2 plugin so when Geronimo gets appropriate
attention being able to boot up a fully Java EE 5 certified
application server and test out ears is another differentiator. So,
let's polish it and put on the shelves...asap - 07/15 the very least.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: [DISCUSS] 2.0 Release Criteria
Posted by Kevan Miller <ke...@gmail.com>.
On Jun 21, 2007, at 12:34 PM, Matt Hogstrom wrote:
> We've gone through the CTS grind and came out victorious http://
> java.sun.com/javaee/overview/compatibility.jsp
>
> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
> working that way too.
>
> All in all its been an excellent six months.
>
> So, what are we going to do for 2.0 and getting it out the door?
>
> Here are my thoughts and we can use this thread to gather everyone
> else's and come to a consensus.
>
> 2.0 Ship Criteria
> Date: mid to end of July (a target only...depends on content)
>
> Certified Assemblies
> Tomcat, Axis 2 and OpenJPA
> Jetty, CXF and OpenJPA
Seems reasonable. I think it's a good idea to run tests of alternate
combinations of web container and web services implementations. We
don't need to to commit to certifying the 2 additional
configurations. However, I think we'll benefit by keeping ourselves
honest...
>
> Other assemblies would be the minimal assemblies but cert doesn't
> apply to them.
>
> Work on fit and finish stuff (cleaning up error messages, improving
> diagnostics, reducing footprint).
One mandatory fit-and-finish item is a thorough review (and update)
of our license/notice files. Jacek already noted that our disclaimers
were out-of-date.
>
> Personally, I'd like to see the full G have a footprint of about
> 40MB (that's a little over 5MB larger than 1.1.1) and Minimal be
> around 20MB. Need to do some research on this (volunteers?)
My unpacked geronimo 1.1.1 jetty server is 41 megs. 2.0-SNAPSHOT
unpacked is 73 megs. Would like to see the 2.0 size reduced. No way
that it'll be brought down to a 5 meg delta. Let's get an analysis of
where our growth is coming from. Then see what we think a reasonable
target is...
--kevan