I think our emails collided. Just to be clear, here is my new
configuration. It does not work because it overwrites what the compiler
did.
<executions>
<execution>
<id>unpack</id>
<phase>process-classes</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>wt</groupId>
<artifactId>wt</artifactId>
<version>4.0-SNAPSHOT</version>
<type>jar</type>
<overWrite>false</overWrite>
<outputDirectory>${project.build.directory}/classes</outputDirectory>
</artifactItem>
</artifactItems>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>false</overWriteSnapshots>
</configuration>
</execution>
</executions>
-Dave
On Tue, Aug 4, 2009 at 12:46 PM, Tim O'Brien <[email protected]> wrote:
> On Tue, Aug 4, 2009 at 1:25 PM, David Hoffer<[email protected]> wrote:
> > Yeah, I meant install phase. My pom's packaging is jar, and I have the
> > source in src/main/java.
> >
> > It seems to find the source because for new files I do find the compiled
> > classes in the right places. However what I also find is that for
> classes
> > in the dependent jar they seem to have overwrote the compiled ones.
> >
> > I think what is happening is that during the compile phase it simply
> skips
> > the compile (or at least the writing of the class file to disk) if it
> > already exists. How can I configure the compile to always overwrite?
>
> Move the copy goal that you declared to happen just after compilation.
> Look at the lifecycle list, I think you want "process-classes"
>
> >
> > -Dave
> >
> > On Tue, Aug 4, 2009 at 12:10 PM, Tim O'Brien <[email protected]>
> wrote:
> >
> >> 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]
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
