I am generating the Javadoc of my project using maven (with the javadoc:javadoc goal).
I have also configured the Javadoc Location property of my project to the folder where maven generates the Javadoc. Then I can easily see the full Javadoc of a class from the Eclipse Javadoc view by selecting "Open Attached Javadoc in a Browser".
However, every time I do some changes in the documentation I need to explicitly recreate the documentation with maven, before I can see the documentation updates in the browser.
Is there a way I can instruct Eclipse to automatically generate the Javadoc files when a file is saved ?
I know this is probably not a good idea when not focused on writing documentation, since it may slow down a bit Eclipse. However, when my main task is writing documentation, a bit of automation in this sense will be appreciated. I guess the right solution passes by updating the documentation of only the files that were saved (and not triggering the whole Javadoc generation process), but I do not know if such a thing is possible.
If you're using the Maven Integration for Eclipse (m2e), you can set up a plugin execution filter so that m2e knows that you desire a particular plugin execution to be also executed in Eclipse. You would want to have the plugin run in the background:
<execute >
<runOnIncremental>true</runOnIncremental>
</execute >
The flip side of this all is that it will run your entire Javadoc execution whenever you save something, incremental is misleading in that sense. It may clog up your Eclipse, and not just "a bit", like you say in the updated question. Every plugin execution that does more than the absolute trivial should be heavily scrutinized.
A truly incremental solution will not come from Maven, since it has no sense of only parts of the project having to be built. Rather, you would need Eclipse to do this directly. I think the same thing happens for Java compilation: it is done by Eclipse itself, incrementally. However, according to the Javadoc FAQ:
A9. Can I incrementally build a document from different runs of Javadoc?
Basically no (...)
We call this incremental build and are considering it for a future release.
But nothing is impossible :)
Related
I forked a repository from Github that has a lot of packages and files, implementing all kind of algorithms, simulations and utility classes.
However, in my research I don't need all of these files/packages for my own simulation to work.
I would like to keep my forked project as minimal as possible, so I would like to keep only the necessary packages/files that are needed to compile my simulation.
I'm talking specifically about the IDE Eclipse. If I decide to "backtrack" all imports starting from my simulation file, I would definitely get lost because the original project is big.
On the other side, if I decide to "delete" a package and see if my simulation compiles, I would stay all week trying this out, and if I delete a needed file I would have to attach it again to my project which is troublesome.
Is there an automatic tool I can use to do this on Eclipse?
A simple option is to use a coverage checker to see what methods in what classes are used during execution, and delete the rest. And then revert anything that causes a compilation error.
This only works for code, not resources, though - and only if something like reflection isn’t used.
I am new to maven and Jcodemodel. I am trying to create an archetype which will accept the wsdl and generate the code. I need to create java code for implementation class file by implementing the interface. I need to use JCodeModel to generate java code. But I am new to JCode. How to use Jcodemodel inside Maven archetype to generate java code?
Kindly, guide me
Maven will build your projects and automate some aspects of managing the builds and the project; but, it will not decide for you what the project does, or how to go about writing the project.
You might need to write Java code that (because you mentioned a WSDL) runs as a web service. That web service apparently should accept "something" and reply back with "something". It is a guess (this is a very vague question), that the something it should accept is some sort of description of a Java class, and the something it should reply will be either Java source code, or a compiled java class.
In either case, the project can be managed by Maven, meaning that Maven will compile, test, and package your project. In certain cases, it will also deploy it (if you configured Maven to do so).
Now if you want Maven to actually accept the WSDL and generate the code, then what Maven will build will be static, meaning that the "generated" code will not be able to change after Maven completes the build. You can; however, build the "next" version which might change. If this scenario sounds more like what you had in mind, then your "source" would be a static file, and the "built project" would be the source code or the object code corresponding to the source.
Without more direction, this is probably the best guide you are going to get. It is just too vague a question, covering too much ground to say much definitively. You also seem to lack a lot of knowledge in a lot key places simultaneously; perhaps the best solution is to identify what you will likely need to brush up on, order those by "what needs what" and start with the element that depends on nothing else.
The problem scienario is as follows (Note: this is not a cross-jar dependency issue, so tools like JarAnalyzer, ClassDep or Tattletale would not help. Thanks).
I have a big project which is compiled into 10 or more jar artifacts. All jars depend on each other and form a dependency hierarchy.
Whenever I need to modify one of the jars, I would check out the relevant source code and the source code for projects that depend on it. Modify the code, compile, repackage the jars. So far so good.
The problem is: I may forget to check one of the dependent projects, because inter-jar dependencies can be quite long, and may change with time. If this happens some jars may go "out-of-sync" and I will eventually get a NoSuchMethodException or a some other class incompatibility issue at run-time, which is what I want to avoid.
The only solution I can think of, the most straighforward one, is to check out all projects, and recompile the bunch. But this takes time, especially if I re-build it every small change. I do have a continuous integration server, that could do this for me, but it's shared with other developers, so seeing if the build breaks is not an option for me.
However, I do have all the jars so hypothetically it should be possible to verify jars which depend on the code that I modified have an inconsistency in method signature, class names, etc. But how could I perform such check?
Has anyone faced a similar problem before? If so, how did you solve it? Any tools or methodologies would be appreciated.
Let me know if you need clarification. Thanks.
EDIT:
I would like to clarify my question a little bit.
The ultimate goal of this task is to check that the changes that I have made will compile against the whole project. I am looking for a tool/technique that would aid me perform such check.
Consider this example:
You have 2 projects: A and B which are deployed as A.jar and B.jar respectively. A depends on B.
You wish to modify B, so you check it out and modify a method signature that A happens to depend on. You can compile B and run all tests by itself without any problems because B itself does not depend on anything. So you happily commit your changes.
In a few hours the complete project integration fails because A could not be compiled!
How do I avoid this?
The kind of tool I am looking for would retrieve A.jar and check that all dependencies in A on the new modified B are still fine. Like a potential compilation error that would happen if I were to recompile A and B sources together.
Another solution, as was suggested by many of you, is to set up a local continuous integration system that would recompile the whole project locally. I don't mind doing this, but I want to avoid doing it inside my workspace. On the other hand, if I check-out all sources to another temporary workspace, then I need to mirror my local changes to the temporary workspace.
This is quite a big issue in my team, as builds break very often because somebody forgot to check out (or open in Eclipse) the right set of projects. I tried persuading people to check-out source and recompile the bunch before commits, but not only it takes time, it needs running quite a few commands so most people just find it too troublesome to do. If the technique is not easy or automated, then it's unusable.
If you do not want to use your shared continuous integration server you should set up a local one on your developer machine where you perform the rebuild processes on change.
I know Jenkins - it is easy to setup (just start) on a local machine and I would advice to run it locally if no one is provided in the IT infrastructure that fits your needs.
Checking signatures is unfortunately not enough. Having the correct signatures does not mean it'll work. It's all about contracts and not just signatures. I mean what happens if the new version of a library has the same method signature, but accepts an ArrayList parameter now in reversed order? You will run into issues - sooner or later. I guess you maybe consider implementing tools like Ivy or Maven:
http://ant.apache.org/ivy/
http://maven.apache.org/
Yes it can be pain to implement it but once you have it it will "guard" your versions forever. You should never run into such an issue. But even those build tools are not 100% accurate. The only proper way of dealing with incompatible libraries, I know you won't like my answer, is extensive regression testing. For this you need bunch of testing tools. There are plenty of them out there: from very basic unit testing (JUnit) to database testing (JDBC Proxy) and UI testing frameworks like SWTBot (depends if your app is a web app or thick client).
Please note if your project gets really huge and you have large amount of dependencies you always not using all of the code there. Trying to check all interfaces and all signatures is way too much. Its not necessary to test it all when your code use lets say 30 % of the library code. What you need is to test what you really use. And this can be only done with extensive regression testing.
I have finally found a whole treasure box of answers at this post. Thanks for help, everyone!
The bounty goes to K. Claszen for the quickest and most input.
I'm also think that just setup local Jenkins is a best idea. What tool you use for build? Maybe you can improve you situation with switching to Maven as build tool? In more smart and don't recompile full project if you don't ask it directly. But switch to in can be HUGE paint in the neck - it hardly depends on how you project organized now...
And about VCS- exist Mercurial/SVN bridge - so you can use local Mercurial for you development ....
check this link: https://www.mercurial-scm.org/wiki/WorkingWithSubversion
There is a solution, jarjar, which allows to have different versions of the same library to be included multiple times in the dependency graph.
I use IntelliJ, not Eclipse, so maybe my answer is too IDE-specific. But in IntelliJ, I would simply include the modules from B into A, so that when I make changes to A, it breaks B immediately when compiling in the IDE. Modules can belong to multiple projects, so this is not anything like duplication, it's just adding references in the IDE to modules in other projects.
I'm writing a Java application that needs a lot of static data that is stored in many enum types. Since I would like an user-friendly way to customize this data using for example xml or json files but I'm not allowed to do it directly with enums I was looking for a way to elegantly do it.
Maybe a good solution would be to have a separate java program that reads the xml files and produces the java sources that are then compiled with the remaining part of the sources. My doubs is how to automatize this process in a stand alone way (eg ant?) and how to integrate it seamlessly with eclipse so that it is autOmatically done when I'm working with the project.. Does anything similar to what I'm looking already exists? Any suggestion to solve my problem?
Thanks!
If the items and the overall structure are somehow fixed (and what varies most is the values of the attributes), you could consider defining the enum with one entry for each of your items and let the enum populate its own constants with data read from an external source (XML / JSON) -- at load time or on demand.
Create a project whose sole job is to generate java from your sources.
Make sure that the generation phase is done by Ant.
Now, wrap this project into eclipse and use a custom ant builder, that calls the target in your already existing build.xml.
This is a standard part of our dev infrastructure, so this definitely works.
You can write a maven plugin that generates the code. There are some plugins that do that. It won't work automatically, but you can connect it to the standard maven lifecycle so it gets executed just before compile.
I just did something like that recently.
You can have ant seamlessly integrate with eclipse to achive that:
In Eclipse open project properties, go to "Builders", click "New...", select "Ant Builder", select a build file, go to "Targets" tab and click "Set Targets..." for "Auto Build". Select the desired target and you are done. The target will run every time you save a source file (if "Build Automatically" is selected).
Have you considered including the XML files in your jar, and loading them on startup into maps that use the enum as a key?
I want to run my unit tests automatically when I save my Eclipse project. The project is built automatically whenever I save a file, so I think this should be possible in some way.
How do I do it? Is the only option really to get an ant script and change the project build to use the ant script with targets build and compile?
Update I will try 2 different approaches now:
Running an additional builder for my project that executes the ant target test (I have an ant script anyway)
ct-eclipse, recommended by Thorbjørn
For sure it it unwise to run all tests, because we can have for example 20.000 tests whereas our change could affect only, let's say 50 of them, among which are tests for the class we have changed and tests for classes that collaborate with our class.
There is an unseful plugin called infinitetest http://improvingworks.com/products/infinitest/ which runs only some tests ( related to class we've changed ) just after we save changes. It also integrate quite nicely with editor ( using annotations ) and problem view - displaying not-passing tests like errors.
Right click on your project > Properties > Builders > New, and there add your ant ant builder.
But, in my opinion, it is unwise to run the unit tests on each save.
See if Eclipse has a plugin for Infinitest.
I'd also consider TestNG as an alternative to JUnit. It has a lot of features that might be helpful in partitioning your unit test classes into shorter and longer running groups.
I believe you are looking for http://ct-eclipse.tigris.org/
I've experimented with the concept earlier, and my personal conclusion was that in order for this to be useful you need a lot of tests which take time. Personally I save very frequently so this would happen frequently, and I didn't find it to be an advantage. It might be different for you.
Instead we bit the bullet and set up a "build server" which watches our CVS repository and builds projects as they change. If the compilation fails or the tests fail we are notified quickly so we can remedy it.
It is as always a matter of taste what works for you. This is what I've found.
I would recommend Inifinitest for the described situation. Infinitest is nowadays a GPL v3 licensed product. Eclipse update site: http://infinitest.github.com
Then you must use INFINITEST. INFINITEST helps you to do Continuous Testing.
Whenever you make a change, Infinitest runs tests for you.
It selects tests intelligently, and only runs the ones you need. It reports unit test failures like compiler errors, and provides additional information that helps you write better tests.