We want to run XSpec as part of our Maven builds to check our XSL transformations. A plugin is available from GitHub. The problem arises when the XSL-stylesheets we check against invoke functions are not available in the Saxon-HE, looking like this:
Error at xsl:if on line 194 column 75 of dyxml_table_cals.xsl:
XPST0017 XPath syntax error at char 0 on line 194 near {...table-enumeration-condition...}:
Cannot find a matching 2-argument function named {http://saxon.sf.net/}evaluate().
Saxon extension functions are not available under Saxon-HE
We own licenses for the PE. According to the Saxon documentation the enhanced editions revert back to the open source HE when no license information is available, which seems to be the case. Is it possible to activate the PE by way of Maven, e.g. using the plugin by codehaus, and how would that look like? We already use a way of activation through Java, but to know of another, arguably more elegant way would be helpful, if possible at all.
I'm not very familiar with the Maven plugins for XSpec but I try to give some hints and workarounds.
The pom.xml of the Maven plugin you mentioned contains a dependency to the version of Saxon used:
<dependency>
<groupId>net.sf.saxon</groupId>
<artifactId>Saxon-HE</artifactId>
<version>9.7.0-1</version>
</dependency>
You should specify the Saxon version in order to use Saxon-PE or Saxon-EE. However, these Saxon versions don't seem to be available on public Maven repositories as, unlike Saxon-HE, they are proprietary software. I guess you can put the .jar file for Saxon-PE in a local repository (see Maven documentation for this). I suggest to put the .lic license file in the same directory as the .jar file.
Other two hints that may help you find a workaround:
XSpec allows to specify the Saxon version in an environment variable inside a shell or batch script. You can then run a shell script in your Maven project using for example the exec-maven-plugin. It's not ideal but it may be enough for your use case.
There is another Maven plugin for running XSpec, you may want to check that out too.
Hope it helps...
After some trial and error we found following solution to be working:
The creator of the XSpec-Maven-Plugin linked above hardcoded the use of the unlicensed Saxon-HE. In particular, following line was causing issues:
private final static Processor processor = new Processor(false);
We forked the code and changed it to:
private final static Processor processor = new Processor(true);
We built a custom class to activate the license and integrated it into the plugin source code. (Can`t post the code here.)
This resolved the licensing issue. Now our XSpec tests are up and running. Yeah us!
Related
I'm looking for possibilities for generating documentation using DocBook as part of my Maven build process. What I'm finding is everyone is suggesting docbkx-maven-plugin over Doxia. The problem is that it seems docbkx is no longer maintained or at least they've moved and left no forwarding address for where to look at the source code. According to the plugin's website the repository is on googlecode.com which of course hasn't existed for many years now. The last update I found of the plugin was back in 2016. This leads me to believe that the plugin is no longer maintained. Does anyone have any news to the contrary, or a different option for generating DocBook output during a maven build?
The source is available here: https://github.com/mimil/docbkx-tools
It does look like the project is no longer maintained, having seen no commits since 2015.
You don't actually need the plugin. If you have a working DocBook toolchain, you can use Maven to invoke it. The plugin could make certain aspects easier, but it also adds a limitation in that it only supports HTML output.
Can a custom Maven plugin use incremental build support from core Maven or would it best have to implement that completely itself, with SHA1 hashes over the input and the like?
Noticed e.g. /target/maven-status/maven-compiler-plugin/compile/default-compile with createdFiles.lst and inputFiles.lst, so thinking that an existing custom e.g. code generator Maven plugin, which reads some files as input, generates some output, may be able to be changed to correctly use Maven Plugin APIs for incremental build? Unclear what specifically that plugin code would have to do differently than it does today for it to become incremental. Doesn't look like there is any doc about this?
Existing code does use e.g. org.sonatype.plexus.build.incremental.BuildContext.hasDelta(File), but with "return true" in org.sonatype.plexus.build.incremental.DefaultBuildContext.hasDelta(File) it's not surprising that this doesn't quite work... ;-) Is this not implemented in Maven, or can be configured differently? Would this require the takari-lifecycle-plugin? (That would be a problem in the case of the particular plugin I'm asking for, because the use of takari-jar instead of normal JAR would interfere with other plugins.)
Understood that the custom Maven plugin likely would have to interface with Maven core API to expose its notion of dependencies between the input files. In the case of this particular custom Maven plugin, some of the input is read from dependencies on the project's classpath. Would the incremental support be able to handle that as well?
Understood that existing Maven plugins, such as maven-compiler-plugin, are struggling with incremental builds (à la Gradle); see [1], [2] and [3], so this Q is specifically to learn about how a custom Maven plugin may be extended to support incremental build.
[1] http://takari.io/2014/10/16/incremental-compilation.html
[2] http://takari.io/book/40-lifecycle.html
[3] Does Maven support incremental builds?
can Maven custom plugins use incremental build support from core Maven?
yes. take a look on the sources of 'querydsl-maven-plugin'. also you can find more usages of BuildContext.hasDelta method with grepcode.com.
does it have to implement that itself?
may it? yes. have to? no.
usually such question means just an unnecessary preemptive optimization. you have to have a rational reason to look forward on incremental builds, before you start implement anything.
I'm using Fiji for the first time, I need to open an image as a FloatType so I followed the example found here http://fiji.sc/wiki/index.php/ImgLib2_Examples#Example_1b_-_Opening_an_ImgLib2_image but I get this error:
WARN: Ignoring non-Maven build directory: /home/utente/workspace/my_project/bin
Exception in thread "main" java.lang.IllegalArgumentException: No compatible service: io.scif.SCIFIOService
at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:222)
at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:176)
at org.scijava.service.ServiceHelper.loadServices(ServiceHelper.java:153)
at org.scijava.Context.<init>(Context.java:200)
at org.scijava.Context.<init>(Context.java:127)
at org.scijava.Context.<init>(Context.java:116)
at io.scif.img.AbstractImgIOComponent.<init>(AbstractImgIOComponent.java:65)
at io.scif.img.ImgOpener.<init>(ImgOpener.java:99)
at SGP_db.StartingJFrame.getGn(StartingJFrame.java:216)
at Plugin.SGP_deblurring_boundary.main(SGP_deblurring_boundary.java:58)
Can't undertand why I get this error, any ideas?
Thanks,
sara
It is almost certainly a build path issue in Eclipse. Are you using the M2E plugin to manage your projects?
If you are not, or aren't sure, please follow the directions on the Fiji web site at:
http://fiji.sc/Developing_ImgLib2#Developing_ImgLib2_with_Eclipse
I would strongly suggest not to manually juggle JAR files in non-Maven Eclipse projects. The Eclipse Maven integration will make your life much easier. For more details, see:
http://fiji.sc/Maven
I've solved importing the ImgOpener class from imglib2.io
Please note that imglib2-io no longer exists; the up-to-date way to access the ImgOpener is to use the io.scif:scifio library instead. If you are basing your work off of the ImgLib2 Examples, please note that you can grab the source from GitHub, which includes a Maven POM with the correct dependencies specified. Start from there, or from the minimal-ij1-plugin project if you need to use ImageJ 1.x routines as well.
I am working on a project and using Maven to build it. The project is a quite big Java web application and it is supposed to work with both Mysql and Oracle databases.
The problem is that there are some specific annotations related to either of the two databases in the source code, plus some other differences, so that I am forced to manually comment/uncomment part of the code before building the application for one of the two databases.
Basically what I would like to achieve is to have my build script, maybe via a Maven profile, to automatically switch the source classes before building depending on the database I want my war to work against.
Putting it simply, the idea is to have MyClass.oracle and MyClass.mysql, and depending on my build profile I should move one of the two in the source dir, rename it MyClass and build. This should be done for some packages, classes, and also configuration files.
Is there any way I can achieve it via "pure" Maven? The only solution I came across till now is to use an antrun plugin and reference an Ant build.xml inside of it.
Thank you,
Mattia
A pure maven solution would be to develop your own maven plugin. Depending on your requirements this can be an overkill, however it is not hard at all, you can see how to achieve this here.
This is a limitation of Maven. One of Maven's purposes is to not have a build script. You should simply use the plugins as available, and setup your project the right way, and magically, everything will build!
There is one solution: Use Ant. Well, not to redo your whole project with Ant, but with the antrun plugin, you can run a few Ant tasks at various phases of your Maven build life cycle.
It's been a long, long time since I've used this, so I am not going to try to write a test pom.xml, but I don't remember it being very difficult to use.
Of course, the correct Maven solution is to divide your project up into "common core" code, and then a separate Oracle and MySql client that uses the "common core". By the way, I hope you're not patching source code. Instead, you're using a properties file to do this for you.
I have a massive Java 6 migration planned for Maven projects that are currently using JDK4 and JDK5.
In doing so, i'd like to script as much as possible. One thing I'd like to script is to replace all Maven references to a JDK4 or JDK5 to JDK6.
The question is, what are all the ways a Maven file can reference JDK?
Here are the ones I know of, listed as XPath's:
//plugin/artifactId[.='maven-compiler-plugin']
//maven.compiler.source
//maven.compiler.target
EDIT: Found another one
/project/profiles/profile/activation/jdk
EDIT: User added one
The aspectj-maven-plugin has source and target configuration.
Am I missing any?