On 4/25/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > On Mon, 2006-04-24 at 21:25 -0400, Alexandre Poitras wrote: > > On 4/24/06, Brandon Goodin <[EMAIL PROTECTED]> wrote: > > > "tons of advantages" - please quantify this. > > > > Well distributing internal corporation dependencies and managing the > > version, especially nightly build is way easier using Maven repository > > capabilities. Managing your project dependencies version is also > > really easier (especially conflicts and snapshots). > > I would disagree. Managing dependencies is really easy when you've > checked jars into a directory - the jars used are the ones in that dir, > and nothing else. >
Well if you depend on a project developped concurrently (some common component) and not a stable component, it is easier. Easy to upgrade to a newer version and especially easy to get the new nightly builds in the morning. Of course, this is doable using some other mechanism but you have to it manually. Maven just see there are a fresh snapshot available and download it. Well, from experience I have found it easier but I guess it depends if Maven fit the way your corporation work. > Of course this does have the disadvantages listed in my mail (more repo > space needed, more bandwidth). > > > > > All the Maven generated reports also work better with regular > > dependencies because they can find some metadatas to work with. > > true. > > > > > > > > > Personally, I find the repository to be a "nice" piece of Maven. But, > > > I don't see it as a cardinal sin to actually distribute libraries in > > > your project. If you follow the libary naming convention then who > > > cares? > > > > > > Personally, what i find annoying are the copious additional, needless, > > > and redundant dependencies that i have to download because of the > > > dependencies defined in the pom of a jar that i need to download. > > > > Nothing the exclude tag can't fix. > > That can be quite clumsy to use, though. Sometimes half-a-dozen libs > need to be excluded, at which point the pom becomes hard to read. Yup but if it is the case it is usually because the original dependency pom has some dependencies that should be declared optional. Time to fill a JIRA issue. Also, the key here is using a super pom so those settings are fixed for all your projects, this is what I do with Spring and Hibernate and it works very well. I don't have to declare all those exclude again and again. > > > > > > I also find it annoying to have to manually install several small > > > libraries to my local repo cuz i can't distribute them as a result of > > > licensing. It is additionally annoying to have to setup a jar > > > repository that will be used for jars that will be needed that can > > > only be distributed privately. All of this... vs. me just referencing > > > them in my source tree? > > > > > > > You are making this sound like it is a lot of work. Manually > > installing files on a corporate repository using install:install-file > > usually doesn't take more time then checking them inside SVN. A maven > > repository is basically a Jar versionning systems. > > [as noted in your followup, you meant deploy:deploy-file] > > That's assuming that a corporate repo exists and that it has upload > support available. Yup but honestly I wouldn't use Maven without it because when you find a bug on ibiblio you don't have to wait for your bug report to be treated, you can fix it on internal corporation repository in the mean time. > > > > > > I like Maven a lot and really enjoy the standard project layout > > > features and plugins that are provided. But, the jar repository has > > > caused me more time and less efficiency. However, i do like ibiblio > > > for a single one stop shop for grabbing jars i need... to drop in my > > > source tree ;-) > > > > > > I like it when people can check out my source from SVN and simply > > > build. This is possible when i place them in SVN. Heck, I can even > > > check Sun Jars into my SVN repo! ;) > > > > If you have a remote Maven repository on the same server as your SVN > > repo, I really don't see the difference. > > True, as long as: > (a) your svn server is already running behind a webserver, so the maven > repo can easily be set up, > (b) there is some upload support for that server, > (c) there is some way of ensuring that jars always come from this repo, > and never from ibiblio (this is the hardest bit in my experience) You're right except couple of things : - a) Http is not mandatory, you can use ftp or sctp for instance. - c) Well this is one is easy to fix, install Maven proxy on your internal corporation repository. Now on your desktop, go in your settings.xml and declare this repository as the only mirror of central. You'll never go on ibiblio again, the proxy will if you have configured it to do so. The only possible downside of this approach is that your repository server needs acces to the Internet. I understand inital difficulties using Maven repositories but once you have an internal corporation repository coupled with Maven-proxy, things get better. Well right now Maven-proxy is not the best tool but it does work. A newer version is coming shipped in Maven repository tools or something like that, I don't remember the name but it looks promising. Can't wait to see the result. > > Cheers, > > Simon > > > --------------------------------------------------------------------- > 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]
