On 20 Sep 2005, at 16:15, John Casey wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Comments are inline. Please bear with me, I think my responses are as
lengthy as your original email! :(
Cheers,
John
Ashley Williams wrote:
| Sincere apologies to the dev team if this email seems like a
troll, I
| absolutely don't mean it to be. I'm aware that they continue to do
| outstanding work and are few in number.
|
| The more I use Maven the more I get a feel for the size and shape
of it
| and find myself looking for features that aren't there. Since I
joined
| the community I've posted questions on what I consider to be the
most
| important aspects of a build system namely (yes in this order):
|
| 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.
I've already addressed this with you and others on this list. I've
mentioned that I'm fully in favor of this sort of integration, and I
have some starting points from Chris that I'll be putting in to allow
this sort of thing. You don't have to wait for all of Ant's API to be
replicated; you only have to wait for me to get this one change in
place. :)
I'm extremely pleased to hear this. I meet all sorts on this list and
I don't know
which contributors are most responsible for steering the project or
are just
giving there opinion on what they would like to happen. Maybe the
roadmap could be maintained a little to show which suggestions have
actually
been taken on board.
|
| 2. Usability from Eclipse - when will I be able to ditch the command
| line and create and manage projects entirely from eclipse
This depends on people with Eclipse development experience (not
experience using Eclipse) picking up the task and running with it.
We're
trying to get something together in the way of a more concerted
effort,
but I'm sure you'll agree that getting a stable API was the first
thing
to do, since otherwise the Eclipse integration project would have to
track a moving target. Now that we've got a beta-1 release, we can
start
thinking about this.
|
| 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.
The funny thing about Maven 2 is that it facilitates external plugin
development. You can load a plugin from a repository hosted anywhere.
Personally, I feel strongly that executing random commands from within
the build process is a Bad Thing,
I can already do that with a mojo - I can write any old java and
attach it
to any old lifecycle phase. BUT I would love to get up to that same
mischief
using the language/syntax of Ant rather than Java!
and a thing that is bad and common
with Ant. Maven - and also Ant, to a lesser extent - is a build tool.
It's not a launching platform, and it's not a tool to be used to run
your coffee maker. Executing random commands from a configuration in a
POM is:
a. unscaleable, since that runtime config is not encapsulated for
reuse
b. bound to partition your build logic into multiple pieces, which now
have to be maintained from multiple sources.
In Ant, you can do anything you please, including things that don't
relate to the process of building software. It's important to keep a
clear idea of the problem domain we're trying to address here.
Having said that, there's nothing stopping you from hosting your own
maven-foo-plugin on Sourceforge or somesuch. If you find what you
perceive to be a hole in our plugin offering, and cannot convince
us to
fill it, there's nothing stopping you from scratching your own
itch. We
currently have maven-execute-plugin on the mojos project, but I'd
really
like to see it deprecated and eliminated eventually.
|
| 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.
You're not the first to point this out, and properly so. Just this
week,
one of the devs started fulltime on fixing this. Documentation has
lagged for a few reasons, which I don't offer as excuses. First, the
devs have been trying to stabilize the featureset and functionality
before we try to document it. This is sort of a chicken-egg scenario,
because (as was pointed out) its easier to maintain a clear design
between multiple devs when you have documentation, but
documentation of
an evolving API gets stale quickly.
Now that you've read the source code for the assembly plugin, will you
contribute some documentation?
|
| 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.
This project can get a little preachy, and I'm no exception. We
tend to
believe that we've seen a lot of use cases (many on this list), and
that
our standard layout is the most elegant solution THAT WE'VE FOUND SO
FAR. I emphasize that, because it's important to acknowledge that
today's gospel is tomorrow's quaint idea. We're focusing on providing
support for that standard layout/model right now, but we will be
adding
support for other project layouts when we learn of deficiencies.
What we
most need is use cases. If you have a specific one, can you share it?
Where, specifically, are you having trouble with meshing your
layout and
the POM?
I'm only suggesting one other layout - everything under com/... and only
because it's a 'code layout design pattern' I come across often.
Compared
to my other points, this one isn't important for me. I do like the
fact that
Maven gets preachy because it means that I know what to expect from
project to project. However I still feel entitled to point out where
I feel Maven
could be a little more generous!
|
| 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.
I addressed this a little bit above, but I believe Maven 2 is still
climbing that maturity curve. We're climbing fast, but there are bound
to be places that need attention. Javadocs may help, but an
architectural overview and set of mini HOW-TOs may go a lot further.
There are very few methods in the code that aren't self-
explanatory, at
least at a high level.
However, I still agree that javadocs would be a
good thing. Unfortunately, as you've so eloquently pointed out,
there is
a long line of Good Things waiting for attention
At the very least couldn't we javadoc the mojo properties so that the
plugins
on the maven website have actual descriptions? I'm guessing you eat your
own dogfood and autogen your webpages from the mojo code.
...this is where we have
to prioritize, and choose which ones we will attend to first. We've
chosen code/feature stability, and API stability heretofore, but we're
starting to focus on POM usability, additional plugin languages, and
documentation now that we're in bugfix mode.
If you've spent any time in the sources, and found that you understood
even a small portion when you were done, would you be willing to write
some of these javadocs and submit a patch? Every contribution, however
small, will push us closer to the level of maturity you desire.
See my comment later. But personally I would never javadoc somebody
elses
code unless I was getting paid a lot of money for it. Seriously the
most likely
way for code to get javadoced is for the coder to do it themselves,
in my opinion.
Take from that the unfortunate corollary.
|
| 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
If I understand correctly, Ivy depends on profile name consistency for
transitivity to function properly...
| 2. compatibility with the ibiblio repository
Maven 2 has this compat as well, and can probably supply the same
level
of functionality as Ivy given the quality of metadata in the m1
repository. You can specify a repository with <layout>legacy</layout>
and it should work. But we're hoping for much more than this.
|
| and in addition
|
| 1. the online docs are excellent even if they are in broken english
Ivy is an overlay for Ant, meant only to provide transitive dependency
resolution and compat with the m1 repository. This means it's a
relatively small project, and therefore have the ability to climb that
maturity curve faster.
As a side note, Ant 1.7 will be using Maven 2.0's artifact-handling
API.
This, after Ivy has been out there available for integration for some
time now. Why is that, do you think?
| 2. Can manage projects from with eclipse, since they are just ant
| projects (with simple projects, haven't tried anything tricky)
What level of integration do you need here? Would it be feasible, for
example, to create a set of command-line execution profiles in
Eclipse,
to call various m2 targets? I've done this successfully with svn,
when I
found subclipse to be far too sluggish and flaky.
| 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.
If I understand correctly, the m2 eclipse plugin does have some
support
for this, although I'm not the best person to speak about it. To some
extent, solutions to this will be compromised by Eclipse's lack of
nested project support...which in some cases can lead to set-semantics
when collecting dependencies for a hierarchy of projects...which
can in
turn lead to sources compiling in Eclipse but not in Maven, since the
dependency declarations are not the same. The eclipse integration has
been escalated as a priority recently, but we're not likelly to have
anything for at least a few weeks. We understand the market share that
Eclipse commands, and its value for integration...unfortunately, we
haven't had the time to devote to external m2 integations up to now.
|
| 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. 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.
'Considerable' is a tad exaggerated, IMHO. Maven gives you
reusability,
not only of plugin functionality, but also of project information (the
POM specifies most of what plugins need, so project configuration
scales
better than Ant for the marginal plugin). It also provides a single,
simple lifecycle that ensures a sane progression from task to task in
order. This lifecycle is the same for everything you will build, since
plugins bind to the lifecycle behind the scenes.
If you attempted to build a lifecycle on top of Ant, I think you'd
find
~ a couple of things to be true:
1. it's not as simple as it seems, particularly if you build multiple
types of projects (EJB, EAR, WAR, JAR, DLL, RPM, ...)
2. unless you attempt to open source your own solution - which
means it
will have to have general applicability, which itself is not a trivial
goal - you will have to maintain your lifecycle layer in addition to
your actual build scripts. Tracking something like this against
updates
in Ant and Ivy is not trivial...I tried something similar before Maven
came along. The problem is that maintaining this lifecycle layer will
not directly impact your company's bottom line, so they will be
reluctant to give you much slack time to maintain it.
It would be great to see this sort of information on the Maven
Website - I'm guessing
there are others who are looking at both Ivy and Maven. Go to the Ivy
website
and the guys there are favorably comparing their product with Maven.
|
| ****************************************
|
| 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.
|
| 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.
|
| 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
I appreciate you taking the time to articulate your concerns. There is
no doubt in my mind that many of the points you raise will resound
with
users, both current and potential. However, I have a question for you:
How long did you spend on this email?
It's fairly involved, and judging by the time I've spent
responding, it
took some effort. Did you do this in the course of your workday? If
so,
can you afford this amount of time a couple times a week? I'd like to
encourage you to spend this amount of time exploring our APIs, writing
javadocs (or whatever doco, etc. you see fit) and submitting patches.
This much effort from a few users like you would really make a
difference fast, IMO.
Just something to think about. Even small patches will eventually
add up.
You've guessed that I've got time on my hands! However only because
I'm between contracts
and so I'm spending some time looking at those projects that have always
interested me, maven being top of the list (but there are others).
Outside of office hours my commitments
mean that I have little time to make meaningful contributions to
opensource projects.
I did try to make an exception for Maven, but I haven't been able to
get up to
speed with the Maven code base quickly enough, which was one of my
gripes.
- -john
|
| -AW
|
|
---------------------------------------------------------------------
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMCeJK3h2CZwO/4URAhfPAKCD1iOtdPe2NO0j8KY6vg0L7oUW4ACgnZpk
7bbtGsKkiZKm8o/wOqY4Sjo=
=JcXf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
