Hi Wendy, "In central" is slightly opaque sometimes. In this case I was deceived by the top level maven directory. I didn't know that this was a very old location, and so I was getting dead-ended for a while until I figured out that everything modern was in org/apache/**
As for creating my own maven, sure I can do that if it seems to be necessary, though forking a project has significant costs, both in the initial code and in maintenance. I'd actually been thinking more along the lines of a plug-in that parses settings.xml and fails out if it doesn't like what it sees. I'm just curious why this fairly important bit of configuration is left out on the desktop where it is hard to manage. The size of the companies that are locking things down is probably shrinking over time as IT managers and Execs become more savvy about licensing/IP and more companies have offshore teams. Ours was more permissive in the past, but the lockdown is in progress, and I'm trying to make sure my team can still operate when it happens. -Gus Patrick Heck ||| Principal Software Engineer Aspen Technology, Inc. ||| +1 781-221-6483 ||| www.aspentech.com -----Original Message----- From: Wendy Smoak [mailto:[email protected]] Sent: Wednesday, May 18, 2011 9:33 PM To: Maven Users List Subject: Re: Bootstraping a repository manager On Wed, May 18, 2011 at 7:56 PM, Heck, Gus (Patrick) <[email protected]> wrote: > As I explained in another response, I want the software to tell me when I've got enough stuff to build (much like test driven development), rather than trusting I covered everything post-hoc. As for doing it with ant projects, I've certainly been there. At one job I wrote a custom ant task that looked at /lib, a properties file and a directory called /licenses. If the jar in lib didn't have an entry in the properties file, or the value for that jar in the properties file didn't match the name of a file in /licenses, the build failed. Not really that hard to implement. As you say, the big time sink is in hunting down the licenses, but in the current job I have to do that anyway to include a copy of the license with the approval form for the lawyers... nothing maven can do about that. The only irritation is that some basic artifacts seem to be hard to find and instead of an answer such as "the artifacts you need can be found here" I get a chorus of "don't do that" Hm? I already told you where the things are. In the central repository. (And you need both the jar and the pom for it to work.) Typically the only organizations that can afford to be this paranoid are really big ones. I work with one of those. The internal Maven repo does not talk to the internet. Instead, developers fill out a web form to request a new artifact to be uploaded, someone approves it if it's in the standards, or sends them off to the reference architecture team to explain why they need it, and then someone else presses the buttons in Archiva to upload it. Plugins are a special case. Those we handle within the build team, as they typically want all kinds of dependencies. So for those we connect to the internet and use the Maven Assembly plugin to create a repository bundle by listing the plugin as a dependency. Maven goes off and gets everything that plugin needs, and the whole bundle is uploaded. Those artifacts generally aren't going to get into your end product, they are just used during the build. > By the way, I am a bit irritated that maven put's the repository information out on the developer's settings.xml. I'd much rather be able to manage that centrally, and not leave it as something that they could screw up, or forget to do after their hard drive fails and the set things up a second time. Is there a way to lock things into a single repository without settings.xml? That's where it's done, with a mirror in settings.xml. You can create your own Maven distribution with the settings.xml you want them to use packaged inside it (in the /conf directory.) I assume if you're this strict about dependencies, developers are not downloading random software from the internet and installing it on their machines, so provide the Maven distro you want them to use. -- Wendy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify the sender and permanently delete the original copy and any copy of any e-mail, and any printout thereof. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
