Incremental build support for maven plugin

[GoogleCodeExporter]

There should be a way to configure wro4j to skip validators like jshint or 
csslint if the code being scanned is unchanged. I am guessing that scanning for 
file changes will be a lot faster than actually validating the files (which is 
a slow operation at the moment).

Original issue reported on code.google.com by cow...@bbs.darktech.org on 28 Aug 2013 at 8:47

[GoogleCodeExporter]

I assume this is related to maven plugin? If yes, this is already happening 
when using m2e-wro4j eclipse plugin which uses wro4j-maven-plugin under the 
hood. 
Otherwise, please elaborate what you understand by "scan". Describing the 
entire flow for your use-case would be useful.

Original comment by alex.obj...@gmail.com on 28 Aug 2013 at 9:07

[GoogleCodeExporter]

Yes, I am referring to the Maven plugin, but I am not using Eclipse (or plan 
to). Can you add this functionality to your Maven plugin?

Original comment by cow...@bbs.darktech.org on 28 Aug 2013 at 9:13

[GoogleCodeExporter]

In order to do that, the maven plugin has to persist somewhere the information 
regarding the previous build. The maven plugin does not persist the state from 
one build to another, so there is no available mechanism I'm aware of which can 
be used to achieve that. Probably it could be possible to store the build state 
on disk (temporary folder), or some custom location. 

Even if this feature is implemented, it would skip the processing of all 
processors, not only of "validators" (ex: jshint, csslint). In other words, I 
see the flow like this:

* Build started
* Check for existence of build state file (stored in a temp folder)
* If build state file doesn't exist, create one. This file will contain 
checksum of original resources used for processing.
* If build state file exist, compare the current checksum with the stored ones. 
If checksums are unchanged, skip processing. Otherwise, perform the entire 
processing flow.

One important aspect, is to perform the processing even when original resources 
are unchanged, in case that the generated resources were deleted.

Original comment by alex.obj...@gmail.com on 28 Aug 2013 at 9:29

• Changed state: Accepted
• Added labels: Type-Enhancement, Milestone-Release-1.7.1
• Removed labels: Type-Defect

[GoogleCodeExporter]

That's fine. Other plugins (like maven-dependency-plugin) create marker files 
or checksums under ${project.build.dir}/maven-dependency-plugin or some other 
custom directory. You could do the same.

Original comment by cow...@bbs.darktech.org on 28 Aug 2013 at 10:23

[GoogleCodeExporter]

Original comment by alex.obj...@gmail.com on 17 Sep 2013 at 3:51

• Changed title: Incremental build support for maven plugin

[GoogleCodeExporter]

Fixed in branch 1.7.x:

The following configuration option has been added: incrementalBuildEnabled 
(false by default). 
When incrementalBuildEnabled=true, the change detection will be enabled and 
running subsequent builds won't have any effect unless the code is changed.

Original comment by alex.obj...@gmail.com on 17 Sep 2013 at 3:56

• Changed state: Fixed

[GoogleCodeExporter]

The documentation reads "Other goals (ex: jslint, jshint, csslint) will ignore 
it, since linting need consistent validation results."

What does "linting need consistent validation results" mean? I routinely go 
through fast edit/compile cycles where linting finds a problem, I fix it and 
retry, it finds another problem, I fix that and retry, etc. Why doesn't it make 
sense to skip linting for unmodified files in this case?

Original comment by cow...@bbs.darktech.org on 1 Oct 2013 at 3:39

[GoogleCodeExporter]

By consistent validation results I mean the following flow:

* You have lint errors and you run wro4j:jslint (or any other linter mojo). 
* Your build fails (as expected). 
* You don't change anything and run the plugin again. 
* Expected: the build should fail since the lint errors aren't fixed yet. 
  Actual: No changes detected, the build is successful.

I think there is a room for improvement of this use-case. When the build fails, 
the information regarding state of resources (change or unchanged) could be 
cleared. As result, if there are no lint errors, subsequent builds won't do any 
processing and the build will be successful, while if there are lint errors - 
the resources containing lint errors will be processed (even if no change is 
detected) causing the build to fail (as expected). 

I will open a new issue for that.

Original comment by alex.obj...@gmail.com on 1 Oct 2013 at 6:57

[GoogleCodeExporter]

Sounds good. Please provide me a link to the new issue when it's created.

Original comment by cow...@bbs.darktech.org on 1 Oct 2013 at 1:35

[GoogleCodeExporter]

issue792

Original comment by alex.obj...@gmail.com on 1 Oct 2013 at 1:38