Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
Original comment by alex.obj...@gmail.com
on 17 Sep 2013 at 3:51
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
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
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
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
issue792
Original comment by alex.obj...@gmail.com
on 1 Oct 2013 at 1:38
Original issue reported on code.google.com by
cow...@bbs.darktech.org
on 28 Aug 2013 at 8:47