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 <tobr...@discursive.com> wrote: > On Tue, Aug 4, 2009 at 1:25 PM, David Hoffer<dhoff...@gmail.com> 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 <tobr...@discursive.com> > wrote: > > > >> On Tue, Aug 4, 2009 at 1:01 PM, David Hoffer<dhoff...@gmail.com> 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 <tobr...@discursive.com> > >> wrote: > >> > > >> >> On Tue, Aug 4, 2009 at 9:25 AM, David Hoffer<dhoff...@gmail.com> > 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: users-unsubscr...@maven.apache.org > >> >> For additional commands, e-mail: users-h...@maven.apache.org > >> >> > >> >> > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >