From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> > 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. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
