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
[SNIP]
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
[SNIP]
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
[SNIP]
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
[SNIP]
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/></> :)
  • No labels