Hmm, how would I go about convincing maven-plugins such as clean to only
use the latest versions (in some cases it just seems to be a dep on the
pom file, not any actual jars). Don't know where I would find the handle
for this in maven, unless one does it by editing the poms that are
wandering off into past versions I suppose.
That of course introduces some chance of running into any cases where
there's a backwards compatibility problem, but keeping the list of
dependencies shorter might be worth that risk.
-Gus
Patrick Heck
||| Principal Software Engineer
Aspen Technology, Inc. ||| +1 781-221-6483 ||| www.aspentech.com
-----Original Message-----
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: Thursday, May 19, 2011 12:30 PM
To: users@maven.apache.org
Subject: Re: Bootstraping a repository manager
On 19/05/2011 11:26 AM, Heck, Gus (Patrick) wrote:
Oh yes, and I'll be doing some new searches now that I have your name
as
a search key since you say you've discussed this a lot. :) Searches on
settings.xml, or repository or most of the keywords I can think of for
this just have way too many hits. The help is definitely appreciated,
sorry if I sounded a bit sour.
On the plus side, I'm now running down dependencies now that I've
figured out where to find things in "central" (and where central is).
Interestingly, a simple maven-clean from maven 3.0.2 pulls
dependencies
for multiple versions of maven and maven-parent. Seems a little funky
to
me, but I guess it's probably a product of plug-ins having a separate
release schedule.
This sounds similar to the problem with third party libraries where you
end up with a lot of different versions of log4j, for example, and you
just pick one - the highest, provide it in a shared libray and then use
exclusions to prevent other jars from loading old versions.
I believe in strict and explicit control over all code (including the
3rd party stuff) that runs in production and went to the trouble of
making this happen for our development team.
Ron
-Gus
Patrick Heck
||| Principal Software Engineer
Aspen Technology, Inc. ||| +1 781-221-6483 ||| www.aspentech.com
-----Original Message-----
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: Wednesday, May 18, 2011 10:22 PM
To: users@maven.apache.org
Subject: Re: Bootstraping a repository manager
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
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
