I'm struggling with the following issue: I want to set up my ant for compiling Java source code. Everything works fine, but I also want to use the spotbugs / findpugs analyzing tool.
So in the manual is written:
<taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask"/>
Honestly, I don't know what they want from me. What is classname? I sat here for hours and didn't find a solution. Of course, spotbugs says the class cannot be found. What is precisely expected?
Have you checked the official spotbugs document?
In your case, you need to add classpath attribute to let ant finds spotbugs-ant.jar. You also need to add <spotbugs> element to run spotbugs analysis.
Related
Eclipse is up to date, cofoja too, and so are java jre/jdk.
ASM should be included in cofoja, but I downloaded the 3.3 just in case.
I followed all the procedures I could find in internet, but the first error eclipse is giving never changed from the first step: "Syntax error, insert "EnumBody" to complete BlockStatements".
The code is very basic:
import java.io.whatever;
import java.net.whatever;
import com.google.java.contract.Requires;
public class ManageSocketServerExplicit{
[...]
public ManageSocketServerExplicit(String p_ipAddress, int p_port){
#Requires("p_port >= 0")
this(p_ipAddress,p_port,10,1000);
[...]
}
}
The error is obviously at the end of the Require.
Configuration
There are several projects in the directory. Let's say that I want to use cofoja just on one of them.
The base directory is C:\svn_java\Progetti_NET, in which there is the project I want to use cofoja on, which is 'Malu'. Into it there are multiple source directories, not just a generic 'src', but the main is called 'Code', and it's the principal.
So the paths are (tried them with both slashes, nothing changes):
classoutput C:\svn_java\Progetti_NET\Malu\bin
classpath C:\svn_java\cofoja-1.1-r146.jar
sourcepath C:\svn_java\Progetti_NET\Malu\Code
Eclipse understands the namespace of cofoja, by the way: I can see the objects listed if I auto-complete them.
So 'Annotation Processing' is all set, and 'Factory Path' again contains "c:\svn_java\cofoja-1.1-r146.jar". The workspace automatically updates when there are changes, and both asmn and cofoja are in the libraries of the 'Java Build Path'.
I tried to add also the -vm command in eclipse.ini to use the jdk (C:/Program Files (x86)/Java/jdk1.7.0_21/bin), but again nothing changed.
Since the configuration is pretty simple it shouldn't be so hard to fix it, but I don't know how.
i used Cofoja with eclipse and i used this link to configure it.
However it has a missing factory path. You need to state the sourcepath too as shown in my image.
If you run it using eclipse, you have to set the run configurations of the file and add the following VM arguements
-javaagent:PATH TO JAR/cofoja.jar
And #Requires and #Ensures are method-level contracts.
You cant write it within the method. Instead you need to write it as follows
public class ManageSocketServerExplicit{
[...]
#Requires("p_port >= 0") // CONTRACT
public ManageSocketServerExplicit(String p_ipAddress, int p_port){
this(p_ipAddress,p_port,10,1000);
[...]
} }
Hope it helps :D
Ok, I understood what was wrong: after adding the source code of cofoja to the project I understood I placed the #Requires in the wrong place... The annotation #Ensures gave me this error, but I forgot about it.
:(
a very well realized tutorial: http://webcourse.cs.technion.ac.il/236700/Spring2013/ho/WCFiles/Contracts%20for%20Java.pdf
jre comes with many libraries in rt.jar one of which is com.sun.istack.internal*. I needed the documentation of com.sun.istack.internal.Nullable(which I found being used by google in its CacheBuilder) and first I thought was to go to docs.oracle.com to find its documentation and there I found nothing about it. Next went to source folder sourced with jdk and I didn't find com name entity in the said folder. Next I take a look at the jre7 release and take a look at all the packages and class and found no mention of Nullable there. Though SO had one mention of it, but nothing concrete. I am still puzzled where to get its documentaion and src if needed. I even looked legacy sun api documentation at oracle but nothing mentioned about it. where does oracle document there policy about ported packages and their being standard or not-standard.They must have documented it somewhere it is just that I'm taking too much of time to get there.
Please point me there.
EDIT: Actually the javax.annotation.Nullable is being used in google CacheBuilder and not com.sun.istack.internal.Nullable.
Also for someone who may face this issue: javax.annotation.Nullable is not part of Java SE as of now, and it is being ported in jsr305 jar. So if you are planning to use CacheBuilder or just going through its code, do add jsr305 jar in your class path, else eclipse get confuse and will point you to com.sun.istack.intenal.Nullable when ever you hover your cursor over Nullable.
Guava doesn't use com.sun.istack.internal.Nullable. Everything that is not documented in the official Java SE javadoc is internal code, and should not be used in applications.
You're probably looking for javax.annotation.Nullable, which is part of JSR305.
Here is a link to the source code:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/istack/internal/Nullable.java/
(This link may break in the future, but you should be able to find an equivalent using a Google search.)
The reason that you can't find the source code or javadocs in the standard JDK / JRE distributions is that this is a INTERNAL class. There is a long-standing Oracle / Sun policy of discouraging developers from writing code that is dependent on Java internal classes.
FWIW - this is just an annotation, and the meaning is pretty much what the class name implies.
UPDATE - Apparently, the real cause of this confusion is that you didn't include the JSR305 jar in your buildpath. It is a dependency for CacheBuilder. Eclipse classname completion is then doing its best ... but failing.
It is said that It's Oracle's intent that these classes be inaccessible at compile-time.
Below is my workaround in case adding a modern jar for those annotation is not allowed.
If using Gradle, add:
compileJava.options.compilerArgs << "-XDignore.symbol.file"
If using Ant, change the javac tag like:
<javac srcdir="src" destdir="${classes.dir}" classpathref="classpath" memoryinitialsize="512m" memorymaximumsize="1024m" fork="true">
<compilerarg line="-encoding utf-8 -XDignore.symbol.file"/>
<exclude name="test/**"/>
</javac>
Im getting a complaint in my Ant build which refers to a missing junit file :
/reports/style/junit-frames.xsl
This error creeped up after I added the tag to my ant tasks, as a method for printing the failures of unit tests out .
JUnit frames expects XSL stylesheets to format the reports correctly. These are junit-frames.xsl and junit-noframes.xsl. You'll need to create these files, or copy them from somewhere. I guess you've defined a styledir which doesn't exist or something?
See JUnitReport task, parameters section.
There are example files in <ant installation directory>/etc.
Because this file probably does not exist and you will have to write it.
I guess you are referring to your other question?
Admitted, this doesn't sound like a best practice altogether, but let me explain. During the build, we need to paste the build number and the system version into a class whose sole purpose is to contain these values and make them accessible.
Our first idea was to use system properties, but due to the volatility of the deployment environment (an other way of saying "the sysadmins are doing weird unholy creepy things") we would like to have them hard-coded.
Essentially I see 4 possibilities to achieve it in ant :
use <replace> on a token in the class
The problem with this approach is that the file is changed, so you have to replace the token back after compilation with a <replaceregexp>...sooo ugly, I don't want to touch source code with regex. Plus temporal dependencies.
copy the file, make replace on the copy, compile copy, delete copy
One one has to mind the sequence - the original class has to be compiled first in order to be overwritten by the copy. Temporal dependencies are ugly too.
copy the file, replace the token on the original, compile, replace the stained original with the copy
Same temporal dependency issue unless embedded in the compile target. Which is ugly too, because all our build files use the same imported compile target.
create the file from scratch in the build script / store the file outside the source path
Is an improvement over the first three as there are no temporal dependencies, but the compiler/IDE is very unhappy as it is oblivious of the class. The red markers are disturbingly ugly.
What are your thoughts on the alternatives?
Are there any best practices for this?
I sure hope I have missed a perfectly sane approach.
Thank you
EDIT
We ended up using the manifest to store the build number and system version in the Implementation-Version attribute, unsing MyClass.class.getPackage().getImplementationVersion(). I have found this solution was one of the answers to this thread, which was posted in the comment by andersoj
I think a simpler approach would be to have your Version.java class read from a simple .properties file included in the JAR, and just generate this .properties file at build-time in the Ant build. For example just generate:
build.number = 142
build.timestamp = 5/12/2011 12:31
The built-in <buildnumber> task in Ant does half of this already (see the second example).
#2 is generally the way I've seen it done, except that your not-ready-to-compile sources should be in a separate place from you ready-to-compile sources. This avoids the temporal issues you talk about as it should only be compiled once.
This is a common pattern that shows up all the time in software build processes.
The pattern being:
Generate source from some resource and then compile it.
This applies to many things from filtering sources before compilation to generating interface stubs for RMI, CORBA, Web Services, etc...
Copy the source to a designated 'generated sources' location and do the token replacement on the copies files to generate sources, then compile the generated sources to your compiled classes destination.
The order of compilation will depend on whether or not your other sources depend on the generated sources.
My solution would be to:
use on a token in the class:
<replace dir="${source.dir}" includes="**/BuildInfo.*" summary="yes">
<replacefilter token="{{BUILD}}" value="${build}" />
<replacefilter token="{{BUILDDATE}}" value="${builddate}" />
</replace>
This replacement should only take place in the build steps performed by your build system, never within a compile/debug session inside an IDE.
The build system setup should not submit changed source code back to the source repository anyway, so the problem of changed code does not exist with this approach.
In my experience it does not help when you place the build information in a property file, as administrators tend to keep property files while upgrading - replacing the property file that came out of the install. (Build information in a property file is informational to us. It gives an opportunity to check during startup if the property file is in synch with the code version.)
I remember we used the 4th approach in a little different way. You can pass release number to the ant script while creating a release.Ant script should include that in the release(config/properties file) and your class should read it from there may be using properties file or config file.
I always recommend to create some sort of directory and put all built code there. Don't touch the directories you checked out. I usually create a target directory and place all files modified and built there.
If there aren't too many *.java files (or *.cpp files), copy them to target/source' and compile there. You can use thetask with a` to modify this file one file with the build number as you copy it.
<javac srcdir="${target.dir}/source"
destdir="${target.dir}/classes"
[yadda, yadda, yadda]
</java>
This way, you're making no modification in the checked out source directory, so no one will accidentally check in the changes. Plus, you can do a clean by simply deleting the target directory.
If there are thousands, if not millions of *.java files, then you can copy the templates to target/source and then compile the source in both {$basedir}/source and target/source. That way, you're still not mucking up the checked out code and leaving a chance that someone will accidentally check in a modified version. And, you can still do a clean by simply removing target.
I was looking for a solution to the same problem, reading this link: http://ant.apache.org/manual/Tasks/propertyfile.html I was able to findout the solution.
I work with netbeans, so I just need to add this piece of code to my build.xml
<target name="-post-init">
<property name="header" value="##Generated file - do not modify!"/>
<propertyfile file="${src.dir}/version.prop" comment="${header}">
<entry key="product.build.major" type="int" value="1" />
<entry key="product.build.minor" type="int" default="0" operation="+" />
<entry key="product.build.date" type="date" value="now" />
</propertyfile>
</target>
This will increment the minor version each time yo compile the project with clean and build. So you are save to run the project any time that the minor version will stay still.
And I just need to read the file in Runtime. I hope this help.
I'm doing a build script for a Java application to run inside the Oracle JVM. In order to import the 50-odd classes, it appears I need to bring them in in order, so any dependencies are present before compilation.
For each class, I'm running 'create or replace and compile java source {className} as {classPath}' for each file. Doing this gives me a compilation error, as the required class(es) are not imported.
How can I generate a list of the classes, in dependency order - that is, as you go down the list, the class's dependencies are listed above. I would prefer to do this as an Ant task.
Also if you have a better idea of how to get these classes imported, I'd love to hear your ideas.
I can't imagine why you'd need to do this, but if you really need to do this, I wonder if hacking a little classloader that prints out each class as it loads and load your app from there would give you a dependency graph?
Compile the classes in the filesystem using the Ant task javac. Use the task depend if more rigorous dependency checking is needed. Use the loadjava tool to load the .class and .java files into the database in arbitrary order.
In order to import the 50-odd classes, it appears I need to bring them in in order so any dependencies are present before compilation.
I have never had to do such a thing simply to compile Java.
This is what Ant was born for. I'd recommend just doing this with Ant. Set the <classpath> and you'll have no trouble.
Brute force method: put the 50 CREATEs in a batch file and execute it until no errors are found. Create the loop in a shell script. Of course it will never end if there are errors in the sources, but I'm assuming they are ok.
Can you not load in a jar file? Why does it have to be individual classes?