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.
When we make packages of NB 6.0.1 for Ubuntu we must strip all external libraries. We also removed NetBeans fork of resolver-1.2. There are 2 changes in NetBeans resolver-1.2 fork in comparison to original source. According to recommendation from Petr Kuzel we should get API change (one method added) to original resolver-1.2 and fix second change on NetBeans side. This way NetBeans packages can use original resolver-1.2. If this is not fixed we must create special updates to deliver forked resolver-1.2.jar to NetBeans Linux distributions as they do not work out of the box. See issues #127717 and #127132.
Created attachment 57425 [details] readme file with more details about changed in fork of resolver-1.2
Please clarify exact version which is affected. Your description says about 6.0.1 by Version field says 6.1 so this issue is on our dashboard. Help us to resolve this inconvenience.
For NB 6.0.1 we made workaround for this issue by creating special update. So preferred target for this fix is 6.1 and next version of Ubuntu. Be aware that this issue had 2 parts: a) change in resolver 1.2 API ie. change in original source so that this change will propagate into Linux distros in package b) change in NetBeans code to handle NPE Aim is to avoid using forked resolver-1.2.jar in NetBeans. I mentioned NB 6.0.1 to explain how we encountered and workarounded this issue for NB 6.0.1. For NB 6.1 packaging we would have to do the same thing if this issue will not be fixed.
Please see my email to commons-dev@xml.apache.org ------------------- start ------------------- Greetings. We have been using xml-commons-resolver-1.2 and we would like to vote for a new API. What is the process of getting our requests in? Is there a way we could file bugs/RFEs against resolver? Thanks Samaresh ------------------- end ------------------- Here is the response I got: ------------------- start ------------------- Hi Samaresh, Since the 1.2 release there hasn't been any discussion on future development or any changes made to the resolver codebase (in large part because no one is maintaining it these days). There currently are no plans for a 1.3. If one were to happen it needs content and volunteers to do the development and release management. Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@ca.ibm.com E-mail: mrglavas@apache.org Samaresh.Panda@Sun.COM wrote on 03/11/2008 02:38:28 PM: > > Hi Michael, > > Please see my answers in line... >> > > Do you have a proposal for a new API? Is this something you (and others >> > > since you mentioned "we") were planning to contribute to? >> > > > > Yes and yes, I would like to contribute. See > > https://issues.apache.org/bugzilla/show_bug.cgi?id=44582. I have filed > > this as a enhancement, but would like to know the road map for resolver? > > I mean is there a plan for resolver 1.3? > > > > Thanks > > Samaresh ------------------- end -------------------
Based on my email conversation, I do not think I can do much. Marking this as future.
Could we possibly fix it now a different way? Can we fix our code the way that the official resolver-1.2 would be sufficient and we could get rid of our forked resolver? Maybe we could use reflection to get to to the data from resolver without the need of the public getPublicIDs() method? Please, reevaluate for 6.1.
From packaging point of view it is bad to fork whole resolver because of change in org/apache/xml/resolver/Catalog.java, org/apache/xml/resolver/CatalogManager.java and org/apache/xml/resolver/tools/CatalogResolver.java. Would it be possible to make our own version of these classes so that we would use our patched version and could use the rest from original resolver? The main point is to avoid duplication of whole rest of resolver-1.2 in our fork. (ie. creating our small fork just with modified classes is quite ok)
Option 1: AFAIK, there are three changes required. 1. We may be able to use reflection for getPublicIDs() in Catalog class. 2. The null check in CatalogManager::readProperties() can be ignored, will throw some informational exception in log I believe. And I do not see a fix for this. The method is private. 3. Possible to extend CatalogResolver class and have our own impl. Option 2: A second and much cleaner approach is to have our own resolver based on apache (with full credit to Apache as per License) and you will not have to worry about packaging at all. IMO, second is better since we will have more control and we'll be able to fix any unknown bugs.
Marek, are you waiting for more inputs from me? Can you guys make a decision? I vote for second option and have our own resolver module. In this case, the external library will not come into picture.
Links to relevant files in mercurial: http://hg.netbeans.org/main/file/721f72486327/o.apache.xml.resolver/external/readme.txt http://hg.netbeans.org/main/file/721f72486327/o.apache.xml.resolver/external/resolver.patch
We will create separate NB specific package for resolver-1.2 for NB 6.1 packaging.
Reassigning to Alexei.
Downgrading this to a P3, since this issue has nothing to do with code, just for tracking purpose.
Samaresh, the way with the forked resolver is risky enough. Currently I've prepared a package with our patch but Ubuntu MOTU team convince me of necessity to update the original resolver package with a new API and do the other changes (handle NPE and CatalogResolver.java changes) in NetBeans sources. Could you please, provide me with a patch for NetBeans sources I can use to handle NPE if original resolver is supplied with getPublicIDs() method.
xml-common-resolver is kind of dead. When I last filed an issue, asking to incorporate the getPublicIDs() API, the response was that there is no one to make that change. So I'm not sure how you want to push this change to original resolver. I suggest you subscribe to commons-dev@xml.apache.org and send email them. Earlier I was thinking to extend original resolver but the classes are closely coupled and they have a lot of private code. So I'm not sure if we could do that either. Please feel free to download the source and take a look for yourself.
Should be a task instead. Updated appropriately.
Solution is as follows: As we cannot put forked resolver package into debian repository we had to use following workaround. 1. We added new method into org.apache.xml.resolver.Catalog.java as described above. It is compatible change. 2. We added 2 new classes org.apache.xml.resolver.NbCatalogManager.java and org.apache.xml.resolver.tools.NbCatalogResolver.java into resolver with necessary incompatible changes and all usages of CatalogManager and CatalogResolver in NB codebase are replaced by NbCatalogManager and NbCatalogResolver. It also includes fix for xmlbeans external library which bundles its own version of resolver.jar. xmlbeans' resolver.jar is deleted and dependency on o.apache.xml.resolver module is added to avoid duplicate resolver.jar.
main #aafdd2524f9b
main #3dcbc7ea2a05 Increment spec version of org.apache.xml.resolver
Integrated into 'main-golden', will be available in build *200901300228* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/aafdd2524f9b User: Marek Slama <mslama@netbeans.org> Log: #128678: Update patch for xml-resolver to be able to use original resolver package in Linux packaging.
main #3dcbc7ea2a05 Increment spec version of org.apache.xml.resolver.
Integrated into 'main-golden', will be available in build *200902030229* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/3dcbc7ea2a05 User: Marek Slama <mslama@netbeans.org> Log: #128678: Increment spec version of org.apache.xml.resolver.