On Tue, 2005-09-20 at 14:19 +0100, Ashley Williams wrote:
1. Usability from Ant - there are hundreds of Ant targets out there
that are useful for me today. I can't justify waiting for them to be
rewritten as Maven equivalents not only because I need functionality
today, but also because I don't see why I have to abandon my
experience with ant.
We are rapidly trying to make Ant functionality available in m2 by
creating a plugin type that allows you to script up plugins using
Ant's
familiar XML scripting. If you can't wait and have a pending project
then your stance is understandable.
For the time being you can take advantage of what we've made available
via Ant tasks.
2. Usability from Eclipse - when will I be able to ditch the command
line and create and manage projects entirely from eclipse
This is something that is actively being pursued and something will
materialize sooner rather then later. We understand the critical
nature
of tool integration. The importance is not lost on us, we understand.
3. Need to do a myriad of simple things such as automatically run
java command or deploy to tomcat. I used to do this all the time in
my ant scripts, ie run my build.xml script and at the end it would
run my app on completion. It's a credit to those on this list who
reply with ideas and workarounds - however this is kind of related to
2 above, where there are lots of ant tasks out there that are tested
to death and that I should be able to use today.
Here our aims are different. We don't want everyone scripting up
everything in their own way. It may be convenient in the short term
but
we would prefer to wait for someone to create a coherent,
consistent way
to launch an appserver for testing so that it benefits all Maven
users.
We feel in the long run this approach serves the community better but
this notion is often at odds with folks who needs to get things done
Right Now(tm).
4. Online documentation. Simple example was trying to get the
assembly plugin to work which Daniel Shomer had to look into the
source code to advise me of what to do. This is just one example of
many.
The documentation is admittedly lacking. I am actually working pretty
much full-time on writing doco for the release so this is not lost
on us
either. We know that documentation is critical for successful
widespread
adoption.
5. Other project structures. Sometimes I will encounter a project
where all the source code is in one tree (beginning with com/). I'm
not saying its any better than one directory per artifact, but I am
saying I encounter such projects in my career and as such I know I
wouldn't be able to use maven.
That's a choice you'll have to make. Many people have found making the
switch to our default ways of doing things has numerous benefits. If
it's not something you can do then we understand but we feel
coherency,
consistency, and comprehension win out over other concerns. Make a
good
plugin and all Maven users benefit. Make a one off script for your own
setup and you've just isolated yourself from a great source of
potential
help. Making a decent plugin might take you an extra 20% in time
but the
ultimate savings in time has shown itself in our community over and
over
again.
We also know that new projects are starting all the time and this
is the
ideal time to try Maven. For people who have different structures, you
will probably also find that their build now works and in these
cases I
would never recommend switching from Make or Ant unless you are having
serious problems with maintenance.
6. Contribute to the code. I have tried to get a foot in the door in
order to fix some of my own critisisms, but the lack of javadocs mean
that I really can't do this other than for some simple plugins. That
is unless I had lots of time to spare which I don't. In turn that
makes me concerned how the project will attract other developers to
move things along quickly.
We have actually attracted more developers in the last 6 months then
ever before. We've got 4-5 new developers on the maven project and at
least as many on the Mojo project. So things are actually looking
great
in terms of community involvement and I think it's only going to
grow as
we approach a final release. There is currently a barrier to entry but
we've managed to overcome that and we're working on making getting
involved easier:
http://maven.apache.org/maven2/developers/development-guide.html
I realize there may be workarounds for some of the above, but I
couldn't stick my neck on the line for a dev team and recommend
sharing of eclipse hack scripts etc as a way of working. I'm also
putting my selfish hat on and say that I'd like to do the above
without defending it - there are a few threads on this list already
that deal with the pros and cons.
***************************************
Now I'll turn my attention to Ivy. I've began to look at this product
and it seems to offer many of the features of Maven including
1. transitive dependencies
2. compatibility with the ibiblio repository
But this is a mere fraction of what Maven tries to accomplish. I don't
think you can really compare the two. Ivy provides a very small subset
of Maven's capabilities.
and in addition
1. the online docs are excellent even if they are in broken english
Docs are docs, it's true. But we'll be in better shape for the final
release.
2. Can manage projects from with eclipse, since they are just ant
projects (with simple projects, haven't tried anything tricky)
3. Can manage maven style module directory structures or single
source trees. Obviously being Ant, it can manage any structure you
like, but these are the only two sane ones I know.
Eclipse support is coming, I promise :-)
As far as allowing any structure, that's just not what Maven is about.
We don't encourage that and never will. We just feel in the long
run the
build is not what developers should be focusing on. The build should
apply standard patterns much like all other aspects of software
development and the focus should be on enriching your application.
That's where the value lies.
Anyone who uses Maven can talk to anyone else who uses Maven and
understand much of what the other is talking about because we
employ and
encourage these best practices. If you have an entirely isolated setup
your chances of getting help are limited and you will remain isolated.
We try to carry the whole notion of patterns into the build
infrastructure so people save their valuable time by being able to
communicate effectively about specifics of a build.
Yes there is stuff that it doesn't have such as a built in lifecycle,
but with what I've learnt from the maven layout, I feel I could quite
easily replicate that in ant in a reusable way.
We know from painful experience that is not the case. I know of many
attempts to replicate what Maven does in many organizations and
very few
of them still live on today. A great deal of consideration went into
m2's lifecycle and I sincerely doubt it could be easily replicated.
That said I would
prefer not to have to. I suppose I'm looking for reassurance as to
why Maven is the way to go because there seems to be considerable
overlap with Ivy.
Maven and Ivy are not really comparable. Apples and Oranges. Ivy
simply
does dependency management and nothing else.
****************************************
I realize that I am being very selfish here, but I have to think very
carefully about what I invest my time in. Maven has all the hallmarks
of being that software that I felt was missing during my career,
which is why I care enough about it to spare the time for these
critisisms. I just want to be sure it has a chance of gaining
critical mass.
Everyone's time is important and deciding what to spend your time
on is
critical. We know that Maven has some shortcomings (just look at our
JIRA!) but issues are being fixed at a breakneck pace. We think that
with the release of 2.0 we're going to have something pretty good.
Maybe the gatekeeper/guardian of this project needs to write some
sort of Jerry Maguire style memo that says what Maven's purpose is
and plans are so that we can all keep focused on that.
What kind of demo do you suggest? I've never seen Jerry Maguire :-)
Maybe my views aren't representative of a large enough demographic in
which case this email will just slip away into obscurity, but either
way thanks for reading and please don't take it as a troll
Lots of folks have talked about the things you're talking about here.
Everyone once in a while I respond just to refresh in my own mind why
the project was started. It takes a while to get accustom to the way
Maven works and what its goals are. In a nutshell Maven is an
attempt to
apply patterns to a build infrastructure in order to make things
easier
for everyone involved in Java (more languages later) software
development.
-AW
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
