This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
From http://wiki.netbeans.org/JavaCardTODOs : JavaCard2 is a split VM. The class files are converted into CAP, which is kind of Execution In Place format. There will be no more linking required for a CAp file. Each method and filed is replaced by some Token numbers, which are fixed. For example Applet.process(0 method may have Token numbers for package, class and method 10, 20, 30 respectively and it cannot be changed. The export file contains this information for each class. Think it as symbol table. Each package must have an export file. for example javacard.framework will have an export file called frameword.exp. The .exp file must be placed under the package tree in a subfolder called javacard. For example framework.exp file should be under javacard/framword/javacard folder. The export path is wherever the javacard folder is starting. almost same as classpath, except that it has it's own package hierarchy. If there is a sub package javacard.framework.services, then there will be an export file javacard/frameword/services/javacard/services.exp. The last token of the package name is used as the file name with extension .exp.
Looks like I still need some details on exactly when an export file is needed.
When we are adding a non-project jar file to a classic applet (or) classic lib projects, ask for .exp file.
Tim I am updating the packager task. Expected to have a property with the name export.path in the properties file. Note:-------------- This is like classpath. Ask for the directory which contains .exp file according to the package structure. Just like a classes folder. This is not the .exp file itself. Ex: .exp file for a.b.c.MyClasses*.class files will be a/b/c/javacard/c.exp Note that the exp file name is the last component of the package. The file itself will be kept under the package hierarchy with additional "javacard" folder. The export path should be pointing to the folder which contains folder 'a'
> Expected to have a property with the name export.path in the properties file. And this is where export files are to be generated to for the project, or where you want to read them from? With the new project metadata, what you will get is, e.g. dependencies.somelibrary.exportpath=path/to/exp/hierarchy/root - I guess a directory is what you need for a library? for libraries; but here it sounds like we are talking about where the packager should generate this stuff to when building a project - if you need that (if so, is it ever going to change or can it just be hard-coded?), it should be tracked as a separate issue - this issue is specifically about how the export path is provided. Do you need that? Now I'm definitely not clear about how to deal with .exp files in a library - so there is 1 .exp file per class, not 1 per library? If the user is adding a Classic Library JAR file, is this info not embedded in the JAR file? How would somebody *distributing* a Classic Library JAR file typically provide this to users of that library - a zip file or something?
> Expected to have a property with the name export.path in the properties file. >>>>And this is where export files are to be generated to for the project, or where you want to read them from? ANKI::: I am hoping this property contains all export files path for this project dependencies. >>>>With the new project metadata, what you will get is, e.g. >>>>dependencies.somelibrary.exportpath=path/to/exp/hierarchy/root - I guess a directory is what you need for a library? Anki::: Yes it is the directory that is required. If there are multiple libraries, how can the build script gets one variable? Or how to populate all these properties? Is there is a single property like export.path, then it would be easy for me to write the ant task. If not I can write ant task to populate dependencies.*.exportpath properties and proceed. Whatever is easy. I can do this in ant tasks, and no problem. >>>>for libraries; but here it sounds like we are talking about where the packager should generate this stuff to when >>>>building a project - if you need that (if so, is it ever going to change or can it just be hard-coded?), it should be >>>>tracked as a separate issue - this issue is specifically about how the export path is provided. Do you need that? >>>>Now I'm definitely not clear about how to deal with .exp files in a library - so there is 1 .exp file per class, not 1 per library? ANKI:::: one .exp per package. (FYI: Technically on library will have only one package only. This is restriction for classic projects. We have this in the list but low priority.) >>>>If the user is adding a Classic Library JAR file, is this info not embedded in the JAR file? ANKI:::: NO, it always be two separate things .exp .jar. And in reality the .jar file will have compile-only classes without any implementation. >>>> How would >>>>somebody *distributing* a Classic Library JAR file typically provide this to users of that library - a zip file or >>>>something? ANKI:::: they provide .jar and .exp files either in a zip file or individual files. Try this link http://www.3gpp.org/ftp/Specs/latest/Rel-5/43_series/43019-560.zip to get an idea about how the SIM API is distributed.
> If there are multiple libraries, how can the build script gets one variable? Or how to populate all these properties? The project.xml contains descriptions of the libraries, <dependencies> <dependency kind="JAR_WITH_EXP_FILE" id="jar1" deployment="DEPLOY_TO_CARD"/> </dependencies> The ID is used for properties related to that dependencies in build.properties, e.g. dependency.jar1.origin=../../Foo/foo.jar dependency.jar1.expfile=../../Foo/foo.exp The build-impl.xsl is generated from the project.xml, and updated when the dependencies change. So the deployment (build, etc.) code for each target will be generated into the build-impl.xml. It will differ based on the deployment strategy and the dependency kind. So, for the deployment target, we will generate deployment code inside the deployment Ant target that serially deploys each thing that needs deploying - i.e. there will be an xsl:foreach inside the XSL for every target where we need to reference dependencies. Store the value of the dependencies ID (i.e. "jar1") in an XSL variable, and generate the correct code depending on the dep kind and deployment strategy - so the deployment code, whatever it is, runs serially, once for each thing that needs to be deployed; the property name for that dependency's exp file property will be hard-coded into the build-impl.xml when it is (re)generated. No need for one property with all available exp files on it (although the XSL could concatenate and create one if it were really needed). >> per library? > ANKI:::: one .exp per package. Okay, this is getting even more confusing. Let me try to detangle this: Are the following statements correct: There are two things that have exp files: Classic* projects and JARs which represent an API built into a card. A classic project may only contain one package. Exp files are one per package. Therefore, a classic library will only have one exp file. HOWEVER, a JAR which represents an API built into a card may contain more than one package. So, what we are setting is an "exp file root" which will contain a package tree of exp files matching the Java class tree, correct? And this option is required for - JAR files with EXP files - Classic Libraries correct? > Try this link http://www.3gpp.org/ftp/Specs/latest/Rel-5/43_series/43019-560.zip to get an idea about how the SIM API is distributed. Pretty weird - there is no jar file, but there is a zip file with .java files with corresponding .class files beside them, but since the package root is not the root of the zip file, this would be unusable as a dependency. Do we want to support both JARs and directories as dependency roots? This is probably an area where we should encourage some sort of best practice - the way this is now, the user would have to unzip Annex_A_java, set a directory dependency to the directory it unzips to (.\Annex_A_java) (we do not currently have "directory dependencies", but we could add another dependency type DIRECTORY and let the IDE detect it in the wizard based on whether the user chooses a JAR or a directory in the wizard). It would make more sense to distribute JAR file + Source zip. However, if this sort of thing is the way things are distributed in the wild, we should probably find a way to support that.
With main/ 48442a044a29 the text is corrected, and the wizard will now accept directories or zip/jar files for the export path for an added library. Currently there is no validation that the exp file structure is correct or even that they exist at all (will probably add at least some minimal check). Now, the question is: What will our tools actually accept? As I mentioned earlier, this is something where we probably should come up with some sort of best-practice and encourage it (and manually unpacking a zip file of .exp files somewhere on disk and pointing NetBeans at it is way too many steps). So, what do we actually want to do here? And, what will packager actually accept as a valid value? And will packager fail the build if what it receives makes no sense?
Packager accepts root directories of export files separated by system-dependent path separator. I.e. if a classic applet depends on two libraries: pack1.lib1 pack2.lib2 and export files of these libraries are located in path1/export/pack1/lib1/javacard/lib1.exp and path2/api_export_files/pack2/lib2/javacard/lib2 correspondingly, then exportpath argument should be: --exportpath path1/export;path2/api_export_files If export files are needed for classic applet and they aren't provided or incorrect locations are provided then packager fails and ant's packager task also fail. I've added processing of dependency.${libname}.expfile properties to Packager's task. So it should be enough to set export file for each dependency. "export.path" property is still used, so export file locations from both properties will be used.
So, no support for exp files in a JAR or zip? I'm wondering if we should support this from the Ant task - if an export path element is a jar/zip, just unzip it to a temporary dir (do something like munge System.currentTimeMillis() into the new directory name to avoid things clobbering each other). Making people unpack zips of things onto their disks and point the IDE at them is really stone-age, and also not good for anybody storing their code in version control, which you probably don't want to fill with a lot of small binary files. Doing that would at least offer a sane best-practice to vendors who need to deliver JARs + exp files. Possible?
Integrated into 'main-golden', will be available in build *201003200200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/48442a044a29 User: tboudreau@netbeans.org Log: #170653 - export path support should accept directories or zip files; fixed misplaced . in dependency.DEP_ID.expfile property name generation; fixed scrolling and dialog-size issues with descriptions by eliminating use of swing HTML support
Fixed for 6.9