Alex,
I am still using Netbeans 8, but I patched the Netbeans platform to allow the
RCP application to intercept and modify the installed module list before it is
displayed. For my application, different versions go to different customers
with certain modules disabled, and this patch allows the different customers to
only see the modules we want them to see in the update center. This may be
what you are looking for.
I have included a couple of pictures demonstrating the patch, a text file
describing the patch that I made to the platform (taken from a post I made to
the old NetBeans forums a number of years ago), and a text file describing how
to patch the platform (taken from the old NetBeans Developers FAQ).
There may be better ways to do this in the newer versions of Netbeans. And I
don’t know if this approach can still be used with newer NetBeans versions.
Thank You!
Joe Huber
Standard Refrigeration LLC
=====
From: Alexander Faust <afaust.germ...@gmail.com>
Sent: Monday, January 3, 2022 9:00 AM
To: users@netbeans.apache.org
Subject: Hide Netbeans internal modules in "update center"
Hello,
it is possible to hide some internal Netbeans modules in the "update center" of
the own RCP application. I want to show only modules of my own cluster / RCP.
The most modules are hided by default, but some modules e.g. "JavaScript 2
Editor" defines the attribute "AutoUpdate-Show-In-Client: true" in the module
MANIFEST.MF. This leads to it being displayed. Is it possible to overwrite the
attribute of the MANIFEST.MF file in the corresponding module, e.g. by using
-J-D switches / parameter with specifying the code name base of the module? Or
is there another mechanism to solve my problem?
Thanks in advance
Best regards
Alex
In case anyone is interested, I finally got back to this issue after being
shuffled around between projects and came up with a solution.
This involves patching the Auto Update UI platform module. I'm working with NB
platform 8.0.2.
In org.netbeans.modules.autoupdate.ui.api, which is a public package, I added a
new class UpdateUnitListModifier, which very simply is
Code:
[...]
package org.netbeans.modules.autoupdate.ui.api;
import java.util.List;
import org.netbeans.api.autoupdate.UpdateUnit;
/** <code>UpdateUnitListModifier</code> modifies a list of {@link
org.netbeans.api.autoupdate.UpdateUnit} items.
* After {@link org.netbeans.modules.autoupdate.ui.PluginManagerUI} creates the
list,
* it looks for providers of this service registered in the global lookup, and
calls them to modify the list.
*
* @author jhuber
*/
public interface UpdateUnitListModifier {
public List<UpdateUnit> modifyList(List<UpdateUnit> uList);
}
Then, in org.netbeans.modules.autoupdate.ui, I modified PuginManagerUI.java by
adding code noted below to initialize() after line 251:
Code:
[...]
private void initialize () {
try {
final List<UpdateUnit> uu =
UpdateManager.getDefault().getUpdateUnits(Utilities.getUnitTypes());
// List<UnitCategory> precompute1 = Utilities.makeUpdateCategories
(uu, false);
if (localTable != null) {
final List<UpdateUnit> nbms =
new
ArrayList<UpdateUnit>(((LocallyDownloadedTableModel)localTable.getModel()).getLocalDownloadSupport().getUpdateUnits());
List<UnitCategory> precompute2 =
Utilities.makeUpdateCategories(nbms, true);
}
//new code
Collection<?> col1 =
Lookup.getDefault().lookupAll(UpdateUnitListModifier.class);
if (!col1.isEmpty()) {
for (Object k1 : col1) {
((UpdateUnitListModifier)k1).modifyList(uu);
}
}
//end new code
// postpone later
refreshUnitsInBackground(uu);
[...]
Finally in my application, I have an UpdateUnitListModifier service provider to
manipulate the UpdateUnit list.
Code:
[...]
@ServiceProvider(service=UpdateUnitListModifier.class)
public class UpdateModifier implements UpdateUnitListModifier {
@Override
public List<UpdateUnit> modifyList(List<UpdateUnit> uList) {
Iterator<UpdateUnit> it1 = uList.iterator();
while (it1.hasNext()) {
UpdateUnit u1 = it1.next();
String s1 = "com.dont.show.this.in.update.tab";
if ((u1.getInstalled() == null) &&
u1.getCodeName().contentEquals(s1)) {
System.out.println ("This module should be removed from the
list: " + u1.getCodeName());
it1.remove();
}
}
return uList;
}
}
When one selects Tools>Plugins, PluginManagerUI goes about figuring out what is
installed, what needs to be updated, and creates an UpdateUnit list with these
items. Per the above modification, after this list is created and before the
default Plugins window is displayed, PluginManagerUI now looks for service
providers to modify this list. The service provider(s) can go through the list
and remove items from (or add items to) the list. PluginManagerUI then goes on
to process the list normally and display it in the various tabs of the Plugins
window.
I've done some limited testing, but it seems to work as planned. My next
challenge is to figure out how to distribute the modified Auto Update UI
platform module through my app's update center. Not much out there about how to
do that.
http://wiki.netbeans.org/DevFaqOrphanedNetBeansOrgModules
1) Copy the entire netbeans folder to a new location. This will be the
platform that will be patched, and the platform that your application will use
and ship.
2) Follow the steps below to set up the source code. Get the source for the
modules you want to patch.
DevFaqOrphanedNetBeansOrgModules
Can I work on just one or two modules from the NetBeans source base by
themselves?
Introduction
Normally to work on modules versioned in the NetBeans main Mercurial repository
you need to clone the entire repository. (For modules in contrib, you need
contrib cloned as a subdirectory of main.) For people interested in just
playing with patches to one or two modules this can be onerous, however. As an
alternative, you can work on "orphan" modules from the netbeans.org source base
(Issue 143236 has details). There are two issues to consider:
Mercurial currently does not let you clone or check out just a subdirectory of
a repository, so you will need to get module sources some other way (we are
still considering some possibilities).
Since "upstream" modules (that the module of interest depends on) are not
available in source form, you need to have a recent development build of
NetBeans available to compile against.
Quick usage guide
1. Create an nb_all dir wherever you like. It must have at least the nbbuild
dir from the netbeans.org source tree.
2. Create nbbuild/user.build.properties and in it set the property
netbeans.dest.dir to the full path to a NetBeans IDE installation you would
like to both compile against and build into (you should not use your real
development IDE, rather a copy).
3. Run: ant -f nbbuild/build.xml bootstrap
4. Add subdirs for any netbeans.org module projects you would like to work on.
(The modules may be already present in the target platform. If they are not,
you need to check out sources for any transitive dependencies not in the target
platform too.)
5. Using the IDE, open the desired projects and work normally.
What works
Source projects should open without error and without displaying error badges,
assuming all dependencies are available in either source or binary form.
You can build the projects normally. The modules will be built into the target
platform (overwriting any existing copy of the module).
You can use Run and Debug to start the target platform with a test userdir
after building the modules, set breakpoints etc.
You can Test the source projects normally.
Code completion should work against APIs present in other modules. If those
modules are available in source form, you will get popup Javadoc automatically,
and can navigate to sources. If not, you can still add popup Javadoc capability
for all published APIs:
1. Download "NetBeans API Documentation" from AU.
2. Open NetBeans Platform Manager.
3. Select the "default" platform and note the location of NetBeansAPIDocs.zip
in the Javadoc tab.
4. Create a new platform; select the same dir as you specified for
netbeans.dest.dir.
5. In the new platform, add NetBeansAPIDocs.zip to the Javadoc tab.
Caveats
If you want to work on unit or functional tests, you need to have all
test-to-test dependencies available as source projects, because we do not
distribute test libraries. Sometimes the transitive dependency tree can get a
bit big. For example, if the functional tests use
org.netbeans.junit.ide.ProjectSupport, then you need to check out
java.j2seproject (in whose unit test dir this class resides), then its
dependencies in turn: projectapi, projectui, openide.filesystems, and
openide.util. Test-to-module dependencies (e.g. nbjunit, jellytools, ...) can
however be satisfied from the target platform's binaries.
If you add new source modules to the tree, you will need to both restart
NetBeans and delete the nbbuild/nbproject/private/ dir in order to reset all
caches and ensure that the new sources are recognized.
Various targets in nbbuild/build.xml not used in the above scenarios may or may
not work usefully, though this should not affect routine module development.
The target platform needs to be new enough to support any API calls you are
making from source modules into binary modules. If the platform is older, you
could see error badges. Besides getting a newer platform, this can be corrected
by adding sources of the new version of the API module to the tree.
Note that the bootstrap ant target will not work if you just copy nbbuild from
the netbeans.org source tree into nb_all. Other than nbbuild you also need to
copy directories:
ide/launcher
javahelp
apisupport.harness
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
