You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stefan Bodewig <bo...@apache.org> on 2005/03/15 12:48:03 UTC
CLASSPATH logic is failing on me
Hi,
struts-taglib failed because the velocity jar wasn't there. I don't
know whether it actually needs velocity, but it looks that way, so
I've added that dependency.
The point is, that velocity is on the CLASSPATH but hasn't been built
because of the log4j-12 failure. I don't understand why it is there.
Looking at
<http://brutus.apache.org/gump/public/struts/struts-taglib/details.html>
I see velocity on the classpath with "Instigator" (something I'll have
to look up in a dictionary) Anakia.
But struts-taglib doesn't depend on Anakia, so why can Anakia
contribute anything to struts-taglib?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: CLASSPATH logic is failing on me
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 15 Mar 2005, Bill Barker <wb...@wilshire.com> wrote:
> Maven requires velocity to execute the jar:jar target.
Interesting, any idea why?
> I'd always just assumed that it was pulling it from
> $HOME/.maven/repository.
Probably it does. But for some reason - I'll try to follow Adam's
explanation later - Gump generates CLASSPATH entries and jar overrides
for velocity in the struts-taglib case. And at the same time doesn't
realize that velocity hasn't been built.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: CLASSPATH logic is failing on me
Posted by Bill Barker <wb...@wilshire.com>.
"Stefan Bodewig" <bo...@apache.org> wrote in message
news:m3y8cpp1u4.fsf@bodewig.bost.de...
> Hi,
>
> struts-taglib failed because the velocity jar wasn't there. I don't
> know whether it actually needs velocity, but it looks that way, so
> I've added that dependency.
>
Maven requires velocity to execute the jar:jar target. I'd always just
assumed that it was pulling it from $HOME/.maven/repository.
> The point is, that velocity is on the CLASSPATH but hasn't been built
> because of the log4j-12 failure. I don't understand why it is there.
>
> Looking at
> <http://brutus.apache.org/gump/public/struts/struts-taglib/details.html>
> I see velocity on the classpath with "Instigator" (something I'll have
> to look up in a dictionary) Anakia.
>
> But struts-taglib doesn't depend on Anakia, so why can Anakia
> contribute anything to struts-taglib?
>
> Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: CLASSPATH logic is failing on me
Posted by Curt Arnold <ca...@apache.org>.
On Mar 15, 2005, at 5:48 AM, Stefan Bodewig wrote:
> Hi,
>
> struts-taglib failed because the velocity jar wasn't there. I don't
> know whether it actually needs velocity, but it looks that way, so
> I've added that dependency.
>
> The point is, that velocity is on the CLASSPATH but hasn't been built
> because of the log4j-12 failure. I don't understand why it is there.
>
> Looking at
> <http://brutus.apache.org/gump/public/struts/struts-taglib/
> details.html>
> I see velocity on the classpath with "Instigator" (something I'll have
> to look up in a dictionary) Anakia.
>
> But struts-taglib doesn't depend on Anakia, so why can Anakia
> contribute anything to struts-taglib?
>
> Stefan
>
My bad. I had wanted to see what would break in avalon-trunk when
using the CVS HEAD of log4j so I dropped the tag modifier from the
logging-log4j-12 descriptor after last nights public run and was going
to reset it before tonight's public run. Unfortunately, log4j CVS HEAD
has dependencies that weren't in the log4j-12 descriptor which caused
it to fail. I had considered adding a avalon-trunk.xml file to
gump/project but apparently it had previously been there but had been
deleted and moved to the avalon SVN archive, so I was resurrect it.
However, I don't see why that should break velocity since that now uses
logging-log4j, not logging-log4j-12. The only things that still use
logging-log4j-12 are the avalon projects.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: CLASSPATH logic is failing on me
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 21 Mar 2005, Adam R. B. Jack <aj...@apache.org> wrote:
>> You recurse for inherit="all" and inherit="runtime", you don't for
>> "no inherit attribute" or inherit="jars". Again, see below.
>
> I was trying to say ... for the project we are building: go get
> it's dependencies (respecting all/runtime), but once "inside" those
> dependencies don't get their sub-dependencies.
That's what I meant as well.
> I don't quite follow, don't for "jars". Why not?
Because it means the project doing inherit="jars" wants to expose the
results of the project but hide the dependency.
> Do you mean 'noclasspath'? I've not see an "no inherit attribute".
I meant absence of any inherit attribute.
>> > I guess I suspected that parts of an API in a sub-jar
>> > (e.g. log4j) might bleed through a user (e.g. say axis) and so to
>> > compile an axis user one might need log4j?
>>
>> It is unlikely to be a compile time dependency. But if it is, then
>> that project (the one that depends on Axis and Log4J) is supposed
>> to say so.
>
> Given what you are telling me, how would it "say so"?
Axis would say <depend project="log4j" runtime="true"/> and the
project that wants to use Axis would say
<depend project="axis" inherit="runtime"/>.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: CLASSPATH logic is failing on me
Posted by "Adam R. B. Jack" <aj...@apache.org>.
Stefan
Thanks for your continued patience and assistance, I really appreciate it.
> > Meaning, do I (except for inherit="jars") not "recurse into the
> > sub-dependency project" to get more dependencies?
>
> You recurse for inherit="all" and inherit="runtime", you don't for "no
> inherit attribute" or inherit="jars". Again, see below.
I was trying to say ... for the project we are building: go get it's
dependencies (respecting all/runtime), but once "inside" those dependencies
don't get their sub-dependencies. (As such, I've stopped recursion for "all"
or "runtime" unless depth=1 ... i.e. the current project).
I don't quite follow, don't for "jars". Why not? "jars" is used (in the
main) as an alias, it seems. As such we seem to want to "pass though" that
project (almost as if it weren't there), so go get sub-dependencies.
Do you mean 'noclasspath'? I've not see an "no inherit attribute".
> > Is it really as simple as for a project one simply includes/resolves
> > merely the explicit dependencies specifies (with inheritence), not
> > going on to get what those projects use to build themselves?
>
> Yes.
>
Cool.
> > I guess I suspected that parts of an API in a sub-jar (e.g. log4j)
> > might bleed through a user (e.g. say axis) and so to compile an axis
> > user one might need log4j?
>
> It is unlikely to be a compile time dependency. But if it is, then
> that project (the one that depends on Axis and Log4J) is supposed to
> say so.
Given what you are telling me, how would it "say so"? What would allow it to
export on of it's dependencies?
> Good idea. Let me again try to capture the dependency logic of
> traditional Gump so that you can compare it to your picture. Nothing
> is set to stone and I'm happy to rework things as needed - but what I
> describe here is the algorithm we used before, and the algorithm I
> apply when I create/modify descriptors.
I do believe it probably ought be changed, (perhaps as you said for the
'overload'.) That said, let's get it right, as best possible, and go from
there.
BTW: Given the way that Gump2 works I don't think it is easy to "take the
jars and break the dependency", and things like that. Dependency and
Classpath are related, but separate things. Gump2 simply walks the
dependency tree and forms a list for the classpath and caches it on the
object. From what I know now, I'd rather calculate things project by project
(at one time) not in some recursive loop. Perhaps Gump3 can do that.
> If you think this is useful and not-obvious from the current docs,
> then I can create an xdoc from it and add it to the site.
I think it is a good re-iteration. Clearly I read far more than there was
between the lines, so perhaps others would also. I've printed it out and
will keep reviewing it until I get the recursion algorithm right.
BTW: I'm hoping I'm close, but w/ such recursion tweaking one never knows if
that is so, or it's just another subtle a change. I'm hoping to compare TEST
to PUBLIC over the next day or few to see what the outcome of the builds
shows. Theoretically TEST could fail w/o it being wrong, just that the
current metadata relies upon the bloated classpath algorithm. I'll keep
watching.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: CLASSPATH logic is failing on me
Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 19 Mar 2005, Adam R. B. Jack <aj...@apache.org> wrote:
> I figured it meant "inherit that into this project", so things that
> depend upon cactus get it & it's inherited baggage. [Actually
> though, that is inherit="jars", isn't it?]
Uhm, no, not quite. We've obviously overloaded inherit too much. See
below.
> Still, have I been overthinking this algorythm all along? Are
> dependencies pretty much simply between the two parties, not (as I'd
> assumed) some cascade of all the dependencies (doing "inheritence"
> the whole tree down to the ground).
It seems so, yes. At least the way dependencies worked in traditional
Gump (which is what I'm coming from with my interpretation) has been
far simpler than you thought.
> Meaning, do I (except for inherit="jars") not "recurse into the
> sub-dependency project" to get more dependencies?
You recurse for inherit="all" and inherit="runtime", you don't for "no
inherit attribute" or inherit="jars". Again, see below.
> Is it really as simple as for a project one simply includes/resolves
> merely the explicit dependencies specifies (with inheritence), not
> going on to get what those projects use to build themselves?
Yes.
> I guess I suspected that parts of an API in a sub-jar (e.g. log4j)
> might bleed through a user (e.g. say axis) and so to compile an axis
> user one might need log4j?
It is unlikely to be a compile time dependency. But if it is, then
that project (the one that depends on Axis and Log4J) is supposed to
say so.
> Ok, I'm going to try to re-work this. I might as well get it right
> here, before I look @ Gump3.
Good idea. Let me again try to capture the dependency logic of
traditional Gump so that you can compare it to your picture. Nothing
is set to stone and I'm happy to rework things as needed - but what I
describe here is the algorithm we used before, and the algorithm I
apply when I create/modify descriptors.
If you think this is useful and not-obvious from the current docs,
then I can create an xdoc from it and add it to the site.
Here we go.
Let's assume
<project name="A">
<jar name="A.jar"/>
</project>
<project name="B-plain">
<depend project="A"/>
<jar name="B-plain.jar"/>
</project>
<project name="B-runtime">
<depend project="A" runtime="true"/>
<jar name="B-runtime.jar"/>
</project>
<project name="B-jars">
<depend project="A" inherit="jars"/>
<jar name="B-jars.jar"/>
</project>
When building any of the B-* projects, A is required. A.jar is on the
CLASSPATH while building any of them.
In the case of B-jars, A.jar is considered part of B-jars' output
jars, hiding the dependency on A completely.
Now let's go one level deeper.
<project name="C">
<depend project="B-plain"/>
</project>
Means no dependency on A at all, A.jar is not on the CLASSPATH. Of
course if A doesn't build, B-plain won't build so C would still end in
a pre-req failed state - but there is no direct dependency at all.
If we change that to read
<project name="C">
<depend project="B-plain" runtime="true"/>
</project>
nothing changes at all. B-plain has no "runtime" dependencies.
And
<project name="C">
<depend project="B-runtime"/>
</project>
doesn't change the picture either, since B-runtime's dependencies are
ignored.
Only with
<project name="C">
<depend project="B-runtime" inherit="runtime"/>
</project>
C gets dependent on A and A.jar becomes part of the CLASSPATH.
You'd use this combination if you want to "run" B-runtime during the
build process of C and B-runtime cannot be run without A. Like Ant's
<junit> task cannot be run without JUnit. Or you can only build your
site with Anakia if velocity, jdom and friends are there.
Then we also have inherit="all". For each of the three B-* projects
<project name="C">
<depend project="B-*" inherit="all"/>
</project>
adds A.jar to the CLASSPATH and it creates a dependency on A directly.
inherit="all" is like importing the dependencies. As a minor variant
we have inherit="hard" which is the same as inherit="all" but turns
<option> into <depend> on its way.
And the we finally have
<project name="C">
<depend project="B-jars"/>
</project>
This time A.jar is on the CLASSPATH when we build C, but C does not
depend on A. If inherit="all" imports the <depend> tags, then
inherit="jars" imports the <jar> tags.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: CLASSPATH logic is failing on me
Posted by "Adam R. B. Jack" <aj...@apache.org>.
> I saw them in a few places (for example many CLASSPATHs seem to
> include bootstrap-ant and ant) but never found the time to complain
> until it finally started to cause problems, sorry.
You know, I was suspicious about that, but never quite registered the
severity of the problem.
> > Ok, so please walk me through this... I see that
> > jakarta-cactus-framework-12 optionally inherits checkstyle for
> > runtime.
>
> Yes, it means "when you build cactus, include checkstyle and all
> projects checkstyle has marked up with runtime="true" in the
> CLASSPATH". It also means "I'm not interested in anything checkstyle
> depends on with runtime="false" (the default) unless I explicitly
> depend on it myself".
I figured it meant "inherit that into this project", so things that depend
upon cactus get it & it's inherited baggage. [Actually though, that is
inherit="jars", isn't it?]
Still, have I been overthinking this algorythm all along? Are dependencies
pretty much simply between the two parties, not (as I'd assumed) some
cascade of all the dependencies (doing "inheritence" the whole tree down to
the ground). Meaning, do I (except for inherit="jars") not "recurse into the
sub-dependency project" to get more dependencies? Is it really as simple as
for a project one simply includes/resolves merely the explicit dependencies
specifies (with inheritence), not going on to get what those projects use to
build themselves?
I guess I suspected that parts of an API in a sub-jar (e.g. log4j) might
bleed through a user (e.g. say axis) and so to compile an axis user one
might need log4j? [I know we strive to keep direct bleed out of APIs, but
I'm just thinking out loud.] How would this be delt with?
> > I see that checkstyle depends upon anakia for runtime.
>
> Yes, it means "when you build checkstyle, include anakia and all
> projects anakia has marked up with runtime="true" in the
> CLASSPATH". It also means "I'm not interested in anything anakia
> depends on with runtime="false" (the default) unless I explicitly
> depend on it myself".
>
> So during the cactus build, Anakia shouldn't be present at all, since
> checkstyle doesn't say runtime="true" here.
>
> > As such, I think I'm seeing that the code is pulling those up/in,
> > and hence a dependency on jakarta-cactus-framework-12 get's the jars
> > that are inherited into it.
>
> They shouldn't be inherited at all. And even if they were, say
> checkstyle had
>
> <depend project="anakia" inherit="runtime" runtime="true"/>
>
> then the jars contributed by anakia should be on the CLASSPATH when
> building cactus, but not when building struts-taglib, because
> struts-taglib says
>
> <depend project="jakarta-cactus-framework-12" />
>
> which means
>
> "when you build struts-taglib, include jakarta-cactus-framework-12 and
> nothing else. I'm not interested in anything
> jakarta-cactus-framework-12 depends on no matter what runtime says
> unless I explicitly depend on it myself".
>
Ok, I'm going to try to re-work this. I might as well get it right here,
before I look @ Gump3. In Gump3 I want to see this aspect be
simple/clean/clear and debugable, and queryable (probably through a
database). I might as well get it right here first.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: CLASSPATH logic is failing on me
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 16 Mar 2005, Adam R. B. Jack <aj...@apache.org> wrote:
> Sadly (since I 'ported' the algorithm from Gump1) I never was 100%
> straight on this stuff. I'd kinda hoped that (after these eons) it
> was well scrutinized by Gumpmeisters, and hence correct. I guess
> fat/bloated CLASSPATHs just are too easy to overlook.
I saw them in a few places (for example many CLASSPATHs seem to
include bootstrap-ant and ant) but never found the time to complain
until it finally started to cause problems, sorry.
> Ok, so please walk me through this... I see that
> jakarta-cactus-framework-12 optionally inherits checkstyle for
> runtime.
Yes, it means "when you build cactus, include checkstyle and all
projects checkstyle has marked up with runtime="true" in the
CLASSPATH". It also means "I'm not interested in anything checkstyle
depends on with runtime="false" (the default) unless I explicitly
depend on it myself".
> I see that checkstyle depends upon anakia for runtime.
Yes, it means "when you build checkstyle, include anakia and all
projects anakia has marked up with runtime="true" in the
CLASSPATH". It also means "I'm not interested in anything anakia
depends on with runtime="false" (the default) unless I explicitly
depend on it myself".
So during the cactus build, Anakia shouldn't be present at all, since
checkstyle doesn't say runtime="true" here.
> As such, I think I'm seeing that the code is pulling those up/in,
> and hence a dependency on jakarta-cactus-framework-12 get's the jars
> that are inherited into it.
They shouldn't be inherited at all. And even if they were, say
checkstyle had
<depend project="anakia" inherit="runtime" runtime="true"/>
then the jars contributed by anakia should be on the CLASSPATH when
building cactus, but not when building struts-taglib, because
struts-taglib says
<depend project="jakarta-cactus-framework-12" />
which means
"when you build struts-taglib, include jakarta-cactus-framework-12 and
nothing else. I'm not interested in anything
jakarta-cactus-framework-12 depends on no matter what runtime says
unless I explicitly depend on it myself".
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: CLASSPATH logic is failing on me
Posted by "Adam R. B. Jack" <aj...@apache.org>.
> >> But struts-taglib doesn't depend on Anakia, so why can Anakia
> >> contribute anything to struts-taglib?
> >
> > I see:
> >
> > struts-taglib -> jakarta-cactus-framework-12 -> checkstyle ->
> > anakia -> jakarta-velocity...
>
> OK, but struts-taglib doesn't inherit anything from
> jakarta-cactus-framework-12 so it should not get any CLASSPATH
> contributions from the projects jakarta-cactus-framework-12 depends
> on. The jars created by jakarta-cactus-framework-12 should be on the
> CLASSPATH, but nothing more than that.
Sadly (since I 'ported' the algorithm from Gump1) I never was 100% straight
on this stuff. I'd kinda hoped that (after these eons) it was well
scrutinized by Gumpmeisters, and hence correct. I guess fat/bloated
CLASSPATHs just are too easy to overlook.
Ok, so please walk me through this... I see that
jakarta-cactus-framework-12 optionally inherits checkstyle for runtime. I
see that checkstyle depends upon anakia for runtime. As such, I think I'm
seeing that the code is pulling those up/in, and hence a dependency on
jakarta-cactus-framework-12 get's the jars that are inherited into it. Can
you pinpoint the problem with this? Is it that since struts-taglib didn't
ask for cactus' runtime it ought not have gotten these?
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: CLASSPATH logic is failing on me
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 15 Mar 2005, Adam R. B. Jack <aj...@apache.org> wrote:
> I chose "Instigator" as in " a person who initiates a course of
> action ", meaning which project caused this classpath entry to be
> added.
Thanks.
>> But struts-taglib doesn't depend on Anakia, so why can Anakia
>> contribute anything to struts-taglib?
>
> I see:
>
> struts-taglib -> jakarta-cactus-framework-12 -> checkstyle ->
> anakia -> jakarta-velocity...
OK, but struts-taglib doesn't inherit anything from
jakarta-cactus-framework-12 so it should not get any CLASSPATH
contributions from the projects jakarta-cactus-framework-12 depends
on. The jars created by jakarta-cactus-framework-12 should be on the
CLASSPATH, but nothing more than that.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: CLASSPATH logic is failing on me
Posted by "Adam R. B. Jack" <aj...@apache.org>.
> Looking at
> <http://brutus.apache.org/gump/public/struts/struts-taglib/details.html>
> I see velocity on the classpath with "Instigator" (something I'll have
> to look up in a dictionary) Anakia.
I chose "Instigator" as in " a person who initiates a course of action ",
meaning which project caused this classpath entry to be added. The
"Contributor" is the project that actually added the CLASSPATH entry, but
the Instigator was intended to help us track down the original cause. In
effect all it does it track one step back, so theoretically one could walk
back along instigators to the original project who's classpath is beign
constructed.
[BTW: I once added tables that were "paths" from classpath part A to B, with
reasons, but I blew Python's mind w/ objects & had to pull it. This'd be a
cool feature for adding to a dynamic interface.]
> But struts-taglib doesn't depend on Anakia, so why can Anakia
> contribute anything to struts-taglib?
Looking
Contributor Instigator
jakarta-cactus-framework-12 struts-taglib
checkstyle jakarta-cactus-framework-12 checkstyle
jakarta-regexp checkstyle
bcel checkstyle
commons-cli checkstyle
commons-collections checkstyle
jdom anakia
jakarta-velocity anakia
jakarta-velocity anakia
avalon-logkit anakia
I see:
struts-taglib -> jakarta-cactus-framework-12 -> checkstyle -> anakia ->
jakarta-velocity...
I hope that helps. Let me know if you see bugs in this logic (I'm too full
of head cold right now to think too much.)
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org