On Tue, Aug 4, 2009 at 1:01 PM, David Hoffer<[email protected]> wrote:
> Hum,
>
> I'm getting close but not quite there yet.  Here is my configuration.
>
> <plugin>
>                <groupId>org.apache.maven.plugins</groupId>
>                <artifactId>maven-dependency-plugin</artifactId>
>                <executions>
>                    <execution>
>                        <id>unpack</id>
>                        <phase>generate-sources</phase>
>                        <goals>
>                            <goal>unpack</goal>
>                        </goals>
>                        <configuration>
>                            <artifactItems>
>                                <artifactItem>
>                                    <groupId>wt</groupId>
>                                    <artifactId>wt</artifactId>
>                                    <version>4.0-SNAPSHOT</version>
>                                    <type>jar</type>
>                                    <overWrite>true</overWrite>
>
> <outputDirectory>${project.build.directory}/classes</outputDirectory>
>                                </artifactItem>
>                            </artifactItems>
>                            <overWriteReleases>true</overWriteReleases>
>                            <overWriteSnapshots>true</overWriteSnapshots>
>                        </configuration>
>                    </execution>
>                </executions>
>            </plugin>
>
> For some reason after running the install goal the unpack seems to have
> taken precedence over the compile!

"install" isn't a goal in this case, it is a phase.   When you run
"install", you are asking Maven to walk through the entire lifecycle
(except the deploy phase).   Instead of trying to test with the
"install" phase, run "mvn generate-sources" then run "mvn compile".
Also use the -X flag to get more output.

Take a look at the list of phases here:
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html


>
> Since the generate-sources phase is before compile shouldn't the compile
> have over written the unpack?  I'm confused.
>

Do you have source in src/main/java?   What is your project's packaging?

> -Dave
>
>
> On Tue, Aug 4, 2009 at 8:39 AM, Tim O'Brien <[email protected]> wrote:
>
>> On Tue, Aug 4, 2009 at 9:25 AM, David Hoffer<[email protected]> wrote:
>> > What is the maven way of creating a patched jar?
>> >
>> > I have a case where I need to apply some overrides to a binary jar which
>> is
>> > one of my dependencies.  I have the source code for the overrides.  So I
>> > could create a child module with the source and the one dependency that
>> > needs the overrides applied.  What maven plugin would I use to extract
>> the
>> > class files from the dependency, combine with the new generated classes
>> from
>> > source, and then re-jar?  The final artifact would have a new name, i.e.
>> > _patched, so as to not get confused with the original.  How can I then
>> stop
>> > the transitive dependency on the original jar?  I would want the
>> dependency
>> > to be on the new patched version only.
>> >
>>
>> 1. Create a project with a new groupId, artifactId, and version.
>>
>> 2.  Publish this third-party binary to a repository manager - you can
>> use one of the various repository managers that allow you to manually
>> upload an artifact.   (Me?  I'd recommend Nexus).
>>
>> 3. Use the dependency plugin to unpack the artifact to your project's
>> target/classes.   Bind the unpack goal to generate-sources or
>> generate-resources so that the download and unpack.
>>
>> Unpack Mojo:
>> http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html
>> Intro to Lifecycle:
>>
>> http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
>>
>> 4. Package, publish your new patched artifact to a repository manager
>> (under a new groupId, artifactId, version).
>>
>> The key here is that you create a project that patches the original
>> artifact and then publishes it under a different GAV coordinate.   I
>> would not recommend patching the JAR and then writing it back to the
>> repository manager under the same GAV coordinate: 1. You are going to
>> have a GAV collision, and 2. It makes it difficult to update to a new
>> version of this binary dependency.
>>
>> > What's the maven way of doing this sort of thing?
>> >
>>
>> Good luck.
>>
>> > -Dave
>> >
>>
>> ---------------------------------------------------------------------
>> 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