Jan 31 11:14:18 jdcasey so, this is sort of the laundry list we've worked up for the plugin/lifecycle handling so far, I think:
Jan 31 11:14:19 jdcasey http://docs.codehaus.org/display/MAVEN/Lifecycle+and+Plugin+Handling
Jan 31 11:14:35 jdcasey etrade has, of course, added their own unique twist to things, too
Jan 31 11:15:06 jesse last editted jun 20 :)
Jan 31 11:15:27 jdcasey yup, but nothing much has changed...I'm pulling it out of mothballs
Jan 31 11:15:34 jdcasey there's another one by brett too...looking
Jan 31 11:15:56 jdcasey http://docs.codehaus.org/display/MAVEN/Plugin+Execution+Model+and+Lifecycle+Improvements
Jan 31 11:16:05 jdcasey you'll like the timestamp on that one even better :)
Jan 31 11:17:36 jdcasey so, some of this has been addressed (at least partially)...the flexible artifact filtering, I mean
Jan 31 11:18:57 jesse ah, this problem
Jan 31 11:19:16 jesse good to be getting unmothballed, it has a lot of ramifications, or it can at least
Jan 31 11:19:20 jdcasey so, the big part of that page that I want to address is phase ordering and suppression
Jan 31 11:19:22 jdcasey right
Jan 31 11:20:11 jdcasey the other twist is that a client brought up the fact that you have to know the lifecycle mapping, plus all inherited plugin bindings, before you can intelligently suppress + add a replacement mojo binding
Jan 31 11:20:22 jdcasey because you have to know where to bind the replacement
Jan 31 11:21:15 jesse the whole build needs to be planned out in other words, before it can be filtered
Jan 31 11:21:41 jdcasey I consider it bad design to say "we'll solve it with tools", but one could make a plugin that would inject the bindings already present for a particular phase into the current pom, for the sake of reordering/suppressing them
Jan 31 11:21:46 jesse to come up with the true build
Jan 31 11:22:17 jdcasey well, yeah, I suppose. I think it would be valuable to have fine-grained control over ordering, to whatever degree you want it (all phases or just one, f.e.)
Jan 31 11:22:28 jesse seems to me that fundamentally this is a question of 'how maliable do we want the lifecycle to be?'
Jan 31 11:22:43 jdcasey and I don't think that adding more and more phases will solve the problem...it just adds confusion and destroys the semantics of existing phases
Jan 31 11:22:54 jesse good good
Jan 31 11:22:58 jdcasey yeah, that's definitely true
Jan 31 11:23:12 jdcasey but I'm not sure that's the only question
Jan 31 11:23:13 jesse all this pre- post- pre-pre- post-post- stuff needs to stop
Jan 31 11:23:26 jdcasey also: how much should a build author need to know about his context?
Jan 31 11:23:37 jdcasey in terms of the inherited phase bindings, packaging, etc.
Jan 31 11:23:41 jdcasey yup, definitely
Jan 31 11:23:54 jesse well, once you decide that fundamentally the lifecycle is solid, then you decend into ording issues within phases themselves
Jan 31 11:23:57 jdcasey post-* really implies something that it cannot currently deliver anyway
Jan 31 11:24:11 jdcasey you only get the post-* phase if you run the build to or past it
Jan 31 11:24:34 jdcasey I think the lifecycle is critical. it gives a set of verbs that are universal
Jan 31 11:24:39 jdcasey that's really important
Jan 31 11:24:53 jesse totally, without it you become ant
Jan 31 11:25:02 jdcasey yeah, basically
Jan 31 11:25:10 jdcasey maven 1 was an advanced ant
Jan 31 11:25:16 jesse right
Jan 31 11:25:42 jesse lets work within and actual phase..
Jan 31 11:25:48 jdcasey right
Jan 31 11:26:06 jesse maybe compile, imagine if the compile plugin was broken out into 3 pieces
Jan 31 11:26:14 jdcasey so, we need to be able to do three things in a phase, from what I see:
Jan 31 11:26:20 jdcasey 1. suppress a phase binding
Jan 31 11:26:20 jesse scanning, pre-processing, compiling
Jan 31 11:26:32 jdcasey 2. specify the ordering of the bindings
Jan 31 11:26:54 jdcasey 3. replace a phase binding without having to know too much about it (this last one is tricky, and I'm not entirely sure about it)
Jan 31 11:27:02 jdcasey yup, sure
Jan 31 11:27:24 jesse in my exaple you can supress pre-processing in java (mostly)
Jan 31 11:27:32 jdcasey how?
Jan 31 11:27:36 jesse but scanning sure needs to come first
Jan 31 11:27:40 jdcasey right
Jan 31 11:27:51 jesse hypotheically it can be, how is your problem :P
Jan 31 11:28:16 jdcasey hehe
Jan 31 11:28:17 jdcasey ok
Jan 31 11:28:24 jesse 1) does this need to be solved in the pom by the user?
Jan 31 11:28:25 jdcasey left as an exercise to the reader
Jan 31 11:29:02 jdcasey well, here's the thing on #1 there: users may need to specify a different scanner. how do they do that?
Jan 31 11:29:17 jesse seems to me that scanning could be declared as a requirement before compiling happens
Jan 31 11:29:55 jdcasey so the compiler declares a dependency on some sort of scanner interface or something?
Jan 31 11:30:01 jdcasey or a scanning action
Jan 31 11:30:02 jdcasey ?
Jan 31 11:30:32 jdcasey that's actually the type of thing we tried to model when we put together the concept of phases in the first place.... :)
Jan 31 11:30:41 jesse assuming scanning is some kinda plugin and compile is a seperate one...this is your state machine thing
Jan 31 11:30:51 jdcasey yeah, sure
Jan 31 11:31:01 jdcasey ok, so the compiler cannot proceed unless scanning does so first
Jan 31 11:31:03 jdcasey but...
Jan 31 11:31:18 jdcasey if I need to replace the default scanner, how would I do that?
Jan 31 11:31:23 jesse hehe, how about this
Jan 31 11:31:27 jdcasey or, do you mean that this dependency creates an ordering?
Jan 31 11:31:32 jdcasey sort of like a DAG?
Jan 31 11:31:45 jesse each plugin declares a StateSetter and a StateRequirement
Jan 31 11:31:49 jesse exactly
Jan 31 11:32:03 jesse you can put whatever StateSetter in you want
Jan 31 11:32:19 jesse but if you want to replace it you need to duplicate the StateSetter
Jan 31 11:32:27 jdcasey that actually starts to blur the line between m2 lifecycle phases, and m1 preGoal/postGoal...if you can abstract the dependency term, you're ok
Jan 31 11:32:28 jesse you _need_ a DAG of some sort here
Jan 31 11:32:29 jdcasey hmm
Jan 31 11:32:34 jdcasey yeah, I suppose so
Jan 31 11:32:47 jesse otherwise how do you expect to reproduce it
Jan 31 11:33:00 jesse you need some ordering mechanism
Jan 31 11:33:08 jdcasey yeah, that's true...unless the addition logic never changes, which is what we have now
Jan 31 11:33:13 jdcasey right
Jan 31 11:33:42 jesse DAG = state graph of ordering inside a phase
Jan 31 11:33:47 jdcasey the ordering mechanism that we've been talking about heretofore has been some place where the user takes the stick and dlineates exactly what happens when within a phase
Jan 31 11:34:03 jdcasey your concept gets us closer to a workflow, right?
Jan 31 11:34:15 jesse ya
Jan 31 11:34:35 jdcasey it'd be interesting to see where general-purpose things like antrun or the shell plugin I wrote would fit into this
Jan 31 11:34:35 jesse that can be analyzed for holes pre-exec
Jan 31 11:34:47 jdcasey they'd have to have some dynamic way of declaring themselves as StateSetter
Jan 31 11:35:01 jesse hm..
Jan 31 11:35:18 jesse not declaring a statesetter means that the work anywhere...freeform
Jan 31 11:35:37 jesse but if the user forces a order externally then they can set it in their pom?
Jan 31 11:35:42 jdcasey yeah, I think I've been dancing around this concept of a workflow for quite awhile now...the problem is declaring an abstract dependency term...but that's sort of what we've started doing with the build context, I guess
Jan 31 11:36:38 jdcasey well, the idea was that the user would specify a binding on the shell plugin, suppress the old make:install plugin, and specify the ordering of the package phase to push the shell plugin back up front, ahead of rpm:build
Jan 31 11:36:40 jdcasey f.e.
Jan 31 11:36:41 jesse so I write a plugin FrackItUp and it needs to run after antrun since I just wanted to use it...but both of these need to run in generate-sources since mines just twiddles with the sources...I place a stateSetter in antrun
Jan 31 11:37:11 jdcasey and the client wanted to say something like <replaces><groupId/><artifactId/>[<version/>]<executionId/></replaces>
Jan 31 11:37:28 jesse and our lifecycle plugins get an honorary awesomeness stateSetter equal to the name of the phase
Jan 31 11:37:41 jdcasey ok, so stateSetter would have to be added as some sort of markup in the plugin config
Jan 31 11:37:43 jdcasey hmm
Jan 31 11:37:52 jesse ya
Jan 31 11:37:53 jdcasey :)
Jan 31 11:38:09 jesse and it could use your build state context
Jan 31 11:38:26 jdcasey yeah, I see where you're going
Jan 31 11:38:42 jesse most people don't need to dick with this kinda stuff
Jan 31 11:38:53 jdcasey the funny thing is, the phases just become arbitrary markers in the larger lifecycle workflow in this...
Jan 31 11:39:04 jesse ya
Jan 31 11:39:12 jesse hm...
Jan 31 11:39:13 jdcasey since state consumer/producer would have to be sorted globally for the lifecycle
Jan 31 11:39:32 jdcasey well, the reason most people don't have to mess with this is that the lifecycle was designed for java dev
Jan 31 11:39:44 jesse true true
Jan 31 11:39:52 jdcasey that will change if maven finds an audience outside of java
Jan 31 12:15:54 jdcasey I do like the simple elegance of saying "this execution replaces that execution" but in reality, this doesn't lessen the complexity...
Jan 31 12:16:03 jdcasey you still have to know the execId of that other execution
Jan 31 12:16:12 jdcasey which is not trivial to discover, I suppose
Jan 31 12:16:21 jdcasey unless you're looking through the debug output
Jan 31 12:16:26 jdcasey anyway, back to the topic
Jan 31 12:16:51 jesse I have a new question :)
Jan 31 12:16:53 jdcasey I like the idea that a build extension can add a new lifecycle phase mapping, which is why keeping it in components.xml is nice
Jan 31 12:16:56 jdcasey ok :)
Jan 31 12:17:27 jesse is adding plugin ordering inside a phase tantamount to undermining the concept of a lifecycle phase?
Jan 31 12:18:01 jdcasey you mean because a phase is implicitly atomic and indivisible or something?
Jan 31 12:18:30 jesse moment
Jan 31 12:20:10 jdcasey k
Jan 31 12:21:58 jesse but yes in a nutshell..
Jan 31 12:23:05 jesse isn't ordering inside of a phase somewhat rending the concept of a hard and fast phase redundent
Jan 31 12:24:39 jdcasey well, the important thing we must retain about phases is the vocabulary available to the user
Jan 31 12:24:42 jdcasey IMO
Jan 31 12:24:55 jesse fair enough
Jan 31 12:25:01 jdcasey that's a compatibility issue...if we get away from even a semblance of the lifecycle, we're in m3 territory
Jan 31 12:25:26 jdcasey beyond that, I have no problem saying that "phases" are just bookmarks in the workflow
Jan 31 12:27:34 jdcasey what we could really use is a "provides"/"requires" syntax for plugins
Jan 31 12:27:54 jesse for state ya
Jan 31 12:27:59 jesse I don't think we can get awya from that
Jan 31 12:28:00 jdcasey ...then somehow overlay the phase names on top of that...if they don't jive, throw an exceptoin
Jan 31 12:28:04 jdcasey nope, agreed
Jan 31 12:28:32 jesse a DAG DOM validator :P
Jan 31 12:28:38 jdcasey that would help a lot of things...though you could argue: what if multiple mojos provide the requirement for another mojo? how does it sort out then?
Jan 31 12:28:56 jdcasey now, if only we could find an acronym for DAG-GUM :)
Jan 31 12:29:15 jesse throw an exception
Jan 31 12:29:22 jdcasey hmm
Jan 31 12:29:27 jesse hrm
Jan 31 12:29:31 jesse no
Jan 31 12:29:33 jdcasey aspectj and javac could be used together
Jan 31 12:29:38 jdcasey hmm
Jan 31 12:30:12 jdcasey I dunno, I'm almost in favor of just forgetting all of this detection and going with an explicit <ordering/> type element
Jan 31 12:30:14 jesse lemme mock something
Jan 31 12:30:16 jdcasey <lifecycleManagement/>
Jan 31 12:30:18 jdcasey ok
Jan 31 12:30:19 jesse ya
Jan 31 12:30:29 jesse _exactly_ what I was just going to mock
Jan 31 12:30:33 jdcasey the detection/magic has gotten us in trouble inthe past
Jan 31 12:30:44 jesse only problem is muliiple execution of the same plugin
Jan 31 12:31:11 jesse then you need to intrduction executionId into =it
Jan 31 12:31:26 jdcasey well, the ordering would have to have execution resolution, not just mojo resolution, IMO
Jan 31 12:31:36 jdcasey right
Jan 31 12:31:57 jdcasey and executionId all of a sudden becomes a much more important figure, where it's sort of a redheaded stepchild now
Jan 31 12:32:15 jesse just smells dirty...
Jan 31 12:32:21 jdcasey which IMO would be a good thing...it makes inheritance less quirky if people are thinking about it
Jan 31 12:32:26 jdcasey :)
Jan 31 12:32:30 jdcasey hmm
Jan 31 12:33:06 jdcasey part of the problem is that we don't have a good, consistent way of referencing a plugin/mojo/execution with a terse syntax...which means <lifecycleManagement/> could get ugly real quick
Jan 31 12:33:29 jdcasey we need to standardize on g:a[:v]:mojo:execId, if we go to lifecycleMgmt
Jan 31 12:33:31 jdcasey IMO
Jan 31 12:33:53 jesse exactly
Jan 31 12:34:05 jdcasey and actually, g:a[:v]:mojo[:execId] where version is discovered, and execId defaults to 'default'
Jan 31 12:34:25 jesse putting <plugin><aid>gid>ve is tediuous for that
Jan 31 12:34:25 jdcasey we do something like this in the components.xml now, but it's handled in the lifecycle executor, and it's ugly
Jan 31 12:34:29 jdcasey we could make it more formal
Jan 31 12:34:36 jdcasey exactly
Jan 31 12:34:45 jdcasey I'd hate it, I can tell you thta
Jan 31 12:34:47 jdcasey that
Jan 31 12:35:08 jesse does Artifact have a toString() that makes it pretty and machine usable?
Jan 31 12:35:20 jdcasey would be nice to have shorthand, too...like: <otherBindings/> so you can do:
Jan 31 12:35:46 jdcasey <phase><binding>g:a:v:m:e</binding><otherBindings/></> to specify that one is definitely first
Jan 31 12:44:13 jdcasey though I do think in the wider context, we'll need to make execIds more prominent...if we're after suppression too...
Jan 31 12:44:37 jesse ok, so its at the execid point and not plugin
Jan 31 12:45:05 jdcasey well, if you can have compiler running for two purposes at different points, you have to have the precision to affect one and not the other
Jan 31 12:45:12 jdcasey think antrun instead of compiler if you like
Jan 31 12:45:20 jesse sure
Jan 31 12:45:31 jdcasey IMO, affecting the plugin as a whole is heavy-handed, and won't be too useful
Jan 31 12:45:36 jesse this is a shitty problem, pardon my language
Jan 31 12:45:48 jdcasey well, yeah, in a way it is
Jan 31 12:46:12 jdcasey but it's funny that we added functionality for additive lifecycle mappings, but no subtraction or replacement...don't you think?
Jan 31 12:46:20 jesse ok, another solution other then #s
Jan 31 12:46:27 jdcasey k
Jan 31 12:46:36 jesse <before> and <after> syntax on execution id's
Jan 31 12:46:46 jesse execution id's become a global ordeal
Jan 31 12:46:53 jdcasey so you say before-some-other-execId?
Jan 31 12:46:58 jesse <ebfore>execId
Jan 31 12:47:01 jdcasey hmm
Jan 31 12:47:10 jdcasey damn, this does suck
Jan 31 12:47:12 jesse then you can build the DAG and look for collisions
Jan 31 12:47:20 jesse execID needs tobe global then though
Jan 31 12:47:25 jdcasey ick
Jan 31 12:47:37 jesse global to the phase at least
Jan 31 12:47:49 jdcasey hmm
Jan 31 12:47:49 jesse might be the simplest though
Jan 31 12:48:27 jdcasey what about <before>g:a:v:e[:m]</>, and use that instead of <phase/> ?
Jan 31 12:48:42 jdcasey we could still use phase for additions
Jan 31 12:48:56 jesse oh!
Jan 31 12:48:59 jdcasey this would be relative positioning, as opposed to normal
Jan 31 12:49:08 jesse <before> <after> <replace>
Jan 31 12:49:16 jdcasey yup
Jan 31 12:49:18 jesse all operating off of execId
Jan 31 12:49:20 jdcasey that's what I was thinking
Jan 31 12:49:30 jesse execid can be freeform like it is now
Jan 31 12:49:38 jdcasey though we should probably preserve <phase/> in there too...for don't-care conditions
Jan 31 12:49:44 jesse but we can recommend the convention of your idea up there
Jan 31 12:49:50 jesse totally
Jan 31 12:49:52 jesse acutally
Jan 31 12:49:56 jesse you still need it there
Jan 31 12:50:02 jdcasey so it'd use a global execId search, or only within a specified plugin?
Jan 31 12:50:08 jdcasey how so?
Jan 31 12:50:14 jdcasey need the phase, you mean?
Jan 31 12:50:17 jesse inside the _phase_
Jan 31 12:50:27 jdcasey so before requires phase?
Jan 31 12:50:30 jesse if there is not phase then its the plugin phase
Jan 31 12:50:41 jdcasey the one it's referencing?
Jan 31 12:50:42 jesse but the Phase concept is a req
Jan 31 12:50:46 jdcasey yup, agreed
Jan 31 12:50:51 jesse exec can have a phase in it
Jan 31 12:50:56 jdcasey so, you have two things happening here
Jan 31 12:50:56 jesse for overrideing hte plugin phase
Jan 31 12:51:11 jdcasey absolute addition, with no other plugin for reference of positioning, etc.
Jan 31 12:51:29 jdcasey and relative addition, etc. with a reference plugin for relative positioning
Jan 31 12:51:56 jdcasey and relative specifications would override the @phase just like <phase/> does
Jan 31 12:52:49 jdcasey now, for suppression, I guess you could have a <skip/> inside the execution...
Jan 31 12:52:50 jesse I would actually throw an exception on #3
Jan 31 12:52:57 jdcasey really?
Jan 31 12:53:15 jdcasey we don't on <phase/> overrides...why on <before/> ?
Jan 31 12:53:23 jesse if you claim <ebfore>foo and your not in the same phase as foo then cry foul
Jan 31 12:54:00 jesse foo wouldn't appear in the phase execId's
Jan 31 12:54:09 jesse so it wouldn't know where to put it in the graph
Jan 31 12:54:17 jesse if execi'd are global the phase
Jan 31 12:54:36 jesse i r a gud spelr
Jan 31 12:54:40 jdcasey yeah, ok...got that
Jan 31 12:55:00 jdcasey hmm, lunch time here...
Jan 31 12:55:05 jesse skip is a problem
Jan 31 12:55:11 jdcasey why is that?
Jan 31 12:55:27 jesse <skip> is absolution, supression is deterministic isn't it?
Jan 31 12:55:57 jesse ugh
Jan 31 12:56:09 jesse I need to understand supression better I think
Jan 31 12:56:21 jdcasey suppress would basically mean "take this out of the lifecycle map"
Jan 31 12:56:30 jdcasey I was using it interchangeably with skip
Jan 31 12:56:32 jesse it seems like <skip> ought to be a plugin thing
Jan 31 12:56:58 jesse cause if you want to skip and exec, just don't put it in :)
Jan 31 12:57:11 jdcasey not sure i agree...if the plugin dev fails to provide it, the user is screwed...also, it means a proliferation of skip* params
Jan 31 12:57:26 jesse no no
Jan 31 12:57:34 jesse not in the config of the plugin
Jan 31 12:57:41 jesse sibling to <version>
Jan 31 12:57:52 jesse on the plugin objecy
Jan 31 12:57:53 jdcasey ah
Jan 31 12:58:06 jdcasey makes sense to me
Jan 31 12:58:15 jdcasey knock out all related functionality
Jan 31 12:58:20 jesse yep
Jan 31 12:58:44 jesse it would be equivalent to skiping the lifecycle for lots of these things
Jan 31 12:58:48 jdcasey though I do have a use case where I want to skip only a single mojo in the plugin...
Jan 31 12:59:00 jdcasey skip make:install, but not make:compile or make:check
Jan 31 12:59:13 jesse o.O
Jan 31 12:59:31 jesse thats one plugin? :)
Jan 31 12:59:50 jdcasey yup...it's all related functionality, and uses the same infra
Jan 31 12:59:55 jesse that plugin applies to multiple phases
Jan 31 13:00:06 jdcasey compiler plugin does too
Jan 31 13:00:06 jesse oh!
Jan 31 13:00:24 jesse <skip/> global, <skip>mojo,mojo</skip>
Jan 31 13:00:49 jdcasey that's a cool idea...
Jan 31 13:01:17 jesse lets you wack out the whole thing or a particular mojo
Jan 31 13:01:31 jdcasey all exec's, though...it's a good clean soln
Jan 31 13:01:34 jesse <skip>MakeInstallMojo</skip>
Jan 31 13:01:56 jdcasey yup
Jan 31 13:02:08 jesse <before> <after> <replace> on the exec, and <skip~/> on the plugin object
Jan 31 13:02:21 jdcasey cool. I'm going to write this up and send it to dev@
Jan 31 13:02:25 jesse exec id's are phase global
Jan 31 13:02:26 jdcasey do you mind me quoting this?
Jan 31 13:02:31 jdcasey right
Jan 31 13:02:52 jesse go for it, you can wack out my brain dump bits, maybe just this idea part
Jan 31 13:03:02 jdcasey yup, cool
Jan 31 13:03:37 jdcasey bbiab
Jan 31 13:03:40 jesse cool
Jan 31 13:14:42 jesse can I mention this on joakim's pre and post test thread?
Jan 31 13:14:57 jesse just that john has something coming that ought to address this..:)
Jan 31 13:16:55 jdcasey yeah, that'd be cool.
Jan 31 13:17:08 jdcasey I'm going to head to campus, then I'll write it up and submit it.
Jan 31 13:56:01 * Disconnected ().
Jan 31 16:01:53 jdcasey ok, almost got this proposal written up
Jan 31 16:02:43 jdcasey I think we may need to skip executions, though...it's possible that a particular binding is the offender, not necessarily the entire functionality of the mojo in all places...does that sound reasonable?
Jan 31 16:03:31 jesse o.O
Jan 31 16:03:37 jdcasey no?
Jan 31 16:04:05 jesse what is the difference between skip on an exec and just commenting it ouy?
Jan 31 16:04:07 jesse out?
Jan 31 16:04:22 jdcasey how do you comment it out if it's in a parent pom?
Jan 31 16:04:47 jesse ack
Jan 31 16:05:01 jdcasey I'm not saying it has to be only all-plugin or by-exec...I'm saying it needs to be all-plugin, all-mojo, or by-exec
Jan 31 16:05:24 jesse <skip>execid,execid</skip> on a exec then?
Jan 31 16:05:48 jdcasey hmm, placement is tricky...I think it should still be a child of <plugin> personlly
Jan 31 16:06:08 jdcasey use <skip>g:a:v:e,...</skip>
Jan 31 16:06:22 jesse could you get this with <replace>?
Jan 31 16:06:28 jdcasey or <skip>mojo1,g:a:v:e(uses mojo2)</skip>
Jan 31 16:06:37 jdcasey you can if you have something to replace with
Jan 31 16:06:46 jdcasey and you can play around it by using a noop plugin to replace with
Jan 31 16:07:01 jesse no, that would still run it with defaults.
Jan 31 16:07:23 jdcasey sorry, not following
Jan 31 16:07:47 jesse replace implys your still in an exec and are replacing one upstream
Jan 31 16:08:10 jesse so its still a valid exec and would run with defaults, not skip it
Jan 31 16:08:27 jesse noop plugin wouldn't help, exec is in a plugin
Jan 31 16:08:56 jesse k, I am cool with your notation I guess
Jan 31 16:09:07 jdcasey I meant that the noop plugin would specify an execution that replaces the one in the other plugin
Jan 31 16:09:21 jesse oh!
Jan 31 16:09:25 jesse yes, that would work
Jan 31 16:09:43 jdcasey but, it would be more elegant to simply say 'skip that antrun execution completely'
Jan 31 16:09:47 jesse <skip> might have too much diverse functionality otherwise
Jan 31 16:09:50 jdcasey less cruft
Jan 31 16:09:54 jdcasey hmm
Jan 31 16:10:18 jesse mixing mojo1, and this other notation is not elegant imo
Jan 31 16:10:28 jdcasey agreed
Jan 31 16:10:44 jdcasey I don't like the syntax of comma-delimited lists, actually
Jan 31 16:10:46 jdcasey but that's a detail
Jan 31 16:10:47 jdcasey IMO
Jan 31 16:10:48 jesse a noop plugin requires forethouht at least...I kinda like it
Jan 31 16:11:02 jesse <skips><skip> :)
Jan 31 16:11:29 jdcasey <skip><goals><goal>mojo1</></><executions><execution>exec1</></></>
Jan 31 16:11:31 jdcasey maybe?
Jan 31 16:11:44 jdcasey <skip><all/></> :)