Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
No Format
Feb 01 10:43:01 jdcasey	two things came up in my mind last night
Feb 01 10:43:27 jdcasey	first, I was thinking about something brett mentioned about this approach for replacement of mojo bindings violating DRY
Feb 01 10:44:36 jdcasey	I think he's got a point. I think the declaration for the replacement target should have to disable that plugin/mojo/execution before it can be replaced, otherwise throw an error
Feb 01 10:44:51 jdcasey	that way, you can always look at that plugin decl to see what's up with it
Feb 01 10:45:03 jdcasey	if it's disabled, you'll see it there...
Feb 01 10:45:18 jdcasey	small price for a lot of clarity, IMO
Feb 01 10:45:41 jesse	not following, sorry
Feb 01 10:45:59 jdcasey	the other thing I was thinking is that we may not have a lot of use for a disable-mojo command...I'd tend to think only <disablePlugin>true/false</> and <disableExecution>true/false</>
Feb 01 10:46:02 jdcasey	oh, ok
Feb 01 10:46:04 jesse	whats getting repeated?
Feb 01 10:46:16 jdcasey	it's not just about repeating...hang on
Feb 01 10:46:29 jdcasey't_repeat_yourself
Feb 01 10:46:56 jesse	I like the disablePlugin boolean, +1
Feb 01 10:46:59 jdcasey	last sentence in first para
Feb 01 10:47:02 jdcasey	cool
Feb 01 10:47:11 jdcasey	sorry, second-last
Feb 01 10:47:24 jdcasey	"a modification of any single element of a system does not change other logically-unrelated elements"
Feb 01 10:47:49 jdcasey	if we have a replace command in one plugin that effectively disables part of another, that could be very difficult to track down
Feb 01 10:47:54 jdcasey	you see what I mean?
Feb 01 10:47:58 jesse	the whole idea of replacement was because you don't have access tot he upstream definition though
Feb 01 10:48:04 jdcasey	hmm, yeah
Feb 01 10:48:10 jdcasey	though you'd have to know the executionId
Feb 01 10:48:16 jdcasey	right?
Feb 01 10:48:19 jesse	yep
Feb 01 10:48:39 jdcasey	so, you can re-declare that executionId in your POM, and disable it first
Feb 01 10:48:42 jesse	its for undoing something someone did upstream, you said etrade wanted this
Feb 01 10:48:58 jdcasey	the whole point of having executionIds in the first place was to allow merging of execution info during inheritance
Feb 01 10:48:59 jesse	that sees like repeating yourself though
Feb 01 10:49:23 jdcasey	well, but it's contained in the same plugin decl, and when you run help:effective-pom, it'll show up as one thing
Feb 01 10:49:30 jdcasey	hmm
Feb 01 10:49:53 jdcasey	it's a little more verbose than I'd like
Feb 01 10:49:55 jesse	replace is mergeing the concept of disable
Feb 01 10:50:09 jdcasey	disable + addition-with-order
Feb 01 10:50:11 jdcasey	yup
Feb 01 10:50:18 jesse	actually
Feb 01 10:50:27 jesse	its more like overriding a method
Feb 01 10:50:43 jesse	and you don't declare the overriding of a method in java or c, you just do it
Feb 01 10:50:59 jesse	which would imply not needing replace at all
Feb 01 10:51:05 jdcasey's not a 1:1 analogy, because you could redeclare the execution with config and all in a child POM...that'd be more like overriding, I'd think
Feb 01 10:51:09 jdcasey	but sure, it's similar
Feb 01 10:51:15 jesse	just a WARNING that you are overwriting a previous definition
Feb 01 10:51:39 jdcasey	you're assuming the executionId has meaning outside of the plugin declaration, which it currently does not
Feb 01 10:51:50 jesse	its global to a phase
Feb 01 10:51:50 jdcasey	b/c otherwise, there's no way to override from outside that plugin
Feb 01 10:51:58 jdcasey	I don't think it is, currently
Feb 01 10:52:15 jdcasey	I'm pretty sure it's just a merge target within a plugin declaration
Feb 01 10:52:27 jesse	well, that was part of the discussion yesterday, it has to be global to allow smoking with a noop plugin or something
Feb 01 10:52:30 jdcasey	(unless something has changed since I wrote it)
Feb 01 10:52:34 jdcasey	I see
Feb 01 10:52:49 jdcasey	...but if we have a disable element for executions, we don't need noop
Feb 01 10:52:50 jdcasey	right?
Feb 01 10:52:58 jdcasey	it's cleaner than noop
Feb 01 10:53:02 jdcasey	it's built-in
Feb 01 10:53:18 jesse	so long as there is a disable and the default execution of the plugin doesn't happen
Feb 01 10:53:58 jesse	which if there is only one exec and you disable it then when its all merged up it will execute the default plugin exec since no exec's would exist...maybe
Feb 01 10:54:08 jdcasey	yup...well, that's another thing...the mojos in a lifecycle mapping in components.xml only have an _implied_ execId of 'default' fwiw
Feb 01 10:54:43 jdcasey	if it's in the mapping, you should be able to manipulate it using the 'default' execId
Feb 01 10:55:07 jdcasey	if it's not in the mapping, and you disable all executions, nothing should run from that plugin...
Feb 01 10:55:16 jdcasey	it'll be dormant
Feb 01 10:55:27 jesse	my fear here is that this is going to lead to 'libraries' of poms that you would inherit from and then just chose the bits and pieces you want
Feb 01 10:56:08 jdcasey	that can't really happen on a large scale unless we allow mixins or multiple inheritance...since you'll have your own parent POM hierarchy...right?
Feb 01 10:56:23 jesse	maven is nice because your build is your build and there is one superpom of conventions..
Feb 01 10:56:27 jdcasey	the only thing you could do is inherit from one of those library poms at the head of your hierarchy
Feb 01 10:56:50 jesse	company pom -> 3 libraries -> choose one as your parent -> project
Feb 01 10:56:54 jdcasey	well, sort of. you still have lifecycle mappings that can change according to which extension you use
Feb 01 10:57:05 jdcasey	that exists today, though
Feb 01 10:57:08 jdcasey	right?
Feb 01 10:57:31 jdcasey	the "library pom" is named for the type of project it represents, or configures
Feb 01 10:57:34 jdcasey	like webapp-parent
Feb 01 10:57:38 jesse	yes, but the concept of forcing your children to undo what you declare isn't so much
Feb 01 10:58:14 jdcasey	no, it's impossible to undo right now, except where individual plugins have a skip param
Feb 01 10:59:18 jesse	it feels like we are replacing a unified build philosopy where decisions have cause and effect with one where anything goes, you just grab what you want and disable the rest
Feb 01 10:59:18 jesse	ie ant
Feb 01 10:59:43 jdcasey	but the reality is that for a large development setup (like, I imagine, jakarta), you'll want to cover as much of the 80% scenario as you can, and allow enough flexibility for the 20% to make the mods they need to get by...right?
Feb 01 10:59:52 jdcasey	it takes the most load off the system that way
Feb 01 11:00:10 jdcasey	otherwise everyone always has to add something, because you're using least-common denominator
Feb 01 11:01:00 jdcasey	I'm not sure I understand why, though...
Feb 01 11:01:27 jdcasey	it's not really allowing just's just the same as adding a new plugin to the build, except in reverse.
Feb 01 11:01:29 jesse	right now the 20% is additive
Feb 01 11:01:46 jdcasey	actually, 80/20 isn't approachable
Feb 01 11:02:01 jdcasey	because you can't get to the 80%-with-no-extra-config point
Feb 01 11:02:27 jdcasey	not without screwing up the 20%, or introducing a multitude of parent POMs
Feb 01 11:05:44 jesse	ok, brett;s issue with replace is what exactly? that you need to redeclare it and then <skip> it and then declare another with the same execiD?
Feb 01 11:05:53 jdcasey	at any rate, I was thinking that forcing the user to explicitly disable the execution before replacing it would make it easier for someone else to come along and understand why that (disabled) execution wasn't running
Feb 01 11:06:12 jdcasey	I'm not clear on his exact issue with it, other than it not being a total solution by itself
Feb 01 11:06:21 jesse	but doens't replace>execid<> already communicate that?
Feb 01 11:06:33 jdcasey	it does, but it's hidden in some other plugin
Feb 01 11:06:36 jdcasey	that's the key
Feb 01 11:06:42 jesse	it seems totally more consice
Feb 01 11:06:46 jesse	concise
Feb 01 11:07:00 jdcasey	you're wondering what's wrong with plugin A...and why it's not're not looking at plugin B, which declares a replacement
Feb 01 11:07:04 jdcasey	yeah, it is
Feb 01 11:07:13 jdcasey	but I'm worried it's not clear enough
Feb 01 11:07:31 jdcasey	I'm worried it'll feel like being ambushed when you're trying to debug the build
Feb 01 11:07:51 jesse	exec is global to a plugin in a phase then
Feb 01 11:07:58 jesse	not global to a phase
Feb 01 11:08:11 jdcasey	it's global to a plugin, period, right now
Feb 01 11:08:24 jdcasey	b/c an exec can actually span multiple phases (ick)
Feb 01 11:08:31 jesse	if thats the default then having the exec replaced somewhere is irrelvent
Feb 01 11:08:33 jdcasey	you just leave off the <phase/>
Feb 01 11:08:56 jdcasey	hmm
Feb 01 11:09:05 jesse	you don't need replace then
Feb 01 11:09:14 jdcasey	why is that?
Feb 01 11:09:20 jesse	just disable in the other plugin and declare your new one
Feb 01 11:09:26 jesse	funcationally equivalent
Feb 01 11:09:43 jdcasey	yeah, but it's important to preserve the ordering of the new mojo with where the old one was bound
Feb 01 11:09:47 jesse	execid is a non-issue then
Feb 01 11:09:48 jdcasey	that's key
Feb 01 11:09:57 jdcasey	it could be the wrong issue
Feb 01 11:10:10 jdcasey	it's too damned ambiguous
Feb 01 11:10:12 jesse	you would then duplicate the before/after in the new decl
Feb 01 11:10:28 jesse	I am cool with this
Feb 01 11:10:59 jdcasey	hmm
Feb 01 11:11:00 jesse	replace is more concise, but verbose can be a good thing
Feb 01 11:11:08 jdcasey	so, how would you declare before/after, though?
Feb 01 11:11:35 jdcasey	damn, why did I allow this crap with executions spanning phases?
Feb 01 11:11:37 jesse	hm, execid still needs to be global to a phase
Feb 01 11:11:49 jdcasey	and scoped within that phase, IMO
Feb 01 11:11:54 jesse	for ordering purposes
Feb 01 11:12:04 jesse	yep
Feb 01 11:12:14 jdcasey	well, you pair plugin id with exec id, and you don't need global-execId
Feb 01 11:12:36 jesse	yI stil think that if your dealing with this complexity its trivial to grep for the execid
Feb 01 11:12:47 jdcasey	but when you say "put it just before execA" and execA spans compile, install, and deploy, where do you put it? just before compile?
Feb 01 11:12:47 jesse	ah right
Feb 01 11:13:04 jdcasey	that's ugly, but I suppose it'd work
Feb 01 11:13:04 jesse	_._
Feb 01 11:13:12 jdcasey	what's that?
Feb 01 11:13:24 jesse	execA spans  compile, install, and deploy, where do you put it?
Feb 01 11:13:42 jesse	yuck
Feb 01 11:13:58 jdcasey	yup, yuck indeed
Feb 01 11:14:00 jesse	I don't think ghtat should be possible
Feb 01 11:14:03 jdcasey	I hate that we allowed that
Feb 01 11:14:11 jesse	that violates the lifecycle
Feb 01 11:14:18 jdcasey	you mean order-before something like that?
Feb 01 11:14:22 jdcasey	no, what I mean is this:
Feb 01 11:14:34 jdcasey	you have three mojos that each declare @phase
Feb 01 11:15:00 jdcasey	you can put them in a single execution, leave off <phase/>, and provide configuration, and it'll configure and bind each to the appropriate phase given by @phase
Feb 01 11:15:12 jdcasey	<gag>
Feb 01 11:15:13 jesse	ah
Feb 01 11:15:39 jdcasey	but we have too much ambiguity in this system, and that was a way of handling two locations for phase declaration
Feb 01 11:16:22 jesse	k, regardless...all of this needs to boil down into a DAG
Feb 01 11:16:37 jesse	with no cycles
Feb 01 11:17:01 jesse	and if we decide on a strict naming convention of the nodes of that DAG
Feb 01 11:17:09 jdcasey	agreed...and to do any ordering/replacement type thing, you'll need some primary key to go after for the index
Feb 01 11:17:16 jesse	we can easily allow for people to shove stuff into it
Feb 01 11:17:18 jdcasey	sure
Feb 01 11:17:33 jdcasey	the strictest naming convention for that DAG is: g:a:v:e:m
Feb 01 11:17:48 jdcasey	that tells beyond a doubt where you are
Feb 01 11:18:05 jesse	gavme? or gavem
Feb 01 11:18:10 jdcasey	em
Feb 01 11:18:16 jesse	k
Feb 01 11:18:21 jdcasey	because an execution can have multiple mojos
Feb 01 11:18:37 jdcasey	a mojo can be in multiple executions too, but this should work for both, I'd say
Feb 01 11:18:47 jesse	so if its replace>gavem</
Feb 01 11:18:49 jdcasey	you find that in a lifecycle mapping, and you'll always have a single place
Feb 01 11:18:54 jesse	that ought to be clear enough
Feb 01 11:19:24 jesse	that replaces the whole node in the graph
Feb 01 11:19:32 jdcasey	well, though I still think we need to require that the replacement target should be disabled before it can be replaced
Feb 01 11:19:41 jdcasey	yes
Feb 01 11:19:44 jesse	adding in the notation to skip that removes the node all together
Feb 01 11:19:53 jdcasey	right
Feb 01 11:20:18 jesse	and we need a plugin help tool that dumps the DAG out
Feb 01 11:20:24 jdcasey	yes
Feb 01 11:20:40 jesse	I say skip the skip thing and provide tooling to debug
Feb 01 11:20:49 jdcasey	call it help:plan or something...that may be too database-ish, though
Feb 01 11:21:03 jesse	its needlessly verbose for the edge case of someone trying to figure it out
Feb 01 11:21:14 jesse	help:build-order
Feb 01 11:21:19 jdcasey	hmm
Feb 01 11:21:40 jesse	IE to do ONE thing I need to change TWO places
Feb 01 11:21:47 jdcasey	I understand what you're saying, I'm just not too wild about depending on tooling as the sole means of figuring this stuff out
Feb 01 11:21:54 jdcasey	yup, understood
Feb 01 11:21:58 jdcasey	*shrug*
Feb 01 11:22:08 jesse	doing it that way seems to violate DRY :)
Feb 01 11:46:41 jdcasey	so, we're settled on replace, disablePlugin/disableExecution, and before/after for ordering on straight addition?
Feb 01 11:46:47 jdcasey	or, what do you think?
Feb 01 11:46:54 jdcasey	I think you're probably right about the replacement stuff
Feb 01 11:47:14 jdcasey	two moves is a pita, and we can handle debugging with tools
Feb 01 11:47:16 jesse	and the help tooling for dumping the exec DAG
Feb 01 11:47:21 jdcasey	just like we do with help:effective-pom
Feb 01 11:47:23 jdcasey	right
Feb 01 11:47:27 jesse	q:
Feb 01 11:47:32 jdcasey	ya?
Feb 01 11:47:44 jesse	do we enforce the gavem naming convention?
Feb 01 11:47:49 jesse	i say yes
Feb 01 11:48:13 jdcasey	that, or we adopt a modified artifact stanza for it, IMO
Feb 01 11:48:27 jdcasey	the artifact stanza is more conventional, and might be more intuitive
Feb 01 11:48:28 jesse	right right, like everything else