OK, I didn't know that you guys were on Juno. But yes, my concern is simply having a version that can be built and used from within any valid Indigo (and Juno of course!) installation. Hopefully that won't be a concern going forward, but it is now.
I'm not sure what we mean exactly when we talk about the "launchers", so just to be clear we're talking about the same thing: The issues I'm seeing aren't confined to launchers, they're in most of the framework plugins and they all seem to stem from this one wst.server.core extension. As WST won't be shipping an Indigo compatible version, this means that if these plugins are dependent on that patched core, then we're never going to be able to build against Indigo so we need a version that doesn't have these specific version dependencies.
btw, how do I apply that patch to my development machine so that I can build this version?
On 2012-04-24, at 11:37 PM, Raev, Kaloyan wrote:
No, I mean the “Indigo” Simultaneous Release. The Launchers are already on the Juno train, but that version is not compatible with Indigo. We can make a compatible version in the Indigo branch, but it won’t be part of any release train. But it seems that this is not a concern for you. From: libra-dev-bounces@xxxxxxxxxxx [mailto:libra-dev-bounces@xxxxxxxxxxx] On Behalf Of Miles Parker
Sent: 24 април 2012 г. 18:34 ч.
To: Libra developers list
Cc: Leo Dos Santos
Subject: Re: [libra-dev] Juno dependencies in Libra framework UI?
On 2012-04-24, at 12:00 AM, Raev, Kaloyan wrote:
The OSGi Bundle Facet feature was introduced with Indigo and in Juno it is still compatible with the Indigo release train. Naci already told you about the Framework Launchers. Indeed, from release perspective it is possible to downport the Framework Launchers to the Indigo stream. Then we can produce an extraordinary release of Libra for Indigo. However, this release won’t be part of the Indigo Simultaneous Release, which means it will not be available on the Eclipse Indigo update site. Only users and adopters that explicitly want this new release will actually use it. If you want to go this way,
Did you mean "Juno" Simultaneous release?
let me know. I will support the work with the release efforts.
The issue isn't so much that we want to be on the release train or anything. We just need to be able to build something that users who are currently on Indigo -- which is almost all of our users -- can consume and that we can build against the Indigo dependencies. IOTW, we've got people now who want to pound away at things, and I want to support them as first class users. And we also need to know that we have something that will work OOTB if there are issues with getting changes into WTP, etc.. Does that make sense?
Regarding lack of response in WTP. Indeed, some subprojects experience some stuffing problems. If you give me a list of bugs, I can raise them to the PMC. Sometimes, this helps to make the things run faster.
Perhaps I'm being overly conservative, I just don't feel like I can rely on getting stuff that builds into WTP from a release perspective given our own internal development timelines. If I was to say create a patch for WTP that the Virgo Tooling relied on and then that patch didn't end up in the Juno release of WTP because of process issues, then the entire Virgo Tooling Juno release is broken, and we don't have time to fix it == really bad. :) I don't want to be facing the problem of trying to talk someone at WTP into looking at a patch when they're at RC1 or whatever. So my sense is that it isn't worth the risk unless it is creating really new functionality that can only be created that way.
______________________________ Senior Engineer and Product Manager, Tasktop Committer, Eclipse Mylyn and Virgo Project Lead, Model Focussing Tools and AMP
libra-dev mailing listlibra-dev@xxxxxxxxxxxhttp://dev.eclipse.org/mailman/listinfo/libra-dev
Miles T. Parker
Senior Engineer and Product Manager, Tasktop
Committer, Eclipse Mylyn and Virgo
Project Lead, Model Focussing Tools and AMP