maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Durchholz ...@durchholz.org>
Subject Re: Jar file not in maven
Date Mon, 04 Feb 2013 06:57:36 GMT
Am 30.01.2013 10:44, schrieb Stephen Connolly:
> First off, I am assuming (always a danger of making an ass of you and me)
> that we have a multi-module project.

No multi-module project here, just dependencies (and a parent pom to 
capture configuration analogies).

> 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.

?
Let's stick with the assumption that the external coordinate provides a 
stable artifact. No need to create anything.

> [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]

Agreed, finding dependencies needs to remain mostly manual and cannot be 
solved automatically.
Those 80% information that can be extracted automatically are provided 
by Tattletale, so no extra tooling for Maven would be required. Since 
extraction can't be made part of the Maven workflow, an external tool is 
just fine.

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

Sure. I'm routinely writing poms by hand anyway; the pom generators in 
m2e haven't been helpful for me (archetype selection is useless if you 
know the archetypes even less than you know the pom structure).

> 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>
>
> <toFile>${project.build.outputDirectory}/${project.build.finalName}.jar</toFile>
>              </configuration>
>            </execution>
>          </executions>
>        </plugin>
>      </plugins>
>    </build>
>
> </project>

Ah. I had overlooked Wagon as another way to skin that cat.

Here's my take ("foo" is a stand-in for the external project's name):

         <plugin>
           <artifactId>maven-scm-plugin</artifactId>
           <executions>
             <execution>
               <id>svn-import-bundled-lwjl</id>
               <phase>generate-sources</phase>
               <goals>
                 <goal>checkout</goal>
                 <goal>update</goal>
               </goals>
               <configuration>
                 <connectionUrl>
                   ${foo.svn.url}/${foo.svn.path}
                 </connectionUrl>
                 <!-- from parent pom's pluginManagement section -->
                 <!-- so they all pull from the same origin rev: -->
                 <scmVersionType>${foo.svn.versionType}</scmVersionType>
                 <scmVersion>${foo.svn.version}</scmVersion>
                 <!-- end from parent pom's pluginManagement section -->
                 <checkoutDirectory>${foo.svn.dir}</checkoutDirectory>
                 <workingDirectory>${proj.svn.dir}</workingDirectory>
               </configuration>
             </execution>
           </executions>
         </plugin>
         <plugin>
           <groupId>com.github.goldin</groupId>
           <artifactId>copy-maven-plugin</artifactId>
           <version>0.2.5</version>
           <executions>
             <execution>
               <id>copy-jar</id>
               <phase>package</phase>
               <goals>
                 <goal>copy</goal>
               </goals>
               <configuration>
                 <resource>
                   <file>${proj.svn.dir}/${proj.svn.jar}</file>
                   <targetPath>${project.build.directory}</targetPath>
                   <destFileName>
                     ${project.build.finalName}.jar
                   </destFileName>
                   <skipIdentical>true</skipIdentical>
                   <attachArtifact>true</attachArtifact>
                 </resource>
               </configuration>
             </execution>
           </executions>
         </plugin>

This works as expected, unfortunately m2e doesn't know that 
copy-maven-plugin replaced the jar, so workspace discovery fails.
Which isn't a Maven problem but something to take to the m2e-users list.

I can try whether Wagon works better in m2e.

> Now that pom.xml implicitly defines the location of the artifact, though
> you need to read the pom to find out.

As opposed to looking at the jar's file name directly?
True. That's why I'm renaming the jar in the copy-maven-plugin 
configuration via
   <destFileName>${project.build.finalName}.jar</destFileName>
The pom needs to carry an explicit version number. I'm taking it 
manually from the download location; it's an SVN site, so I could be saying
   <version>3.0-SNAPSHOT</version>
or
   <version>3.0.rev4711</version>
depending on whether I'm pulling from upstream snapshots (and don't care 
about stability anyway, yet) or from a fixed upstream revision and don't 
want to rely on their tagging.
If I can rely on their tagging, I can set proj.

 > 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...

I wouldn't be able to download the jar manually then, so the MRM route 
wouldn't help...

 > 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...

... and this scenario would be irrelevant then.

> 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.

I'll have to think about that one a bit more.

> 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...

As I said, the dependencies can't be determined automatically.
BTW it's just occurring to me that you can't determine them 
automatically no matter what, whether the jar comes as a binary or as a 
standard Maven project. You just rely on whoever is providing the pom to 
properly specify all the dependencies.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message