Eric Redmond wrote: > >> 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 >> theirE >> 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. >
In the company that I helped setting up a Maven-based build environment, a public site like ibiblio.org is considered a potentially unsafe source. Like it or not. Only JARs that have been approved internally may be used for production. (BTW, this was within finance industry which is partly quite sensitive at such points.) Practically, that meant we had to set up an internal remote repository and deploy all existing JARs to it. This worked fine in the end, but felt difficult in the beginning - probably due to the lack of good documentation and examples. The bigger problem was setting up an internal **plugin** repository: >> 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? > You can do it with an in-house remote plugin repository, but how would you populate it with all plugins that you need? Ok, you can set up a proxy for this purpose. Then, you somehow have to make sure that Maven downloads all relevant plugins (this is not trivial either). Afterwards you can disconnect the proxy from Internet, or use the proxy's cache as your internal plugin repository. (Keeping the proxy alive and connected to the Internet might be unacceptable because you want to evaluate new plugins before you release them for internal usage.) When I wanted to use Maven-proxy for this purpose, I soon encountered problems because it did not support NTLM authentication, so I could not get through the firewall. So we helped us with zipping up a local repo as a workaround. Anyway, I think that the whole task of setting up an internal plugin repository is too complicated. We don't want to use a proxy, so why do we have to set it up. When talking about tools, companies are used to download the tool from the vendor's site or install it from CD and then just use it. This is not possible with Maven, you need an Internet connection during run-time, at least until you have managed to set up an internal plugin repository. >> 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. > Maybe it becomes clearer with an example: Let's say, your build uses plugin X which has a dependency to Xerces. So you will have Xerces in your local repository after running your build, because it is downloaded from the internal plugin repository to your local repository. Thereafter, you are able to declare a dependency to Xerces in your project, and the build will run through - even if Xerces has not been released to the internal remote repository, and there's no connection to the Internet. Builds should only be able to use artifacts that have explicitly been released to the internal remote repository. Nothing else. Even not JARs from an internal plugin repository. >> 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). > Did my points get a little bit clearer now? But don't get me wrong, I do not consider these points real showstoppers. We did set up a Maven-based build environment succesfully in the end, and it works quite well. Regards, Arne -- View this message in context: http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6084903 Sent from the Maven - Users forum at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
