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.
The registration of archive builder and properties are done like this: JarCreator.addBuilder(<my builder>.getInstance()); JarCreator.addExtendedProperty(new <my property>); JarOption.singleton().addOption(<my option node>.getInstance()); These should be moved to xml layers but I suspect the jar packager code needs to implement the framework for that first.
for the options it should be fairly easy (ContextOption is said to be deprecated anyway and JarOption.singleton() is not nice either.) However the issue here is backward compatibility. I've checked the Enterprise edition and noone seems to be adding an option under the jar node. Rochelle, do you add some options there? I didn't fully understand what the JarCreator stuff is doing. Can you give an example, please? Thanks.
Milos, we do add an option, but if you require a change which is not backwards compatible, as long as there is a clear/easy mechanism to change the module code, it is okay for us. As far as the JarCreator stuff, I'm not entirely sure, but please see section 2.2.2 at <http://jarpackager.netbeans.org/jarpackdesign.html>
well, I think we can have a backward compatible stage, when old way of adding options will still work along with the new way (*fingers crossed*) I think the way to go is to move the registration to the layer definition..
ok, I have the code for the settings alomost done. (still figuring out if I can make it fully backward compatible) The sub-options will be declared in layer.xml in folder Services/Hidden/JarPackager.. any such options will be treated as subnodes of the main JarOption node.. I'll address the Builders and Extended properties in the same way. As I figured it out both these should be added only at module startup and removed during module uninstallation, right?
Yes, the builds and extended properties are only at module restored/uninstall time.
The registration of archive builder and properties are done like this: JarCreator.addBuilder(<my builder>.getInstance()); JarCreator.addExtendedProperty(new <my property>); JarOption.singleton().addOption(<my option node>.getInstance()); It will be moved to declarative layer definition, you should remove the add/remove methods from your module install classes. for Builders: <folder name="JarPackager"> <folder name="Builders"> <file name="org-netbeans-modules-jarpackager-TestBuilder.instance"> <attr name="instanceOf" stringvalue="org.netbeans.modules.jarpackager.api.ArchiveBuilder"/> </file> </folder> </folder> For extended properties: <folder name="JarPackager"> <folder name="ExtendedProperties"> <file name="org-netbeans-modules-jarpackager-TestFactory.instance"> <attr name="instanceOf" stringvalue="org.netbeans.modules.jarpackager.api.ExtendedPropertyFactory"/> </file> </folder> </folder> both these should be fully backward compatible and your old code will work without problems. for settings the JarOption.singleton() method is deprecated (JarOption still remains to be ContextOption however once the ContextOption class gets deprecated, it will change it's superclass as well) and the registration of options is done on layer this way: Put your setting in the folder Services/Hidden/JarPackager: <folder name="Services"> <folder name = "Hidden"> <folder name="JarPackager"> <file name="jarpackager-settings.settings" url="jarpackager-settings.settings"> <attr name="SystemFileSystem.localizingBundle" stringvalue="org.netbeans.modules.jarpackager.options.Bundle"/> <attr name="SystemFileSystem.icon" urlvalue="nbres:/org/netbeans/modules/jarpackager/resources/jar_recipe.gif"/> </file> </folder> </folder> This change is not fully backward compatible, diong it the old way will result in you settings to be missing in Tools/Options dialog..
integrated into main trunk.
I assume this is done in the trunk. Can you add a section or a link to this issue in the 3.3->3.4 migration guide?
This is in the upgrade guide.
I'm trying to verify this and have some comments: 1) I found that my builder and property factory classes were previously package private and I needed to change them to be public. 2) The examples below are not detailed in terms of <my builder>, <my property>, and <my option node>. As it is I was slightly confused and had to rely on my past knowledge of layer editing. I added a .settings property and entries to the bundle for the Services/Hidden - not sure if I had to do that. 3) You should specify which version of jarpackager module I need to declare. I guessed and changed from 1.6.x to 1.10. Does this change require a new IDE-Dependencies version? Any package/api dependencies?
Sorry Rochelle, I came to jarpackager well after this change was made so I don't know much about it - nothing more than written here. I'm sorry, I cannot tell you wether all the changes you made were necessary. Nevertheless, I'll try to help you as much as I can and investigate everything necessary. Do you have any problems with the fix now?
I am not actively using a build with this fix yet, so I can't tell if I have problems with it. However, I think it's valuable to ask Milos the answers to my questions and use them to update the entry in the upgrade guide on this topic.
re 1. I assume that is the result of layer definition. Maybe you could keep them package private if you define a factory method to create them?? re 2. I don't quite follow you, but I assume you did just well in the end, right? re 3. No idea, it's 6+ month back. I can't recall what I did last week :)
For 1) This was just a comment and suggestion that might be needed for the upgrade guide entry. For 2) I figured something out, but I'm not sure if it's correct. Again, I am pointing out where the upgrade guide should be improved. For 3) This information should be found and added to the upgrade guide.
Please investigate issues 1-3 and improve the upgrade guide entry accordingly.
not working on jarpackager for more than a year, reassigning.
Now irrelevant.