On 8/31/06, ArneD <[EMAIL PROTECTED]> wrote:
Eric Redmond wrote: > > Any more reasons? Care to expand these ideas? > Hi Eric, for corporate users, I believe there are some additional issues to the ones already named. Especially in large companies, it is often unacceptable to let users download artefacts directly from an Internet repository, even not through a proxy. Companies need to have full control over all artifacts used in their build processes, that means that only artefacts that have been explicitly released by someone should be used.
I don't understand why a Proxy is unacceptible. The administrator of the Proxy can - at any time- disconnect the Proxy from the internet. So when you start using Maven, you want
to immediately set up an internal repository which, I believe, is still a too complicated task.
We did this by enacting a single build on our projects and let Proximity fill itself. Once it has the artifacts it needs, disconnect it. This is especially true for setting up an internal plugin repository. We did
not find a comfortable way to initially fill an internal plugin repository. You should be able to say "fill my plugin repository with all required JARs for the plugins x, y and z". Our workaround was to set up a Maven reference installation zip, that already has all required plugin JARs in its local repository, so that users who unzip that archive have everything they need.
Why can't you solve this with an in-house remote repository, rather than zipping up jars for local repos? Another point is, plugin JARs and production JARs should be separated. This
is already possible for remote repositories, but it should be possible for the local repository as well. Tool JARs like xerces etc. are used both by plugins and by projects. But just because some plugin needs a JAR file, corporate users do not want to make that JAR available for builds. Corporate users just don't want to get tools mixed up with production software.
Why does your build software get mixed up with your production software? Using the release or dependency plugins will not bundle build tools with the jars to be released. Anyway, Maven is a great piece of software, full of great ideas. But some
things still need to be improved before Maven has chances to achieve a wide acceptance.
Unless I'm really misunderstanding the problems, I haven't seen a problem you've had that is inherent to Maven (except possibly by creating a mirror repository with a set of dependencies). I'd chalk-up many of your problems to lack of documentation or guidence, which we all agree is a problem. I too handle large-scale corporate builds for a living, and that is part of the reason for this poll. The problems I have had with Maven are few and far between, mostly related to my own ignorance of where to look for help, or bugs in the code. But I still hear from people who refuse to use Maven and I was intrigued as to why, since my own experience has been largely positive - especially in the corporate space. I am finding more often than not that people who have difficulty with Maven are attempting to use it it in non-standard ways, or refuse to alter their project structures to match. Is this a hubris of Maven or of the project developers? That is a question for philosophers. What I do know is that Maven is a conceptual project framework, as much as a software build system - just like Object Oriented programming is as much conceptual construct, as it is a programming language's tenet. Just as OO has evolved design patterns, and ant has best practices, I feel that a lot of the problems with Maven are a lack of simple "how-tos", largely due in part that its concepts are so new. Does than mean that Maven is not worth using? I doubt it... as Russ mentioned above, Ant can always be your stopgap. Eric Arne
-- View this message in context: http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6078097 Sent from the Maven - Users forum at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
