Yes, I realize what Mark was referring to - but I still cannot see the
point in having to repeat oneself WRT importing an already imported
compile-scope dependency in all projects where it would be used. This would
imply loads of redundant imports in all dependent poms in a multi-module
reactor along the lines of:
<dependency>
<groupId>a.project.a.domain</groupId>
<artifactId>mydomain-model</artifactId>
</dependency>
I would claim the contrary position to Mark's - I would not want to litter
all poms in the reactor with the dependency above just because it is
imported in a project onto which several/most/all other projects in the
reactor depends. This approach violates the DontRepeatYourself principle
quite a lot. Moreover, since the dependency *is* required to get the
dependent projects to run properly I can see quite a few reasons why it
would break existing builds. Simply passing a type from the mydomain-model
as an argument to a method in a publicly available interface implies that
the mydomain-model project is required transitively.
Moreover - I find the dependency mechanism broken in the other direction
compared to Mark's view; presently we have to repeat all provided-scope
depedencies in the reactor since they are not transitively spread as
dependencies to importing projects. Loads of unnecessary POM repetition
follows, which is less than ideal since the POM can get quite bloated as
is. I would rather suggest that we need new transitive scope semantics for
provided-scope dependencies to prevent us from unnecessarily repeating
these several times in a multimodule reactor.
Thus ... I'm asking because I assume that Mark sees something I have missed
in the pom transitivity mechanism, and I want to know what that might be.
2014-04-07 9:42 GMT+02:00 Anders Hammar <and...@hammar.net>:
> I believe he's talking about what's mentioned here (see the asterix):
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>
> /Anders
>
>
> On Mon, Apr 7, 2014 at 9:37 AM, Lennart Jörelid
> <lennart.jore...@gmail.com>wrote:
>
> > I don't understand the difference between what you suggest here, Mark,
> and
> > simply disabling transitive dependencies.
> > Could you elaborate somewhat?
> >
> >
> > 2014-04-07 3:41 GMT+02:00 Mark Derricutt <m...@talios.com>:
> >
> > > On 7 Apr 2014, at 12:32, Benson Margulies wrote:
> > >
> > > We then have other logical classpaths. . Something like javadoc should
> > >> be able to define another named classpath structure; combining the
> > >> dependencies of the plugin's implementation with dynamic code
> > >> (doclets, whatever) seems like a category confusion to me.
> > >>
> > >
> > > If we change/break this - can we PLEASE make the compilation path
> IGNORE
> > > transitive dependencies of 'compile' dependencies - if I -need- it to
> > > compile, -I- should depend on it up front.
> > >
> > >
> > > Mark
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> >
> > --
> >
> > --
> > +==============================+
> > | 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
> > +==============================+
> >
>
--
--
+==============================+
| 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
+==============================+
