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.
Often our external integrators are ready to adopt a module to work well with two or more versions of NetBeans. Then they get really upset if such effort is not possible. That is why there should be a documented way how to make one module (or more modules) working well with old window system and with new one. This includes some kind of support for specification of layout of components in Windows/ as well as Windows2/
It can work well when module defines the same set of TopComponents (settings files) in both old and new configuration. If there is some component in old configuration which is not defined in new configuration there is currently no way how to detect that this component should not be imported. Is such limitation acceptable? If yes then it is ok to define old and new winsys configuration in new module.
Defining components in both layouts is acceptable limitation in my opinion.
Actualy limitation is not so strict. Components defined in old configuration must be subset of components defined in new configuration. In other words if component is defined in old configuration then it must be defined in new configuration. (New configuration can define more components than old configuration.)
this is IMHO invalid. rather then having a module to work with 2 distinct version of the IDE out of the box, it's better and more maintainable to have 2 distinct version of the modules. people working with the platform will always fix their product to a giveen platform version, possibly doing a complete upgrade from time to time. Yarda, do you have a usecase where it's causing trouble to roll out 2 version of the module? Closing as won't fix, please reopen if you disagree.
A bit too late, I am affraid. This was needed for modules to run in 3.5 and 3.6.
closed