> >4) Create "optional" scope. Rely on repository POM to set this
> >proeprly. Add "inclusions" for optionally-scoped jars that mirrors
> >exclusions for currently passed along jars.
> >
> >
> Inclusions is really just a less agressive version of (2). It is more
> verbose than (1) in the case where the dependencies are correct > 50% of
> the time. So if we fix the biggest offenders, (1) remains the best solution.
>
> As above, if the repository were correct you wouldn't need this yourself.
>
> Brett
Sorry, I don't think I was clear in what I want. I'm not talking
about inclusions INSTEAD of optional scope. I'm talking about where
you specify the optional dependency. Now that I realize that you'd
have to specify the scope too, I'm not sure if it's worth it to do it
this way. I guess the greatest advantage would getting the version
number of the transitive dependency right. Here's the two ways to do
it.
How I think you're suggesting:
<dependencies>
<dependency>
<groupId>springframework</groupId>
<artifactId>spring-hibernate</artifactId>
<version>2.5</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>net.sf.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>2.1.8</version>
<scope>provided</scope>
</dependency>
</dependencies>
Whereas my suggestion was:
<dependencies>
<dependency>
<groupId>springframework</groupId>
<artifactId>spring-hibernate</artifactId>
<version>2.5</version>
<scope>compile</scope>
<inclusions>
<inclusion>
<groupId>net.sf.hibernate</groupId>
<artifactId>hibernate</artifactId>
<scope>provided</scope>
</inclusion>
</inclusions>
</dependency>
</dependencies>
As you can see, the only advantage here is that you wouldn't specify
the version of the optionally-scoped dependency, because you'd get
that transitively from the main dependency. It may not be worth the
confusion, trouble, etc. My experience is quite limited, so I really
couldn't say on the tradeoffs. But I did just want to make sure that
what I was suggesting is clear so that you can decide properly on it.
For the short term, the latest version of Spring in the repository
simply doesn't define dependencies anymore as far as I can tell, which
gets rid of most of my current problems, so I can now be fully behind
waiting to get the repository to 80%. :) (Random side note: does
getting the repository up-to-date also involve getting projects like
spring and the commons-* to change the groupId to a package-like name,
and at what point do you get rid of the old name, since several exist
both ways, which is confusing in getting people to go to a "right"
way?)
--
Stephen Duncan Jr
www.stephenduncanjr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
