Dependency scope for compile -- what should be included?

[Jim Christenson <ji...@wolterskluwer.com>]

I need some help understanding how the dependency resolution works and why. 
I have read the documentation on the various scopes and want to know what
the best practice is for listing project dependencies.

I am working with a project that uses a number of external libraries. 
However, the tech-lead on this project doesn't want to list the "common"
libraries as dependencies in his project.  An example is log4j.  His
argument is that log4j is included in several of the other libraries he is
using.  From a build perspective I would expect that if the code imports an
external class that it should be listed as a direct dependency.  This would
lead me to think that the compile classpath should only have the direct
dependencies listed and not the transitive dependencies (this would fail a
build and force all of the dependencies to be claimed).  As it stands right
now if log4j is in the transitive dependency list everything compiles and
the dependency report makes it look like we don't directly use this library.

Is there a way to force this, or is there some other tool/report that would
look at the code and show the gaps?

Is this valid or am I missing something here?

Thank you in advance for any insights to help my understanding...

Jim
-- 
View this message in context: http://www.nabble.com/Dependency-scope-for-compile----what-should-be-included--tp16300807s177p16300807.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 scope for compile -- what should be included?

[Wendy Smoak <ws...@gmail.com>]

On Wed, Mar 26, 2008 at 6:09 AM, Jim Christenson
<ji...@wolterskluwer.com> wrote:

>  Is there a way to force this, or is there some other tool/report that would
>  look at the code and show the gaps?

mvn dependency:analyze

Analyzes the dependencies of this project and determines which are:
used and declared; used and undeclared; unused and declared.

http://maven.apache.org/plugins/maven-dependency-plugin/usage.html

-- 
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dependency scope for compile -- what should be included?

["simon.kitching@chello.at" <si...@chello.at>]

Hi Jim,

Jim Christenson schrieb:
> I need some help understanding how the dependency resolution works and why. 
> I have read the documentation on the various scopes and want to know what
> the best practice is for listing project dependencies.
>
> I am working with a project that uses a number of external libraries. 
> However, the tech-lead on this project doesn't want to list the "common"
> libraries as dependencies in his project.  An example is log4j.  His
> argument is that log4j is included in several of the other libraries he is
> using.  From a build perspective I would expect that if the code imports an
> external class that it should be listed as a direct dependency.  This would
> lead me to think that the compile classpath should only have the direct
> dependencies listed and not the transitive dependencies (this would fail a
> build and force all of the dependencies to be claimed).  As it stands right
> now if log4j is in the transitive dependency list everything compiles and
> the dependency report makes it look like we don't directly use this library.
>
> Is there a way to force this, or is there some other tool/report that would
> look at the code and show the gaps?
>
> Is this valid or am I missing something here?
>
> Thank you in advance for any insights to help my understanding...
>
> Jim
>   
Do you mean that your code has
   import org.apache.log4j.Log;
and your pom does not have a dependency on log4j, but still compiles
because log4j is a transient dependency?

That would be "bad style" in my opinion; direct dependencies should be
declared.

But I don't know of any tool that would help to detect situations like
that; the tool would need to actually scan the local source code to find
out which classes are referenced, then scan the list of direct
dependencies and verify that each referenced class can be found in a
direct dependency. Possible, but not easy.


Regards,
Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org