maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lennart Jörelid <lennart.jore...@gmail.com>
Subject Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
Date Thu, 10 Apr 2014 14:07:29 GMT
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:

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.



2014-04-08 2:21 GMT+02:00 Mark Derricutt <mark@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: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message