[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] A home for Bundlor

Hi Miles,

 

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.

 

Greetings,

Kaloyan

 

From: Miles Parker [mailto:miles.parker@xxxxxxxxxxx]
Sent: 20 януари 2012 г. 04:11 ч.
To: Raev, Kaloyan
Cc: Glyn Normington; Martin Lippert; Leo Dos Santos; libra-dev@xxxxxxxxxxx; virgo-dev@xxxxxxxxxxx; pde-dev@xxxxxxxxxxx
Subject: Re: A home for Bundlor

 

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:



Hi Miles,

I have to admit that I have only bare knowledge about Bundlor. I played with it a little bit, but have never used it for real development.

 

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?

 

In order to move Bundlor to Libra we must see how Bundlor can fit into this picture. AFAIK, correct me if I am wrong, Bundlor and PDE cannot work together.

PDE strictly follows the Manifest-first approach where developers maintain the Manifest themselves, while Bundlor requires from developers to maintain a template that is used to generate the Manifest. So, let's see if it is possible to integrate Bundlor with PDE. If it is possible and there are plans this to be done, then we should see what would be the best place for Bundlor - PDE or Libra. 

 

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.

 

cheers,

 

Miles

 

 




Greetings,
Kaloyan

-----Original Message-----
From: Miles Parker [mailto:miles.parker@xxxxxxxxxxx]
Sent: 19 януари 2012 г. 03:48 ч.
To: Raev, Kaloyan
Cc: Glyn Normington; Martin Lippert; Leo Dos Santos
Subject: A home for Bundlor

Hi Kaloyan,

I've recently begun some work on the Virgo Tooling / IDE. While looking through the code I noticed that a good deal of it had to do with the Bundlor mechanism. These really shouldn't have any direct coupling with the Virgo server runtime tooling proper -- they're a separate concern. In fact, it seems that they could have really wide applicability, beyond even Web Tools to eclipse packaging in general.  You're probably already familiar with them, but I wasn't and they do some pretty neat stuff with auto-discovery and maintenance of Manifest files, etc.

The plugins I'm thinking about are a few supporting classes in the Bundlor git repository:

http://git.eclipse.org/c/virgo/org.eclipse.virgo.bundlor.git/tree

But mostly in Virgo Tooling:

http://git.eclipse.org/c/virgo/org.eclipse.virgo.ide.git/tree

o.e.v.ide.bundlor.*

as well as large parts of

o.e.v.ide.manifest.*  (it looks like there is some par stuff there that would have Virgo tooling coupling)

My thinking is that they might be better suited to Libra, or perhaps even a more general set of tools that could be provided out of Libra or Virgo but w/o any of the target specific dependencies. At the very least I'd like to see what dependencies we can get out of them. (For all of the tool stuff a major thrust will be getting the existing Spring IDE dependencies out.)

So, the question is, do you have any interest in taking these on as part of Libra?

There are a number of outstanding bugs / feature requests -- nothing really urgent or involved  -- but that's not why I'm suggesting it. :) I've organized those under: https://bugs.eclipse.org/bugs/show_bug.cgi?id=368782

cheers,

Miles