Re: Dependency analysis through wars
On Wed, May 26, 2010 at 1:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 26 May 2010 01:02, leonfranzen leon_fran...@tvworks.com 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 5/26/10 9:47 AM, Brian Fox wrote: On Wed, May 26, 2010 at 1:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 26 May 2010 01:02, leonfranzen leon_fran...@tvworks.com 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
In theory yes but then be prepared for unexpected results. On Wed, May 26, 2010 at 9:50 AM, Justin Edelson justinedel...@gmail.com wrote: On 5/26/10 9:47 AM, Brian Fox wrote: On Wed, May 26, 2010 at 1:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 26 May 2010 01:02, leonfranzen leon_fran...@tvworks.com 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
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 justinedel...@gmail.com wrote: On 5/26/10 9:47 AM, Brian Fox wrote: On Wed, May 26, 2010 at 1:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 26 May 2010 01:02, leonfranzen leon_fran...@tvworks.com 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
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
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
Dependency analysis through wars
I'm trying to perform an analysis of the entire dependency tree for a large set of projects with deep transitive dependencies. Some of the dependencies 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, including war dependencies and their transitive dependencies? I'm not opposed to building a custom plugin, but advice regarding how it should be done would be very welcome. Thanks. -- View this message in context: http://old.nabble.com/Dependency-analysis-through-wars-tp28672012p28672012.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
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
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
On 26 May 2010 01:02, leonfranzen leon_fran...@tvworks.com 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
