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: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
