It doesnt seem that when you combine these Fileset attribute like below:
eg:
<fileset dir="src">
<include name="gov/nasa/arc/mas/selenium/tests/*.java" />
<excludesfile name="${test.suite}.exclude" />
</fileset>
that it has the expected behavior which is to include all *.java under src but exclude all the file specified on the excludefile.
Is it possible to combine include and excludesfile or do you need to user a corresponding includesfile??
Its a shame that these things are not documented and its hard to find explanations on google.
Actually, I think the Ant Manual is pretty clear about these types of things.
What isn't clear to me is what it is that you want to do. Do you want to use external files for both your "includes" and your "excludes"? Or are you looking to have one override the other?
It is documented and should work: http://ant.apache.org/manual/Types/fileset.html
Note that in the excludesfile, "each line of this file is taken to be an exclude pattern." What does your excludesfile look like?
Related
I am adding more than 20 files to a fileset with various includes and excludes file. This takes a bit so the dependent task on Ant fileset is skipped by Ant. It wont run the dependent operation at all. This is inefficient. Does anyone know a better way to make the fileset to add files and then perform dependent instead of skipping it?
A way to do that is to use sleep https://ant.apache.org/manual/Tasks/sleep.html. I cannot use waitfor.
Example:
<fileset id="scr" dir="dir1/*" casesensitive="yes"
includes="bin/*, lib/* excludes="dir1/*.py />
<foreach param="file" in="scr">
<echo message="${file}"/>
</foreach>
</fileset>
The above example will skip printing the file name completely since Ant is still adding files to fileset.
The foreach task is not part of ANT, it is a 3rd party extension and I'm not entirely certain it's designed to work the way you think.
Instead could I suggest you print your fileset contents as follows:
<apply executable="echo">
<fileset dir="dir1/*" casesensitive="yes" includes="bin/*, lib/* excludes="dir1/*.py />
</apply>
Or like this if you want to use a fileset reference:
<fileset id="scr" dir="dir1/*" casesensitive="yes" includes="bin/*, lib/* excludes="dir1/*.py />
<apply executable="echo">
<fileset refid="scr"/>
</apply>
Note:
Ant is not a programming language so looping is not fun. If you need complex logic I highly recommend embedding a scripting language. I don't recommend ant-contrib
I've got a jar file that will match a certain pattern, but contains a version number that will change over time (it's placed there using a dependency manager). It is the only jar file that will ever be in that directory. Is there a way I can invoke Ant's java task using the directory and (if necessary) a pattern to find the jar file rather than statically specifying the filename? I'd rather not have to update build.xml every time the version changes.
So given something like this:
/path/to/some/jarfile-3.24.8.jar
... that might later look like this:
/path/to/some/jarfile-4.3.2.jar
Can I achieve the equivalent of this?
<java jar="path/to/some/jarfile-*.jar" fork="true" spawn="true" />
Thoughts
I was thinking maybe I could rig something up using the fileset task, but I couldn't find a way to reference it from the java task (and the java task doesn't support the <include> nested tag like some other tasks do).
... after further research, pathconvert looks like it might help. I'm not familiar enough with the mechanics to see how to piece things together though.
After some trial and error, I found a solution using fileset and pathconvert - here's my simplified solution:
<fileset dir="/path/to/some" id="jarfile-path-contents" includes="jarfile-*.jar" />
<pathconvert property="file.jarfile" refid="jarfile-path-contents" />
<java jar="${file.jarfile}" fork="true" spawn="false" />
I used fileset in order to specify the pattern and location of the jar.
I used pathconvert to place the found jar file reference into a property.
Then I was able to simply reference that property in my java task.
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 try to obfuscate my project, but not all code. I try obfuscate only code from 1 package.
How can i do it in yguard (or somewhere else, proguard?)?
Thanks!
From the documentation:
There are three possible ways of specifying which classes will be excluded from the shrinking and obfuscation process:
It looks like the second way will be most useful for you:
One can specify multiple java classes
using a modified version of a
patternset. The patternset's includes
and excludes element should use java
syntax, but the usual wildcards are
allowed. Some examples:
<class>
<patternset>
<include name="com.mycompany.**.*Bean"/>
<exclude name="com.mycompany.secretpackage.*"/>
<exclude name="com.mycompany.myapp.SecretBean"/>
</patternset>
</class>
I've developed a module for a Java project. The module depends on external library (fastutil). The problem is, the fastutil.jar file is a couple of times heavier than the whole project itself (14 MB). I only use a tiny subset of the classes from the library. The module is now finished, and no-one is likely to extend it in future. Is there a way I could extract only the relevant class to some fastutil_small.jar so that others don't have to download all this extra weight?
Obfuscation tools such as ProGuard usually provide a feature to remove unused classes (and even fields and methods) from the jar file. You have to be careful to verify everything still works, 'though, because you might be using reflecton to access classes or methods that ProGuard can't analyze.
You can use only that feature and already get quite some saving
Or you could combine it with other space-saving obfuscation techniques (such as class and method renaming) to save even more space at the cost of harder debugging (your stack traces will become harder to parse).
From the installation instructions of fastutil:
Note that the jar file is huge, due to the large number of classes: if you plan to ship your own jar with some fastutil classes included, you should look at AutoJar (also available at JPackage) to extract automatically the necessary classes.
As fastutil is LGPL open-source software, you could just copy the relevant source files to your project and drop that jar file. The compiler will then tell you if have all the files you need. Just keep the packages as they are and put a copy of the fastutil license file on top.
Yeah one crude is to have a backup of your original jar. then remove all unused class files from the jar. and there may be some internal references to other class which you can add as and when it is required. ie while executing it may throw a class not found exception so then you can add that class from the original jar to this jar.
For a project of any complexity, I would personally avoid Proguard for this very specific purpose of shrinking an external library like fastutil because doing so currently requires considerable configuration to specify all the jars that will be modified and those that are to be left intact. You will also have to specify the filters to get the source contents from your input jars into the correct output jars.
On top of that, the tool does not like to modify external jar files without having access to modify the application jar file. It will generate an error as a 'warning' even when only using the shrink option that indicates a library that is to be updated is referenced by a fixed jar file. If you are only shrinking the code and doing no optimizations or obfuscation, this requirement is an unnecessary limitation. In my case, this was forcing me to include a whole set of library references in my Proguard configuration as inputs when my only goal was to eliminate classes from the fastutil jar that I do not use.
I think Proguard could solve this issue with minor changes but for right now, I found its usage for the purpose to be frustrating and time consuming. Instead I offer up this solution for anyone who has this specific problem.
In this example, I use ant to clearly remove those primitive types that I do not use in my application and then remove the specific implementations of maps that I do not use. With this configuration, I reduced the jar file from 23Mb to 5Mb which was sufficient for my case.
<jar destfile="F:/Programs/Java/JARS/fastutil-8.5.6-partial.jar">
<zipfileset src="F:/Programs/Java/JARS/fastutil-8.5.6.jar">
<!-- eliminate keys of specific primitive types -->
<exclude name="it/unimi/dsi/fastutil/booleans/**"/>
<exclude name="it/unimi/dsi/fastutil/chars/**"/>
<exclude name="it/unimi/dsi/fastutil/doubles/**"/>
<exclude name="it/unimi/dsi/fastutil/io/**"/>
<exclude name="it/unimi/dsi/fastutil/longs/**"/>
<!-- eliminate maps of specific implementations -->
<exclude name="it/unimi/dsi/fastutil/**/*ArrayMap*"/>
<exclude name="it/unimi/dsi/fastutil/**/*AVLTree*"/>
<exclude name="it/unimi/dsi/fastutil/**/*CustomHash*"/>
<exclude name="it/unimi/dsi/fastutil/**/*Linked*"/>
<exclude name="it/unimi/dsi/fastutil/**/*RBTree*"/>
<exclude name="it/unimi/dsi/fastutil/**/*Reference*"/>
</zipfileset>
<zipfileset src="F:/Programs/Java/JARS/fastutil-8.5.6.jar">
<include name="**/*2ObjectFunction.class"/>
</zipfileset>
</jar>
While this is not the optimal solution, it is easier to setup and troubleshhoot than using Proguard.