I've been doing some research on the maven source and javadoc plugins, and I wanted to inquire a bit about the usage of each.
I understand conceptually how the plugins work, and what they do.
What I'm confused about, is why you would want to bundle sources or javadoc along with your artifact. Doesn't the javadoc get published when you do site:deploy? If I am creating a JAR library that will be used as a dependency of another project in eclipse, will attaching javadoc or sources enable me to see the javadoc in eclipse when using functions in that library, whereas if I fail to use the javadoc plugin, they won't be available?
What is "forked-path" and "jar-no-fork"? They seem to be relevant to this. Like I said I've done a lot of researching, I just can't tie it all together. Thanks!
Eclipse and other tools know how to download source and javadoc artifacts and use them to show you doc and source of your dependencies.
Forked-path and jar-no-fork are just about not running out of memory.
Related
By default, Maven standard directory layout has two Java source folders:
src/main/java
src/test/java
For my purposes, I need a third one src/junit/java which should be packaged into a JAR with the classifier junit.
If possible, the new source folder should have it's own classpath (compile + everything with scope junit).
My guess is that for this, I will have to modify at least the resource and compile plugins.
Or is there an easier way?
I have a workaround as explained here but for that, I have to put things like Mockito and JUnit on the compile classpath which violates my sense of purity.
For all people who doubt the wisdom of my approach: I have support code that help to write unit tests when you work with code from src/main/java. Since I'm using the same support code in the tests for the project itself, this code needs to be compiled after src/main/java and before src/test/java.
Specifically, my support code needs to import code from src/main/java and the tests need to be able to import the support code.
I've seen a couple of Maven setups, which bundle test code in an own Maven module. You could then create a simple main-module <- support-module <- test-module dependency chain with that. But then main-module would compile fine, if you build it on it's own without test-module. Ofc you could aggreate them together with a reactor-pom and just build the project via this pom.
Edit:
If you have problems with this setup regarding code coverage, you can use the Jacoco Maven plugin to aggregate the test coverage generated by test-module to main-module. See this for further information: http://www.petrikainulainen.net/programming/maven/creating-code-coverage-reports-for-unit-and-integration-tests-with-the-jacoco-maven-plugin/
Is there anywhere that can give you a tutorial or anything on creating a Debian package using Ant?
I'm being told its already a part of Ant but I've never seen any functions even remotely associated with it.
I don't want to use ant-deb-task either seeing as its not actually part of Ant.
There is no task for this in the core Ant distribution.
There are examples for ant-deb-task available in the examples file on the download page.
Another option is jdeb which also provides documentation.
The team I work for manages a large collection of technical documentation which is written in LaTeX.
Currently all the documentation we have is manually built by the editors and then checked into a version control system. Sometimes people forget to compile their documents so we have a situation where the PDF and .tex files are often out of step. Unfortunately when this happens our users find themselves reading old versions of our document.
I've managed to hack a simple script to build PDFs using Make - it's rather clumsy.
I was wondering if there was a better way to do it? Most people in our department use Eclipse + Pydev for a Python project which means we are all very familiar with this IDE. I know that Ant plays nicely with Eclipse, so might we be able to use this tool for our doc building?
So what's the best way of doing this? I hope I will not have to learn everything there is to know about a new build-system in order to automate the building of some quite simple docs.
There is an external Ant task for LaTeX PDF generation, though the site is in German.
To use it, download the jar to a location on your machine, then define a taskdef as follows:
<taskdef name="latex" classname="de.dokutransdata.antlatex.LaTeX"
classpath="/path/to/ant/lib/ant_latex.jar"/>
Then to use it, define a target like this:
<target name="doLaTeX">
<latex
latexfile="${ltx2.file}"
verbose="on"
clean="on"
pdftex="off"
workingDir="${basedir}"
/>
</target>
Where ltx2.file is the file to process.
This is a link to the howto page listing the parameters. If you need any more options, my German is just about passable enough to explain, maybe.
There is also a maven plugin for LaTeX, but I can't find any documentation.
Haven't tried it, but I remember seeing a blog post about it.
If you know python, this blog post might be interesting
EDIT: Also, I would assume that you're using some kind of version control system, and I can't say for sure, but I use git to manage all my latex docs, and it might be possible to use some kind of post-commit hook to execute a script to rebuild the document. This would depend on how your repository is structured... just thinking out loud, so to speak.
I went into great detail on a large number of build systems for latex in this question, but its slightly different in your case. I think you want rubber or latexmk. The latex-makefile seems a good idea, but only supports building via postscript, which might not be your build process.
In general, its a good idea to keep generated files outside of version control for just this reason. A good exception is when specialist build tools are not widely available, and your situation sounds similar. You might do better with a commit-hook to build automatically upon commit.
I guess I should also point out that committing something without first building it and checking it is a deadly sin, so a better solution might be to stamp that out.
Maven is a better alternative as build system compared to Ant. So I would recommend a maven-plugin to generate PDF from LaTeX sources. Have a look at mathan-latex-maven-plugin
After a recent juggling with our ant scripts I've started to wonder if something better is possible.
I need a builder that will know to recompile all required .java files for me.
For ex. for this structure
public class A { ]
public class B extends A {}
public class C {
B b;
}
For: Compile('C') Will know to compile A, B, C.
For: B changed, Compile('C') will know to recompile just B.
I know of several alternatives, Ivy which seems like an extension of ant which is our current java builder. Scons which we are currently using for building C++ code, scons is excellent in doing the above described behavior for C code. Then there are reports of Maven being almost but not quite there.
What would you suggest? What tools are you using Free Software / Commercial for you build system?
Thank you,
Maxim.
Ant, with 'depend' task and with 'closure' option turned on
'make', from IDEA ide
None of ivy, scons or maven will help you with your problem as stated.
What do you mean by "for Compile('C')"? I don't think this is what you have in your ant file.
For this case, Ant should be working as desired: you have described its default behaviour. In the same javac element, Ant will only recompile changed classes. See the Ant manual entry for the javac task, especially the 'includeDestClasses' attribute.
You should probably post an example ant file that you are finding inadequate.
maven, both for my personal and my commercial products
In your question you describe inter-class dependencies. Most build systems, in particular Maven, are aimed more at inter-project dependencies. I believe most systems just recompile all the classes in a project and most of the benefits of these build systems is in building as few projects as possible.
Both Maven and Ivy will allow you to easily specify both external and internal dependencies of your project, including which version of the project you depend on. They will both also automatically download external libraries (such as apache commons) to your local machine as part of the build process if they are not already locally cached, saving a lot of work manually downloading and organizing third party jar files.
Ivy is an extension of ant, like you mention. I recommend Maven. It is a convention oriented build system that I've used successfully and feel is quite mature. Maven requires far less up front effort to start using and is quite extensible.
I'm wondering are there more current and active alternative tools to the Apache Forrest product for project documentation that developers are using?. It seems to be stuck in v0.8 release since 2007.
I'm thinking about using the maven site via Ant to generate a HTML report with the various javadoc, pmd and findbug reports for my project. Just wondering what other developers are using out there.
maven can grenerate copious amounts of project documentation.
I'd point you to the maven documentation for this, but the maven documentation is, ironically, rubbish.
We generate most of our documentation from source using a new open source build system for Java called EBuild (features) that is a great alternative to Maven. You may have to adopt EBuild-specific conventions to make the most of that though.
There's some detailed articles on the deficiencies of Ant and also Maven on the site.