Re: Hudson and Client-Side Classes
Re: Hudson and Client-Side Classes
- Subject: Re: Hudson and Client-Side Classes
- From: Chuck Hill <email@hidden>
- Date: Tue, 16 Jun 2009 12:36:05 -0700
On Jun 16, 2009, at 3:58 AM, David Avendasora wrote:
On Jun 15, 2009, at 11:28 PM, Chuck Hill wrote:
On Jun 15, 2009, at 5:47 PM, David Avendasora wrote:
On Jun 15, 2009, at 8:37 PM, Chuck Hill wrote:
On Jun 15, 2009, at 5:19 PM, David Avendasora wrote:
On Jun 15, 2009, at 6:28 PM, Chuck Hill wrote:
Maybe. Which task is this for? What does your build.xml say
for this task?
build.woapp.
And lookie there:
<lib dir="Libraries">
<include name="*.jar" />
</lib>
I checked, and this little gem is in the build.xml file of all
the App and Framework project templates.
The new ones? I wonder if that is a left over from pre-New
Hotness.
Yep. Nightly as of a couple nights ago.
Hold on now. That is in the woapplication task? That is just
copying jars into the Contents/Resources/Java directory IIRC. That
is not putting them on the classpath, just assembling the bundle.
Okay, you are right.
Yes, I know. :-P
That isn't what is putting the contents of the Library directory on
the classpath.
This is (or should I say "Is this?"):
<classpath>
<fileset dir="Libraries">
<include name="*.jar" />
</fileset>
<fileset dir="${wo.extensions}">
<include name="*.jar" />
</fileset>
</classpath>
Which is from the compile target, nested inside a wocompile element.
Yes, that is doing it.
I'm guessing there's a reason that it just loads everything in
Libraries, but it's counterintuitive when the incremental
builder doesn't do that. Not as far as I can tell, anyway.
I am leaning more towards cruft that never bit anyone before.
I just love being the guy that this kind of stuff bites. Maybe I'm
just willing to look like an idiot and ask... :-)
You do it really, really well. ;-)
Seriously. I figure I'm a bigger idiot if I sit here for hours on
end beating my head against the wall trying to figure it out for
myself when someone in the community has the answer. First I search
my email history (I have 3 years of the WO Lists on my computer),
then I Google it and if I still can't find the answer, I ask the
list. Why wait? My ego's not so fragile.
I can't tell you how many people I talked to this year at WOWODC who
I never see on the list that told me "I've been doing WO for a few
years now and I feel like I should just know it, so I feel like an
idiot to ask simple questions on the list."
That is a silly attitude. Don't ask and you won't learn.
I figure my legacy will be that I was the guy that almost single-
handedly asked every stupid WO question (obscure or obvious) so
they'd be in google for future generations.
Only they won't Google. :-(
The same should hold true for /Library/WebObjects/Extensions/
if people shouldn't be putting stuff in there, and it seems to
cause a lot of confusion, why go and automatically load
everything in there?
For compatibility with how the runtime works. Just because
people say that you should not be putting things in there, does
not mean that other people will listen.
Can we at least make Ant write "You moron! There's stuff in the
WebObjects/Extensions directory. Get rid of it." into the
console if the directory isn't empty? It would have only mildly
hurt my feelings yesterday, but would have saved me a few hours
time.
We could, but that would entail messing about in the WOProject
code. That ranks somewhere around "double root canal" in terms
of fun.
Yeah, it was kind of a rhetorical question....
Probably a good suggestion for Jira, but not at the top of my list
of Stinky Things to Attend To. Few of which I have ever started...
Second, I added an external .jar file to my project, it shows
up in the .classpath file in the project, but Ant is _not_
loading that one. Why?
How did you add it? What does it look like in the .classpath
file?
In the Build Path properties window I clicked the "Add External
JARs" button and selected it. It is the client-side jar of
EODistribution (Since WOLips doesn't automatically add the
client-side jars to the classpath when you add a framework to
the build path).
<classpathentry kind="lib" path="/Developer/WebObjects/bestmaid/
System/Library/Frameworks/JavaEODistribution.framework/Versions/
A/WebServerResources/Java/JavaEODistribution.jar"/>
That sounds like a Mike question. The FQ path looks scary in the
classpath, but I would have thought that New Hotness would have
put these on the classpath. Is it perhaps just not _scanning_
for it as there is a FQ path?
Well, this is an "External JAR" so it would have to be fully
qualified,
Right. The "Variable" functionality is probably a better choice
for this sort of thing.
This another case of 8 different ways to do something in Eclipse and
the most obvious way is most often wrong.
I changed it to a variable and now it says:
<classpathentry kind="var" path="NEXT_SYSTEM_ROOT/Library/
Frameworks/JavaEODistribution.framework/WebServerResources/Java/
JavaEODistribution.jar"/>
But that isn't picked up either.
I was not suggesting that would work, just that it was less fragile to
machine differences.
The debug log shows the classpath as (you can search if you want,
but it's not in there):
[wocom
My eyes!
but it appears that anything in the .classpath file that is a
type="lib" get's ignored. Which may be why the build.xml file goes
and grabs everything out of the Libraries directory.
I suspect that you are mixing Apples and Octopus Hair here, but I
am only guessing. Hopefully Mike will see this and comment on New
Hotness and type="lib".
Maybe. (Two great tastes that taste great together, don't cha know)
but the type="var" isn't getting picked up either. Do you use that?
No. I notice that Mike is studiously ignoring this thread. Perhaps
he does not use lib stuff and never noticed this?
Chuck
--
Chuck Hill Senior Consultant / VP Development
Come to WOWODC'09 in San Fran this June!
http://www.wocommunity.org/wowodc09/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden