Maven jasperreports-maven-plugin define compile charset - maven-2

When using the jasperreports-maven-plugin/1.0-beta-2 to compile a jrxml file to jasper, the resulting report doesn't display unicode characters properly, it displays ???? instead.
It is obvious this is a font problem. So I opened iReport 4.0.1, and compiled the jrxml file from there without changing any specific settings, the resulting jasper file could display the unicode characters just fine. So I am assuming there are some compile time properties which I am not setting properly.
I thought of using the tag of the jasperreports-maven-plugin plugin, to define the resulting encoding properties to the used when compiling the jasper file. But I couldnt find what properties to set there.
I guessed some properties from
The JasperReport Configuration Reference
specifically
net.sf.jasperreports.default.pdf.encoding
net.sf.jasperreports.export.character.encoding
but to no avail.
So I would like to know either if iReport uses some special compilation options regarding fonts,encoding or charset properties that can be set in the asperreports-maven-plugin mojo.
Alernatively, if this is not possible from this mojo.
Thanks

The Maven plugin is most likely not using JasperReports 4.0.1 to compile the report. By default it uses the JasperReports defined as a dependency: jasperreports:jasperreports:1.2.0.
Because JasperReports 4.0.1 has a different group, artifact and version this dependency can't be overridden. Exclusions only work for dependencies of dependencies, so that isn't an option either. You will need a different version of the mojo to compile templates using 4.0.1.
Lucky for you a patch has already been applied to the trunk of the mojo so all you have to do is check out the code and deploy a version to your repository.
http://svn.codehaus.org/mojo/trunk/mojo/jasperreports-maven-plugin/
After deploying the plugin you will need to override the dependency to 4.0.1. You do this by defining dependencies at the plugin level.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jasperreports-maven-plugin</artifactId>
<dependencies>
<dependency>
<groupId>net.sf.jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>4.0.1</version>
</dependency>
</dependencies>
</plugin>

Related

Liquibase 4.13+ dependency without opencsv dependency

I tried to upgrade the liquibase version to 4.13 in my project, but when I tested it, I found a problem with loading csv data. It looks like the opencsv dependency provided with the liquibase dependency is missing. The following dependency helped to solve this problem. But my question is, why do I have to manually add it now?
<dependency>
<groupId>com.opencsv</groupId>
<artifactId>opencsv</artifactId>
<version>5.6</version>
</dependency>
In v4.12.0 opencsv.jar was moved. Rather than shading opencsv into the liquibase-core.jar, define it as a dependency in the shipped pom.xml and include it as a separate jar in the internal/lib directory.

grails module "app-name"-grailsPlugin isn't automatically loaded in IntelliJ on Windows but is on Mac

I am supposed to get a "app-name"-grailsPlugins folder/module under my project structure, however I am not getting it.
enter image description here
I am not sure if it's a maven issue, since I am getting a sucessful "maven compile" as well as "grails compile" but my friend is able to get it on his mac.
Because of that IntelliJ isn't able to recognize a valid class from the spring-security-core plugin. It doesn't affects me as much as of now, but I shouldn't have any line of code "redlined" and IntelliJ should be able to recognize that class.
This is my dependency within the pom.xml:
<groupId>org.grails.plugins</groupId>
<artifactId>spring-security-core</artifactId>
<version>${grails.spring-security.version}</version>
<scope>runtime</scope>
<type>zip</type>
<exclusions>
<!--<exclusion>
<!– can make global exclusion in BuildConfig –>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>-->
<exclusion>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
</exclusion>
</exclusions>
</dependency>
Any help is appreciated. I have been looking everywhere so far.
Screenshot of project structure with missing grailsPlugins module with maven 3.8.3
UPDATE
STEPS TO REPRODUCE
Install sdkman
Use sdkman to install Grails 2.4.5
Use Grails 2.4.5 command-line "grails create-app (name of your grails project)" to create grails project.
Open grails project inside IntelliJ
Go to terminal inside IntelliJ and use Grails command "grails create-pom (your chosen group id [com.samplemaven]) to create Maven pom.xml file.
Go to IntelliJ File|Project Structure | Module and you will see that IntelliJ doesn't automatically generate app-name-grailsPlugins module
Sample Grails 2.4.5 project in IntelliJ with Maven integration

JPS incremental annotation processing is disabled. Compilation results on partial recompilation may be inaccurate

Since IntelliJ IDEA 2020.3.2 (I use Community Edition), I started getting:
Parsing java... [applicationname]
java: JPS incremental annotation processing is disabled. Compilation results on partial recompilation may be inaccurate.
Use build process "jps.track.ap.dependencies" VM flag to enable/disable incremental annotation processing environment.
Writing classes
warning, upon running the application within the IntelliJ IDEA.
This actually happens during the build phase, when you run your application for the "first" time (to be more precise, when target (or whatever you have configured as a building result directory) is being built).
What does this message mean?
As IDEA's build is incremental, it uses wrapper interfaces in order to collect some data that will help incremental analysis to correctly compile files affected by changes.
The -Djps.track.ap.dependencies=false option is added in:
File > Settings/Preferences > Build, Execution, Deployment > Compiler.
Then field Build process VM options disables collection of dependencies specified by an annotation processor when Filer methods are called.
In later versions of IntelliJ, the settings is now under:
File > Settings > Build, Execution, Deployment > Compiler, then field Shared build process VM options
See some more details in this issue: IDEA-252069.
I was using an older version of Lombok, changing to newer version fixed the issue in IntelliJ
Old version:
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
New version:
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.20</version>
<scope>provided</scope>
</dependency>
In my case i was trying to use an old version lombok plugin (version 1.16.16), but it's an old plugin version, I updated to 1.18.20 (obs.: today is july 2021) and it works well.
I had to remove the target dir with rm -Rf ./target or mvn clean, then inside IntelliJIDEA's Maven panel, I clicked on the Icon "Reload all maven projects".
I also tried to "Invalidate cache and restart".
Not sure what was working but it solved my error.
We can do all operations in IntelliJ IDEA.
add -Djps.track.ap.dependencies=false in proper place.
In the right of IDEA, click Maven -> Reload All Maven Projects.
Also in the Maven -> Excute Maven Goal (represented by a 'm' icon) -> mvn clean -> enter
Then Excute Maven Goal -> mvn install -> enter
Build -> Rebuild Project.
Thank Andrey, djangofan and Falcon.
1.New version added in pom.xml
enter code here
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.20</version>
<scope>provided</scope>
</dependency>
enter code here
2.mvn clean -> build project
In my case,the specific error is couldn't find one class file. I open it and find the suffix magically becomes '.aj'. Change it back to '.java'. It works for me.
I know the thread is almost 2 years old, but since this came up in search.
Fo me it worked after File->'Invalidate Caches...'

Running unit tests in Tycho fails: resolves google-collections instead of Guava

I am having an issue running tests using tycho due to an incorrect dependency resolution that, somehow, is placing the the old Google Collections .jar on the classpath and not the Guava one, despite the fact that at no point in any of my poms do I specify a dependency on collections (only guava).
My unit tests fail due to things like NoSuchMethodError (ImmutableList.copyOf), NoClassDefFoundError (Joiner), which I pretty much narrowed down to 'finding the wrong jar'. These same tests pass when ran manually in Eclipse.
Here is the relevant part of the pom:
<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>14.0.1</version>
</dependency>
...
</dependencies>
The phrase 'google collections' appears no where. The only other repository I specify is:
<repositories>
<repository>
<id>helios</id>
<layout>p2</layout>
<url>http://download.eclipse.org/releases/helios</url>
</repository>
</repositories>
My plugin imports 'com.google.common.base' and 'com.google.common.collect' as imported packages. I have my own bundled version of Guava 14 in my workspace for debugging, but in the POM I elect to not use my local module.
I followed Sean Patrick Floyd's answer on this question (JUnit throws java.lang.NoSuchMethodError For com.google.common.collect.Iterables.tryFind), and had my test throw an exception with the location of the .jar that the Iterables class was loaded from. It spat back out:
java.lang.IllegalArgumentException: file:/C:/Documents and Settings/Erika Redmark/.m2/repository/p2/osgi/bundle/com.google.collect/0.8.0.v201102150722/com.google.collect-0.8.0.v201102150722.jar
This is where I am now stuck. This google-collections jar is coming seemingly out of no where, and I don't know how to stop it. As long as it is being resolved, my unit tests will fail. How can I stop Tycho from trying to get the old Google Collections?
Just to clarify, this has not stopped building and deployment; the plugin update site is on an CI platform and we have been able to install the plugin on different Eclipse IDEs, so this issue is only affecting the tests.
Please let me know if additional information is needed.
The plug-in com.google.collect 0.8.0.v201102150722 is part of the Helios p2 repository that you have configured in your POM. This means that this plug-in is part of the target platform and so may be used to resolve dependencies.
If you want to ensure that the bundle is not used, make sure that it is not part of the target platform. In your case, the easiest way to do this is to explicitly remove the plug-in from the target platform:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<filters>
<filter>
<type>eclipse-plugin</type>
<id>com.google.collect</id>
<removeAll />
</filter>
</filters>
</configuration>
</plugin>
Next, you need to make sure that the guava plug-in is part of the target platform. You can add an artifact from a Maven repository to the target platform in the following way:
Declare a Maven dependency to the artifact in the dependencies section of the POM. You already have done this correctly.
Set the configuration parameter <pomDependencies> to consider on Tycho's target-platform-configuration plug-in.
Note that this will generally only work if the referenced artifact is already an OSGi bundle. This is the case here: com.google.guava:guava:14.0.1 seems to have all manifest headers needed by OSGi.
This should give you the result you wanted: In the test runtime, guava should now be used to match your com.google.common.* package imports.
And another general remark on declaring dependencies in Tycho: In Tycho, you can only declare dependencies in the PDE source files META-INF/MANIFEST.MF, feature.xml, etc.
The normal Maven-style dependencies declared in the POM do not add dependencies to the project. As explained above, the POM dependencies may only add artifacts to the target platform, i.e. the set of artifacts that may be used by Tycho to resolve the dependencies declared in the PDE source files. So in the end, the POM dependency may become part of the resolved dependencies, but only if the dependency resolver picks it for matching one of the declared dependencies.
by default, tycho will add any p2 artifacts you installed in your local maven repo to the target platform. If bundle com.google.collect exports the package which you import, it may be wired.
To stop tycho from including any locally installed artifacts, you can use -Dtycho.localArtifacts=ignore (or, remove the unwanted bundle from your local maven repo)
See http://wiki.eclipse.org/Tycho/Release_Notes/0.16#Improvements_and_Fixes

Error while using JSFUnit/HtmlUnit/CSSParser

We've just recently converted our project to using Maven for builds and dependency management, and after the conversion I'm getting the following exception while trying to run any JSFUnit tests in my project.
Exception class=[java.lang.UnsupportedOperationException]
com.gargoylesoftware.htmlunit.ScriptException: CSSRule com.steadystate.css.dom.CSSCharsetRuleImpl is not yet supported.
at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:527)
at net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:537)
...
All the dependencies and JARs for JSFUnit were pulled with Maven using the JBoss repository (http://repository.jboss.com/maven2/).
We're using the following dependencies in the project:
jboss-jsfunit-core 1.2.0.Final
jboss-jsfunit-richfaces 1.2.0.Final
richfaces-ui 3.3.2.GA
openfaces 2.0
JSF 1.2_12
Facelets 1.1.14
Before the dependencies were being managed by Maven, we were able to run our JSFUnit tests just fine. I was able to semi-fix the issue by using a ss_css2.jar file that someone had tucked into our WEB-INF/lib directory (from before the Maven conversion). I'm hoping to find out if there's something else I can do to fix the dependencies in Maven rather than resorting to managing some of the dependencies myself.
You're very likely getting an "incompatible" version of HtmlUnit or another JAR (pulled transitively). Try with the version you were using previously and declare it under the dependencyManagement section, e.g.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>net.sourceforge.htmlunit</groupId>
<artifactId>htmlunit</artifactId>
<version>2.7</version><!-- put "your" version here -->
</dependency>
</dependencies>
</dependencyManagement>
Or, if you changed any version, try to revert to the exact previous state (by the way, could you clarify the differences between the previous versions and the one currently used?).
Update: It appears that the problem was related to the version of the cssparser artifact. I hadn't all the required elements to figure this out but the OP did :)