|Re: [libra-dev] A home for Bundlor|
Do you agree that a Proof-of-Concept showing how Bundlor can be integrated with PDE is a good first step? If we see that this is possible (and also how it is possible), will open the door for many improvements like https://bugs.eclipse.org/329198 you have mentioned.
Realized I probably should have put this on the lists to begin with, correcting that now.
On Jan 19, 2012, at 5:20 AM, Raev, Kaloyan wrote:
Neither have I. I see it as a cool feature and could be a real nice to have, but it doesn't really fit in with the Virgo IDE scope writ narrow, that is "tools for the Virgo server runtime" (but very much does with the larger Spring donation which has also spawned Libra etc..) In some sense Bundlor complicates testing and deployment on the deployment side as the actual MANIFEST.MF aren't transparent and of course that's what is critical for testing what is going on with various deployment scenarios. On the other hand, all of the Virgo examples etc.. rely on it, and judging by the number of bugs raised (in a positive sense, i.e. enhancement requests, tweaks, etc..) I take it that it has a large and satisfied user community.
The scope of the Libra project is to provide an OSGi Enterprise toolset based on WTP and PDE.
We should definitely talk about scope and where we overlap. Leo and I are also very much interested -- as is I think a lot of the user community -- in having the most PDE like user experience possible. (Caveat: "where appropriate".) So for example, this is something the user community has been clamoring for and we want to give some love to: https://bugs.eclipse.org/bugs/show_bug.cgi?id=329198 Does that look anything like something that you guys might work on as well?
I don't think that that is true in the large sense, but it might be true now. Glyn can I'm sure speak to this better, but my understanding is that the Bundlor is a build-time only tool. As you say, it only creates the MANIFEST.MF and other artifacts that define a proper project. In that sense, it's basically a code-generation tool that happens to target build. If that is true than it should be totally workable to tack a Manifest and Schema builder onto .project after the (soon to be renamed) com.springsource.server.ide.bundlor.core.builder builder. [There is the added complexity of the Maven builder in the typical toolchain, but let's not even go there.]
In fact, what I (think) I would love to see Virgo primarily targeting full-fledged PDE projects. That would buy us a lot in terms of packaging issues, make things a lot more transparent for typical Eclipse developers, and make it especially easy to do things like deploy RAP applications. I should say that I know very little about WTP either, so I might be missing part of that picture here; I'm guessing that there are other project types that aren't compatible with PDE approaches and of course people should be able to use any projects that ultimately will build and run for the Virgo runtime target. It's just that we would be able to provide all of the advantages of PDE tooling and packaging to those that want it.
But the bottom line is that I was also thinking that Bundlor could be a great addition to PDE in that it is actually broader scope than WTP or Libra as well. I'd go a step further and argue for a PDE-owned model-driven successor that took care of a lot of other bits of build, plugin and feature definition and other house-keeping and configuration stuff, but now we're really outside of the immediate scope! Still, if any PDE folks want to jump in.. :)
So, let me know what you think. We're going to be isolating some of this stuff more, and I don't think there is any rush to resolve this. We likely will not be focussing actively on bundlor stuff soon, but of course if other people want to contribute to this area that would be great.