Community
Participate
Working Groups
For some reason, it appears to me, the xpath2 sdk feature is not built. Both the org.eclipse.wst.xsl_sdk.feature and the org.eclipse.wst.xsl.feature both include (only) the org.eclipse.wst.xml.xpath2.processor.feature The org.eclipse.wst.xsl_sdk.feature should include (build) the org.eclipse.wst.xml.xpath2.processor.sdk.feature Also, both xpath2 features contain "source template folders" ... they only need to be in org.eclipse.wst.xml.xpath2.processor.feature and, of course, the build.properties file in org.eclipse.wst.xml.xpath2.processor.sdk.feature should be modified to include the directive generate.feature@org.eclipse.wst.xml.xpath2.processor.feature.source=org.eclipse.wst.xml.xpath2.processor.feature I have not actually looked at a "distribution" ... I am coming to these conclusions just looking at the feature definitions in cvs. I am assuming there's not some other technique I don't know about, being used to create the sdk feature.
(In reply to comment #0) > For some reason, it appears to me, the xpath2 sdk feature is not built. > > Both the > org.eclipse.wst.xsl_sdk.feature > and the > org.eclipse.wst.xsl.feature > both include (only) the > org.eclipse.wst.xml.xpath2.processor.feature > > The > org.eclipse.wst.xsl_sdk.feature > should include (build) the > org.eclipse.wst.xml.xpath2.processor.sdk.feature > > Also, both xpath2 features contain "source template folders" ... they only need > to be in > org.eclipse.wst.xml.xpath2.processor.feature > > and, of course, the build.properties file in > org.eclipse.wst.xml.xpath2.processor.sdk.feature > should be modified to include > the directive > > generate.feature@org.eclipse.wst.xml.xpath2.processor.feature.source=org.eclipse.wst.xml.xpath2.processor.feature > > I have not actually looked at a "distribution" ... I am coming to these > conclusions just looking at the feature definitions in cvs. I am assuming > there's not some other technique I don't know about, being used to create the > sdk feature. Athena based builds had a slightly different way of creating the SDK feature as compared to the way the WTP build does it. Also there isn't really any difference between the Xpath2 Processor Feature and the SDK. the only difference would be having generated source bundles.
It also appears the org.eclipse.wst.xml.xpath2.processor_tests.feature is never built. Its not in any map files. For the WTP build, you apparently build the xpath2 test bundle with other xsl tests. Is that required? Do the xpath2 tests depend on xsl or xsl tests? Or, could it be broken out into its own feature? (What I'm after is a stand alone xpath2 build, independent of the rest of xsl (Conceptually, I'd think xsl would depend on it, but not vice versa ... is that overly simplistic on my part? Do you use the org.eclipse.wst.xml.xpath2.processor_tests.feature for any special builds? If not ... I'll "take it over" to set it up as other tests features ... but if you use it for your own "side" thing, then that's ok too. and I'll handle some other way. And, to be explicit, do you mind if I fix-up the SDK feature to include the runtime feature (and the source features, of course). I don't want to mess you up ... but, not sure how else we can be consistent in WTP (in the sense that users get a consistent stuff, if they install the SDK version). Again, if that would mess up your current scheme, I'll leave it alone ... but, doesn't seem like its good for much, as it is. From my limited knowledge. Thanks,
(In reply to comment #2) > It also appears the > org.eclipse.wst.xml.xpath2.processor_tests.feature > is never built. Its not in any map files. This is a left over from the Athena build. In actuallity the PsychoPath Processor is part of the wst.xsl component. It probably actually needs to be split out into it's own component (wst.xml.xpath). > > For the WTP build, you apparently build the xpath2 test bundle with other xsl > tests. Is that required? Do the xpath2 tests depend on xsl or xsl tests? Or, > could it be broken out into its own feature? (What I'm after is a stand alone > xpath2 build, independent of the rest of xsl (Conceptually, I'd think xsl would > depend on it, but not vice versa ... is that overly simplistic on my part? Correct, this was again done for historical reasons due to XPath 2 coming in as part of the wst.xsl incubator project. It really does need to be split into it's own component in wst as mentioned above. > > Do you use the > org.eclipse.wst.xml.xpath2.processor_tests.feature > for any special builds? If not ... I'll "take it over" to set it up as other > tests features ... but if you use it for your own "side" thing, then that's ok > too. and I'll handle some other way. No we no longer use it for any special builds. The maven based CI builds don't require the feature to run the tests. > > And, to be explicit, do you mind if I fix-up the SDK feature to include the > runtime feature (and the source features, of course). I don't want to mess you > up ... but, not sure how else we can be consistent in WTP (in the sense that > users get a consistent stuff, if they install the SDK version). Again, if that > would mess up your current scheme, I'll leave it alone ... but, doesn't seem > like its good for much, as it is. From my limited knowledge. Nope be my guest. I really would like to see this made into it's own component, as it really has grown into that over the last year. If we do that, QA contact should be Jesper as he is heading up the PsychoPath processor development now.
Another, more minor question ... the .classpath file has <accessrules> <accessrule kind="accessible" pattern="org/eclipse/wst/xml/xpath2/**"/> </accessrules> In my experience, and limited view, that means it is ok to access non API in itself. Is there other xml.xpath2 plugin? I don't see any except the branding plugin (which doesn't even have Java code). so ... as far as I know, this access rule can be removed ... but, thought I'd ask here if it serves some purpose I'm not aware of.
(In reply to comment #4) > Another, more minor question ... the .classpath file has > > <accessrules> > <accessrule kind="accessible" pattern="org/eclipse/wst/xml/xpath2/**"/> > </accessrules> > > In my experience, and limited view, that means it is ok to access non API in > itself. Is there other xml.xpath2 plugin? I don't see any except the branding > plugin (which doesn't even have Java code). so ... as far as I know, this > access rule can be removed ... but, thought I'd ask here if it serves some > purpose I'm not aware of. There was thought of breaking the plugin up into two or more plugins, but that hasn't occurred yet.
Moving to the XPath component out of XSL.
