You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by leonfranzen <le...@tvworks.com> on 2010/05/25 20:48:49 UTC
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency analysis through wars
Posted by Jörg Schaible <jo...@gmx.de>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency analysis through wars
Posted by Wayne Fay <wa...@gmail.com>.
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency analysis through wars
Posted by Justin Edelson <ju...@gmail.com>.
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 <ju...@gmail.com> wrote:
>> On 5/26/10 9:47 AM, Brian Fox wrote:
>>> On Wed, May 26, 2010 at 1:57 AM, Stephen Connolly
>>> <st...@gmail.com> wrote:
>>>> On 26 May 2010 01:02, leonfranzen <le...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency analysis through wars
Posted by Brian Fox <br...@infinity.nu>.
In theory yes but then be prepared for unexpected results.
On Wed, May 26, 2010 at 9:50 AM, Justin Edelson <ju...@gmail.com> wrote:
> On 5/26/10 9:47 AM, Brian Fox wrote:
>> On Wed, May 26, 2010 at 1:57 AM, Stephen Connolly
>> <st...@gmail.com> wrote:
>>> On 26 May 2010 01:02, leonfranzen <le...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency analysis through wars
Posted by Justin Edelson <ju...@gmail.com>.
On 5/26/10 9:47 AM, Brian Fox wrote:
> On Wed, May 26, 2010 at 1:57 AM, Stephen Connolly
> <st...@gmail.com> wrote:
>> On 26 May 2010 01:02, leonfranzen <le...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency analysis through wars
Posted by Brian Fox <br...@infinity.nu>.
On Wed, May 26, 2010 at 1:57 AM, Stephen Connolly
<st...@gmail.com> wrote:
> On 26 May 2010 01:02, leonfranzen <le...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency analysis through wars
Posted by Stephen Connolly <st...@gmail.com>.
On 26 May 2010 01:02, leonfranzen <le...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Dependency analysis through wars
Posted by leonfranzen <le...@tvworks.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency analysis through wars
Posted by leonfranzen <le...@tvworks.com>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency analysis through wars
Posted by Wayne Fay <wa...@gmail.com>.
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org