Hi Ron...

yes I understood your point.. but some days ago I tried to compile a
project like this:

prj.a:
public class A extends B{}

prj.b:
public class B extends C{}

prj.c:
public class C{}

where their pom are:

prj.a -> prj.b (provided scope)

prj.b -> prj.c (provided scope)


is strange... but the build fails because A extends B and A needs to
know also C at compile time..

Could you try to compile my example?

thank a lot...

regards
--
Marco Speranza <marcospera...@apache.org>
Google Code: http://code.google.com/u/marco.speranza79/


2012/7/18 Ron Wheeler <rwhee...@artifact-software.com>:
> On 18/07/2012 12:23 PM, Marco Speranza wrote:
>>
>> Hi
>>
>> thanks for your reply... I read the maven dependency mechanism and I
>> understud how it's works...
>>
>> The definition of  'provided' scope is that "is only available on the
>> compilation and test classpath" and the user should provide the
>> dependency at runtime.
>> And the definition of 'runtime' scopoe is that "the dependency is not
>> required for compilation"
>>
>> so my question is: why the provided transitive dependency is NOT
>> included in 'compile' classpath and the 'runtime' transitive
>> dependency IS included in the compile classpath?
>>
>> Furthermore IMHO this behavior could break some builds (see my little
>> example) because if the project A needs B at compile time and the
>> project B needs C at compile time.. for the 'transitivity' theorem
>> also A might need of C at compile time, isn't it?.
>
>
> Why would the compiler even care about C when compiling A?
> It only has references to B that it needs to resolve.
> Lets say that I use Apache's log4j. My code only refers to log4j objects and
> my code does not have any references to the objects that log4j uses.
>
> At runtime, my code will run just fine as long as the log4j.jar has in it
> all of the things that log4j requires to perform its functions.
>
> Remember:
> The current system works for thousands of projects every day with tens of
> thousands of developers using "provided" and "compile" scopes successfully.
>
>
> Ron
>
>
>>
>> thanks
>> ciao
>> --
>> Marco Speranza <marcospera...@apache.org>
>> Google Code: http://code.google.com/u/marco.speranza79/
>>
>>
>> 2012/7/18 abhijith tn <abhijit...@gmail.com>:
>>>
>>> Hi Marco,
>>>
>>> It is very simple. Maven stops searching for the dependency when it finds
>>> provided scope and maven assumes the dependency will be provided
>>> externally. Best example being server library jars like servlet-api jar.
>>>
>>> Below link will give you clear picture
>>>
>>>
>>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>>>
>>> On Tue, Jul 17, 2012 at 2:44 PM, Marco Speranza
>>> <marcospera...@apache.org>wrote:
>>>
>>>> Hi all...
>>>>
>>>> a friend of mine and I have experienced a compilation error when we
>>>> have tried to compile this project:
>>>>
>>>> prj.a:
>>>> public class A extends B{}
>>>>
>>>> prj.b:
>>>> public class B extends C{}
>>>>
>>>> prj.c:
>>>> public class C{}
>>>>
>>>> where their pom are:
>>>>
>>>> prj.a -> prj.b (provided scope)
>>>>
>>>> prj.b -> prj.c (provided scope)
>>>>
>>>> our compilation fails because C is not included in A's compile
>>>> classpath as shown in the table [1]
>>>>
>>>> My question is... why the transitive 'provided' dependencies of a
>>>> 'provided' dependency are not transitive and the transitive
>>>> *'runtime'* dependencies of a 'provided' dependency is transitive?
>>>>
>>>> IMHO would be better that provided dependencies are transitive and
>>>> runtime dependencies not, it isn't?
>>>>
>>>>
>>>> have a nice day... :-)
>>>>
>>>>
>>>> [1]:
>>>>
>>>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>>>>
>>>>
>>>> --
>>>> Marco Speranza <marcospera...@apache.org>
>>>> Google Code: http://code.google.com/u/marco.speranza79/
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
> ---------------------------------------------------------------------
> 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

Reply via email to