Closed stelfrich closed 7 years ago
Are there any known, but undocumented use-cases for the goals for which no integration tests exist?
Not sure. It looks like install-artifact
is just used in the copy-jars
IT? I didn't write that code though.
This is deeper than I have time to read and understand, but the commits look fine enough. So I'm just going to merge it. Thank you very much for your efforts on this.
Note that my long-term plan is to migrate the copy-jars mojo into the scijava-maven-plugin, generalizing beyond just ImageJ. The idea is that any SciJava-based application could potentially benefit from this, and this stuff has nothing to do with images. It's about installing SciJava plugins into SciJava applications. Once the copy-jars mojo is moved, it might be the case that the imagej-maven-plugin can disappear completely. Or it might be the case that there is a different, ImageJ-specific thing we want to add later... it's been awhile since I've thought about it so I'm not totally sure anymore.
Closes #20.
Not sure. It looks like
install-artifact
is just used in thecopy-jars
IT? I didn't write that code though.
I guess the idea was to be able to run install-artifact
from anywhere (no POM required) to install a specific artifact and all its dependencies into a provided imagej.app.directory
. That is what made sense to me and, hence, is what the implementation does, although I haven't figured out a good way to put that into an integration test.
Once the copy-jars mojo is moved, it might be the case that the imagej-maven-plugin can disappear completely.
I am not entirely sure that will work unless we put the ImageJ-specific code in special case logic into scijava-maven-plugin. I guess we could also move all the general parts of copy-jars
and install-artifact
into scijava-maven-plugin and keep the special case logic (e.g. Bio-Formats or IJ1 plugin) in imagej-maven-plugin. This plugin here would then just be some lines of code but we'd have to maintain it (:-1:), keeping the possibility to not pollute scijava-maven-plugin with ImageJ specifics (:+1:). Keeping this plugin for now, with just the case logic would be my preferred option.
I am not entirely sure that will work unless we put the ImageJ-specific code in special case logic into scijava-maven-plugin.
The idea would be to make the mojos configurable enough that ImageJ-specific logic is no longer needed. For example, for Bio-Formats, the Bio-Formats Maven POM(s) would specify the property values such that running mvn -Dscijava.app.directory
works as intended without the currently hardcoded logic in the copy-jars mojo.
Migrates the plugin to the latest working version of the Maven 3 API.
Open questions:
imagej.app.directory
being a parameter. Happy to change that back to how it was before, i.e. a property that contains the custom name of theimagej.app.directory
property and not a property itself containing the path