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 reglib module contains utilities which allow a module to register with the registration relay service. This is very useful functionality. The reglib is currently in the nb cluster. I have a module in ide (glassfish.common) that would benefit from being able to use it. Since reglib does not have any dependencies, this should be easy to switch...
pcw noticed that the build order for the ide cluster and the nb cluster switches from distribution to distribution.... in the web and javaee dist... the order is ide then nb in the jruby dist... the order is nb then ide So unifying the order to nb then ide may resolve the build ordering, too.
Changing the build order won't work because nb.cluster.nb depends on nb.cluster.ide The 'reglib' module can be moved to the ide cluster as Vince suggested in the first comment.
Currently reglib is used by registration module, installer and some cnd module as they use some registration. Another registration effort should be coordinated. CCing Jan. We have now friend not public API to be able to change it more freely according to client needs.
Jarda is it ok to move reglib from nb cluster to ide cluster?
BTW how does it fit into whole 'registration'? GF can either register itself through its own UI or it can delegate to NB IDE if installed by our bundle installer. For which scenario is your registration described in #149148 targeted? For second case installer creates necessary registration data (including GF service tag) and then user can register all products either invoking browser from installer or any time later using Help -> Register from IDE menu. So for this scenario is seems duplicate. For first case IDE does not know about GF registration so GF should register itself. Again in this case registering GF through Services tab could result in duplicate registrations.
IMO, the reglib does not belong to the ide cluster. It's specific to NetBeans as a branded product. I agree with Marek's last point and also do not understand the scenario this proposal is trying to solve. GF is eiter installed independently of NetBeans and in that case it cannot rely on any of the NB clusters. Or, it's installed in a bundle with NetBeans and then the registration is handled through the *common* NB + GF registration process.
mslama: A Register item on the server node in the Services explorer will make it easier to register a server that has not been bundled with the IDE, but added to the Servers list manually. There are multiple ways to Register a GF installation currently: 1. when the server is installed, or 2. through the admin console. If the user has already installed the server and added that server to the IDE, the chance for the user to choose method one has passed... Registering the server via the admin console is still possible, but is hard to see from inside the IDE. We want it to be easy for a user to register their server. jchalupa: it is clear to me that registration is an 'nb thing'... I am trying to figure out why you claim that reglib is an NetBeans specific module? It is not dependent on any modules (according to it project.xml file). Is there nb specific code or data in reglib? Should it move to the 'registration' module, which has no API at all?
Sustaining does not see any easy way how to move lib from one cluster into another cluster as part of patch release. Even if we use post-install-hook, this will be very complicated thing to do and we believe that it will not work for all NB installations (especially read-only install dir and patches in user dir may cause a lot of troubles, also Mac installation will be problematic). So we would like to warn everybody that if this issue is critical, then it should be fixed in NB 6.5 RC or FCS. Otherwise sustaining will not be able to deliver fix of this issue as part of NB 6.5 patches.
The registration functionality has been turned off in NetBeans and installer. So closing as wontfix.