Use http://mojo.codehaus.org/build-helper-maven-plugin/add-source-mojo.html to add additional source directories.
Vincent On Thu, Jul 28, 2011 at 17:15, KARR, DAVID (ATTSI) <[email protected]> wrote: > > -----Original Message----- > > From: KARR, DAVID (ATTSI) > > Sent: Thursday, July 28, 2011 7:03 AM > > To: Maven Users List > > Subject: RE: Why would "unpack-dependencies" sometimes not do its job? > > > > > -----Original Message----- > > > From: Brian Fox [mailto:[email protected]] > > > Sent: Wednesday, July 27, 2011 8:49 AM > > > To: Maven Users List > > > Subject: Re: Why would "unpack-dependencies" sometimes not do its > > job? > > > > > > default is: > > > > > > overWriteIfNewer=true > > > overWriteReleases = false > > > overWriteSnapshots=false > > > > > > Setting the releases or snapshots to true will cause it to ignore the > > > if newer check. > > > > Ok. I assume it doesn't matter if I set both to true? > > > > This change worked. > > > > I also noticed that the dependency classes were missing from > > "target/classes" just before I did the build. I think this means that > > this is being caused by m2e (Eclipse Maven plugin). I had just changed > > the flags in my pom.xml, and Eclipse built the workspace. > > I suppose the fact that m2e is clearing out "target/classes" shouldn't be > surprising, as that's my project's output directory. > > I guess it would have made sense to have "maven-dependency-plugin" write > its classes to something like "target/dependency/classes" and then make > "maven-jar-plugin" take classes from both "target/classes" and > "target/dependency/classes". Unfortunately, I'm surprised to see that > "maven-jar-plugin" can only specify one directory to pull classes from. > > > > 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] > > > > > > --------------------------------------------------------------------- > > 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] > >
