maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: Jar file not in maven
Date Wed, 30 Jan 2013 09:44:17 GMT
On 30 January 2013 09:15, Joachim Durchholz <> wrote:

> Am 30.01.2013 09:13, schrieb Anders Hammar:
>  Joachim, a possible solution would be to front the external non-Maven repo
>> with a repo manager transforming it into a true Maven repo.
> Sounds complicated.
> I.e. not doable unless you know all aspects that need to be considered,
> hence probably far out of my league.
> > As a Nexus (one
>> of the repo managers out there) user I know you can do that via
>> implementing a virtual repo plugin, but I would expect you can do similar
>> things with the other repo managers as well.
> Still too complicated and out of my league, I fear.
> > Just keep in mind that it
>> can't do anything magical; if metadata is missing you have to provide it
>> in
>> some way.
> Sure.
> The version number would come from the revision number or tag if using an
> SVN as a source.
> For Sourceforge, it would have to be extracted from the file name.
> I think the version number is the most important metadata anyway.
>  Other than that, I can only shim in with Stephen that many of us are tired
>> of arguing about what's the correct way of solving things "the Maven way".
> Yes, I can understand that. I'm pretty much aware that this is making this
> exchange tortuous, for both sides; I have to constantly battle this "you
> essentially don't know what you're talking about" attitude, which is tiring
> as well.
>  You may not agree with us, but that's a different thing.
> Yes, currently I disagree.
> However, I'm eager to hear arguments that may falsify my view. I'd be all
> for it to see how this use case (import available from an external, stable
> download site) can be properly integrated into a Maven workflow.
> The proposals that I have seen don't preserve the version number. My claim
> (yet to be falsified) is that this makes people set up imports without
> version number, losing this essential piece of information. If people "do
> it right" and manually add the version number by whatever means, a consumer
> of such a Maven artifact still won't know whether the manually provided
> information is actually right.
> So I'm arguing for some mechanism to record in a pom:
> - the coordinate where the download comes from
> - the coordinate where the artifact is supposed to go do in a maven repo
> - an automatic process that installs the pom and the download
> Whether the download should be part of the build process or triggered
> manually depends on whether the origin is stable (i.e. whether there's a
> risk that the origin overwrites the artifact at its coordinate - not an
> issue if the origin is an SCM and the download coordinate includes a
> revision number).

Here is how I would "Maven Way" handle this kind of dependency.

First off, I am assuming (always a danger of making an ass of you and me)
that we have a multi-module project.

I would create a pom.xml for the artifact that I want to use. This pom.xml
will have to correctly identify the runtime dependencies of the artifact I
am providing, so tooling is not really going to help, the artifact will
have to be hand written due to the nature of these things.

[I have experimented with using bytecode analysis to establish dependencies
between a set of .jar files in a lib directory, and it can give you a good
starting point, but too often it gives dependencies which should be
optional, or misses dependencies that are referenced via reflection. The
amount of times it has been in error is > 20% in my experience, and that
error rate is unacceptable for general guidance]

So you have to write the pom.xml by hand.

It will look something like this

<project xmlns="" xmlns:xsi="" xsi:schemaLocation="">

  ... other details as you see fit ...

    ... list these ...

      <!-- many ways to skin this cat -->
              <url>some remote url</url>



Now that pom.xml implicitly defines the location of the artifact, though
you need to read the pom to find out. Your project will be a simple
"check-out and build" assuming they are not behind a corporate proxy that
prevents downloading .jar files from random websites... in which case they
will need to get an exception for all of them to access that website and
they will curse you for not just sticking it in a MRM which they at least
got the corporate IT guys to grant an exception to...

The better way would be to write the pom.xml and use

mvn install:install-file -Dfile=... -DpomFile=...


mvn deploy:deploy-file -Dfile=... -DpomFile=...

or upload as a bundle to the corporate MRM

to install that pom... the pom would probably look mostly the same, except
you would list the origin of the file in the <scm> section, e.g.

<project xmlns="" xmlns:xsi="" xsi:schemaLocation="">


  ... other details as you see fit ...

    ... list these ...


And here's the best bit about that way... when you write a pom.xml like
that, it's just perfect for submitting to central in a bundle upload...
which means that others can receive the benefit of your hard work
determining the list of dependencies.

Now if you don't provide a pom file to install:install-file or
deploy:deploy-file those plugins will generate a crappy stub for you... we
need to put some pom there, and the stub will not break things, so it
should be seen as a stop-gap until you determine the correct <dependencies>

Now if you are complaining that the above is too much work, well the only
real work I see is determining the list of dependencies... and sorry to
say, but that is hard work that a person needs to do if it is to be done
right... and if you don't need it done right, then the stub pom is just

> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**<>
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message