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/10/07 15:37:55 UTC
[status] main issues
There are three main issues, IMO, that prevent gump from reaching a
thermal equilibrium.
1) the data pollution is too much (signal/noise ratio too low)
2) the metadata is black magic, inconsistent and not properly documented
3) the maven integration is poor and hacky
before we can tackle the real juicy challenges that gump faces (for
example, serious blame back-tracking) we need to get to equilibrium.
Equilibrium is defined when there are no projects with FOG = 0.00
So, goal #1 of this group, IMO, should focus on reaching equilibrium
before attempting to do anything more serious.
Of the above, I worked on 2) by creating a validation tool. Next phase
is to write a cron job that validates each module descriptor and nags if
it's not valid.
As for 1), I plan to improve the HTML output first (remove some of the
noise and use DHTML to make ti a little more dynamic), and second work
on a dynamic webapp for data visualization.
But the *most* serious concern is that we seem to have no way to build
with Maven and, due to excalibur, this is holding up basically 15
percent of our projects (including, yes, you guessed right, cocoon).
The problem with maven is that I don't know how we can "inject" the
gump-generated dependency jars into maven.
Does anybody have an idea? we can't expect excalibur to fix this on
their own since this is obviously a gump issue, more than an excalibur
issue.
--
Stefano.
Re: maven, gump, developer effort (was: Re: [status] main issues)
Posted by Brett Porter <br...@gmail.com>.
> I will assert that maven is the root problem (no offense intended to the
> maven people, I'm rather happy with maven recently otherwise). Maven is
No offense taken :) However, I don't think Maven itself is the problem
- as Adam has said, building works fine until we get to conflicting
dependency IDs. I'll discuss this against Adam's mail.
> not built to have other stuff control it, ie it is not very embeddable
> (unlike ant).
This is true - but this is not how gump uses it?
> It is also not properly bootstrappable.
I'm not entirely sure this is correct. Some small work would need to
be done to get it to play with gump, but this is on the Maven build,
not on Maven itself. I haven't pursued this because I don't want it to
be "one more thing to break the build chain" until everyone is
comfortable with it as it stands.
> It also has too
> many complex dependencies itself.
I've started cutting these down for Maven 1.1. I think dom4j and jelly
will always be problematic in the Maven 1.0 lifecycle though.
> I will assert as well that this problem goes away with maven2
> (http://cvs.apache.org/viewcvs.cgi/maven-components/ and
> http://nagoya.apache.org/eyebrowse/SummarizeList?listId=254), being
> built using an IoC container and all as it is.
I think it will still build in the same way (jar overrides), but it
should be a whole lot easier to play with. You're right - you could
completely replace the artifact location mechanism if you wanted.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: maven, gump, developer effort
Posted by Peter Janes <pe...@liberate.com>.
Leo Simons wrote:
> I will assert that the most serious concern with gump is that it is too
> hard to use, understand or improve for non-gump-gurus. If this were a
> componay and I were the boss, the first thing I would tell people to
> work on is a much more readable and enticing website. Ie "What is Gump?
> Gump is a social experiment." is not very successful marketing-wise.
For what it's worth, I don't think it's too hard to use or understand.
(Times below are approximate because I've been doing this as a side project
for work whenever I've had a few free cycles.)
I had my very first experience setting up "classic" XSLT Gump just before it
was removed from CVS, based only on the "GOM" docs on the website and the
existing metadata files. Within a couple of days I'd extended it to perform
Perforce-based checkouts. I used a half-dozen of the "official" metadata
modules but the vast majority are homegrown.
Migrating the classic install to Python Gump, sans Perforce support, was a
snap. Adding Perforce took a little while longer--about a week--but that was
mostly due to my unfamiliarity with Python and the structure of the code.
There are certainly things to be improved, most of which are being discussed
in other threads right now. Of greatest importance (to me, at least) are
reporting and nagging, both of which are pretty heavyweight: the classic
versions were much friendlier. It would also be nice to achieve parity with
classic Gump, specifically supporting the <javadoc/> element. The internals
aren't the easiest thing to dive into to make changes, or I'd probably have
added support for publishing Javadocs to the artifacts repository myself.
All in all, I don't think Gump for "users" is as horrendous a beast as you've
made it sound. I don't consider myself a "gump-guru" in any sense, but I've
had more trouble getting Ant to run some of our less trivial builds than I had
installing, configuring and running Gump to build the 60-odd projects we have
in-house. I don't understand Maven *at all*, and I've tried a couple of times.
> The second thing I would have my team do is to get in place a
> double-click (and/or configure; make; make install) installer.
Which would do what exactly, other than unzip the distribution into a
directory? I'm just curious--other than getting SVN, Java and the right
version of Python onto a new machine, it took me all of 5 minutes to
completely "reinstall" my entire Gump setup, so I don't understand why an
installer would be worth the effort. (Unless you're talking about rolling out
Gump to every person on a team... in which case my question would be "why?")
Peter J.
--
Sometimes the Universe needs a change of perspective.
--J. Michael Straczynski
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: maven, gump, developer effort
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:
> Disclaimer: it has been weeks/months since I last looked into all this.
>
> Stefano Mazzocchi wrote:
>
>> But the *most* serious concern is that we seem to have no way to build
>> with Maven and, due to excalibur, this is holding up basically 15
>> percent of our projects (including, yes, you guessed right, cocoon).
>
>
> actually, we do, but I think its buggy.
>
>> The problem with maven is that I don't know how we can "inject" the
>> gump-generated dependency jars into maven.
>
>
> that has been answered by others now :-D
>
>> Does anybody have an idea?
>
>
> I will assert that maven is the root problem (no offense intended to the
> maven people, I'm rather happy with maven recently otherwise). Maven is
> not built to have other stuff control it, ie it is not very embeddable
> (unlike ant). It is also not properly bootstrappable. It also has too
> many complex dependencies itself.
>
> I will assert as well that this problem goes away with maven2
> (http://cvs.apache.org/viewcvs.cgi/maven-components/ and
> http://nagoya.apache.org/eyebrowse/SummarizeList?listId=254), being
> built using an IoC container and all as it is.
>
> There was/is a pretty aggressive schedule set for maven2 (IIRC the
> original idea was to have it released by now), which made me want to
> work on all this even less.
>
> ---
>
> Some general comments are no doubt still valid.
>
> Taking even a short look at the CVS|SVN history of the excalibur
> codebases (barring various experiments and other "noise") reveals that a
> rather significant part of the time has been invested in build systems,
> gump integration etc etc. For a supposedly mature and stable project,
> much much more than makes sense.
>
> That had to stop, and it has. The only healthy way to improve the
> excalibur "FOG" factor is to make it easy and worthwhile for excalibur
> and others to do just that.
>
> I will assert that the most serious concern with gump is that it is too
> hard to use, understand or improve for non-gump-gurus. If this were a
> componay and I were the boss, the first thing I would tell people to
> work on is a much more readable and enticing website. Ie "What is Gump?
> Gump is a social experiment." is not very successful marketing-wise.
>
> The second thing I would have my team do is to get in place a
> double-click (and/or configure; make; make install) installer.
>
> g'night!
Leo,
do you want to help making gump a better thing? fix that damn excalibur
project!
Don't ask what gump can do for you, but what you can do for gump.
Everything we talked at FooCamp does *NOT* work if we don't reach
equilibrium.
Do you want an easier Gump? a better documentation? better marketing?
better ability to spot blame? a better way to edit the metadata and
validate it?
Join the club.
Now, can we get to equilibrium first? please? can you help me help you?
--
Stefano.
maven, gump, developer effort (was: Re: [status] main issues)
Posted by Leo Simons <ls...@jicarilla.org>.
Disclaimer: it has been weeks/months since I last looked into all this.
Stefano Mazzocchi wrote:
> But the *most* serious concern is that we seem to have no way to build
> with Maven and, due to excalibur, this is holding up basically 15
> percent of our projects (including, yes, you guessed right, cocoon).
actually, we do, but I think its buggy.
> The problem with maven is that I don't know how we can "inject" the
> gump-generated dependency jars into maven.
that has been answered by others now :-D
> Does anybody have an idea?
I will assert that maven is the root problem (no offense intended to the
maven people, I'm rather happy with maven recently otherwise). Maven is
not built to have other stuff control it, ie it is not very embeddable
(unlike ant). It is also not properly bootstrappable. It also has too
many complex dependencies itself.
I will assert as well that this problem goes away with maven2
(http://cvs.apache.org/viewcvs.cgi/maven-components/ and
http://nagoya.apache.org/eyebrowse/SummarizeList?listId=254), being
built using an IoC container and all as it is.
There was/is a pretty aggressive schedule set for maven2 (IIRC the
original idea was to have it released by now), which made me want to
work on all this even less.
---
Some general comments are no doubt still valid.
Taking even a short look at the CVS|SVN history of the excalibur
codebases (barring various experiments and other "noise") reveals that a
rather significant part of the time has been invested in build systems,
gump integration etc etc. For a supposedly mature and stable project,
much much more than makes sense.
That had to stop, and it has. The only healthy way to improve the
excalibur "FOG" factor is to make it easy and worthwhile for excalibur
and others to do just that.
I will assert that the most serious concern with gump is that it is too
hard to use, understand or improve for non-gump-gurus. If this were a
componay and I were the boss, the first thing I would tell people to
work on is a much more readable and enticing website. Ie "What is Gump?
Gump is a social experiment." is not very successful marketing-wise.
The second thing I would have my team do is to get in place a
double-click (and/or configure; make; make install) installer.
g'night!
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Maven and excalibur
Posted by Brett Porter <br...@gmail.com>.
Hi,
Been meaning to reply to that other thread for some time...
On Thu, 7 Oct 2004 17:15:34 -0600, Adam R. B. Jack <aj...@apache.org> wrote:
>
> Basically, the first one I looked at either needed more Gump <depends in the
> descriptor (or changes to 'jar ids', see next) that lead to Maven jar
> overrides. BTW: The 'gump' goal for a Maven project takes this information
> from the POM and creates the correct Gump descriptor. Have you tried that?
My main worry is that there may be more information in the gump
descriptor than the maven plugin will create. Is anyone prepared to
try "maven gump" on excalibur and tell me what is missing?
I don't really have a desire to learn any more about gump to be
honest, but am happy to help out.
Niclas showed that Magic's descriptor lets you put gump id's against
every dependency. We can do that in Maven without changing the schema
if we need an interim solution while gump moves to a more robust ID
namespace. But its only going to be helpful if the maven gump goal is
being used to generate the descriptor, so that needs to be attempted
first.
> did mention groupId and artifactId -- whereas Gump has 'jar id' (which we
> map only to artifact id). As I understand it Maven 1.0 is still ok w/
> artifact id, it isn't yet requiring groupId, that is coming soon. When it
We won't "require" groupId in jar overrides for backwards
compatibility, but it needs to be an option to give it, because there
are already conflicts in the artifactId namespace as is shown in
excalibur.
> The main problem we have is that Gump jar ids are not sufficiently unique,
> so we've decided to (bit by bit) change ours to match theirs.
>
> When I get time I'll look at these closer.
Thanks Adam.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Maven and excalibur
Posted by "Adam R. B. Jack" <aj...@apache.org>.
> maven integration might not be hacky (true, I had no idea we were
> injectin stuff in, so I take that back) but it does not work at all.
Wanna take that back also? ;-) It works for a number of Maven projects.
e.g.
http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html
See:
http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_file/build.properties.html
> Problem is
>
> http://brutus.apache.org/gump/public/excalibur/
>
Basically, the first one I looked at either needed more Gump <depends in the
descriptor (or changes to 'jar ids', see next) that lead to Maven jar
overrides. BTW: The 'gump' goal for a Maven project takes this information
from the POM and creates the correct Gump descriptor. Have you tried that?
> Now, tell me, is this just a matter of fixing the excalibur.xml file or,
> like Stephen suggested, the problem is much deeper?
I'm on diaper duty today, so I haven't had chance to read Stephen's
concerns. I also don't know if 'Magic' is involved here. That said, Stephen
did mention groupId and artifactId -- whereas Gump has 'jar id' (which we
map only to artifact id). As I understand it Maven 1.0 is still ok w/
artifact id, it isn't yet requiring groupId, that is coming soon. When it
comes we'll probably use the module name as the groupId default, and allow
overrides.
The main problem we have is that Gump jar ids are not sufficiently unique,
so we've decided to (bit by bit) change ours to match theirs.
When I get time I'll look at these closer.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [status] main issues
Posted by Stefano Mazzocchi <st...@apache.org>.
Adam R. B. Jack wrote:
> So what is the problem?
Problem is
http://brutus.apache.org/gump/public/excalibur/
maven integration might not be hacky (true, I had no idea we were
injectin stuff in, so I take that back) but it does not work at all.
Now, tell me, is this just a matter of fixing the excalibur.xml file or,
like Stephen suggested, the problem is much deeper?
--
Stefano.
Re: [status] main issues
Posted by "Adam R. B. Jack" <aj...@apache.org>.
> 3) the maven integration is poor and hacky
How much do you actually know about this integration? I don't know that it
is poor, and I believe it is not hacky. Where are you getting your
information?
> But the *most* serious concern is that we seem to have no way to build
> with Maven and, due to excalibur, this is holding up basically 15
> percent of our projects (including, yes, you guessed right, cocoon).
>
> The problem with maven is that I don't know how we can "inject" the
> gump-generated dependency jars into maven.
We are doing it. Clearly you've next to no idea on how this works.
We use the technique that Mavenites told us was appropriate:
http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependencies
> Does anybody have an idea? we can't expect excalibur to fix this on
> their own since this is obviously a gump issue, more than an excalibur
> issue.
So what is the problem?
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [status] main issues
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 October 2004 21:37, Stefano Mazzocchi wrote:
> The problem with maven is that I don't know how we can "inject" the
> gump-generated dependency jars into maven.
Brett Porter (Maven expert) is normally around to answer questions on how
Maven operates.
> Does anybody have an idea? we can't expect excalibur to fix this on
> their own since this is obviously a gump issue, more than an excalibur
> issue.
I can propose a short term solution;
Revert the Excalibur packages in Gump back to the one sitting in the frozen
"avalon-excalibur" CVS, which builds close to perfectly in Gump (I think
there is the altrmi instrumentation packages that fails as a dep on altrmi,
or something like that.)
Then we take the Excalibur Maven projects and name them slightly different, so
we can sort that out without holding up all the projects downstream.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [status] main issues
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen,
thanks much for your input. Some comments below.
>>But the *most* serious concern is that we seem to have no way to build
>
>
>>with Maven and, due to excalibur, this is holding up basically 15
>>percent of our projects (including, yes, you guessed right, cocoon).
>
>
> Fast track solution could be to put the last released jar files into an
> excalibur-releases module with project ids matching the current set of
> ids, and disable the existing excalibur descriptors pending resolution
> of gump/maven equation (see below).
Yes, that might be an ad-hoc solution and it might work for now since
there are not so many maven projects in our tree anyway (just checked).
Can you provide such a 'fake' descriptor? i think it would be much
faster than me trying to hack one up.
>>The problem with maven is that I don't know how we can "inject" the
>>gump-generated dependency jars into maven.
>
> Maven is fine on the "injection" stuff - basically it used a jar
> override property that tells maven to use the jar file named in a
> property value as the actual jar to bind against. The problem is the
> generation of the property files (by gump's maven builder).
Ok, good to know.
>
>>Does anybody have an idea?
>
> Gump uses a namespace made of a project id and an optional output key.
> Maven uses a combination of group and artifact name combination. If we
> take for example - the jar file produced by ant containing the junit
> optional task is referenced in gump as:
>
> project: ant
> id: junit
>
> In Maven the same jar file is normally referenced as:
>
> groupId: ant
> artifactId: ant-junit
>
> When Gump's maven builder generates the proprieties file used during the
> maven build, it uses the gump project model to establish the set of
> dependencies and for each dump declared dependency (with full
> inheritance of dependencies) create a property with the following name
> and value:
>
> maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.
> jar
>
> Problem here is that:
>
> 1. this property definition does not correspond to anything
> declared in the target project's project.xml (because the
> property is derived from the gump based dependencies - not
> the project's declared dependencies)
>
> 2. the strategy for mapping of gump artifact keys to maven
> artifact keys is basically broken in that duplicate property
> names can be generated (e.g. the property name generated for
> the main JUnit project jar file is "maven.jar.junit")
>
> The solution to this problem is to drive the property file generation
> off the project.xml file and NOT the gump dependency graph. This will
> solve most issues because it will result in a much smaller set of
> properties - but an underlying problem needs to be solved - namely the
> declaration within a maven project of any mappings between maven
> artifact names to gump project keys (e.g. ant/ant-junit --> ant:junit).
> These mappings need to be used by the maven gump task when generating a
> maven project descriptor.
I'm sorry, but I have lost you.
If the strategy is broken, why don't we fix it? [but I think I'm missing
a point here obviously]
--
Stefano.
RE: [status] main issues
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> But the *most* serious concern is that we seem to have no way to build
> with Maven and, due to excalibur, this is holding up basically 15
> percent of our projects (including, yes, you guessed right, cocoon).
Fast track solution could be to put the last released jar files into an
excalibur-releases module with project ids matching the current set of
ids, and disable the existing excalibur descriptors pending resolution
of gump/maven equation (see below).
> The problem with maven is that I don't know how we can "inject" the
> gump-generated dependency jars into maven.
Maven is fine on the "injection" stuff - basically it used a jar
override property that tells maven to use the jar file named in a
property value as the actual jar to bind against. The problem is the
generation of the property files (by gump's maven builder).
> Does anybody have an idea?
Gump uses a namespace made of a project id and an optional output key.
Maven uses a combination of group and artifact name combination. If we
take for example - the jar file produced by ant containing the junit
optional task is referenced in gump as:
project: ant
id: junit
In Maven the same jar file is normally referenced as:
groupId: ant
artifactId: ant-junit
When Gump's maven builder generates the proprieties file used during the
maven build, it uses the gump project model to establish the set of
dependencies and for each dump declared dependency (with full
inheritance of dependencies) create a property with the following name
and value:
maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.
jar
Problem here is that:
1. this property definition does not correspond to anything
declared in the target project's project.xml (because the
property is derived from the gump based dependencies - not
the project's declared dependencies)
2. the strategy for mapping of gump artifact keys to maven
artifact keys is basically broken in that duplicate property
names can be generated (e.g. the property name generated for
the main JUnit project jar file is "maven.jar.junit")
The solution to this problem is to drive the property file generation
off the project.xml file and NOT the gump dependency graph. This will
solve most issues because it will result in a much smaller set of
properties - but an underlying problem needs to be solved - namely the
declaration within a maven project of any mappings between maven
artifact names to gump project keys (e.g. ant/ant-junit --> ant:junit).
These mappings need to be used by the maven gump task when generating a
maven project descriptor.
Stephen.
> we can't expect excalibur to fix this on
> their own since this is obviously a gump issue, more than an excalibur
> issue.
>
> --
> Stefano.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: [status] main issues
Posted by Stephen McConnell <mc...@dpml.net>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> But the *most* serious concern is that we seem to have no way to build
> with Maven and, due to excalibur, this is holding up basically 15
> percent of our projects (including, yes, you guessed right, cocoon).
Fast track solution could be to put the last released jar files into an
excalibur-releases module with project ids matching the current set of
ids, and disable the existing excalibur descriptors pending resolution
of gump/maven equation (see below).
> The problem with maven is that I don't know how we can "inject" the
> gump-generated dependency jars into maven.
Maven is fine on the "injection" stuff - basically it used a jar
override property that tells maven to use the jar file named in a
property value as the actual jar to bind against. The problem is the
generation of the property files (by gump's maven builder).
> Does anybody have an idea?
Gump uses a namespace made of a project id and an optional output key.
Maven uses a combination of group and artifact name combination. If we
take for example - the jar file produced by ant containing the junit
optional task is referenced in gump as:
project: ant
id: junit
In Maven the same jar file is normally referenced as:
groupId: ant
artifactId: ant-junit
When Gump's maven builder generates the proprieties file used during the
maven build, it uses the gump project model to establish the set of
dependencies and for each dump declared dependency (with full
inheritance of dependencies) create a property with the following name
and value:
maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.
jar
Problem here is that:
1. this property definition does not correspond to anything
declared in the target project's project.xml (because the
property is derived from the gump based dependencies - not
the project's declared dependencies)
2. the strategy for mapping of gump artifact keys to maven
artifact keys is basically broken in that duplicate property
names can be generated (e.g. the property name generated for
the main JUnit project jar file is "maven.jar.junit")
The solution to this problem is to drive the property file generation
off the project.xml file and NOT the gump dependency graph. This will
solve most issues because it will result in a much smaller set of
properties - but an underlying problem needs to be solved - namely the
declaration within a maven project of any mappings between maven
artifact names to gump project keys (e.g. ant/ant-junit --> ant:junit).
These mappings need to be used by the maven gump task when generating a
maven project descriptor.
Stephen.
> we can't expect excalibur to fix this on
> their own since this is obviously a gump issue, more than an excalibur
> issue.
>
> --
> Stefano.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org