From: "Geir Magnusson Jr." <geirm@adeptra.com>
I'm in a 30 person company with a development team of 5 and we have a
separate dev environment, qa environment and of course production
environments. By separate I mean really, really separate - separate
firewalls, separate DMZ's, separate secure areas. Can't get from one
to another.
Well different companies will do it differently. Maybe I should be clear - I
want dist:deploy to deploy to other developers in the company, not an
external website. At present dist:deploy only supports ssh, and thats just
no use to me.

At present I have stopped working on using Maven. If it takes 3 days with
Maven to not achieve what you want, then is it worth it? At some point
everybody gives up. I know ant will give me less. But it will work.

(Apologies for this being a more negative email, but you must hear the
negative side too)

So, where are the failings?
1) No network shared repository
Maven proxy seems very useful, but I don't have the ability to run a server
process in my environment. The remote repositories list doesn't support a
file location in its list either

What I need is for core Maven to support the notion of a shared mid-level
repository without a server process. Ideally this should be the default
location for jar:deploy/pom:deploy/dist:deploy, as a company doesn't want to
upload to ibiblio.

2) Filesystem
jar:deploy/dist:deploy don't work with filesystem. Which leads to maven xml,
and eventual failure.

3) Maven xml
Nice idea, but very difficult to use. Because there is no documentation on
the properties that get created internally by each goal. For example, I'm
sure that there is a property defined by the dist goal for the
'target/distributions' directory. I needed to use this in a script to do an
ant copy as dist:deploy doesn't work. But this isn't documented anywhere,
nor can it be discovered without much searching of code.

As I tried to work around each problem, I found I was adding more and more
into maven xml. In fact I was writing an ant script. It was just taking much
longer than writing a pure ant script as I didn't know the variables I was
using. So, I reasoned that I might as well just write my own ant script
separate from maven.

4) Trust and blame
Maven is at a higher level than ant. Just like Java is higher level than
assembler. With Java you can trust that it will do what it says it will.
Unfortunately, with Maven I no longer have the Trust necessary to use it.
Each maven call I make feels like guesswork. It might work, but it might
not. It might copy a file where I want it, or it might mess up part of my
corporate network by copying it somewhere unexpected.

Ant is at the 'do this, do that' level. If something goes wrong, its my
fault. Maven is at the 'let maven do that for you' level. If something goes
wrong its maven's fault. Thus, I blame maven, not myself, for the failure.
With my OSS hat on, that worries me.

You should know that I don't feel good writing this. I'm sure that for you
guys, it all seems to work great and well. But I can't spend forever on
trial and error attempts. Especially as I don't feel that what I am trying
to do is that complicated.

I will probably use maven just to do site:deploy (that works well :-). The
rest will be ant. Maybe I'll look again after version 1.0. Sorry.


To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 14 | next ›
Discussion Overview
groupusers @
postedSep 25, '03 at 9:05p
activeOct 7, '03 at 10:46p



site design / logo © 2021 Grokbase