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.