Re: maven.
Re: maven.
- Subject: Re: maven.
- From: Mike Schrag <email@hidden>
- Date: Fri, 3 Apr 2009 22:27:31 -0400
No, I remember quite clearly why I wrote it, and that's because I
wanted the users of WOLips to have a very simple experience out-of-
the-box, and Maven does NOT provide that.
What problems do you see? Could we improve the tool to better fit
your needs? Which specific problems are you facing?
I'm sure you can improve it. Mostly my problem is that I have to know
about it at all. To me, the best build system is the one that I never
see, and if I have to see, I want it to be relatively easy to tweak
(<= I hate ant, too, btw, it's just the most accessible and nicely
integrated tool for Eclipse at the moment).
I can't say "oh you want to build and test your app -- sure learn
maven -- here's the name of the book to start."
But couldn't you say: "Do you want to improve the entire development
lifecycle of your projects? Do you want to improve the way you
MANAGE your projects? Here is a tool and the name of a book to
start. And you don't have to read the entire book to recognize the
benefits".
Sure ... I could say that. Oooorrrrr I could say "Click Run As... Ant
Build and your app will work." Which do you think a normal user would
want me to say? I know which one _I_ would want me to say (not to
mention I'm not at all sold on that aspect of Maven myself).
My goal with WOLips is to make it very easy for people to get a
WebObjects application started, developed, built, and deployed.
Period. If Maven can deliver a better experience for the users of
WOLips than the stock ant system, that's great, but I haven't seen it
yet. I want to decrease the complexity of people's lives, not
increase it. At the moment, i recognize that we do not have a good
answer for inter-project build dependencies. Obviously Maven is a
possible solution to this problem, but it has an annoying (to me, and
I know also to many others) learning curve. My question is whether I
can deliver a solution that removes the curve. If that's making Maven
suck less for people to get started with, whatever, I'm fine with
that. If it's using one of the existing ant tasks, that's cool. If
it's writing something that does it, I don't really care ... I want it
to be nice and I want it to be simple. I have a relatively narrow
problem definition. If other people have a grander problem definition,
that's cool -- use Maven if that works.
I want people to launch WOLips and things just work.
So you want something that works only for WebObjects projects? For
me this a huge drawback, for example.
Given that I work mostly on WebObjects projects, I want something that
works GREAT for WebObjects. If it works ONLY on WebObjects projects,
that is entirely secondary to me. I honestly don't care. If you or
others feel otherwise, by all means use whatever you want. I don't
want a tool that makes a whole bunch of things kind of better, I want
a tool that makes _precisely what I do AWESOME_. I don't claim to have
achieved this, mind you, but that's why I work on what I work on.
Take the component editor in WOLips as an example here. I evaluated 5
different XML/HTML editing environments for Eclipse and they all were
terrible. Do you use Web Tools Project plugins to edit your HTML? If
you bring on other developers, they'll probably know that set of
plugins better -- it's the "standard" for editing HTML and XML in
Eclipse. I'm ASSUMING you don't, that you probably prefer to use the
one that is in WOLips because it's nicely integrated with the other
parts of the tool. It's not that I just like replacing things, it's
that I want things to not suck. And sure, my stuff sucks, too, but
mostly not in ways that I care about :)
I understand you see a problem on WOLips+Ant implementation, right?
You want to improve it, but you think it is to much to ask people to
add a set of tools just to have more control over their environment,
correct?
Yes?
I hate (*HATE*) build systems. They all suck. I don't want to
think about a build system. I want it to just work. If you want
something fancy, learn Maven and go crazy. If you want to instead
agree to our requirements, then you do nothing and WOLips "just
works."
Would you mind being more specific? Your proposal is very similar to
the concepts behind Maven. If you agree with some requirements,
Maven just works and does everything for you. The only difference is
that your solution will work only for WebObjects projects.
BTW, Maven have a few commands to solve most of your problems. Those
commands are the same for every project in the world that uses
Maven. Most configuration you have to do in a project after its
creation is to add/remove dependencies. And you don't have to
manipulate XML with the new POM editor from m2eclipse. Where is all
the complexity? Does the number of tools required to make all the
environment ready make you crazy?
I agree this is how things SHOULD work, but the times I've used Maven
it has NEVER been like this. It's always "something's not right in
your settings.xml" "oh you need to manually put that in your .m2
folder" "what in the world does this error even MEAN". Maybe these are
just poorly implemented maven projects, I have no idea, but I have yet
to see this nirvana that apparently exists. I also know I'm not alone
in this -- Maven is pretty notorious for having accusations of
complexity leveled at it, and not just in the WO world.
As I understand it, even when you use the Maven plugins and build
system, to launch your app you still have to use our incremental
builders if you want hot code replacement?
Yes. Is this a problem?
Just pointing out that you're not just dealing with Maven and it takes
care of everything for you, you're dealing with TWO build systems that
are very different. I don't doubt at all that this can be made better
and better integrated, but it's just another tick mark in the
complexity column.
ms
_______________________________________________
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
References: | |
| >maven. (From: Mike Schrag <email@hidden>) |
| >Re: maven. (From: Henrique Prange <email@hidden>) |
| >Re: maven. (From: Mike Schrag <email@hidden>) |
| >Re: maven. (From: Lachlan Deck <email@hidden>) |
| >Re: maven. (From: Mike Schrag <email@hidden>) |
| >Re: maven. (From: Henrique Prange <email@hidden>) |