You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Colin Sampaleanu <co...@exis.com> on 2005/05/30 00:39:09 UTC
How does Maven 2 handle compile-only dependency
I was taking a look at the description of the Scope support in Maven 2:
http://maven.apache.org/maven2/dependencies.html
but am confused as to hove Maven 2 handles dependencies which are needed
only for compiling, but _not_ at runtime.
Consider the example of the servlet apis (or really any other J2EE api
provided by the servlet container). To compile an app deployed in a
servlet container, you need servlet-api.jar to be around for the
compile. But any war file (or EAR file) you deploy into the container,
should not include the API jar.
None of the scopes seem to make sense. If it's put into 'compile' scope,
then it's also supposed to be available in the runtime classpath, and I
presume this means it will be bundled with the artifact. On the other
hand, if it's marked in the 'runtime' or 'test' scope, then it won't be
available for the compile classpath.
Unless I'm missing something, it seems like there should really be a
'compile-only' scope, or the 'compile' scope should actually be for
compile-only.
Any thoughts?
Regards,
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How does Maven 2 handle compile-only dependency
Posted by Brett Porter <br...@apache.org>.
Colin Sampaleanu wrote:
> I will say I don't agree with your statement in one of those messages
> that in a container deployment, the fact that the container APIs are
> provided by the container doesn't mean the code still doesn't have a
> dependency on the servlet apis (and presumably still needs to be
> declared).
You've lost me. Too many doesn't for me to parse :)
> Personally, for that scope for that api, I certainly do consider
> bundling requirements = dependency declaration. There is no difference
> in my mind in the fact that those APIs are being provided by the J2EE
> environment from the fact that in a standard J2SE environment some
> other arbitrary API is provided by the J2SE runtime. It's standard and
> built-in, and for _that_ environment, not a real dependency any more
> as far as a build tool is concerned. Now if you do need to build or
> use the same code in environments (other JDK versions or a build/test
> running outside of the container) where those APIs are not available,
> that's another matter. The APIs (or Jar implementing them) are a
> dependency for those environments.
I think this later statement clarifies it - so you think that because
the container provides it, the code no longer has an explicit dependency
on the servlet api (I'll use this specifically though it applies to any
such example), but an implicit one that you can assume will always be
present.
The problem with this is that when you get into transitive dependencies,
you are now making that assumption for every project that depends on
yours. Probably not a big deal in the servletapi example, but certainly
in the j2se case. If you go down that path, you also need to describe
what your other assumptions are as well (which is entirely possible with
Maven's proposed profiles for the JDK case, or for building an artifact
for weblogic which requires different jars I hear).
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How does Maven 2 handle compile-only dependency
Posted by Colin Sampaleanu <co...@exis.com>.
I found some of the discussion in "Re: [jira] Commented: (MNG-415) allow
exclusion of certain depend encies from inclusion in an archive". Some
interesting stuff. I will say I don't agree with your statement in one
of those messages that in a container deployment, the fact that the
container APIs are provided by the container doesn't mean the code still
doesn't have a dependency on the servlet apis (and presumably still
needs to be declared). Personally, for that scope for that api, I
certainly do consider bundling requirements = dependency declaration.
There is no difference in my mind in the fact that those APIs are being
provided by the J2EE environment from the fact that in a standard J2SE
environment some other arbitrary API is provided by the J2SE runtime.
It's standard and built-in, and for _that_ environment, not a real
dependency any more as far as a build tool is concerned. Now if you do
need to build or use the same code in environments (other JDK versions
or a build/test running outside of the container) where those APIs are
not available, that's another matter. The APIs (or Jar implementing
them) are a dependency for those environments.
Colin
Colin Sampaleanu wrote:
> Thanks Brett,
>
> These days I don't normally track the discussion on a daily basis on
> the dev or user lists, so had not see any, in a cursory look.
> Filtering on 'scope' in the subject I've found "A dependency with
> compile scope in pom.xml still adds jar to war lib in m2?", but that's
> not really a discussion of options. Pointers to any threads of
> relevance are certainly appreciated, especially the one where you say
> you listed the downsides.
>
> I'm currently working on setting up some standard scope equivalents
> for some Ivy based projects (where scopes or something like them are
> called configurations, and there are an infinite number of them
> definable, although that doesn't make things necessarilly clearer). I
> am very much interested in coming up with something that is directly
> translatable to Maven 2, since at a minimum people will also want to
> use the projects from Maven 2, and additionally, who knows, people
> might also want to compile them with Maven 2. There's no sense with
> going with something incompatible, if something compatible can be
> figured out.
>
> When you bring in the optional need for some things in different JDK
> environments (saw some mention on this in a maven user thread talking
> about profiles) the options get pretty varied and complicated. Punting
> on the JDK version variances, at a minimum it seems like the scopes
> that would work are:
>
> runtime: added to compile time, test-test, and runtime classpaths
> (latter implies bundling)
> compile-only: in addition to runtime dependencies. added to
> compile-time and unit-test classpaths, but not runtime (the latter
> does not imply the container does not make these available, just that
> the build does not bundle them)
> test: in additon to runtime and compile-only dependencies. added to
> test classpath.
>
> The compile-only should almost better be called buildtime, since it's
> really available for both compile and test portion of a build. This is
> the scope that is different from Maven 2.
>
> This would work for most projects. If something produces both a web
> app and a standalone jar file, and it's desired to have one scope that
> includes all the dependencies for this (probably a good thing) then
> there would probably be a need for a 'standalone' scope that would
> include the runtime stuff as well as some stuff that would normally be
> only in compile-only for the web build.
>
> In Ivy, you can define any number of scopes, and they can inherit from
> each other, so ultimately I can model any set of dependencies I want,
> but I would rather not go with something that's too complicated, or
> with something that doesn't have a decent translation to Maven 2...
>
> One point; I think it's a bit of a mistake to go to exclusion on a
> per-plugin basis. There is something (to me) very attractive about
> being able to summarize dependencies for artifacts in terms of simple
> scopes (or groups of scopes) or configs or groups of configs in Ivy,
> and leaving it at that, without brining in plugins into the picture.
> This make it pretty much easier to switch between different dependency
> handling systems.
>
> Regards,
> Colin
>
> Brett Porter wrote:
>
>> Colin,
>>
>> This has been discussed recently on both the user and dev lists, and
>> there are pros and cons to both approaches.
>>
>> This is the case of servlet API/J2EE, and perhaps some libraries
>> provided by the final JDK but not compiling JDK. It's not that they
>> are compile-only - it's that they -may- be provided for you at
>> runtime. They are still required at runtime.
>>
>> All we really need to change is to ensure:
>> - they are not bundled when they target an environment where it will
>> be provided (always the case for servlet/J2ee/etc type JARs).
>> - they are not used from plugins where the plugin provides them (eg,
>> mock servlet api tests)
>>
>> Current options seem to be:
>> - a "container" scope that implies compile, runtime and test, but can
>> be excluded easily from bundling
>> - exclusions on a per plugin basis
>> * a full implementation of specification dependencies would allow
>> the plugins to exclude based on the specifications by default
>> * this is a bit limited as you would always have to add weblogic
>> specific ones, for example
>> - change to independant scopes which is more or less what you are
>> proposing
>> * I've listed a couple of downsides to this previously
>>
>> I'll add it to the agenda for the (hopefully final) IRC meeting
>> tonight. Anyone is welcome to attend, or attach your comments in
>> advance to the wiki page which I'll have up shortly.
>>
>> Thanks,
>> Brett
>>
>> Colin Sampaleanu wrote:
>>
>>> I was taking a look at the description of the Scope support in Maven 2:
>>> http://maven.apache.org/maven2/dependencies.html
>>> but am confused as to hove Maven 2 handles dependencies which are
>>> needed only for compiling, but _not_ at runtime.
>>>
>>> Consider the example of the servlet apis (or really any other J2EE
>>> api provided by the servlet container). To compile an app deployed
>>> in a servlet container, you need servlet-api.jar to be around for
>>> the compile. But any war file (or EAR file) you deploy into the
>>> container, should not include the API jar.
>>>
>>> None of the scopes seem to make sense. If it's put into 'compile'
>>> scope, then it's also supposed to be available in the runtime
>>> classpath, and I presume this means it will be bundled with the
>>> artifact. On the other hand, if it's marked in the 'runtime' or
>>> 'test' scope, then it won't be available for the compile classpath.
>>>
>>> Unless I'm missing something, it seems like there should really be a
>>> 'compile-only' scope, or the 'compile' scope should actually be for
>>> compile-only.
>>>
>>> Any thoughts?
>>>
>>> Regards,
>>> Colin
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
--
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How does Maven 2 handle compile-only dependency
Posted by Brett Porter <br...@apache.org>.
Colin Sampaleanu wrote:
>
> Well you may be making the distinction between scopes and profiles,
> but for some cases it seems to me to be a rather arbitrary difference,
> and Ivy's configurations at least can to a decent extent be used for
> both.
I'm not sure about that - I think we've got both scope and profiles
pretty well nailed down and its clear which does which. Profiles go
beyond just dependencies. Maven, last time I checked, did a few more
things than dependency management ;)
>
> Well, examples is probably the best I can contribute here, more than
> answers :-). I'm actually looking for the latter, or at least trying
> to arrive at some sort of best-practice answers.
Absolutely, we've got the same aims. Thanks for taking the time to talk
it through - its given me a few extra points to help us get it resolved
in our next design conference.
>
> But aside from these, I guess the question is how you handle/declare
> optional dependencies. Take Spring Framework for exmaple, near and
> dear to my heart.
It's a good example.
> So it would be nice for the dependency sytem to allow the library
> creator (us, the Spring developers in this case) to come up with
> certain standard configs or dependency declarations that people can
> use as-is, but is it even realistic to think this can be done, given
> the actual complex dependency requirements?
As far as I can tell, absolutely. This is the reason that Maven keeps
demanding separate projects to build different artifacts. The code only
appears once, and then you can repackage it into all those other JARs,
with a POM that represents exactly what that particular JAR depends on.
> For something like spring-hibernate.jar for example, in the Ivy case
> (not even thinking about Maven), about all I can think of doing is
> exposing a config which pulls in all the optional Hibernate
> dependencies, and then people can (easily) exclude stuff they know
> they don't actually need, and another one which pulls in only
> Hibernate and any other deps which will always be needed, and then
> people using that can add stuff they know they actually need.
This is the only viable choice. The user can only select the dependency
at the granularity you've given them (ie, spring-hibernate + all the
hibernate dependencies you've used in there, whether they use them or
not). Then, they can filter out the ones they don't want. We're
discussing a way to do this in the Maven POM right now because to be
realistic, it will happen - but the ideal is that you can just as
easilly split your functionality along the same lines
(spring-hibernate-core, spring-hibernate-jta as well as an aggregated
spring-hibernate) but this starts getting impossible at the 3rd or 4th
level of depedency too.
Anyway, its good that spring is thinking about it in these terms rather
than lumping it all together as the only way which seems to be popular
elsewhere. Its great to have that as a distribution channel, but its
nice to have a choice. For the end project, it is easiest for them
manage their project the less they have to depend on - but that doesn't
mean fewer dependant jars, but more concise ones if you get my drift
(and I have indeed drifted there).
> In the Maven case, where there is no idea (last I checked) of
> user-defined scopes, I wouldn't know how to offer even this level of
> control.
No, its not necessarily about definable scopes. I'm looking at explicit
blocking of certain dependencies and their dependencies. We have a
dependency management section that should be used for that.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How does Maven 2 handle compile-only dependency
Posted by Colin Sampaleanu <co...@exis.com>.
Brett Porter wrote:
> Colin Sampaleanu wrote:
>
>> There are some creative ways to get flexible and less verbose with
>> scopes. In Ivy for example, scopes can inherit from each other, first
>> of all. Secondly, when declaring configs (scopes) of dependencies
>> that you need, and declaring configs (scopes) that you expose, you
>> can use a verbose notation with subelements and the like, but you can
>> also use a short-form, so
>
>
> This is the same discussion trap Xavier and I fell into - scopes
> aren't the same as configurations. configurations are actually much
> more like Maven profiles, which are both additive and inherited.
>
> Scope is meant to describe the use of the dependency through build
> lifecycle, and how that is managed transitively. Profiles are meant to
> handle the environmental differences. I'm a bit concerned that the
> water is getting muddied between the two, so I would like to get it
> resolved - there just seems to be this one area of overlap between the
> target environment and the build cycle.
Well you may be making the distinction between scopes and profiles, but
for some cases it seems to me to be a rather arbitrary difference, and
Ivy's configurations at least can to a decent extent be used for both.
However in Ivy it's true there is no idea of standardized optional
transitive (flow-through) configs for handling environment such as a JDK
level. Ie while the dependency model is quite powerful, without
standardized profiles for things like the JDK level, you can't really do
something like say, I need Spring Framework, and need it in a JDK 1.4
environment, and so its dependencies should be only those for JDK 1.4,
and the dependencies of the dependencies should only be those for JDK
1.4. You can only do this when the entire dependency chain has taken
this need into consideration and exposed the right configs (additive to
others or total) for that environment. That said, it's pretty easy to
include or exclude certain dependencies as needed.
>
>> While the Ivy dependency capabilities may seem like overkill to some
>> people, my feeling is that only when you get to this level can you
>> realistically express the dependency requirements of 99% of the
>> projects out there (as opposed to 90% or 95% or something like that).
>
>
> I'd be happy to work through specific examples, because I'm more
> interested in finding the problem before the solution :) We've been
> very careful in m2 to start with the bare minimum that covers all the
> use cases people have brought up over the life of m1, to keep it as
> simple as possible.
Well, examples is probably the best I can contribute here, more than
answers :-). I'm actually looking for the latter, or at least trying to
arrive at some sort of best-practice answers. Ultimately, there are easy
to find examples of the requirement to designate dependencies as needed
for compile +test +runtime (runtime==bundling), compile +test -runtime
(not needed at all at runtime, or container/environment provides them),
test only, runtime only, and compile only (this one is less common).
These are all pretty obvious, the "compile +test -runtime" case is the
servlet-api.jar one, or really any other API provided by the container.
But aside from these, I guess the question is how you handle/declare
optional dependencies. Take Spring Framework for exmaple, near and dear
to my heart. You can use it as spring.jar, which includes the kitchen
sink, but there are a large amount of variable options depending on what
parts of Spring you actually use. Even within one area, such as
Hibernate integration, there are a number of variable options. If you
deploy Hibernate in a JTA environment or do certain types of caching, or
use a certain connection pool, you may need certain dependencies,
otherwise others. If you deploy Spring as the granular jars like
spring-core.jar, spring-hibernate.jar, etc., then it becomes simpler,
but you still have a number of optional transitive dependencies (such as
the Hibernate ones, for example). So it would be nice for the dependency
sytem to allow the library creator (us, the Spring developers in this
case) to come up with certain standard configs or dependency
declarations that people can use as-is, but is it even realistic to
think this can be done, given the actual complex dependency
requirements? For something like spring-hibernate.jar for example, in
the Ivy case (not even thinking about Maven), about all I can think of
doing is exposing a config which pulls in all the optional Hibernate
dependencies, and then people can (easily) exclude stuff they know they
don't actually need, and another one which pulls in only Hibernate and
any other deps which will always be needed, and then people using that
can add stuff they know they actually need. In the Maven case, where
there is no idea (last I checked) of user-defined scopes, I wouldn't
know how to offer even this level of control.
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How does Maven 2 handle compile-only dependency
Posted by Brett Porter <br...@apache.org>.
Colin Sampaleanu wrote:
> There are some creative ways to get flexible and less verbose with
> scopes. In Ivy for example, scopes can inherit from each other, first
> of all. Secondly, when declaring configs (scopes) of dependencies that
> you need, and declaring configs (scopes) that you expose, you can use
> a verbose notation with subelements and the like, but you can also use
> a short-form, so
This is the same discussion trap Xavier and I fell into - scopes aren't
the same as configurations. configurations are actually much more like
Maven profiles, which are both additive and inherited.
Scope is meant to describe the use of the dependency through build
lifecycle, and how that is managed transitively. Profiles are meant to
handle the environmental differences. I'm a bit concerned that the water
is getting muddied between the two, so I would like to get it resolved -
there just seems to be this one area of overlap between the target
environment and the build cycle.
> While the Ivy dependency capabilities may seem like overkill to some
> people, my feeling is that only when you get to this level can you
> realistically express the dependency requirements of 99% of the
> projects out there (as opposed to 90% or 95% or something like that).
I'd be happy to work through specific examples, because I'm more
interested in finding the problem before the solution :) We've been very
careful in m2 to start with the bare minimum that covers all the use
cases people have brought up over the life of m1, to keep it as simple
as possible.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How does Maven 2 handle compile-only dependency
Posted by Colin Sampaleanu <co...@exis.com>.
Brett Porter wrote:
> Colin Sampaleanu wrote:
>
>> Thanks Brett,
>>
>> These days I don't normally track the discussion on a daily basis on
>> the dev or user lists, so had not see any, in a cursory look.
>> Filtering on 'scope' in the subject I've found "A dependency with
>> compile scope in pom.xml still adds jar to war lib in m2?", but
>> that's not really a discussion of options. Pointers to any threads of
>> relevance are certainly appreciated, especially the one where you say
>> you listed the downsides.
>
>
> Actually, most of the comments have been on the user list. There was a
> thread here following a JIRA ticket (making it hard to find in
> archives, sorry), but a lot of that centred around different objections.
>
> The downsides to separations as I see it:
> - trading one potential confusion for another (I'm sure some people
> would assume the current behaviour, that if it is there at compilation
> it should be at runtime)
> - potential to get verbose when you have >1 scope
> - if we decide to add another scope that might be implied from the
> others, it would not exist on existing metadata and need to be added
There are some creative ways to get flexible and less verbose with
scopes. In Ivy for example, scopes can inherit from each other, first of
all. Secondly, when declaring configs (scopes) of dependencies that you
need, and declaring configs (scopes) that you expose, you can use a
verbose notation with subelements and the like, but you can also use a
short-form, so
A, B, C -> E, F
says that my configs A, B, and C need the configs E and F of the
dependency (module) I am depending on. There is also wildcard support like
* -> B, C'
which says all my configs need the configs B and C of the target
dependency. Finally, there are unions, so
A -> B; * -> C
says that A needs the B and C configs of the target dependency, while
all other configs I define need at least the C config of the target
dependency.
So this is a pretty concide way to combine scopes. And it's very easy to
mix and match scopes which are additive, and scopes which are inheritive
(is that a word).
More info here:
http://www.jayasoft.fr/org/modules/ivy/ivyfile.php
While the Ivy dependency capabilities may seem like overkill to some
people, my feeling is that only when you get to this level can you
realistically express the dependency requirements of 99% of the projects
out there (as opposed to 90% or 95% or something like that).
Regards,
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How does Maven 2 handle compile-only dependency
Posted by Brett Porter <br...@apache.org>.
Colin Sampaleanu wrote:
> Thanks Brett,
>
> These days I don't normally track the discussion on a daily basis on
> the dev or user lists, so had not see any, in a cursory look.
> Filtering on 'scope' in the subject I've found "A dependency with
> compile scope in pom.xml still adds jar to war lib in m2?", but that's
> not really a discussion of options. Pointers to any threads of
> relevance are certainly appreciated, especially the one where you say
> you listed the downsides.
Actually, most of the comments have been on the user list. There was a
thread here following a JIRA ticket (making it hard to find in archives,
sorry), but a lot of that centred around different objections.
The downsides to separations as I see it:
- trading one potential confusion for another (I'm sure some people
would assume the current behaviour, that if it is there at compilation
it should be at runtime)
- potential to get verbose when you have >1 scope
- if we decide to add another scope that might be implied from the
others, it would not exist on existing metadata and need to be added
>
> I'm currently working on setting up some standard scope equivalents
> for some Ivy based projects (where scopes or something like them are
> called configurations, and there are an infinite number of them
> definable, although that doesn't make things necessarilly clearer). I
> am very much interested in coming up with something that is directly
> translatable to Maven 2, since at a minimum people will also want to
> use the projects from Maven 2, and additionally, who knows, people
> might also want to compile them with Maven 2. There's no sense with
> going with something incompatible, if something compatible can be
> figured out.
Yes, this needed to happen. You will find discussions with Xavier in the
dev archives, as we discussed sharing metadata. This same issue came up,
and a configuration takes the role of both the scope and the profile,
but still appears to be completely user-driven rather than having a
special meaning. I maintained the problem with Ivy's flexible approach
was that the configurations weren't going to match up transitively. At
least that's how I understood it, but I'm not sure we ever got to
complete agreeance.
>
> When you bring in the optional need for some things in different JDK
> environments (saw some mention on this in a maven user thread talking
> about profiles) the options get pretty varied and complicated. Punting
> on the JDK version variances, at a minimum it seems like the scopes
> that would work are:
>
> runtime: added to compile time, test-test, and runtime classpaths
> (latter implies bundling)
> compile-only: in addition to runtime dependencies. added to
> compile-time and unit-test classpaths, but not runtime (the latter
> does not imply the container does not make these available, just that
> the build does not bundle them)
> test: in additon to runtime and compile-only dependencies. added to
> test classpath.
what happened to runtime only dependencies? ie drop-in providers for a
particular api. The reason not to have these on the compilation
classpath is to prevent accidents where a class is directly used from
the implementation specific jar.
I really didn't think scope should equate to bundling, but I can see how
they sometimes match a classpath/classloader definition, so am willing
to add a "container" scope that implies some property of bundling.
Also, let's consider this beyond just Java, thinking of other languages.
Are there instances of runtime only dependencies? Are there instances of
compile time only dependencies?
I'd say almost certainly for C/C++. compile includes headers and
libraries, runtime libraries only. I can't think of compile time only
examples here - unless we consider static linking in that way?
We'll still consider it. It's possible given other languages that
compile-only might make more sense than a container scope.
>
> In Ivy, you can define any number of scopes, and they can inherit from
> each other, so ultimately I can model any set of dependencies I want,
> but I would rather not go with something that's too complicated, or
> with something that doesn't have a decent translation to Maven 2...
Maven already had inheritence, so the modelling is still achievable,
just in a different way. Similarly with profiles - this will allow those
arbitrary configurations, though because they are driven by some
specific factors we expect the ones used to be reasonably limited so
that it doesn't get confusing.
>
> One point; I think it's a bit of a mistake to go to exclusion on a
> per-plugin basis. There is something (to me) very attractive about
> being able to summarize dependencies for artifacts in terms of simple
> scopes (or groups of scopes) or configs or groups of configs in Ivy,
> and leaving it at that, without brining in plugins into the picture.
> This make it pretty much easier to switch between different dependency
> handling systems.
>
I agree as long as we are talking about general properties of
dependencies that make sense across different applications. What
concerns me about the way this discussion initially headed (the previous
thread I mentioned) was that
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How does Maven 2 handle compile-only dependency
Posted by Colin Sampaleanu <co...@exis.com>.
Thanks Brett,
These days I don't normally track the discussion on a daily basis on the
dev or user lists, so had not see any, in a cursory look. Filtering on
'scope' in the subject I've found "A dependency with compile scope in
pom.xml still adds jar to war lib in m2?", but that's not really a
discussion of options. Pointers to any threads of relevance are
certainly appreciated, especially the one where you say you listed the
downsides.
I'm currently working on setting up some standard scope equivalents for
some Ivy based projects (where scopes or something like them are called
configurations, and there are an infinite number of them definable,
although that doesn't make things necessarilly clearer). I am very much
interested in coming up with something that is directly translatable to
Maven 2, since at a minimum people will also want to use the projects
from Maven 2, and additionally, who knows, people might also want to
compile them with Maven 2. There's no sense with going with something
incompatible, if something compatible can be figured out.
When you bring in the optional need for some things in different JDK
environments (saw some mention on this in a maven user thread talking
about profiles) the options get pretty varied and complicated. Punting
on the JDK version variances, at a minimum it seems like the scopes that
would work are:
runtime: added to compile time, test-test, and runtime classpaths
(latter implies bundling)
compile-only: in addition to runtime dependencies. added to
compile-time and unit-test classpaths, but not runtime (the latter does
not imply the container does not make these available, just that the
build does not bundle them)
test: in additon to runtime and compile-only dependencies. added to test
classpath.
The compile-only should almost better be called buildtime, since it's
really available for both compile and test portion of a build. This is
the scope that is different from Maven 2.
This would work for most projects. If something produces both a web app
and a standalone jar file, and it's desired to have one scope that
includes all the dependencies for this (probably a good thing) then
there would probably be a need for a 'standalone' scope that would
include the runtime stuff as well as some stuff that would normally be
only in compile-only for the web build.
In Ivy, you can define any number of scopes, and they can inherit from
each other, so ultimately I can model any set of dependencies I want,
but I would rather not go with something that's too complicated, or with
something that doesn't have a decent translation to Maven 2...
One point; I think it's a bit of a mistake to go to exclusion on a
per-plugin basis. There is something (to me) very attractive about being
able to summarize dependencies for artifacts in terms of simple scopes
(or groups of scopes) or configs or groups of configs in Ivy, and
leaving it at that, without brining in plugins into the picture. This
make it pretty much easier to switch between different dependency
handling systems.
Regards,
Colin
Brett Porter wrote:
> Colin,
>
> This has been discussed recently on both the user and dev lists, and
> there are pros and cons to both approaches.
>
> This is the case of servlet API/J2EE, and perhaps some libraries
> provided by the final JDK but not compiling JDK. It's not that they
> are compile-only - it's that they -may- be provided for you at
> runtime. They are still required at runtime.
>
> All we really need to change is to ensure:
> - they are not bundled when they target an environment where it will
> be provided (always the case for servlet/J2ee/etc type JARs).
> - they are not used from plugins where the plugin provides them (eg,
> mock servlet api tests)
>
> Current options seem to be:
> - a "container" scope that implies compile, runtime and test, but can
> be excluded easily from bundling
> - exclusions on a per plugin basis
> * a full implementation of specification dependencies would allow the
> plugins to exclude based on the specifications by default
> * this is a bit limited as you would always have to add weblogic
> specific ones, for example
> - change to independant scopes which is more or less what you are
> proposing
> * I've listed a couple of downsides to this previously
>
> I'll add it to the agenda for the (hopefully final) IRC meeting
> tonight. Anyone is welcome to attend, or attach your comments in
> advance to the wiki page which I'll have up shortly.
>
> Thanks,
> Brett
>
> Colin Sampaleanu wrote:
>
>> I was taking a look at the description of the Scope support in Maven 2:
>> http://maven.apache.org/maven2/dependencies.html
>> but am confused as to hove Maven 2 handles dependencies which are
>> needed only for compiling, but _not_ at runtime.
>>
>> Consider the example of the servlet apis (or really any other J2EE
>> api provided by the servlet container). To compile an app deployed in
>> a servlet container, you need servlet-api.jar to be around for the
>> compile. But any war file (or EAR file) you deploy into the
>> container, should not include the API jar.
>>
>> None of the scopes seem to make sense. If it's put into 'compile'
>> scope, then it's also supposed to be available in the runtime
>> classpath, and I presume this means it will be bundled with the
>> artifact. On the other hand, if it's marked in the 'runtime' or
>> 'test' scope, then it won't be available for the compile classpath.
>>
>> Unless I'm missing something, it seems like there should really be a
>> 'compile-only' scope, or the 'compile' scope should actually be for
>> compile-only.
>>
>> Any thoughts?
>>
>> Regards,
>> Colin
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How does Maven 2 handle compile-only dependency
Posted by Brett Porter <br...@apache.org>.
Colin,
This has been discussed recently on both the user and dev lists, and
there are pros and cons to both approaches.
This is the case of servlet API/J2EE, and perhaps some libraries
provided by the final JDK but not compiling JDK. It's not that they are
compile-only - it's that they -may- be provided for you at runtime. They
are still required at runtime.
All we really need to change is to ensure:
- they are not bundled when they target an environment where it will be
provided (always the case for servlet/J2ee/etc type JARs).
- they are not used from plugins where the plugin provides them (eg,
mock servlet api tests)
Current options seem to be:
- a "container" scope that implies compile, runtime and test, but can be
excluded easily from bundling
- exclusions on a per plugin basis
* a full implementation of specification dependencies would allow the
plugins to exclude based on the specifications by default
* this is a bit limited as you would always have to add weblogic
specific ones, for example
- change to independant scopes which is more or less what you are proposing
* I've listed a couple of downsides to this previously
I'll add it to the agenda for the (hopefully final) IRC meeting tonight.
Anyone is welcome to attend, or attach your comments in advance to the
wiki page which I'll have up shortly.
Thanks,
Brett
Colin Sampaleanu wrote:
> I was taking a look at the description of the Scope support in Maven 2:
> http://maven.apache.org/maven2/dependencies.html
> but am confused as to hove Maven 2 handles dependencies which are
> needed only for compiling, but _not_ at runtime.
>
> Consider the example of the servlet apis (or really any other J2EE api
> provided by the servlet container). To compile an app deployed in a
> servlet container, you need servlet-api.jar to be around for the
> compile. But any war file (or EAR file) you deploy into the container,
> should not include the API jar.
>
> None of the scopes seem to make sense. If it's put into 'compile'
> scope, then it's also supposed to be available in the runtime
> classpath, and I presume this means it will be bundled with the
> artifact. On the other hand, if it's marked in the 'runtime' or 'test'
> scope, then it won't be available for the compile classpath.
>
> Unless I'm missing something, it seems like there should really be a
> 'compile-only' scope, or the 'compile' scope should actually be for
> compile-only.
>
> Any thoughts?
>
> Regards,
> Colin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org