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]

Reply via email to