What we need is a debug flag that loads the modules at random if possible (while still respecting the topological sort as defined by dependencies). This would show all kind of assumptions you didn't thing about.
--emi vin., 14 aug. 2020, 19:43 Patrik Karlström <pat...@trixon.se> a scris: > Hi, > > Den fre 14 aug. 2020 kl 11:39 skrev Emilian Bold <emilian.b...@gmail.com>: > >> I feel you are enumerating a whole bunch of workarounds you already >> thought about without giving us an example of the real issue you >> experienced. >> > > I was unable to, and still am, specifying the issues, but one of the > symptoms was that things that used to be initialized on time no longer were. > Very much like your db example below. > This appeared after switching to a newer jdk/jre, revarting that and > things worked as expected. > But I believe things can break pretty quick as it is now. > > >> >> Normally, modules can be installed and enabled and disabled by users are >> any time. >> >> If your app is somehow erratic now it means there's a hidden dependency >> not exposed. Maybe a module needs to provide / require some tags or maybe >> your module install needs to wait for something. So it could be a module >> problem or just a business logic problem: if a module prepares the DB in a >> background thread and the other module just starts using the DB right >> ahead, the modules could be loaded in the right order and still break the >> app due to a normal bug. >> > > Thanks, this makes a lot of sense. > > I will start declaring manifest dependencies, moduleType, and add > something like the WindowManager.invokeWhenUIReady() that modules can > register for and be run after the foundation of the application is set up > and ready to go. > > /Patrik > > > >> >> --emi >> >> joi, 13 aug. 2020, 13:46 Patrik Karlström <pat...@trixon.se> a scris: >> >>> Lately I've been experiencing problematic behavior in a platform >>> application with close to 40 modules, NetBeans ones un-counted. >>> >>> I believe that it's related to the fact that I did not declare >>> any OpenIDE-Module-Module-Dependencies in the manifests and that the module >>> load order changed somehow. >>> >>> I do have a couple of platform books but I'm struggling with putting the >>> pieces together in order to secure my module dependencies. >>> >>> This led to the following questions: >>> >>> 1. Is it just dumb luck that I got away with this for a couple of years, >>> just relying on maven dependencies? >>> >>> 2. Does the following list reflect the order for @OnStart and Installers >>> to be executed? >>> INFO [org.netbeans.core.startup.NbEvents]: Turning on modules: >>> org.openide.util.lookup [8.41.1 >>> 12.0-u1-efd543aaefdb0a9f8f0073896cb12c82fe4ef9c8] >>> org.openide.util [9.15.1 >>> 12.0-u1-efd543aaefdb0a9f8f0073896cb12c82fe4ef9c8] >>> org.openide.util.ui [9.16.1 >>> 12.0-u1-efd543aaefdb0a9f8f0073896cb12c82fe4ef9c8] >>> org.openide.modules [7.56 >>> 12.0-u1-efd543aaefdb0a9f8f0073896cb12c82fe4ef9c8] >>> org.netbeans.api.annotations.common/1 [1.35 >>> 12.0-u1-efd543aaefdb0a9f8f0073896cb12c82fe4ef9c8] >>> se.trixon.almond.almond.nbp.core [11.0.6 11.0.6-20200809 202008090637] >>> org.openide.filesystems [9.18 >>> 12.0-u1-efd543aaefdb0a9f8f0073896cb12c82fe4ef9c8] >>> ... >>> >>> 3. Will the order of the module loading always be the same, given that >>> the module collection is unchanged? >>> >>> 4. Will OpenIDE-Module-Module-Dependencies declarations change the >>> loading order? (Counting on that actually :)) >>> >>> 5. Is it a good idea to create a module A, that depends (manifest) on >>> module B, C & D, and let module E that depends on B,C,D depend on A instead? >>> There are a couple of E1, E2,E3 modules. >>> >>> 6. Should I combine OpenIDE-Module-Module-Dependencies with <moduleType> >>> in nbm-maven-plugin? >>> >>> 7. How do they interact? >>> >>> /Patrik >>> >>>
