> In my experience, this is a very common attitude though. Unfortunately.
> For example, the jspwiki project currently under apache > incubation stores its dependencies in the version-control > system and will not change. And they are not stupid people; > it is just the way they like to work. Doing something out of some irrational liking is hardly good business practice. Maybe they have some ANT days hangups? Just how does the Maven project integrate this behaviour given that its dependency mechanism is inteded to work off a regular M2 repo? Prove to me that they are not driving a horse and cart through some of the basic principles of Maven, i.e. portable standard build. Are they using coded paths to their dependencies? If so what happens if that behaviour is depricated? With no proper business rationale and many objections, this practice is dangerous. Some people will of course tell you that everything you need to build a project must be checked into the VCS along with the rest of the project - so what do they think all us other folks who don't do this are up to? Cos I can assure you we are getting a better deal, faster check out and import for a start, and safe that we are using Maven as intended. > useful to have a way for maven to deal with this. Persuading > people to move to maven is difficult enough without having to > tackle a second problem like this concurrently. Maven provides a plugin mechanism, i.e. mojos, and customizable lifecycles for those who wish to dabble. But the disadvantage is that all that makes a build off standard. So best to do it only when unavoidable. > BTW, one of the issues is that previously java classpaths had > to be set up with the explicit names of dependent jars; > having dependencies that change names was awkward. So simply > having a stable name, and overwriting with later versions of > the jars was tempting. Now that java can use "*" to pick up > all jars in a dir this is no longer relevant, but the habit endures. This just adds to the crazyness. Maven controls dependency versions for very good reasons. If you are hard coding classpaths, that practice has to stop. Using * also means you have little control over what is being loaded at runtime. If you have some scripts that need to build classpaths, then these should be filtered resources, so they adapt dynamically to the build. Leverage Maven to provide classpaths with the right deps. > I think that in this case, storing the repository in VCS makes sense. 8< What sense? If a newer version of a dep artifact pops into the Maven repo, it can be picked (or not) up by the next build, you can control this behaviour in a number of ways, this is powerful. How does putting artifacts in the VCS fit into this Maven standard? I also don't get the concerns over replication - some trivial replication/proxy technology should take care of that. It should not be an issue to sweat the developers. Regards, John Eurobase International Limited and its subsidiaries (Eurobase) are unable to exercise control over the content of information in E-Mails. Any views and opinions expressed may be personal to the sender and are not necessarily those of Eurobase. Eurobase will not enter into any contractual obligations in respect of any part of its business in any E-mail. Privileged / confidential information may be contained in this message and /or any attachments. This E-mail is intended for the use of the addressee(s) only and may contain confidential information. If you are not the / an intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify us immediately, and then delete this E-mail. Neither the sender nor Eurobase accepts any liability whatsoever for any defects of any kind either in or arising from this E-mail transmission. E-Mail transmission cannot be guaranteed to be secure or error-free, as messages can be intercepted, lost, corrupted, destroyed, contain viruses, or arrive late or incomplete. Eurobase does not accept any responsibility for viruses and it is your responsibility to scan any attachments. Eurobase Systems Limited is the main trading company in the Eurobase International Group; registered in England and Wales as company number 02251162; registered address: Essex House, 2 County Place, Chelmsford, Essex CM2 0RE, UK. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
