marcarvalho / fitnesse-launcher-maven-plugin

Automatically exported from code.google.com/p/fitnesse-launcher-maven-plugin
0 stars 0 forks source link

Allow suppression of clean-expand-move in setup based on marker file #23

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The actions performed in the setup goal (cleaning, expanding the fitnesse.jar 
and moving the FitNesseRoot folder into the workingDir folder) can take quite 
some time on startup. A proven practice from many code or resource generating 
plugins is to use a marker file to indicate that generation has taken place, to 
avoid unnecessary, repetetive re-generation. The marker file itself is 
typically removed together with the generated resources, e.g. as part of the 
"clean" lifecycle.

The attached patch adds a configuration property "fitnesse.markerFile" that, if 
set, provides the name of a marker file. If set and the marker file exists, the 
setup goal succeeds without actions. If set and the marker file doesn't exist, 
the ordinary setup actions are executed, and on successful completion the 
marker file is created for future reference.

Below is an example configuration:

      <plugin>
        <groupId>uk.co.javahelp.fitnesse</groupId>
        <artifactId>fitnesse-launcher-maven-plugin</artifactId>
        <configuration>
          <markerFile>${project.build.directory}/fitnesse-launcher-plugin-marker</markerFile>
          ...
        </configuration>
      </plugin>

Original issue reported on code.google.com by bjorn.be...@callistaenterprise.se on 23 Sep 2013 at 3:59

Attachments:

GoogleCodeExporter commented 9 years ago
The maven-dependency-plugin is used to unpack the fitnesse jar. This plugin 
already has its own file marker system. This marker was being deleted by the 
clean() step of SetupMojo.

maven-dependency-plugin has its own 'overWrite' config, which allows it to 
honour or ignore the marker file.

So, in handling this, in combination with Issue #22, I think the best thing is 
for there to be 2 extra config properties for setup, defaulting to false:
fitnesse.deletePluginsProperties
fitnesse.alwaysUnpackFitnesse

The clean() step would only happen if 'deletePluginsProperties' == true.
The clean() step would no longer remove the marker file, just 
plugins.properties.
The unpack() step would pass 'alwaysUnpackFitnesse' through to 
maven-dependency-plugin, 'overWrite' config.
The move() step, with its own 'overwrite' set to false (Issue #29) can remain 
unchanged, because it's safe to move something that isn't there.

Hopefully this will result in improved usefulness all round.

PS. There was some reason, lost to me now, why we were deleting 
plugins.properties and the dependency-plugin marker file. I think may have had 
something to do with
some Fitnesse plugin or other I was testing, such as Xebium. However, I've now 
tested this new config with the project webapp-example, and it all seems to 
work.

Original comment by stewart@javahelp.co.uk on 23 Jun 2014 at 3:25

GoogleCodeExporter commented 9 years ago
Committed to /trunk at r396

Original comment by stewart@javahelp.co.uk on 23 Jun 2014 at 3:35