[30/05/2005 23:35:42] brett: "compile only" dependencies
[30/05/2005 23:37:02] jdcasey: I'm -1 for free-form scopes
[30/05/2005 23:37:09] brett: only 1? :)
[30/05/2005 23:37:11] jdcasey: that way lies madness I think
[30/05/2005 23:37:24] trygvis: I'm +1 for the plugin knowing what artifacts to exclude by default
[30/05/2005 23:38:04] jdcasey: I think this is more of a bundling problem than anything...and it shouldn't be an excuse to make our dependency listings incomplete
[30/05/2005 23:38:10] jdcasey: :)
[30/05/2005 23:38:34] jdcasey: IMO, Colin's point of not including JDK as a dependency is a necessary flaw in the POM
[30/05/2005 23:38:48] brett: you think it should be given?
[30/05/2005 23:38:49] jdcasey: it's non-trivial, esp. when you start using the JCE
[30/05/2005 23:39:01] brett: well, our profiles will allow that
[30/05/2005 23:39:08] jdcasey: not necessarily, but it creates an incomplete impression of the project's dependencies
[30/05/2005 23:39:08] brett: though spec deps could get smarter
[30/05/2005 23:39:11] jdcasey: sure
[30/05/2005 23:39:22] brett: right, I agree
[30/05/2005 23:39:46] jdcasey: something that many people forget is that the POM's a descriptor first, build instructions second
[30/05/2005 23:39:49] brett: you should say I depend on jaxp, and then say, but I'm targetting JDK 1.4 so s'all good
[30/05/2005 23:39:56] * brett forgets
[30/05/2005 23:40:15] brett: but that was essentially my thoughts wrt scope
[30/05/2005 23:40:22] trygvis: could we have something like target=servlet-container?
[30/05/2005 23:40:28] brett: target?
[30/05/2005 23:40:29] jdcasey: I like the 'container' soln, but not the name
[30/05/2005 23:40:42] trygvis: target as in targetting
[30/05/2005 23:40:55] brett: what other targets would you have?
[30/05/2005 23:41:01] brett: is that a per-dep specification?
[30/05/2005 23:41:21] trygvis: never mind, I think I'm beeing silly
[30/05/2005 23:41:43] brett: ok, thanks. not sure I had any brain room left for radical new ideas ;)
[30/05/2005 23:42:18] brett: can we bash out the definition of scope, to see if we are doing the right thing with it?
[30/05/2005 23:42:25] brett: I'm worried it is being abused
[30/05/2005 23:43:43] trygvis: ok, but another question
[30/05/2005 23:44:02] brett: shoot
[30/05/2005 23:44:07] trygvis: if we go with the plugin having a list of artifacts to exclude (like [servlet-api,ejb-api])
[30/05/2005 23:44:25] brett: ok, I think I ruled that out eventually
[30/05/2005 23:44:28] brett: too many variables
[30/05/2005 23:44:36] trygvis: hm
[30/05/2005 23:44:53] brett: you'd forever be including weblogic-foo
[30/05/2005 23:44:59] brett: excluding
[30/05/2005 23:45:24] brett: which you'll do anyway, but you probably want to have it taken care of
[30/05/2005 23:45:25] trygvis: what if the war plugin could have a list of artifacts to exclude?
[30/05/2005 23:45:44] brett: that's what I mean - how does it know what dependency is servletapi?
[30/05/2005 23:46:00] brett: that was my original idea, but I got talked out of it
[30/05/2005 23:46:02] trygvis: I mean a list that you could configure
[30/05/2005 23:46:10] trygvis: which would be merged with the internal defaults
[30/05/2005 23:46:39] brett: nobody seemed to like that
[30/05/2005 23:47:00] brett: but I kind of agree, bundling != scope
[30/05/2005 23:47:04] trygvis: so what is the current solution? adding sope=container?
[30/05/2005 23:47:27] brett: yeah, which is reasonably clean, but it just doesn't feel quite right
[30/05/2005 23:48:53] brett: I do see the point being made
[30/05/2005 23:48:59] jason: yo
[30/05/2005 23:49:10] brett: contents of WEB-INF lib is not really any different from the cp given to surefire
[30/05/2005 23:49:21] jdcasey: I agree, it seems like we're abusing scope, which should be a build-process thing, not something that ripples out to the deployment
[30/05/2005 23:49:48] jdcasey: except it's outside the scope of the build.
[30/05/2005 23:50:00] jdcasey: you're talking about a deployment tool now, basically
[30/05/2005 23:50:25] jason: so would each tool know about the dependencies it might be dealing with
[30/05/2005 23:50:38] brett: it shouldn't have to
[30/05/2005 23:50:43] brett: less is more!
[30/05/2005 23:50:54] jason: a BEA specific mojo for EARs would have a massive number of deps
[30/05/2005 23:51:22] jason: as you need the whole lib/ to compile but obviously none of that because the container provides it
[30/05/2005 23:51:48] jason: what other options does anyone see aside from the scope, or a literal list of excludes in that case
[30/05/2005 23:52:09] brett: throwing them out no matter how bad?
[30/05/2005 23:52:22] brett: could have bundling T|F as a dep element, default to true
[30/05/2005 23:52:43] jdcasey: actually, that sounds closer to the mark to me...
[30/05/2005 23:53:19] jason: can we think of any other cases like that?
[30/05/2005 23:53:28] jason: are we just going back to properties in the dep?
[30/05/2005 23:53:34] brett: no
[30/05/2005 23:53:39] jason: not that it's bad, just thinking extensibility
[30/05/2005 23:53:42] jdcasey: I think it's more controlled than dep properties
[30/05/2005 23:53:43] brett: arbitrary info in dep bad for transitivity
[30/05/2005 23:54:09] jdcasey: also I don't really think we need that level of expressiveness in deps
[30/05/2005 23:55:04] brett: alternate tack...
[30/05/2005 23:55:10] brett: what if we add other plugins
[30/05/2005 23:55:20] brett: cactus is a favourite because it crosses all these boundaries
[30/05/2005 23:55:32] brett: how do we establish what is used for cactus?
[30/05/2005 23:55:50] jdcasey: will the bundling not hold true for cactus?
[30/05/2005 23:56:03] jdcasey: you might include extra stuff, eh? like test artifacts?
[30/05/2005 23:56:09] brett: aye, but it isn't desired for any of the other 3
[30/05/2005 23:56:17] brett: yes, cactus specific stuff
[30/05/2005 23:57:51] jdcasey: ugh - <bundling><target>cactus</target></bundling>?
[30/05/2005 23:58:21] brett: thats just the properties again
[30/05/2005 23:58:36] brett: I guess we could go there, and use dependencyManagement
[30/05/2005 23:58:57] * brett thinks we had it right all along
[30/05/2005 23:59:09] jason: what, with properties?
[30/05/2005 23:59:36] jdcasey: brett: it's not as free-form as the properties...
[30/05/2005 23:59:47] brett: yes, but someone wanted to map deps to names
[30/05/2005 23:59:59] brett: yes, though let's call it configuration for consistency and to say we actually did something
[31/05/2005 00:00:07] brett: and they aren't transitive
[31/05/2005 00:00:24] jdcasey: the scope should handle transitivity, shouldn't it?
[31/05/2005 00:00:29] brett: the endpom declares dependency management to do its thing
[31/05/2005 00:00:37] brett: jdcasey: yes, scope is different
[31/05/2005 00:00:46] jdcasey: or do you mean that we can't negate all of servletapi's deps by excluding it during bundle
[31/05/2005 00:01:10] brett: hang on
[31/05/2005 00:01:55] brett: in dep management, you have <dep><g>servletapi</g><a, v/><configuration><warBundle>false</warBundle></></>
[31/05/2005 00:02:09] brett: that means servletapi and its deps don't get bundled in the war you are currently building
[31/05/2005 00:02:25] brett: what I meant above was
[31/05/2005 00:02:56] brett: if someone put said configuration in a normal dependency element (which is also fine), and you then depended on the project containing that, the dep you get wouldn't have that configuration
[31/05/2005 00:03:04] brett: the configuration applies only to the current POM
[31/05/2005 00:04:13] jdcasey: what drives you to make that rule? I've obviously missed something
[31/05/2005 00:04:20] jason: doesn't scope = container (or whatever) generally work
[31/05/2005 00:04:38] jason: the depMan seems wrong to me because you've got plugin specific info in there again
[31/05/2005 00:04:53] *** evenisse has signed off IRC (Ping timeout).
[31/05/2005 00:05:11] jdcasey: jason: the difference between bundling for cactus and bundling for weblogic (production, etc) all within the same POM makes scope='container' sort of broken
[31/05/2005 00:05:11] *** trenton has joined #maven.
[31/05/2005 00:05:25] *** pvdhoef has signed off IRC (Leaving).
[31/05/2005 00:05:44] jason: we can have another scope to accommodate
[31/05/2005 00:05:45] brett: jdcasey: because the project you depend on doesn't know what your environment is going to be. It can't determine if it will be in a war or not
[31/05/2005 00:05:49] jdcasey: it's a fair point, though: this is sort of plugin configuration, not really related to the pure project...
[31/05/2005 00:05:58] jdcasey: oh
[31/05/2005 00:07:19] brett: jason: scope = container works fine, but it is different to the other scopes, so I'm worried it is changing the definition
[31/05/2005 00:07:20] jdcasey: jason: so have a cactus-container scope?
[31/05/2005 00:07:38] jdcasey: right, it doesn't fit into the implied-scope framework, f.e.
[31/05/2005 00:07:51] jason: because it applies to build in addition to the packing process?
[31/05/2005 00:08:16] brett: yeah, though maybe I'm drawing a line in the wrong spot
[31/05/2005 00:08:27] brett: feels like build vs deployment to me though
[31/05/2005 00:08:28] jason: scope yields in the creation of a list of artifacts
[31/05/2005 00:08:33] jdcasey: brett: actually, in pure terms, scope='runtime' ought to be a scope='none' with bundling turned on
[31/05/2005 00:08:53] brett: ??
[31/05/2005 00:09:09] brett: but it still implies test?
[31/05/2005 00:09:09] jdcasey: scope='runtime' artifacts aren't used in the build process at all, are they?
[31/05/2005 00:09:40] brett: only testing
[31/05/2005 00:09:43] jdcasey: ok
[31/05/2005 00:10:01] *** conan has signed off IRC (Ping timeout).
[31/05/2005 00:10:03] jdcasey: this beast is too big for me to keep track of all the details in my puny brain :)
[31/05/2005 00:10:04] jason: what you package is obviously dependent on what you declare as dependencies, how those dependencies are utilized in your build vs your deploy or bundle needs to be expressed some way and i think scope does that
[31/05/2005 00:10:26] brett: yep, I agree
[31/05/2005 00:10:35] jdcasey: jason: but the difference being that in all other cases, scope relates to building classpaths for the build...
[31/05/2005 00:10:36] jason: does scope not simply produce a set of artifacts based on some rules
[31/05/2005 00:10:45] brett: yes
[31/05/2005 00:10:46] brett: so the following makes sense to me:
[31/05/2005 00:10:58] jason: jdcasey, i see scope different and never thought of it that way
[31/05/2005 00:10:59] brett: "give me everything I need at runtime, but leave out stuff I already have"
[31/05/2005 00:11:15] brett: jdcasey: a little java specific too
[31/05/2005 00:11:20] jason: scope=provided
[31/05/2005 00:11:35] brett: yeah, I was secretly going to rename container to that
[31/05/2005 00:12:07] jdcasey: I'll not push back on that one. it's definitely the most terse definition we've talked about.
[31/05/2005 00:12:08] jason: and then maybe test-provided for cactus goop if it is in fact different
[31/05/2005 00:12:27] *** hohi has signed off IRC (KVIrc 3.2.0 'Realia').
[31/05/2005 00:12:34] jdcasey: maybe it redefines the concept of scope, maybe not. the practicality makes it worthwhile, I suppose.
[31/05/2005 00:12:37] jason: i think we could make any list of artifacts for any purpose using the scope stuff
[31/05/2005 00:12:53] brett: but with a fixed set of scopes?
[31/05/2005 00:12:53] jdcasey: the trick is to avoid user-defined scopes
[31/05/2005 00:13:11] jason: sure, i don't think there are that many cases that we can't control them
[31/05/2005 00:13:18] jdcasey: third party plugins may introduce a need for new scopes
[31/05/2005 00:13:29] jason: have an example?
[31/05/2005 00:13:31] jdcasey: cactus being a prime example
[31/05/2005 00:13:53] jason: i'm sure we could generalize what cactus does, no?
[31/05/2005 00:13:59] jdcasey: it represents a new class of plugin from what else we've been discussing, and forces a new scope
[31/05/2005 00:14:20] brett: cactus will take the test stuff, and maybe add something you only use in cactus
[31/05/2005 00:14:49] jdcasey: or cactus-like cases...
[31/05/2005 00:15:06] brett: the only issue I see is if you use another plugin that does the same thing
[31/05/2005 00:15:11] jdcasey: not that there are many, but then again we have barely begun to dabble in non-java things
[31/05/2005 00:16:30] jason: what does cactus actually do that is different? never used cactus myself, so i don't know?
[31/05/2005 00:16:36] jason: it's weirdo bundling stuff?
[31/05/2005 00:16:57] brett: not so different
[31/05/2005 00:17:01] brett: its just another source path
[31/05/2005 00:17:06] brett: hence another classpath
[31/05/2005 00:17:25] brett: you might write a cactus test case that uses mockobjects
[31/05/2005 00:17:41] brett: you don't want the dep for your unit tests or anything else
[31/05/2005 00:18:20] jason: so in your cactus WAR you might dump in some cactus servlet filter stuff or whatever
[31/05/2005 00:18:27] brett: right
[31/05/2005 00:18:37] brett: cactus specific stuff the cactus plugin will dump in itself
[31/05/2005 00:18:38] jason: so wouldn't that be like test-provided (or something nicer)
[31/05/2005 00:18:45] jason: scope=test-provided
[31/05/2005 00:18:52] brett: no, its the opposite
[31/05/2005 00:18:55] brett: you actually want to bundle it
[31/05/2005 00:19:04] jason: in your final war?
[31/05/2005 00:19:05] brett: scope=integration-test, if you will
[31/05/2005 00:19:12] brett: in your final cactus war
[31/05/2005 00:19:26] trygvis: final? are there several cactus wars?
[31/05/2005 00:19:28] jason: right, for testing not your WAR
[31/05/2005 00:19:34] jason: the war you deploy
[31/05/2005 00:19:39] brett: right
[31/05/2005 00:19:51] jason: scope=integration-test sounds good
[31/05/2005 00:19:58] brett: declare a dependencies element inside the plugin? :)
[31/05/2005 00:20:03] jdcasey: that almost starts to sound like binding deps to phases... :)
[31/05/2005 00:20:06] trygvis: why is that different than scope=test?
[31/05/2005 00:20:36] jason: because you're modifying your production WAR to run in cactus
[31/05/2005 00:20:49] jason: which requires some special jars for cactus to execute
[31/05/2005 00:21:01] trygvis: so you'll have a different classpath for unit and integration tests?
[31/05/2005 00:21:03] brett: jason: problem with integration-test is if you use cactus and something else too, both integration tests
[31/05/2005 00:21:55] jason: so if you were doing a cactus run and a run with a load tester or something
[31/05/2005 00:22:08] brett: yeah
[31/05/2005 00:22:13] brett: but these are definitely plugin specific
[31/05/2005 00:22:23] brett: and I don't think they are transitive
[31/05/2005 00:22:32] jdcasey: bundling sounds more like a selector than anything else to me...something that the mojo itself could request from maven...like "give me the set to be bundled for 'cactus'"
[31/05/2005 00:22:32] brett: (that I can think of)
[31/05/2005 00:23:14] brett: jdcasey: well that's one solution. scope = cactus, which inherits from "test", and we have our predefined types to keep things sane
[31/05/2005 00:23:33] *** conan has joined #maven.
[31/05/2005 00:24:08] jdcasey: I was actually thinking that the mojo could register @requiresDependencyResolution "test" and then select bundling='cactus' (different element inside the dep) from that...
[31/05/2005 00:24:25] brett: yeah, well - the other, I think, is still to use dep management to control the cactus bundling
[31/05/2005 00:24:26] jdcasey: then you've got a user-defined space for selectors, and our strict vocab for scopes
[31/05/2005 00:24:37] brett: and since there is already a usecase for using dep management configuration
[31/05/2005 00:24:46] brett: (mapping war to context path in ear)
[31/05/2005 00:24:48] jdcasey: what's that other use case?
[31/05/2005 00:24:51] jdcasey: oh
[31/05/2005 00:25:18] jason: mapping a war to a context path in an ear?
[31/05/2005 00:25:25] brett: yes
[31/05/2005 00:25:27] jason: goes in a dep configuration?
[31/05/2005 00:25:39] brett: yes
[31/05/2005 00:25:40] jdcasey: I have to say, I always hated <war.bundle>true</war.bundle>...I mean, it's a common enough function, but needs user-defined selectors
[31/05/2005 00:25:46] jason: that just sounds wrong to me
[31/05/2005 00:26:20] brett: jason: I agreed, but how to configure on the plugin cleanly stumped me
[31/05/2005 00:26:24] jdcasey: actually, the context path mapping sounds like EAR plugin config...
[31/05/2005 00:26:32] jason: yah
[31/05/2005 00:26:43] jdcasey: it would be a matter of specifying a map type inside the <configuration> element...no?
[31/05/2005 00:27:19] jason: i would think so, i think configuration in the deps is not a good idea in general
[31/05/2005 00:27:20] jdcasey: we need a concise shorthand for dependency reference...
[31/05/2005 00:27:27] brett: g:a
[31/05/2005 00:27:44] jdcasey: that's the problem with the mapping in the plugin, isn't it? the dependency reference is complicated?
[31/05/2005 00:27:52] brett: <contextPaths><g:a>/foo</g:a></>
[31/05/2005 00:28:05] jdcasey: brett: if we could reference deps that way and have it parsed into something real (a dep) that would be really cool
[31/05/2005 00:28:10] jdcasey: right
[31/05/2005 00:28:31] jdcasey: the problem with 'g:a' is that it looks like a namespace to the xml parser, doesn't it?
[31/05/2005 00:28:36] trygvis: (we need to make sure ":" is a illegal character inside a groupId and artifactId unless it's already done)
[31/05/2005 00:28:46] jdcasey: that's a good point
[31/05/2005 00:29:02] brett: <contextPaths><contextPath><artifact>g:a</><path>/foo</></></>
[31/05/2005 00:29:06] jdcasey: that's what I was thinking actually
[31/05/2005 00:29:19] brett: yeah, that'll do me
[31/05/2005 00:29:38] jdcasey: maybe ${g:a} and have the expr evaluator resolve them
[31/05/2005 00:29:48] brett: ?
[31/05/2005 00:30:10] jdcasey: then you'd have a Map with key type of Dependency or Artifact, and value-type of String
[31/05/2005 00:30:22] jdcasey: probably not useful...nm
[31/05/2005 00:30:25] brett: scope = provided / container still irks me. in a transitive scenario I'd ask "how do you know where I'm going to put you?"
[31/05/2005 00:31:09] brett: or is it non transitive
[31/05/2005 00:31:17] brett: becomes compile
[31/05/2005 00:31:25] jdcasey: if it's non-transitive, is that exceptional to the other scopes?
[31/05/2005 00:31:29] jdcasey: I guess not
[31/05/2005 00:31:41] jdcasey: well, yes it is, actually
[31/05/2005 00:31:45] brett: test disappears transitively
[31/05/2005 00:31:54] jdcasey: ah, right
[31/05/2005 00:32:10] brett: good enough for me
[31/05/2005 00:32:17] trygvis: but it's not unlikely to require servlet-api if you're using the war as another jar is it?
[31/05/2005 00:32:36] brett: I don't understand
[31/05/2005 00:32:50] jdcasey: I'm uncomfortable with using scope in this way, fwiw. </2cents>
[31/05/2005 00:33:49] brett: its worth 2cents, if that even parsed
[31/05/2005 00:34:10] jdcasey: trygvis: if myProject depends on servletapi with scope=container, and yourProject depends on myProject to compile, where does servletapi come in? is that what you mean?
[31/05/2005 00:34:19] trygvis: yes
[31/05/2005 00:34:56] jdcasey: that's a valid point, I'd say
[31/05/2005 00:35:00] jason: servlet api is there it's just something the packaging would look at to exclude it from the package
[31/05/2005 00:35:22] jason: that dep wouldn't drop out of the chain
[31/05/2005 00:35:33] jdcasey: jason: so scope=container means that it's included in the compile scope?
[31/05/2005 00:35:52] jason: well you need to compile a servlet
[31/05/2005 00:36:08] jdcasey: I mean the transitive compile scope...
[31/05/2005 00:36:23] jason: i don't see why not
[31/05/2005 00:36:44] trygvis: (I'm making dinner in the background)
[31/05/2005 00:37:00] jdcasey: what are the transitive implications for test-container, then?
[31/05/2005 00:37:01] brett: I don't like it. somebod is assuming something further down the foodchain
[31/05/2005 00:37:04] jdcasey: none
[31/05/2005 00:37:17] jdcasey: brett: can you elaborate?
[31/05/2005 00:37:39] jdcasey: (I'm having trouble articulating all this in my head)
[31/05/2005 00:38:19] brett: in trygve's example
[31/05/2005 00:38:32] brett: you depend on something that tells you you have to have it in the container
[31/05/2005 00:38:38] brett: but you don't have a container
[31/05/2005 00:38:43] jason: if there is case where in one scenerio where scope=provided didn't hold true i think it would be a problem
[31/05/2005 00:39:03] jason: if there is a concrete example of that then i would agree with you
[31/05/2005 00:39:05] brett: strutstestcase depends on servletapi, but it would be compile scope
[31/05/2005 00:39:31] brett: jason: I Don't think there is, because I believe provided only makes sense at the endpom
[31/05/2005 00:39:56] brett: which smells to me like it doesn't really make sense as a scope in the first place :)
[31/05/2005 00:40:00] brett: but I could be wrong
[31/05/2005 00:40:17] brett: going to the jdk use case is probably more concrete here
[31/05/2005 00:40:30] brett: foo depends on jaxp, scope = provided
[31/05/2005 00:40:38] brett: bar depends on foo, but intends to run on jdk 1.3
[31/05/2005 00:40:50] brett: I guess foo already has a 1.4 assumption so you can't do that
[31/05/2005 00:40:56] jason: so in your project you override the scope
[31/05/2005 00:41:14] brett: yah, ok
[31/05/2005 00:41:30] jason: i mean you're going to have to twiddle something
[31/05/2005 00:41:35] jason: whether it be a configuration or scope
[31/05/2005 00:41:45] brett: ok, I can live with that
[31/05/2005 00:41:54] brett: provided stays provided
[31/05/2005 00:42:20] jason: we ponder counter examples and see if we come up with any when we chat again
[31/05/2005 00:42:24] jason: if we are going to chat again
[31/05/2005 00:42:26] brett: and is equivalent to compile + test
[31/05/2005 00:42:55] brett: I agreed originally so I don't think I'll find much different. I'm just going in circles now :)
[31/05/2005 00:43:00] jdcasey: so at the least we have two new scopes: provided and integration-test?
[31/05/2005 00:43:03] jason: hokay
[31/05/2005 00:43:16] brett: glad we sorted out the ear context path thing
[31/05/2005 00:43:29] *** evenisse has joined #maven.
[31/05/2005 00:44:37] *** evenisse_ has joined #maven.
[31/05/2005 00:44:45] jason: what's next?
[31/05/2005 00:44:58] brett: jdcasey: it may be acceptable to have arbitrary scopes that aren't transitive. IT's only in transitivity that they go haywire, and you aren't going to have transitive cactus projects
[31/05/2005 00:45:05] brett: but let's ponder that more