On 28 June 2011 11:31, Benson Margulies <bimargul...@gmail.com> wrote: > 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? >
no scope => compile (modello default value) also dependency on war artifacts is used for war overlays.... what I am thinking is that if we change the war plugin so that only scope compile wars are used for overlays, then tomcat maven plugin is free to use either provided and/or runtime as the scope for side-deployment... runtime could be good if you always needed it as a side webapp (e.g. the ear plugin could then pull those runtime wars in transitively, while the provided would behave as non-transitive) > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org