maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Jar file not in maven
Date Wed, 30 Jan 2013 09:47:16 GMT
On 30 January 2013 09:44, Stephen Connolly
<stephen.alan.connolly@gmail.com>wrote:

> On 30 January 2013 09:15, Joachim Durchholz <jo@durchholz.org> 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="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
> ">
>   <modelVersion>4.0.0</modelVersion>
>   <groupId>com.yourcompany.thirdparty</groupId>
>   <artifactId>third-party-artifact</artifactId>
>   <version>subversion-revision</version>
>
>   ... other details as you see fit ...
>
>   <dependencies>
>     ... list these ...
>   </dependencies>
>
>   <build>
>     <plugins>
>       <!-- many ways to skin this cat -->
>       <plugin>
>         <groupId>org.codehaus.mojo</groupId>
>         <artifactId>wagon-maven-plugin</artifactId>
>         <version>1.0-beta-4</version>
>         <executions>
>           <execution>
>             <phase>package</phase>
>             <goals>
>               <goal>download-single</goal>
>             </goals>
>             <configuration>
>               <url>some remote url</url>
>               <fromFile>third-party-artifact.jar@
> ${project.version}</fromFile>
>

Sorry a cut-and-paste error on this next line:


>
> <toFile>${project.build.outputDirectory}/${project.build.finalName}.jar</toFile>
>

Should actually be


<toFile>${project.build.directory}/${project.build.finalName}.jar</toFile>

But I was copying from some other pom I had to hand

            </configuration>
>           </execution>
>         </executions>
>       </plugin>
>     </plugins>
>   </build>
>
> </project>
>
> 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=...
>
> or
>
> 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="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
> ">
>   <modelVersion>4.0.0</modelVersion>
>   <groupId>com.yourcompany.thirdparty</groupId>
>   <artifactId>third-party-artifact</artifactId>
>   <version>subversion-revision</version>
>
>   <scm>
>     <connection>http://some-remote-url/...</connection>
>   </connection>
>
>   ... other details as you see fit ...
>
>   <dependencies>
>     ... list these ...
>   </dependencies>
>
> </project>
>
> 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
> fine!
>
>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<users-unsubscribe@maven.apache.org>
>>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>

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