The other nice thing about Maven is that no matter what one is building
or how unusual one thinks their environment is, someone has already
built something similar and someone has already worked out a best
practice in a similar environment.
It is also supported by a great forum where you get advice that you
could not find or afford and it is free here.
Ron
On 18/05/2011 9:32 PM, Wendy Smoak wrote:
On Wed, May 18, 2011 at 7:56 PM, Heck, Gus (Patrick)
<gus.h...@aspentech.com> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org