You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Allison, Bob" <ro...@qwest.com> on 2006/01/05 12:43:14 UTC
RE: Improve methods to define the scope and packaging of dependencies(MNG-1732)
I understand what you are saying on this. I am also looking at the
number of questions on the user list in the vein of
-- How do I get a jar in both scope=compile and scope=test?
-- How do I get a jar packaged in the ear instead of the war?
Answering the first question is simply a matter of pointing the user to
the correct documentation, since it is obvious that they need to better
understand the scope definitions, but it also points out that
scope=compile is not intuitively "use this jar everywhere". Allowing
the alternative definition I outlined in the JIRA issue allows people to
explicitly state their intentions.
Answering the second question seems much more difficult. I saw one email
yesterday where someone recommended against using Maven 2 because of
this issue. With my proposal, the answer would be to define the jar as
follows in the war project:
<dependency>
<groupId>g</groupId>
<artifactId>a</artifactId>
<usage>
<war>false</war>
<ear>true</true>
</usage>
</dependency>
Because in this case scope is not defined, it defaults to "compile"
which makes it available to the ear project transitively.
The changes that would be needed for the war and ear plugins is to look
for the usage Map:
If (usage == null) {
// proceed as done currently
} else {
String todo = (String)usage.get("war"); // or "ear" for the ear
plugin
if ("true".equalsIgnoreCase(todo)) {
// package it
}
}
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Wednesday, December 28, 2005 06:14
To: Maven Developers List
Subject: Re: Improve methods to define the scope and packaging of
dependencies(MNG-1732)
We went over these suggestions in March and I was originally a proponent
of phase or goal-based scoping instead of what we kept, but now agree we
made the right choice.
Basically, the scope is an intelligent default for most settings, it
maps well to a number of different scenarios, and scopes are based on
each other. This is the reason we don't have compile and test as
separate, for example.
As for the others, the main issue with this is transitive dependencies.
If A uses B and B uses C, how does A control the properties/usages of C?
With scope, these can be intelligentally combined, but this might not be
the case with arbitrary properties/usages.
The suggestion we have had is to use configuration on the plugin that
takes an artifact filter for applying boolean properties. When it comes
to mapping paths, this configuration would be in the form of name value
pairs (a list of items, each having group, artifact id and installation
location).
I think in this case you'd have a lot of repeated information. My
preference would be to build up a database of these things somewhere
were it is only required once.
I hope this explains it.
- Brett
Allison, Bob wrote:
> I'm back from vacation now, so if this won't start another holy war
> (like XML format) I have two questions on this issue:
>
> 1) Why is this a bad idea?
>
> 2) Assuming that this idea won't be done, any suggestions on how to
> configure the mapping of dependencies to RPM installation locations?
>
> A good deal of the reason for the suggestion was to allow dependencies
> to be easily mapped to the location where the RPM package should
install
> them. If the project has dependencies which need to be packaged, I
need
> to know where to put them. With things the way they are right now, I
> need to specify the group/artifact/version/type as a dependency then
> repeat the information in the RPM plugin configuration so that I can
> link that dependency with a location in the package. I also see a lot
> of confusion on the user list on how to get a dependency [not]
packaged
> in a war/ear/ejb (especially when people make the same mistake I made
> and assume that "compile" scope means compile-time, not everywhere)
> since you have to play games with the scope and exclusions to get
things
> packaged correctly (based on what I see on the user list).
>
> -----Original Message-----
> From: Brett Porter (JIRA) [mailto:jira@codehaus.org]
> Sent: Sunday, December 11, 2005 02:51
> To: dev@maven.apache.org
> Subject: [jira] Closed: (MNG-1732) Improve methods to define the scope
> andpackaging of dependencies
>
>
> [ http://jira.codehaus.org/browse/MNG-1732?page=all ]
>
> Brett Porter closed MNG-1732:
> -----------------------------
>
> Assign To: Brett Porter
> Resolution: Won't Fix
>
> we can answer questions about why this is a bad idea on the dev list
>
>
>> Improve methods to define the scope and packaging of dependencies
>> -----------------------------------------------------------------
>>
>> Key: MNG-1732
>> URL: http://jira.codehaus.org/browse/MNG-1732
>> Project: Maven 2
>> Type: Improvement
>>
>
>
>> Versions: 2.0
>> Reporter: Bob Allison
>> Assignee: Brett Porter
>>
>
>
>> I have been thinking about the way the dependency scope is being
used,
>>
> and I think there may be a need to expand the scope definitions so
that
> more flexibility is available for defining what dependencies get
> packaged into artifacts and what dependencies are used in the various
> classpaths. My thought is to create a new tag on the dependency XML
> tree called "usage"; it would look something like this:
>
>> <dependency>
>> <groupId>junit</groupId>
>> <artifactId>junit</artifactId>
>> <version>3.8.1</version>
>> <!--scope>test</scope-->
>> <usage>
>> <compile>true</compile>
>> <test>true</test>
>> <execute>false</execute>
>> <jar>false</jar>
>> <rpm>/usr/local/lib</rpm>
>> </usage>
>> </dependency>
>> I see two classes of items within the <usage> tag:
>> -- classpath items (compile, test, execute above) which split out
the
>>
> current meaning of the scope value and would have the value of "true"
or
> "false" to identify if the dependency should appear on the classpath;
> the default value for these would be "true"
>
>> -- packaging items (jar, rpm above) which control the packaging of
the
>>
> dependency into the specified type of artifact and would have the
value
> "false" to omit the dependency, "true" to package the dependency in a
> package-specific default location (e.g., wars would default to
> "WEB-INF/lib"), or a path to package the dependency in a specific
place
> in the artifact; the default value for these would be "false"
>
>> My expectation is that both <scope> and <usage> would be accepted and
>>
> that <usage> would be configured as a Map. If possible, it would be
> easier for mojos to use this arrangement if specifying <scope> would
> cause a pre-configured <usage> map to be placed in the usage variable
so
> that mojos only have to look at the usage map and not interpolate the
> scope value as well.
>
>> I think this may also help with people who have a hard time
>>
> remembering that a scope of "compile" means that the dependency is
also
> available at runtime and which scopes make the dependency get packaged
> into the artifact. It would also address some of the "how do I keep
my
> war dependencies from appearing in my ear file" type of questions.
>
>
---------------------------------------------------------------------
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
Re: Improve methods to define the scope and packaging of dependencies(MNG-1732)
Posted by Brett Porter <br...@apache.org>.
Hi Bob,
We've been over the first case before. I think its dangerous to change
that now - better documentation/explanation (or maybe even alternative
naming), but I think we need to retain the compile -> runtime -> test
relationship.
I know we need to sort out that second use case. There's also
discussions on skinny wars and appserver located (provided) jars.
I think we should pull this together for a discussion on the wiki for 2.1.
I don't believe the usage tag is the solution as it still doesn't answer
the question of how you allocate transitive dependencies to the war/ear.
The current WAR includes all JARs and blocks dependencies transitively
(because they are already included). The opposite is the skinny WAR that
would not include and and passes all on transitively. I think the
solution is to allow configuration of an artifact filter that
includes/excludes artifacts. The filter that excludes from the WAR would
be used to include in the EAR.
We've talked about doing this for configuration already. Making them
easy to configure would be a good idea, na dmaybe we should make them
identifiable sections of the pom so they can be reused like in this use
case.
Maybe the ideas need to be combined - filters that do things (war
inclusion) that are listed on dependencies and would supersede
exclusions. I haven't thought that trough yet, but its one thing we can
discuss.
- Brett
Allison, Bob wrote:
> I understand what you are saying on this. I am also looking at the
> number of questions on the user list in the vein of
> -- How do I get a jar in both scope=compile and scope=test?
> -- How do I get a jar packaged in the ear instead of the war?
>
> Answering the first question is simply a matter of pointing the user to
> the correct documentation, since it is obvious that they need to better
> understand the scope definitions, but it also points out that
> scope=compile is not intuitively "use this jar everywhere". Allowing
> the alternative definition I outlined in the JIRA issue allows people to
> explicitly state their intentions.
>
> Answering the second question seems much more difficult. I saw one email
> yesterday where someone recommended against using Maven 2 because of
> this issue. With my proposal, the answer would be to define the jar as
> follows in the war project:
> <dependency>
> <groupId>g</groupId>
> <artifactId>a</artifactId>
> <usage>
> <war>false</war>
> <ear>true</true>
> </usage>
> </dependency>
> Because in this case scope is not defined, it defaults to "compile"
> which makes it available to the ear project transitively.
>
> The changes that would be needed for the war and ear plugins is to look
> for the usage Map:
> If (usage == null) {
> // proceed as done currently
> } else {
> String todo = (String)usage.get("war"); // or "ear" for the ear
> plugin
> if ("true".equalsIgnoreCase(todo)) {
> // package it
> }
> }
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: Wednesday, December 28, 2005 06:14
> To: Maven Developers List
> Subject: Re: Improve methods to define the scope and packaging of
> dependencies(MNG-1732)
>
>
> We went over these suggestions in March and I was originally a proponent
> of phase or goal-based scoping instead of what we kept, but now agree we
> made the right choice.
>
> Basically, the scope is an intelligent default for most settings, it
> maps well to a number of different scenarios, and scopes are based on
> each other. This is the reason we don't have compile and test as
> separate, for example.
>
> As for the others, the main issue with this is transitive dependencies.
> If A uses B and B uses C, how does A control the properties/usages of C?
> With scope, these can be intelligentally combined, but this might not be
> the case with arbitrary properties/usages.
>
> The suggestion we have had is to use configuration on the plugin that
> takes an artifact filter for applying boolean properties. When it comes
> to mapping paths, this configuration would be in the form of name value
> pairs (a list of items, each having group, artifact id and installation
> location).
>
> I think in this case you'd have a lot of repeated information. My
> preference would be to build up a database of these things somewhere
> were it is only required once.
>
> I hope this explains it.
>
> - Brett
>
> Allison, Bob wrote:
>> I'm back from vacation now, so if this won't start another holy war
>> (like XML format) I have two questions on this issue:
>>
>> 1) Why is this a bad idea?
>>
>> 2) Assuming that this idea won't be done, any suggestions on how to
>> configure the mapping of dependencies to RPM installation locations?
>>
>> A good deal of the reason for the suggestion was to allow dependencies
>> to be easily mapped to the location where the RPM package should
> install
>> them. If the project has dependencies which need to be packaged, I
> need
>> to know where to put them. With things the way they are right now, I
>> need to specify the group/artifact/version/type as a dependency then
>> repeat the information in the RPM plugin configuration so that I can
>> link that dependency with a location in the package. I also see a lot
>> of confusion on the user list on how to get a dependency [not]
> packaged
>> in a war/ear/ejb (especially when people make the same mistake I made
>> and assume that "compile" scope means compile-time, not everywhere)
>> since you have to play games with the scope and exclusions to get
> things
>> packaged correctly (based on what I see on the user list).
>>
>> -----Original Message-----
>> From: Brett Porter (JIRA) [mailto:jira@codehaus.org]
>> Sent: Sunday, December 11, 2005 02:51
>> To: dev@maven.apache.org
>> Subject: [jira] Closed: (MNG-1732) Improve methods to define the scope
>> andpackaging of dependencies
>>
>>
>> [ http://jira.codehaus.org/browse/MNG-1732?page=all ]
>>
>> Brett Porter closed MNG-1732:
>> -----------------------------
>>
>> Assign To: Brett Porter
>> Resolution: Won't Fix
>>
>> we can answer questions about why this is a bad idea on the dev list
>>
>>
>>> Improve methods to define the scope and packaging of dependencies
>>> -----------------------------------------------------------------
>>>
>>> Key: MNG-1732
>>> URL: http://jira.codehaus.org/browse/MNG-1732
>>> Project: Maven 2
>>> Type: Improvement
>>>
>>
>>> Versions: 2.0
>>> Reporter: Bob Allison
>>> Assignee: Brett Porter
>>>
>>
>>> I have been thinking about the way the dependency scope is being
> used,
>>>
>> and I think there may be a need to expand the scope definitions so
> that
>> more flexibility is available for defining what dependencies get
>> packaged into artifacts and what dependencies are used in the various
>> classpaths. My thought is to create a new tag on the dependency XML
>> tree called "usage"; it would look something like this:
>>
>>> <dependency>
>>> <groupId>junit</groupId>
>>> <artifactId>junit</artifactId>
>>> <version>3.8.1</version>
>>> <!--scope>test</scope-->
>>> <usage>
>>> <compile>true</compile>
>>> <test>true</test>
>>> <execute>false</execute>
>>> <jar>false</jar>
>>> <rpm>/usr/local/lib</rpm>
>>> </usage>
>>> </dependency>
>>> I see two classes of items within the <usage> tag:
>>> -- classpath items (compile, test, execute above) which split out
> the
>>>
>> current meaning of the scope value and would have the value of "true"
> or
>> "false" to identify if the dependency should appear on the classpath;
>> the default value for these would be "true"
>>
>>> -- packaging items (jar, rpm above) which control the packaging of
> the
>>>
>> dependency into the specified type of artifact and would have the
> value
>> "false" to omit the dependency, "true" to package the dependency in a
>> package-specific default location (e.g., wars would default to
>> "WEB-INF/lib"), or a path to package the dependency in a specific
> place
>> in the artifact; the default value for these would be "false"
>>
>>> My expectation is that both <scope> and <usage> would be accepted and
>>>
>> that <usage> would be configured as a Map. If possible, it would be
>> easier for mojos to use this arrangement if specifying <scope> would
>> cause a pre-configured <usage> map to be placed in the usage variable
> so
>> that mojos only have to look at the usage map and not interpolate the
>> scope value as well.
>>
>>> I think this may also help with people who have a hard time
>>>
>> remembering that a scope of "compile" means that the dependency is
> also
>> available at runtime and which scopes make the dependency get packaged
>> into the artifact. It would also address some of the "how do I keep
> my
>> war dependencies from appearing in my ear file" type of questions.
>>
>>
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org