default is: overWriteIfNewer=true overWriteReleases = false overWriteSnapshots=false
Setting the releases or snapshots to true will cause it to ignore the if newer check. On Wed, Jul 27, 2011 at 11:13 AM, KARR, DAVID (ATTSI) <[email protected]> wrote: >> -----Original Message----- >> From: Brian Fox [mailto:[email protected]] >> Sent: Tuesday, July 26, 2011 5:01 PM >> To: Maven Users List >> Subject: Re: Why would "unpack-dependencies" sometimes not do its job? >> >> you can set a flag to tell it to always unpack. I forget the exact >> param, but it's in the docs. > > I just checked the doc page for "dependency:unpack-dependencies" and there's > no flag I can see that does this. > >> On Tue, Jul 26, 2011 at 5:01 PM, KARR, DAVID (ATTSI) <[email protected]> >> wrote: >> >> -----Original Message----- >> >> From: GALLAGHER, RON (ATTSI) >> >> Sent: Tuesday, July 26, 2011 12:03 PM >> >> To: Maven Users List >> >> Subject: RE: Why would "unpack-dependencies" sometimes not do its >> job? >> >> >> >> David, >> >> >> >> When the dependency plugin unpacks an artifact, it puts a marker >> file >> >> in >> >> the 'markersDirectory' [1] so that it doesn't unpack that same >> artifact >> >> a second time. >> >> >> >> When you run "mvn clean", that 'markersDirectory' is cleared out, >> along >> >> with all other build output. >> >> >> >> Is it possible that the absence of classes from your dependent jar >> >> files >> >> is due to the presence of one or more marker files in the >> >> 'markersDirectory' that were placed there during the previous build? >> > >> > Ok, it happened again. All the marker files are present, but >> "target/classes" doesn't have the dependent classes. I'll watch to see >> if something else after this removes things from that tree. >> > >> >> [1] >> >> http://maven.apache.org/plugins/maven-dependency-plugin/unpack- >> >> dependenc >> >> ies-mojo.html#markersDirectory >> >> >> >> Ron Gallagher >> >> >> >> >> >> -----Original Message----- >> >> From: KARR, DAVID (ATTSI) >> >> Sent: Tuesday, July 26, 2011 1:02 PM >> >> To: [email protected] >> >> Subject: Why would "unpack-dependencies" sometimes not do its job? >> >> >> >> I'm using both "maven-dependency-plugin" and "maven-jar-plugin" so >> all >> >> of my application classes and dependent classes go into a single jar >> >> file. Every once in a while I discover that the resulting jar file >> >> doesn't have my dependent classes. If I then do "mvn clean" and >> then >> >> "mvn" (default goal of install), it works fine. At the time it's >> >> happened, I didn't have the presence of mind to check my >> >> "target/classes" directory to verify it was "maven-dependency- >> plugin" >> >> that failed to do its work. As the job of "maven-jar-plugin" is >> much >> >> simpler, I don't think it's likely this is the problem. >> >> >> >> My plugin configs follow this. >> >> >> >> Any ideas why this might be happening? >> >> >> >> ------------------ >> >> <plugin> >> >> <groupId>org.apache.maven.plugins</groupId> >> >> <artifactId>maven-dependency-plugin</artifactId> >> >> <version>2.3</version> >> >> <executions> >> >> <execution> >> >> <id>copy</id> >> >> <phase>prepare-package</phase> >> >> <goals> >> >> <goal>unpack-dependencies</goal> >> >> </goals> >> >> <configuration> >> >> <includeScope>compile</includeScope> >> >> <excludeScope>test</excludeScope> >> >> >> >> <outputDirectory>target/classes</outputDirectory> >> >> </configuration> >> >> </execution> >> >> </executions> >> >> </plugin> >> >> <plugin> >> >> <groupId>org.apache.maven.plugins</groupId> >> >> <artifactId>maven-jar-plugin</artifactId> >> >> <version>2.3.1</version> >> >> <configuration> >> >> <classesDirectory>target/classes</classesDirectory> >> >> <archive> >> >> <manifest> >> >> >> <mainClass>mypackage.MyClass</mainClass> >> >> >> >> >> <addDefaultImplementationEntries>true</addDefaultImplementationEntries> >> >> </manifest> >> >> </archive> >> >> </configuration> >> >> </plugin> >> >> ------------------ >> >> >> >> -------------------------------------------------------------------- >> - >> >> 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] >> > >> > >> >> --------------------------------------------------------------------- >> 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]
