Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 128678 - Push API change to original resolver-1.2
Push API change to original resolver-1.2
Status: RESOLVED FIXED
Product: xml
Classification: Unclassified
Component: Catalog
6.x
All All
: P3 (vote)
: 6.x
Assigned To: mslama
issues@xml
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-28 10:34 UTC by mslama
Modified: 2009-02-19 23:31 UTC (History)
4 users (show)

See Also:
Issue Type: TASK
:


Attachments
readme file with more details about changed in fork of resolver-1.2 (1.23 KB, text/plain)
2008-02-28 10:40 UTC, mslama
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mslama 2008-02-28 10:34:31 UTC
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.
Comment 1 mslama 2008-02-28 10:40:47 UTC
Created attachment 57425 [details]
readme file with more details about changed in fork of resolver-1.2
Comment 2 Michael Nazarov 2008-02-28 18:30:54 UTC
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.
Comment 3 mslama 2008-02-29 08:33:52 UTC
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.
Comment 4 Samaresh Panda 2008-03-11 23:54:28 UTC
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 -------------------
Comment 5 Samaresh Panda 2008-03-14 00:17:52 UTC
Based on my email conversation, I do not think I can do much. Marking this as future.
Comment 6 Antonin Nebuzelsky 2008-03-20 17:58:10 UTC
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.
Comment 7 mslama 2008-03-20 18:16:02 UTC
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)
Comment 8 Samaresh Panda 2008-03-21 17:28:53 UTC
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.
Comment 9 Samaresh Panda 2008-03-24 21:32:50 UTC
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.
Comment 11 mslama 2008-04-07 13:23:54 UTC
We will create separate NB specific package for resolver-1.2 for NB 6.1 packaging.
Comment 12 Antonin Nebuzelsky 2008-06-03 09:37:53 UTC
Reassigning to Alexei.
Comment 13 Samaresh Panda 2008-06-18 22:11:33 UTC
Downgrading this to a P3, since this issue has nothing to do with code, just for tracking purpose.
Comment 14 Yulia Novozhilova 2008-08-14 17:57:22 UTC
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.
Comment 15 Samaresh Panda 2008-08-15 16:02:03 UTC
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.
Comment 16 Samaresh Panda 2008-11-18 16:14:56 UTC
Should be a task instead. Updated appropriately.
Comment 17 mslama 2009-01-29 11:56:39 UTC
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.
Comment 18 mslama 2009-01-29 13:03:38 UTC
main #aafdd2524f9b
Comment 19 mslama 2009-01-29 14:34:25 UTC
main #3dcbc7ea2a05 Increment spec version of org.apache.xml.resolver
Comment 20 Quality Engineering 2009-01-30 08:46:22 UTC
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.
Comment 21 mslama 2009-02-02 09:00:34 UTC
main #3dcbc7ea2a05
Increment spec version of org.apache.xml.resolver.
Comment 22 Quality Engineering 2009-02-03 08:33:55 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo