Displaying #maven-dev/2017-01-14.log:

Sat Jan 14 07:58:39 2017  olamy:Joined the channel
Sat Jan 14 10:16:57 2017  hboutemy:Joined the channel
Sat Jan 14 11:56:13 2017  rfscholte:Joined the channel
Sat Jan 14 12:00:26 2017  rfscholte:hboutemy: ping
Sat Jan 14 12:10:50 2017  hboutemy:rfscholte: Hi Robert
Sat Jan 14 12:10:56 2017  hboutemy:I'm working on fixing the IT
Sat Jan 14 12:11:08 2017  rfscholte:which one?
Sat Jan 14 12:11:19 2017  hboutemy:I tested with Maven 3.4-SNAPSHOT, then didn't see the failures
Sat Jan 14 12:11:42 2017  hboutemy:in fact, plugin-info-jdk is easy to fix
Sat Jan 14 12:11:51 2017  hboutemy:but I still get some other failures
Sat Jan 14 12:12:26 2017  hboutemy:you wanted to discuss something else?
Sat Jan 14 12:14:06 2017  rfscholte:yes :)
Sat Jan 14 12:14:17 2017  hboutemy:let's go :)
Sat Jan 14 12:14:30 2017  rfscholte:i don't think usePluginXmlMavenVersionRange should be exposed as a versionrange
Sat Jan 14 12:14:43 2017  rfscholte:for users it should be a simple boolean
Sat Jan 14 12:14:47 2017  rfscholte:or Boolean
Sat Jan 14 12:14:56 2017  hboutemy:no, not boolean
Sat Jan 14 12:15:02 2017  hboutemy:it has to be dynamic
Sat Jan 14 12:15:18 2017  hboutemy:you can define minimumVersion if you want
Sat Jan 14 12:15:33 2017  hboutemy:or perhaps you can define "requireSince"
Sat Jan 14 12:15:39 2017  hboutemy:resuireSince would be boolean
Sat Jan 14 12:15:46 2017  hboutemy:requireSince
Sat Jan 14 12:16:33 2017  hboutemy:I made it short; is this understandable?
Sat Jan 14 12:17:16 2017  rfscholte:I don't think it is that understandable
Sat Jan 14 12:17:22 2017  hboutemy::)
Sat Jan 14 12:17:55 2017  hboutemy:currently, we need a range to define which Maven version will read plugin.xml and which version will scan
Sat Jan 14 12:17:56 2017  rfscholte:by default we can guess what the best option is (based on the fix in Maven 3.x.y)
Sat Jan 14 12:18:25 2017  rfscholte:is the enduser wants to force a certain behavior, IMHO it should be as simple as a boolean
Sat Jan 14 12:18:26 2017  hboutemy:and this is just to ensure we have since info
Sat Jan 14 12:18:37 2017  rfscholte:correct
Sat Jan 14 12:18:51 2017  rfscholte:that's the default behavior
Sat Jan 14 12:18:53 2017  hboutemy:if we just tell him: do you expect to enfore accurate since info?
Sat Jan 14 12:19:01 2017  hboutemy:by default, yes
Sat Jan 14 12:19:10 2017  hboutemy:but we can disable accurate since
Sat Jan 14 12:19:20 2017  hboutemy:another solution:
Sat Jan 14 12:19:45 2017  hboutemy:copy PluginDescriptor reeader into maven-plugin-plugin
Sat Jan 14 12:19:52 2017  hboutemy:source core
Sat Jan 14 12:19:55 2017  hboutemy:source code
Sat Jan 14 12:20:01 2017  hboutemy:it's not that huge
Sat Jan 14 12:20:09 2017  rfscholte:duplicate code.... ugly
Sat Jan 14 12:20:33 2017  rfscholte:then we need to maintain to codebases
Sat Jan 14 12:20:35 2017  hboutemy:avoiding reading plugin.xml = complex algorithm and explanations = ugly also
Sat Jan 14 12:21:16 2017  hboutemy:we can hardcode the Maven minimum version to read through Maven-providede reader
Sat Jan 14 12:21:28 2017  hboutemy:for "old" versions, copied code
Sat Jan 14 12:21:32 2017  rfscholte:that's what I'm thinking
Sat Jan 14 12:21:34 2017  hboutemy:yes, workaround
Sat Jan 14 12:21:39 2017  hboutemy:but limited in time
Sat Jan 14 12:21:56 2017  hboutemy:when we deprecate Maven 3.3.9, we drop the little code copy
Sat Jan 14 12:22:08 2017  hboutemy:of course, this has to be documented properly
Sat Jan 14 12:22:22 2017  hboutemy:but the current boolean (or range) require good documentation also
Sat Jan 14 12:22:30 2017  hboutemy:since it seems overkill
Sat Jan 14 12:22:51 2017  rfscholte:I made it read-only, I don't believe any user wants to change it
Sat Jan 14 12:22:53 2017  hboutemy:another option
Sat Jan 14 12:23:02 2017  rfscholte:if so, raise a jira issue
Sat Jan 14 12:23:10 2017  hboutemy:IIUC, the parameter was defined just because IT is failing
Sat Jan 14 12:23:27 2017  hboutemy:but nobody writes plugin.xml by hand
Sat Jan 14 12:23:29 2017  rfscholte:true, that's the only reason: just for IT
Sat Jan 14 12:23:45 2017  rfscholte:we'll, don 't be sure about that...
Sat Jan 14 12:23:51 2017  hboutemy:then we sould be able to create a simpler workaround
Sat Jan 14 12:25:01 2017  hboutemy:then it seems copying a fixed descriptor reader and using it for Maven <= 3.3.9 looks the most viable solution
Sat Jan 14 12:25:50 2017  rfscholte:that's good, just don't expose it as a parameter which nobody will change :)
Sat Jan 14 12:25:57 2017  hboutemy:yes
Sat Jan 14 12:28:06 2017  hboutemy:do you want to do it yourself? or me? (I have color to add, and aether to rename...)
Sat Jan 14 12:29:01 2017  rfscholte:I will pick it up
Sat Jan 14 12:32:50 2017  hboutemy:ok, great
Sat Jan 14 12:40:27 2017  rfscholte:org.apache.maven.tools.plugin.extractor.model.PluginMetadataParser also exists (it is a simplified version I guess). Only used by org.apache.maven.tools.plugin.extractor.ant.AntMojoDescriptorExtractor
Sat Jan 14 12:41:35 2017  rfscholte:I prefer to use the one from Maven Core, in the end that's the one being used
Sat Jan 14 12:44:28 2017  tibor_:Joined the channel
Sat Jan 14 14:04:00 2017  hboutemy:grrrr... learning more advanced git to be able to resolve conflicts...
Sat Jan 14 14:04:10 2017  hboutemy:I hate that
Sat Jan 14 14:09:26 2017  hboutemy:rfscholte: now you can clean up the parameter in plugin-info-jdk IT
Sat Jan 14 14:12:32 2017  hboutemy:[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile (default-compile) on project maven-plugin-plugin: Compilation failure
Sat Jan 14 14:12:32 2017  hboutemy:[ERROR] /home/herve/projets/maven/trunks/plugin-tools/maven-plugin-plugin/src/main/java/org/apache/maven/plugins/plugin/descriptor/MNG6109PluginDescriptorBuilder.java:[56,66] cannot find symbol
Sat Jan 14 14:12:32 2017  hboutemy:[ERROR] symbol: method setSince(java.lang.String)
Sat Jan 14 14:12:32 2017  hboutemy:[ERROR] location: class java.lang.Object
Sat Jan 14 14:12:39 2017  hboutemy:building with Maven 3.3.9
Sat Jan 14 14:14:11 2017  hboutemy:and Jenkins gets same result https://builds.apache.org/view/M-R/view/Maven/job/maven-plugin-tools/278/console
Sat Jan 14 14:14:19 2017  hboutemy:I liked the idea...
Sat Jan 14 14:58:52 2017  hboutemy:ok, you seem to not be here: I fixed the little issue :)
Sat Jan 14 15:49:00 2017  rfscholte:back
Sat Jan 14 15:49:19 2017  rfscholte:I had to go for a new car
Sat Jan 14 15:49:57 2017  rfscholte:I missed the generics part :(
Sat Jan 14 15:50:49 2017  rfscholte:but by far the best solution I could think of
Sat Jan 14 17:16:38 2017  rfscholte:Joined the channel
Sat Jan 14 17:58:22 2017  hboutemy:rfscholte: yes, perfect solution!
Sat Jan 14 17:58:43 2017  hboutemy:just a little specialisation, no copy/paste
Sat Jan 14 18:08:16 2017  rfscholte::)
Sat Jan 14 18:09:45 2017  rfscholte:now looking at groovy 2.4.8 to confirm it fixes all our (known) Jigsaw issues
Sat Jan 14 19:48:14 2017  tibor_:Joined the channel
Sat Jan 14 19:52:01 2017  tibor_:@hboutemy: Hi Herve. How are you. I am currenlty making research with IO close/flush and JRE implementation and I want to prepare before sending any email because throwing exception in Surefire listener may lead to a loop in code which happened in reality when the rutine writing to std/out produced IndexOutOfBoundsException while writing byte[] and JUnit has a loop in RunListener and Surefire hanged.
Sat Jan 14 19:53:01 2017  tibor_:@hboutemy: So in other words close() flush() and IOException may lead to similar situation or may break reporters and lead to incoplete report. Let's see if the plugin fails gracefully but I do not think so.

Comments