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.
due to http://hg.netbeans.org/releases/rev/e7d30459a7f9 mix of annotation based registration and layer based registrations causes incorrect ordering of resolvers: all layer.xml based resolvers are put before all annotation based resolvers after
was found when evaluating issue #208111
Right. That is the reason why all layer based resolvers in the distribution were converted to annotation based. The fix is to convert all others as well. Should be fairly easy with @MIMEResolver.Registration. This evaluation would mean won'tfix. Alternatively I can change the annotation based resolvers to take priority. This would require an API review.
(In reply to comment #2) > Right. That is the reason why all layer based resolvers in the distribution > were converted to annotation based. > > The fix is to convert all others as well. Should be fairly easy with > @MIMEResolver.Registration. This evaluation would mean won'tfix. (In reply to comment #2) > Right. That is the reason why all layer based resolvers in the distribution > were converted to annotation based. > > The fix is to convert all others as well. Should be fairly easy with > @MIMEResolver.Registration. This evaluation would mean won'tfix. The problem is that platform was changed incompatibly => application based on RCP have to be rewritten to work on this state of platform (i.e. by replacing all layer.xml based registration to annotations) > > Alternatively I can change the annotation based resolvers to take priority. > This would require an API review. Why position is not enough to sort both kind or resolvers?
Will try.
Fix 0bcc265ca338 made declarative resolvers available in unit tests even if none of them are included in a lookup. However this still leads to problems with tests that are registering their own resolvers into lookup (bug 208167). Moreover the combination of XML resolvers being read from file object directly and @MR.xyzRegistration resolvers being read from lookup does not respect mutual positioning. Moreover constructing FolderLookup is not easy as it requires some mime resolution (.instance, JavaHelp.xml, folders), but it also currently produces list of registered mime resolvers. Thus I am going to stop using .instance files. I'll rename them. Possibly to .xml and just annotate them with attributes that will take precedence when converting them to resolvers.
*** Bug 208167 has been marked as a duplicate of this bug. ***
core-main#bbc75f9bab51
The JavaScript tests are still failing after 3 days in JavaEE build #3742: http://bertram2.netbeans.org:8080/job/javaee/, reopening. Looks like this change is not in the build yet?
(In reply to comment #7) > core-main#bbc75f9bab51 Does not appear to exist, did you forget to push it? If you are not using *.instance, maybe move out of Services altogether. The history is a little complicated - originally Services/MIMEResolver/*.xml had InstanceCookie and were loaded essentially using Lookup.getDefault().lookupAll(MIMEResolver.class), which permitted declarative and procedural resolvers to be intermixed. When that was changed so as to avoid a dep on loaders (bug #138846), they had to be separated (and 10d30eec11f7 put the declarative ones first, effectively making the procedural ones useless), though for compatibility the declarative resolvers were still read from the same location. It is possible that procedural resolvers, manually registered declarative resolvers, and annotation-registered resolvers could all be loaded with a single call to Lookups.forPath("Services/MIMEResolver") - and thus freely intermixed - if RecognizeInstanceFiles were made to load the MIMEResolver objects from the declarative forms, and RecognizeInstanceObjects also delegated to this impl somehow.
(In reply to comment #9) > (In reply to comment #7) > > core-main#bbc75f9bab51 > Does not appear to exist, did you forget to push it? Probably. It is there right now. > If you are not using *.instance, maybe move out of Services altogether. The recent problems are caused by ordering. The old definitions and new definitions should inter-mix. Which is what I get when keeping the definition in Services/MIMEResolver for free.
Integrated into 'main-golden', will be available in build *201202220400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/bbc75f9bab51 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #208160: Keep ordering by generating just .xml files