subject:"scopeperi\/scope"

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 --
      scopenon-classpath/scope
      listtomcat/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

Re: scopeperi/scope

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 --
      scopenon-classpath/scope
      listtomcat/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

Re: scopeperi/scope

On 28 June 2011 11:38, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
 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

The critical scope to add for me is something along the lines of
provides or supplies or embeds-equivalent

So that when computing the dependency tree, we could automatically
exclude dependencies that are already provided or supplied or embedded
in another dependency.

The sticking point for me is that it needs a good name different from provided

 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 --
      scopenon-classpath/scope
      listtomcat/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

Re: scopeperi/scope

 The critical scope to add for me is something along the lines of
 provides or supplies or embeds-equivalent


Why is this a scope and not just more configuration inside the
dependency/ element?

dependency
  !-- gav --
  alsoProvides
   alsoProvide
!-- gav --
  /alsoProvide
 /alsoProvides
/dependency



 So that when computing the dependency tree, we could automatically
 exclude dependencies that are already provided or supplied or embedded
 in another dependency.

 The sticking point for me is that it needs a good name different from 
 provided

 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 --
      scopenon-classpath/scope
      listtomcat/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

Re: scopeperi/scope

On 28 June 2011 14:01, Benson Margulies bimargul...@gmail.com wrote:
 The critical scope to add for me is something along the lines of
 provides or supplies or embeds-equivalent


 Why is this a scope and not just more configuration inside the
 dependency/ element?

    dependency
      !-- gav --
      alsoProvides
       alsoProvide
        !-- gav --
      /alsoProvide
     /alsoProvides
    /dependency


Because why should I have to always state that I'm using
org.slf4j:log4j-over-slf4j and that it provides log4j:log4j much
better that the pom for org.slf4j:log4j-over-slf4j says oh and by the
way I provide log4j:log4j myself so you don't need to pull it in
transitively if you depend on me

maven could then break the build for you if you pull in log4j:log4j
and org.slf4j:log4j-over-slf4j just as it does if you try to pull in
two different versions of log4j:log4j

and it could ensure that a project that depends on
org.slf4j:log4j-over-slf4j never has log4j:log4j in its dependency
tree.

People will say that OSGi is the real answer here, and that you have
to... blah blah blah... we are in the real world here, OSGi is good
for some things and not for others, Maven needs a solution that is
better than having to add
excludesexcludegroupIdlog4j/groupIdartifactIdlog4j/artifactId/exclude/excludes
to _all_ the dependencies in your project just because you have added
a dependency on org.slf4j:log4j-over-slf4j



 So that when computing the dependency tree, we could automatically
 exclude dependencies that are already provided or supplied or embedded
 in another dependency.

 The sticking point for me is that it needs a good name different from 
 provided

 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

Re: scopeperi/scope


 Because why should I have to always state that I'm using
 org.slf4j:log4j-over-slf4j and that it provides log4j:log4j much
 better that the pom for org.slf4j:log4j-over-slf4j says oh and by the
 way I provide log4j:log4j myself so you don't need to pull it in
 transitively if you depend on me

I think that you are abusing the term 'dependency' here. I think that,
if this is worth doing, it's worth adding a new element to the POM at
the same level as 'dependencies' to declare that the project's
artifact also provides a list of additional gavs.


 maven could then break the build for you if you pull in log4j:log4j
 and org.slf4j:log4j-over-slf4j just as it does if you try to pull in
 two different versions of log4j:log4j

 and it could ensure that a project that depends on
 org.slf4j:log4j-over-slf4j never has log4j:log4j in its dependency
 tree.

 People will say that OSGi is the real answer here, and that you have
 to... blah blah blah... we are in the real world here, OSGi is good
 for some things and not for others, Maven needs a solution that is
 better than having to add
 excludesexcludegroupIdlog4j/groupIdartifactIdlog4j/artifactId/exclude/excludes
 to _all_ the dependencies in your project just because you have added
 a dependency on org.slf4j:log4j-over-slf4j



 So that when computing the dependency tree, we could automatically
 exclude dependencies that are already provided or supplied or embedded
 in another dependency.

 The sticking point for me is that it needs a good name different from 
 provided

 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

Re: scopeperi/scope

On 28 June 2011 14:38, Benson Margulies bimargul...@gmail.com wrote:

 Because why should I have to always state that I'm using
 org.slf4j:log4j-over-slf4j and that it provides log4j:log4j much
 better that the pom for org.slf4j:log4j-over-slf4j says oh and by the
 way I provide log4j:log4j myself so you don't need to pull it in
 transitively if you depend on me

 I think that you are abusing the term 'dependency' here. I think that,
 if this is worth doing, it's worth adding a new element to the POM at
 the same level as 'dependencies' to declare that the project's
 artifact also provides a list of additional gavs.


I agree, but if you stick to the cannot change the pom format the
only thing you can just about do is introduce a new scope.


 maven could then break the build for you if you pull in log4j:log4j
 and org.slf4j:log4j-over-slf4j just as it does if you try to pull in
 two different versions of log4j:log4j

 and it could ensure that a project that depends on
 org.slf4j:log4j-over-slf4j never has log4j:log4j in its dependency
 tree.

 People will say that OSGi is the real answer here, and that you have
 to... blah blah blah... we are in the real world here, OSGi is good
 for some things and not for others, Maven needs a solution that is
 better than having to add
 excludesexcludegroupIdlog4j/groupIdartifactIdlog4j/artifactId/exclude/excludes
 to _all_ the dependencies in your project just because you have added
 a dependency on org.slf4j:log4j-over-slf4j



 So that when computing the dependency tree, we could automatically
 exclude dependencies that are already provided or supplied or embedded
 in another dependency.

 The sticking point for me is that it needs a good name different from 
 provided

 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,

Re: scopeperi/scope


 I agree, but if you stick to the cannot change the pom format the
 only thing you can just about do is introduce a new scope.


Is this, let's make this feature before we're willing to change the
pom or let's never change the pom.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: scopeperi/scope

I would offer

  scopealsoProvides/scope

for the feature you propose.

On Tue, Jun 28, 2011 at 11:11 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 On 28 June 2011 14:38, Benson Margulies bimargul...@gmail.com wrote:

 Because why should I have to always state that I'm using
 org.slf4j:log4j-over-slf4j and that it provides log4j:log4j much
 better that the pom for org.slf4j:log4j-over-slf4j says oh and by the
 way I provide log4j:log4j myself so you don't need to pull it in
 transitively if you depend on me

 I think that you are abusing the term 'dependency' here. I think that,
 if this is worth doing, it's worth adding a new element to the POM at
 the same level as 'dependencies' to declare that the project's
 artifact also provides a list of additional gavs.


 I agree, but if you stick to the cannot change the pom format the
 only thing you can just about do is introduce a new scope.


 maven could then break the build for you if you pull in log4j:log4j
 and org.slf4j:log4j-over-slf4j just as it does if you try to pull in
 two different versions of log4j:log4j

 and it could ensure that a project that depends on
 org.slf4j:log4j-over-slf4j never has log4j:log4j in its dependency
 tree.

 People will say that OSGi is the real answer here, and that you have
 to... blah blah blah... we are in the real world here, OSGi is good
 for some things and not for others, Maven needs a solution that is
 better than having to add
 excludesexcludegroupIdlog4j/groupIdartifactIdlog4j/artifactId/exclude/excludes
 to _all_ the dependencies in your project just because you have added
 a dependency on org.slf4j:log4j-over-slf4j



 So that when computing the dependency tree, we could automatically
 exclude dependencies that are already provided or supplied or embedded
 in another dependency.

 The sticking point for me is that it needs a good name different from 
 provided

 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

Re: scopeperi/scope

On 28 June 2011 16:27, Benson Margulies bimargul...@gmail.com wrote:

 I agree, but if you stick to the cannot change the pom format the
 only thing you can just about do is introduce a new scope.


 Is this, let's make this feature before we're willing to change the
 pom or let's never change the pom.


We, as of yet, do not have a good story for how we can change the pom
format... without breaking all the clients of poms out there...

Keeping in mind that some of the clients are not using Maven's tooling
to parse the pom.

The best story so far is to deploy a side-pom that is of the new
format, so you would be deploying for example

foo-1.0.pom
and
foo-1.0.pom5

for the version 5 format pom.

And our deploy tooling would convert a pom5 into an old modelVersion
4.0.0 pom... this gives the issue of how do we extend again... will we
then end up with .pom, .pom5, .pom6, .pom7, .pom8 all being deployed
at the same time?

So then the story goes that we get an extensible format right and that
is what we deploy (perhaps with a classifier, since poms do not yet
have classifiers, and that way we are not baking version numbers into
the file extension...

foo-1.0.pom
and
foo-1.0-extensible.pom

if you are building with a maven version that knows of extensible poms
it would try for the extensible pom first and fail-back to the 4.0.0
pom. Old builds will only see the 4.0.0 poms... Maven repo managers
can forward convert the 4.0.0 poms to extensible through an
established mapping rule or such if we want to reduce bandwidth... but
then what about the checksums of those poms... and the gpg
signatures... we could do it for central as a one-time operation with
a known gpg signature though as a work-around...

What I have not seen is a concrete solid proposal for an extensible
pom format... and until we have one of those, that can be proven to be
extensible enough that we don't have to dance around again to
accomodate older clients, essentially the pom format is frozen.

-Stephen

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

scopeperi/scope

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

Re: scopeperi/scope

2011-06-27 Thread Arnaud Héritier

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.comwrote:

 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

Re: scopeperi/scope

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.comwrote:

 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

Re: scopeperi/scope

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
  namecompile/name
  transitivetrue/transitive
/scope
scope
  nameruntime/name
  transitivefalse/transitive
/scope
scope
  nametest/name
  transitivetrue/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.comwrote:

 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

Re: scopeperi/scope

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.

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.

So, what would you think of

   dependency
  !-- gav --
  scopenon-classpath/scope
  listtomcat/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
      namecompile/name
      transitivetrue/transitive
    /scope
    scope
      nameruntime/name
      transitivefalse/transitive
    /scope
    scope
      nametest/name
      transitivetrue/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.comwrote:

 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

Re: scopeperi/scope

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 --
      scopenon-classpath/scope
      listtomcat/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
      namecompile/name
      transitivetrue/transitive
    /scope
    scope
      nameruntime/name
      transitivefalse/transitive
    /scope
    scope
      nametest/name
      transitivetrue/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.comwrote:

 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

Re: scopeperi/scope

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 --
scopenon-classpath/scope
listtomcat/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
namecompile/name
transitivetrue/transitive
/scope
scope
nameruntime/name
transitivefalse/transitive
/scope
scope
nametest/name
transitivetrue/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.comwrote:

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

Re: scopeperi/scope

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 --
  scopenon-classpath/scope
  listtomcat/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
  namecompile/name
  transitivetrue/transitive
/scope
scope
  nameruntime/name
  transitivefalse/transitive
/scope
scope
  nametest/name
  transitivetrue/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 :

Re: scopeperi/scope