I want to debug one of the class from cxf-api-2.7.6 jar file ,downloaded the source file with the help of IntelliJ IDEA,but it does not contain POM file so what are the exact steps to generate the jar file after making changes in the source file.
Any help or suggestion would be greatly appreciated.
Thanks!
You should not modify a library and recompile it. It will be a pain to maintain. You will probably never be able to upgrade your library, and you might break some other behaviors.
If you just need to understand what is happening, you can use intellij debug tools as mentionned by Pim Hazebroek.
If you need to change the behavior of the library, you should :
Check that you are not misusing the library (you could post your usecase on stackoverflow for advice)
Check whether the latest version of cxf addresses your needs.
Use a different library.
Extend your current library (with inheritance for instance)
If however, you really need to modify cxf sources, you could clone https://github.com/apache/cxf, checkout the tag, modify the sources and rebuild.
There is (usually) no need to modify the source and repackage it with the advanced breakpoints in IntelliJ.
Unless you want to drastically modify the behaviour of course... But for simple debugging tasks you can use the "evaluate and log" as demonstrated in String.toUpperCase here:
It even provides code assistence.
Optionally you can uncheck the Suspend checkbox to remove the need to resume it when hit frequently.
Related
I dislike the build tools that exist for Java. So I wrote my own. But there is one feature that it doesn't have yet; auto-import of changes into the IntelliJ project.
I'm having trouble finding information on how to do this. Tutorials on how to write IntelliJ plugins throw tons of useless stuff at me (creating UI for example).
I know this isn't your typical stackoverflow I-have-a-bug question but I'm quite lost and could use a pointer in the right direction.
If you need to know when a certian file was changed and auto-import information from this file you can use VirtualFileManager.addVirtualFileListener().
Or even use fileDocumentManagerListener extension point. Whatever suits your needs more.
So far I've managed to create a simple IntelliJ plugin. The start is fairly simple. IntelliJ has the plugin project skeleton built in. File->new Project is enough there.
From there I've created a class that implements ModuleComponent. The documentation here (https://www.jetbrains.org/intellij/sdk/docs/basics/plugin_structure/plugin_components.html) says it will be loaded whenever a module is opened.
To get it to work I had to add this stuff in the plugin.xml:
<module-components>
<component>
<interface-class>packagename.ClassName</interface-class>
<implementation-class>packagename.ClassName</implementation-class>
</component>
</module-components>
The documentation manages to hide this next step but its possible to give the ModuleComponent a constructor like so:
public ClassName(final Module module) {}
This should give me an instance of the Module class to read values from and to modify the way I need.
As it turns out IntelliJ makes it difficult to figure out how to do things. There is no Javadoc for example. People seem to suggest reading the source code. Weird..
A quick look through the methods of Module didn't really help me much. Google let me know that in order to make changes to the Module I could do the following:
ModuleRootManager.getInstance(module).getModifiableModel()
I can call several methods on this model and finally call .commit() when I'm done to persist the changes. The ModifiableRootModel has two methods that look very promissing:
ModifiableRootModel.addModuleOrderEntry()
ModifiableRootModel.addLibraryEntry()
The first takes a Module instance. I'm hoping that if I add the correct Module this will allow me to well, add modules :). I can think of two situations here. First, the module is already loaded in the project, in which case I will need to find it and add it. And second, the module is not loaded yet so I will need to tell IntelliJ to load it and add it to the project.
The second method takes a Library instance. Just new Library() doesn't work, and google isn't very helpful here. From my buildfile I can extract the groupId:artifactId:version:scope value. So I'll need a way to turn those strings into a Library that works.
This is how far I've gotten so far. Current problems are:
I need to find the already loaded modules so I can find the one I'm linking to
I need a way to add a module to the project if it hasn't been loaded yet
I need a way to turn a maven style dependency into a Library object so I can add it to the module
I need a way to list all the existing modules and libraries so I don't end up adding duplicates
I am currently developing a simple plugin that retrieves results from a Jenkins build. I am extending Notifier and using build.getResults() to get the information. However, when I upload my plugin, I can't set it as a post-build action.
When I run my builds, they break on build.getResults() since I am trying to get the results while the build is still running.
What can I do to properly get the build result ?
Best thing is to look at existing plugins which use Notifier extension point (click to expand implementing plugins list).
Check that you have the Descriptor implemenation (inner) class, as well as config.jelly. Also check jenkins.out and jenkins.err logs for any exceptions (such as malformed config.jelly).
Edit: Actually, Notifier subclass of this plugin looks really simple as Notifiers go: https://wiki.jenkins-ci.org/display/JENKINS/The+Continuous+Integration+Game+plugin , see especially its GamePublisher.java and corresponding config.jelly, and it's GameDescriptor.java, which has been made a full outer class (often descriptor is inner class). Also if you want options into Jenkins' Global configuration, you need a global.jelly, but if you don't have such options, that is something you can just leave out (unlike config.jelly, which you must have for Notifier even if it is empty, like here).
As a general note, it can be really annoying when things do not work, and you do not get any error, your stuff simply is just not displayed by Jenkins... If you just want to get things to work for you, using Groovy build step might be easier, but if you want to get things to work for others, then doing a decent full plugin reduces support requests.
Since this sounds so simple, are you sure you need a plugin ? Take a look at using a Groovy Postbuild step instead; they're much easier to write. There are some good usage examples in the link. If you decide you really need a plugin, see if you can extend an existing one rather than writing your own; it's an easier way to understand the ins and outs of Jenkins plugin writing.
I have a scenario where I have code written against version 1 of a library but I want to ship version 2 of the library instead. The code has shipped and is therefore not changeable. I'm concerned that it might try to access classes or members of the library that existed in v1 but have been removed in v2.
I figured it would be possible to write a tool to do a simple check to see if the code will link against the newer version of the library. I appreciate that the code may still be very broken even if the code links. I am thinking about this from the other side - if the code won't link then I can be sure there is a problem.
As far as I can see, I need to run through the bytecode checking for references, method calls and field accesses to library classes then use reflection to check whether the class/member exists.
I have three-fold question:
(1) Does such a tool exist already?
(2) I have a niggling feeling it is much more complicated that I imagine and that I have missed something major - is that the case?
(3) Do you know of a handy library that would allow me to inspect the bytecode such that I can find the method calls, references etc.?
Thanks!
I think that Clirr - a binary compatibility checker - can help here:
Clirr is a tool that checks Java libraries for binary and source compatibility with older releases. Basically you give it two sets of jar files and Clirr dumps out a list of changes in the public api. The Clirr Ant task can be configured to break the build if it detects incompatible api changes. In a continuous integration process Clirr can automatically prevent accidental introduction of binary or source compatibility problems.
Changing the library in your IDE will result in all possible compile-time errors.
You don't need anything else, unless your code uses another library, which in turn uses the updated library.
Be especially wary of Spring configuration files. Class names are configured as text and don't show up as missing until runtime.
If you have access to the source code, you could just compile source against the new library. If it doesn't compile, you have definitely a problem. If it compiles you may still have a problem if the program uses reflection, some kind of IoC stuff like Spring etc.
If you have unit tests, then you may have a better change catch any linking errors.
If you have only have a .class file of the program, then I don't know any tools that would help besides decomplining class file to source and compiling source again against the new library, but that doesn't sound too healthy.
The checks you mentioned are done by the JVM/Java class loader, see e.g. Linking of Classes and Interfaces.
So "attempting to link" can be simply achieved by trying to run the application. Of course you could hoist the checks to run them yourself on your collection of .class/.jar files. I guess a bunch of 3rd party byte code manipulators like BCEL will also do similar checks for you.
I notice that you mention reflection in the tags. If you load classes/invoke methods through reflection, there's no way to analyse this in general.
Good luck!
I'm working on a couple of web services that use JAXB bindings for the messages (in JAX-WS or spring-ws). When using these bindings there's always some code that is automatically generated from the WSDL to bind the message objects. I'm struggling to figure out the best way I can make this work so that it's easy to work with, hard to break and integrates nicely with IDEs (mostly using eclipse).
I think there are a couple of ways to go about this. The three main options I see right now are:
Generate code, keep the source artifacts and check them into the repository. Pros: integrates easily with IDEs (source highlighting etc), works within the build system. Cons: generated code changes each time you regenerate it, possibly creating noisy commits. It's also redundant since the WSDL file is already checked in, usually.
Generate code as part of the build process. Don't keep source artifacts or only keep them in output directories. Pros: fixes all the cons from the previous one. Cons: harder to integrate with IDE, though maybe this build step can be run automatically? I currently use this on one of my projects but the first time I checkout the project it appears broken, which is a minor nuisance.
Keep generated bindings in separate libraries (jars) included with maven or manually updated jars, depending on your build process. I got the idea from a thread on java.net. This seems more stable and uses explicit versioning but seems a bit heavyweight.
Which one of these options would you implement and how? We're currently using maven and eclipse, so any ideas in that regard would be great. I think this problem generalises to most other build systems and IDE combinations though, even other languages perhaps.
I went for option 3. If you already host your own repository (and optionally CI), it's not that heavyweight. All it takes is a simple POM. It's even possible to include some utility/wrapper/builder classes (that often make life easier with generated classes) and use them in several projects.
I'd go for option 2 and generate code in the "standard" ${project.build.directory}/generated-sources/<toolname> location as part of the build process. Using generated sources is well supported by m2eclipse (use Maven > Update Project Configuration once sources have been generated) and, if I remember well, by the maven eclipse plugin as well (i.e. the folder will be added to the Java Build Path). Actually, I think NetBeans also handle this fine. Not sure for Idea.
For the generation itself, you may need the maven-jaxb2-plugin if I understood correctly.
Is there an IDE/Tool/script/something that can show call hierarchy and/or data flow in Scala+Java programs (preferably from source code).
Or (as a backup plan) is there a tool that can show it using Java bytecode? (And preferably give the option to go to source code, if provided by user).
All that, preferably integrated into an IDE and/or Maven :-)
The requirement to support Scala is crucial in this question. I Already know of and use such tools for Java, in 3 IDEs. They do not work very well (actually: at all) when Scala is involved.
TIA
Poor man's call hierarchy: Comment the method out and see where your red squigglies show up. [/me ducks]
Did you tried Eclipse?
SBT can do that. You'll have to check it out to get more information, because I haven't done it.
EDIT
Sorry, I confused things. SBT can generate component dependencies, not call hierarchy.