Develop Reference

How to generate JPA Static-Metamodel without annotations?

I would like to apply the JPA 2.0 Criteria API to a Hibernate legacy application in order to get type-safe queries. Manual model creation is not an option; neither is the introduction of annotations (i.e. converting *.hbm.xml mappings into JPA annotations).
I tried to use Hibernate's "hibernate-jpamodelgen-4.3.6.Final.jar" generator without luck so far. The idea was to have a "dummy" entity to kick in Hibernate's annotation processor (JPAMetaModelEntityProcessor). Then, so my hopes, JPAMetaModelEntityProcessor would detect persistence.xml and would eventually be smart enough to also detect XML configured entities.

That's a real pity that three years after this question was asked, with Hibernate v. 5.2.12, it's still not easy to find how to generate metamodel without use of annotations. Anyway I am going to describe my solution here as this question (without any answer) pops up as the search result for the query "Generate metamodel without annotations". I struggled a bit with this task, but after all I got there with this ANT task:
<target name="jpa_metamodel">
<delete dir="..\\src_tmp"/>
<copy todir="..\\src_tmp">
<fileset dir="..\\src">
<include name="my/model/package/*.java"/>
<include name="META-INF/**/*.xml"/>
</fileset>
</copy>
<replace file="../src_tmp/my/model/package/AbstractEntity.java" token="class" value="#javax.persistence.Entity class"/>
<javac srcdir="..\\src_tmp"
destdir="..\\src_jpa_generated"
failonerror="true"
fork="false">
<compilerarg value="-proc:only"/>
<compilerarg line="-s ..\\src_jpa_generated"/>
<compilerarg line="-Adebug=true"/>
<classpath>
<fileset dir="..\\dependencies\\hibernate">
<include name="**\\*.jar"/>
</fileset>
<pathelement location="../src_tmp"/> <!-- to put META-INF in classpath -->
</classpath>
</javac>
</target>
Problems with Hibernate medamodel generator are:
/META-INF/persistence.xml and /META-INF/orm.xml are searched in classpath, and not in source folder. However it seems to be not enough, because after mapping XMLs are added to classpath they are correctly discovered and generator processes mentioned classes (log entries for every class are emitted), but still, for some reason, no output is produced. So to the next step...
It seems that it's not really possible to go further without actual annotation. Or maybe it is, but I still don't know how, but I can live with simple workaround. I simply automatically add #Entity annotation to temporarily copied sources. Actually I add the annotation in only one file, but in my case it happens to be a root of my entity hierarchy. This might have a meaning, and might not - I did not bother checking. However the need for this step indicates it might be difficult (impossible?) to generate metamodel for entity classes compiled without annotations.
You need to remember about -s compiler arg to store generated *.java files somewhere.
Hope this might be helpful for someone in the future.

Adding extra information in JUnit reports

I am using JUnit4 and want to put some extra information to be displayed in JUnit reports.
For this, I shall be dumping the extra information to the report xml and then modify the xslt to read that extra information to generate the HTML report.
Steps so far that are working are:
Copied all the code from XMLJUnitResultFormatter to MyFormatter.java and modified the endTest() method to add that extra information in the form of an extra attribute to testcase XML tag.
This is really bad :( but I could not simply override it as there usages of the private instance variables directly without getters/setters in endTest() method.
My junit ant task:
<junit fork="yes" printsummary="withOutAndErr">
<!--<formatter type="xml"/>-->
<formatter classname="com.some.junit.MyFormatter" extension=".xml"/>
<test name="com.some.source.MyTestClassTest" todir="${junit.output.dir}"/>
<classpath refid="JUnitProject.classpath"/>
</junit>
Modified the xslt to read the extra attribute of TESTCASE xml tag and display in report.
My modified ant task for report:
<target name="junitreport" depends="MyTestClassTest">
<junitreport todir="${junit.output.dir}">
<fileset dir="${junit.output.dir}">
<include name="TEST-*.xml"/>
</fileset>
<report styledir="reportstyle" format="frames" todir="${junit.output.dir}"/>
</junitreport>
</target>
I came across using TestNG nor SureFire Maven plugins as solutions, but I can't use them in my project.
Is there any better way than this in JUnit4?

Maybe?
The interface org.apache.tools.ant.taskdefs.optional.junit.JUnitResultFormatter is what needs to be implemented for a custom output format. This could write to any output stream, which is all the extensiblity that was built into the framework. You are right, there isn't a good way to extend the capabilities of XMLJUnitResultFormatter to customize the output. A copy-paste-modify certainly isn't ideal, but certainly acceptable.
Another approach might be to have more than one formatter defined in your ant task. One could be the regular xml formatter, with another being your custom one for additional information. These two files could be combined and then turned into HTML using xsl transforms.
I leave it to you to decide if this a better method than you had devised.

Why does Eclipse ant editor warn me

I am having some trouble (annoyance really) with ANT editor in Eclipse where it is displaying me a warning "Reference build.classpath not found." on the following block:
<target name="generate" depends="..., mvn-depends">
<taskdef name="xjc" classname="com.sun.tools.xjc.XJCTask">
<classpath refid="build.classpath" />
</taskdef>
...
</target>
With mvn-depends target looking like this:
<target name="mvn-depends">
<artifact:dependencies pathId="build.classpath">
<pom refid="my.pom" />
</artifact:dependencies>
</target>
The rest of the references to build.classpath in the build file are not throwing any warnings and the and build runs just fine without any errors, so it does not seem to be amounting to much.
Still, ignoring a warning makes me feel sort of dirty every time I have to edit that file. Specifically, not knowing if this is a bug in Eclipse ant build file validation code or a potential problem in the way the build file has been structured, that Eclipse has identified.
If anyone has any ideas on why this warning is being shown and whether it is safe to ignore or maybe even disable from preferences and would care to share that knowledge, I would definitely be grateful for the knowledge.
Edit:
As requested, here is an example of a reference to build.classpath that does not cause any warnings:
<javac deprecation="off" debug="on" source="1.7" target="1.7" encoding="UTF-8"
includeantruntime="false" memoryMaximumSize="512M" fork="true">
<classpath refid="build.classpath" />
</javac>

As the editor could recognize refids and other elements that Ant specifies, I guess that the editor does something similar to Ant's build file parsing process.
That is, parse this ant build file into a Project object, and references in <taskdef> may be checked, while <javac> may not.
Since the build.classpath is set during runtime and it is set by something other than things like <classpath>, Eclipse may not find it.
I don't have strong prove about this. But something can be done to make us know more.
First, copy the <javac> to the same target where the warned
<taskdef> exists, to see if the <javac> gets a warning;
Then, copy the <taskdef> to the same target where the presetdefed
<javac> exists, to see if the <taskdef> still gets a warning;
Third, in target "generate", comment out the <taskdef> part, and
check if the <xjc ... /> call gets a warning.
For the first one, I expect "NO", while for the other two, I expect "YES". Otherwise, my guess is wrong.
And it makes sense that it is just a warning -- things Eclipse can't find in editing time could exist during runtime.

Make sure you have given the path element location correctly as bellow.
<property name="dependencyfinder.home" value="C:/DependencyFinder"/>
<path id="dependencyfinder">
<pathelement location="${dependencyfinder.home}/lib/aaa.jar"/>
</path>
<taskdef classname="com.sun.tools.xjc.XJCTask">
<classpath refid="dependencyfinder"/>
</taskdef>
Note: DependencyFinder has a folder lib and lib has aaa.jar
Please check the bellow link for more information
Click here

XML schema method naming inconsistency

I am hoping someone has experienced this issue and can maybe shed some light.
I have an xml schema and an ant build file. The output .java files differ when I run ant on Windows versus Mac, even if I am using the same jaxb-xjc.jar to do the xml-compiling. The Windows side is naming the "getter" methods for attributes as "getX". The Mac side wants to name them "isX". Anyone experience anything like this before and/or have a solution? This is consistent between Windows Vista & 7 doing this the one way and Mac OSX 10.6 & 10.7 (untested on Mac OSX 10.8) doing it the other.
----edit----
I'll attach some of the code from the ant build.xml file.
Telling it what the xjc is.
<taskdef name="xjc" classname="com.sun.tools.xjc.XJCTask">
<classpath refid="classpath"/>
</taskdef>
Here is the 'actual' compiling:
Compiling the automaton schema
<echo>Compiling old automaton schema</echo>
<xjc schema="${oldxml-schema}" destdir="${src.dir}" package="${oldxml.package}">
<produces dir="${oldxml-gen.dir}" includes="**/*.java"/>
</xjc>
<echo>Compiling the plugin schema</echo>
<mkdir dir="${plugin-gen.dir}" />
<xjc schema="${plugin-schema}" destdir="${src.dir}" package="${plugin.package}">
<produces dir="${plugin-gen.dir}" includes="**/*.java"/>
</xjc>
<echo>Compiling the pluginDesumaSide schema</echo>
<mkdir dir="${pluginDesumaSide-gen.dir}" />
<xjc schema="${pluginDesumaSide-schema}" destdir="${src.dir}" package="${pluginDesumaSide.package}">
<produces dir="${pluginDesumaSide-gen.dir}" includes="**/*.java"/>
</xjc>
</target>
All targets (by that I mean anything mentioned like ${}) are defined and every links and compiles right except for Mac naming the 'getter' methods as 'is' methods for variables. They are boolean attributes that do have defaults if non-specified.

From the responses I got I was able to google for a solution. Apparently this naming inconsistency and another (a getter returning a primitive but the setter only accepting objects) was apparent by chance for older xml-compilers due to some inconsistency in the specification.
This was fixed by going to http://jaxb.java.net/ and getting a new jaxb-impl.jar & jaxb-xjc.jar. I downloaded and ran the jaxb.jar file download and it created the needed jars.

ant BeforeTargets

In MSBuild there is a BeforeTargets attribute you can add to a target that allows you to run a target before the base target without having to alter the base target. I was wondering if ANT supported this kind of functionality, or am I stuck having to redefine all my targets when I want to execute a target before another one ?
Thanks,
Raul

You can use the depends attribute in (N)Ant:
<target name="target3" depends="target1,target2">
which is same as DependsonTargets in MsBuild I suppose. I would strongly discourage you from using Before/After Targets. If I run a target, after seeing the build file, and see that some extra target is run before / after it eventhough I did not see anything being said about the other targets, I would be very confused and sometimes, this can cause harm.

In MSBuild 4.0, there are BeforeTargets and AfterTargets attributes for targets. These specify a list of targets that are to be run before/after another target.
This is actually quite nice for specifying something to occur after a target defined in another targets file you don't have control over (such as Microsoft.Common.targets).
Example:
<Import Project="Microsoft.Common.targets" />
<Target Name="GetSourceFiles" BeforeTargets="Build">
<Message Text="GetSourceFiles now executing" />
... execute your source control operations ...
</Target>
<Target Name="CopyOutputsForPublishing" AfterTargets="Build">
<Message Text="CopyOutputsForPublishing now executing" />
... execute your copying operations ...
</Target>
I've found these quite helpful.
Much more at:
http://blogs.msdn.com/b/visualstudio/archive/2010/02/18/build-extensibility-with-net-framework-4.aspx