Would you be more specific what you want?
I would welcome very detailed proposal sent to nbdev@netbeans.org.

Actually (without proposal) I'm not sure the issue belongs to nbbuild.
Changing to P4 ENHANCEMENT unless after the detailed proposal.

Ruda, the topic has already been discussed on nbdev, and this is
definitely not intended to be assigned to release engineers, so don't
worry about it.

I will take care of this one.

To Jesse: InstalledFileLocator is cool but I am afraid it 
will not be enough. It will be enough in case that the NB 
is started with all permissions (especially with file 
permission and classloader permissions) and the bootstrap 
code will create an installation directory on the users 
machine. But there might be a requirement that the whole 
NB installation is hidden and 
javax.jnlp.PersistenceService is used to store local user 
data. But the PersistenceService does not use the 
java.io.File class but rather provides you with an input 
stream.

As a starting point I will try to come up with some 
bootstrap code started by JWS and still using 
java.io.File. And after this is finished I will try to 
come investigate the PersistenceService. Pleas dont expect 
the result of this immediatelly but as a rough estimate 
give me couple weeks (for the fist phase).

And if there is anyone eager to work on this issue please 
tell me not to duplicate our efforts.

I was thinking perhaps that given an NBM file with some install paths
in it, the conversion to JNLP would produce a mapping that takes
install path and points it to either (1) the name of a class or
resource in that JAR, if the file is a JAR and that class or resource
is unique across all JARs in the installation; or (2) an autogenerated
resource name, where the contents of the file from the installation
are packed into the module JAR under a new unique name.

The IFL operating under JNLP would then consider the cases:

1. Try to look up the known resource path characteristic of the JAR.
If it can be found, and is a jar: protocol URL, then the JAR was
carried over to the user's machine intact; find it and return it.

2. Otherwise we are dealing with some other kind of file not in JAR
format. Copy the resource stream for it to a temp file
(File.makeTempFile, File.deleteOnExit) and return that. Can reuse the
temp file if requested again.

Note that IFL can also point to installed directories full of files,
making #2 a little more complicated.

I'm not too familiar with JNLP yet, so treat these as possible ideas
only. I am assuming that at least the JAR files in the app will
normally be downloaded, saved to disk in some cache area, and put in
the classpath when starting, and that all resources must be accessed
via the classpath. This constrains how the app can behave, but IFL can
handle all the details of recreating File's corresponding to pieces of
the original installation.

Re. user data - IFL is not intended for user data, it is only for
files produced as part of the installation (i.e. from NBMs). For the
userdir, I would suggest that system/ be stored as an XML filesystem
encoded in UTF-8 and sent to the persistence service. Sometimes a
module asks FileUtil.toFile for something in the SFS and expects to
get it; this should probably be fixed in the module, but you could
also have a special subclassed filesystem that writes out some temp
files corresponding to a SFS file object on demand.

Some modules may attempt to do other stuff in the userdir (using
${netbeans.user} directly), but too bad; they are not compliant with
the Open APIs and now they will pay. :-)

Sorry for not being clear: I thought of the whole NB installation
being "user data" from the JWS perspective. I did not think about
using JWS for getting the files there - I would run only bootstrap
using JWS (which can create the NB install dirs) and then using either
normal files or better (and harder) use PersistenceService to
store/retrieve content of the NB install dir. For the SFS I consider
using memory filesystem and then flush it to some server - I don't
have details about this yet.

Well, it would seem to make sense to use JNLP "properly" to retrieve
the installation files; it would then properly manage caching and so
on, as well as incremental download of new versions of modules -
otherwise you would have to implement all that sort of thing manually,
which doesn't sound like an improvement.

Not entirely manually - autoupdate could work. But if you think that
using JWS by putting nb jars inside jnlp jars (which are on classpath)
and getting the nb jars as resources I will also give it a try. Let us
see which approach will work better. Do I understand it right that you
mean to use the conntent of nbm files as the contents for JWS/JNLP jars?

"But if you think that using JWS by putting nb jars inside jnlp jars
(which are on classpath) and getting the nb jars as resources" - no;
NB JARs would be directly JNLP JARs and thus on the classpath (no
support for >1 version of a single lib - probably OK since the JNLP
publisher controls the whole installation); only non-JAR resources
would be packed inside module JARs so they could be extracted to disk
when requested from IFL.

"Do I understand it right that you mean to use the conntent of nbm
files as the contents for JWS/JNLP jars?" - no, not exactly.

E.g. I would expect that openide.jar or java.jar or ant-1.4.1.jar
would be regular libs as far as JNLP is concerned, i.e. <jar> elements
in the .jnlp file. (Lazy downloading is probably impossible due to all
the reflection, but oh well.) There would be a single class loader for
all modules. (See
org.netbeans.core.modules.ModuleManager.createFixed.) Besides being in
the spirit of JNLP, it permits incremental JAR downloads which is
necessary for good upgrade performance.

Only non-JAR resources, e.g. system/ParserDB/* or docs/*.zip etc.,
would be bundled up in the module JARs and unpacked on demand.

"(no support for >1 version of a single lib - probably OK since the
JNLP publisher controls the whole installation)". I am not sure - what
if there are two modules depending on two separate versions of the
same library?

Also would disabling a module work in this scenario? And what about
adding new modules while the app is running?

"what if there are two modules depending on two separate versions of
the same library?" - it wouldn't work; don't do that. As publisher you
control the distribution so you can easily ensure that this does not
happen.

"Also would disabling a module work in this scenario? And what about
adding new modules while the app is running?" - No and no. Seems
contrary to the idea of WebStart to me anyway. You should just click
on a link and get a running app with a sensible configuration, just as
in normal applications. If the website admin gets requests to make a
different module config available, he/she can do so. The
configurability is server-managed.

Imagine following use case: the user starts the application from a web
page. The application brings a login dialog. According to the login
information certain modules are enabled while others disabled. If the
user is granted more rights (like by supplying something like super
user password) some relevant modules get enabled.

The advantage of having the modules installed and enable/disable them
as needed might be important since after the login no additional code
is donwloaded - the modules are already there. I am not sure how would
this work with pure JWS - maybe the user would log in using some web
page and after successfull login there would be several apps ready to
start that would share some of the jar files. Not sure how would this
work.

BTW if you sort of cripple the module system while using JWS/JNLP
quite logical question can arise: do we still need netbeans as a
platform? After you make fixed the content that is part of a distro of
such app you almost no longer need the dynamic nature of menu, toolbar
configuration. What remains is the window system and couple of utility
classes. This approach leads you to one monolitic app not partitioned
to the modules.

Re. enabling modules conditionally: you can choose not to enable some
modules which happen to be available on the classpath. You can just
enable some of them. However modules from the classpath, once enabled,
cannot be disabled in the same session (using the current module
system). Presumably this would not matter.

Or the user could login via the web page (servlets etc.) and the web
app controlling login would serve that user the correct set of modules
by sending the user the correct JNLP file (either generated on the fly
or selected from a fixed list).

Re. "crippling" of the module system - I don't think that runtime
enablement/disablement of modules is a critical feature of the NB
platform! It is nice in some circumstances, unwanted in others.
Certainly the usefulness of partitioning an application into
independent modules is not drastically reduced by not permitting them
to be turned on or off at runtime. You still have configurability at
deployment time, as well as code modularity. The Eclipse platform
never supported runtime status changes for plug-ins, for example.

Also a minor point: menu and toolbar configurability is independent of
dynamic module status changes. You can keep the list of modules fixed
at runtime and still permit runtime changes to menus and toolbars. You
can also permit user customizations to menus and toolbars to be
respected even after restarting with a different module configuration.

I believe that this issue was solved by Jarda in the trunk/5.0.

What remains are my classloaders that are in

installer/jnlp/modules. Thanks to the core changes this module can be used
independently on the rest of the JNLP support for the platform. If ever I would
like some more prominent place for the module I will create a separate issue.
But for now I think the module can stay where it is now.

I am closing this issue as invalid since the request is now obsolete - we
already have the support in the platform.

This issue had *1 votes* before move to platform component