I was pretty sleepy last night. My residual disagreement is that 'provided' doesn't just mean 'copy to local repo'. It means 'copy to local repo and put in test classpath.' Yes, I now get it, an appropriate packaging avoids any classpath. The word 'provided' is used because it's 'provided' by the environment by magic at runtime. I end up thinking that one more scope would make this easier to explain. Try writing a paragraph of doc that we'd put in the pom doc to explain 'provided' if we decide to just stick with this.
However, I have a really simple idea. What if we permitted *no scope at all* for non-jar artifacts to serve this purpose? On Mon, Jun 27, 2011 at 8:32 PM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > the wars are really side web apps that are provided by somebody else at > deployment time in the runtime container. > > just as the server api is provided by somebody else. > > the tomcat plugin is providing the container, so as it knows those side apps > are not present it would make sense to me if it provided them for me. just > like when running unit tests, surfer will provide the provided deps on my > test classpath. > > what i am saying is tomato does not need a special scope. symmantically > their required scope is provided. > > - Stephen > > --- > Sent from my Android phone, so random spelling mistakes, random nonsense > words and other nonsense are a direct result of using swype to type on the > screen > On 28 Jun 2011 00:46, "Benson Margulies" <bimargul...@gmail.com> wrote: >> The tomcat wars are NOT provided. The idea is to grab them from the >> repositories, copy them to the local repo, and have the tomcat plugin >> 'collect them all.' >> >> I didn't know that maven already had the concept of non-classpath >> artifact types. I've been laboring under the idea that these things >> would end up in the classpath if not excluded somehow. >> >> Tomcat could stop using the special scope, but then it would need to >> redundantly list these artifacts in its own config, unless the author >> were willing to take the attitude that *all* war dependencies should >> be launched. Using foo:bar syntax instead of a nest of XML that is >> perhaps not too awful, but it still feels like listing the same thing >> twice. Hmm: how does the new site plugin avoid this? With the new site >> plugin, can you built a reporting plugin in the reactor and then use >> it in a site? I bet not. >> >> In short, I'm arguing for some idea of annotating dependencies to >> avoid redundantly calling them out in plugins, but I'm not arguing >> terribly loudly. >> >> On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly >> <stephen.alan.conno...@gmail.com> wrote: >>> 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 >>> >>> >> >> --------------------------------------------------------------------- >> 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
