Community
Participate
Working Groups
Build Identifier: I20090611-1540 This patch is an extension of XMLResourceImpl EMF class in order to open files referencing DTD. The aim of this patch is to avoid bugs occuring when the XML parser try to check the DTD online if Internet connection is not available This class will be available for various future MoDisco discoverers based using DTD definitions. Reproducible: Didn't try
Created attachment 155129 [details] Extension of XMLResourceImpl class for DTD
Hi Nicolas, could you make, as soon a possible, the following confirmations via this bug: 1. You authored 100% of the content 2. You have the rights to donate the content to Eclipse under the EPL 3. You have already provided the filled Employer Consent Forms to the Foundation Fabien.
It sounds like a bug I already tried to fix by inhibiting the default "URIHandlerImpl": org.eclipse.gmt.modisco.common.core.resource.MoDiscoResourceSet.createURIConverter I wonder if this is redundant now?
I don't think it is redundant. The new mechanism does not require MoDiscoResourceSet using -> NoExternalLoadXmlResourceImpl hierarchy might be used in some more EMF contexts. Within a MoDiscoResourceSet, the old mechanism is more general than just "DTD" references cases.
(In reply to comment #2) > Hi Nicolas, > > could you make, as soon a possible, the following confirmations via this bug: > > 1. You authored 100% of the content > 2. You have the rights to donate the content to Eclipse under the EPL > 3. You have already provided the filled Employer Consent Forms to the > Foundation > > Fabien. Hi Fabien, 1. I am the author of 100% of the content 2. I have the rights to donate the content to Eclipse under the EPL 3. I have already provided the filled Employer Consent Forms to the Foundation Nicolas
Hugo, I think a CQ might be necessary for this bug. The contribution proposition has a reference to a String constant coming from a apache licensed source : "http://apache.org/xml/features/nonvalidating/load-external-dtd" It should not cause any problem since the constant is delivered with SUN JDK (com.sun.org.apache.xerces.internal.impl.Constants) and so should be seen as a "exempt pre-req" (http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf). Could you please initiate a CQ if you agree with the need ? Fabien.
Hi Fabien, If the problem is just about a reference to a String constant, we may find an alternative solution so that we don't need such a dependency anymore (by adding the constant to the class definition for instance). My opinion is that we are starting having (too) many dependencies to third-party libraries. We should try to limitate these dependencies to the strictly required/useful cases... Best regards, Hugo
Hugo, my explanation in my last comment was not understandable enough : In fact, since the referenced Constant is defined in Java component delivered within the SUN JDK, such a component is a pre-requisite for Eclipse components working and does not create problem from IP point of view. I commited the patch into "org.eclipse.gmt.modisco.common.core".
OK, thanks Fabien! Hugo
Patch integrated
