You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stefano Mazzocchi <st...@apache.org> on 2004/03/06 01:20:23 UTC
feature request: top critical failures
Dear gumpmaisters,
we need a way to improve the state of our tree.
My idea is simple: send a summary email to this list with the current
state of the tree.
this should have a list of the build failures, ranked by the number of
other builds that depend on it.
For example:
excalibur-logging is breaking basically 40% of our tree and nobody
gives a damn.
nekohtml is not even there and again, it breaks a huge part of the
tree thru HTTPUnit that depends on it
My point it: we need a way to focus on hotspots.
Cocoon hasn't been built for 6 months because of dependency failures.
I'm committed to make this change, who's with me?
--
Stefano.
Re: feature request: top critical failures
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> we need a way to improve the state of our tree.
Agreed.
> My idea is simple: send a summary email to this list with the current
> state of the tree.
>
> this should have a list of the build failures, ranked by the number of
> other builds that depend on it.
Not ranked, but isn't this this? The 'affected' is intended to rank. I know
there is an overestimate in this number, but I didn't think there was an
underestimate [see below].
http://lsd.student.utwente.nl/gump/project_todos.html
I look at this page (like today) and focus on the one(s) w/ the highest
number -- hence the two mails I've sent today.
> For example:
>
> excalibur-logging is breaking basically 40% of our tree and nobody
> gives a damn.
>
> nekohtml is not even there and again, it breaks a huge part of the
> tree thru HTTPUnit that depends on it
Not sure these match what I see at:
http://lsd.student.utwente.nl/gump/project_todos.html
Is your 'view' more accurate? Can you elaborate on how you calculated these?
> My point it: we need a way to focus on hotspots.
Yup.
> Cocoon hasn't been built for 6 months because of dependency failures.
Funny, that was exactly what I was looking at today. I think an analysis of
this (known to be bloated) table gives us a view of how close something is
to getting built. Maybe we need to review the numbers of projects in various
states for here & see if this helps us detect non-lost-causes.
http://lsd.student.utwente.nl/gump/cocoon-2.1/cocoon_details.html#Full+Project+Dependencies
> I'm committed to make this change, who's with me?
I'm committed to your goal. I want 100% Gumpage as the norm & failures to
stand out. I'll help where I can.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: feature request: top critical failures
Posted by Leo Simons <le...@apache.org>.
Stefano Mazzocchi wrote:
> Dear gumpmaisters,
>
> we need a way to improve the state of our tree.
>
> My idea is simple: send a summary email to this list with the current
> state of the tree.
basically a text-based version of
http://lsd.student.utwente.nl/gump/project_todos.html
ranked by some weighing of "affected" and "state". Right? Sounds good.
Maybe we also need to additionally rank by not just "projects" in the
gump perspective, but also "projects" in the ASF perspective. It seems
the appropriate piece of data to look at is the "to" address of the
<nag/> tag (as most communities are defined by their mailing list). Good
idea?
> excalibur-logging is breaking basically 40% of our tree and nobody
> gives a damn.
most active avaloners (excalibur is a much-neglected part of avalon) are
gump-ignorant.
> nekohtml is not even there and again, it breaks a huge part of the tree
> thru HTTPUnit that depends on it
I have no idea what nekohtml is, but HTTPUnit is green:
http://lsd.student.utwente.nl/gump/httpunit/httpunit.html
> I'm committed to make this change, who's with me?
yeah! (I think Adam has actually done most of it already ;)
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: feature request: top critical failures
Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 6 Mar 2004, Adam R. B. Jack <aj...@apache.org> wrote:
>> I will try to suggest a new build.xml to the avalon team for this
>> component. May be it could be built with Maven, but I do not know
>> Maven, and I do not know either the interface between gump and
>> Maven.
>
> The way is it (was) meant to work is on types "maven ant" (I think
> this is the goal, to get a build.xml) and "maven gump" to get a Gump
> descriptor.
I think that this is not what the Avlon team has done, it looks more
as if they had tried to manually create Ant build files to simulate
Maven.
"maven ant" and "maven gump" have some quirks as well, at least with
some versions of Maven - Ant build files sometime contain absolute
paths that are only correct for the machine that has done "maven ant".
> I beleive Stefan knows of a reason why some <mkdir entries often
> need to get things to work, but that can be step two.
He has some vague theories ;-)
> BTW: We do now have Gump (at least Gumpy) building via Maven, and
> I'd like to see it tried on something real. This occurs when <maven
> is used instead of <ant in the descriptor.
Why not pick one of the mavenized projects, say one of the commons
components, and try? Make that two projects, one using <ant> and one
using <maven> so we can compare the results.
> I'd be tempted to have Gump write the build script on the fly, from
> the information in the metadata,
This would never work 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: feature request: top critical failures
Posted by "Adam R. B. Jack" <aj...@apache.org>.
> Actually in the last one or two months, I have been "giving a damn" as
> you said.
I suspect Stefano meant more from the owners, not all the Gumpmeisters 'cos
we are a caring bunch. ;-) We've noticed all you've achieved ... (hmm, we
need a FOG Factor for a count of projects & dependencies that folks have
returned to the fold. ;-)
> I will try to suggest a new build.xml to the avalon team for this
> component. May be it could be built with Maven, but I do not know Maven,
> and
> I do not know either the interface between gump and Maven.
The way is it (was) meant to work is on types "maven ant" (I think this is
the goal, to get a build.xml) and "maven gump" to get a Gump descriptor.
These then get check in, and the rest you know. I beleive Stefan knows of a
reason why some <mkdir entries often need to get things to work, but that
can be step two.
BTW: We do now have Gump (at least Gumpy) building via Maven, and I'd like
to see it tried on something real. This occurs when <maven is used instead
of <ant in the descriptor.
http://lsd.student.utwente.nl/gump/jakarta-gump-test/gump-test-maven1.html
http://lsd.student.utwente.nl/gump/jakarta-gump-test/gump-test-maven2.html
Unfortunately if one sets a dependency on <maven -- not actually necessary
right now, one doesn't get a build:
http://lsd.student.utwente.nl/gump/incubator-geronimo/incubator-geronimo.html
http://lsd.student.utwente.nl/gump/incubator-geronimo/incubator-geronimo_details.html#Definition
> I am also wondering whether we should not define some gump best
> practices for ant build files of individual projects :
Not a bad idea, we could add it to this (intended to be Gump best
practices).
http://gump.apache.org/metadata/practices.html
> *A good build file (for gump) is a simple build file*
You know, I so agree! All Gump ought need is compile & jar -- and it if
wouldn't destroy Stefan's ant regression testing tool I'd be tempted to have
Gump write the build script on the fly, from the information in the
metadata, and forget any complex build tools.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: feature request: top critical failures
Posted by Stefan Bodewig <bo...@apache.org>.
On Sun, 07 Mar 2004, Stefano Mazzocchi <st...@apache.org> wrote:
> With "nobody gives a damn" I meant none of the avalon people.
They are possibly busy bashing each other. Oops, off topic.
> There are two paths here:
>
> 1) make gump smart enough to work with that's out there
The problem with most of the excalibur components is that their build
files simply don't work. Neither using Gump nor running Ant from the
command line. I'm not sure whether they'd actually build using Maven,
I've come to have my doubts here as well.
But this probably is the only option for Gump, run Maven for projects
that build using Maven since the developers will never run the build
files they provide and thus never know that those build files don't
work.
>> I will give a shout to the xdoclet guys concerning this later.
Antoine, consider pinging Erik Hatcher, he has commit access to the
xdoclet module.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: feature request: top critical failures
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> But you are right, if the number of dependencies is displayed, it will
> be easier to detect the spots which are harming a lot gump.
I think gumpy suffers from "data overload" syndrome: too many numbers,
too much eye candy... it's harder to spot where the errors are.
One person's eye candy is another person's complete transparency. ;-)
Seriously though, Gumpy will mature to the point of knowing what is optimal
& what is fluff, but to this point it's has been a case of exploring/display
what is possible. I agree, it has amassed & has reached overload.
I think we ought start to teach the forrest loader to display less and less
unless verbose or debug (or an error condition, e.g. failed state) exist. We
can have vast sections of the output excluded via this, and only have (say)
the details page when needed, or aspects of any.
Now, let's all figure out what is noise in the normal, and ought be
reduced...
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: feature request: top critical failures
Posted by Stefano Mazzocchi <st...@apache.org>.
Antoine Lévy-Lambert wrote:
> Stefano Mazzocchi wrote:
>
>> Dear gumpmaisters,
>>
>> excalibur-logging is breaking basically 40% of our tree and nobody
>> gives a damn.
>>
>>
> Hi Stefano,
>
> Actually in the last one or two months, I have been "giving a damn" as
> you said. With the participation of the corresponding communities,
> and the help of Stefan Bodewig, we got a number of builds with a lot of
> dependencies, located upstream of excalibur-logging, repaired :
> - jaxen,
> - dom4j,
> - xml-fop,
> - .velocity
Antoine,
I seriously apologize if my comment sounded offensive. With "nobody
gives a damn" I meant none of the avalon people. Which is really making
me sad and a little bit worried, given how much cocoon relies on those
pieces.
> But you are right, if the number of dependencies is displayed, it will
> be easier to detect the spots which are harming a lot gump.
I think gumpy suffers from "data overload" syndrome: too many numbers,
too much eye candy... it's harder to spot where the errors are.
> Concerning excalibur-logging :
>
> The build file of excalibur-logging does not match the source tree of
> this component, and expects java sources to be at a place where they are
> not.
>
> I will try to suggest a new build.xml to the avalon team for this
> component. May be it could be built with Maven, but I do not know Maven,
> and
> I do not know either the interface between gump and Maven.
>
> I am also wondering whether we should not define some gump best
> practices for ant build files of individual projects :
>
> - the full path of each dependency jar should be a property, not just
> the name of the jar (so that gump can override the property properly)
> - preferably, the build.xml of each project should not attempt to build
> another project, or there should be a way for gump (by setting properties)
> to prevent this from happening.
> I am thinking here about xdoclet. xdoclet is expecting xjavadoc to be in
> a parallel source tree ( ../xjavadoc ) which is OK for gump
> and tries to build the xjavadoc.jar (not good) when the xdoclet build
> file thinks the xjavadoc.jar is not uptodate with the sources.
There are two paths here:
1) make gump smart enough to work with that's out there
2) lobby to change things for them to adapt in whatever gump way
Technically, 2 is king.
Socially, 2 is impossible.
> I will give a shout to the xdoclet guys concerning this later. The point
> I am trying to make is that :
>
> *A good build file (for gump) is a simple build file*
True.
Unfortunately, this is real life and real life is a bitch.
We must build gump so that it can cope with the real world, the opposite
is just too hard to be true.
--
Stefano.
Re: feature request: top critical failures
Posted by Antoine Lévy-Lambert <an...@antbuild.com>.
Stefano Mazzocchi wrote:
> Dear gumpmaisters,
>
> excalibur-logging is breaking basically 40% of our tree and nobody
> gives a damn.
>
>
Hi Stefano,
Actually in the last one or two months, I have been "giving a damn" as
you said. With the participation of the corresponding communities,
and the help of Stefan Bodewig, we got a number of builds with a lot of
dependencies, located upstream of excalibur-logging, repaired :
- jaxen,
- dom4j,
- xml-fop,
- .velocity
But you are right, if the number of dependencies is displayed, it will
be easier to detect the spots which are harming a lot gump.
Concerning excalibur-logging :
The build file of excalibur-logging does not match the source tree of
this component, and expects java sources to be at a place where they are
not.
I will try to suggest a new build.xml to the avalon team for this
component. May be it could be built with Maven, but I do not know Maven,
and
I do not know either the interface between gump and Maven.
I am also wondering whether we should not define some gump best
practices for ant build files of individual projects :
- the full path of each dependency jar should be a property, not just
the name of the jar (so that gump can override the property properly)
- preferably, the build.xml of each project should not attempt to build
another project, or there should be a way for gump (by setting properties)
to prevent this from happening.
I am thinking here about xdoclet. xdoclet is expecting xjavadoc to be in
a parallel source tree ( ../xjavadoc ) which is OK for gump
and tries to build the xjavadoc.jar (not good) when the xdoclet build
file thinks the xjavadoc.jar is not uptodate with the sources.
I will give a shout to the xdoclet guys concerning this later. The point
I am trying to make is that :
*A good build file (for gump) is a simple build file*
Cheers,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org