I have a simple pre-processing step that infrequently needs to be performed on some resources in a Maven/Eclipse project, this involves a simple OS command using a utility executable, for example:
glslc triangle.frag -o spv.triangle.frag
The glslc executable processes the triangle.frag shader module and generates the spv.triangle.frag output file (in the same directory).
Ideally I would like a maven goal that performed the above for all modified .frag files within a given directory structure, rather than having to switch to a terminal, or create shell scripts, etc.
I assume an ANT plugin for Maven is the way to go (assuming that's the simplest and most common mechanism available). I have tried adding a maven antrun plugin but I'm struggling to work out how to configure it for multiple/modified files. I'm sure it's relatively straight-forward but it's been a long time since I've had to fiddle with ANT and I'm at a bit of a loss where to start. Had a look online but can't find any decent examples or tutorials, probably because I'm not searching for the right things.
Note that the files do not change that much but it would be very convenient to have a quick-and-dirty (or hot-deploy) means of generating the output file file(s) that have changed.
Also note that these resources do not need to be part of the maven build/deploy process, i.e. they are only used during development and testing.
Alternatively is there an equivalent Eclipse mechanism that that can be used to do the same thing? Again this is a convenience so something relatively 'manual' is fine.
I'm looking for any pointers to relevant examples, tutorials, repos, etc. as a starting point or hint from which I can then implement a solution.
Related
I do not understand the purpose of ant. I read the introduction, but am missing the big picture. I know the following (or at least that I want to use them),
Java
jdbc
hibernate
jsp
servlet container like Tomcat
But I don't see how ant fits in.
Is there some all comprehensive tutorial that tells me how to put all this together?
Why would I want ant? What is the alternative if I don't have ant?
EDIT: So is this sort of the compiling part of its Visual Studio counterpart?
Ant is used as a build system. You do not have to use it--in fact there are quite a few better systems but since ant was one of the first it's still likely to be very common. It generally is used to compile your java files, create wars and often even put the .war files onto the tomcats.
Maven is bigger and tries to do a lot more, but it's also rather strict in it's format and quite heavy--but it's quite common these days as well. Maven can gather all your dependencies automatically which is nice, with ant you still have to download everything yourself.
There are others, but you get the idea.
Response to comment:
I don't use visual studio, but I think it is more limited. For instance, Eclipse can build all your java files into a jar or execute them directly (in fact, it uses ant internally). If you wanted to take your visual stuido "Build configuration" and put it into another tool (Perhaps an automated build system like Jenkins) that doesn't rely on visual studio directly, can you do so?
I guess Ant is the way we code our builds--it's portable betweeen many tools. Visual Studio would be cleaner to "create" your build, but "Exporting" the ability to build would be more difficult (if even possible).
Also ant is portable across operating systems as well as tools. We can switch from Eclipse to Netbeans to IntelliJ without touching our build toolchain.
How would you completely remove visual studio and replace it with slickedit, emacs or vi (if that was your thing, which I'm sure it's not) without starting over from scratch with your build?
For any web application to work you need to package or build all your java code with all the libraries into an web application archive to accomplish this task we need to some tool or library to package into the correct format and some of the libraries which can achieve this is
Apache Ant and Apache Maven
There some good discussions about Ant vs Maven in SO.
You need ant to build the project. Well you can build project using IDE like eclipse etc. But for production purpose and big projects, it always advisable to some build script like ant. Its a script where you can customize what you want to build and what not. you can define what is the output should be like war/jar/ear etc
Other alternative is Maven which is very prevalent and standard now a days
I have a vague memory that I've seen a build system for Java or some other JVM lang which you could run in continous mode (so to speak). This would make the build system run in the background, watching the source dir for changes. As soon as a source file changes, the build system kicks in and re-runs relevant parts of the build process to produce a fresh artifact.
Ring any bells?
Thanks
Is it the gradle daemon?
This keeps gradle running in the background because it has long start up times - and scans the file system to identify when files change.
There are lots of engines that support continual checkouts/building/testing (e.g. Jenkins nee Hudson, CruiseControl, TeamCity etc.).
If you're looking at JVM languages other than Java, then (for example) the Maven Scala plugin supports continuous building and testing upon file changes. e.g.
$ mvn scala:cctest
will run the compile/test cycle in a loop watching for source changes and acting upon them.
If your build tool or language doesn't support this natively, it's trivial to write a shell script to watch a directory structure and execute another script/tool upon change. See this SO question for solutions.
I figured out that it was in fact sbt that I meant. There is another question here on SO relating to how to build Java projects: Use SBT to Build Pure Java Project. Thanks everyone for your help.
i am setting up a java project now. in the past, we always included everything (unzipped) from the 3rdparty, such as ant, junit, jfreechart, and others, inside our release. I am wondering is it possible just take those related .jar files but not everything with our software release? then we can get a smaller and neat release. Those 3rdparty library licenses don't allow us to do that way? what's your way? thanks,
You really want to retain the separate jars, if possible. Check out the maven appassembler plugin. It does a nice job of putting together an "unzippable" installation for you, in a controlled way. In the result you'll have a very straightforward "repo" directory filled with all of your dependencies.
I use the maven-assembly-plugin to build a single jar for each application. The plugin quickly handles the fuss of unzipping all the library jars and putting the whole lot back together as a single jar. It also supports writing a manifest with a main class specified which makes running the application simple from a command line (much simpler than specifying a classpath argument as long as your arm anyway).
If their licenses say that you should distribute derivatives with sources, then you are obliged to do that by law.
Another question is if they really force that. As far as I remember GPL, you shall distribute the sources if you want, but there is another way - you must make sources easily availiable to users. So you can drop sources in your distributables.
Any way, you should look at the licenses.
EDIT:
If you will decide to pack the whole program into single jar, I recommend Proguard. It is java optimiser, shrinker, and much more - all in one! To pack everything into one jar, just specify all your jars - program and libraries - as program jars, and specify only one jar as output. Usually it works just fine.
What's the best option for packaging and distributing a command line application written in Java, targetting OS/X and Unix?
The executable jar option seems fairly robust, and my distribution doesn't need to be super fancy, so right now I'm just thinking of plonking a bash script next to that with the relevant java invocation and being done with it.
I'm wondering if there's something similar to python's bdist package that would let me easily make nice installers for both target platforms. Or if there's some more obvious way that I'm missing where I can turn the entire distribution in to a executable file that wraps the jar in some way.
Since you are providing a CLI application it may be easiest to just provide the script you already mentioned. I usually try to keep it self-contained, e. g. not referencing external paths / using only relative paths etc. And maybe a readme.txt file.
If you would like to provide a full-blown installer, you might want to take a look at IzPack, a tool for generating installers for Java deliverables. It also allows the wizard to run in console mode, if you do not have a graphical environment available for installation (see the "Features" page in the link above).
How do you ensure, that you can checkout the code into Eclipse or NetBeans and work there with it?
Edit: If you not checking in ide-related files, you have to reconfigure buildpath, includes and all this stuff, each time you checkout the project. I don't know, if ant (especially an ant buildfile which is created/exported from eclipse) will work with an other ide seamlessly.
We actually maintain a Netbeans and an Eclipse project for our code in SVN right now with no troubles at all. The Netbeans files don't step on the Eclipse files. We have our projects structured like this:
sample-project
+ bin
+ launches
+ lib
+ logs
+ nbproject
+ src
+ java
.classpath
.project
build.xml
The biggest points seem to be:
Prohibit any absolute paths in the
project files for either IDE.
Set the project files to output the
class files to the same directory.
svn:ignore the private
directory in the .nbproject
directory.
svn:ignore the directory used for
class file output from the IDEs and any other runtime generated directories like the logs directory above.
Have people using both consistently
so that differences get resolved
quickly.
Also maintain a build system
independent of the IDEs such as
cruisecontrol.
Use UTF-8 and correct any encoding issues
immediately.
We are developing on Fedora 9 32-bit and 64-bit, Vista, and WindowsXP and about half of the developers use one IDE or the other. A few use both and switch back and forth regularly.
The smart ass answer is "by doing so" - unless you aren't working with multiple IDEs you don't know if you are really prepared for working with multiple IDEs. Honest. :)
I always have seen multiple platforms as more cumbersome, as they may use different encoding standards (e.g. Windows may default to ISO-8859-1, Linux to UTF-8) - for me encoding has caused way more issues than IDEs.
Some more pointers:
You might want to go with Maven (http://maven.apache.org), let it generate IDE specific files and never commit them to source control.
In order to be sure that you are generating the correct artefacts, you should have a dedicated server build your deliverables (e.g. cruisecontrol), either with the help of ant, maven or any other tool. These deliverables are the ones that are tested outside of development machines. Great way to make people aware that there is another world outside their own machine.
Prohibit any machine specific path to be contained in any IDE specific file found in source control. Always reference external libraries by logical path names, preferable containing their version (if you don't use maven)
The best thing is probably to not commit any IDE related file (such as Eclipse's .project), that way everyone can checkout the project and do his thing as he wants.
That being said, I guess most IDEs have their own config file scheme, so maybe you can commit it all without having any conflict, but it feels messy imo.
For the most part I'd agree with seldaek, but I'm also inclined to say that you should at least give a file that says what the dependencies are, what Java version to use to compile, etc, and anything extra that a NetBeans/Eclipse developer might need to compile in their IDE.
We currently only use Eclipse and so we commit all the Eclipse .classpath .project files to svn which I think is the better solution because then everyone is able too reproduce errors and what-not easily instead of faffing about with IDE specifics.
I'm of the philosophy that the build should be done with a "lowest common denominator" approach. What goes into source control is what is required to do the build. While I develop exclusively in with Eclipse, my build is with ant at the command line.
With respect to source control, I only check in files that are essential to the build from the command line. No Eclipse files. When I setup a new development machine (seems like twice a year), it takes a little effort to get Eclipse to import the project from an ant build file but nothing scary. (In theory, this should work the same for other IDEs, no? Surly they must be able to import from ant?)
I've also documented how to setup a bare minimum build environment.
I use maven, and check in just the pom & source.
After checking out a project, I run mvn eclipse:eclipse
I tell svn to ignore the generated .project, etc.
Here's what i do:
Only maintain in source control your ant build script and associated classpath. Classpath could either be explicit in the ant script, a property file or managed by ivy.
write an ant target to generate the Eclipse .classpath file from the ant classpath
Netbeans will use your build script and classpath, just configure it to do so through a free form project.
This way you get IDE independent build scripts and happy developers :)
There's a blog on netbeans site on how to do 3. but i can't find it right now. I've put some notes on how to do the above on my site - link text (quick and ugly though, sorry)
Note that if you're using Ivy (a good idea) and eclipse you might be tempted to use the eclipse ivy plugin. I've used it and found it to be horribly buggy and unreliable. Better to use 2. above.