from:"Jeff McAffer"

Re: [equinox-dev] [p2-dev] Equinox/p2 meeting minutes posted

2011-04-20 Thread Jeff McAffer


 If there is no objection I will release that during the week so we can 
 actually work on the code together.

I'm not a real fan of this approach in the last week of M7.  If bogus API gets 
into M7 then we'll have a hell of a time removing/changing it.  We almost 
always end up regretting those last minute pushes.  For the code itself I don't 
care but releasing API that is not baked is less than optimal.

Jeff

On 2011-04-19, at 1:30 PM, Pascal Rapicault wrote:

 This issue has been discussed at the end of M6 with Tom and it has been 
 agreed at the time that we will add this new API in M7 (I had not foreseen it 
 happening so late).
 
 I just attached a new patch taking the feedback into account. The focus is on 
 API since this is the most pressing issue for the rest of the week. The code 
 needs to be polished. 
 
 If there is no objection I will release that during the week so we can 
 actually work on the code together.
 
 
 On 2011-04-19, at 9:27 AM, Jeff McAffer wrote:
 
 Darn. you are talking about 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=337016?
 
 That's new API right?  I took a look but am not sure what the final form is 
 that you are thinking of.  Susan had some comments and David as well.  The 
 original patch from you had a method getAgent() which seems suspect as it 
 does effectively the ServiceHelper trick.  Do you have any examples of this 
 API in use.
 
 If you are going to look to release this please post a new patch with the 
 proposed shape, some example use and mark for review.  Ideally we could get 
 John and/or DJ to review (I'll review as PMC guy).  Please do not release 
 until it has been reviewed.
 
 Jeff
 
 
 On 2011-04-18, at 5:22 PM, Pascal Rapicault wrote:
 
 Crap. Just a heads up that I stil need to release the new simplified API 
 around the operations. I'll likely only get to that Friday.
 
 On 2011-04-18, at 3:21 PM, Thomas Watson wrote:
 
 http://wiki.eclipse.org/Equinox/Meeting_Minutes/20110418
 
 As a reminder M7 is next week. After that we head into rampdown for M7. 
 Please see http://eclipse.org/equinox/planning/freeze_plan_3.7.php for 
 more details on the process for ramping down the release.
 
 Tom
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 ___
 p2-dev mailing list
 p2-...@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/p2-dev
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [p2-dev] Equinox/p2 meeting minutes posted

2011-04-20 Thread Jeff McAffer

I did review the API (see the bug). 

The discussion there seems to be around naming etc.  The word setter does not 
occur in https://bugs.eclipse.org/bugs/show_bug.cgi?id=337016

Are we talking about the same thing?

BTW, you did ask if there are no objections...

Jeff


On 2011-04-20, at 11:32 AM, Pascal Rapicault wrote:

 There is only one discussion point. Do we want a new class versus a setter?
 Rather than focusing on the process, please review the API.
 
 On 2011-04-20, at 11:30 AM, Jeff McAffer wrote:
 
 We seem to still be discussing the API. You seem to want to put it in now 
 (today) and sort it out later. I'd like the API to be more agreed to 
 before putting it in to M7 given the lateness of the hour.
 
 Jeff
 
 On 2011-04-20, at 10:43 AM, Pascal Rapicault wrote:
 
 The API has been ready since before eclipsecon. Dave and others reviewed it 
 and it is good.
 What do you propose instead? We wait 3.7.1?
 
 On 2011-04-20, at 10:29 AM, Jeff McAffer wrote:
 
 
 If there is no objection I will release that during the week so we can 
 actually work on the code together.
 
 I'm not a real fan of this approach in the last week of M7.  If bogus API 
 gets into M7 then we'll have a hell of a time removing/changing it.  We 
 almost always end up regretting those last minute pushes.  For the code 
 itself I don't care but releasing API that is not baked is less than 
 optimal.
 
 Jeff
 
 On 2011-04-19, at 1:30 PM, Pascal Rapicault wrote:
 
 This issue has been discussed at the end of M6 with Tom and it has been 
 agreed at the time that we will add this new API in M7 (I had not 
 foreseen it happening so late).
 
 I just attached a new patch taking the feedback into account. The focus 
 is on API since this is the most pressing issue for the rest of the week. 
 The code needs to be polished. 
 
 If there is no objection I will release that during the week so we can 
 actually work on the code together.
 
 
 On 2011-04-19, at 9:27 AM, Jeff McAffer wrote:
 
 Darn. you are talking about 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=337016?
 
 That's new API right?  I took a look but am not sure what the final form 
 is that you are thinking of.  Susan had some comments and David as well. 
  The original patch from you had a method getAgent() which seems suspect 
 as it does effectively the ServiceHelper trick.  Do you have any 
 examples of this API in use.
 
 If you are going to look to release this please post a new patch with 
 the proposed shape, some example use and mark for review.  Ideally we 
 could get John and/or DJ to review (I'll review as PMC guy).  Please do 
 not release until it has been reviewed.
 
 Jeff
 
 
 On 2011-04-18, at 5:22 PM, Pascal Rapicault wrote:
 
 Crap. Just a heads up that I stil need to release the new simplified 
 API around the operations. I'll likely only get to that Friday.
 
 On 2011-04-18, at 3:21 PM, Thomas Watson wrote:
 
 http://wiki.eclipse.org/Equinox/Meeting_Minutes/20110418
 
 As a reminder M7 is next week. After that we head into rampdown for 
 M7. Please see http://eclipse.org/equinox/planning/freeze_plan_3.7.php 
 for more details on the process for ramping down the release.
 
 Tom
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 ___
 p2-dev mailing list
 p2-...@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/p2-dev
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 ___
 p2-dev mailing list
 p2-...@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/p2-dev
 
 ___
 p2-dev mailing list
 p2-...@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/p2-dev
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 ___
 p2-dev mailing list
 p2-...@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/p2-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [p2-dev] Equinox/p2 meeting minutes posted

2011-04-19 Thread Jeff McAffer

Darn. you are talking about 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=337016?

That's new API right?  I took a look but am not sure what the final form is 
that you are thinking of.  Susan had some comments and David as well.  The 
original patch from you had a method getAgent() which seems suspect as it does 
effectively the ServiceHelper trick.  Do you have any examples of this API in 
use.

If you are going to look to release this please post a new patch with the 
proposed shape, some example use and mark for review.  Ideally we could get 
John and/or DJ to review (I'll review as PMC guy).  Please do not release until 
it has been reviewed.

Jeff


On 2011-04-18, at 5:22 PM, Pascal Rapicault wrote:

 Crap. Just a heads up that I stil need to release the new simplified API 
 around the operations. I'll likely only get to that Friday.
 
 On 2011-04-18, at 3:21 PM, Thomas Watson wrote:
 
 http://wiki.eclipse.org/Equinox/Meeting_Minutes/20110418
 
 As a reminder M7 is next week. After that we head into rampdown for M7. 
 Please see http://eclipse.org/equinox/planning/freeze_plan_3.7.php for more 
 details on the process for ramping down the release.
 
 Tom
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 ___
 p2-dev mailing list
 p2-...@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/p2-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] incubator pages need updating

2011-04-06 Thread Jeff McAffer

Can the relevant people update the incubator pages to reflect reality?  See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=340648

Jeff



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for Borislav Kapukaranov on rt.equinox.bundles by Jeff McAffer

2011-04-01 Thread portal on behalf of Jeff McAffer

Jeff McAffer voted:
+1
+1

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for John W Ross on rt.equinox.bundles by Jeff McAffer

2011-04-01 Thread portal on behalf of Jeff McAffer

Jeff McAffer voted:
+1
+1

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for Glyn Normington on rt.equinox.bundles by Jeff McAffer

2011-04-01 Thread portal on behalf of Jeff McAffer

Jeff McAffer voted:
+1
+1

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Welcome Brian de Alwis as a new rt.equinox.incubator Committer

2011-01-11 Thread portal on behalf of Jeff McAffer

rt.equinox.incubator Committers,
This automatically generated message marks the completion of all the legal
paperwork and webmaster provisioning for Brian de Alwis. Brian de Alwis is
a new full Committer on the rt.equinox.incubator project.

Welcome!
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Committer vote for Brian de Alwis has concluded successfully

2010-12-29 Thread portal on behalf of Jeff McAffer

rt.equinox.incubator Committers,
This automatically generated message marks the successful completion of
voting for Brian de Alwis to receive full Committer status on the
rt.equinox.incubator project. The next step is for the PMC to approve this
vote, followed by the EMO processing the paperwork and provisioning the
account.

Vote summary: 9/0/0 with 29 not voting 
   ?  Simon Archer
  +1  John Arthorne
   ?  Neil Bartlett
  +1  Oleg Besedin
   ?  Boris Bokowski
   ?  Stoyan Boshev
   ?  Ian Bull
   ?  Sonia Dimitrov
   ?  Pavlin Dobrev
   ?  Aldo Eisma
   ?  Matthew Flaherty
   ?  Jennifer Fogell
   ?  Ted Habeck
   ?  Thomas Hallgren
   ?  BJ Hargrave
  +1  DJ Houghton
   ?  Simon Kaegi
  +1  Lazar Kirchev
   ?  Peter Kriens
   ?  David Lavin
  +1  Daniel Le Berre
   ?  Scott Lewis
   ?  Eric Li
   ?  Stefan Liebig
  +1  Martin Lippert
  +1  Jeff McAffer
   ?  Susan McCourt
   ?  Shawn Minto
   ?  Kim Moir
   ?  Andrew Niefer
   ?  Matthew Piggott
   ?  Steffen Pingel
  +1  Pascal Rapicault
   ?  Heiko Seeberger
   ?  Dave Stevenson
  +1  Thomas Watson
   ?  Matthew Webster
   ?  Ruibin Zhou

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO e...@eclipse.org

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Incubating product/feature publishing improvements

2010-12-22 Thread Jeff McAffer

After some discussion, we have decided to create a work area in the equinox 
incubator to work on improving the p2 support for publishing features and 
products.  We are doing this work in the incubator to better facilitate others 
participating.

The goal here is to unify the p2 and PDE (and other) publishing implementations 
to make a single, robust, easily consumed publishing mechanism for features and 
products. This should address a number of concerns around non-PDE build 
production of features and products.  For more details, see Bug 331974.  This 
should be a relatively short-term effort with a goal of getting changes into 
the mainstream by 3.7M6 if not earlier.

The work will be carried out in the existing Equinox incubator in CVS at
org.eclipse.equinox/incubator/p2/publishing

This area will be primed with a copy of p2.publishing and pde.build (and the 
related tests).

If you are interested in working on this effort, please make yourself and your 
particular concerns known on the p2-dev mailing list. From previous 
conversations Brian de Alwis has some contributions and I'll start an election 
for him as an equinox incubator contributor presently.

Jeff___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Vote for Committer status for Brian de Alwis was started by Jeff McAffer

2010-12-22 Thread portal on behalf of Jeff McAffer

rt.equinox.incubator Committers,
This automatically generated message signals that Jeff McAffer has
nominated Brian de Alwis as a Committer on the rt.equinox.incubator
project. The reason given is as follows:

I am pleased to nominate Brian de Alwis to work in the Equinox incubator. 
Specifically Brian has volunteered to work on issues around p2 publishing
of products and features.  He has already synthesized some patches from
various areas and contributed to correct branding issues on the Mac.  As a
committer on the incubator he will be better enabled to make the required
changes.


The vote is being held via the MyFoundation portal: voters *must* use the
portal for the votes to be properly recorded.  The voting will continue
until either all 38 existing Committers have voted or until they have been
given enough time to vote, even if they do not do so (defined as at least
one week). Brian de Alwis must receive at least three +1s and no -1s for a
successful election.

Eligible Committers must cast their votes through their My Foundation
portal page (do NOT just reply to this email; your vote will not be
correctly recorded unless you use the portal):

http://portal.eclipse.org/

The project Committers eligible to vote are:

Simon Archer
John Arthorne
Neil Bartlett
Oleg Besedin
Boris Bokowski
Stoyan Boshev
Ian Bull
Sonia Dimitrov
Pavlin Dobrev
Aldo Eisma
Matthew Flaherty
Jennifer Fogell
Ted Habeck
Thomas Hallgren
BJ Hargrave
DJ Houghton
Simon Kaegi
Lazar Kirchev
Peter Kriens
David Lavin
Daniel Le Berre
Scott Lewis
Eric Li
Stefan Liebig
Martin Lippert
Jeff McAffer
Susan McCourt
Shawn Minto
Kim Moir
Andrew Niefer
Matthew Piggott
Steffen Pingel
Pascal Rapicault
Heiko Seeberger
Dave Stevenson
Thomas Watson
Matthew Webster
Ruibin Zhou

*NOTE*: Successful elections are left open for a maximum of 120 days to
allow for processing of paperwork.  After that time the election will be
expired, regardless of its current status.  Should papework processing on
the part of the candidate take more time than allowed, a new election will
have to be held.

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO e...@eclipse.org

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] shell refactoring proposal - Gogo jars in orbit

2010-12-09 Thread Jeff McAffer

Much of this info is in the Orbit FAQ (http://wiki.eclipse.org/Orbit_Faq)

Summary: We need to get a Orbit committer who will support Gogo in Orbit.  
They then  enter a CQ that piggybacks on the orginal.  Then once that is 
approved they (the committer) puts the Gogo in Orbit and away we go.

To that end, I have recruited DJ to manage Gogo in Orbit.  He entered CQ 4690 
and will put Gogo in the Orbit builds etc when it is approved.

Jeff


On 2010-12-08, at 3:37 AM, Kirchev, Lazar wrote:

 Gogo jars are approved for use in equinox incubator (CQ 4561), but now what 
 should be done in order to include them in orbit? File another CQ to request 
 this?
  
 Lazar
  
 From: equinox-dev-boun...@eclipse.org 
 [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Jeff McAffer
 Sent: Thursday, December 02, 2010 4:11 PM
 To: Equinox development mailing list
 Subject: Re: [equinox-dev] shell refactoring proposal - Indigo plan deadline
  
 I'm not sure how to deal with the gogo jars in orbit. The jars are real 
 bundles and we will not have to repackage them or anything like that. Jeff 
 what do you recommend?
 
 Orbit is about maintaining bundles for third party code that eclipse projects 
 use. We already have cases where the code is delivered to us as a bundle 
 (ICU, SSH, ...) so this would be just another instance of this.
  
 As for timing, we have to wait for the IP team to approve the CQ but it 
 should be reasonably quick.
 I do not plan to move the console out of the framework. We can provide any 
 changes you need to be able to disable it completely in your environment. I 
 think there are options to do this already.
 
 I guess the trick is if we expect someone running eclipse -console to get the 
 built in one in one case and Gogo in another. What are we expecting the user 
 model to be?
  
 Jeff
  
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo

2010-12-03 Thread Jeff McAffer

Lazar makes a good point that people are used to -console giving them a 
console. Some thoughts

1) Will there be people care what console -console gives them? 

2) Put another way, can we make the assumption that if Gogo is around no one is 
interested in using the built-in console?

3) if -console is still the trigger to make a console appear then -console 
none cannot be used to turn off the old console and turn on gogo.  Would be 
odd for users.

4) if there is another means of turning off the built-in console then we need 
some means of saying when gogo is installed, turn off the other console.  If 
we assume yes to #2 then, for example, some disable.builtin.console property 
could be set in p2 metadata related to Gogo.  This is sort of like how p2 
cohabitates with update.configurator.  We set a property to turn off 
update.configurator's real work.

5) Assuming gogo currently does not look for any command line args (like 
-console) there should be another bundle that looks for -console (whatever) and 
triggers gogo.

Jeff


On 2010-12-03, at 9:50 AM, Kirchev, Lazar wrote:

 I think we already have such an option – specifying “-console none” disables 
 both the discovery of CommandProvider services and ConsoleSession services. 
 The disadvantage is that if “-console none” is used the 
 FrameworkCommandProvider service is not registered. Probably an option 
 whether to register this service or not should be added.
  
 Lazar
  
 From: equinox-dev-boun...@eclipse.org 
 [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson
 Sent: Friday, December 03, 2010 4:07 PM
 To: Equinox development mailing list
 Subject: Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo
  
 There are two things to consider.
 
 1) The equinox console implementation currently discovers the equinox 
 CommandProvider services which provide the set of commands to the equinox 
 osgi console. In a prototype that Lazar has been working on there is a 
 bridge bundle that is able to map equinox CommandProvider services onto gogo 
 commands. It may be necessary to disable the discovery of the CommandProvider 
 services in the built-in framework console when using the gogo shell and 
 equinox bridge bundle on top.
 
 2) Currently the built-in console supports ConsoleSessions being created even 
 if you don't specify the -console option. This allows a ConsoleSession 
 service to be registered which provides the import/output for the equinox 
 console. This is how the eclipse console view is able to establish a console 
 session with the running host framework, even when -console is not used. The 
 bridge bundle Lazar has worked on also is able to discover Equinox 
 ConsoleSessions to provide a connection to the gogo shell. It may also be 
 necessary to disable the discovery of the ConsoleSession services in the 
 built-in framework console when using the gogo shell and equinox bridge 
 bundle on top.
 
 What I am suggesting for 3.7 (Indigo) is to have a configuration option that 
 completely disables these two things in the built-in framework console. It 
 basically makes the built-in framework console deadcode so that we don't have 
 to worry about it interfering with a console/shell bundle on top.
 
 Tom
 
 
 
 image001.gifKirchev, Lazar ---12/03/2010 03:58:32 AM---Technically if the 
 framework is configured with the Gogo bundles to be installed and started, 
 and is run without the –console
 
 image003.png
 From:
 image004.png
 Kirchev, Lazar l.kirc...@sap.com
 image003.png
 To:
 image004.png
 Equinox development mailing list equinox-dev@eclipse.org
 image003.png
 Date:
 image004.png
 12/03/2010 03:58 AM
 image003.png
 Subject:
 image004.png
 Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo
 
 
 
 Technically if the framework is configured with the Gogo bundles to be 
 installed and started, and is run without the –console option, it should work 
 just fine. But users are accustomed to use the -console option. When they 
 eventually start Equinox, configured with Gogo, with the –console option, 
 they will have a framework with two shells, fighting with each other for 
 resources. This may be a problem.
 
 Lazar
 
 From: equinox-dev-boun...@eclipse.org 
 [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Jeff McAffer
 Sent: Friday, December 03, 2010 3:00 AM
 To: Equinox development mailing list
 Subject: Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo
 
 IMHO the bar for Indigo is pretty low. We need to make sure that Gogo can run 
 properly on Equinox. All servicability extension work can be focused on using 
 Gogo. Having a way to disable the current console would be interesting but 
 not essential. Don't want the console? don't put -console on the command 
 line. 
 
 I'm reluctant to put any logic in the framework or launcher to choose between 
 consoles or search for console implementations or... People shipping 
 configurations where they want to use Gogo should

Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo

2010-12-03 Thread Jeff McAffer

 1,2: I do not think that users will prefer the built-in console if Gogo is 
 available, as long as the Equinox commands are available through Gogo.

I tend to agree especially because Gogo is likely better from a user 
perspective.

 5: in the implementation in the patch proposed in 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=169603 such logic is added in 
 EclipseStarter. But currently there are concerns this logic not to be built 
 in the framework.

Actually, now that you point it out, we should likely have this discussion on 
the bug so the information/discussion/decisions are captured there.  I'll 
respond to the #5 point there...

Jeff___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] shell refactoring proposal - Indigo plan deadline

2010-12-02 Thread Jeff McAffer

 I'm not sure how to deal with the gogo jars in orbit. The jars are real 
 bundles and we will not have to repackage them or anything like that. Jeff 
 what do you recommend?
 
Orbit is about maintaining bundles for third party code that eclipse projects 
use. We already have cases where the code is delivered to us as a bundle (ICU, 
SSH, ...) so this would be just another instance of this.

As for timing, we have to wait for the IP team to approve the CQ but it should 
be reasonably quick.
 I do not plan to move the console out of the framework. We can provide any 
 changes you need to be able to disable it completely in your environment. I 
 think there are options to do this already.
 
I guess the trick is if we expect someone running eclipse -console to get the 
built in one in one case and Gogo in another. What are we expecting the user 
model to be?

Jeff

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo

2010-12-02 Thread Jeff McAffer

The disadvantage is usability.  Right now you get equinox and run with -console 
and its all good.  If we break it out you'll have to get two bundles and make 
sure that the console bundle is started...

We have thought about shipping two setups, one with the console and one 
without.  That might work but we need to consider consumer confusion (which one 
do I get, which one do I have, ...) and the work required to setup/maintain the 
build.  

Perhaps the new starter kit direction we've been exploring could offer some 
help...

Anyway, there is a lot of pressure to improve ease of use so we need to keep 
that in mind through these changes.

Jeff
On 2010-12-01, at 6:02 PM, Alex Blewitt wrote:

 On 1 Dec 2010, at 22:06, Thomas Watson wrote:
 
 There have been various discussions about replacing our framework console 
 with something a bit more functional and flexible like apache gogo [1]. At 
 this point in the Indigo release we do not plan to remove our own console 
 for the Indigo release. Instead we will do what ever is required to enable 
 the use of gogo on top of Equinox. We would like to use the incubator to 
 allow this effort to mature and then re-evaluate the complete removal of our 
 built-in framework console in a later release. Lazar Kirchev from SAP has 
 been doing various experiments and investigations in this area. My hope is 
 that Lazar will soon be in a position to contribute this work to the equinox 
 incubator so that others can try it out on top of Indigo.
 
 Tom
 
 [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=317827
 
 One other advantage would be in slimming down Equinox by providing the 
 console in a separate bundle from the main OSGi runtime.
 
 Alex
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo

2010-12-02 Thread Jeff McAffer

IMHO the bar for Indigo is pretty low.  We need to make sure that Gogo can run 
properly on Equinox.  All servicability extension work can be focused on using 
Gogo. Having a way to disable the current console would be interesting but not 
essential.  Don't want the console?  don't put -console on the command line.  

I'm reluctant to put any logic in the framework or launcher to choose between 
consoles or search for console implementations or...  People shipping 
configurations where they want to use Gogo should setup their config to have 
Gogo installed and started.  We may choose in the future to supply such a setup 
from Equinox and there can even be a bundle that looks for a -gogo command line 
arg but that should not be in the framework impl.

So, what do we actually have to do here?

Jeff


On 2010-12-02, at 1:44 PM, Thomas Watson wrote:

 This is the kind of thing I want to address for 3.7 to enable the use of 
 bundles on top of the framework to provide the console. Ideally this would 
 involve a way to configure the framework so that the -console option just did 
 what you need to get your bundles started as well as completely disabling the 
 console support built into the framework. I think that is part of the 
 solution proposed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=169603
 
 Tom
 
 
 
 graycol.gifKirchev, Lazar ---12/02/2010 10:52:30 AM---For the extraction 
 of the console in a separate bundle there is a bug opened: 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=169
 
 ecblank.gif
 From: ecblank.gif
 Kirchev, Lazar l.kirc...@sap.com
 ecblank.gif
 To:   ecblank.gif
 Equinox development mailing list equinox-dev@eclipse.org
 ecblank.gif
 Date: ecblank.gif
 12/02/2010 10:52 AM
 ecblank.gif
 Subject:  ecblank.gif
 Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo
 
 
 
 For the extraction of the console in a separate bundle there is a bug opened:
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=169603
 and a patch is provided there. 
 
 One of the reasons for considering the moving of the console out of the 
 framework is that adding new features to the console while it is in the 
 framework will increase the size of the framework. The current built-in 
 console lacks telnet supportability features for example. Now if the console 
 stays in the framework, it will not include such features. But such 
 supportability features also improve usability. Probably we should provide 
 them as an optional bundle - anyone who needs them to install this bundle? 
 What I have prepared for the incubator is meant to run as a Gogo command, but 
 it easily may be changed to support both cases – as a Gogo command, and the 
 ConsoleSession interface available since 3.6.
 
 Also, currently the only way to run Gogo on top of Equinox is to start 
 Equinox without the –console option, and make Gogo bundles initially started. 
 So it is not possible to pass –console and start either one, or the other. 
 Probably add an option to specify the console jar/jars, if a console 
 different from the built-in should be started?
 
 Lazar
 
 
 
 From: equinox-dev-boun...@eclipse.org 
 [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson
 Sent: Thursday, December 02, 2010 5:50 PM
 To: Equinox development mailing list
 Subject: Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo
 We also must consider the amount of work it would take to extract the console 
 out and test it properly. I am reluctant to do any of that work when we want 
 to eventually replace the console implementation with the gogo shell and a 
 bundle that bridges the old equinox command implementations to the new shell.
 
 Tom
 
 
 
 graycol.gifJeff McAffer ---12/02/2010 09:37:45 AM---The disadvantage is 
 usability. Right now you get equinox and run with -console and its all good. 
 If we break it out you'll ha
 
 34743407.jpg
 From: 34519726.jpg
 Jeff McAffer j...@eclipsesource.com
 34743407.jpg
 To:   34519726.jpg
 Equinox development mailing list equinox-dev@eclipse.org
 34743407.jpg
 Date: 34519726.jpg
 12/02/2010 09:37 AM
 34743407.jpg
 Subject:  34519726.jpg
 Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo
 
 
 
 
 The disadvantage is usability. Right now you get equinox and run with 
 -console and its all good. If we break it out you'll have to get two bundles 
 and make sure that the console bundle is started...
 
 We have thought about shipping two setups, one with the console and one 
 without. That might work but we need to consider consumer confusion (which 
 one do I get, which one do I have, ...) and the work required to 
 setup/maintain the build. 
 
 Perhaps the new starter kit direction we've been exploring could offer some 
 help...
 
 Anyway, there is a lot of pressure to improve ease of use so we need to keep 
 that in mind through these changes.
 
 Jeff 
 
 On 2010-12-01, at 6:02 PM, Alex Blewitt wrote:
 On 1 Dec 2010, at 22:06, Thomas Watson wrote

Re: [equinox-dev] How to best simulate standalone Equinox deployment in Eclipse

2010-11-19 Thread Jeff McAffer

Hey Robert, 

I think we need some more information here.  You should not have to mess with 
the system packages settings etc.  I've been using javax and org.xml etc for 
years and have never had to do this.  What Alex says may be required in cases 
where you are going for internal/private JRE classes (e.g., com.sun) but the 
system bundle exports all these packages for you so all you have to do is 
import the packages in your bundles.  This is the way the OSGi spec expects 
things to work.  That is, you should Import-Package for all packages you need 
other than java.* (which you get for free).  If you do this you should get all 
the right compile errors etc.

Jeff



On 2010-11-19, at 11:53 AM, Robert Krüger wrote:

 
 Hi,
 
 I'm going through the (so far rather painful) process of trying to deploy my 
 OSGI app developed within Eclipse 3.6 in a standalone Equinox environment for 
 the first time.
 
 The two main things I ran into were having to specify javax.* and other 
 packages included in the JavaSE (like org.xml.sax.*) in 
 org.osgi.framework.system.packages and adding Import-Package entries for 
 these in the respective bundles. The former is not too bad as this only has 
 to be done once. However the latter is a bit tedious in the development 
 process if I always have to go through the export, run, change in IDE, rerun 
 cycle.
 
 How is this done best, from a productivity point of view? Is there a way to 
 configure an eclipse OSGI run configuration in such a way that it behaves 
 like the standalone environment, i.e. throws Exceptions/Errors on classes not 
 imported or even better have the compiler mark this as an error? How does the 
 fact that I have Bundle-RequiredExecutionEnvironment: JavaSE-1.6 specified 
 for all bundles affect all this? What do I have to do to be able to test this 
 realistically within Eclipse?
 
 Thanks in advance for sharing any hints in this matter.
 
 Regards,
 
 Robert   
 
 
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] core features

2010-10-19 Thread Jeff McAffer

In an effort to create some starter kits for Equinox and p2 I created some 
core features to capture the essential elements of equinox and p2 in various 
headless scenarios. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=314486 
Of course no feature will cover all use cases but these seem to be useful in 
things like the starter kit and Toast as well as a proposed PDE Build and 
Basebuilder products.

Please take a look and comment on the bug as you see fit.

Jeff



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] new website

2010-10-08 Thread Jeff McAffer

Last night I converted over a mess of the Equinox website to the new format.  I 
tried to get all the popular pages. Please do the following:

- Look at the  site and see if there are any things missing or messed up.  
- Check that the pages of interest to your work have been converted.  If they 
haven't, convert them (see below) or talk to me.

Jeff


How to convert. Basically we just changed how the wrapper is setup and how 
sections are delineated.
- Find a file that is converted.  Say equinox/resources.php
- copy the beginning lines down to the midcolumn line
- replace the first part of the old file with the new beginning. NOTE: you will 
want to preserve the pageTitle and pageKeywords variable settings of the old 
file
- grab the last few lines (EOHTML down) from a new file and replace everything 
after the last /div in the old file.
- save, commit and enjoy

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Website update

2010-10-04 Thread Jeff McAffer

In response to the discussion in today's call, and with the help of DJ, I 
updated the prototype website and download samples as follows

- The website now has a RSS feed view in the right column showing the 5 most 
recent posts found on Planet Eclipse that have the word equinox in them 
somewhere.  We can make this query as complicated as we like.  I started by 
using tags and categories but it seems many people do not tag or categorize 
their posts reliably. This shows up on every equionx related page.

- The download sample (http://eclipse.org/equinox/testweb/somebuild.php) now 
has all the content for a build so you can see the complete picture.

- I used some of DJs previous work in Orbit and made the various sections 
collapsable. I'm not 100% satisfied with how it looks but want it to be clear 
to people that they should expand the section to find more content.  Comments 
and suggestions are welcome

So much for formatting and page structure.  I'd really like to get some input 
on the content for the four buttons at the top as well as the menu entries.

Jeff

The prototype is in the following pages.  Some are linked together but here is 
the full list.
http://eclipse.org/equinox/testweb/
http://eclipse.org/equinox/testweb/resources.php
http://eclipse.org/equinox/testweb/download.php
http://eclipse.org/equinox/testweb/somebuild.php

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Equinox website

2010-10-01 Thread Jeff McAffer

I've been playing a little in my spare time with the Equinox and RT web 
sites.  The prototype web pages are here
http://eclipse.org/equinox/testweb/
http://eclipse.org/equinox/testweb/resources.php
http://eclipse.org/equinox/testweb/download.php
http://eclipse.org/equinox/testweb/somebuild.php
DJ and Kim have been hacking the downloads pages and I took their output and 
tweaked it further to use the Nova look and give an integrated feel with the 
rest of the new site.

Outstanding topics:
- content of the four boxes in the banner (i.e., what should they say/link to)
- What should the menu bar entries be
- interesting links for the right side
- updating things like the getting started guides

Please take a look. We can talk about this in the call on Monday.
Jeff


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] New time for the p2 and equinox calls

2010-09-21 Thread Jeff McAffer

Sigh.  I knew there had to be a ripple in the time/space continuum (or I was 
missing something).  Apparently the latter.  Sorry folks.  Too much mail, not 
enough brain-power.  I can't seem to edit my votes so we'll just have to work 
around the inversion. Basically most times on Tues are good.  Or should I say, 
few times on Tues are bad.

Jeff


On 2010-09-20, at 10:54 AM, John Arthorne wrote:

 
 Pascal requested that we select the times that we are *not* available. So, 
 OK means not available. At least that's how I filled it out, and I 
 suspect the same with Susan. 
 
 
 
 Jeff McAffer j...@eclipsesource.com 
 Sent by: equinox-dev-boun...@eclipse.org
 09/20/2010 10:48 AM
 Please respond to
 Equinox development mailing list equinox-dev@eclipse.org
 
 To
 Equinox development mailing list equinox-dev@eclipse.org
 cc
 P2 developer discussions p2-...@eclipse.org
 Subject
 Re: [equinox-dev] New time for the p2 and equinox calls
 
 
 
 
 
 Thanks for setting up the poll Pascal.  A few things to note 
 
 - The poll closes tomorrow so vote now 
 - Please be careful about the timezones.  I'm not really sure how this works 
 but it seems like Susan is ok with 0600PT calls.  Perhaps she is but it would 
 be worth confirming your votes and the timezone info 
 - there are a number of votes for Wed morning calls.  IMHO opinion this 
 should not be an option.  There are a sequence of PMC (Eclipse and RT) calls 
 and the standing Eclipse Project planning call all Wed morning. Either 
 timezones are messed up or people who need to be on those calls are 
 forgetting something 
 
 Jeff 
 
 
 On 2010-09-16, at 5:33 AM, Pascal Rapicault wrote: 
 
 In order to minimize the numbers of call people have to attend, and given the 
 short duration of the equinox calls, we have decided to give a try a unique 
 p2 and equinox call. If you have any concern with the merge let us know, 
 otherwise please vote to the following poll. 
 
 Be careful the poll is set backward ! You need to provide the time when you 
 are *not* available. 
 http://doodle.com/5agqkufaevtdpfks 
 
 PaScaL 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for Lazar Kirchev on rt.equinox.incubator by Jeff McAffer

2010-06-30 Thread portal on behalf of Jeff McAffer

Jeff McAffer voted:
+1
Great

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] API Addition

2010-04-11 Thread Jeff McAffer

I don't recall a API change proposal or approval for this.  The bug cited does 
have the API keyword but no approvals AFAICT.  Was that done somewhere else?

Jeff


On 2010-04-09, at 8:52 PM, Pascal Rapicault wrote:

 In order to address bug 303990 - metarequirement seems broken, I have had to 
 add two new constants in the IProvisioningAgent INSTALLER_AGENT and 
 INSTALLER_PROFILEID.
 This was a necessity because otherwise the director application was not able 
 to install metarequirements.
 
 PaScaL___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] API Addition

2010-04-11 Thread Jeff McAffer

Great. I did not recall this as one of the approved ones. Would be  
good to note that in the bug for consistency and transparency.


Thanks for the info.

Jeff


On 2010-04-11, at 4:15 PM, Pascal Rapicault pas...@sonatype.com wrote:

During last week team meeting, we went through all the API bugs to  
discuss as a team their relevance, impact, and get a verbal approval  
from the PMC thus streamlining the release of the API for all  
parties involved.
This particular bug was part of this discussion, and it needs to be  
noted that it represents a loss of functionality over what we had in  
the past.


On 2010-04-11, at 2:51 PM, Jeff McAffer wrote:

I don't recall a API change proposal or approval for this.  The bug  
cited does have the API keyword but no approvals AFAICT.  Was that  
done somewhere else?


Jeff


On 2010-04-09, at 8:52 PM, Pascal Rapicault wrote:

In order to address bug 303990 - metarequirement seems broken, I  
have had to add two new constants in the IProvisioningAgent  
INSTALLER_AGENT and INSTALLER_PROFILEID.
This was a necessity because otherwise the director application  
was not able to install metarequirements.


PaScaL___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Re: [p2-dev] who should declare dependencies on ds?

2010-04-03 Thread Jeff McAffer

yes, partially. Features do not allow you ot set start levels, properties and
command line args. So, they are part of the story certainly but products are
the tasty recipe.

Jeff

On 2010-04-03, at 12:29 PM, O'Flynn, Dennis wrote:

In your analog, sounds like the pancakes would be a feature while the eggs
and flour are plug-ins.

(Sent from my Droid)

-Original Message-
From: Neil Bartlett [njbartl...@gmail.com]
Received: 4/2/10 6:51 PM
To: Equinox development mailing list [equinox-...@eclipse.org]
CC: P2 developer discussions [p2-...@eclipse.org]
Subject: Re: [equinox-dev] Re: [p2-dev] who should declare dependencies on ds?

This is the thing about decoupling bundles with services...

Eggs do not depend on flour; they know nothing about flour. Flour knows
nothing about eggs. We need some kind of knowledge that lives outside of the
ingredients -- i.e., a recipe -- in order to make pancakes.

Rgds,
Neil

On Fri, Apr 2, 2010 at 9:57 PM, Jeff McAffer j...@eclipsesource.com wrote:
Good point Jason. I would generalize it even more and say that it is not
just DI but the decoupling that comes with services (or the extension
registry for that matter). We decouple bundles to they don't depend on
specific implementations but then do not have a mechanism for spec'ing that
they actually need an implementation. There is the component definition in DS
etc but p2 or someone else has to read/understand that. The unique thing
about DS is that it is even more removed.

You could say , hey, the bundle has DS markup so it must need DS While that
is likely true in many cases, it is also possible that the same bundle could
be used with and without DS. It may contain other markup for other DI
mechanisms. These have to be dealt with at a higher level as you say.

Jeff

On 2010-04-02, at 4:40 PM, Jason Barkanic wrote:

In general this is a problem with any kind of dependency injection, although
in this case nothing is actually being injected, but it is being set up and
managed by an outside component.

Do you set up a dependency on the dependency injector? How do you best
notify clients that they need the dependency injection framework with your
config, or else they'll have to set things up themselves? It's not even
different implementations of DS, but you could substitute in Blueprint, or
Spring, without changing the API (that is if you don't define API to include
one particular set of bundles over another).

This kind of thing is annoying though (I've been a victim). I'm interested
to see what solutions present themselves as more and more people move to DI
and Services paradigms. I think good error messages can help, since that
might have alleviated your 6 week search in the first place, but that is
easier said than done. The error message could make suggestions about why a
service lookup failed, but it's hard [impossible] to really know.

-Jason

Phil Wrote:
=

I can appreciate the desire to allow different DS implementations but the
bottom line is that DS is going to break any RCP application that uses P2
(there may be other fall out as well). My RCP app uses P2 so I thought that
I should download 3.6M5 so that I had time to make comments about the API
before the API freeze. When I updated not only did my auto update
functionality break, but my build server broke also (PDE build with P2). It
took 6 weeks of googling before I figured out that there was this new DS
bundle that I not only had to include, but I also had to be responsible for
starting.

All is well for me now, but I fear that this change is going to have a big
impact when 3.6 releases. At a minimum this needs to be documented probably
both in What's New in the Plug-In Development Environment Guide and also
in the 3.6 Plug-in Migration Guide. Getting the rcpupdate example updated
(bug 307558) was a good step in the right direction.

Thanks,
Phil

On Thu, Apr 1, 2010 at 1:50 PM, Thomas Watson tjwat...@us.ibm.com wrote:
Note that Equinox does have the ability to declare non-code dependencies in
bundle manifests. See Eclipse-GenericCapability and Eclipse-GenericRequire
headers at:

http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html

This could be used by the DS implementation to declare a DS runtime
capability and bundles defining DS components could declare a requirement on
the DS runtime capability. But this mechanism only describes resolve time
dependencies. It still would not solve Jeff's other concerns about the need
to have DS active in order to truly work. Also note that p2 meta-data
currently does not reflect the generic capabilities/requirements declared in
a bundle manifest so even if we specified these today I don't

Re: [equinox-dev] Re: [p2-dev] who should declare dependencies on ds?

2010-04-02 Thread Jeff McAffer

Phil, I am completely sympathetic with your case and, BTW, thanks for adopting
p2 early. Your suggestion for more doc makes sense. There should likely be a
big get and start DS topic in several places. Could you enter a bug for that?
Likely in Equinox/Compendium area of bugzilla.

For completeness, this is not an issue specific to p2 rather whoever uses DS.
It happens that p2 is one of those parties. I don't know who all uses DS but it
has been part of the RCP feature since 3.5 at least. If your app is
includes/depends on the RCP feature then you should get DS with no additional
action. This was really my point. It should be up to higher level constructs to
say hey, to support this scenario, we are going to put together these bundles
and That is what we did in the RCP feature. In light of that, it would
not be unreasonable to say that the p2 features should spec a dependency on the
DS bundle. If that were to happen, I would use require not include to allow
for flexibility in the underlying deployment.

Note that DS still needs to be started (and typically with a low start level).
I recall last year lots of discussion around having PDE do this automatically
for people but do not remember the outcome of that.

Jeff

On 2010-04-02, at 9:58 AM, Phil Borlin wrote:

Thanks,
Phil

On Thu, Apr 1, 2010 at 11:50 AM, Thomas Watson tjwat...@us.ibm.com wrote:
Note that Equinox does have the ability to declare non-code dependencies in
bundle manifests. See Eclipse-GenericCapability and Eclipse-GenericRequire
headers at:

http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html

Also note that the OSGi alliance is currently looking at providing a standard
way for declaring generic capabilities and requirements for a future core
specification. We should keep an eye on this space and feed any additional
requirements we may have to OSGi in this area.

Tom

graycol.gifJeff McAffer ---04/01/2010 11:46:32 AM---It should be up to the
system integrator. Actually, there should be metadata (in p2) that expresses
the need for various servic

ecblank.gif
From: ecblank.gif
Jeff McAffer j...@eclipsesource.com
ecblank.gif
To: ecblank.gif
P2 developer discussions p2-...@eclipse.org
ecblank.gif
Cc: ecblank.gif
Equinox development mailing list equinox-dev@eclipse.org
ecblank.gif
Date: ecblank.gif
04/01/2010 11:46 AM
ecblank.gif
Subject: ecblank.gif
[equinox-dev] Re: [p2-dev] who should declare dependencies on ds?

It should be up to the system integrator. Actually, there should be metadata
(in p2) that expresses the need for various services to be present to make
the integrator's job easier but ultimately inclusion/activation/... are in
the eye of the beholder. So we should not cod classpath (bundle or package)
dependencies, rather we need more markup in p2 metadata to capture these
non-classpath-related dependencies.

More detail: In this case you could declare a package dependency on the ds
package but that will only get you the interfaces and not the implementation.
The producer could similarly declare a bundle dependency on the Equinox ds
bundle. This is short sighted as there are other DS implementations. Various
p2 features could include the Equinox DS bundle. This is better

Re: [equinox-dev] Re: [p2-dev] who should declare dependencies on ds?

2010-04-02 Thread Jeff McAffer

Good point Jason. I would generalize it even more and say that it is not just
DI but the decoupling that comes with services (or the extension registry for
that matter). We decouple bundles to they don't depend on specific
implementations but then do not have a mechanism for spec'ing that they
actually need an implementation. There is the component definition in DS etc
but p2 or someone else has to read/understand that. The unique thing about DS
is that it is even more removed.

You could say , hey, the bundle has DS markup so it must need DS While that
is likely true in many cases, it is also possible that the same bundle could be
used with and without DS. It may contain other markup for other DI mechanisms.
These have to be dealt with at a higher level as you say.

Jeff

On 2010-04-02, at 4:40 PM, Jason Barkanic wrote:

In general this is a problem with any kind of dependency injection, although
in this case nothing is actually being injected, but it is being set up and
managed by an outside component.

-Jason

Phil Wrote:
=

Thanks,
Phil

http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html

Tom

Jeff McAffer ---04/01/2010 11:46:32 AM---It should be up to the system
integrator. Actually, there should be metadata (in p2) that expresses the
need for various servic

From:
Jeff McAffer j...@eclipsesource.com

To:
P2 developer discussions p2-...@eclipse.org

Cc:
Equinox development mailing list equinox-dev@eclipse.org

Date:
04/01/2010 11:46 AM

Subject:
[equinox-dev] Re: [p2-dev] who should declare dependencies on ds?

It should be up to the system integrator. Actually, there should be metadata
(in p2) that expresses the need for various services to be present to make

[equinox-dev] Re: [p2-dev] who should declare dependencies on ds?

2010-04-01 Thread Jeff McAffer

It should be up to the system integrator. Actually, there should be metadata 
(in p2) that expresses the need for various services to be present to make the 
integrator's job easier but ultimately inclusion/activation/... are in the eye 
of the beholder. So we should not cod classpath (bundle or package) 
dependencies, rather we need more markup in p2 metadata to capture these 
non-classpath-related dependencies.

More detail: In this case you could declare a package dependency on the ds 
package but that will only get you the interfaces and not the implementation.  
The producer could similarly declare a bundle dependency on the Equinox ds 
bundle. This is short sighted as there are other DS implementations.  Various 
p2 features could include the Equinox DS bundle.  This is better but suffers 
from the same problem--that feature would not be usable with other DS 
implementations.

Note that the problem is a friend of the HTTP service, Help system and myriad 
of other situations where people need a service to be there but there is no 
clear declaration of that dependency. 

Note also that simply having DS there is not enough.  It needs to be started. 
This is a product/launch level concern (i.e., the DS bundle can/should not say 
that it should always be started).

So, unless the p2/ds problem is burning, it would be better to address the 
underlying issue than ad hoc addressing of the symptoms.

Jeff

On 2010-04-01, at 12:21 PM, Susan Franklin McCourt wrote:

 We currently use ds in p2 to declare most of our services.
 Yet we don't have any particular bundle that declares a dependency on ds.
 
 I can justify this in some respects - theoretically there could be clients 
 that consume the p2 bundles, declare their own services (using ds or 
 dynamically) and thus don't care about getting the default service 
 registrations. However this is not typical usage. Most people would expect to 
 get the ds-declared services, and right now they only get cryptic errors or 
 failed launches if they aren't using our features or product files and don't 
 know to include ds.
 
 For example, in a recent bug [1] , someone was getting a confusing error 
 because we forgot to include ds in the .product file for an example. We fixed 
 it by including ds in the product file. 
 
 My question is - is this the right fix? 
 It feels a little strange that a consumer that doesn't declare any services 
 with ds still has to know that the bundles it is using declare their services 
 this way.
 Is it intentionally left up to the configurer of the system to ensure ds is 
 included in the running target? Or should the bundles that declare services 
 with ds be requiring the ds bundle?
 
 susan
 
 [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=307558
 
 ___
 p2-dev mailing list
 p2-...@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/p2-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Re: [PLEASE READ] API changes MUST be approved by PMC BEFORE releasing

2010-03-30 Thread Jeff McAffer

Great points Tom.  We discussed this again in the Equinox team call this 
morning.

The need to talk openly about API changes is two-fold:
1) The community needs to be aware of what is coming or proposed.  We need 
their feedback and input. Perhaps they are depending heavily on something that 
is about to change? Perhaps they really need the change?  We need to know.

2) Sober second thought. Writing out the API change request message gives you a 
moment to think about the changes, are they really needed, how will they affect 
people, who is benefitting and how, ... By seeking approval from the broader 
community and project leadership you get constructive feedback on the ideas and 
perhaps a broader perspective.

So to that end, please

1) read Tom's guidelines below 

2) review any open bugs that have the api keyword and is for 3.6. If it is 
still valid, write up a API change request message outlining the risks etc. See 
http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg01009.html for an example 
of a clearly stated/structured change request.  The message should be sent to 
the equinox-dev or p2-dev list as appropriate.

If the bug is no longer valid or is to be deferred, either remove the keyword 
or change the milestone to something not related to 3.6. 

Thanks

Jeff/Tom

On 2010-03-24, at 1:12 PM, Thomas Watson wrote:

 I sent a similar note out on Monday on this same topic. We must have PMC 
 approval for all API changes that go in after API freeze. There is an API 
 freeze for a reason. The community needs to stabilize on our M6 (API freeze) 
 build. Any API changes at all (even additions) need to be carefully 
 considered and if at all possible deferred until the next release. Any API 
 changes this late in the cycle can be very disruptive to our a adopters and 
 consumers.
 
 If API changes are a must then please ensure the following steps are taken.
 
 1) Post a message to p2-dev mailing list describing the API change, its 
 benefits and and the potential risks (who it breaks, any known clients etc.). 
 If it turns out that the are already a number of clients of the API that is 
 changing within Helios or with in the Eclipse community then we likely need 
 to avoid the change. Any changes that could break a client also must be 
 posted to the cross-project mailing list to make the community aware of the 
 breaking change.
 
 2) Make sure a bug is open to track the API change.
 
 3) Ask for PMC approval on the bug. This is done in a similar way to asking 
 for a patch review on the bug report. There is a section to ask for PMC 
 approval. You must get a +1 from Jeff or myself before releasing the change 
 to CVS.
 
 Please speak up if you have any questions or doubts at all.
 
 Tom
 
 ___
 p2-dev mailing list
 p2-...@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/p2-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] shell refactoring proposal

2010-03-30 Thread Jeff McAffer

Krassi, 

This is great.  I've been wanting the console out of the framework for some 
time.  See Bug 169603.

Having a better, more functional console that has a better command UI structure 
would be a real bonus to many users.

As you observe, maintaining compatibility with the old way is essential both 
for contributors and users/doc.

I look forward to this work.  Thanks for coming forward.

Jeff


On 2010-03-30, at 6:20 PM, Semerdzhiev, Krasimir wrote:

 Hi,
  
 This is a short summary of an activity we believe fits to the current point 
 in time and the direction of the project. Any input on that is highly 
 appreciated.
  
 Krassi
  
 Introduction
 We’d like to propose an incubation activity under the Eclipse Equinox 
 umbrella which to result in a RFC147 compliant implementation of a shell in 
 equinox. Furthermore it will result in better separation of the shell 
 functionality from the main equinox framework, leaving only single required 
 functional parts in the framework itself. In addition to that we aim at 
 enhancing the standard set of commands for analyzing dependency and class 
 loading issues within Equinox.
 RCF147 is complementary to the just-released OSGi 4.2 specification and 
 defines a standard way to implement and run commands on an OSGi 4.2 
 framework. Its main qualities span in the direction of ease of use, 
 interactivity and ease of implementation and testing of provided commands.
  Scope
 Provide an RFC147 compliant shell in equinox
 Replace the current equinox console with a well componentized one
 Maintain compatibility with the currently existing Equinox APIs for 
 registering commands. Those are deeply embedded in the framework and must 
 remain available.
 Improve the experience of troubleshooting bundle issues when using Equinox. 
 Focus on wiring, bundle resolution, class loading, etc. by providing 
 additional commands with in-depth understanding of the framework 
 implementation.
 Timeframe
 Aim for Eclipse 3.7 (2011) release and start there early in order to avoid 
 intersection with other on-going development plans
 Define a branch with a fork of Equinox sources in order to achieve easy 
 merging back into the main line once development is completed and accepted
  
  
  
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] How to recognize Categories, Features, Bundles and Products?

2009-09-19 Thread Jeff McAffer

Perhaps some information on why you are doing this would help.  It  
seems that you are infering some semantics from things that just  
*happen* to be a certain way. This may change in the future so  
understanding what you are actually looking for would help.


Jeff



On 18-Sep-09, at 5:53 AM, Filip Hrbek wrote:


Hi all,

I have difficulties with IU analysis. I wonder what determines the  
type of an IU.


Basically we can analyze following properties:

1) does ID end with .feature.group or not?
2) is org.eclipse.equinox.p2.type.category set to true?
3) is org.eclipse.equinox.p2.type.group set to true?

My guess is that this we could use following algorithm:

 
if 
(true 
.equalsIgnoreCase 
(iu.getProperty(IInstallableUnit.PROP_TYPE_CATEGORY))) {
 
if 
(true 
.equalsIgnoreCase(iu.getProperty(IInstallableUnit.PROP_TYPE_GROUP)))

return NESTED_CATEGORY;
else
return CATEGORY;
}
 
if 
(true 
.equalsIgnoreCase(iu.getProperty(IInstallableUnit.PROP_TYPE_GROUP)))

return PRODUCT;
if(iu.getId().endsWith(.feature.group))
return FEATURE;
if(iu.isFragment())
return FRAGMENT;
if(iu.isBundle())
return BUNDLE;
return OTHER;

You may have noticed that I also used two category variants - normal  
and nested. This is an attempt to handle cases such as http://download.eclipse.org/releases/galileo 
 | General Purpose Tools | PDE/API Tools Environment Descriptions.


The algorithm looks fairly complicated. Is there any standard method  
for this in p2 code? If not, is my suggestion correct?


Thanks,

Filip

--
Filip Hrbek  |  filip.hr...@cloudsmith.com  |  +420.777.662642  |   
skype: filip.hrbek

CLOUDSMITH  |  Czech Republic
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Fwd: [eclipse-pmc] Project proposal on application security

2009-08-04 Thread Jeff McAffer


FYI, there is a security related thread starting on eclipse-pmc

Begin forwarded message:


Eclipse PMC,

My name is Arshan and I'd like Eclipse to enable developers to write  
more secure code. I'm working with the OWASP foundation and have  
elicited funds to accomplish the introduction of security into key  
points in the technology stack with security analysis of application  
server frameworks, vendor outreach programs, and more. I'm writing  
to ask you, however, about introducing security into your IDE (which  
happens to be my favorite IDE).


The IDE is a very effective place for security to go since it will  
necessarily catch problems earlier in the lifecycle than would
security checks in other places. There a host of issues the JDT can  
easily detect while developers are writing code, including:


* Injection attacks (cross-site scripting, command injection,  
SQL injection, XPath/XML injection, etc.)

* Information leakage
* Cryptographic weakness
* ...and many more!

While a 3rd party plugin could technically perform these checks,  
having them in the IDE would greatly legitimize security in  
developers' eyes, since most view security problems as theoretical  
or bothersome. And the momentum is growing; it's not just the banks  
that are taking application security seriously anymore - the world  
is starting recognize that applications are part of your security  
perimeter. In fact, we recently spoke at JavaOne about some specific  
security flaws the J2EE world is continually producing.


Other IDEs are getting into the game as well. Visual Studio invested  
in CAT.NET, a tool used to help MS developers find security problems  
and IBM recently bought Ounce, a static analysis tool for finding  
security flaws. I do penetration testing, code review and security  
research for a living. The problems are out there in staggering  
numbers, and its only getting worse. Frankly, developers will keep  
re-introducing problems as long as the IDE lets them.


I'm proposing we create an Eclipse sub-project or extend a piece of  
the existing Eclipse base to allow users to enable security guidance  
with customizable levels of interaction. As budget allows we are  
prepared to take on the necessary expenses for implementing these  
features, but the commitment to developing more secure code can only  
come from your organization.


We are very flexible on the logistical details and are mostly eager  
to start a conversation around application security and Eclipse.


Thanks for your time,

Arshan Dabirsiaghi
Director of RD
Aspect Security
http://www.aspectsecurity.com
O: (301) 604-4882
C: (443) 791-5355

Project Lead
Intrinsic Security Working Group
Open Web Application Security Project (OWASP)
http://owasp.org

___
eclipse-pmc mailing list
eclipse-...@eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Autostarting Bundles

2009-04-18 Thread Jeff McAffer





BTW, it turns out that you have to have simple.configurator there AND
marked as started for the configuration you are creating to be
considered "p2 enabled" and the bundles.info file to be written.Â  The
bundles.info file may be written in other cases (I seem to have seen
that).


Jeff


Chris Aniszczyk wrote:
On Thu, Apr 16, 2009 at 8:35 AM, O'Flynn, Dennis dennis.ofl...@compuware.com
wrote:
  
  



Chris, 

FYI - I
tried using the product defân editor to set the bundles
start levels.Â  I had a problem when using the âdefaultâ start level.Â 
It set
the entry in the config.ini to â...@0â.Â  This caused an error when
starting the
server-side Eclipse environment.Â  Once I changed these to a specific
start
level (â...@4â), everything did work.
BTW â I
was surprised that bundles marked for started were defined
via âosgi.bundlesâ, instead of setting CUâs to update the bundle.info.



  
  
  
You're on the bleeding edge a bit Dennis. I fixed that issue yesterday:
272361: don't write out 0 for start levels
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=272361
  
If you don't included simpleconfigurator in your product, everything
will be on the osgi.bundles property. If you include
simpleconfigurator, PDE should use it.
  
Let me know if we can help, we have had great success using product
definitions to manage server side applications.
  
Cheers,
  
-- 
Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
  http://twitter.com/eclipsesource
| http://twitter.com/caniszczyk
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Using Equinox Declarative services in another OSGI framework

2009-04-03 Thread Jeff McAffer





Not sure if you did already but a bug report here would be useful.
Anything that makes stuff easier to use is a good thing.

Jeff


Alin Dreghiciu wrote:

  Thanx Stuart.
That resolved the import problem so now DS is up and running (using
the supplement bundle).
In this case, as debug stuff is not so important and can work without
debug stuff based on system params I would rather make the imports
optional then having to bring in just another bundle to make it
resolve. Even more in this case as the DebugOptions service is not
there the supplement bundle is not of any use beside exporting the
debug package. So, if I have the supplement bundle in I would expect
that the supplement bundle is also publishing service implementations
for the services it can, and this supplement bundle just has the
classes (api + some impl) but not use them as there is no bundle
activator.
Could be that this (publish the services) is not possible outside
Equinox system bundle, is that the case?

On Mon, Mar 9, 2009 at 10:05 AM, Stuart McCulloch mccu...@gmail.com wrote:
  
  
2009/3/9 Alin Dreghiciu adreghi...@gmail.com


  Hi Guys,

I was trying to use Declarative Services implementation from equinox
in another OSGi framework and looks like that is not possible.
DS has an import on org.eclipse.osgi.service.debug;version="1.0"
package that I could only find in the Equinox framework itself.
Is it available from somewhere else?
  

Hi Alin,

have you looked in the org.eclipse.equinox.supplement bundle?
I'm using this to run the Eclipse extension point registry on Felix
which also needs that debug import

You can find releases of org.eclipse.equinox.supplement here:

 http://download.eclipse.org/equinox/

just pick from either the 3.4 / 3.5 stream



  If not, can the org.eclipse.osgi.service.debug be made available at
least as a separate bundle, even better together with DebugOptions
impl?

Another simpler option would be to make this import optional and
handle the fact that package is not available in the DS Activator,
case when DS can work as in case that no DebugOptions service is
available = using system properties.

Thanx,
--
Alin Dreghiciu
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
http://www.codedragons.com - New Energy for Projects - Great People
working on Great Projects at Great Places
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  

--
Cheers, Stuart

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



  
  


  



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Request to remove Constants#SERVICE_TYPE constant

2009-03-30 Thread Jeff McAffer





+1

Thomas Watson wrote:

  Hello fellow Equinox team. In the past Equinox was under the
Eclipse PMC and we needed to get PMC approval for post M6 API changes.
Now that we are under RT Jeff and I decided that it would be best to
keep the Equinox API change approvals localized to the Equinox dev
list. Here is my first API change request for Galileo (hopefully will
not need any more this release).
  
I am CC'ing the eclipse PMC for their awareness.
  
GOALS/BENEFITS:
  
org.osgi.framework.Constants is an interface of constants for
the OSGi framework. This API is defined by the OSGi
Alliance. Several new constants have been added during
the coarse of the OSGi R4.2 specification process which is 
being implemented in the Galileo release of Equinox. The
SERVICE_TYPE is a new constant that was introduce during
the R4.2 specification process. It has since been decided
that the constant is not needed and should be removed.
  
In Equinox we must align with the final OSGi API as 
defined by the OSGi Alliance.
  
  
ASSOCIATED BUGS:
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=270511
  
RISKS:
Low. These are new constants introduced by OSGi during the 3.5 cycle. 
The constant is consumed by ECF (RFC 119 impl), but they are
willing to make the change as well. There are currently no other
known adopters.
  
PERFORMANCE IMPACT:
None.
  
  
Tom
  
  
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Declarative Services within RCP Application

2009-02-08 Thread Jeff McAffer





note as well that there are some DS console commands like "ls" and
"component" that are quite usefule.

Jeff
    

Neil Bartlett wrote:

  Okay this looks fine, both the equinox.ds and equinox.util bundles are
present and active.

Which bundles contain the two DS components you're expecting to see,
and what is the output of the "services" command in the OSGi console?

Regards
Neil

On Fri, Feb 6, 2009 at 11:38 PM, Mitra, Priyanka
priyanka.mi...@etrade.com wrote:
  
  
Neil, I am able to get the osgi console while running the RCP App. Here is the output.

osgi ss

Framework is launched.

id  State   Bundle
0   ACTIVE  org.eclipse.osgi_3.4.2.R34x_v20080826-1230
   Fragments=6
1   ACTIVE  org.eclipse.osgi.services_3.1.200.v20071203
2   ACTIVE  org.eclipse.equinox.ds_1.0.0.v20080427-0830
3   RESOLVEDorg.eclipse.core.runtime.compatibility.registry_3.2.200.v20080610
   Master=15
4   ACTIVE  org.eclipse.ui.workbench_3.4.1.M20080827-0800a
5   ACTIVE  tops.order.trade.mgmt_1.0.0
6   RESOLVEDorg.eclipse.equinox.transforms.hook_1.0.0.v20080610
   Master=0
7   ACTIVE  com.etrade.tops.container_1.0.0
8   ACTIVE  org.eclipse.core.jobs_3.4.0.v20080512
9   ACTIVE  org.eclipse.swt_3.4.1.v3449c
   Fragments=26
10  ACTIVE  org.eclipse.core.databinding_1.1.1.M20080827-0800b
11  ACTIVE  org.eclipse.core.contenttype_3.3.0.v20080604-1400
12  ACTIVE  com.ibm.icu_3.8.1.v20080530
13  ACTIVE  org.eclipse.core.commands_3.4.0.I20080509-2000
14  ACTIVE  JMSImporter_1.0.0
15  ACTIVE  org.eclipse.equinox.registry_3.4.0.v20080516-0950
   Fragments=3
16  ACTIVE  org.eclipse.core.runtime_3.4.0.v20080512
17  ACTIVE  org.eclipse.equinox.common_3.4.0.v20080421-2006
18  ACTIVE  com.etrade.common3_1.0.0
19  ACTIVE  org.eclipse.core.expressions_3.4.0.v20080603-2000
20  ACTIVE  org.eclipse.ui_3.4.1.M20080910-0800
21  ACTIVE  org.eclipse.equinox.util_1.0.0.v20080414
22  ACTIVE  org.eclipse.core.runtime.compatibility.auth_3.2.100.v20070502
23  ACTIVE  com.etrade.tops.jms_1.0.0
24  ACTIVE  org.eclipse.jface.databinding_1.2.1.M20080827-0800a
25  ACTIVE  org.eclipse.equinox.preferences_3.2.201.R34x_v20080709
26  RESOLVEDorg.eclipse.swt.gtk.linux.x86_3.4.1.v3449c
   Master=9
27  ACTIVE  org.eclipse.jface_3.4.1.M20080827-2000
28  ACTIVE  org.eclipse.equinox.app_1.1.0.v20080421-2006
29  ACTIVE  org.eclipse.help_3.3.101.v20080702_34x
30  ACTIVE  javax.servlet_2.4.0.v200806031604


-Original Message-
From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of equinox-dev-requ...@eclipse.org
Sent: Friday, February 06, 2009 9:01 AM
To: equinox-dev@eclipse.org
Subject: equinox-dev Digest, Vol 46, Issue 7

Send equinox-dev mailing list submissions to
   equinox-dev@eclipse.org

To subscribe or unsubscribe via the World Wide Web, visit
   https://dev.eclipse.org/mailman/listinfo/equinox-dev
or, via email, send a message with subject or body 'help' to
   equinox-dev-requ...@eclipse.org

You can reach the person managing the list at
   equinox-dev-ow...@eclipse.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of equinox-dev digest..."


Today's Topics:

  1. Re: Declarative Services within RCP Applications (Neil Bartlett)
  2. Handling errors in the equinox (Krzysztof Daniel)


--

Message: 1
Date: Fri, 6 Feb 2009 11:49:33 +
From: Neil Bartlett njbartl...@gmail.com
Subject: Re: [equinox-dev] Declarative Services within RCP
   Applications
To: Equinox development mailing list equinox-dev@eclipse.org
Message-ID:
   bb4674270902060349l5aa6d4adl50588815b584a...@mail.gmail.com
Content-Type: text/plain; charset=UTF-8

Well spotted Dennis. However the dependency on util is not indirect, it is a straightforward direct dependency. And util does not need to be started, it just needs to be present and resolved.

Priyanka, could you show us the output of the "ss" command in the OSGi console?

Note that in general, integrating Eclipse Extensions and OSGi Services (whether DS or otherwise) is a hard problem because of the lifecycle mismatch and the semantic differences between extensions and services.

Regards,
Neil

On Fri, Feb 6, 2009 at 11:23 AM, O'Flynn, Dennis dennis.ofl...@compuware.com wrote:


  I'm under the assumption that equinox.ds has an indirect dependency upon equinox.util.  Try starting equinox.util before equinos.ds.

I use the following startup order in my RCP app's config.ini:

osgi.bundles=...\
  org.eclipse.equinox.u...@2:start, \
  org.eclipse.equinox...@2:start, \
  ...



The contents of this e-mail are intended

Re: [equinox-dev] bundle resource URLs format has changed

2009-01-28 Thread Jeff McAffer





Thanks for bringing this up. The information should be broadcast quite
widely. I'm sure there are folks consuming Equinox that will be
affected.
Should likely also be in release notes etc.

Jeff

Thomas Watson wrote:

  The failure in org.eclipse.core.tests.runtime
(org.eclipse.core.tests.internal.runtime.FileLocatorTest.testFileLocatorFind)
is a result of the fix to bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=252303
  
In this bug we changed the format of the bundle resource URLs to encode
a framework instance id in the URLs host. The bundle resource URL hosts
used to only include the ID of the bundle where the resource is
located. Now the host includes a framework instance id encoded in the
host (i.e. framewrok id.bundle id). We have always
considered the scheme of the bundle resource URLs to be internal. The
scheme is not specified by OSGi and the external format of the bundle
resource URLs cannot be depended on from one framework to another
framework implementation.
  
I opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=262376
to fix the runtime tests. I am bringing this issue up to the community
because others may have been making assumptions on the format of the
bundle resource URLs. Let the Equinox team know if you find any other
issues with this change.
  
Thanks.
  
Tom
  
  
  
  eclipse-releng---01/26/2009
03:17:05 AM---Build I20090125-2000 (Timestamp: 200901252000): Automated
JUnit testing is complete. Test failures/errors occurred in the fol
  
  

  

From:

eclipse-rel...@eclipse.org
  
  

To:

platform-releng-...@eclipse.org
  
  

Date:

01/26/2009 03:17 AM
  
  

Subject:

[platform-releng-dev] [eclipse-build]Build
I20090125-2000 (Timestamp: 200901252000):Automated JUnit testing
complete. Test failures/errors occurred.
  

  
  
  
  
  
  Build I20090125-2000 (Timestamp: 200901252000): Automated JUnit
testing is complete. Test failures/errors occurred in the following: 
  
org.eclipse.ant.tests.core_linux.gtk.x86
org.eclipse.ant.tests.core_linux.gtk.x86_6.0
org.eclipse.ant.tests.core_macosx.carbon.ppc_5.0
org.eclipse.ant.tests.core_win32.win32.x86
org.eclipse.ant.tests.core_win32.win32.x86_6.0
org.eclipse.ant.tests.ui_linux.gtk.x86
org.eclipse.ant.tests.ui_linux.gtk.x86_6.0
org.eclipse.ant.tests.ui_macosx.carbon.ppc_5.0
org.eclipse.ant.tests.ui_win32.win32.x86
org.eclipse.ant.tests.ui_win32.win32.x86_6.0
org.eclipse.core.tests.runtime_linux.gtk.x86
org.eclipse.core.tests.runtime_linux.gtk.x86_6.0
org.eclipse.core.tests.runtime_macosx.carbon.ppc_5.0
org.eclipse.core.tests.runtime_win32.win32.x86
org.eclipse.core.tests.runtime_win32.win32.x86_6.0
org.eclipse.equinox.p2.tests_linux.gtk.x86
org.eclipse.equinox.p2.tests_linux.gtk.x86_6.0
org.eclipse.equinox.p2.tests_macosx.carbon.ppc_5.0
org.eclipse.equinox.p2.tests_win32.win32.x86
org.eclipse.equinox.p2.tests_win32.win32.x86_6.0
org.eclipse.jdt.debug.tests_linux.gtk.x86
org.eclipse.jdt.debug.tests_linux.gtk.x86_6.0
org.eclipse.jdt.debug.tests_macosx.carbon.ppc_5.0
org.eclipse.jdt.debug.tests_win32.win32.x86
org.eclipse.jdt.debug.tests_win32.win32.x86_6.0
org.eclipse.pde.ui.tests_macosx.carbon.ppc_5.0
org.eclipse.releng.tests_linux.gtk.x86
org.eclipse.releng.tests_linux.gtk.x86_6.0
org.eclipse.releng.tests_macosx.carbon.ppc_5.0
org.eclipse.releng.tests_win32.win32.x86
org.eclipse.releng.tests_win32.win32.x86_6.0
org.eclipse.swt.tests_linux.gtk.x86
org.eclipse.swt.tests_linux.gtk.x86_6.0
org.eclipse.ua.tests_linux.gtk.x86
org.eclipse.ua.tests_linux.gtk.x86_6.0
org.eclipse.ua.tests_macosx.carbon.ppc_5.0
org.eclipse.ua.tests_win32.win32.x86
org.eclipse.ua.tests_win32.win32.x86_6.0
org.eclipse.ui.tests.navigator_macosx.carbon.ppc_5.0
  
HTTP Download:
  
  http://download.eclipse.org/eclipse/downloads/drops/I20090125-2000
  
  
___
platform-releng-dev mailing list
platform-releng-...@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/platform-releng-dev
  
  
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] test bundles

2009-01-21 Thread Jeff McAffer

In working through some contributions in the Component area it was noted 
that there is no decent home for Components tests.  The current 
components constituents either have no apparent tests or have them in 
the core.runtime test area in the Eclipse project. Given that Equinox is 
a full-fledged project we should probably have our own set of test 
bundles that are stand alone from downstream projects.


I opened a bug to track this and added it next weeks call agenda.
   https://bugs.eclipse.org/bugs/show_bug.cgi?id=261949

Jeff
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Move the equinox incubator to RT

2009-01-07 Thread Jeff McAffer

I agree that C is the way to go for all th reasons Tom mentioned plus:
The incubator is a distinct "subproject" with distinct commit rights
etc. spreading out the content will be confusing and just asking for
things to "graduate by accident"

The incubator area should be structured according to the work areas
which may or may not correspond to the formal components that we have
in the rest of Equinox.

Jeff

Thomas Watson wrote:

I prefer something similar to option C. This is because we have
examples of work areas that do not fit into any of the existing
graduated categories. For example, the AspectJ stuff. I think it would
be better to have one incubator folder with a different folder
underneath for each workarea.

I am against option B. A flat structure has proven to be confusing and
hard to find what you are looking for. I could be enticed to use option
A if we allow new incubator work areas to have their own folder under
org.eclipse.equinox. For example

org.eclipse.equinox/aspectj/incubator ...

Where org.eclipse.equinox/aspectj would not have any thing except the
incubator folder because nothing has graduated from it yet. Once
something graduates it would move up into the parent "aspectj" folder.
A disadvantage to this approach is that it will pollute the
org.eclipse.equinox/ folder with work areas that may never graduate and
could be abandoned altogether.

Tom

Pascal
Rapicault ---01/07/2009 09:51:57 AM---While this is being done, could
we start talking about the shape of things in this incubator?

From:

Pascal Rapicault
pascal_rapica...@ca.ibm.com

To:

Equinox development mailing list
equinox-dev@eclipse.org

Cc:

equinox-dev@eclipse.org,
equinox-dev-boun...@eclipse.org

Date:

01/07/2009 09:51 AM

Subject:

Re: [equinox-dev] Move the equinox incubator to
RT

While this is being done, could we start talking about
the shape of things in this incubator?
The current structure of the repo is:
org.eclipse.equinox/
framework/
bundles/
p2/
bundles/
[...]

What do we want:
A - one incubator folder under each work are in the repo?
org.eclipse.equinox/
framework/
bundles/
incubator/
p2/
bundles/
incubator/
[...]

B - one incubator and everything flat
org.eclipse.equinox/
incubator/
org.eclipse.equinox.p2.foo.bar
org.eclipse.log.zoo
framework/
bundles/
p2/
bundles/
[...]

C - one incubator with structure reflecting the work areas
org.eclipse.equinox/
incubator/
p2/
org.eclipse.equinox.p2.foo.bar
compendium/
org.eclipse.log.zoo
framework/
bundles/
p2/
bundles/
[...]

Personally I would vote for A.
What do you think?

PaScaL
Thomas Watson
---01/06/2009 05:24:45 PM---We have put this off long enough. As a New
Year's resolution we will finally move the equinox incub

From:

Thomas Watson tjwat...@us.ibm.com

To:

equinox-dev@eclipse.org

Date:

01/06/2009 05:24 PM

Subject:

[equinox-dev] Move the equinox incubator to RT

We have put this off long enough. As a New Year's resolution we will
finally move the equinox incubator to its rightful place under
RT-Equinox. We do not want to just move everything from the old
equinox incubator over to the RT-Equinox because many projects in
the old incubator are outdated and stagnant. We have opened a bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=258483) to determine what bundles from the equinox incubator are
still active and should be moved over to the RT-Equinox repository.

At this time we are looking for folks on the Equinox team and the
community to tell us what project from the incubator are still active.
If you are using or maintaining a project in the equinox incubator then
please chime into the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=258483 and let us know what projects you would like to see migrated
over. Once we have the list of projects determined then we will
finalize the new repository layout for the equinox incubator. We want
to have the list of projects finalized by M5 (end of January).

Tom
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org

Re: [equinox-dev] update site for equinox aspects

2008-11-24 Thread Jeff McAffer

I belive there is an incubator build.  You should be able to define some 
features, add them to that build and have the aspects stuff built all 
the time and put up on the Equinox build site and repo.


Jeff

Martin Lippert wrote:

Hi Andrew,

we don't have one yet, but I will try to figure out what is necessary 
to create one. Technically its not a problem but I am not sure where 
to put it. I will try to figure out.


Cheers,
-Martin


Andrew Eisenberg wrote:

Hi Martin and Heiko,

Do you have or are you planning on creating an update site for 
equinox aspects?

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for John Arthorne

2008-11-16 Thread portal on behalf of Jeff McAffer

+1
The more John can commit to, the better off we are...

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] p2 publisher tests?

2008-10-16 Thread Jeff McAffer





Given that these tests were never included in the build in their old
location, should we just delete the now empty projects from the repo to
eliminate confusion and clutter?

Jeff

DJ Houghton wrote:

  They were moved to be included inside the regular p2 test suites a
couple of weeks ago.
  
  http://dev.eclipse.org/mhonarc/lists/p2-dev/msg00305.html 
  
  
  
  "Chris Aniszczyk"
[EMAIL PROTECTED]
  
  
  

  


  

  
"Chris Aniszczyk"
[EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED]
10/15/2008 12:11 AM

  

  
  Please respond
to
Equinox development mailing list equinox-dev@eclipse.org
  

  


  

  




  

  
  To
  
  
  "Equinox development mailing list"
equinox-dev@eclipse.org


  
  cc
  
  
  


  
  Subject
  
  
  [equinox-dev] p2 publisher tests?

  


  

  
  

  


  

  
  
  Anyone know where they went after the move? This is
what I found so far:
  
  http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/p2/bundles/org.eclipse.equinox.p2.publisher.tests/?root=RT_Project
  http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/p2/bundles/org.eclipse.equinox.p2.tests.publisher/?root=RT_Project
  
Both of those projects are empty in HEAD for me when checking out from
CVS.
  
-- 
Cheers,
  
~ Chris Aniszczyk___
equinox-dev mailing list
equinox-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/equinox-dev
  
  
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] p2 publisher tests?

2008-10-16 Thread Jeff McAffer





Very weird. I just went to open a bug report about this and could not
find the folders in the repo anymore. Perhaps someone deleted them?
Both Chris and saw them yesterday... insert twilight zone music
here


BTW, what is our policy on test bundles. The publisher tests were in a
bundle on their own then that was merged with the p2.tests. Looking at
the repo there are also some p2.tests.optimizers and p2.tests.ui.
Should these be merged as well?

Jeff

Thomas Watson wrote:

  +1
  
For any projects that are dead and have never been included in an
I-Build, we should ask the web master to manually delete the
directories for us.
  
Tom
  
  
  
  Jeff McAffer
---10/16/2008 09:28:41 AM---Given that these tests were never included
in the build in their old location, should we just delete the now empty
projects fro
  
  

  

From:

Jeff McAffer [EMAIL PROTECTED]
  
  

To:

Equinox development mailing list
equinox-dev@eclipse.org
  
  

Date:

10/16/2008 09:28 AM
  
  

Subject:

Re: [equinox-dev] p2 publisher tests?
  

  
  
  
  
  
  Given that these tests were never included in the
build in their old location, should we just delete the now empty
projects from the repo to eliminate confusion and clutter?
  
Jeff
  
DJ Houghton wrote: 
  

  They were moved to be included inside the regular
p2 test suites a couple of weeks ago.
  
  http://dev.eclipse.org/mhonarc/lists/p2-dev/msg00305.html 
  
  
  
  "Chris Aniszczyk" [EMAIL PROTECTED]
  
  
  

  


  

  

  

  
"Chris Aniszczyk" [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 
10/15/2008 12:11 AM 
  

  

  

  


  

  
  Please respond to
Equinox development mailing list equinox-dev@eclipse.org
  

  




  

  
  To
  
  
"Equinox development mailing list" equinox-dev@eclipse.org


  
  cc
  
  


  
  Subject
  
  
[equinox-dev] p2 publisher tests?

  


  

  
  

  


  

  
  
Anyone know where they went after the move? This is what I found so far:
  
  http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/p2/bundles/org.eclipse.equinox.p2.publisher.tests/?root=RT_Project
  http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/p2/bundles/org.eclipse.equinox.p2.tests.publisher/?root=RT_Project
  
Both of those projects are empty in HEAD for me when checking out from
CVS.
  
-- 
Cheers,
  
~ Chris Aniszczyk___
equinox-dev mailing list
  equinox-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/equinox-dev
  
  
  
  
___
equinox-dev mailing list
  equinox-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/equinox-dev
  
  

  
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] org.eclipse.osgi_3.4.2.R34x_v20080826-1230 defines ExecutionEnvironment: J2SE-1.5

2008-10-13 Thread Jeff McAffer

Ah, Assuming we are not using any Java5 language features we need to
set the source and target options to Java 1.3 equivalents.

Jeff

Heiko Seeberger wrote:
Tom,

My issues were based on the VM that was defined for the run
configuration for my test cases. This was not a Java 5 VM and therefore
I had those "UnsupportedClassFileVersionErrors" when org.eclipse.osgi
now was compiled against Java 5. Of course this was easy to solve, thus
there is no need to get busy ...

I was just interested in the reasons for adding Java 5 to the
list of execution environments. Thanx for your information.

Heiko

Am 10.10.2008 um 15:25 schrieb Thomas Watson:

Hi Heiko,

The reason this was added was to avoid compilation errors when
importing org.eclipse.osgi into your workspace as source from the
target SDK. The org.eclipse.osgi project supports the OSGi minimum 1.1
execution environment but will make use of additional classes from J2SE
1.4 and 1.5 if they are available (e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=133048).
When importing the bundle as source from the target SDK it gets
compiled against J2SE 1.5 for convenience (PDE uses the first EE listed
in the BREE as the default VM to compile against).

The org.eclipse.osgi project in CVS contains the OSGi minimum 1.1
execution environment jar plus some additional stubbed classes to
compile against. We wanted to avoid having to ship these stub jars in
order to import org.eclipse.osgi as source and we wanted to avoid
forcing the average developer from finding a minimun execution
environment to compile against.

I am curious why this is causing issues with your test cases. The BREE
header used to list only OSGi/Minimum-1.1. Now it also lists J2SE-1.5.
Semantically there is no difference because OSGi/Minumum-1.1 is a
proper subset of J2SE-1.5. A bundle that states it can run on
OSGi/Minimum-1.1 is also implying that it can run on J2SE-1.3 or higher.

Tom

graycol.gifHeiko
Seeberger ---10/10/2008 03:13:48 AM---Hi,

ecblank.gif
From:
ecblank.gif
Heiko Seeberger [EMAIL PROTECTED]

ecblank.gif
To:
ecblank.gif
Equinox development mailing list equinox-dev@eclipse.org

ecblank.gif
Date:
ecblank.gif
10/10/2008 03:13 AM

ecblank.gif
Subject:
ecblank.gif
[equinox-dev]
org.eclipse.osgi_3.4.2.R34x_v20080826-1230 defines
ExecutionEnvironment: J2SE-1.5

Hi,

After updating to 3.4.1 I had some issues with my test cases for
Equinox Aspects. The reason was, that the latest version of the system
bundle now defines Java 5 as the first execution environment:
Bundle-RequiredExecutionEnvironment: J2SE-1.5,OSGi/Minimum-1.1

Is this by intention? If yes, why?

Heiko

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] org.eclipse.osgi_3.4.2.R34x_v20080826-1230 defines ExecutionEnvironment: J2SE-1.5

2008-10-10 Thread Jeff McAffer

I believe there is a property we can put in the build.properties to
tell PDE which EE to use for compilation purposes. This seems like the
safer and more explicit path regardless of any issues Heiko may be
seeing.

Jeff

Thomas Watson wrote:

Hi Heiko,

Tom

Heiko
Seeberger ---10/10/2008 03:13:48 AM---Hi,

From:

Heiko Seeberger [EMAIL PROTECTED]

To:

Equinox development mailing list
equinox-dev@eclipse.org

Date:

10/10/2008 03:13 AM

Subject:

[equinox-dev]
org.eclipse.osgi_3.4.2.R34x_v20080826-1230 defines
ExecutionEnvironment: J2SE-1.5

Hi,

Is this by intention? If yes, why?

Heiko

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] org.eclipse.osgi_3.4.2.R34x_v20080826-1230 defines ExecutionEnvironment: J2SE-1.5

2008-10-10 Thread Jeff McAffer

sigh. is another option to include the build.properties in the source
and get PDE to use it?

I am more curious than expecting a change here. I agree that it is
unusual that the BREE content/ordering is causing an issue...

Jeff

Thomas Watson wrote:

We use those properties in the build.properties file in CVS to
setup our advanced classpath during the real build. And besides, the
build.properties from the CVS project is not the same as the one used
by PDE when you import as source. In this case PDE generates one for
you based on the contents of your bundle manifest. This is the reason
J2SE-1.5 is listed first, so that PDE will use J2SE-1.5.

Tom

Jeff McAffer
---10/10/2008 09:22:21 AM---I believe there is a property we can put in
the build.properties to tell PDE which EE to use for compilation
purposes. This se

From:

Jeff McAffer [EMAIL PROTECTED]

To:

Equinox development mailing list
equinox-dev@eclipse.org

Date:

10/10/2008 09:22 AM

Subject:

Re: [equinox-dev]
org.eclipse.osgi_3.4.2.R34x_v20080826-1230 defines
ExecutionEnvironment: J2SE-1.5

I believe there is a property we can put in the
build.properties to tell PDE which EE to use for compilation purposes.
This seems like the safer and more explicit path regardless of any
issues Heiko may be seeing.

Jeff

Thomas Watson wrote:

Hi Heiko,

The reason this was added was to avoid compilation errors when
importing org.eclipse.osgi into your workspace as source from the
target SDK. The org.eclipse.osgi project supports the OSGi minimum 1.1
execution environment but will make use of additional classes from J2SE
1.4 and 1.5 if they are available (e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=133048). When importing the bundle as source from the target SDK it
gets compiled against J2SE 1.5 for convenience (PDE uses the first EE
listed in the BREE as the default VM to compile against).

Tom

Heiko Seeberger
---10/10/2008 03:13:48 AM---Hi,

From:

Heiko Seeberger [EMAIL PROTECTED]

To:

Equinox development mailing list equinox-dev@eclipse.org

Date:

10/10/2008 03:13 AM

Subject:

[equinox-dev] org.eclipse.osgi_3.4.2.R34x_v20080826-1230 defines
ExecutionEnvironment: J2SE-1.5

Hi,

Is this by intention? If yes, why?

Heiko

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] listening to bug buckets

2008-09-29 Thread Jeff McAffer

With the recent move and reorg of the Equinox bugzilla buckets, you 
might want to check that your bugzilla account is setup to listen to all 
the new components.  Below is the complete list of inbox users you can 
watch using the Bugzilla  Preferences  email settings.


[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Jeff
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Extension registry evolution

2008-09-29 Thread Jeff McAffer





Oleg Besedin wrote:
= Single context object =
  
  
   I don't like that clients cannot provide more
than just one single
  
   "context" object.
  
  
  Good point. I did this for simplicity as having
only
one argument eliminates the need to match constructor arguments. If we
were to support multiple arguments we'd have to add a new construct to
the extension point schema - something like 
  
  constructor 
  
  argument position
= "1" name = "name_of the_attribute_from_plugin_xml"/
  
  argument position
= "2" name = "name_of the_attribute_from_plugin_xml"/
  
  ...
  
  /constructor
  
  
  This is probably worth supporting as an option.
  

I didn't follow the context object discussion it seems like this is a
better way to do the initData stuff. correct? That is cool. I wonder
as well if dynamic context is on the table? That is supplying objects
in the call the createExecutableExtension call.

  = Annotations and VM support =
  
  
  Annotations would be really nice to use. As an
example
take be the topic above ("single context object"): annotations
could have been used to tie constructor arguments to the XML
attributes.

  
  
  However, Eclipse SDK runs on 1.4 and the position
of the extension registry in the Eclipse stack does not give us much
freedom.
We'll have to support pre-1.5 VMs at least in the 3.x stream, there is
no choice. As such any functionality based on annotations would have to
be optional.
  

Is there [easy] some way we can support annotations if they are there
(and we are on an appropriate VM) but otherwise allow people to work
without htem?
- the extension registry: while it
might not look
like a conventional DI framework, in spirit it is very similar. The
functionality
gets obscured by registry artifacts as pieces that gets injected are
IConfigurationElements
/ IExtensions. With this enhancement the actual Java typed objects will
be injected using method/field injection; and an optional "context"
elements will be injected via constructors. 
  

I entered a bug today to talk about linking the extension lifecycle
with that of services (DS) and more of the bundle lifecycle. This
would go a long way IMHO towards making extensions and services
intereact better. That and making it easeier to lookup and inject
services into createExecutableExtension and to contribute extensions
that are in fact services (e.g., make it easy to use an
IExecutableExtensionFactory)

Jeff


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] plan comments

2008-09-26 Thread Jeff McAffer

The plan is looking pretty good.  Below are a few comments.  In some 
places I did some changes (I marked these in the comments below).  These 
should have your review.  Please add or tweak as needed in the next few 
days so we can meet the Tuesday deadline


Jeff

General
- the bugs referred to from the plan shoul dhave the plan keyword
- There are a number of plan items that do not have bug reports.  [I did 
all that I could see but please verify yours have ONE bug and it has the 
plan keyword]


Scalability and Performance
- p2 item should have one umbrella bug with the plan keyword.  the 
other bugs listed on the plan now should be blockers for the new plan bug


Robustness
- the p2 items need to be filled out.  In most cases the first comment 
in the bug report is the text that should appear i nthe plan. [I did 
some tweaks here}
- added p2 testing item. 


Consumability
- the p2 items need to be filled out.  In most cases the first comment 
in the bug report is the text that should appear i nthe plan. [I did 
some tweaks here}

- added an API item.
- added a publisher item
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] new equinox builds location

2008-09-11 Thread Jeff McAffer


Great. Thanks Kim.

Are there any issues with the fall maintenance release and update site  
URLs?  For example, if there is an old URL in circulation then do we  
need to put the fall release content on the old site?


Jeff

On Sep 11, 2008, at 5:35 PM, Kim Moir [EMAIL PROTECTED] wrote:



Equinox builds now appear in the new RT location on  
download.eclipse.org and will be synched there with the build process.


http://download.eclipse.org/equinox/

Old builds still appear in the old location because that location is  
read only and I can't delete it. This is good for the short term,  
but over the longer term it should be cleaned and purged of stale  
non-release builds. I also copied some older builds to the archive  
site and requested that an archive location be created for http://archive.eclipse.org/equinox



Kim

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] .qualifier for export package?

2008-09-09 Thread Jeff McAffer

 
John Arthorne [EMAIL PROTECTED] 

  
  

To: 


Equinox development mailing list equinox-dev@eclipse.org

  
  

Date: 


09/05/2008 11:00 AM 

  
  

Subject: 


Re: [equinox-dev] .qualifier for export package?
  

  
  
  
  
  
  
  
  
We have qualifiers on bundles to support the notion of provisioning
"line-ups"
(aka features) that list precise groups of IUs (one precise build of a
particular bundle). We *don't* have qualifiers on bundles so that
require-bundle
statements can precisely choose a particular build of a bundle to
depend
on, since this kind of coupling is too restrictive. We don't have any
mechanism
today for defining line-ups of packages as we do today with bundles, so
qualifiers on packages currently have no value. 
  
I think the use case you have in mind is picking a single bundle as a
starting
point, and then expanding from that bundle based on its dependencies
(picking
a thread in the ball of yarn and pulling on it to see what comes out).
In this scenario, if the bundle has an import-package statement, and
there
are multiple builds of a bundle providing that package in the
repository,
which one do you choose? The problem here as BJ points out, is we would
never want to couple our require-bundle/import-package statements down
to the qualifier level. This tight coupling completely defeats the
purpose
of the component architecture where dependencies are expressed at the
level
of specification. So, I don't think this ball-of-yarn scenario can work
in a development scenario where I want to provision and test a
particular
build from a development repository containing several builds. I think
this scenario is only interesting when run against repositories of
officially
released content such as the release train repository, in which case
any
package that satisfies the import is acceptable and qualifiers on
either
imports or exports are not needed. 
  
More fundamentally, I may be alone here but I question the premise that
packages are simply finer-grained versions of bundles, and so
everything
we do with bundle versions is still applicable at the package level. My
thinking is that a bundle is a container that holds specifications,
implementations,
and other non-code artifacts. As such its version number must have the
flexibility to capture the fact that it contains not only API, but
other
non-API artifacts that people may rely on (implementation
characteristics,
extension points, documentation, source code, etc). When someone has a
require-bundle statement, they may want to express their dependency on
any one of the things that bundle contains. Thus it's reasonable for
someone
to have a dependency range of, say, [1.0.2,2.0.0) on a bundle, because
they may rely on some non-code attribute of the bundle that was
introduced
in version 1.0.2. 
  
An API package, on the other hand, is pure specification. Version
numbers
on packages can thus be expressed purely as a function of the API in
the
package. If the API changes, the version changes, if the API doesn't
change,
the version doesn't change. I don't even see a need for the service
segment
on a package: major.minor should be enough to express compatible and
incompatible
API changes. In my view the only value of the push towards
import-package
is it moves dependencies from the container (bundle), to the
specification
(package). It is not simply a push towards dependency on finer-grained
containers (which can be acheived simply by making our bundles
smaller).
The great power of this shift is that it allows for the flexibility of
interchangeable implementations of that specification. Moving to this
world
means you can no longer rely on non-API characteristics of a package,
so
having an import-package define more than a major.minor dependency
defeats
the purpose. 
  
I think we need to make sure we agree on *why* moving from
require-bundle
to import-package is valuable. That will held guide our thinking on the
semantics of package version numbers, where to use them, and the
related
use cases around them. I would argue that today only a very small
number
of Eclipse API packages are truly pure specification that one could
reasonably
swap out the implementation of transparently. In my view these are the
only packages that are worth versioning at the package level. I
certainly
think the *goal* should be moving towards this world of
specification-level
dependencies (and thus use of import-package), but that's not where we
are today. 
  
John 
  

  
Jeff McAffer
[EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 
09/05/2008 01:33 AM 




  

  
  Please respond to
Equinox development mailing list equ

Re: [equinox-dev] .qualifier for export package?

2008-09-06 Thread Jeff McAffer

e a
dependency range of, say, [1.0.2,2.0.0) on a bundle, because they may
rely on some non-code attribute of the bundle that was introduced in
version 1.0.2. 
  
An API package, on the other hand, is pure specification. Version
numbers on packages can thus be expressed purely as a function of the
API in the package. If the API changes, the version changes, if the API
doesn't change, the version doesn't change. I don't even see a need for
the service segment on a package: major.minor should be enough to
express compatible and incompatible API changes. In my view the only
value of the push towards import-package is it moves dependencies from
the container (bundle), to the specification (package). It is not
simply a push towards dependency on finer-grained containers (which can
be acheived simply by making our bundles smaller). The great power of
this shift is that it allows for the flexibility of interchangeable
implementations of that specification. Moving to this world means you
can no longer rely on non-API characteristics of a package, so having
an import-package define more than a major.minor dependency defeats the
purpose. 
  
I think we need to make sure we agree on *why* moving from
require-bundle to import-package is valuable. That will held guide our
thinking on the semantics of package version numbers, where to use
them, and the related use cases around them. I would argue that today
only a very small number of Eclipse API packages are truly pure
specification that one could reasonably swap out the implementation of
transparently. In my view these are the only packages that are worth
versioning at the package level. I certainly think the *goal* should be
moving towards this world of specification-level dependencies (and thus
use of import-package), but that's not where we are today.
  
  
John 
  
  
  
  

  
Jeff McAffer
[EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 
09/05/2008 01:33 AM 


  

  
  Please respond to
Equinox development mailing list equinox-dev@eclipse.org
  

  





  

  
  To
  
  Equinox development
mailing list equinox-dev@eclipse.org 


  
  cc
  
  


  
  Subject
  
  Re: [equinox-dev]
.qualifier for export package?

  



  

  
  

  


  

  
  
  
  
I'm certainly sympathetic to you thinking here. Having qualifiers in
import statements is ugly at best. The challenge is that in the dev
cycle the API of something may change many many times. This would lead
to quite visible changes in unreasonable ways. For example, say we
introduce some API and then "break" it several times as we refine in
the dev cycle. Then the first release of the API might have version
42.23.27 or some such. Trying to manage API semantics during the
dev/release cycle seems like overkill. Clearly that is an over done
example but you get the point I hope.
  
Lets step back for a second. Some goals in decreasing order of
priority/importance.
  
Goal #1: ensure that at least all API packages have version numbers on
the exports.
Goal #2: be able to eat our own dog food wrt provisioning and version
management during the dev cycle.
  
Good news is that #1 is likely agreed to and *all* we have to do is put
the initial version numbers on the current packages and then have the
tooling help people manage them according to the current versioning
model.
  
The proposal for using .qualifier was actually one possible
implementation of goal #2. #2 is interesting because eating our own dog
food seems to greatly increase the likelihood of our technology being
good/useful. Without some sort of increasing version number on the
packages, p2 for example, will have a hard time figuring out what to
give you cause everything will look the same to it.
Can anyone think of another way of enabling #2? Of the top of my head
I'm thinking that something like the odd/even version pattern might
help...
  
Jeff
BJ Hargrave wrote: 
  
If you change API during dev cycle, that is the proper time to also
change the major or minor version. That is the whole point. I would
assume that API tooling will complain until you do so. Just changing
the qualifier is insufficient to capture an API change. Also, I think
that last thing we want to see are bundles using qualifiers in import
package statements! So if you use qualifier to denote API change during
dev, then other bundles will need to import using qualifiers to ensure
they wire to the desire API if they use it. UGLY! 
  
Qualifiers are useful to capture implementation changes. But API is

Re: [equinox-dev] .qualifier for export package?

2008-09-06 Thread Jeff McAffer





no. If you spec a constraint on a package, the bundle or version of
the bundle from which the package comes does not factor into the
decision.

Jeff

David M Williams wrote:

   Without some sort of increasing version number on
the packages, p2 
 for example, will have a hard time figuring out what to give you 
 cause everything will look the same to it.
 Can anyone think of another way of enabling #2?
  
  
  Wouldn't p2 _have_ to always pick a bundle with the
highest
qualifier (thereby getting the highest level of any packages in that
bundle)?
  
  If not, then this API use case would only be a special
case of a general problem of using "old" implementations. 
  
  Perhaps I'm missing the point? 
  
  
  
  
  
  

  
From:
    
    Jeff McAffer
[EMAIL PROTECTED]

  
  
To:

Equinox development
mailing list equinox-dev@eclipse.org

  
  
Date:

09/05/2008 04:32 AM

  
  
Subject:

Re: [equinox-dev]
.qualifier for export
package?
  

  
  
  
  
  
  
  I'm certainly sympathetic to you thinking here.
Having
qualifiers in import statements is ugly at best. The challenge is
that in the dev cycle the API of something may change many many times.
This would lead to quite visible changes in unreasonable ways. For
example, say we introduce some API and then "break" it several
times as we refine in the dev cycle. Then the first release of the
API might have version 42.23.27 or some such. Trying to manage API
semantics during the dev/release cycle seems like overkill. Clearly
that is an over done example but you get the point I hope.
  
Lets step back for a second. Some goals in decreasing order of
priority/importance.
  
Goal #1: ensure that at least all API packages have version numbers on
the exports.
Goal #2: be able to eat our own dog food wrt provisioning and version
management
during the dev cycle.
  
Good news is that #1 is likely agreed to and *all* we have to do is put
the initial version numbers on the current packages and then have the
tooling
help people manage them according to the current versioning model.
  
The proposal for using .qualifier was actually one possible
implementation
of goal #2. #2 is interesting because eating our own dog food seems
to greatly increase the likelihood of our technology being good/useful.
Without some sort of increasing version number on the packages, p2
for example, will have a hard time figuring out what to give you cause
everything will look the same to it.
Can anyone think of another way of enabling #2? Of the top of my
head I'm thinking that something like the odd/even version pattern
might
help...
  
Jeff
BJ Hargrave wrote: 
  
  
If you change API during dev cycle, that is the proper time to also
change
the major or minor version. That is the whole point. I would assume
that API tooling will complain until you do so. Just changing the
qualifier
is insufficient to capture an API change. Also, I think that last thing
we want to see are bundles using qualifiers in import package
statements!
So if you use qualifier to denote API change during dev, then other
bundles
will need to import using qualifiers to ensure they wire to the desire
API if they use it. UGLY! 
  
Qualifiers are useful to capture implementation changes. But API is a
specified
thing that changes deliberately and (hopefully) slowly and its version
is not subject to implementation. 
-- 
  
  

  
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi
Alliance
[EMAIL PROTECTED]



office: +1 386 848 1781
mobile: +1 386 848 3788

  

  
  
  
  
  
  
  
  

  
From:
    
Jeff McAffer [EMAIL PROTECTED]

  
  
To:

Equinox development
mailing list equinox-dev@eclipse.org

  
  
Date:

2008/09/03 06:16 AM

  
  
Subject:

Re: [equinox-dev]
.qualifier for export
package?
  

  
  
  
  
  
  
  
I understand your hestiation and actually agree with you from the
"released
code" point of view. However, we spend a lot of time dealing
with code and API that is in development. If we are to have any hope
of provisioning and managing that, we need to know the difference
between
the various iterations of the packages. For example, when someone
adds an API during the dev cycle and you want use it, you need to
import
the right version of the package to ensure you get it. Changing the
first three segments version number of the package for every change
done
in the dev cycle feels too disruptive.
  
To a certain extent this could be handled in the provisioning system
but
that would force the situation of bundles in a particular context
(e.g.,
a build "lineup"). That is, bundles would

Re: [equinox-dev] .qualifier for export package?

2008-09-06 Thread Jeff McAffer





Yup. It is not so much that I want to control the version of the
package rather that I want to be able to use p2 during development. So
I started this thread off with a solution rather than stating the
problem (to be honest I don't think I fully formed the problem in my
head at that time).

I'm thinking that something in the lineup direction will be beneficial
here...

Jeff

BJ Hargrave wrote:

  If I understand #2 correctly, then
you
want a controlled version practice during the development cycle. This
is
challenging since you may want to change your mind and break from a
previous
API change made during the same dev cycle.
  
  
  For example:
  
  
  1.2 is the last shipped version of a
package (let's say thats in Ganymede).
  
  
  So during the dev cycle you change
to
1.3 because you add new API. Soon you add more API. 1.3.1 or 1.4? Then
you decide to pull some of those API changes because we learned they
did
not work as expected. What version then? 2.0? Because of the breaking
change?
I think this is a fairly impossible situation during the dev cycle
because
we are free to change our mind about new API until API freeze.
  
  
  I think the odd/even versioning
could
be useful. But it still does not easily handle the removal of new API
previously
added during the dev cycle. It only seems to work well if the API only
"grows" but does not shrink.
  
  
  -- 
  
  

  
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi
Alliance
[EMAIL PROTECTED]



office: +1 386 848 1781
mobile: +1 386 848 3788

  

  
  
  
  
  
  
  
  

  
From:
    
    Jeff McAffer
[EMAIL PROTECTED]

  
  
To:

Equinox development
mailing list equinox-dev@eclipse.org

  
  
Date:

2008/09/05 04:32 AM

  
  
Subject:

Re: [equinox-dev]
.qualifier for export
package?
  

  
  
  
  
  
  
  I'm certainly sympathetic to you thinking here.
Having
qualifiers in import statements is ugly at best. The challenge is
that in the dev cycle the API of something may change many many times.
This would lead to quite visible changes in unreasonable ways. For
example, say we introduce some API and then "break" it several
times as we refine in the dev cycle. Then the first release of the
API might have version 42.23.27 or some such. Trying to manage API
semantics during the dev/release cycle seems like overkill. Clearly
that is an over done example but you get the point I hope.
  
Lets step back for a second. Some goals in decreasing order of
priority/importance.
  
Goal #1: ensure that at least all API packages have version numbers on
the exports.
Goal #2: be able to eat our own dog food wrt provisioning and version
management
during the dev cycle.
  
Good news is that #1 is likely agreed to and *all* we have to do is put
the initial version numbers on the current packages and then have the
tooling
help people manage them according to the current versioning model.
  
The proposal for using .qualifier was actually one possible
implementation
of goal #2. #2 is interesting because eating our own dog food seems
to greatly increase the likelihood of our technology being good/useful.
Without some sort of increasing version number on the packages, p2
for example, will have a hard time figuring out what to give you cause
everything will look the same to it.
Can anyone think of another way of enabling #2? Of the top of my
head I'm thinking that something like the odd/even version pattern
might
help...
  
Jeff
BJ Hargrave wrote: 
  
  
If you change API during dev cycle, that is the proper time to also
change
the major or minor version. That is the whole point. I would assume
that API tooling will complain until you do so. Just changing the
qualifier
is insufficient to capture an API change. Also, I think that last thing
we want to see are bundles using qualifiers in import package
statements!
So if you use qualifier to denote API change during dev, then other
bundles
will need to import using qualifiers to ensure they wire to the desire
API if they use it. UGLY! 
  
Qualifiers are useful to capture implementation changes. But API is a
specified
thing that changes deliberately and (hopefully) slowly and its version
is not subject to implementation. 
-- 
  
  

  
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi
Alliance
[EMAIL PROTECTED]



office: +1 386 848 1781
mobile: +1 386 848 3788

  

  
  
  
  
  
  
  
  

  
From:
    
Jeff McAffer [EMAIL PROTECTED]

  
  
To:

Equinox development
mailing list equinox-dev@eclipse.org

  
  
Date:

2008/09/03 06:16 AM

Re: [equinox-dev] .qualifier for export package?

2008-09-05 Thread Jeff McAffer





I'm certainly sympathetic to you thinking here. Having qualifiers in
import statements is ugly at best. The challenge is that in the dev
cycle the API of something may change many many times. This would lead
to quite visible changes in unreasonable ways. For example, say we
introduce some API and then "break" it several times as we refine in
the dev cycle. Then the first release of the API might have version
42.23.27 or some such. Trying to manage API semantics during the
dev/release cycle seems like overkill. Clearly that is an over done
example but you get the point I hope.

Lets step back for a second. Some goals in decreasing order of
priority/importance.

Goal #1: ensure that at least all API packages have version numbers on
the exports.
Goal #2: be able to eat our own dog food wrt provisioning and version
management during the dev cycle.

Good news is that #1 is likely agreed to and *all* we have to do is put
the initial version numbers on the current packages and then have the
tooling help people manage them according to the current versioning
model.

The proposal for using .qualifier was actually one possible
implementation of goal #2. #2 is interesting because eating our own
dog food seems to greatly increase the likelihood of our technology
being good/useful. Without some sort of increasing version number on
the packages, p2 for example, will have a hard time figuring out what
to give you cause everything will look the same to it.
Can anyone think of another way of enabling #2? Of the top of my head
I'm thinking that something like the odd/even version pattern might
help...

Jeff
BJ Hargrave wrote:

  If you change API during dev cycle,
that is the proper time to also change the major or minor version.
That
is the whole point. I would assume that API tooling will complain until
you do so. Just changing the qualifier is insufficient to capture an
API
change. Also, I think that last thing we want to see are bundles using
qualifiers in import package statements! So if you use qualifier to
denote
API change during dev, then other bundles will need to import using
qualifiers
to ensure they wire to the desire API if they use it. UGLY!
  
  
  Qualifiers are useful to capture
implementation
changes. But API is a specified thing that changes deliberately and
(hopefully)
slowly and its version is not subject to implementation. 
  
  -- 
  
  

  
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi
Alliance
[EMAIL PROTECTED]



office: +1 386 848 1781
mobile: +1 386 848 3788

  

  
  
  
  
  
  
  
  

  
From:
    
    Jeff McAffer
[EMAIL PROTECTED]

  
  
To:

Equinox development
mailing list equinox-dev@eclipse.org

  
  
Date:

2008/09/03 06:16 AM

  
  
Subject:

Re: [equinox-dev]
.qualifier for export
package?
  

  
  
  
  
  
  
  I understand your hestiation and actually agree with
you
from the "released code" point of view. However, we spend
a lot of time dealing with code and API that is in development. If
we are to have any hope of provisioning and managing that, we need to
know
the difference between the various iterations of the packages. For
example, when someone adds an API during the dev cycle and you want use
it, you need to import the right version of the package to ensure you
get
it. Changing the first three segments version number of the package
for every change done in the dev cycle feels too disruptive.
  
To a certain extent this could be handled in the provisioning system
but
that would force the situation of bundles in a particular context
(e.g.,
a build "lineup"). That is, bundles would no longer be
completely/accurately self-describing.
  
Jeff
  
BJ Hargrave wrote: 
  
  
I would be extremely cautious about using qualifier on package
versions.
I must say that I have never seen it done. 
  
It seems an over specification. I think that having build tools to
advise
you to increment the micro is more than sufficient.
  
-- 
  
  

  
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi
Alliance
[EMAIL PROTECTED]



office: +1 386 848 1781
mobile: +1 386 848 3788

  

  
  
  
  
  
  
  
  

  
From:

Thomas
Watson/Austin/[EMAIL PROTECTED]

  
  
To:

Equinox development
mailing list equinox-dev@eclipse.org

  
  
Date:

2008/09/02 10:45 AM

  
  
Subject:

Re: [equinox-dev]
.qualifier for export
package?
  

  
  
  
  
  
  
  
Before recommending every package uses a qualifier I have the following
concerns:
  
1) In Eclipse we have loads of packages. We

Re: [equinox-dev] GWT+Equinox

2008-09-03 Thread Jeff McAffer

You might want to get the real Jetty stuff rather than checking it out 
using the psf.  The psf may be out of date.  Try using all released code.


Jeff

Ian Bull wrote:

Ricardo,

I have this working with GWT 1.5 and Eclipse 3.4, so we know it's 
possible :-).


Have you tried adding javax.servlet to the required plug-ins for GWT? 
I have a GWT bundle, and I noticed that it depends on javax.servlet. 
If I remove this dependency I get the class cast exception.


I also removed all the servlet stuff from Exported Packages list. (See 
the Runtime tab in the Manifest editor).


Cheers,
Ian

Ricardo Giacomin wrote:


Hi there,

I tried to follow the directions from wiki page 
http://wiki.eclipse.org/index.php/Google_Web_Toolkit_and_Equinox with 
no success. The problem is that no matter what I do I still get the 
ClassCastException when the ServletManager tries to instantiate the 
servlet. It is probably a problem of different servlet API version 
(2.4 in equinox http and 2.3 in gwt).


I’m using:

GWT 1.5.2

Eclipse 3.4

Jetty Http from 
http://www.eclipse.org/equinox/server/downloads/jettyhttp-anon.psf


Any hints?

Thank you in advance.

Regards,

Ricardo Giacomin


--
This message has been scanned for viruses and
dangerous content by *MailScanner* http://www.mailscanner.info/, 
and is

believed to be clean.


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [Equinox Security] Error while running unit tests of JCA/JAAS_framework_contribution

2008-08-31 Thread Jeff McAffer





Could you summarize the information in the quoted posts and put them on
the wiki? Perhaps the outdated material should also be removed? or
archived?


Oleg Besedin wrote:

  Hi Ricardo,
  
  That page is quite outdated and
probably
is not a good starting point. See:
  
  
  http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04701.html
  
  http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04702.html
  
  
  Thanks,
  
  Oleg
  
  
  
  
  

  
"Ricardo
Giacomin"
[EMAIL PROTECTED] 

Sent by:
[EMAIL PROTECTED]
08/27/2008 02:41 PM

  

  
  Please
respond to
[EMAIL PROTECTED]; Please respond to
Equinox development mailing list equinox-dev@eclipse.org
  

  






  

  
  To
  
  equinox-dev@eclipse.org
  


  
  cc
  
  
  


  
  Subject
  
  [equinox-dev]
[Equinox Security] Error
while running unit tests ofJCA/JAAS_framework_contribution

  



  

  
  
  
  
  

  



  

  
  
  
  
  Hi,
  
  
  
  (I tried sending this post to
eclipse.technology.equinox
  newsgroup
but got no answers. Sorry for this cross-posting then)
  
  
  
  
  
  I'm trying to run junit tests of
milestone
M3 of equinox security. I followed the directions presented in the
wiki page
(http://wiki.eclipse.org/Security:_JCA/JAAS_framework_contribution).
  
Unfortunately, I get the exceptions presented in the stack trace below.
  
Environment is:
  
Eclipse 3.4.0
Windows Vista
JRE 1.5.0_06
  
Any help would be appreciated.
  
Regards,
Ricardo Giacomin
  
  
!SESSION 2008-08-22 16:17:33.257
---
eclipse.buildId=I20080617-2000
java.version=1.5.0_06
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: -version 3 -port 55474 -testLoaderClass
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader
-loaderpluginname org.eclipse.jdt.junit.runtime -testNameFile
C:\Users\Giacomin\AppData\Local\Temp\testNames4844.txt
-application org.eclipse.pde.junit.runtime.uitestapplication -product
org.eclipse.sdk.ide
-testpluginname org.eclipse.equinox.security.junit
Command-line arguments: -os win32 -ws win32 -arch x86 -version 3
-port 55474 -testLoaderClass
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader
-loaderpluginname org.eclipse.jdt.junit.runtime -testNameFile
C:\Users\Giacomin\AppData\Local\Temp\testNames4844.txt
-application org.eclipse.pde.junit.runtime.uitestapplication -product
org.eclipse.sdk.ide
-data C:\Users\Giacomin\osgi/../junit-workspace -dev
file:C:/Users/Giacomin/osgi/.metadata/.plugins/org.eclipse.pde.core/pde-junit/dev.properties
-os win32 -ws win32 -arch x86 -testpluginname
org.eclipse.equinox.security.junit
  
!ENTRY org.eclipse.osgi 4 0 2008-08-22 16:17:37.539
!MESSAGE !STACK 0
org.osgi.framework.BundleException: Cannot attach fragment bundle
"org.eclipse.equinox.security.boot.jre15x"
to resolved host "org.eclipse.osgi". Try refreshing the
host bundle.
at
org.eclipse.osgi.framework.internal.core.BundleHost.attachFragment(BundleHost.java:575)
at
org.eclipse.osgi.framework.internal.core.BundleFragment.addHost(BundleFragment.java:298)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.setResolved(PackageAdminImpl.java:337)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.applyDeltas(PackageAdminImpl.java:353)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:441)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:221)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:164)
at java.lang.Thread.run(Thread.java:595)
  
!ENTRY org.eclipse.core.runtime 4 0 2008-08-22 16:17:37.990
!MESSAGE !STACK 0
org.osgi.framework.BundleException: The bundle could not be resolved.
Reason:
Missing Constraint: Require-Bundle: org.eclipse.equinox.app;
bundle-version="[1.0.0,2.0.0)"
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:351)
at
org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1061)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:632)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:506)
at

Re: [equinox-dev] Need help starting an OSGI based project

2008-08-23 Thread Jeff McAffer





This should be asked on the the newsgroups.

Summary is that you should use the eclipse executable. it is available
for many many platforms. The PDE tooling contains comprehensive
tooling. Even if you are just using Equinox, get the RCP book and
pretend you are making and RCP app without the UI. Everything is the
same.

starting from a script is ok but does no integrate well into the
desktop. Taskbar, dock, what have you are not well hooked and there
can be strange behaviour. all depends on your scenario

Jeff

Vinayak Joshi wrote:

  

  
Hi 

I have been asked to base a new application on the OSGi framework
choosing Equinox as the runtime. After my initial few weeks of study I
have a few questions that I need clarified since I couldn't find any
direct answers for these (or perhaps didn't manage to reach the right
resources): 

1. As per the quick start guide I can launch equinox through:  

java -jar org.eclipse.osgi_x.y.z.jar -console

However, there are launchers available for most platforms too. I want
to know as to 
which approach I should be taking - use a launcher to start my
application or stick to a script that runs "java -jar
org.eclipse.osgi_x.y.z.jar -console" etc? Any trade-offs between the
two?

2. In case I have to use the launcher due to some reasons, then if I
were to package my application as a product and distribute it - would
that mean users launching the product via eclipse.exe? Any other way?

Please point me to any resources that deal with step-by-step on
building products based on equinox runtime. I am really new to this
stuff so any help would be really appreciated!

Vin.


  

  
  
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Equinox on the move

2008-08-11 Thread Jeff McAffer

The process of moving Equinox to its new home under RT has begun.  Much 
of the Eclipse Foundation database information has been moved and over 
the course of this week the bugs, CVS repo and downloads sites will move 
as well.  Tom and I will continue to keep you informed of the progress 
and any actions you might need to take.


Jeff  Tom
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Code move timeline

2008-07-18 Thread Jeff McAffer





yes, Equinox is moving and all future releases should come from the
"new" repo in RT-land. 

Jeff

Thomas Watson wrote:

  Yes we will retain history. We do not plan to physically remove
the old tags and branches from the /cvsroot/eclipse repo so the old map
files should continue to be able to build the maintenance builds. I
think we will remove all the content from HEAD and place a readme in
each project stating where the project has moved. But this does not
imply that the old tags and branches will be deleted.
  
But this does raise the question about which repository should be used
for 3.4.x. Which repo should we use to develop 3.4.x? My vote is to do
all future releases out of the Runtime repo, including point releases
(3.4.1). In this case the 3.4.x map files should only have to be
updated with the new location when the first fix is dropped into the
new Runtime repo.
  
Tom
  
  
  
  Kim Moir
---07/17/2008 04:06:46 PM---So I assume that the cvs history will be
retained when the bundles are moved to the RT project's re
  
  

  

From:

Kim Moir [EMAIL PROTECTED]
  
  

To:

Equinox development mailing list
equinox-dev@eclipse.org
  
  

Date:

07/17/2008 04:06 PM
  
  

Subject:

Re: [equinox-dev] Code move timeline
  

  
  
  
  
  
  
So I assume that the cvs history will be retained when the bundles are
moved to the RT project's repository? The 3.4.x map files will need to
be updated with the new location too so we don't have build breakage 
  
Kim 
  
  
  
  
  

  
Thomas Watson
[EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 
07/17/2008 02:04 PM 


  

  
  Please respond to
Equinox development mailing list equinox-dev@eclipse.org
  

  





  

  
  To
  
  Equinox development
mailing list equinox-dev@eclipse.org 


  
  cc
  
  


  
  Subject
  
  Re: [equinox-dev] Code
move timeline

  



  

  
  

  


  

  
  
  
  
We discussed this at the Tuesday Equinox call. It looks like a large
part of the team will be on vacation at the end of July. The proposal
is to move the equinox projects to RT during the week of July 28th.
  
We also discussed what to do with the equinox incubator. At this time
we are going to wait for the new Eclipse Development Process to be
approved (hopefully in August). The new process should allow us to
create incubator projects under any project in Eclipse. This will allow
us to create an incubator project for equinox directly under the
equinox project in RT.
  
Jeff and I have been discussing the layout of the different components
of Equinox. Today we have Bundles, Framework, p2, Security. The Bundles
category has become kind of a dumping ground for many unrelated
bundles. We would like to split these bundles out into three
categories: 
  
  
osgi-compendium - All bundles that implement one of the osgi compendium
specifications. This includes the following projects:
org.eclipse.equinox.app
org.eclipse.equinox.cm
org.eclipse.equinox.device
org.eclipse.equinox.ds
org.eclipse.equinox.event
org.eclipse.equinox.http
org.eclipse.equinox.http.jetty (jetty5 and jetty6 impls)
org.eclipse.equinox.io
org.eclipse.equinox.ip
org.eclipse.equinox.log
org.eclipse.equinox.metatype
org.eclipse.equinox.preferences
org.eclipse.equinox.useradmin
org.eclipse.equinox.util
org.eclipse.equinox.wireadmin
org.eclipse.osgi.services
org.eclipse.osgi.util
  
components - The bundles that provide infrastructure to developing
components in Equinox. This includes the following projects:
org.eclipse.equinox.common
org.eclipse.equinox.registry
org.eclipse.equinox.transforms.hook
org.eclipse.equinox.transforms.xslt
  
  
server-side - The server side bundles.
org.eclipse.equinox.http.registry
org.eclipse.equinox.http.servlet
org.eclipse.equinox.http.servletbridge
org.eclipse.equinox.jsp.jasper
org.eclipse.equinox.jsp.jasper.registry
org.eclipse.equinox.servletbridge
  
  
This would result in the following CVS structure in RT
  
org.eclipse.equinox/components
org.eclipse.equinox/framework
org.eclipse.equinox/osgi-compendium
org.eclipse.equinox/p2
org.eclipse.equinox/security
org.eclipse.equinox/server-side
  
All commiters with rights to the projects contained in Bundles will
continue to have access to all the projects which got moved to the
three new categories. We are not trying to create more fine grained
commit rights. Instead we

Re: [equinox-dev] Possible to obtain org.eclipse.osgi.jar without OSGi framework classes?

2008-07-04 Thread Jeff McAffer





Hey Olaf

Did you try copying out the OSGi types and putting them on the JCA
classloader? If the FirstChild is actually a child of the JCA loader
then it should get the OSGi types from JCA and ignore the ones in the
osgi.jar. Of course, if you are trying to isolate Equinox from the JCA
classes this might be a problem. What is the parent of the JCA
classloader? 
Jeff

Bergner, Olaf wrote:

  
  
  
  Hi Jeff,
  
  I'm trying to integrate Equinox as a JCA adapter into WLS 9.2
which, to the best of my knowledge, is not based on OSGi, as opposed to
WLS 10.0. Anyway, my goals are the following:
  
  - Keep the application's main programming model, migrate to
OSGionly those very few yet very sensitive parts of the application
that change very often. This application is a _massive_ J2EE app which
has been in the works since 2001. We are still working on finishing the
first iteration.
  - Statically define a set of service interfaces whose
implementation will be provided at runtime by Equinox. These interfaces
live in a jar which is visible to both the enclosing JCA adapter
moduleas well as Equinox. The packages these interfaces reside inare
listed among OSGi's system packages.
  - Keep Equinox' class space(s) almost completely isolated
from that of the enclosing JCA adaptermodule's.
  - Expose the org.osgi.framework classes - and later possibly
the packageadmin's classes - to the enclosing JCA adapter module so
that accessing OSGi services becomes possible. The org.osgi.framework
package is listed among OSGi's system packages.
  
  When bootsrapping Equinox from inside the JCA adapter, I
create a new child first classloader as a child classloader of the
classloader that loaded the JCA module. This child first classloader
knows about the location of the org.eclipse.osgi.jar on the classpath
and first tries to load classes from this jar before delegating to the
parent classloader, thus isolating the Equinox implementation from the
enclosingJCA adapter module. This works like a charm:
  
  JCARAR ClassLoader-
service-interfaces.jar
   |
   |
   ChildFirstBootstrapClassLoader
-org.eclispe.osgi.jar
  
  Unfortunately, since the OSGi framework is included in
org.eclispe.osgi.jar, this also means that the org.osgi.framework
classes will be loaded by this child first classloader and will
therefore not be visible to the enclosing JCA adapter module.I tried
patching the child first classloader to not loading classes that start
with "org.osgi.framework" - I consider this solution an ugly hack - and
putting osgi_R4.jar on the JCA adapter module's classpath. This doesn't
work since it gives me a NoSuchMethodError: Equinox cannot find the
method Bundle.start(). I am no classloading expert but suspect that
there are two Bundle classes loaded. Of course, I could be totally
wrong.
  
  Anyway, after several fruitless hours of debugging I decided
not to venture further down this path and opted for a solution that
uses reflection to gain access to the BundleContext returned from
EclipseStarter.startup(). This works yet feels a little clumsy. If
someone could point me tomeans of achieving my original goal
ofsharing the OSGi API classes between Equinox and the enclosing JCA
adapter module, I would be grateful.
  
  Cheers,
  Olaf
  
  --
  Hey Olaf,
  
  
  The short answer is, No, such a distribution is not readily available.
  
  The question in my mind is why do you need this? If you remove
the OSGi classes where will they come from? If you happen to be running
on an OSGi-based JEE app server then you could in theory get the
classes from the app server. To do this you should be able to play
around with the framework's parent classloader. That way the OSGi
classes would still be in the org.eclipse.osgi bundle but they would be
ignored in favor of the ones from the parent loader.
  
  
  Jeff
  
  Olaf Bergner wrote: 
  
  
Hello,


I'm currently embedding equinox into a JEE app server and would like to make
the OSGi API visible to the enclosing application. Therefore, I need an
org.eclipse.osgi distribution that does not include the org.osgi.framework
classes. Does it exist?


Cheers,
Olaf

___
equinox-dev mailing list
[EMAIL PROTECTED]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

  
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Possible to obtain org.eclipse.osgi.jar without OSGi framework classes?

2008-06-25 Thread Jeff McAffer


Hey Olaf,

The short answer is, No, such a distribution is not readily available.

The question in my mind is why do you need this?  If you remove the OSGi 
classes where will they come from?  If you happen to be running on an 
OSGi-based JEE app server then you could in theory get the classes from 
the app server.  To do this you should be able to play around with the 
framework's parent classloader.  That way the OSGi classes would still 
be in the org.eclipse.osgi bundle but they would be ignored in favor of 
the ones from the parent loader.


Jeff

Olaf Bergner wrote:

Hello,

I'm currently embedding equinox into a JEE app server and would like to make
the OSGi API visible to the enclosing application. Therefore, I need an
org.eclipse.osgi distribution that does not include the org.osgi.framework
classes. Does it exist?

Cheers,
Olaf

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Aspects: Reworked website, quick-start guide and Hello world! demo

2008-06-24 Thread Jeff McAffer


Sounds good.  Of course by update site I meant to say p2 repository :-)

Jeff

Martin Lippert wrote:

Hi Jeff,


This sounds like a good plan.  Thanks for being proactive on this.
It will be interesting to see what happens with the *new* lower 
version.  For exapmle, if the update sites that people use have both 
the new and old with the new version being lower then users likely 
will not be able to get the right thing.  Would you see removing the 
older versions?


I think we should create a new update site for this.

As for the graduation review, do you have a set of code that you 
would like to release now?  If that is true then you might just 
graduate with a higher version number and remove the old versions.


I think that either option would be fine.  Thanks again.


Our current idea is to start with the lower version number, then build 
a number of milestone builds over the next months and graduate after 
this period (maybe by the end of this or beginning of next year). Does 
this sound reasonable?


-Martin





Jeff

Martin Lippert wrote:

Hi Jeff,

we discussed this briefly and the result is: we would like to do ALL 
this stuff... ;-)


Our idea would be:

1. lower the version numbers to make the incubator status clear. 
This includes communication with the community to avoid confusion 
and to make clear that this does not include lowering the quality of 
the code produced so far... ;-)


2. produce some more milestone builds instead of what we called 
releases in the past. We will write up a project plan as a wiki page 
that includes open bugs and our goals for upcoming milestone builds.


3. start the graduation process for a future first release of 
equinox aspects including reviews, a release review and whatever is 
necessary to graduate... :-)


What do you think?

-Martin



Jeff McAffer wrote:

Possible solutions:
- graduate
- lower the version numbers

In either case there will need to be a review if there is going to 
be a release.  You could avoid a review if the version number is 
lowered AND the event is rephrased as a milestone.


As for dealing with the past, well, dropping the version numbers 
would certainly cause some confusion.  Graduation would retain the 
version number sequence but we'd have to have a discussion in the 
wider community to see if graduation is warranted (I have no 
evidence either way at this point).


I'm certainly open to alternatives.

Jeff
Martin Lippert wrote:


Thanks Bjorn and Jeff for the clarification!

Now the question arises how we should deal with upcoming releases 
of equinox aspects while being in incubation... ;-)


Since we published releases with versions 1.x I am not sure what 
the best way is to move on. We mentioned the incubation within the 
bundle names and download zips (according to the guidelines I 
hope). Should we go back to versions 0.x with the next releases 
(with some explanations to avoid confusion)?


-Martin





Bjorn Freeman-Benson wrote:
The policy that we've been following/enforcing is that a project 
in incubation must have releases  1.0 and that projects out of 
incubation have releases = 1.0. I apologize that this is not 
clearly written.


Jeff McAffer wrote:
In any event, Bjorn (cc'd) would certainly know if there is an 
actual policy on this.


 



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Null Pointer Exception in EclipseStarter

2008-06-18 Thread Jeff McAffer





Craig, 

Thanks for taking the time to report this. Can I ask you to enter a
bug report at
 https://bugs.eclipse.org/bugs/
That helps us track and address these issues.
Jeff
 

Craig Phillips wrote:

  Hi,
  
  If someone wants to take a deeper
look... Stack trace at bottom of this post...
  
  Context is atomcat web-app a la jsp
[hence,not usingorg.eclipse.equinox.servletbridge];
  
  Snippet of application code (java):
  
   if (!EclipseStarter.isRunning()) { BundleContext ctx =
EclipseStarter.startup( args, null ); }
  I can run the jsp,
which invokes the aforementioned java code, after starting tomcat, and
all is well;
  However, if I restart the
web-app (leaving tomcat up and running), I get an NPE for which the
stack trace indicates is deep in the bowels of EclipseStarter.startup()
[noting that isRunning() returned false, which I guess is correct...
  On an aside, I'm not sure
how to trap web-app stop/restart to invoke EclipseStarter.shutdown()...
(and other clean up activities) [my ignorance on that one, presume];
  Here's the stack trace:
  java.lang.NullPointerException
 at
org.eclipse.osgi.framework.internal.core.FrameworkProperties.getPrope
rty(FrameworkProperties.java:58)
 at
org.eclipse.osgi.framework.internal.core.FrameworkProperties.getPrope
rty(FrameworkProperties.java:51)
 at
org.eclipse.osgi.framework.util.SecureAction.getProperty(SecureAction
.java:74)
 at
org.eclipse.osgi.framework.internal.protocol.StreamHandlerFactory.cre
ateURLStreamHandler(StreamHandlerFactory.java:91)
 at java.net.URL.getURLStreamHandler(URL.java:1106)
 at java.net.URL.init(URL.java:393)
 at java.net.URL.init(URL.java:283)
 at java.net.URL.init(URL.java:306)
 at java.io.File.toURL(File.java:623)
 at
org.apache.catalina.loader.WebappClassLoader.getURL(WebappClassLoader
.java:2302)
 at
org.apache.catalina.loader.WebappClassLoader.findResourceInternal(Web
appClassLoader.java:1973)
 at
org.apache.catalina.loader.WebappClassLoader.findClassInternal(Webapp
ClassLoader.java:1759)
 at
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoa
der.java:872)
 at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1327)
 at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1206)
 at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
 at
org.eclipse.osgi.framework.internal.core.Framework.installContentHand
lerFactory(Framework.java:1678)
 at
org.eclipse.osgi.framework.internal.core.Framework.initialize(Framewo
rk.java:236)
 at
org.eclipse.osgi.framework.internal.core.Framework.init(Framework.j
ava:152)
 at
org.eclipse.osgi.framework.internal.core.OSGi.createFramework(OSGi.ja
va:90)
 at
org.eclipse.osgi.framework.internal.core.OSGi.init(OSGi.java:31)
 at
org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarte
r.java:282)
 at org.craig.cache.entry.PojoEntry.query(Unknown Source)
 at org.apache.jsp.sample_jsp._jspService(sample_jsp.java:73)
 at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
.java:374)
 at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
37)
 at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
 at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:233)
 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:175)
 at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:128)
 at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:102)
 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:109)
 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:286)
 at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:844)
 at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ss(Http11Protocol.java:583)
 at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
7)
 at java.lang.Thread.run(Thread.java:619)
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Aspects: Reworked website, quick-start guide and Hello world! demo

2008-06-14 Thread Jeff McAffer


I was looking through the dev process doc (proposed update is at
   http://www.eclipse.org/projects/dev_process/development_process.php
and did not see anything obvious about limits on version numbers.  
Personal opinion on my part says that if it is ready for prime time then 
it should graduate and have a version that is = 1.*.  If it is not then 
the version number should be 1.0.   Really it is all about setting 
expectations to the consumers.  If you picked up something that was = 
1.0, you would expect it to be ready to go. If you pick up something 
that is incubating then you expect some rough edges.  These two 
conditions seem to be mutually exclusive.


In any event, Bjorn (cc'd) would certainly know if there is an actual 
policy on this.


One thing that I did note however is that Releases have to go through 
a release review.  I'm suspecting that the Aspects stuff did not have a 
formal release review.  Correct?  Assuming it did not, we need to either 
have a review or reposition the current code as a Milestone or some 
such.  Again, this is about managing expectations.  Our consumers expect 
releases to have a certain level of IP cleanliness, testing, ...  As a 
community we have agreed that release reviews are part of ensuring that 
that expectation is met.


Let me know what you want to do here.

Jeff

p.s., my apologies for not cluing into this situation earlier.

Heiko Seeberger wrote:
Do you have a hint where I could ask whether 1.* might be an issue in 
incubation?


Am 14.06.2008 um 02:58 schrieb Jeff McAffer:

On a side note, I'm not 100% but there may be an issue with calling 
the Aspects stuff 1.* when it is incubation.

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox Aspects: Reworked website, quick-start guide and Hello world! demo

2008-06-13 Thread Jeff McAffer


Heiko,

This is great.  Thanks.  some suggestions
- It would be great to have the quick start and demo somewhere in a 
permanent location on the main page.  These items will not be new 
forever and the what's new section is not where people would look to get 
started.  Perhaps a whole Getting Started bar near the top of the page?


- downloads.  The aspects downloads are hidden.  They are no tin the 
incubator seciton of the main Equinox download pages 
(http://download.eclipse.org/eclipse/equinox) nor are then on the 
Equinox Incubator downloads page 
(http://www.eclipse.org/equinox/incubator/downloads.php)


On a side note, I'm not 100% but there may be an issue with calling the 
Aspects stuff 1.* when it is incubation.


Other question:  Is there a 3.4 version of these facilities?

Jeff

Heiko Seeberger wrote:

Hi,

I just reworked the Equinox Incubator Aspects website. Now there is a 
detailled quick-start guide and a Hello world! demo.


We are looking forward to getting your feedback ...

Heiko
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] feature names

2008-06-11 Thread Jeff McAffer

As discussed in the planning call this morning our feature names are all
over the map.  Here is a sample of some I see in the current testUpdates
repo

 

Eclipse Project Equinox bundle feature

Eclipse P2 Developer Resources

Equinox bundle source feature

Equinox Provisioning Director Application Feature

Equinox Provisioning Generator

Equinox Provisioning Platform

 

The should be.  (in the corresponding order)

 

Equinox Bundles

Equinox p2 Developer Resources

Equinox Bundles Developer Resources

Equinox p2 Director Application

Equinox p2 Generator Application

Equinox p2

 

Anyone have other ideas?

 

Jeff

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] feature names

2008-06-11 Thread Jeff McAffer

Agreed with Tom on the bundles features.

 

As for the p2 features, if we are going to change them  and it is low risk, why 
not change them now.  In the precise usecase of Eclipse and the SDK the 
features do not show up to the user but they may in other cases no?

 

For p2 vs Provisioning, I understand your point about descriptiveness.  How 
about 

Equinox p2 Provisioning Developer Resources 

Equinox p2 Director Application 

Equinox p2 Generator Application 

Equinox p2 Provisioning

 

The point of choosing a distinct name was so that we could talk about things 
more easily.  It was cumbersome to always say “Equinox Provisioning”. The 
suggestion above does not sacrifice brevity, branding or descriptiveness.

 

Jeff



 

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Watson
Sent: Wednesday, June 11, 2008 12:37 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] feature names

 

I do think the equinox bundles SDK features should be updated for 3.4 if 
possible. This feature is available for download from the equinox page. The 
current name is pretty strange.

Tom



Inactive hide details for John Arthorne ---06/11/2008 11:20:51 AM---I will just 
point out these feature names don't appear anywJohn Arthorne ---06/11/2008 
11:20:51 AM---I will just point out these feature names don't appear anywhere 
outside our test updates repository



From:


John Arthorne [EMAIL PROTECTED]



To:


Equinox development mailing list equinox-dev@eclipse.org



Date:


06/11/2008 11:20 AM



Subject:


Re: [equinox-dev] feature names

  _  





I will just point out these feature names don't appear anywhere outside our 
test updates repository apart from Equinox Provisioning Platform. The 
director and generator features are build-time only features that probably 
shouldn't even be put on the test update site. They only exist because of the 
nature of the build process and I don't think there are interest for users. The 
p2 source feature will be installed on disk for users, but the name will only 
be found by the user if they open the feature.properties file on disk, since 
the source features are not installed and don't appear in the About dialog or 
configuration details. Since the testUpdates repository contents will be blown 
away with the first 3.5 build, I don't really see any value fixing them for 
3.4.0. 

I did consciously called the p2 feature Equinox Provisioning Platform because 
I thought Equinox p2 wouldn't be sufficiently descriptive for a user not 
familiary with our code names. I could be convinced otherwise... 

Having said that, consistency is of course good and it would make sense to 
update them all to be consistent in 3.5 if we don't do it earlier. 




Jeff McAffer [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 

06/11/2008 11:51 AM 


Please respond to
Equinox development mailing list equinox-dev@eclipse.org


To

'Equinox development mailing list' equinox-dev@eclipse.org 


cc




Subject

[equinox-dev] feature names

 









As discussed in the planning call this morning our feature names are all over 
the map. Here is a sample of some I see in the current testUpdates repo 

Eclipse Project Equinox bundle feature 
Eclipse P2 Developer Resources 
Equinox bundle source feature 
Equinox Provisioning Director Application Feature 
Equinox Provisioning Generator 
Equinox Provisioning Platform 

The should be… (in the corresponding order) 

Equinox Bundles 
Equinox p2 Developer Resources 
Equinox Bundles Developer Resources 
Equinox p2 Director Application 
Equinox p2 Generator Application 
Equinox p2 

Anyone have other ideas? 

Jeff___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



image001.gifimage003.pngimage004.png___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] [prov] Discourages access

2008-05-30 Thread Jeff McAffer

It was the joint decision of the team and the PMC that p2 would not have any
API.  By definition, anything that is not API is marked as x-internal =
true.  As a result, and by design, you get a warning that you are using
something that is not API.  I agree that this is annoying however, no one
will ever be able to say they were not warned that the stuff was not API
(believe me, many people have tried to claim they didn't know that stuff was
not API)

 

It would be interesting to raise an enhancement request on PDE to allow
developers to ignore the errors/warnings from certain bundles.  The problem
now is that if you turn off the warning you don't get it for any other uses
of non-API.  

 

Another strategy that we talked about at the time was introducing something
like x-api:= [internal | provisional |stable]  This would institutionalize
the notion of provisional API. This could then be tooled accordingly.  Of
course, it opens a number of other issues but they might be worth
considering as the main problem here is real.

 

Summary:  no joy for you right now but there might be some help from tools
if you enter an enhancement request.

 

Jeff

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Schaefer, Doug
Sent: Friday, May 30, 2008 12:13 PM
To: Equinox development mailing list
Subject: [equinox-dev] [prov] Discourages access

 

Hey gang,

 

I'm just wondering why you've hidden all of the provisional APIs away from
everyone other than p2 itself? I'm getting really tired of seeing
Discouraged access warnings in my generators and installers. Just curious
(and venting :)

 

Doug.

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] Shared profile registries

2008-05-30 Thread Jeff McAffer

I fyou run the installer in shared mode it uses one profile registry and
creates a new profile for every different thing you install.

Jeff

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:equinox-dev-
 [EMAIL PROTECTED] On Behalf Of Thomas Hallgren
 Sent: Friday, May 30, 2008 5:38 PM
 To: Equinox development mailing list
 Subject: [equinox-dev] Shared profile registries

 I'm curious about how the profile registry is intended to be used. At
 present, each eclipse installation will have it's own registry. Are
 there any plans to have some kind of registry hierarchy (global,
 machine, user) or other ideas that would make it possible to for
 instance discover all installed eclipse instances? Given that profiles
 can be roaming, parented, shared as read-only, etc. it seems a lot of
 thoughts has gone into this already.

 Regards,
 Thomas Hallgren

 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] Commit rights for Rafael Chaves have been expired

2008-05-20 Thread Jeff McAffer

AFAIK there are no special rights or priveleges associated with Emeritus
status.  It is more a recognition of the contributions made.  Otherwise
former committers would just drop off the face of the project.  The concept
is new.  See https://bugs.eclipse.org/bugs/show_bug.cgi?id=222350.

 

Jeff

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Arthorne
Sent: Tuesday, May 20, 2008 4:29 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Commit rights for Rafael Chaves have been expired

 


Just out of curiosity, what does Committer Emeritus mean? Does this give
them discounts at EclipseCon or anything? I haven't seen this term before...
(but I think it's a cool idea to honour ex-committers who made significant
contributions) 






[EMAIL PROTECTED] (portal on behalf of emo) 
Sent by: [EMAIL PROTECTED] 

05/20/2008 04:18 PM 


Please respond to
Equinox development mailing list equinox-dev@eclipse.org


To

equinox-dev@eclipse.org 


cc



Subject

[equinox-dev] Commit rights for Rafael Chaves have been expired

 






eclipse.equinox Committers,
Jeff McAffer has expired the commit rights for Rafael Chaves (rchaves). 
The reason for this change is:

Unfortunately, after talking with Rafael it turns out that he is no longer
able to contribute to Equinox.  In recognition of his various contributions
he is being added to the Committer Emeritus list.  Thanks!

To honor Rafael Chaves's contributions to the project, Jeff McAffer has
nominated Rafael Chaves for Committer Emeritus status.

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] Is the P2 installer supposed to work?

2008-05-20 Thread Jeff McAffer

Dunno Alex.  This works fine for me on windows but I see your point on the Mac.

 I had a look at the p2installer.ini:
 
 -showsplash
 org.eclipse.platform
 -vmargs
 -Xdock:icon=../Resources/Eclipse.icns
 -XstartOnFirstThread
 -Xms40m
 -Xmx256m
 -XX:MaxPermSize=256m
 -Dorg.eclipse.swt.internal.carbon.smallFonts
 
 No mention of the org.eclipse.equinox.p2.installDescription that the
 page suggests it looks for. I try adding it, and get a new message
 saying the error is invalid. That's maybe because the URL that that
 page points to is invalid:
 
   http://update.eclipse.org/eclipse/testUpdates/sdk-
 installer.properties
 - 404 not found

The doc is wrong.  The correct URL is 
http://download.eclipse.org/eclipse/testUpdates/sdk-installer.properties

 * When finished, you can delete the installer
 
 I deleted it. At least that worked ...

Cute.

Not really...

Jeff

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] Is the P2 installer supposed to work?

2008-05-20 Thread Jeff McAffer

I should have mentioned...

- Please enter a bug for this with your good steps.  Thanks!
- We have been running the installer on windows and the Mac quite regularly and 
even via JNLP.  This must be a quirk in the build as the product definition 
file looks fine.

Jeff

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:equinox-dev-
 [EMAIL PROTECTED] On Behalf Of Jeff McAffer
 Sent: Wednesday, May 21, 2008 12:18 AM
 To: 'Equinox development mailing list'
 Subject: RE: [equinox-dev] Is the P2 installer supposed to work?
 
 Dunno Alex.  This works fine for me on windows but I see your point on
 the Mac.
 
  I had a look at the p2installer.ini:
 
  -showsplash
  org.eclipse.platform
  -vmargs
  -Xdock:icon=../Resources/Eclipse.icns
  -XstartOnFirstThread
  -Xms40m
  -Xmx256m
  -XX:MaxPermSize=256m
  -Dorg.eclipse.swt.internal.carbon.smallFonts
 
  No mention of the org.eclipse.equinox.p2.installDescription that the
  page suggests it looks for. I try adding it, and get a new message
  saying the error is invalid. That's maybe because the URL that that
  page points to is invalid:
 
http://update.eclipse.org/eclipse/testUpdates/sdk-
  installer.properties
  - 404 not found
 
 The doc is wrong.  The correct URL is
   http://download.eclipse.org/eclipse/testUpdates/sdk-
 installer.properties
 
  * When finished, you can delete the installer
 
  I deleted it. At least that worked ...
 
 Cute.
 
 Not really...
 
 Jeff
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] [p2] Milestone update site for 3.4

2008-05-15 Thread Jeff McAffer

+1  I annotated the bug with more thoughts

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Timothy Webb
Sent: Thursday, May 15, 2008 5:17 PM
To: Equinox development mailing list
Subject: [equinox-dev] [p2] Milestone update site for 3.4

Apologies for the persistence on this issue, but we are actively using the
3.4 milestones site for provisioning to clients and the current corruption
is causing an outage to our users.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=232352

The current mismatch as described in the bug above guarantees that no
provisioning can be performed using the milestone site with p2 (the
artifacts.jar has M7 artifacts while the content.jar has M6a and earlier IUs
-- never the two shall meet).  

Is the expectation that this site should be available for provisioning?  Is
there a better site to use that contains the 3.4 milestone builds?  

Any assistance in cleaning up the site would be appreciated.

Thanks,

Tim

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] Equinox artifacts in Maven2 repository

2008-05-12 Thread Jeff McAffer

Ideally people would not have to copy the repos somewhere else just to get
Maven integration.  Perhaps someone in the community can provide/point to an
update site/p2 adapter for Maven?  That way you would just point Maven at
the main Eclipse repos (or a mirror).

Jeff

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:equinox-dev-
 [EMAIL PROTECTED] On Behalf Of Davanum Srinivas
 Sent: Monday, May 12, 2008 8:25 AM
 To: Equinox development mailing list
 Subject: Re: [equinox-dev] Equinox artifacts in Maven2 repository
 
 Saminda,
 
 I see some here - http://repo1.maven.org/eclipse/org/eclipse/equinox/
 
 -- dims
 
 On Mon, May 12, 2008 at 2:39 AM, Saminda Abeyruwan [EMAIL PROTECTED]
 wrote:
  Hi Devs,
 
  Is there a Maven2 repository that contains  the newest Equinox
 artifacts. I
  tried the Maven2 central repository, but couldn't find any.
 
 
 
  --
  Saminda Abeyruwan
 
  Senior Software Engineer
   WSO2 Inc. - www.wso2.org
  ___
   equinox-dev mailing list
   equinox-dev@eclipse.org
   https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 
 
 
 
 --
 Davanum Srinivas :: http://davanum.wordpress.com
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] RE: [eclipse-dev] Re: Eclipse 3.4 shape

2008-04-28 Thread Jeff McAffer

Thanks John.  We'll discuss this amongst the EPP team and see where to go.
We have much of the installer generation code working now and the UI is
underway.  Obviously there is lots of testing and little items to work
though

 

Jeff

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Arthorne
Sent: Monday, April 28, 2008 7:01 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] RE: [eclipse-dev] Re: Eclipse 3.4 shape

 


There is no deep technical problem with the installer - we intend to
continue producing it and work on improving it. This decision was really
about whether we can get the necessary level of polish and testing to commit
to promoting the installer as a first class way for the larger community
to get Eclipse applications in the Ganymede release. There are various
details to work out, and likely more will come up under wider testing.
Prioritizing installer work against p2 capabilities exposed to end users in
the platform, and p2 build and tooling support, the installer comes up less
important.  We'll get it in the best shape we can for 3.4, and it will be
great to have the EPP team looking into the details of creating installers
for EPP packages, since this is where bundle pooling across applications
really comes into play. 






Jeff McAffer [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 

04/26/2008 11:38 AM 


Please respond to
Equinox development mailing list equinox-dev@eclipse.org


To

'General development mailing list of the Eclipse project.'
[EMAIL PROTECTED] 


cc

'Equinox development mailing list' equinox-dev@eclipse.org 


Subject

[equinox-dev] RE: [eclipse-dev] Re: Eclipse 3.4 shape

 






I think the EPP team is interested in doing this.  Do you see any technical
reasons why it cannot be done or is this mainly a coordination/timing issue?

Jeff

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:eclipse-dev-
 [EMAIL PROTECTED] On Behalf Of Pascal Rapicault
 Sent: Wednesday, April 23, 2008 9:05 PM
 To: [EMAIL PROTECTED]
 Subject: [eclipse-dev] Re: Eclipse 3.4 shape
 
 
 Given the load of work that the p2 team is facing, it has been decided
 to
 not promote the p2-based installer as a delivery format for 3.4.0 (we
 may
 make it early-access).
 However we will try to deliver it for 3.4.1 and get the EPP packages
 converted as well.
 
 PaScaL
 
 (initial discussion:
 http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg08091.html)
 
 ___
 eclipse-dev mailing list
 [EMAIL PROTECTED]
 To change your delivery options, retrieve your password, or unsubscribe
 from this list, visit
 https://dev.eclipse.org/mailman/listinfo/eclipse-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] RE: [eclipse-dev] Re: Eclipse 3.4 shape

2008-04-26 Thread Jeff McAffer

I think the EPP team is interested in doing this.  Do you see any technical
reasons why it cannot be done or is this mainly a coordination/timing issue?

Jeff

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:eclipse-dev-
 [EMAIL PROTECTED] On Behalf Of Pascal Rapicault
 Sent: Wednesday, April 23, 2008 9:05 PM
 To: [EMAIL PROTECTED]
 Subject: [eclipse-dev] Re: Eclipse 3.4 shape

 Given the load of work that the p2 team is facing, it has been decided
 to
 not promote the p2-based installer as a delivery format for 3.4.0 (we
 may
 make it early-access).
 However we will try to deliver it for 3.4.1 and get the EPP packages
 converted as well.

 PaScaL

 (initial discussion:
 http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg08091.html)

 ___
 eclipse-dev mailing list
 [EMAIL PROTECTED]
 To change your delivery options, retrieve your password, or unsubscribe
 from this list, visit
 https://dev.eclipse.org/mailman/listinfo/eclipse-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] Equinox IP log

2008-04-18 Thread Jeff McAffer

Thanks John, this is a good start.  I wonder if there is something we can
harvest from the Orbit IP log structure.  DJ?  Thoughts?

 

It would be generally useful to have the CQ numbers associated with the
third party code.

 

One important not is that I believe we have a policy about protecting email
addresses.  We went through this in Orbit where the decision was to not
include them.  DJ, do you recall anything about this?  Either way, unless
there is a compelling reason to include them they should be removed.

 

Jeff

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Arthorne
Sent: Friday, April 18, 2008 4:00 PM
To: equinox-dev@eclipse.org
Subject: [equinox-dev] Equinox IP log

 


FYI, I have committed an initial Equinox IP log: 

http://www.eclipse.org/equinox/documents/iplogs/EquinoxIPlog.html 

We had initially started with a separate IP log per component, but as I
started to update them I found it painful to track the committer lists
separately so I combined them. Also there is only one IP log URL that can be
linked from http://eclipse.org/projects/listofprojects.php.  The third party
software list is not yet complete, and I have not processed all the p2
contributions since p2 graduation.  Can all committers quickly scan the
committer list and ensure they are listed, and their login, organization,
and email addresses are correct? I believe we only need to record committers
who contributed to the 3.4 release - this excludes people who committed only
to the incubator project, and those who only committed prior to the 3.3
release (someone please correct me if this is wrong).

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] [p2] plug-in versions

2008-04-14 Thread Jeff McAffer

Agreed we can talk about this tomorrow.  In the mean time, my 2c is that we
call it 1.0.  It is a release and we are believing that it is useful/works/.
It would be strange IMHO to have the SDK based on something that we don't
feel good enough about to call 1.0.

 

As for JSCH, we do not control the numbering of their bundles so we ship
whatever we get.

 

Jeff

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Arthorne
Sent: Monday, April 14, 2008 10:23 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] [p2] plug-in versions

 


Let's discuss and resolve at the Equinox meeting tomorrow. I can be
convinced either way, but a number  1.0 provides a good hint to adopters
that referencing p2 bundles isn't a good idea - since there is no API,
absolutely anything can change right up to the day of the 3.4 release, and
in maintenance releases. We may even want to refactor and
add/delete/merge/split bundles before delivering a real API in the next
release. I also noticed we shipped a 0.1.0 Jsch bundle in 3.3, and there are
perhaps other examples in Ganymede projects.  The version numbers really
describe API rather than functionality. 





Thomas Watson [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 

04/14/2008 09:42 AM 


Please respond to
Equinox development mailing list equinox-dev@eclipse.org


To

Equinox development mailing list equinox-dev@eclipse.org 


cc



Subject

Re: [equinox-dev] [p2] plug-in versions

 






My 2 cents ...

For Ganymede the plan is to have 1.0 p2 functionality. This should not imply
that we will have p2 1.0 API. I imagine for the first release of p2 we are
going to have lots of bundles start to use the internal.provisional APIs
because there is no public API available and they will have to resort to
using the internal.provisional APIs. I suggest we release with all p2 bundle
versions as 1.0. When we graduate to real API for p2 then the bundles can be
increased to 2.0.

This way we can recommend a version range of [1.0, 2.0) for early adopters
use internal.provisional API. In a future release when p2 does include real
API then the early adopters will be able to clearly see which bundles
graduated real API. I suppose the same can be done with 0.1.0 versions with
a range of [0.1.0, 1.0) and [1.0, 2.0) after the real API is introduced. But
a bundle version of 0.1.0 does not give the impression that p2 is releasing
1.0 functionality in Ganymede.

Tom



Inactive hide details for John Arthorne ---04/14/2008 07:31:09 AM---I don't
think we ever decided on this. The thinking was thaJohn Arthorne
---04/14/2008 07:31:09 AM---I don't think we ever decided on this. The
thinking was that since no API was being declared, we might leave the
plug-ins with



From: 


John Arthorne [EMAIL PROTECTED] 



To: 


Equinox development mailing list equinox-dev@eclipse.org 



Date: 


04/14/2008 07:31 AM 



Subject: 


Re: [equinox-dev] [p2] plug-in versions

 

  _  





I don't think we ever decided on this. The thinking was that since no API
was being declared, we might leave the plug-ins with a number  1.0 and then
move to 1.0 in the first release that contains real API (likely 3.5).
Typically the initial API of a plug-in appears in version 1.0 of the
plug-in. 




Chris Aniszczyk [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 

04/10/2008 07:23 PM 


Please respond to
Equinox development mailing list equinox-dev@eclipse.org

 


To

Equinox development mailing list equinox-dev@eclipse.org 


cc




Subject

[equinox-dev] [p2] plug-in versions

 










I noticed that all of p2 plug-ins are currently 0.10.qualifier... shouldn't
this be 1.0.0.qualifier since these have been graduated and will be included
in the SDK for 3.4?

I ask this as I'm trying to straighten out some plug-in dependency ranges in
PDE.

Cheers,

---
Chris Aniszczyk | IBM Lotus | Eclipse Committer |
http://mea-bloga.blogspot.com/ http://mea-bloga.blogspot.com |
+1.860.839.2465___
equinox-dev mailing list
equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

image001.gifimage002.gif___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] [prov] Auto installing touchpoint

2008-04-14 Thread Jeff McAffer

Incubator or not doesn't really matter to me.  I am just pushing on
contributions.  I dunno what is involved in doing untar.  The point of
getting it out there is that if you had the requirement, it is likely that
others do too.

Jeff

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:equinox-dev-
 [EMAIL PROTECTED] On Behalf Of Schaefer, Doug
 Sent: Monday, April 14, 2008 10:31 AM
 To: Equinox development mailing list
 Subject: RE: [equinox-dev] [prov] Auto installing touchpoint
 
 I guess it comes to whether people are in a hurry for it or not. Why
 not
 just follow the regular contribution process and get it into the
 mainstream? Incubators are for new ideas that need soak time and eyes
 to
 see if their any good. I'm not so worried about this one.
 
 The way I've implemented the untar action it is trivial, but it misses
 the point. I shouldn't have to change the Native touchpoint to add in
 new actions. I'll put together a proposal with a patch and set up a
 bug.
 But this will likely have to wait for a few weeks, but then everyone
 should be busy finishing off 3.4.
 
 Doug.
 
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Jeff McAffer
 Sent: Sunday, April 13, 2008 8:00 PM
 To: 'Equinox development mailing list'
 Subject: RE: [equinox-dev] [prov] Auto installing touchpoint
 
  I'm not a big incubator kind-a guy so I'll probably wait for the 3.5
  stream to open up to work on this. In the meantime I've cloned the
  native touchpoint and added the Apache code and my untar action in.
 
 Not sure how to interpret this.  Contributing it to the incubator is
 not
 a large overhead.  Open a bug report and attach the code.  You need to
 take some action with respect to the cloned EPL code anyway.  This is
 even easier...
 
 Jeff
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] [prov] Auto installing touchpoint

2008-04-12 Thread Jeff McAffer

We can copy the Apache code and include it in the touchpoint bundle (as one
option).  Either way, I would suggest contributing the tarball code to the
p2 incubator.  If someone wants/needs to use it or has some time to do
integration then they can do so.

Eventually agents should be able to provision themselves...

Jeff

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:equinox-dev-
 [EMAIL PROTECTED] On Behalf Of Schaefer, Doug
 Sent: Monday, April 07, 2008 9:08 PM
 To: Equinox development mailing list
 Subject: RE: [equinox-dev] [prov] Auto installing touchpoint
 
 Cool, if it was there I'd be very impressed.
 
 I just have an untar action very similar to the unzip in the Native
 touchpoint. I'm using the tar and bzip2 packages from Apache as well as
 the builtin gzip input stream. It could be generic enough to put in the
 Native. But we'd need to figure out how to introduce the Apache
 dependencies. They are a part of the ant.jar file in the org.apache.ant
 plugin (which is where I got them). But it's full of other stuff too.
 
 Cheers,
 Doug.
 
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Pascal Rapicault
 Sent: Monday, April 07, 2008 8:04 PM
 To: Equinox development mailing list
 Cc: Equinox development mailing list; [EMAIL PROTECTED]
 Subject: Re: [equinox-dev] [prov] Auto installing touchpoint
 
 It is something that we would like to be able to do, but it won't be
 implemented before the next release.
 Could you tell us more about what are the actions provided by your
 touchpoint and what you are doing with the tarball?
 If it is really simple and generic we could probably make it available
 in the native touchpoint.
 
 PaScaL
 
 
 
 |
 | From:  |
 |
 
 --
 -
 -|
   |Schaefer, Doug [EMAIL PROTECTED]
 |
 
 --
 -
 -|
 |
 | To:|
 |
 
 --
 -
 -|
   |Equinox development mailing list equinox-dev@eclipse.org
 |
 
 --
 -
 -|
 |
 | Date:  |
 |
 
 --
 -
 -|
   |04/07/2008 07:15 PM
 |
 
 --
 -
 -|
 |
 | Subject:   |
 |
 
 --
 -
 -|
   |[equinox-dev] [prov] Auto installing touchpoint
 |
 
 --
 -
 -|
 
 
 
 
 
 Hey gang,
 
 The more I get into p2 the more I'm impressed by it. I have written my
 own touchpoint that installs tarballs and have been able to generate
 the
 right repositories to download and install them from the MinGW website.
 Very cool and easy once you know how.
 
 The next part of this is to figure out how to get the plug-in with my
 touchpoint into people's hands. The ultimate would be for this to be
 represented in the metadata somehow where I could mark this as a
 capability my plug-in provides that the engine could auto install
 before
 installing the artifacts that need it. Is this capability there, or
 something nifty we could add next release.
 
 Cheers,
 Doug___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Welcome Neil Bartlett as a new eclipse.incubator Committer

2008-04-07 Thread portal on behalf of Jeff McAffer

eclipse.incubator.eclipse.incubator.equinox Committers,
This automatically generated message marks the completion of all the legal
paperwork and webmaster provisioning for Neil Bartlett. Neil Bartlett is a
new full Committer on the  component of the eclipse.incubator project.

Welcome!
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Welcome Boris Bokowski as a new eclipse.incubator Committer

2008-04-07 Thread portal on behalf of Jeff McAffer

eclipse.incubator.eclipse.incubator.equinox Committers,
This automatically generated message marks the completion of all the legal
paperwork and webmaster provisioning for Boris Bokowski. Boris Bokowski is
a new full Committer on the  component of the eclipse.incubator project.

Welcome!
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] p2 metadata generation

2008-04-03 Thread Jeff McAffer

Michael, 

 

Plugins == bundles.  There is nothing special in the generator that could
distinguish between the two ('cause there is no difference).  What are you
doing that is not working?

 

Jeff

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hampel, Michael
Sent: Wednesday, April 02, 2008 7:50 AM
To: equinox-dev@eclipse.org
Subject: [equinox-dev] p2 metadata generation

 

Hello,

 

can someone please tell me if it is possible to generate the needed p2
metadata for pure bundles(no eclipse plugins) in a local

directory and how I would do this?

 

thanx in advance for any help,

 

Michael

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] App server classpath

2008-04-03 Thread Jeff McAffer

Hey Emmanuel, 

 

Great to see you using Equinox.  These kinds of questions are best asked on
the Equinox newsgroup

 
http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.equino
x

There you will find a diverse user community who may have had the same issue
and have solutions or, conversely, will benefit from your questions and
their answers.

 

When your issues are resolved, please consider writing about your
experiences on the newsgroup and/or wiki .

Jeff

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Emmanuel Potvin
Sent: Wednesday, April 02, 2008 3:05 PM
To: 'Equinox development mailing list'
Subject: [equinox-dev] App server classpath

 

When I execute 

 

InitialContext context = new InitialContext(); 

 

Inside a bundle deployed in a web app in jboss, I got a :

 

javax.naming.NoInitialContextException: Cannot instantiate class:
org.jnp.interfaces.NamingContextFactory [Root exception is
java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory]

 

The same line inside a servlet method works fine. How can I tell my bundle
to search inside jboss libraries??

 

Emmanuel

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Committer vote for Neil Bartlett has concluded successfully

2008-04-03 Thread portal on behalf of Jeff McAffer

eclipse.incubator.eclipse.incubator.equinox Committers,
This automatically generated message marks the successful completion of
voting for Neil Bartlett to receive full Committer status on the  component
of the eclipse.incubator project. The next step is for the PMC to approve
this vote, followed by the EMO processing the paperwork and provisioning
the account.

Vote summary: 14/0/0 with 11 pending 
  +1  John Arthorne
  +1  Oleg Besedin
  +1  Stoyan Boshev
   ?  Robert Connell
   ?  Sonia Dimitrov
   ?  Jennifer Fogell
   ?  Olivier Gruber
  +1  Ted Habeck
  +1  BJ Hargrave
  +1  Kim Horne
  +1  DJ Houghton
  +1  Simon Kaegi
   ?  Peter Kriens
  +1  Stefan Liebig
  +1  Martin Lippert
  +1  Jeff McAffer
   ?  Susan McCourt
   ?  Kim Moir
   ?  Andrew Niefer
   ?  Pascal Rapicault
   ?  Jay Rosenthal
  +1  Dave Stevenson
  +1  Thomas Watson
   ?  Matthew Webster
  +1  Ikuo Yamasaki

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO [EMAIL PROTECTED]

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Committer vote for Neil Bartlett has been approved by the PMC

2008-04-03 Thread portal on behalf of Jeff McAffer

eclipse.incubator.eclipse.incubator.equinox Committers,
This automatically generated message marks the PMC's approval of the vote
for Neil Bartlett's full Committer status on the eclipse.incubator.equinox
component of the eclipse.incubator project. The next step is for the
project lead to return to the portal and fill in the CVS package and
employer information for Neil Bartlett.

The PMC's comments were: Great.  Welcome Neil

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO [EMAIL PROTECTED]

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Committer vote for Boris Bokowski has been approved by the PMC

2008-04-03 Thread portal on behalf of Jeff McAffer

eclipse.incubator.eclipse.incubator.equinox Committers,
This automatically generated message marks the PMC's approval of the vote
for Boris Bokowski's full Committer status on the eclipse.incubator.equinox
component of the eclipse.incubator project. The next step is for the
project lead to return to the portal and fill in the CVS package and
employer information for Boris Bokowski.

The PMC's comments were: Great.  Welcome Boris

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO [EMAIL PROTECTED]

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Committer vote for Heiko Seeberger has been approved by the PMC

2008-03-28 Thread portal on behalf of Jeff McAffer

eclipse.incubator.eclipse.incubator.equinox Committers,
This automatically generated message marks the PMC's approval of the vote
for Heiko Seeberger's full Committer status on the
eclipse.incubator.equinox component of the eclipse.incubator project. The
next step is for the project lead to return to the portal and fill in the
CVS package and employer information for Heiko Seeberger.

The PMC's comments were: good deal

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO [EMAIL PROTECTED]

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] [prov] should p2 be in the RCP sdk

2008-03-27 Thread Jeff McAffer

The RCP downloads from Eclipse have update.configurator in them.  This is
convenient because that configurator automatically discovers and installs
all the bundles so people getting started with RCP do not need to
laboriously list out the things they need.  It is however unfortunate in the
case of someone wanting to use p2 in the RCP context.  Issues

-  How do they get all the p2 bundles into their target and then
into their RCP product (need a p2 feature?)

-  If I start with something that is UM based (e.g., the RCP SDK)
and then add in p2, what do I have to do to make my app use p2 rather than
update.configurator.

 

Some amount of this can be resolved in doc but there are some packaging
considerations as well.

 

Note that in the past we have resisted putting UM in the RCP downloads in
the interest of keeping RCP slim and trim.  I'm still in favour of that.  I
do wonder though if we can do something with the simple configurator or
directory watcher to get the net effect (auto installation of bundles) that
we have now without the UM aftertaste.

 

Jeff

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] Incubator request for Extensions/Services Integration work

2008-03-27 Thread Jeff McAffer

+1

 

This fits well with investigations we need to do for e4 as well as the SAT
work and some discussions with James Branigan from the Jazz team around
stuff they have been doing.

 

Need a pithy name for the workarea.  component programming model (CPM)
perhaps?  As Oleg points out, it is really something that is broader than
just services and extensions.

 

Jeff

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Aniszczyk
Sent: Thursday, March 27, 2008 11:31 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Incubator request for Extensions/Services
Integration work

 

+1 also

Cheers,

---
Chris Aniszczyk | IBM Lotus | Eclipse Committer |
http://mea-bloga.blogspot.com | +1.860.839.2465

Inactive hide details for Oleg Besedin ---03/27/2008 10:24:40 AM---+1 from
me. If needed, I can help with IPZilla. The area proOleg Besedin
---03/27/2008 10:24:40 AM---+1 from me. If needed, I can help with IPZilla.
The area probably could be created with a more gener



From:


Oleg Besedin [EMAIL PROTECTED]



To:


Equinox development mailing list equinox-dev@eclipse.org



Date:


03/27/2008 10:24 AM



Subject:


Re: [equinox-dev] Incubator request for Extensions/Services Integration work

  _  





+1 from me. If needed, I can help with IPZilla. 

The area probably could be created with a more general purpose - something
like component models investigation?
equinox-incubator/component-model/service-injection 

Thanks, 
Oleg 





Neil Bartlett [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 

03/27/2008 10:53 AM 


Please respond to
Equinox development mailing list equinox-dev@eclipse.org


To

Equinox development mailing list equinox-dev@eclipse.org 


cc




Subject

[equinox-dev] Incubator request for Extensions/Services Integration work

 









Hello,

I have been doing some investigative work recently in the area of
integrating extensions with OSGi services. As a result of this, I have
developed a small framework for dynamically injecting services into
extension objects according to metadata defined via the extension
registry. As a very simple example, suppose we have an extension
object (e.g. a ViewPart) which has a method
setLogReader(LogReaderService). We can declare an injected bean
extension as follows:

  extension point=...injectedBeans
  bean id=logReaderView
class=org...LogReaderView
  injectSingle interface=org.osgi.service.log.LogReaderService
set=setLogReader/
  /bean
  /extension

And then the actual view extension as:

  extension point=org.eclipse.ui.views
  view class=org...InjectedExtensionFactory:logReaderView
name=Log Reader/
  /extension

This results in all objects instantiated from the log view extension
being dynamically injected with the log reader service as it becomes
available (and un-injected when it goes away).

I would like to request a work area under the Equinox incubator as a
home for this code so that others can test it and experiment with this
and other approaches to the extensions/services integration problem.

Regards,
Neil
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



image001.gifimage002.pngimage003.png___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] [prov] p2 for starters

2008-03-27 Thread Jeff McAffer

This is likely related to ProvisioningHelper which is another interesting
utilty class.  It would be good to factor things to provide a simple API to
much of this function.  Helmut, can you synthesize the ProvisioningUtil and
ProvisioningHelper classes to make something that you think makes sense?
We'll have to see what to call it and where to put it and how to get it but
the idea is attractive.  Keep in mind here that we absolutely have to avoid
creating another Platform class.

Jeff

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:equinox-dev-
 [EMAIL PROTECTED] On Behalf Of Haigermoser, Helmut
 Sent: Thursday, March 27, 2008 11:11 AM
 To: Equinox development mailing list
 Subject: RE: [equinox-dev] [prov] p2 for starters
 
 Thanks Susan, that information is appreciated! :)
 I am already on the way implementing my own query provider and will let
 you guys know how this went,
 our workflow is certainly somewhat different to yours and this will
 probably prove your framework to be flexible enough if I succeed  :)
 
 One small thing I stumbled over regarding the provisional APIs: There
 is
 this class,
 org.eclipse.equinox.internal.provisional.p2.ui.operations.ProvisioningU
 t
 il that would be a good helper class to use, it helps register
 repositories etc. However, it's a UI class rendering it unusable for
 us,
 the reason for it being a UI-class seems to be the ProvUIActivator
 class
 being used in service lookups, not sure if that can be changed...
 
 So, thanks for this first bunch of answers!! :)
 Chao,
 hh
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Susan Franklin
 McCourt
 Sent: 27 March 2008 15:49
 To: Equinox development mailing list
 Subject: Re: [equinox-dev] [prov] p2 for starters
 
 Hi, Helmut.
 I work on the p2 UI, so I can answer some of the UI questions and will
 defer to the core guys to answer the rest..
 
 - Is p2 allowing nested groups like these:
   snip
 - Can you suggest a strategy on how to best filter a repos content,
 both
 based on users choices and entitlement? Is there a filter layer we can
 put on top of a repository or can we use special queries to achieve
 this? This one revolves around reducing the available
 groups/categories
 in the UI from the massive amount of available ones, also the user
 should not see any IUs (s)he won't be allowed to use later on...
 
 There's not really a canned taxonomy for how to traverse a tree of
 IU's.
 IU's can refer to each other through their required capabilities, or
 for
 that matter using properties that you define. Groups happen to be a
 property that we define for filtering, but you could define your own.
 
 We traverse a repo in a particular way in the admin UI, and a
 different,
 (yet similar way) in the SDK Update and Install group. The model
 elements are set up so that you can define this taxonomy in terms of
 queries. See the classes IQueryProvider and its implementors. You can
 traverse the tree of repos using queries such as AVAILABLE_IUS,
 INSTALLED_IUS, etc. That way any app can have its own filtering or
 hierarchy. The UI components such as the UpdateAndInstallGroup, and
 some
 of the actions, etc. are passed a query provider by the caller so that
 the particular tree can be built. This was designed so that the queries
 can be optimized at the server if need be, rather than relying on
 UI-side technology like viewer filters to accomplish this.
 
 That said, there are probably some built-in assumptions that have crept
 into the code, so if you were to try this out, it would help prove that
 what I say is true. Note that all of our API is provisional for 3.4, so
 we expect some iteration as clients adopt, and I'd love to see someone
 try to build a completely different view of the world using this
 mechanism - that's why it's there.
 
 - How can we best listen to the installation process, the job
 framework
 seems not to allow us to retrieve the percent complete of an
 installation? This question originates from looking at our old
 installer
 that would send us strings like these: Installation 5% complete:
 Currently installing eclipse/plugins/com.windriver.ide_3.0.0.jar, can
 we hope to get the same amount of progress information from p2 and the
 jobs framework?
 
 We use the jobs framework and IProgressMonitor. The default progress
 reporting for jobs shows an overall percent complete and assigns sub
 monitors for reporting of subtasks such as downloads. The
 IProgressService framework allows you to plug in your own way of
 showing
 this progress. Right now we use the workbench progress reporting, so
 that as a download occurs, you see progress in the workbench status
 icon
 and can open the progress view to see the progress of the running jobs.
 In the future we may extend the standard progress reporting so that
 progress could be shown in-line in the install dialog, but probably
 won't get to this for 3.4.
 
 I'll defer to the core guys for the rest, things

[equinox-dev] Vote for Committer status for Boris Bokowski has started

2008-03-27 Thread portal on behalf of Jeff McAffer

eclipse.incubator.eclipse.incubator.equinox Committers,
This automatically generated message signals that Jeff McAffer has
nominated Boris Bokowski as a Committer on the  component of the
eclipse.incubator project. The reason given is as follows:

Based on community interest we are setting up a component programming model
work area in the equinox incubator.  Boris is one of the driving forces
behind the programming model for the UI in e4 and has lots of great input
and usecases to bring to the table.  Having him on-board for this
investigation would be beneficial to all.


The vote is being held via the MyFoundation portal: voters *must* use the
portal for the votes to be properly recorded.  The voting will continue
until either all 25 existing Committers have voted or until they have been
given enough time to vote, even if they do not do so (defined as at least
one week). Boris Bokowski must receive at least three +1s and no -1s for a
successful election.

Eligible Committers must cast their votes through their My Foundation
portal page (do NOT just reply to this email; your vote will not be
correctly recorded unless you use the portal):

http://portal.eclipse.org/

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO [EMAIL PROTECTED]

The project Committers eligible to vote are:

John Arthorne
Oleg Besedin
Stoyan Boshev
Robert Connell
Sonia Dimitrov
Jennifer Fogell
Olivier Gruber
Ted Habeck
BJ Hargrave
Kim Horne
DJ Houghton
Simon Kaegi
Peter Kriens
Stefan Liebig
Martin Lippert
Jeff McAffer
Susan McCourt
Kim Moir
Andrew Niefer
Pascal Rapicault
Jay Rosenthal
Dave Stevenson
Thomas Watson
Matthew Webster
Ikuo Yamasaki

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] Incubator request for Extensions/Services Integration work

2008-03-27 Thread Jeff McAffer

Yeah, I was going to point you at this.  In the incubator we are pretty open
to contributions.  People like you, Neil and others who have stuff to
contribute are more than welcome.  We should do a set of nominations now
that most of the active committers have agreed that doing this makes sense.
I started some elections

Jeff

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:equinox-dev-
 [EMAIL PROTECTED] On Behalf Of Boris Bokowski
 Sent: Thursday, March 27, 2008 8:54 PM
 To: Equinox development mailing list
 Subject: Re: [equinox-dev] Incubator request for Extensions/Services
 Integration work
 
 +1 from me too, and I would be interested in participating. How does
 this work? Will initial committers be nominated?
 
 Boris
 
 On Thu, Mar 27, 2008 at 1:04 PM, Jeff McAffer [EMAIL PROTECTED] wrote:
 
 
 
 
  +1
 
 
 
  This fits well with investigations we need to do for e4 as well as
 the SAT
  work and some discussions with James Branigan from the Jazz team
 around
  stuff they have been doing.
 
 
 
  Need a pithy name for the workarea.  component programming model
 (CPM)
  perhaps?  As Oleg points out, it is really something that is broader
 than
  just services and extensions.
 
 
 
  Jeff
 
 
 
 
 
 
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of Chris Aniszczyk
   Sent: Thursday, March 27, 2008 11:31 AM
 
   To: Equinox development mailing list
 
 
  Subject: Re: [equinox-dev] Incubator request for Extensions/Services
  Integration work
 
 
 
 
 
  +1 also
 
   Cheers,
 
   ---
   Chris Aniszczyk | IBM Lotus | Eclipse Committer |
  http://mea-bloga.blogspot.com | +1.860.839.2465
 
   Oleg Besedin ---03/27/2008 10:24:40 AM---+1 from me. If needed, I
 can help
  with IPZilla. The area probably could be created with a more gener
 
 
 
   From:
 
 
   Oleg Besedin [EMAIL PROTECTED]
 
 
 
   To:
 
 
   Equinox development mailing list equinox-dev@eclipse.org
 
 
 
   Date:
 
 
   03/27/2008 10:24 AM
 
 
 
   Subject:
 
 
   Re: [equinox-dev] Incubator request for Extensions/Services
 Integration
  work
   
 
 
 
 
 
 
   +1 from me. If needed, I can help with IPZilla.
 
   The area probably could be created with a more general purpose -
 something
  like component models investigation?
  equinox-incubator/component-model/service-injection
 
   Thanks,
   Oleg
 
 
 
 
 
  Neil Bartlett [EMAIL PROTECTED]
   Sent by: [EMAIL PROTECTED]
 
  03/27/2008 10:53 AM
 
 
  Please respond to
   Equinox development mailing list equinox-dev@eclipse.org
 
 
  To
 
  Equinox development mailing list equinox-dev@eclipse.org
 
 
  cc
 
 
 
 
  Subject
 
  [equinox-dev] Incubator request for Extensions/Services Integration
 work
 
 
 
 
 
 
 
 
 
 
 
   Hello,
 
   I have been doing some investigative work recently in the area of
   integrating extensions with OSGi services. As a result of this, I
 have
   developed a small framework for dynamically injecting services into
   extension objects according to metadata defined via the extension
   registry. As a very simple example, suppose we have an extension
   object (e.g. a ViewPart) which has a method
   setLogReader(LogReaderService). We can declare an injected bean
   extension as follows:
 
 extension point=...injectedBeans
 bean id=logReaderView
   class=org...LogReaderView
 injectSingle
 interface=org.osgi.service.log.LogReaderService
   set=setLogReader/
 /bean
 /extension
 
   And then the actual view extension as:
 
 extension point=org.eclipse.ui.views
 view class=org...InjectedExtensionFactory:logReaderView
   name=Log Reader/
 /extension
 
   This results in all objects instantiated from the log view extension
   being dynamically injected with the log reader service as it becomes
   available (and un-injected when it goes away).
 
   I would like to request a work area under the Equinox incubator as a
   home for this code so that others can test it and experiment with
 this
   and other approaches to the extensions/services integration problem.
 
   Regards,
   Neil
   ___
   equinox-dev mailing list
   equinox-dev@eclipse.org
   https://dev.eclipse.org/mailman/listinfo/equinox-dev
   ___
   equinox-dev mailing list
   equinox-dev@eclipse.org
   https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 
  ___
   equinox-dev mailing list
   equinox-dev@eclipse.org
   https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] +1 for Andrew Niefer

2008-02-28 Thread portal on behalf of Jeff McAffer

+1
Andrew is awesome!

Voting summary: http://portal.eclipse.org/


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Committer vote for Andrew Niefer has been approved by the PMC

2008-02-28 Thread portal on behalf of Jeff McAffer

eclipse.equinox.eclipse.equinox.p2 Committers,
This automatically generated message marks the PMC's approval of the vote
for Andrew Niefer's full Committer status on the eclipse.equinox.p2
component of the eclipse.equinox project. The next step is for the project
lead to return to the portal and fill in the CVS package and employer
information for Andrew Niefer.

The PMC's comments were: Andrew is even more awesome

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO [EMAIL PROTECTED]

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] [prov] manifest changes

2008-02-21 Thread Jeff McAffer

Feels like a missing Update classpath or some such.  This all works fine
for me though I do have foundation 1.1 installed.

Jeff

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:equinox-dev-
 [EMAIL PROTECTED] On Behalf Of Timothy Webb
 Sent: Thursday, February 21, 2008 6:07 PM
 To: Equinox development mailing list
 Subject: Re: [equinox-dev] [prov] manifest changes

 The errors I receive are all due to is not accessible due to
 restriction on required library jre..\lib\rt.jar.  It appears
 that PDE is still attempting to include those values from my JRE.  My
 guess would be that since I don't have a foundation 1.1 compatible JVM
 installed, it is continuing to try and resolve the classes from the
 1.6 JRE that I have configured for this workspace instead of using the
 org.apache.xerces project that is available.  I do indeed see
 org.apache.xerces listed in the Plug-in Dependencies for this project.

 As a complete guess, I modified by hand the .classpath file.  I moved
 the Plug-in Dependencies library prior to the JRE one.  Doing this
 fixed the compile errors for me.  I'm guessing we probably shouldn't
 be dependent on the ordering of the build path for something like
 this...?

 On Feb 21, 2008, at 4:44 PM, DJ Houghton wrote:

  This is strange... I'm not sure why you would get errors. What type
 of
  errors do you see? Are they to the effect of ...can't see due to
  access
  restriction on org.apache.xerces?

  Either way, the code has been checked out for the test build so I
 have
  reverted the change in HEAD so if you reload you should be ok. But
  we still
  need to figure out why you are getting these errors.

  [EMAIL PROTECTED] wrote on 02/21/2008 04:28:19 PM:

  When I picked up this change on two different systems, I receive
  build
  errors on the artifact repository about not being able to find the
  various XML files.  I do have xerces in my workspace and doing the
  normal tricks to get the project building seem to be failing.  Any
  suggestions on why this change would break compilation?

  Thanks,
  Tim

  On Feb 21, 2008, at 2:47 PM, DJ Houghton wrote:

  I have released a change to the manifest file for the
  org.eclipse.equinox.p2.artifact.repository project so Kim can test
  the
  Foundation EE in the build. If you have this project (and this
  change)
  loaded into your workspace and a Foundation 1.1 VM set up, it will
  also
  require that you have a project like Xerces also in your workspace.
  Xerces
  is already in the project set file so you should be good, but I
 just
  wanted
  to give you a heads up in case you see strange errors about not
  finding XML
  classes.

  ___
  equinox-dev mailing list
  equinox-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/equinox-dev

  ___
  equinox-dev mailing list
  equinox-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/equinox-dev

 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] [prov] use of Foundation 1.1

2008-02-19 Thread Jeff McAffer

There are several projects in p2 currently that list J2SE 1.4 and Foundation
1.1 in the BREE for the bundle. This is good but they list them in that
order. The net result is that J2SE 1.4 is used to compile the code.  What
happens in some cases people don't have 1.4 so PDE uses the next best thing
which ends up being 1.5 or 1.6. In the end we get references to things we
ought not.  In particular, I just had a setup in which there were no XML api
in my workspace or target yet everything was compiling ok.  Took quite some
time to figure out how this could be so.

 

If everyone agrees, I will go through the projects and update them
accordingly.

 

Jeff

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

1 2 >

1 - 100 of 180 matches

Mail list logo