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: 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
