On 13/10/2010 2:52 PM, Leon Rosenberg wrote:
On Wed, Oct 13, 2010 at 5:31 AM, Brian Topping<[email protected]> wrote:
On Oct 12, 2010, at 10:01 PM, Martin Gainty wrote:
Suprisingly maven is not the first programming language to use XML
This is worth clarifying. What makes Maven unique, and I believe
groundbreaking, is that the POM is declarative, not procedural. It is not a
programming language in the traditional sense. There are many examples of
procedural languages written in XML, and many agree they are painful to use.
That's why the one that was used in Maven 1.x is notably absent from Maven 2.x
Many traditional programming languages are declarative and not
procedural or are based on declarative concepts, most of the time the
declarative nature of such languages proved itself problematic.
But seriously is there a comparison matrix somewhere which compares
ant+ivy vs maven? As an ant+ivy user I have recently tried out maven
(yes, i hand-wrote poms for about 15 projects) which mostly depend on
each other, I got them all published in nexus etc. I must say that I'm
pretty shaken how unreliable maven build are.
With ant it either works or not. If it works, it works everywhere, in
console, in eclipse in hudson. With maven, I got plenty of builds that
run in console but not in eclipse, or in eclipse but not in hudson, or
in hudson but not in console. Besides that I haven't found anything in
maven that isn't present in ant somehow, except for parent-poms, but
they got added to the recent ivy release so they don't count anymore
;-)
I find it pretty hard to maintain versions with maven. Do I have to
make them all depend on RELEASE version of each other? Distinct
versions of each other? SNAPSHOTS? I started with snapshot, but I
couldn't publish a second version without republishing everything, so
I consider this bad idea...
regards
Leon
P.S. Is there a documentation somewhere which really describes which
lifecycle phase is meant for what?
Maven is really missing a best practice section.
You can do almost anything with Maven but most of those things are
really bad ways to go about developing.
If you read the workflows that people are trying to shoehorn into Maven,
you would think that there are no standard platforms for running
applications and each company writes their own web server.
I can not believe that there are so many different ways to deploy java
applications.
.
Once you get used to the paradigm shift and get used to it, it becomes
remarkably easy to look at any build and find what it is doing. While many
systems (like Ivy) have started using Maven's central repository, if they use
procedural descriptions of a build, they are missing the vision that Maven has.
Personally, I find it frustrating to have to dissect an Ant build to figure out
what's going on. A Maven build is validated against a schema, and finding what
I am looking for is predictable and quick. It's also fast to write, since most
IDEs can do type-completion with a schema declaration, and many have been
augmented to read plugin.xml files inside plugins to do type completion of
plugin configuration as well.
Lastly, having a validated structure for the build allows IDEs to import the
POM directly, and because the Plugin interface is so simple, it's easy for IDEs
to integrate against plugins. In my experience, this level of integration is
unique to Maven.
Hope you stick with it. Maven will really grow on you, as it has with a huge
number of folks over the last few years.
Brian
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
