On Apr 10, 2014, at 10:07 AM, Lennart Jörelid <lennart.jore...@gmail.com> wrote:
> So ... the consequence of your approach would be that POMs throughout a
> maven reactor would have to repeat a dependency declaration if the classes
> in your maven project "directly" import a type. This - to me - seems not
> only complex to resolve in a big reactor, but quite user-unfriendly as
> well. An example shows this, I think:
It is not as, it can very hard to debug what version of a dependency you are
using which will be pull in transitively in the case there are conflicting
versions. We always recommend users declare their direct compile time
dependencies, we also recommend users declare their direct test compile time
dependencies. While I may not be a complete fan of OSGi, I share their
promotion of being as explicit as possible about what you directly require. The
resolving mechanism can be deterministic once the requirements of a particular
project is known. It's far friendlier to be able to reason about your
dependencies correctly. If you don't state them all sorts of other problems
arise.
>
> You have an API Maven project where you create class AbstractSuperType as
> follows which declares a dependency to an artifact (exemplified by the
> Logger/LoggerFactory/Membership classes):
>
> public abstract AbstractSuperType {
> protected static final Logger log =
> LoggerFactory.getLogger(Membership.class);
>
> protected AbstractSuperType(String something) {
> }
>
> ....
> }
>
> You then create an Impl project where you define a class ConcreteType as
> follows:
>
> public ConcreteType extends AbstractSuperType {
>
> public ConcreteType() { super("some text"); }
>
> private void someUtilityMethod() { log.debug("... "); }
> }
>
> As the ConcreteType extends AbstractSuperType, which uses the
> Logger/LoggerFactory/Membership classes, Maven will be required to
> synthesize a classpath including the dependencies for all three of these
> classes in order to run the unit tests - we both agree on that. If I
> understand you correctly, you suggest that Maven's mechanics to synthesize
> the test scope classpath should include all required transitive
> dependencies (in effect runtime dependencies for jUnit) - but that Maven's
> mechanics to synthesize the compile scope class path should not. This
> implies that Maven users must understand that Maven uses two different ways
> to construct its classpath in compile and test scopes. Also, the user must
> understand that the compilation fails if the someUtilityMethod is added to
> the ConcreteType - because you would now be required to add a dependency to
> the Impl project as well.
>
> I find it more usable to simply use the same mechanics to synthesize class
> path in compile and test scopes, implying that transitive dependencies are
> included in the respective class path without any extra pom dependencies
> being added to parent and child projects.
I'm not recommending classpaths used different mechanisms, I'm not sure where
in the thread you inferred otherwise. The issue I started this thread with is a
very specific issue that applies to handful of plugins in the Maven ecosystem
that non-declaratively and programmatically push dependencies into a project.
>
>
>
> 2014-04-08 2:21 GMT+02:00 Mark Derricutt <m...@talios.com>:
>
>> On 7 Apr 2014, at 19:37, Lennart Jörelid wrote:
>>
>> I don't understand the difference between what you suggest here, Mark, and
>>> simply disabling transitive dependencies.
>>> Could you elaborate somewhat?
>>>
>>
>> Well, the basics are:
>>
>> * When compiling code, all I need to do is satisfy the contracts my
>> dependencies interfaces/public signatures. If my code fails to compile due
>> to some absent dependency ( note, this is different from a non-resolvable,
>> declared dependency ), then I should go an add a `<dependency/>` element to
>> my pom.
>> * When running tests however, you require the transitive dependencies on
>> the classpath so the upstream code _actually works_.
>> * When packaging for distribution, you require the transitives for a
>> running solution.
>>
>>
>>
>
>
> --
>
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: l...@jguru.se
> | URL: www.jguru.se
> | Phone
> | (skype): jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
I never make the mistake of arguing with people for whose opinions I have no
respect.
-- Edward Gibbon
