Re: Dependency analysis through wars
Wayne Fay wrote: >> 1) Yes, transitive dependencies of a war are ignored >> 2) Yes, this is on purpose >> 3) No, this isn't going to change >> 4) You can try fiddling with components.xml, but other stuff might break >> (see #2 above) > > This "final analysis" is why I originally suggested simply changing > the War packaging to Jar for purposes of a one-time dependency > analysis... but did not realize there were "a lot" of Wars that needed > to be analyzed. > > For relatively smaller projects involving fewer Wars, this can be a > reasonable solution, especially if this is not an analysis you will be > performing on a regular basis. Actually we build all our wars with packaging type jar and use the war- plugin with an explicit execution step to produce the war as attached artifact. That way we can even in overlay scenarios inherit the original dependencies and simply exclude the jars form the overleyed wars. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency analysis through wars
> 1) Yes, transitive dependencies of a war are ignored > 2) Yes, this is on purpose > 3) No, this isn't going to change > 4) You can try fiddling with components.xml, but other stuff might break > (see #2 above) This "final analysis" is why I originally suggested simply changing the War packaging to Jar for purposes of a one-time dependency analysis... but did not realize there were "a lot" of Wars that needed to be analyzed. For relatively smaller projects involving fewer Wars, this can be a reasonable solution, especially if this is not an analysis you will be performing on a regular basis. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency analysis through wars
Just trying to close the thread... 1) Yes, transitive dependencies of a war are ignored 2) Yes, this is on purpose 3) No, this isn't going to change 4) You can try fiddling with components.xml, but other stuff might break (see #2 above) On 5/26/10 10:02 AM, Brian Fox wrote: > In theory yes but then be prepared for unexpected results. > > On Wed, May 26, 2010 at 9:50 AM, Justin Edelson > wrote: >> On 5/26/10 9:47 AM, Brian Fox wrote: >>> On Wed, May 26, 2010 at 1:57 AM, Stephen Connolly >>> wrote: On 26 May 2010 01:02, leonfranzen wrote: > > For now, my plan is to : > 1. Build the DependencyNode tree with the maven DependencyTreeBuilder for > the top-level POM > 2. Traverse the tree and find each war Node > 3. Serialize the node tree to disk > 4. Separately run the dependency node serializer on each of the war > projects > found in step 2. > 5. Deserialize all of the separate trees and assemble an aggregate > dependency node tree. > > I'll wait to see if I'm missing some sort of filter configuration that's > simply chucking out war dependency results, but I have a suspicion that > Maven just doesn't resolve transitive war dependencies and that it would > There is a components.xml that defines the war packaging. in that components.xml it says that war is not a classpath dependency type (which is correct because war files usually contain their dependencies), so the net result is that when you build the classpath from the list of dependencies, the transitive deps of war files will be ignored by design. But AFAIK dependency:tree will show those deps >>> >>> It won't because it's relying on the core resolution to build the >>> tree. Your paragraph above is otherwise exactly on the money. Maven is >>> told not to resolve war dependencies transitively. >> So theoretically, couldn't the OP crack open the uber jar, modify >> components.xml, repackage it, and then run dependency:tree? >> >> To be clear... any support email to the mailing list that begins "I >> created my own uber jar by modifying components.xml" is probably not >> going to get a lot of (helpful) feedback. >> >> Justin >> >>> > take a lot of work to make it do so. > > -- > View this message in context: > http://old.nabble.com/Dependency-analysis-through-wars-tp28672012p28674916.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > 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 >> >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency analysis through wars
In theory yes but then be prepared for unexpected results. On Wed, May 26, 2010 at 9:50 AM, Justin Edelson wrote: > On 5/26/10 9:47 AM, Brian Fox wrote: >> On Wed, May 26, 2010 at 1:57 AM, Stephen Connolly >> wrote: >>> On 26 May 2010 01:02, leonfranzen wrote: >>> For now, my plan is to : 1. Build the DependencyNode tree with the maven DependencyTreeBuilder for the top-level POM 2. Traverse the tree and find each war Node 3. Serialize the node tree to disk 4. Separately run the dependency node serializer on each of the war projects found in step 2. 5. Deserialize all of the separate trees and assemble an aggregate dependency node tree. I'll wait to see if I'm missing some sort of filter configuration that's simply chucking out war dependency results, but I have a suspicion that Maven just doesn't resolve transitive war dependencies and that it would >>> >>> There is a components.xml that defines the war packaging. in that >>> components.xml it says that war is not a classpath dependency type (which is >>> correct because war files usually contain their dependencies), so the net >>> result is that when you build the classpath from the list of dependencies, >>> the transitive deps of war files will be ignored by design. But AFAIK >>> dependency:tree will show those deps >>> >> >> It won't because it's relying on the core resolution to build the >> tree. Your paragraph above is otherwise exactly on the money. Maven is >> told not to resolve war dependencies transitively. > So theoretically, couldn't the OP crack open the uber jar, modify > components.xml, repackage it, and then run dependency:tree? > > To be clear... any support email to the mailing list that begins "I > created my own uber jar by modifying components.xml" is probably not > going to get a lot of (helpful) feedback. > > Justin > >> >>> take a lot of work to make it do so. -- View this message in context: http://old.nabble.com/Dependency-analysis-through-wars-tp28672012p28674916.html Sent from the Maven - Users mailing list archive at Nabble.com. - 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 > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency analysis through wars
On 5/26/10 9:47 AM, Brian Fox wrote: > On Wed, May 26, 2010 at 1:57 AM, Stephen Connolly > wrote: >> On 26 May 2010 01:02, leonfranzen wrote: >> >>> >>> For now, my plan is to : >>> 1. Build the DependencyNode tree with the maven DependencyTreeBuilder for >>> the top-level POM >>> 2. Traverse the tree and find each war Node >>> 3. Serialize the node tree to disk >>> 4. Separately run the dependency node serializer on each of the war >>> projects >>> found in step 2. >>> 5. Deserialize all of the separate trees and assemble an aggregate >>> dependency node tree. >>> >>> I'll wait to see if I'm missing some sort of filter configuration that's >>> simply chucking out war dependency results, but I have a suspicion that >>> Maven just doesn't resolve transitive war dependencies and that it would >>> >> >> There is a components.xml that defines the war packaging. in that >> components.xml it says that war is not a classpath dependency type (which is >> correct because war files usually contain their dependencies), so the net >> result is that when you build the classpath from the list of dependencies, >> the transitive deps of war files will be ignored by design. But AFAIK >> dependency:tree will show those deps >> > > It won't because it's relying on the core resolution to build the > tree. Your paragraph above is otherwise exactly on the money. Maven is > told not to resolve war dependencies transitively. So theoretically, couldn't the OP crack open the uber jar, modify components.xml, repackage it, and then run dependency:tree? To be clear... any support email to the mailing list that begins "I created my own uber jar by modifying components.xml" is probably not going to get a lot of (helpful) feedback. Justin > >> >>> take a lot of work to make it do so. >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/Dependency-analysis-through-wars-tp28672012p28674916.html >>> Sent from the Maven - Users mailing list archive at Nabble.com. >>> >>> >>> - >>> 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
Re: Dependency analysis through wars
On Wed, May 26, 2010 at 1:57 AM, Stephen Connolly wrote: > On 26 May 2010 01:02, leonfranzen wrote: > >> >> For now, my plan is to : >> 1. Build the DependencyNode tree with the maven DependencyTreeBuilder for >> the top-level POM >> 2. Traverse the tree and find each war Node >> 3. Serialize the node tree to disk >> 4. Separately run the dependency node serializer on each of the war >> projects >> found in step 2. >> 5. Deserialize all of the separate trees and assemble an aggregate >> dependency node tree. >> >> I'll wait to see if I'm missing some sort of filter configuration that's >> simply chucking out war dependency results, but I have a suspicion that >> Maven just doesn't resolve transitive war dependencies and that it would >> > > There is a components.xml that defines the war packaging. in that > components.xml it says that war is not a classpath dependency type (which is > correct because war files usually contain their dependencies), so the net > result is that when you build the classpath from the list of dependencies, > the transitive deps of war files will be ignored by design. But AFAIK > dependency:tree will show those deps > It won't because it's relying on the core resolution to build the tree. Your paragraph above is otherwise exactly on the money. Maven is told not to resolve war dependencies transitively. > >> take a lot of work to make it do so. >> >> -- >> View this message in context: >> http://old.nabble.com/Dependency-analysis-through-wars-tp28672012p28674916.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> - >> 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
Re: Dependency analysis through wars
On 26 May 2010 01:02, leonfranzen wrote: > > For now, my plan is to : > 1. Build the DependencyNode tree with the maven DependencyTreeBuilder for > the top-level POM > 2. Traverse the tree and find each war Node > 3. Serialize the node tree to disk > 4. Separately run the dependency node serializer on each of the war > projects > found in step 2. > 5. Deserialize all of the separate trees and assemble an aggregate > dependency node tree. > > I'll wait to see if I'm missing some sort of filter configuration that's > simply chucking out war dependency results, but I have a suspicion that > Maven just doesn't resolve transitive war dependencies and that it would > There is a components.xml that defines the war packaging. in that components.xml it says that war is not a classpath dependency type (which is correct because war files usually contain their dependencies), so the net result is that when you build the classpath from the list of dependencies, the transitive deps of war files will be ignored by design. But AFAIK dependency:tree will show those deps > take a lot of work to make it do so. > > -- > View this message in context: > http://old.nabble.com/Dependency-analysis-through-wars-tp28672012p28674916.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Dependency analysis through wars
For now, my plan is to : 1. Build the DependencyNode tree with the maven DependencyTreeBuilder for the top-level POM 2. Traverse the tree and find each war Node 3. Serialize the node tree to disk 4. Separately run the dependency node serializer on each of the war projects found in step 2. 5. Deserialize all of the separate trees and assemble an aggregate dependency node tree. I'll wait to see if I'm missing some sort of filter configuration that's simply chucking out war dependency results, but I have a suspicion that Maven just doesn't resolve transitive war dependencies and that it would take a lot of work to make it do so. -- View this message in context: http://old.nabble.com/Dependency-analysis-through-wars-tp28672012p28674916.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency analysis through wars
I don't think I can do that easily since that would require rebuilding and redeploying the modified projects as the new packaging type. Maybe I could fetch all of the dependency POMs with something like go-offline and modify them in my local repository? Yuck. I hope there is a nicer way, but I'll consider this if there are no alternatives. I'm thinking that modifying the existing dependency plugin tree builder code might be a better solution. Wayne Fay wrote: > >> at various levels are war type projects. The dependency plugin appears >> to >> stop at war projects as if they have no dependencies of their own. Does >> anyone have suggestions as to how I can build a full dependency tree, > > Could you temporarily change the packaging to "jar" for those war > projects, just to get past the issue so you could complete your > analysis, and then change them back? > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > -- View this message in context: http://old.nabble.com/Dependency-analysis-through-wars-tp28672012p28672240.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency analysis through wars
> at various levels are war type projects. The dependency plugin appears to > stop at war projects as if they have no dependencies of their own. Does > anyone have suggestions as to how I can build a full dependency tree, Could you temporarily change the packaging to "jar" for those war projects, just to get past the issue so you could complete your analysis, and then change them back? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org