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.
AUC request: ============ Module: Customer Encoder Editor AUC Type: Beta AUC Version: 5.5.1 Contact: Gabriel Badescu Live date: April 16, 2007 Test bits to be delivered in early March. Final version in early April. Waiting for more information from Gabriel.
NB signature required: Yes URL: http://www.glassfishwiki.org/jbiwiki/Wiki.jsp?page=CustomDefined The bits are ready however module descriptors do not contain propert CDDL license texts. Module suite consists of umbrella module "Encoder Support" (org-netbeans-modules-encoder-suite.nbm) plus 8 more modules. Waiting for rebuilt modules.
URL: http://www.glassfishwiki.org/jbiwiki/attach/CustomDefined/netbeansmodules.zip We now have the final bits with proper license. Could you please Roberte sign all the modules and stage them on 5.5.1 Beta Update Center? Thanks!
Customer Encoder modules are staged on Beta UC for Nb 5.5.1. Please, proceed with download test.
There is problem with dependencies of all Encoder modules. See one of the error dialog (attached) that appears when trying to add modules to the list of "Include in Install" at the 2nd step of Update Center Wizard. Tested in following configuration: Mac OS X 10.4.8 on i386 NetBeans IDE 5.5.1 Beta (Build 200702211400) Java HotSpot(TM) Client VM 1.5.0_07-87
Created attachment 39258 [details] Screenshot attached...
I had similar problems until I realized that these modules work only in NetBeans 5.5.1 Gavotte release where it works fine. The problem is whether it should not have its own update center then not to disappoint NetBeans 5.5.1 users. What's your opinion Jun?
Yes, all encoder modules require enterprise pack to work. Especially, they heavily depend on XML Schema modules and the XMLBeans module. Can I just add " (Ent. Pack Required)" to every encoder module's display name? So users know the prerequisite before they attempt an installation. Later, if we have more and more modules coming out for various encoding support, we may consider to have a update center specifically for encoders. But right now since it is still in Beta stage, my recommendation is to put them into AUC Beta but explicitly mark them with " (Ent. Pack Required)". Sounds OK?
I am not sure if hosting enterprise pack modules in NB beta UC is a good idea. For enterprise pack 5.5, there was a separate update center to host entpack5.5 modules. Gavotte eventually will have its own update center but gavotte beta, unfortunately, points to Nb551 ucs and entpack55 UC. The following are the possible solutions to make nbms available to users for gavotte: - Make them available on 551 UC, as suggested previously. IMHO this is not a good idea since it will confuse NB551 users. - Make them available on entpack55 UC but set their spec numbers so that entpack55 users will not see those modules and only gavotte users will see it. - Make the nbms available on enterprise.netbeans.org and request that users download these and manually install the nbms (instead of through an UC). I myself prefer this solution to the previous two.
Correction to the previous post: "The following are the possible solutions to make nbms available to users for gavotte:" should read as "The following are the possible solutions to make nbms available to users for gavotte beta:"
Why do you think that putting the modules on the 551 UC would be confusing? Im assuming enterprise pack 55 users would not be going to the UC - correct?
> Why do you think that putting the modules on the 551 UC would be confusing? Because NB551 users who have not installed enterprise pack 551 will also see the modules but cannot download and install. So, while putting the nbms on NB551 UC would make it available for gavotte beta users, presence of these bugs might confuse NB551 users.
Other possible ways of solving this issue: - In coke update center, create a separate folder '5.5.1 Beta Modules' and put gavotte beta modules there. This will of course only give a visual indication to the user. It will still not stop coke users from downloading (unless spec numbers are adjusted to make them invisible for coke users). - Provide an update on coke uc that will add a gavotte beta uc to the user's list of update centers and create a gavotte beta uc and populate them with gavotte beta modules. This may not be worthwhile if the number of modules is not large; if the set of gavotte beta modules is small, then it may be sufficient to just post the nbms on enterprise.netbeans.org for manual downloads. - Post the modules on plugin portal at http://plugins.netbeans.org/PluginPortal/.
I tend to agree with the first solution i.e. to put the module into a special folder on EntPack Update Center. However, shouldn't the folder be created under Features instead of the same level? I mean: NetBeans Enterprise Pack Update Center | +-- Features | +-- Beta | +-- Customer Encoder +-- Libraries
> NetBeans Enterprise Pack Update Center > | > +-- Features > | +-- Beta > | +-- Customer Encoder > +-- Libraries The 'NetBeans Enterprise Pack Update Center' above refers to 5.5 UC (which is also unfortunately the UC pointed to by 5.5.1 beta). So, the above arrangement would indicate that 'beta features' relate to 'beta features for 55'. What we are trying to achieve here is to provide a separate uc for 5.5.1 beta users within the existing 5.5 uc; therefore the following may be more appropriate: NetBeans Enterprise Pack Update Center | +-- Features +-- Libraries +-- NetBeans Enterprise Pack 5.5.1 Beta Update Center | +-- Features | +-- Customer Encoder | +-- Libraries There are several potential problems with this approach: 1) We need to ensure the ordering is right. (We don't want the visible order in the client to be 'features' , '.. beta center' , 'libraries' ...) 2) We are simulating an UC within a UC. This might lead to issues while the client resolves dependencies. For instance, if a library module is present in both top-level libraries and beta|libraries folder, which one will be picked up? This may be a remote use-case of course. 3) As mentioned earlier, we should ensure that the openide version dependency for 5.5.1 beta modules should be set so that 5.5 users would get a 'incompatible version' dialog. We should do so because there is no way to make the 5.5.1 beta entries themselves invisible to 5.5 users. Given the issues involved, we should take a look at the other options (Make the nbms available on enterprise.netbeans.org, provide a patch which will add a dedicated 5.5.1 beta uc...) before settling on this.
Karthik and I discussed this and agreed that we would put these modules under the Coke UC under a folder called 5.5.1 (to avoid confusing Coke users). Thanks! Gabe
Suggested structure: NetBeans Enterprise Pack Update Center +-- NetBeans Enterprise Pack 5.5 Update Center | +-- Features | +-- Libraries +-- NetBeans Enterprise Pack 5.5.1 Beta Update Center | +-- Features | +-- Customer Encoder | +-- Libraries
Just a minor correction: The name of the feature should be "Custom Encoder" (not "Customer Encoder") or more generalized as "Encoder Support" (I prefer this one actually).
The name used here is only for the purposes of the dicsussion; the update center itself will take the name from the nbm itself, using OpenIDE-Module-* variables in the manifest. While preparing the nbm, modulename, short and long descriptions, dependencies etc should be checked to see if they have correct values. Also, we need to ensure open-ide dependancy is set to 551's openide version.
I agree with last Karthik's proposal 3 comments above (Wed Mar 21 18:45:34 +0000 2007). Let's create two subfolders on the Enterprise Pack Update Center distinguished by version in the title and put the Custom Encoder modules under the 5.5.1 one. May we proceed with staging or will you send us some other bits?
Thanks. The structure looks good. As planned, I will send you these 9 NBMs again no later than Apr. 9 (maybe as early as Apr. 2) as the bits for Custom Encoder Beta release for 5.5.1 Enterprise Pack Beta. I will also send you NetBeans 6 version of these 9 NBMs just in case you have AUC created for the JavaOne preview version of NB 6 Enterprise Pack. So you can publish this feature for NB 6 Enterprise Pack preview version too.
Bits for 5.5.1 Enterprise Pack Beta: http://www.glassfishwiki.org/jbiwiki/attach/CustomDefined/EncoderModules551Beta.zip Bits for 6.0 Enterprise Pack Preview: http://www.glassfishwiki.org/jbiwiki/attach/CustomDefined/EncoderModules600Preview.zip
Could you please Roberte stage the new bits according to the agreed structure and let us know here? Please see above. Thanks!
Just noticed that 6.0 has an update center called "NetBeans SOA Pack Update Center". Probably for 6.0, the encoder modules should be staged there?
> Suggested structure: > > NetBeans Enterprise Pack Update Center > +-- NetBeans Enterprise Pack 5.5 Update Center > | +-- Features > | +-- Libraries > +-- NetBeans Enterprise Pack 5.5.1 Beta Update Center > | +-- Features > | +-- Customer Encoder > | +-- Libraries In the above suggested structure, it should be okay if empty folders are not created. That is, if the coke UC is empty, the the folder "NetBeans Enterprise Pack 5.5 Update Center" and its sub-folders may not be created. (The folders and subfolders will be created of course if and when any coke modules are posted).
Encoder modeles are now staged on both EP 5.5.1 and EP 6.0 UCs please proceed with the download test. I put the umbrella module under "Features" and the rest of modules unde "Libraries" as we usually do on NB UCs Posting tools are setup to exclude empty folders, so I didn't create folder "NetBeans Enterprise Pack 5.5 Update Center".
Looks good except "_" char in the folder name: "NetBeans Enterprise Pack 5.5.1 Beta Update_Center". Could you Roberte remove the underscore?
"_" is removed. I'm sory for the typo.
Did overall testing for this feature based on the bits installed from 5.5.1 and 6.0 staging update centers respectively. Both 5.5.1 and 6.0 bits work as expected. Please proceed with go live. Thanks.
Done. I pushed the Encoder modules live on both UC for EP 5.5.1 and EP 6.0
Thanks a lot, folks. It looks good!
I downloaded latest NetBeans 6.0 all-in-one bits from http://bits.nbextras.org/netbeans/6.0/nightly/ and noticed that there is nothing called "Update Center" anymore. Al plugins are installed, updated and managed through Tools-->Plugins. I don't see SOA pack in the Plugins Manager screen's Settings tab either. Did SOA pack update center get removed? How can user see these encoder modules that have just been published? Thanks. Jun
I have created http://www.netbeans.org/issues/show_bug.cgi?id=102071 to track encoder plugins on NB6 UC. (junxu, gbadescu: please add yourself to cc for 102071, if needed). ON 5.5.1 UC itself, the issue has been resolved and therefore i am closing this issue.
Created attachment 41601 [details] Encoder modules revision 1 for 551
This ticket is reopened due to issue 102235 and 101048. The current encoder bits in Coke AUC can be installed by 5.5 EP users without any warnings. But after restarting NB, NoClassDefFound occurs. The solution is to change encoder modules to depend on xml-schema-model and xml-xam modules with minimum specification number 1.1.22 instead of 1.1.21. 1.1.22 is used in NB EP 5.5.1 Beta for these two xml modules, which are depended on by encoder modules. In NB EP 5.5, the specification number was 1.1.21. After bumping up this specification number, even though 5.5 EP users select encoder modules to install, they will get warnings on dependency not satisfied. Even though they ignore warnings and still install these modules, these modules will not be enabled and the problem reported in 102235 and 101048 will not occur. Please sign the NBMs in the EncoderModules551_r1.zip attachment and refresh the encoder modules in the 5.5 Enterprise Pack Update Center. Thanks. Jun
Are you okay with this solution Karthik? I think it makes sense although it's another ugly patch of something that could have been solved by 1 person in 2 minutes BEFORE 5.5.1 EP was released. :-|
I agree with the solution. (You are right; we should have checked the dependency during the initial posting itself...)
For 55 users who have already downloaded and installed the module, the workaround to this issue is to uninstall the encoder modules.
*** Issue 101048 has been marked as a duplicate of this issue. ***
OK, could you please Roberte sign the modules and restage them on 5.5 EP UC? Thanks a lot.
Modules were restaged, please, proceed with the download test.
Verified the module download from staging UC. Testcases: - Installed NB551 , entpack-beta for 551. Downloaded and installed encoder modules and it worked without any errors. - Installed NB55, entpack for 55. Error dialog popup, and informed user the dependencies could not be satisfied. If installed, there was a Warning dialog asking user either to "Disable and continue" or "Exit". It all worked well. However, there is a minor glitch: The Warning dialog will popup one more time when you quit and restart the IDE. The dialog will then no longer show up when you start IDE the third time.
Verified as described previously and will close the bug.
Verified
For some reason, the staging and production seem to be out of sync for 'Enterprise Pack 5.5.1 beta Update Center' and 'Enterprise Pack 5.5 Update Center'. It is possible that the staging was not pushed to production. Robert: Can you please check push the staging nbms to production on both the aboce centers?
It's really weird: staging area contains newer modules. Could you Roberte please investigate what's the difference? And publish it to the live Update Center? Thanks!
I think the problem might be that the spec number was not incremented; they are all version 1.0.
In an offline conversation, Jun Xu has confirmed that: - the existing spec numbers are correct - the bits on the staging work as expected. The only remaining thing that needs to be done is to push the staging bits for encoder modules on coke uc to production. Robert/Jiri : Can you please do so? Details of the offline conversation: - Both 551_entpack_beta and 55_entpack point to the same UC. 551 was discontinued after beta and hence did not get its own uc. - The existing modules in production work fine for 551 users and the new fix is not for 551 users. Since spec numbers are not incremented, 551 users wont see the new modules, which is okay. - 55 users, when they download the modules, will get the fix (which is merely to disable the module for 55). - existing 55 users who have already obtained the modules will not see the newer version. The workaround for them is to disable the modules manually. We have decided to live with this case and chosen not to re-post with updated spec numbers.
Would it be Roberte possible to push the modules from staging area to the live one, please? Thanks a million!
I just pushed modules live.
Verified that the production bits is working as expected, same as the staging bits.