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: Mon, 15 Jun 2009 20:36:25 -0700
On Jun 15, 2009, at 6:55 PM, Lachlan Deck wrote:
On 16/06/2009, at 11:30 AM, Michael Schrag wrote:
Maven == Ant cubed. Or maybe Obsfucated Ant. :-P
Chuck, are you speaking from experience here or just shootin' the
breeze? David, do you know how much 'set-up' is required to use
maven with Hudson?
All this toying around with environments etc sounds tiring. :-)
I've had the pleasure of using Maven some now and you're not really
giving the full story here
Well I wasn't attempting to give the full story - only what's
related to building under hudson (which I believe this topic was
about). Sure there's a couple of other steps involved in setting up
maven overall but I think it misleading (though I know Chuck's
mostly joking
No, not joking for what I thought the topic was, "difficulty in
debugging build problems in Ant vs Maven".
... but others believe him word-for-word) to keep suggesting that by
using maven you're problems would be exponentially more difficult.
Then again - Chuck was probably 'goating' a response :-)
Ouch!
In my experience with maven, setting up a new machine is relatively
painless because all of the configuration is self contained. That is
the point I was attempting to make.
I agree that is is very good for dependancy management when
(a) the dependancy still exists in the repository
(b) the repository still exists
(c) there are no build problems
Sometimes this is the case, particularly when you control all the
repositories. It certainly has NOT been the case for all the
Mavenized projects that I have tried to build, especially over a few
years. People "clean up" repositories. Shit breaks.
Chuck
... So far, any time something has gone wrong in Maven, it's been a
completely nasty pain to diagnose. At least with ant, it's stupid
simple for better or worse.
Naturally I can't comment on theoretical problems. Not saying you
didn't have problems - but having no idea what they were and whether
it was user misunderstanding or a maven limitation (depending on the
approach) it's not worth speculating. I'm not wanting to start off
another thread either.
Mind you, I'm not an ant fan either -- I have the exact same hatred
that Chuck has, but it's really misleading to suggest that Maven
will just magically fix all your build problems. It makes a class
of problems easier, but it brings along a bunch of its own new ones
as well.
I think that really depends on how complex your problem is .. i.e.,
custom things. There certainly is a learning curve with maven - no
doubt about it.
Anyway - sure there's challenges with whatever you use. I'm simply
responding to the mantra that for this particular situation (or even
in general) it would be even worse with maven. In this regard I
strongly beg to differ.
<notDirectlyMavensFaultIDontThinkButRelatedPain>On top of the core
Maven complexity, I can't even leave the maven plugins installed in
eclipse because it pretty well destroys my WOLips plugin
development environment by (as far as I can tell) fiddling with my
project classpaths incorrectly. I'm wondering if maybe because
there's a pom up higher in the wolips checkout (even though I
import subprojects that don't have poms) that it's screwing with
maven into trying to do things that it shouldn't, but i really have
no idea.
If you're talking now about WOLips plugins development alone I did
notice that more recently the woenvironment etc seem to be using
maven for the .classpath files. I don't know when/who but that'd be
your issue. It took me a few goes to clean the whole project import
tree before it all compiled properly. I assumed it was all working
for you seeing as this is the first I've heard of the problem .. and
I failed to mention it.
i just know that when the maven plugins aren't installed things
always work and when they are, seemingly randomly all my plugin
projects break.</notDirectlyMavensFaultIDontThinkButRelatedPain>
(That particular question is quite a different topic .. which should
be on the woproject list if anything)
When it comes down to it, SOMEONE has to do the heavy lifting both
in Maven and in Ant. In Maven, you guys have done a bunch of work
on the custom archetype stuff, and in ant we've done a bunch of
work on the custom build.xml that the WOLips project uses. I use
completely stock ant build files from WOLips and it takes me
literally about a minute to setup a new project in Hudson that
builds along with its dependencies -- I really don't feel any pain
with this.
Great.
Dave is obviously something a little different than most here, and
I suspect there are edge cases in both the Maven tooling as well as
the stock build.xml's. If what you're doing is outside of what the
author of your build tools intended, you're going to have a bad
day, no matter what you're using.
Sure.
with regards,
--
Lachlan Deck
_______________________________________________
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
--
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