Displaying #maven-dev/2017-12-22.log:

Fri Dec 22 04:33:51 2017  olamy:Joined the channel
Fri Dec 22 08:18:09 2017  hboutemy:Joined the channel
Fri Dec 22 09:04:05 2017  rfscholte:Joined the channel
Fri Dec 22 12:22:20 2017  hboutemy:rfscholte: Hi RObert
Fri Dec 22 12:22:30 2017  hboutemy:do you have some time?
Fri Dec 22 12:23:39 2017  rfscholte:hboutemy: Hi Herv√©. yes, I have time
Fri Dec 22 12:24:00 2017  hboutemy:I'm looking at MNG-6308
Fri Dec 22 12:24:15 2017  hboutemy:and I don't like the result: trying to analyze why
Fri Dec 22 12:24:30 2017  hboutemy:I get to 2 causes
Fri Dec 22 12:24:40 2017  hboutemy:1. packaging vs classifier
Fri Dec 22 12:25:05 2017  hboutemy:2. groupId takes too much space, brings noise IMHO
Fri Dec 22 12:25:37 2017  hboutemy:on packaging vs classifier: I think the groupId:artifactId:xxx means xxx is a classifier
Fri Dec 22 12:25:59 2017  hboutemy:classifier (when consuming) not a packaging (when building)
Fri Dec 22 12:26:34 2017  hboutemy:then it adds confusion
Fri Dec 22 12:26:58 2017  rfscholte:A MavenProject's Coordinate can never contain a classifier
Fri Dec 22 12:27:12 2017  hboutemy:nor a packaging
Fri Dec 22 12:27:40 2017  rfscholte:it always has a specific packaging
Fri Dec 22 12:27:47 2017  hboutemy:coordinate at that level is groupId:artifactId:version: nothing more
Fri Dec 22 12:28:07 2017  hboutemy:packaging is not coordinate: it's an information (taken from the build pom)
Fri Dec 22 12:28:18 2017  hboutemy:a key build information
Fri Dec 22 12:29:01 2017  rfscholte:they all are to me.
Fri Dec 22 12:29:19 2017  hboutemy:packaging is not coordinate
Fri Dec 22 12:29:35 2017  hboutemy:classifier is coordinate (of a sub-artifact)
Fri Dec 22 12:30:05 2017  rfscholte:yes it is. how can you differ jar from war in case GA is the same?
Fri Dec 22 12:30:26 2017  rfscholte:coordinate is all you need to get to the file
Fri Dec 22 12:30:27 2017  hboutemy:oh yes, classifier+extensions, you're right
Fri Dec 22 12:30:35 2017  hboutemy:but not packaging
Fri Dec 22 12:31:08 2017  hboutemy:and type is equivalent to classifier+extension
Fri Dec 22 12:31:17 2017  rfscholte:packaging is a hint for the lifecycle and is transformed to a file-extension
Fri Dec 22 12:31:26 2017  rfscholte:in most cases they are the same
Fri Dec 22 12:31:42 2017  hboutemy:ok for the hint to lifecycle, but not file-extension
Fri Dec 22 12:32:25 2017  hboutemy:each sub-artifact has a classifier (eventuall null)+extension
Fri Dec 22 12:32:54 2017  hboutemy:I'm pretty sure we're at a key concept that is causing us issues
Fri Dec 22 12:33:02 2017  rfscholte:yes
Fri Dec 22 12:33:19 2017  hboutemy:and it's funny that a display discussion comes to such a key point
Fri Dec 22 12:34:01 2017  rfscholte:up until now attached artifacts are quite simple (javadoc, sources), but ideally they should have their own lifecycle, even if it is just for one goal
Fri Dec 22 12:34:13 2017  hboutemy:???
Fri Dec 22 12:34:37 2017  hboutemy:that's our misunderstanding
Fri Dec 22 12:35:10 2017  hboutemy:to me, lifecycle is for the whole "project" (I don't like this term for what we're talking about)
Fri Dec 22 12:35:17 2017  hboutemy:not for each sub-artifact
Fri Dec 22 12:36:52 2017  hboutemy:when Maven builds a pom, it gets the packaging then know which default plugin bindings to apply
Fri Dec 22 12:37:11 2017  rfscholte:yes, but only for the main artifact
Fri Dec 22 12:37:15 2017  hboutemy:then each plugin goal can create sub-artifacts as it wants (with proper classifiers+extensions)
Fri Dec 22 12:37:31 2017  hboutemy:then you can tell, if you want, that there is a "main" artifact
Fri Dec 22 12:38:02 2017  hboutemy:"main" for sure means no classifier is null
Fri Dec 22 12:38:15 2017  hboutemy:and there is a main extension, why not
Fri Dec 22 12:38:41 2017  rfscholte:true, but this is possible because e.g. sources-jar is very simple. I think it would be better if there was a sources-lifecycle, where the packaging-phase is only specified
Fri Dec 22 12:39:17 2017  hboutemy:thinking...
Fri Dec 22 12:39:46 2017  hboutemy:first, I think you must fix the way to tell it
Fri Dec 22 12:39:53 2017  rfscholte:it works now, because it is very simple to generate this jar, you can do it within 1 goal.
Fri Dec 22 12:40:02 2017  hboutemy:there is no "sources lifecycle": there would be sources plugin binding
Fri Dec 22 12:40:10 2017  hboutemy:lifecycle is "default"
Fri Dec 22 12:40:38 2017  hboutemy:"because it is very simple to generate this jar, you can do it within 1 goal": no
Fri Dec 22 12:40:53 2017  hboutemy:you have multiple goals: to create =then to attach
Fri Dec 22 12:40:58 2017  hboutemy:for example
Fri Dec 22 12:41:14 2017  hboutemy:once again, it's about goals binding, not lifecycle
Fri Dec 22 12:41:51 2017  hboutemy:3 lifecycles: default, clean and site http://maven.apache.org/ref/3.5.2/maven-core/lifecycles.html
Fri Dec 22 12:42:24 2017  hboutemy:then goals bindings to default lifecycle according to packaging: http://maven.apache.org/ref/3.5.2/maven-core/default-bindings.html
Fri Dec 22 12:42:55 2017  hboutemy:clean and site lifecycles are not customized per-packaging
Fri Dec 22 12:43:31 2017  rfscholte:so how do we identify http://maven.apache.org/ref/3.5.2/maven-core/default-bindings.html# ?
Fri Dec 22 12:44:19 2017  rfscholte:if we call these bindings, then I want a sources-bindings (not sources-lifecycle )
Fri Dec 22 12:44:48 2017  hboutemy:I don't understand the question: packaging is the key, that's why I want to display it
Fri Dec 22 12:45:28 2017  hboutemy:when we attach sources, it's manual
Fri Dec 22 12:45:31 2017  hboutemy:in parent pom
Fri Dec 22 12:46:17 2017  hboutemy:like https://svn.apache.org/viewvc/maven/pom/tags/apache-18/pom.xml?view=markup#l314
Fri Dec 22 12:46:26 2017  rfscholte:IMO every attached artifact deserves a binding, so it can be part of the complete lifecycle
Fri Dec 22 12:46:50 2017  hboutemy:or https://svn.apache.org/viewvc/maven/pom/tags/apache-18/pom.xml?view=markup#l374
Fri Dec 22 12:47:40 2017  hboutemy:at the moment, what you describe does not exist: there is no formal binding defined, just parent poms
Fri Dec 22 12:49:04 2017  rfscholte:I'm trying to figure out why you why packaging it that important to you (IMHO these attached artifacts are as important)
Fri Dec 22 12:49:23 2017  hboutemy:the only "magic" is that javadoc:jar has a "packaging" default phase
Fri Dec 22 12:50:01 2017  hboutemy:packaging defines default bindings
Fri Dec 22 12:50:20 2017  hboutemy:= some magic from http://maven.apache.org/ref/3.5.2/maven-core/default-bindings.html
Fri Dec 22 12:50:57 2017  hboutemy:other sub-artifacts are not defined this way: it's in parent pom, specific to parent poms used
Fri Dec 22 12:51:51 2017  hboutemy:ideally, what could be useful would be to display if a goal executes because of a default binding from a packaging or because of additional configuration in pom
Fri Dec 22 12:52:11 2017  rfscholte:I think we need to stop about about parent, that is distracting from the main topic
Fri Dec 22 12:52:32 2017  hboutemy:parent or not parent, it's additional config in the pom
Fri Dec 22 12:52:53 2017  hboutemy:ie explicit config in the pom
Fri Dec 22 12:53:02 2017  hboutemy:(made implicit by parents...)
Fri Dec 22 12:53:21 2017  rfscholte:I think making clear which plugins are part of default binding and which not is a nice idea
Fri Dec 22 12:54:02 2017  rfscholte:does that mean that the packaging can be removed from the header? ;)
Fri Dec 22 12:54:07 2017  hboutemy:I fear it will confuse people, but yes, that's a consequence of making clear why packaging is key
Fri Dec 22 12:54:19 2017  hboutemy:"from the header"?
Fri Dec 22 12:54:28 2017  hboutemy:oh, no
Fri Dec 22 12:54:37 2017  rfscholte:from the ----< G:A:P >----- ?
Fri Dec 22 12:54:54 2017  hboutemy:it's key in the header, because it triggers many goals bindings
Fri Dec 22 12:55:20 2017  hboutemy:but perhaps not in the header=> the footer?
Fri Dec 22 12:55:31 2017  hboutemy:---< G:A >---
Fri Dec 22 12:55:39 2017  hboutemy:Building Tada
Fri Dec 22 12:55:59 2017  hboutemy:------[packaging]---
Fri Dec 22 12:56:22 2017  hboutemy:(just because it was "[packaging]" in the reactor order)
Fri Dec 22 12:56:24 2017  rfscholte:I can live with that
Fri Dec 22 12:57:16 2017  hboutemy:and if it's right-justified, it remembers once again the message from reactor order
Fri Dec 22 12:58:02 2017  hboutemy:centered or right justified: as you want
Fri Dec 22 12:58:03 2017  rfscholte:hmm, I'd prefer centered. The right thing is really ugly
Fri Dec 22 12:58:18 2017  hboutemy:but I think separate coordinate form packaging avoids confusion
Fri Dec 22 12:58:33 2017  hboutemy:it's a question of habit :)
Fri Dec 22 12:58:58 2017  hboutemy:I won't fight on that, it's not so important
Fri Dec 22 12:59:12 2017  rfscholte::)
Fri Dec 22 12:59:22 2017  rfscholte:xmas spirit
Fri Dec 22 12:59:46 2017  hboutemy:usual spirit, but at xmas, it's even more important
Fri Dec 22 13:00:48 2017  hboutemy:do you want to implement it? or prefer me to do?
Fri Dec 22 13:01:43 2017  rfscholte:it's you adjustment, so you can do it :)
Fri Dec 22 13:01:52 2017  hboutemy:ok
Fri Dec 22 13:02:22 2017  hboutemy:on your idea to create some bindings for sub-artifacts: I don't know how we could configure it
Fri Dec 22 13:02:26 2017  hboutemy:but could make sense
Fri Dec 22 13:02:27 2017  rfscholte:I'm trying to make m-release M3 ready, which is probably a hard job which needs to be done
Fri Dec 22 13:02:30 2017  hboutemy:to avoid copy/paste
Fri Dec 22 13:02:45 2017  hboutemy:removing M2 support?
Fri Dec 22 13:02:46 2017  rfscholte:push that idea to M4
Fri Dec 22 13:02:51 2017  rfscholte:yep
Fri Dec 22 13:03:11 2017  hboutemy:does it adds value, like simplification?
Fri Dec 22 13:03:25 2017  hboutemy:or just removes dependencies?
Fri Dec 22 13:03:30 2017  rfscholte:yes, it is quite hard to maintain
Fri Dec 22 13:03:56 2017  hboutemy:is it really harder because of M2 support?
Fri Dec 22 13:04:27 2017  hboutemy:of because it makes use of scm + invokes builds...
Fri Dec 22 13:04:59 2017  hboutemy:+ modify poms...
Fri Dec 22 13:05:33 2017  rfscholte:if you change all maven deps to 3.0, you get a huge amount of compilation errors
Fri Dec 22 13:06:00 2017  rfscholte:it's just a sign that it requires extra attention
Fri Dec 22 14:52:56 2017  tibor17:Joined the channel
Fri Dec 22 14:54:09 2017  tibor17:@rfscholte: I have a problem with compiler:3.6.1. It still attempts to compile module even if it has not changed.
Fri Dec 22 14:54:34 2017  tibor17:[INFO] Compiling 1 source file to E:\tmp\zmaz20\audit\audit-reader-api\target\classes
Fri Dec 22 14:55:07 2017  tibor17:I have even tried to use <useIncrementalCompilation>false</useIncrementalCompilation>
Fri Dec 22 15:08:06 2017  rfscholte:have you tried 3.7.0?
Fri Dec 22 15:18:28 2017  tibor17:@rfscholte: I am trying right now
Fri Dec 22 15:20:55 2017  tibor17:Still the same
Fri Dec 22 15:20:55 2017  tibor17:[INFO] Compiling 1 source file to E:\tmp\zmaz20\audit\audit-reader-api\target\classes
Fri Dec 22 15:21:14 2017  tibor17:I do not see which source is being compiled.
Fri Dec 22 15:21:34 2017  rfscholte:actually as expected, I cannot remember changing anything related to this
Fri Dec 22 15:21:50 2017  rfscholte:-X doesn't give extra info?
Fri Dec 22 15:22:37 2017  tibor17:I used -X but I still do not see which source file was compiled
Fri Dec 22 15:23:41 2017  tibor17:@rfscholte: My Jenkinsfile has several stages. Previous compiles sources and sends a notification. Next one runs unit and IT tests in parallel but the problem is that these two delete target/classes one to each other.
Fri Dec 22 15:24:27 2017  tibor17:The sources are not generated in this module. Only in dependency module.
Fri Dec 22 15:26:22 2017  rfscholte:do you have the example so I can reproduce it?
Fri Dec 22 15:27:25 2017  tibor17:I will try
Fri Dec 22 15:27:51 2017  tibor17:It has proprietary dependency, so I have to exclude it.
Fri Dec 22 15:43:33 2017  tibor17:@rfscholte: Why only one package remains not recompiled and other three were compiled?
Fri Dec 22 15:43:53 2017  tibor17:I thought all or nothing would be compiled.
Fri Dec 22 16:09:13 2017  rfscholte:tibor17: as long as I cannot see the project i cannot tell. When using all defaults, if there is one file changed, then target/classes is emptied and everything is compiled
Fri Dec 22 16:10:34 2017  tibor17:I will send you my project. Meanwhile I have made some experiments and excluded annotation processor in compiler but this has not changed the outcome.
Fri Dec 22 16:25:31 2017  tibor17:@rfscholte: I have sent the project.
Fri Dec 22 16:25:33 2017  tibor17:Thx
Fri Dec 22 16:29:09 2017  rfscholte:got it
Fri Dec 22 16:29:30 2017  tibor17:cool, what's the problem in my project?
Fri Dec 22 16:30:36 2017  tibor17:Maybe the compiler debug mode should print also the changed files for which the module has to be compiled again.
Fri Dec 22 16:40:48 2017  rfscholte:[DEBUG] Stale source detected: E:\tmp-help\audit\audit-reader-api\src\main\java\com\scheidtbachmann\shared\audit\api\package-info.java
Fri Dec 22 16:41:30 2017  rfscholte:the debug info is there, but is *before* the changes detected-message
Fri Dec 22 16:49:55 2017  tibor17:@rfscholte: What does it mean for me? Because package-info is not being changed anyway.
Fri Dec 22 16:52:33 2017  rfscholte:I think https://issues.apache.org/jira/browse/MCOMPILER-205
Fri Dec 22 16:58:02 2017  tibor17:@rfscholte: the file has not been compiled to byte code. Why? What am I doing wrong in plugin configuration?
Fri Dec 22 17:00:27 2017  tibor17:Do you think I have to add -Xpkginfo:always ?
Fri Dec 22 17:11:41 2017  tibor17:@rfscholte: I have added -Xpkginfo:always seems to be a good workaround, thx.
Fri Dec 22 18:23:25 2017  rfscholte:Joined the channel

Comments