Or you could do 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>net.java.dev.jna</groupId>
<artifactId>jna</artifactId>
<packaging>jar</packaging>
<version>3.0.3</version>
<name>Java Native Access</name>
<distributionManagement>
<repository>
...
</repository>
</distributionManagement>
<build>
<plugins>
<!-- fake out maven and install the binary artifact -->
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<copy
file="${basedir}/src/main/jar/${pom.artifactId}-${pom.version}.jar"
tofile="${basedir}/target/${pom.artifactId}-${pom.version}.jar"
overwrite="true"/>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
On Wed, Jul 16, 2008 at 7:45 AM, Stephen Connolly
<[EMAIL PROTECTED]> wrote:
> I would do a simple trickery...
>
> disable the jar plugin and then use the build-helper plugin to attach
> the jar file.
>
> That way you can keep the jar packaging and have your jar!
>
> On Wed, Jul 16, 2008 at 7:13 AM, Kristian Rink <[EMAIL PROTECTED]> wrote:
>> Folks;
>>
>> I am searching for a smart way to deal with .jar artifacts not available
>> in public repositories, i.e. because maintainers didn't care and/or they
>> are part of some proprietary application simply not available in such a
>> way. We're using an archiva repository as an internal storage / proxy,
>> and so far I manually dumped these .jars there using a fake pom to
>> deploy a pre-packed file. This works fine, however I am in fear that,
>> three years from now, no one will remember where these artifacts
>> actually came, and/or that, given we need to rebuild our local maven
>> structure or even loose our archive, people simply checking out code off
>> our SVN repository will fail to build the projects because of missing
>> these dependencies. My idea, so:
>>
>> - I want to create "empty" maven2 projects, maybe .jar packaging, to
>> contain nothing else but a third-party .jar (like the client library to
>> our internal online viewer) in src/main/resources/. The .jar should,
>> along with the project, be committed to SVN to ensure the .jar is always
>> there at the right version and goes to the repository in case it is missing.
>>
>> - My projects requiring these third-party .jars should depend upon those
>> empty "wrapper" projecs.
>>
>> - When building / deploying these "wrapper" projects, all that should
>> happen is that the .jar off src/main/resources/ is installed in the
>> local repository according to groupId, artifactId, version defined in
>> the "wrapper" pom.
>>
>> - Build/deployment of these artifacts should happen "automatically", in
>> best case using some kind of plugin to be defined in the "wrapper" pom.
>>
>>
>> Is something like this possible? How to possibly achieve this? So far I
>> thought about using the exec:exec plugin calling mvn to deployFile but
>> this doesn't seem pleasant in situations in which, in example, the
>> NetBeans maven2 integration is used so a plugin definitely would be a
>> better approach...
>>
>>
>> Thanks in advance for any hints, best regards.
>> Kristian
>>
>>
>> -- Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/
>> jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 "One
>> dreaming alone, it will be only a dream; many dreaming together is the
>> beginning of a new reality." (Hundertwasser)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]