I wanted to know from where the values for RIM-COD-Module-Dependencies parameter are populated in Jad file of a Blackberry project ?
Generally this is done by RIM's RAPC tool. You invoke this when you do a build from the JDE or from the Eclipse JDE Plugin. You can also invoke this from the command line, or using something like bb-ant-tools.
RAPC does a bunch of things - compiling .java files to bytecode (using javac), doing preverification (like sun's WTK), doing some obfuscation/packing/optimization on your bytecode (stripping out unused bits of code, etc), and figuring out what dependencies your .cod will have.
Are you having specific problems with the module dependencies?
Related
I have installed Luadist and created a small program (named abcd.lua which also uses IUP GUI). It runs well with command iuplua.exe abcd.lua I want to give it to some other persons to try. Since Lua may not be installed on their computer, I want to give it to them with Luadist folder. I see that there are a large number of files in Luadist folder (1148 to be exact- tried listing them here but it exceeds character count). They are in following folders:
bin : has large number of exe and dll files.
include: has lauxlib.h luaconf.h lua.h lua.hpp lualib.h
lib: has liblua.dll.a and its extracted folder and a lua folder with large number of subfolders and files
share: also has large number of folders and files.
tmp: only empty cache folder currently
Following files contain 'iup' in their names:
./share/luadist-git/dists/iup-3.6
./share/luadist-git/dists/iup-3.6/dist.info
./share/iup
./share/iup/README
./share/iup/COPYRIGHT
./lib/lua/iupluaimglib.dll
./lib/lua/iuplua.dll
./lib/lua/iuplua_mglplot.dll
./lib/lua/iupluacd.dll
./lib/lua/iupluacontrols.dll
./lib/lua/iupluagl.dll
./lib/lua/iuplua_pplot.dll
./lib/lua/iupluatuio.dll
./lib/lua/iupluaim.dll
./bin/libiuptuio.dll
./bin/libiup_pplot.dll
./bin/iuplua.exe
./bin/iupview.exe
./bin/libiup.dll
./bin/libiupgl.dll
./bin/libiupcd.dll
./bin/libiupim.dll
./bin/libiupimglib.dll
./bin/libiup_mglplot.dll
./bin/libiuplua.dll
./bin/libiupcontrols.dll
Will giving only these file alongwith my program file (abcd.lua) be sufficient, though I think many dll files will also be needed?
Which files or folders can I select to give or do I need to give all files for proper running of my program? Thanks for your help.
In the IUP documentation, each library describes its dependencies. You can start there.
But the answer depends on what modules are you using. If the only "require" you do is "iup", then it is quite simple. You will need the executable, the Lua DLL, the IUP DLL and the IUPLUA DLL.
You have a couple of options:
(1) move the executable to a different folder and start your script. It will fails with an error message about a missing DLL; move the DLL to the folder with the executable and repeat. This should give you a list of the dependencies, assuming the execution will follow all code paths that load external modules.
(2) use the dependency walker to find all dependencies that your executable and its DLLs have. The advantage of this method is that you can execute it without moving any files and it will give you a detailed analysis of the dependencies and how they are resolved on your system.
Keep in mind that you don't need to preserve the same structure that LuaDist has for the dynamic libraries; you can put all the DLLs your script needs next to the executable (and this is likely to be the simplest and the most successful configuration).
I have few own APIs with around 2000 classes overall. Some of them use the new Path API from JDK7. Most other classes, however, do not rely on any new JDK APIs or new language features. So most classes could be used in a JDK6 environment (which I plan to do). Let's assume, I've annotated all JDK7-only classes with #Java7Only.
What I need now, is a way to create a JDK6-only subset of all my projects more-or-less automatically, without introducing new version branching or product lines (would be too complicated to maintain).
All projects are created using Netbeans, thus using Ant. Many projects depend on others.
Please help me evaluate, which ideas according to my problem is most appropriate. Which problems could occur with each idea?
Common first step for all ideas
Let an annotation processor search for #Java7Only-annotated classes and store the list to a properties file.
Idea 1 (specific)
Write a tool which would use the properties file to recursively copy the whole project, except JDK7-only files.
Build the copied project using JDK6 by invoking ant, thus getting a JDK6-compliant jar.
Idea 2 (specific)
Write a second annotation processor which would use the properties file to pass everything except JDK7-only files to a JavaCompiler instance.
Either build a jar using Java APIs or use Ant API for that.
(This would be a Java-only idea, but probably too complicated)
Idea X (abstract)
Somehow influence the Ant build process (by overwriting some targets?) and for each JDK6-compliant class: let Ant compile two versions of it (one time with JDK6 compiler, another time with JDK7 compiler).
(JDK7-only classes would be compiled only once, using the JDK7 compiler, of course)
Package each bunch to a separate jar.
Possible common problems to the ideas
Some projects dependent on others, so some actions (such as packaging) should consider this.
Remember: the JDK7 compiler generates downward incompatible class files, that's why every possible idea has to happen on sources-level (before or during the build process, not afterwards).
My thoughts on Idea 2:
Essentially this is invoking a compiler within a compiler. Annotation processors are run as part of compilation. Can this be done safely? Is there any static state in Sun's javac that would cause problems. (I don't know the answer but from memory there might be some static state that could cause problems in this scenario).
Idea 1 seems simpler and better to me.
But taking a step back, is it possible to separate out all the JDK 7 specific stuff into a separate module and compile it separately, into a different JAR?
Have the 'main' project, compiled using JDK 6 (which JDK 7 would have no problems reading because it is backwards compatible)
The JDK 7 specific module(s), with source in a different directory, which includes the 'main' JAR on the compilation classpath, could be built separately, with a different build.xml if necessary.
This only partially applies but I'd thought I'd mention it anyway.
The problem with just using -source 1.6 -target 1.6 options for validation is that you can still use Java 7 API when compiled using JDK 7.
I've used the Animal Sniffer Maven Plugin for a few projects now and it has proved quite useful. This plugin scans byte-code of your classes for JDK API usage. That is, you can tell it to fail the build if you attempt to use JDK 7 API when you are targeting JDK 6. This wont help much for separating out classes as you need but it could be useful as a final validation step combined with -source 1.6 -target 1.6 compiler options.
There is also an animal sniffer Ant plugin, as mentioned from the Animal Sniffer main page.
Can EclEmma eclipse plugin be used for code coverage with obfuscated (with Proguard) jar file?
Thanks.
I don't think that this makes sense, because the source files would have to be obfuscated too, to generate an appropriate report.
A report is always generated using the source files of the project and these must match the class files exactly.
I don't think that you want to look at a coverage report of obfuscated code.
Hi I have source code that ant builds into a javaSE jar, and we ship that, ant also at the same time builds the source for a JavaME project.
which I currently then open netbeans and let it compile the jars for JavaME, i'd like to do this last bit in ant and wondered if its possible and if so how?
Sure, but you'll have to add tasks for pre-verification etc.
Have a look at
Antenna An Ant-to-End Solution For Wireless Java
User's Guide for J2ME Ant Tasks
From the webpage of Antenna:
Antenna provides a set of Ant tasks suitable for developing wireless Java applications targeted at the Mobile Information Device Profile (MIDP). With Antenna, you can compile, preverify, package, obfuscate, and run your MIDP applications (aka MIDlets), manipulate Java Application Descriptor (JAD) files, as well as convert JAR files to PRC files designed to run on the MIDP for PalmOS implementations from Sun and IBM.
I am using JDom jar and I want to add to my blackberry project. I am using eclipse plugins for blacberry. while building blackberry app from eclipse the error is displayed on the console as
"JDOMAbout$info:error!missing stack map #label.... "
rapc falied for the project along with this several warnings are also displayed ...so any body have came across this ?
The stack map is part of what's generated when a jar file is preverified. Sounds like your jar is not J2ME ready. Assuming it's compatible with J2ME, the standard way is to create a .cod file from the .jar, and reference that in your project. Unfortunately you can't do that with the Eclipse plugin, but once you have the .cod, you can reference it in your Eclipse project.
You have to create a Blackberry archive or library project (or whatever it's called) and add your library to that, then reference it from your application project. You may or may not have to use the Blackberry JDE to do some hackery with the jdp file as well, but I can assure it works in Eclipse. We had the kSOAP library included in ours and Eclipse would 'build' it with rapc and generate the proper files (you sort of have to do it manually, by telling the project to build).
I unfortunately don't have an environment to check things right now, but the basic idea was have a second project, include the jar, and then reference that.
All that, and the jar has to be J2ME compatible.
Maybe You can find something useful and more J2ME friendly in kDom package of kXML project
Tutorial: How To Use 3rd Party Libraries in your Applications