| [wtp-incubator-dev] More on XSL Graduation ... |
More on XSL Graduation ...
There has been a lot of really good discussion on this thread, and I appreciate being educated on options I hadn't even thought of before, but I think the XSL Component should become part of the Source Editing Project as originally planned. I don't think there is a completely compelling argument one way or the other, but here's the reasons that lead me to my conclusion.
1. The explicit purpose and mission of the WTP Incubator project was to incubate components that fit into the existing WTP Projects with the intent they would graduate into that Project. That's how we made sure we'd stay "in scope", the reason we name the incubating packages the way we do, etc. While I'm sure those rules could be bent, I'd prefer not to since those were our own conditions of creating that Incubating project. I don't mean to be bureaucratic, but sort of feel that was our contract of how we'd operate. As has been implied, now that the Eclipse Foundation allows for arbitrarily nested projects, perhaps we no longer need the WTP Incubator ... but, getting rid of it (and changing our own rules) would seem to be a larger, longer term effort than this specific issue. Post Galileo.
2. I personally believe there's "strength in numbers" and projects with more like-minded members encourages more collaboration -- even if they don't directly work on the same code. I know, it's not all or nothing, and its not magic, and not compelling all by itself ... it's just a tendency we should encourage, I believe, by having the two XSL committers join the larger Source Editing Project, instead of being "all by themselves" in their own project. In other words, there's a certain amount of "team work" that's associated with projects which we should encourage.
3. The XSL component seems to me to conceptually be more of a component, on par with DTD, XSD, etc., all of which would be meaningful in an XML Project (XDT). But, I couldn't see the point, currently, of each of them being their own project under WTP. While some have pointed out that 'source editing' sounds narrow, I think that's just a naming issuing of the project ... not an issue with the project's scope or mission.
4. To have a new XSL Project in WTP would take more PMC discussion. We'd be glad to do that if insisted, but so far, we have only talked about having an XML Project in WTP (which we would support). Having an XSL project in the WTP container project would change the shape of the project and would seem out of place, to me (as though it wasn't well integrated). So, I'd want more discussion with PMC if the committers insisted that's what was wanted.
So, what's in favor of a separate project? I do see the merit others have pointed out, in particular:
A. If the XSL Committers really did not want the current Source Editing team to have the ability to touch their code (or vice versa). Currently, we all follow "social conventions" in touching others components code which I think has been working well. I don't think that's a concern here in this case, but, by all means, let me know if I'm missing that. Long term, I do see that could be an advantage, though, by making boundaries and responsibilities clearer.
B. If the XSL Committers really thinks they would need an independent releases. But I'm not sure that's advisable for this case. It did once, for a 0.5 release, but that was mostly to get a permanent version in place for an adopter. I think having XSL (or a similar "component") have it's own release could lead to a "fragmented" install base, and surprising bugs would pop up with mixed installs. If the XSL Team wanted an off-cycle release, I would recommend they work with the "larger" source editing project to make sure they had a coordinated release. I agree this doesn't make conceptual sense with "JSP" and "JSDT" in the mix, but it would if we an XDT project container project in WTP, with XSD, DTD, XML, and XSL in that container.
So, I'd like to go with the original plan for XSL for Galileo, but start discussions of how to change WTP to be more in-line with the trend of having container projects.
In particular, the PMC does support having an XML sup-project in WTP and we'd help in the formation of that, in what ever way we could.
So, unless there's objections, I think I'm still on the hook to write up the manual IP log as I promised (which I'll start on today or tomorrow).