maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
Subject Re: Jar file not in maven
Date Mon, 04 Feb 2013 12:57:46 GMT
MRM would help if your company blocked access to the internet.

  You go to your favourite cyber-café. Download the jars. Bring them to 
the office and put them in your MRM and they would be good for everyone 
until you wanted to change version.

You could also get the indulgence of your system manager to either do 
the download for you or give you a one-time free pass to the internet 
for 15 minutes to let you get your downloads.

Good to see that you are making good progress with Stephen.

Ron

On 04/02/2013 1:57 AM, Joachim Durchholz wrote:
> 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...
MRM would help. You go to your favourite cyber-café. Download the jars. 
Bring them to the office and put them in your MRM and they would be good 
for everyone until you wanted to change version.

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


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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


Mime
View raw message