Hum, Adding <overWriteIfNewer>false</overWriteIfNewer> does not help either. The behavior I am seeing is that it always overwrites.
-Dave On Tue, Aug 4, 2009 at 12:49 PM, David Hoffer <[email protected]> wrote: > 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] >> >> >
