Displaying #maven/2016-11-05.log:

Sat Nov 5 00:11:45 2016  fredcooke:stephenc: Link to the source and/or config of the bot? Re my earlier questions, and also perhaps some sort of help command?
Sat Nov 5 01:25:56 2016  HoierM:Joined the channel
Sat Nov 5 08:10:32 2016  lefou:Joined the channel
Sat Nov 5 08:24:01 2016  jknetl:Joined the channel
Sat Nov 5 09:27:13 2016  onu:Joined the channel
Sat Nov 5 10:15:10 2016  dandan86:Joined the channel
Sat Nov 5 10:45:50 2016  dandan86:Joined the channel
Sat Nov 5 11:03:18 2016  rfscholte:Joined the channel
Sat Nov 5 11:11:00 2016  hjd:Joined the channel
Sat Nov 5 11:13:55 2016  thc202:Joined the channel
Sat Nov 5 11:21:22 2016  stephenc_:Joined the channel
Sat Nov 5 11:21:56 2016  stephenc_:rfscholte: am on phone client. Are you there?
Sat Nov 5 11:22:17 2016  rfscholte:yes
Sat Nov 5 11:22:27 2016  stephenc_:Ok. Cool
Sat Nov 5 11:22:49 2016  stephenc_:So I have been thinking about MNG-5384
Sat Nov 5 11:23:28 2016  rfscholte:reading
Sat Nov 5 11:24:50 2016  stephenc_:I'm thinking if we could define "substitutions" and plugin mojos could advertise producing artifact's
Sat Nov 5 11:25:12 2016  stephenc_:That way jar:jar could advertise producing a jar
Sat Nov 5 11:26:00 2016  stephenc_:But perhaps jar:stage could just produce the substitution jar-dir and be bound to process-classes say
Sat Nov 5 11:26:38 2016  stephenc_:Then surefire:test can say it wants dependencies of type jar (but will accept substitutions of type jar-dir)
Sat Nov 5 11:27:32 2016  rfscholte:that would also solve another problem: dependency:tree now requires a compile in case of multimodule, but Maven should be able to know the artifacts upfront
Sat Nov 5 11:28:13 2016  rfscholte:also the reason why I wanted to remove finalNames in the plugin-configuration, just set project.build.finalName
Sat Nov 5 11:28:40 2016  stephenc_:Then when we build the multimodual reactor for phase test we would know that other dependent modules need to be driven to at lease process-classes in order to get at least the jar-dir dependency... but where we have driven specific modules as far as package for say other reasons, those would get their jar dependency as the ideal
Sat Nov 5 11:29:03 2016  stephenc_:Also we can generalise to war and war-dir
Sat Nov 5 11:29:39 2016  stephenc_:If I am building an overlay war I don't have to package the base war, I just need the war-dir
Sat Nov 5 11:30:13 2016  rfscholte:It would be great if Maven could know all main and attached artifacts during build-plan
Sat Nov 5 11:30:29 2016  stephenc_:Can you create a MNG for removing finalName and tag is for Pom changes
Sat Nov 5 11:30:57 2016  stephenc_:I don't know if we can know all up front, but we can know intent
Sat Nov 5 11:31:38 2016  stephenc_:As I see it, with the 5.0.0 Pom I think we can remove the need for special goals like jar:test-jar
Sat Nov 5 11:33:14 2016  stephenc_:The jar goal would declare which scopes it wants to use when attaching the artifacts, so I can have two executions, one pulling the compile and runtime scopes, the other pulling compile, runtime and test
Sat Nov 5 11:33:25 2016  stephenc_:That would be done by execution specific configuration
Sat Nov 5 11:33:58 2016  rfscholte:just to be clear: you want to remove finalName from build-section?
Sat Nov 5 11:34:04 2016  stephenc_:So that if a user then needs e.g. An integration test jar, they can supply the scopes to the jar:jar execution
Sat Nov 5 11:34:42 2016  stephenc_:rfscholte: that's what you asked for yes? (And doesn't make sense now that Pom 5.0.0 removes the concept of a single primary artifact)
Sat Nov 5 11:34:57 2016  stephenc_:At least AIUI
Sat Nov 5 11:35:20 2016  rfscholte:no, I asked to remove it from per plugin configuration
Sat Nov 5 11:35:36 2016  rfscholte:and that's already done for several plugins
Sat Nov 5 11:35:44 2016  stephenc_:Ah ok. Cool
Sat Nov 5 11:36:54 2016  stephenc_:I thought you were looking to remove finalName from build and if that was the case I'd just want a MNG to track and review... no need for plugin specific configuration changes IMHO as that does not affect the scheme
Sat Nov 5 11:38:26 2016  stephenc_:What I want to be able to do is stop needing to eg replicate the compiler:compile goal for every different phase of compilation
Sat Nov 5 11:39:43 2016  stephenc_:So I think we shouldn't need compiler:testCompile or further compiler:integrationTestCompile... compiler:functionalTestCompile... compiler:acceptanceTestCompile, etc
Sat Nov 5 11:40:14 2016  rfscholte:that might work with classpaths, but not with modulepaths.
Sat Nov 5 11:40:33 2016  stephenc_:A compile goal that takes as input a list of dependency scopes is what I see
Sat Nov 5 11:40:46 2016  rfscholte:unless we can inject some phase-based path builders
Sat Nov 5 11:41:25 2016  stephenc_:Well yes this is the tricky part
Sat Nov 5 11:43:11 2016  stephenc_:So I see test-compile needing the "main" jar but accepting the "main" jar-dir plus all the compile, provided, and test scope dependencies of type jar (but accepting jar-dir as a substitute)
Sat Nov 5 11:44:13 2016  stephenc_:Forgetting how we expose that configuration... how would that play with Java 9 modules
Sat Nov 5 11:45:33 2016  stephenc_:(Obviously there would need to be some symbiotic relationship between the plugin configuration and its declaration of interest in artifacts and declaration of intent to publish)
Sat Nov 5 11:46:06 2016  rfscholte:as long as Maven is aware of the main-code and as we can assume that all other test-compilations are based on this main, then we should be good.
Sat Nov 5 11:47:52 2016  stephenc_:Yes the configuration of the compile goal bound to test-compile would need to have overrides e.g. Setting the module identifier to be a different default ID than the ID used when bound to compile
Sat Nov 5 11:48:46 2016  stephenc_:I think we need a level of indirection for "substitutions"
Sat Nov 5 11:49:27 2016  stephenc_:E.g. In some cases a ZIP can be added to a classpath just like a Jar can
Sat Nov 5 11:51:01 2016  stephenc_:And people inventing custom file types may want to be able to say "these should be treated exactly like a jar... in fact we build them with jar:jar just giving a different extension... but surefire should slurp them up and put on test classpath"
Sat Nov 5 11:51:29 2016  stephenc_:Currently we do that by having the custom packaging say "classpath compatible"
Sat Nov 5 11:52:03 2016  rfscholte:yeah, and I don't like that flag
Sat Nov 5 11:52:25 2016  stephenc_:But that smacks of too much Java-centricity... plus it requires consumers to add the custom packaging to their Pom so that their surefire is aware they are classpath compatible
Sat Nov 5 11:53:16 2016  rfscholte:there should be no reference to a classpath in Maven Core. It is a (java) maven-plugin thing
Sat Nov 5 11:53:48 2016  stephenc_:If we add an element to the PDT that allows advertising the conventions that this artifact follows... one of those could be "classpath"
Sat Nov 5 11:54:29 2016  stephenc_:Similarly a war would follow the "javaee-webapp" convention
Sat Nov 5 11:55:01 2016  stephenc_:Perhaps classpath is "java-classpath" or "java:classpath"
Sat Nov 5 11:55:47 2016  rfscholte:the <packaging> should trigger some kind of language-context for all plugins to use.
Sat Nov 5 11:55:52 2016  stephenc_:But in any case, surefire would say it only wants dependencies that follow the "java:classpath" convention
Sat Nov 5 11:56:10 2016  stephenc_:I'm renaming packaging to template
Sat Nov 5 11:56:23 2016  stephenc_:At least in the current Pom 5.0.0 proposal
Sat Nov 5 11:56:53 2016  rfscholte:I noticed, I understand the concept, but it is probably hard to sell
Sat Nov 5 11:57:22 2016  rfscholte:it is a naming thingy :)
Sat Nov 5 11:57:34 2016  stephenc_:Well the main issue I see is that we then have basically three things all doing the same thing
Sat Nov 5 11:57:49 2016  stephenc_:Template/packaging, parent, mixin
Sat Nov 5 11:58:05 2016  stephenc_:They all just basically layer in defaults for the project
Sat Nov 5 11:58:25 2016  stephenc_:In fact they all can just be a Pom 5.0.0
Sat Nov 5 11:58:25 2016  rfscholte:true
Sat Nov 5 11:58:43 2016  stephenc_:This makes custom packaging easier... you just deploy a Pom
Sat Nov 5 11:59:08 2016  stephenc_:We would put some filtering on the different types
Sat Nov 5 11:59:29 2016  stephenc_:So you never inherit GAV from a template
Sat Nov 5 11:59:57 2016  stephenc_:Similarly you would never inherit repositories or distribution mgmt
Sat Nov 5 12:00:05 2016  rfscholte:that makes a lot of sense
Sat Nov 5 12:00:19 2016  stephenc_:But those things would need to be in the template in order to deploy it
Sat Nov 5 12:00:40 2016  stephenc_:So that gives a reason for making it "special"
Sat Nov 5 12:01:35 2016  stephenc_:Similarly mixins would not overwrote some stuff... unclear ATM if the mixin restrictions would be the same as template
Sat Nov 5 12:02:00 2016  stephenc_:So it is then down to sequencing and arity
Sat Nov 5 12:02:44 2016  stephenc_:You can only have one template... it gets applied *first*
Sat Nov 5 12:03:28 2016  stephenc_:You can only have up to one parent... it gets applied second
Sat Nov 5 12:03:47 2016  stephenc_:You can have any number of mixins that get applied in Pom order
Sat Nov 5 12:04:05 2016  stephenc_:The only mandatory is the template
Sat Nov 5 12:04:47 2016  stephenc_:wonders if template should be specified by GAV (with perhaps a default G if unspecified)
Sat Nov 5 12:05:44 2016  stephenc_:rfscholte: am I just thinking too generically?
Sat Nov 5 12:05:45 2016  rfscholte:I would like to see a special packaging type for aggregators. No GAV required, never released, etc.
Sat Nov 5 12:06:30 2016  stephenc_:Yep. They don't need anything much from the lifecycle (unless they are a parent)
Sat Nov 5 12:07:01 2016  stephenc_:I think a parent should have some Validation's applied to stop hijacking for custom stuff
Sat Nov 5 12:07:46 2016  rfscholte:it is a lot, we should come with a good order with some experimental things. probably start with the parts that have quite a lot of impact to ensure those parts work.
Sat Nov 5 12:07:52 2016  stephenc_:With the ability to define a custom lifecycle and bindings in the Pom directly, there should be no need to hijack packaging=Pom to do custom packaging
Sat Nov 5 12:08:38 2016  stephenc_:I'm aiming for a vision of where we want to get to... (ok where I think we want to get to)
Sat Nov 5 12:08:48 2016  rfscholte::)
Sat Nov 5 12:09:03 2016  stephenc_:Once I have that vision I want to see if there is a path there
Sat Nov 5 12:09:35 2016  stephenc_:When I think of maven, I see it as a declarative build engine
Sat Nov 5 12:09:57 2016  rfscholte:there are a lot of things I like in the proposals, just need to make sure we all understand it and that it is indeed helping maven-users
Sat Nov 5 12:10:07 2016  stephenc_:People see it as declarative in dependencies... because they have to hack the lifecycles
Sat Nov 5 12:10:43 2016  stephenc_:But IMHO the original vision was declarative in build *and* dependencies
Sat Nov 5 12:11:37 2016  rfscholte:4.0.0 isn't that bad, but meanwhile there's a need for new features
Sat Nov 5 12:12:03 2016  stephenc_:I see eg JvZ wanting to rip out say the site lifecycle... and instead I see that as just another build lifecycle... just one that produces a different set of artifacts
Sat Nov 5 12:12:21 2016  stephenc_:Artifacts that are not deployed to a maven repo
Sat Nov 5 12:12:40 2016  stephenc_:But still artifacts that have a lifecycle and get built
Sat Nov 5 12:13:01 2016  rfscholte:I agree.
Sat Nov 5 12:13:06 2016  stephenc_:So I say: build isn't special... we should stop treating it as such
Sat Nov 5 12:13:36 2016  rfscholte:+100
Sat Nov 5 12:13:48 2016  stephenc_:Instead of ripping out the site lifecycle... I want to rip them all out... and then add them back I. By templates that define the conventional lifecycles
Sat Nov 5 12:14:25 2016  stephenc_:s/I. B/in b/
Sat Nov 5 12:14:41 2016  rfscholte:also the reason why I started moving lifecycles from core to packaging plugins...
Sat Nov 5 12:15:32 2016  stephenc_:That is what has lead me to have lifecycles and bindings as the first class declarations in the pom... no "build|reporting"
Sat Nov 5 12:16:10 2016  stephenc_:What I see as necessary though is a configuration model...
Sat Nov 5 12:16:28 2016  stephenc_:Need a generic way to share configuration across plugins
Sat Nov 5 12:17:05 2016  stephenc_:Need a way to provide defaults for each lifecycle that span all plugins that see as relevant
Sat Nov 5 12:17:36 2016  mischat:Joined the channel
Sat Nov 5 12:17:51 2016  stephenc_:One way could be to have grab-bag configuration sections in the bindings... but that makes ide support tricky
Sat Nov 5 12:18:35 2016  rfscholte:I have to work on my Devoxx talk, mine is already at monday. Week after that ApacheCon. Will share these thoughts with other maven devs there
Sat Nov 5 12:19:13 2016  stephenc_:Perhaps if plugins could declare global configuration and plugin configuration... at least IDEs could discover the global configuration permitted elements (but that means we loose schema validation in the grabbags)
Sat Nov 5 12:19:39 2016  stephenc_:Ok thanks. Would like to be there but family commitments...
Sat Nov 5 12:19:47 2016  rfscholte:IDE vendors should be involved early too.
Sat Nov 5 12:20:21 2016  stephenc_:Yep... I want to get my vision down first (I'm selfish I know)
Sat Nov 5 12:20:42 2016  stephenc_:I wonder should we try and start back up the hangouts?
Sat Nov 5 12:21:05 2016  rfscholte:sounds good to me
Sat Nov 5 12:21:51 2016  stephenc_:Ok... I'll see if I can pick a time!
Sat Nov 5 12:23:34 2016  rfscholte:Left the channel
Sat Nov 5 12:31:16 2016  adac:Joined the channel
Sat Nov 5 12:31:41 2016  jknetl:Joined the channel
Sat Nov 5 12:45:22 2016  hjd:Left the channel
Sat Nov 5 12:45:53 2016  hjd:Joined the channel
Sat Nov 5 13:04:52 2016  HoierM:Joined the channel
Sat Nov 5 13:45:58 2016  edvorg:Joined the channel
Sat Nov 5 13:49:57 2016  dandan86:Joined the channel
Sat Nov 5 14:06:39 2016  hboutemy:Joined the channel
Sat Nov 5 14:50:33 2016  HoierM:Joined the channel
Sat Nov 5 15:08:25 2016  smola_:Joined the channel
Sat Nov 5 15:48:24 2016  conan:Joined the channel
Sat Nov 5 16:48:39 2016  conan_:Joined the channel
Sat Nov 5 18:10:41 2016  isavin:Joined the channel
Sat Nov 5 18:10:43 2016  isavin:Joined the channel
Sat Nov 5 18:14:44 2016  dandan86:Joined the channel
Sat Nov 5 18:50:21 2016  hboutemy:Joined the channel
Sat Nov 5 18:52:26 2016  theRealGent:Joined the channel
Sat Nov 5 19:16:19 2016  dandan86:Joined the channel
Sat Nov 5 19:26:36 2016  isavin:Joined the channel
Sat Nov 5 19:26:36 2016  isavin:Joined the channel
Sat Nov 5 20:17:03 2016  dandan86:Joined the channel
Sat Nov 5 21:44:51 2016  adac:Joined the channel
Sat Nov 5 22:25:30 2016  conan:Joined the channel
Sat Nov 5 23:15:07 2016  jasonvanzyl:Joined the channel
Sat Nov 5 23:31:26 2016  jasonvanzyl:Joined the channel
Sat Nov 5 23:34:11 2016  dandan86:Joined the channel
Sat Nov 5 23:51:30 2016  jasonvanzyl:Joined the channel
Sat Nov 5 23:54:25 2016  theRealGent:Joined the channel
Sat Nov 5 23:56:45 2016  jasonvanzyl_:Joined the channel