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