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:[EMAIL PROTECTED] > Sent: Sunday, December 11, 2005 02:51 > To: [email protected] > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
