(16:07:04) trygvis: I think I'm -1 to your latest change to the axis plugin
(16:07:18) trygvis: magically adding a compile time dependency isn't maven style
(16:07:19) jc2817: ?
(16:07:25) jesse: the adding the dep?
(16:07:27) trygvis: yep
(16:07:36) jc2817 left the room (quit: CGI:IRC).
(16:07:38) joakime: heh.
(16:07:38) jesse: vmassol does it in the clover plugin
(16:07:42) joakime: <-- guilty of that
(16:07:46) trygvis: I don't like that either :)
(16:07:49) jesse: lol
(16:07:53) joakime: cobertura does it too.
(16:07:56) trygvis: though the clover stuff is probably only test time
(16:08:00) trygvis: it's not a runtime dependency?
(16:08:10) jesse: ok, time for a steel cage fight
(16:08:16) trygvis: though I might not understand what's really going on here
(16:08:25) jesse: it is only for compile
(16:08:54) joakime: i personally want <scope> and <phases><phase/></phases> in the <dependency> section.
(16:09:08) mjason [~jasonva@CPE0014516993be-CM023080004191.cpe.net.cable.rogers.com] entered the room.
(16:09:22) trygvis: only compile? what is it needed for?
(16:09:27) joakime: or <dependency><phase-exclusions><phase>test</phase></phase-exclusions></dependency>
(16:09:32) vmassol: trygvis: what don't you like in the clover plugin?
(16:09:35) jesse: axis deps in the generated source code
(16:09:45) jesse: vmassol: the adding of a compile dep
(16:09:59) vmassol: why?
(16:10:15) trygvis: because all dependencies are supposed to be in the pom
(16:10:20) trygvis: but as I said I might be missing something here
(16:10:53) vmassol: trygvis: would you say this also for cehckstyle, pmd, etc?
(16:10:54) joakime: whats the specific compile-time dep in clover?
(16:11:01) trygvis: vmassol: definitely
(16:11:02) ***joakime is curious.
(16:11:08) trygvis: but can't someone just tell me why it's needed?
(16:11:15) vmassol: trygvis: my preference goes to what's simplest for the user
(16:11:22) trygvis: (#%/#()%
(16:11:38) vmassol: Maven is based around providing sensible defaults
(16:11:46) trygvis: DUDE
(16:11:49) vmassol: it makes sense to me
(16:11:50) vmassol: :-)
(16:11:53) |conan| [~conan@mdproctor.plus.com] entered the room.
(16:12:09) trygvis: so then the user of the pom will have to add the dependency by hand?
(16:12:20) vmassol: err
(16:12:25) vmassol: quite the opposite
(16:12:39) trygvis: then tell my why you're adding a compile time dependency ..
(16:12:42) jesse: vmassol: in packaging yes
(16:12:43) vmassol: I don't want the user to define a clover dep in its pom
(16:13:10) conan left the room (quit: Ping timeout).
(16:13:10) |conan| is now known as conan
(16:13:32) trygvis: jesse: why do you need to inject the axis dependency for the axis stuff?
(16:13:34) vmassol: trygvis: simply to generate clases...
(16:13:59) jesse: trygvis: it uses axis to generate a mess of code, and then needs axis to compile that code
(16:14:09) jesse: for type definitions and whatnot
(16:14:14) vmassol: same for clover
(16:14:25) vmassol: and same for any generation plugin
(16:14:34) trygvis: but then it won't require it runtime?
(16:14:58) vmassol: that's the user's problem
(16:15:03) trygvis: wtf?
(16:15:12) trygvis: I'm not talking about the clover plugin
(16:15:26) trygvis: I must be missing something obvious here
(16:15:30) jesse: trygvis: yes, that is the problem with doing it that way
(16:15:59) trygvis: so the producer benefits but all the consumers loose?
(16:16:24) trygvis: and the project has a single implicit dependency while all other dependencies are explicitly stated?
(16:17:18) jesse: its the precedent set by the existing plugins that needs to be decided here..
(16:17:29) trygvis: I'm so -1 to that
(16:17:47) trygvis: we explicitly removed the injection of the junit dependency from the test plugin for this exact reason
(16:17:51) trygvis: explicit dependency management
(16:18:09) vmassol: I'm also -1 to remove it!
(16:18:10) vmassol: :-)
(16:18:11) trygvis: so what if the user want another axis version?
(16:18:32) trygvis: seriously?
(16:18:36) trygvis: I can't see the gain here
(16:20:19) vmassol: that's true for all plugins
(16:20:26) trygvis: what do you mean?
(16:21:00) jesse: trygvis: that was my thought, I was swayed by the precedent of the other plugins...which is ultimately the issue here
(16:21:24) jesse: imo
(16:21:34) vmassol: imo a plugin has to control its dependecies
(16:21:46) trygvis: this is not a question of a plugin controlling it's own dependencies
(16:21:58) trygvis: this is a plugin controlling the depencies of the _project_
(16:22:21) vmassol: when I use a plugin I want it to bring the deps it needs
(16:22:33) trygvis: of course, that's not what we're talking about
(16:22:50) trygvis: jesse: which other plugins are doing this?
(16:23:09) vmassol: so when i use the axis plugin I want it to bring the axis dep
(16:23:14) jesse: well, clover was the one I found the code in, joakime says cobetura
(16:23:31) jesse: I didn't see it in pmd though
(16:23:43) vmassol: now it's me who's lost :-)
(16:23:47) vmassol: what are we talking about then?
(16:23:47) trygvis: clover and cobertura doesn't inject any compile time (and thus run time) dependencies
(16:23:56) jesse: clover does
(16:24:03) mjason left the room (quit: mjason).
(16:24:06) joakime: junit was a special case, as surefire isn't junit specific. - and plugins can have their own deps overwritten in the project pom using the <plugin><depdendencies>
(16:24:35) joakime: trygvis: cobertura injects a cobertura runtime dep for the test phase only.
(16:24:47) trygvis: that's an entirely different thing
(16:25:13) jesse: that is what the axis is doing as well, the painful part of the axis one imo is that it leaves the user up to haveing to add the axis dep manually somewhere else in the packaging
(16:25:16) trygvis: it's a test time dependency, not a compile time dependency
(16:25:23) jesse: since it loses the transitive nature of the compile requirement
(16:25:47) joakime: well, cobertura has a different set of dependencies during the test compile time.
(16:25:54) trygvis: if the produced jar has a dependency on axis it must be in the pom
(16:25:58) jesse: which maybe I didn't explain fully to vincent yesterday
(16:26:14) mjason [~jasonva@CPE0014516993be-CM023080004191.cpe.net.cable.rogers.com] entered the room.
(16:26:39) trygvis: joakime: still, it's not a compile time dependency
(16:26:39) vmassol: trygvis: axis plugin generates source files. It does so by using an axis dep provided by the plugin. Then to compile you need the same dep, no?
(16:27:04) trygvis: depends on the generated sources, but I think you do in the axis case
(16:27:29) vmassol: so as you agreed that plugins being their own dep, here you go!
(16:27:41) jesse: vmassol: yes, but the issue is that the axis dep ought to be carried along to the other artifacting using it
(16:27:44) trygvis: vmassol: no way
(16:28:01) joakime: trygvis: (on your side of the argument) the modello plugin generates xpp readers/writers that requires a compile time dep to plexus-utils be added to the project pom.
(16:28:22) trygvis: yes and all projects that use the xpp3 stuff has a dependency on plexus-utils
(16:28:35) trygvis: and that's done that way by design
(16:29:14) trygvis: what the axis plugin should do is that it should stop if the project is missing an axis dependency
(16:29:18) trygvis: or warn at least
(16:29:26) joakime: axis plugin is unique tho.
(16:29:41) trygvis: what's the difference between modello and axis?
(16:29:44) joakime: axis has a project dep requirement, and a plugin dep requirement. it's a first. (as i see it)
(16:29:54) joakime: modello only has a project dep requirement.
(16:30:01) joakime: the plugin dep does not.
(16:30:11) trygvis: ok, that's a different but I still don't agree
(16:31:20) joakime: the axis requirements seem like a new use case for me. something we need to address and deal with.
(16:31:45) trygvis: agreed
(16:32:06) joakime: cobertura and clover are plugin dep only. modello is project dep only. and axis is the first to straddle both the plugin and the project.
(16:32:24) jesse: \o/ ya me :P
(16:32:27) trygvis: my point is that the project's pom has to include the axis depdenency if not you're hurting all consumers
(16:32:52) trygvis: which is totally unacceptable (imo)
(16:32:55) vmassol: trygvis: I think I see your point. What I'm used to doing is to add the needed deps in the project using clovered code. What you're saying is that those projects should get it transitively and should not add id
(16:32:58) joakime: course, i'm not a core developer, and could be that brett and the gang have a technique or pland for this already.
(16:33:51) trygvis: vmassol: "clovered code" ?
(16:34:05) vmassol: code on which clover has been run on
(16:34:07) jesse: clovered code isn't used outside the artifact...axis is
(16:34:15) vmassol: why not?
(16:34:16) trygvis: exactly, a big point here
(16:34:30) vmassol: jesse: here's an example
(16:34:33) jesse: oh wait, clovered code can be released?
(16:34:47) joakime: clovered code has been used in integration testing. which is in an artifact.
(16:34:47) trygvis: then clover should be a dependency in the pom too
(16:35:01) vmassol: imagine I have a WAR that has code that has been clovered. Then I create my EAR? I need it to have the clover jar for execution
(16:35:05) trygvis: at least for the "main" artifact
(16:35:18) vmassol: s/?//
(16:36:10) vmassol: trygvis: ironically this is what I had coded initially in Clover and brett "fixed" it by including the clover dep inside the plugin
(16:36:24) joakime: heh.
(16:37:06) vmassol: I still think it's a bit harder on users but I undersdtand the issue now
(16:37:26) jesse: vmassol: the user is screwed if they don't know they need to add that clover dep into the packaging artifact right?
(16:37:47) vmassol: right
(16:38:12) jesse: ok, that is the same issue as axis then
(16:38:31) trygvis: all most at least, the clover stuff is only used for testing and within a project
(16:38:38) trygvis: not a maven project, but a "company project"
(16:38:47) trygvis: so it's a less of a risk of messing up stuff for users
(16:38:51) jesse: should this be caught at packaging or at the project layer when it is being run
(16:39:09) pinj2 [~c39d966@beaver.codehaus.org] entered the room.
(16:39:26) trygvis: perhaps we need an integration test scope?
(16:39:26) pinj2: hi all. does anyone have a config file for continuum to set it up to run on another port to 8080? If not is it easy to give me an example, the documentation doesn't give me enough info.
(16:39:36) vmassol: trygvis: that we need anyway
(16:39:40) pinj2: cheers in advance
(16:39:58) mjason: pinj2: ask in #continuum
(16:40:50) jesse: trygvis: integration scope won't fix the axis one...what we need to decide is to fail fast in the project during compile time or ... not sure in the packaging phase
(16:41:14) trygvis: no, but it will make it possible for the project to have clover as a integration test dependency :)
(16:41:16) vmassol: so the axis plugin will need to check that the axis dep passed it by the project is compatible witht he plguin code
(16:41:38) vmassol: s/passed it/passed to it/
(16:41:51) jesse: hm...ick
(16:41:54) mjason: i understand the axis dependency being required by the user POM but what's the issue with clover?
(16:42:08) vmassol: mjason: same thing
(16:42:08) trygvis: vmassol: yes, I guess
(16:42:12) trygvis: or just trust the user :)
(16:42:17) ***mjason missed the beginning
(16:42:31) vmassol: trygvis: yeah that would be the first implementation...
(16:42:40) jesse: what if the user puts axis 2.0 in the project deps and the plugin uses 1.x?
(16:42:43) trygvis: not sure how you would keep the plugin up to date?
(16:43:01) vmassol: it'll fail with some ugly stack trace...
(16:43:11) jesse: and not obviously
(16:43:44) trygvis: it's not that hard catching those exceptions
(16:43:55) jesse: ah, we just use the xpp3 object to rewrite the project pom to add the correct axis version!
(16:43:59) dain [~dain@68-171-62-46.vnnyca.adelphia.net] entered the room.
(16:44:05) trygvis: NoSuchMethodException etc
(16:44:06) jesse: :P
(16:44:12) dantran [~dtt@206.171.40.13] entered the room.
(16:44:29) vmassol: anyway I'm now in agreement with you. Jesse are you going to revert the change. I need to know because I have to modify the book's J2EE chapter to match this... yuck
(16:44:47) jdcasey [~jdcasey@adsl-220-156-43.gnv.bellsouth.net] entered the room.
(16:44:49) jesse: lol, ya...I'll switch it back around
(16:44:53) trygvis: \o/
(16:45:03) trygvis: what a mess I started :)
(16:45:11) vmassol: better now that later... :-)
(16:45:35) vmassol: and we need a jira for clover...
(16:45:38) jesse: bad precedent though, now I'll argue with vincent more :P
(16:45:50) vmassol: {#[{[``{~#@??
(16:47:06) CoffeeBre: interesting discussion you had there. I had one plugin that has exactly the same issue. Is this only going to be in the book?
(16:48:14) CoffeeBre: anyone can comment on my proposal (mail to dev@mojo...) to add a new idea ui designer m2 plugin to mojo sandbox?
(16:48:18) vmassol: we should cover it in the plugin dev guide somewhere
(16:48:56) vmassol: CoffeeBre: thanks for proposing to do it! :-)
(16:49:22) joakime: (thinking out loud) wonder if <scope>provided</scope> in a plugin could be made to refer to a dep in the project level?
(16:49:50) CoffeeBre: vmassol: sorry no time for that now! Not sure I followed the whole thread correctly though :)
(16:49:55) vmassol: hehe
(16:50:11) vmassol: we have logs...
(16:50:16) mjason: if a plugin generates code that requires a particular artifact then it's a dependency, i think that's pretty simple
(16:50:37) mjason: it's in the code whether it was generated or done by hand
(16:51:21) mjason: though most decent generation tools will either allow you to use a dependency or generate dependency free code
(16:51:33) ***jdcasey is completely lost, as usual...
(16:52:02) mjason: jdcasey: the gist is plugins that required dependencies in the user POM
(16:52:17) jdcasey: are they a problem?
(16:52:17) mjason: so if you generate a parser with Antlr you need the Antlr runtime jar
(16:52:22) joakime: jdcasey: scroll back to "*tilt*" and read from there.
(16:52:33) jdcasey: don't have that much backlog :)
(16:52:48) jdcasey: ...but I'm intrigued
(16:52:49) jdcasey: :)
(16:52:59) zentrum_: morning :)
(16:53:02) jdcasey: hi
(16:53:03) mjason: or if you generate any code that requires an artifact then it must be in the user POM
(16:53:11) zentrum_: what's happened with mojo.codehaus.org?
(16:53:11) jdcasey: right