[jira] [Commented] (MCOMPILER-209) Incremental compilation doesn't work unless useIncrementalCompilation is set to 'false'

2019-07-17 Thread Igor Bljahhin (JIRA)


[ 
https://issues.apache.org/jira/browse/MCOMPILER-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887123#comment-16887123
 ] 

Igor Bljahhin commented on MCOMPILER-209:
-

Happy 5th year birthday, dear bug!

> Incremental compilation doesn't work unless useIncrementalCompilation is set 
> to 'false'
> ---
>
> Key: MCOMPILER-209
> URL: https://issues.apache.org/jira/browse/MCOMPILER-209
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Michael Ekstrand
>Priority: Major
> Attachments: 
> MCOMPILER_209_reversed_if_else_branches_for_useIncrementalCompilation_flag.patch,
>  SO_AJ_MavenSoftExceptions.zip
>
>
> The compiler plugin has the 
> [useIncrementalCompilation|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#useIncrementalCompilation]
>  flag.  However, when this flag is set to {{true}} and using the {{javac}} 
> compiler, the compilation is not very incremental; the compiler always at 
> least claims it is rebuilding all source files (and compile times are 
> consistent with this being what it is actually doing, though it is hard to 
> tell).  If I set {{useIncrementalCompilation}} to {{false}}, then it actually 
> does report that some modules are up-to-date, and some only need a subset of 
> their files compiled.
> It seems that one  or more of the following is happening:
> * {{useIncrementalCompilation}} has some meaning that is very different from 
> what a user would expect, actually controlling whether the compiler plugin 
> uses some internal incremental compilation mechanism vs. incremental 
> compilation support built-in to the particular compiler backend.  One would 
> expect this flag to turn on incremental compilation vs. build-everything.
> * The log messages do not reflect what it is actually doing; that is, it 
> seems possible that it's saying "Compiling 164 source files" when it's really 
> handing 164 source files off to the compiler for potential compilation.  If 
> this is the case, it is very confusing and misleading.
> * The logic of {{useIncrementalCompilation}} is just inverted.  Looking at 
> the source code for the abstract compiler MOJO, it doesn't look like it's 
> quite this simple, but I also don't know what all the various components at 
> work are doing.
> * There is a bug in the implementation of {{useIncrementalCompilation}}.
> The result of all this is incremental compilation with Maven is very 
> confusing and difficult to understand.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] (MASSEMBLY-603) ${maven.build.timestamp} placeholder is not filtered

2012-03-31 Thread Igor Bljahhin (JIRA)
Igor Bljahhin created MASSEMBLY-603:
---

 Summary: ${maven.build.timestamp} placeholder is not filtered
 Key: MASSEMBLY-603
 URL: https://jira.codehaus.org/browse/MASSEMBLY-603
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Igor Bljahhin
Priority: Minor
 Attachments: assembly-issue.zip

When filtering files in assembly plugin most of placeholders are replaced with 
values,
but Maven's property maven.build.timestamp (described here 
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html in 
Special Variables section) is not substituted with value.

Run mvn clean package in the test project and you will get 
target/assembly-issue-0.0.1-SNAPSHOT-dist.zip archive. Open index.html from 
archive and you will see that property project.version was replaced during 
assembly, but maven.build.timestamp was left untouched.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MCHANGES-270) announcement-generate goal fails in multimodule project if templateDirectory is defined

2011-12-15 Thread Igor Bljahhin (JIRA)
Igor Bljahhin created MCHANGES-270:
--

 Summary: announcement-generate goal fails in multimodule project 
if templateDirectory is defined
 Key: MCHANGES-270
 URL: https://jira.codehaus.org/browse/MCHANGES-270
 Project: Maven 2.x Changes Plugin
  Issue Type: Bug
  Components: announcement
Affects Versions: 2.6
 Environment: Maven 3.0.3
Reporter: Igor Bljahhin
Priority: Critical
 Attachments: maven-changes-plugin-test.zip

In my multimodule project only one submodule has changes.xml. If I run 
changes:announcement-generate from parent project, then it fails with error 
message 

[ERROR] ResourceManager : unable to find resource 'our-announcements/announcemen
t.vm' in any resource loader.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MCHANGES-270) announcement-generate goal fails in multimodule project if templateDirectory is defined

2011-12-15 Thread Igor Bljahhin (JIRA)

[ 
https://jira.codehaus.org/browse/MCHANGES-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=286077#comment-286077
 ] 

Igor Bljahhin commented on MCHANGES-270:


Generation is working fine, if put our-announcements directory into submodule 
folder, instead of src/main/resources/ directory. Hope, this information 
helps to localize the bug.

 announcement-generate goal fails in multimodule project if 
 templateDirectory is defined
 ---

 Key: MCHANGES-270
 URL: https://jira.codehaus.org/browse/MCHANGES-270
 Project: Maven 2.x Changes Plugin
  Issue Type: Bug
  Components: announcement
Affects Versions: 2.6
 Environment: Maven 3.0.3
Reporter: Igor Bljahhin
Priority: Critical
 Attachments: maven-changes-plugin-test.zip


 In my multimodule project only one submodule has changes.xml. If I run 
 changes:announcement-generate from parent project, then it fails with error 
 message 
 [ERROR] ResourceManager : unable to find resource 
 'our-announcements/announcemen
 t.vm' in any resource loader.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MCHANGES-266) It is not possible to disable the plugin in submodules

2011-12-14 Thread Igor Bljahhin (JIRA)

[ 
https://jira.codehaus.org/browse/MCHANGES-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285892#comment-285892
 ] 

Igor Bljahhin commented on MCHANGES-266:


I have the same problem with changes:changes-validate goal in multimodule 
project. The changes.xml is present in the parent project. The plugin tries to 
validate the file in every child project.

 It is not possible to disable the plugin in submodules
 --

 Key: MCHANGES-266
 URL: https://jira.codehaus.org/browse/MCHANGES-266
 Project: Maven 2.x Changes Plugin
  Issue Type: Bug
Reporter: Krzysztof Krason
Priority: Critical

 In a multi-module project there is no way to tell the plugin to generate 
 changes only for the parent module.
 It would be best to have something like this:
 configuration
   skipChildstrue/skipChilds
 /configuration
 This way anyone could set if he wants to generate reporst for submodules also.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira