On 28 June 2011 00:15, Benson Margulies <bimargul...@gmail.com> wrote: > Consider the tomcat use case, and then mine. > > The tomcat use-case is: declare additional artifacts of type/packaging > 'war'. The plugin launches them as additional webapps.
Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided -> supplied by the container... in this case tomcat > > My use case: This artifact of code, here, depends on that giant > artifact of data, there. > > In both cases, the dependency *does* need to be copied to the local > repo, but does *not* want to be in classpath. then that is a non-classpath artifact type unless i mis-understand your case > > So, what would you think of > > <dependency> > <!-- gav --> > <scope>non-classpath</scope> > <list>tomcat</list> > </dependency> > > > That is, define the concept of a named list of dependencies, which > seems harmlessly extensible, while defining exactly one more scope, to > use for this purpose? > > > > On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly > <stephen.alan.conno...@gmail.com> wrote: >> Allowing people to have custom scopes is a thin end of the wedge... >> >> The scopes we have are not sufficient, so I am +1 to expanding them >> >> Custom scopes are a recipe for disaster... the whole point of >> standardization is that everyone knows what they mean. >> >> Currently we have: >> >> compile - which we have borked to be transitive but shouldn't be >> runtime - fair enough >> provided - which is closer to what compile should have been >> test - not good enough for the multitude of testing phases >> system - Eeek! don't use >> import - nobody has a clue what exactly this does >> >> Critically missing from my PoV are: >> >> provides - needs a better name, but I want to signify that I provide a >> specific GAV in my pom so that you don't bother trying to pull it in >> for another dep... eg. log4j-over-slf4 would provides log4j >> >> test-compile >> test-runtime >> >> some scope that is like compile & runtime but not the test classpath... >> >> Actually the more I think about it what you really want to specify, in >> a standardized way is the list of classpaths to add to, and whether it >> is transitive on that classpath... >> >> And of course in the non-maven world, classpath does not make sense... >> but there are equivalents >> >> <dependency> >> <groupId>...</groupId> >> <artifactId>...</artifactId> >> <version>...</version> >> <scopes> >> <scope> >> <name>compile</name> >> <transitive>true</transitive> >> </scope> >> <scope> >> <name>runtime</name> >> <transitive>false</transitive> >> </scope> >> <scope> >> <name>test</name> >> <transitive>true</transitive> >> </scope> >> </scopes> >> </dependency> >> >> Man that's ugly >> >> On 27 June 2011 23:27, Benson Margulies <bimargul...@gmail.com> wrote: >>> Two options in my head: >>> >>> 1) Eliminate the warning. >>> 2) Allow some means for officially defining scopes -- the problem >>> being that the consumer is the logical place for the definition. >>> >>> >>> 2011/6/27 Arnaud Héritier <aherit...@gmail.com>: >>>> I don't have any pointer in mind except this page which doesn't say much >>>> than a stricter validation of POM : >>>> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-StricterPOMValidation >>>> But that right that in maven 2 we just ignored unknown scopes while maven 3 >>>> throws a warning >>>> >>>> Arnaud >>>> >>>> On Mon, Jun 27, 2011 at 7:02 PM, Benson Margulies >>>> <bimargul...@gmail.com>wrote: >>>> >>>>> In looking at the tomcat plugin, I noticed that it depends on using a >>>>> custom scope, and there was commentary complaining that maven 3 >>>>> complains. >>>>> >>>>> Is there a thread or a JIRA about this? I'm contemplating creating >>>>> something like this of my own, and I'd like to know what trouble I'm >>>>> getting myself into. >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
