date:20080414

Re: [equinox-dev] [prov] p2 build contribution

2008-04-14 Thread Pascal Rapicault

I have also added
+ Bug 216050. [prov] SimplePlanner.sortOperations
ArrayIndexOutOfBoundsException (NEW)



 
  From:   Pascal Rapicault/Ottawa/[EMAIL PROTECTED] 
 

 
  To: Equinox development mailing list 
 

 
  Date:   04/14/2008 10:21 PM   
 

 
  Subject:[equinox-dev] [prov] p2 build contribution
 

 






The map file has been updated for the following Bug changes:
+ Bug 97100.  element with type="web" should not be used as a
update site (WONTFIX)
+ Bug 203760. [prov] [repo] ensure URLs are properly encoded (NEW)
+ Bug 204177. [ui] Should have a refresh action in available features page
(FIXED)
+ Bug 204347. [prov] Extension to the PDE Target provisioner (FIXED)
+ Bug 215927. [prov] Authentication upon connection (FIXED)
+ Bug 216028. [ui] Available IU view enhancements (NEW)
+ Bug 216029. [prov] [ui] Installed IU view enhancements (FIXED)
+ Bug 217093. [prov] Cleanup of SimpleMetadataRepositoryFactory's cache
when repository is removed (FIXED)
+ Bug 218186. [prov] [ui] update progress dialogues have workbench as
parent (FIXED)
+ Bug 219888. [ui] - "Other" category shows up even if empty (FIXED)
+ Bug 220554. Support associateSitesURL in UM repository (FIXED)
+ Bug 221087. [ui] Size dialog seems to create a new plan (FIXED)
+ Bug 221412. Remove "verify" attribute on SimpleArtifactRepository (FIXED)
+ Bug 221434. [um] installing from an old update site download plugins and
features in the wrong place (FIXED)
+ Bug 221710. Add links to Native touchpoint (FIXED)
+ Bug 222445. Move extensionlocation repo implementation (FIXED)
+ Bug 222565. Strings need to be externalized (NEW)
+ Bug 222621. Metadata generation for chmod and ln actions (NEW)
+ Bug 223095. Metadata generator should consider features for plugin shape
(FIXED)
+ Bug 223447. [ui] check for update button disabled after click and unclick
(FIXED)
+ Bug 224241. [ui] - Enable revert for M7 (NEW)
+ Bug 224244. [reconciler] Problems when removing higher version of
singleton bundle (FIXED)
+ Bug 224482. [reconciler] Need to watch the platform.xml (NEW)
+ Bug 224710. Need to better handle problem files on server (NEW)
+ Bug 225054. platform.xml location issues with spaces in path (FIXED)
+ Bug 225634. Excessive flushing when writing using XMLWriter (FIXED)
+ Bug 226041. MirrorSelector constructor doesn't handle spaces well (FIXED)
+ Bug 226095. [ui] ProvisionAdminUI fails to display profiles (FIXED)
+ Bug 226116. [ui] cleanup unused messages (FIXED)
+ Bug 226129. missing legal files in p2 source bundles (FIXED)
+ Bug 226202. [shared] bundles.info not read in shared install mode (FIXED)
+ Bug 226219. Re-enable revert in planner (FIXED)
+ Bug 226344. FeatureParser doesn't close streams (FIXED)
+ Bug 226345. UpdateSite repos should only set checksum after generating
(FIXED)
+ Bug 226507. NPE if no IServiceUI implementation is available (FIXED)
+ Bug 226528. Excessive prompting for authenticated connections (FIXED)
+ Bug 226594. Translation Clarification -
org.eclipse.equinox.p2.artifact.repository (FIXED)
+ Bug 226708. Compile errors in nightly builds (FIXED)
+ Bug 226852. director application need to change install folder when
operating on a roaming profile (FIXED)
+ Bug 226921. org.eclipse.equinox.p2.extensionlocation is missing legal
files (FIXED)
+ Bug 226927. IUProfileProperties not cleaned up when IU removed (FIXED)
+ Bug 226929. CacheManager uses URL.hashCode() (FIXED)
+ Bug 227033. IllegalArgumentException : URI is not hierarchical (FIXED)

___
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] p2 build contribution

2008-04-14 Thread Pascal Rapicault


The map file has been updated for the following Bug changes:
+ Bug 97100.  element with type="web" should not be used as a
update site (WONTFIX)
+ Bug 203760. [prov] [repo] ensure URLs are properly encoded (NEW)
+ Bug 204177. [ui] Should have a refresh action in available features page
(FIXED)
+ Bug 204347. [prov] Extension to the PDE Target provisioner (FIXED)
+ Bug 215927. [prov] Authentication upon connection (FIXED)
+ Bug 216028. [ui] Available IU view enhancements (NEW)
+ Bug 216029. [prov] [ui] Installed IU view enhancements (FIXED)
+ Bug 217093. [prov] Cleanup of SimpleMetadataRepositoryFactory's cache
when repository is removed (FIXED)
+ Bug 218186. [prov] [ui] update progress dialogues have workbench as
parent (FIXED)
+ Bug 219888. [ui] - "Other" category shows up even if empty (FIXED)
+ Bug 220554. Support associateSitesURL in UM repository (FIXED)
+ Bug 221087. [ui] Size dialog seems to create a new plan (FIXED)
+ Bug 221412. Remove "verify" attribute on SimpleArtifactRepository (FIXED)
+ Bug 221434. [um] installing from an old update site download plugins and
features in the wrong place (FIXED)
+ Bug 221710. Add links to Native touchpoint (FIXED)
+ Bug 222445. Move extensionlocation repo implementation (FIXED)
+ Bug 222565. Strings need to be externalized (NEW)
+ Bug 222621. Metadata generation for chmod and ln actions (NEW)
+ Bug 223095. Metadata generator should consider features for plugin shape
(FIXED)
+ Bug 223447. [ui] check for update button disabled after click and unclick
(FIXED)
+ Bug 224241. [ui] - Enable revert for M7 (NEW)
+ Bug 224244. [reconciler] Problems when removing higher version of
singleton bundle (FIXED)
+ Bug 224482. [reconciler] Need to watch the platform.xml (NEW)
+ Bug 224710. Need to better handle problem files on server (NEW)
+ Bug 225054. platform.xml location issues with spaces in path (FIXED)
+ Bug 225634. Excessive flushing when writing using XMLWriter (FIXED)
+ Bug 226041. MirrorSelector constructor doesn't handle spaces well (FIXED)
+ Bug 226095. [ui] ProvisionAdminUI fails to display profiles (FIXED)
+ Bug 226116. [ui] cleanup unused messages (FIXED)
+ Bug 226129. missing legal files in p2 source bundles (FIXED)
+ Bug 226202. [shared] bundles.info not read in shared install mode (FIXED)
+ Bug 226219. Re-enable revert in planner (FIXED)
+ Bug 226344. FeatureParser doesn't close streams (FIXED)
+ Bug 226345. UpdateSite repos should only set checksum after generating
(FIXED)
+ Bug 226507. NPE if no IServiceUI implementation is available (FIXED)
+ Bug 226528. Excessive prompting for authenticated connections (FIXED)
+ Bug 226594. Translation Clarification -
org.eclipse.equinox.p2.artifact.repository (FIXED)
+ Bug 226708. Compile errors in nightly builds (FIXED)
+ Bug 226852. director application need to change install folder when
operating on a roaming profile (FIXED)
+ Bug 226921. org.eclipse.equinox.p2.extensionlocation is missing legal
files (FIXED)
+ Bug 226927. IUProfileProperties not cleaned up when IU removed (FIXED)
+ Bug 226929. CacheManager uses URL.hashCode() (FIXED)
+ Bug 227033. IllegalArgumentException : URI is not hierarchical (FIXED)

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

[equinox-dev] Equinox projects tagged for the I-Build

2008-04-14 Thread Thomas Watson


The map file has been updated for the following Bug changes:
+ Bug 194943. Europa Crashes During Startup (FIXED)
+ Bug 217351. [prov] What is the install location in a p2 context
(ASSIGNED)
+ Bug 221581. Inconsistent handling of {ee.home} in EE files (FIXED)
+ Bug 223089. [sec] Do we need "-password", "-keyring" (FIXED)
+ Bug 225090. Need cleanup of temporary files after browsing sites (FIXED)
+ Bug 225386. [sec] Javadoc gotchas (FIXED)
+ Bug 225891. Deadlock due to synchronization in the
org.eclipse.equinox.log bundle's Activator's stop(BundleContext) method
(FIXED)
+ Bug 225899. org.eclipse.equinox.log - JavaDoc errors (FIXED)
+ Bug 225907. [DS] Unexpected component deactivation-activation when
creating new Configuration (FIXED)
+ Bug 226048. [sec] Add progress monitor to long-runing secure storage
operations (FIXED)
+ Bug 226053. eclipse -console < /dev/null prints infinite loop (FIXED)
+ Bug 226576. [sec] messages params are reversed for missing files in a
signed jar (FIXED)
+ Bug 226579. [sec] Array out of bounds in Base64 (FIXED)
+ Bug 226591. [sec] Change and recover password should be specific to a
password provider (FIXED)
+ Bug 226615. CCE in catch Throwable (FIXED)
+ Bug 226716. [sec] Allow user to disable password providers (FIXED)
+ Bug 226744. [sec] Polish password recovery dialog (FIXED)
+ Bug 226754. [sec] Confirm overwrite of the secure storage file (FIXED)
+ Bug 226991. [sec] password verification - make it rule-based (FIXED)
+ Bug 227034. [sec] secure storage dialogs: shells and syncExecs (FIXED)

The following projects have changed:
org.eclipse.equinox.launcher.win32.win32.ia64
org.eclipse.equinox.launcher.carbon.macosx
org.eclipse.equinox.launcher.win32.win32.x86_64
org.eclipse.equinox.launcher.gtk.linux.ppc
org.eclipse.equinox.launcher.motif.linux.x86
org.eclipse.equinox.security.tests
org.eclipse.osgi.tests
org.eclipse.osgi
org.eclipse.equinox.launcher.gtk.linux.x86_64
org.eclipse.equinox.security.ui
org.eclipse.equinox.launcher.motif.hpux.ia64_32
org.eclipse.equinox.security
org.eclipse.equinox.ds
org.eclipse.equinox.launcher.wpf.win32.x86
org.eclipse.equinox.launcher
org.eclipse.equinox.log
org.eclipse.equinox.launcher.win32.win32.x86
org.eclipse.equinox.launcher.gtk.solaris.sparc
org.eclipse.equinox.executable
org.eclipse.equinox.supplement
org.eclipse.equinox.launcher.motif.aix.ppc
org.eclipse.equinox.launcher.gtk.linux.x86
org.eclipse.equinox.util

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

Re: [equinox-dev] Small RCP example with p2

2008-04-14 Thread John Arthorne

p2 doesn't currently have any API. About the best you can do at the moment 
is to invoke the p2 command that opens the install dialog. This command 
has id "org.eclipse.equinox.p2.ui.sdk.update".  You can hook this command 
to a menu from your plugin.xml, or you can invoke the command 
programmatically with code something like this:

ICommandService commandService = (ICommandService) 
PlatformUI.getWorkbench().getService(ICommandService.class);
IHandlerService handlerService = (IHandlerService) 
PlatformUI.getWorkbench().getService(IHandlerService.class);
Command cmd = 
commandService.getCommand("org.eclipse.equinox.p2.ui.sdk.update");
ExecutionEvent executionEvent = 
handlerService.createExecutionEvent(cmd, null);
cmd.executeWithChecks(executionEvent);

HTH,
John




"Matthias Luebken" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
04/14/2008 02:43 PM
Please respond to
Equinox development mailing list 


To
equinox-dev@eclipse.org
cc

Subject
[equinox-dev] Small RCP example with p2






Hi

I'm trying to put together a small p2 example: An RCP-App that
triggers an update action and updates a plugin from an update site.
My first question: Is there something like
"UpdateManagerUI.openInstaller()" for p2?
My second: How would a minimal p2-update site look like?

Thanks in advance.
Matthias

-- 
blog: luebken.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] Small RCP example with p2

2008-04-14 Thread Westbury, Nigel

I would use the UI provided by org.eclipse.equinox.p2.ui.  Is this going to be 
a self-provisioning setup?

In terms of a minimal repository, p2 does not itself define the site layout.  
This is abstracted out, so you can get as simple as you like.  If you want 
something more minimal than the old update site or a p2 update site then just 
implement your own repository factory.  Extend the 
org.eclipse.equinox.p2.metadata.repository.metadataRepositories and 
org.eclipse.equinox.p2.metadata.repository.artifactRepositories.  You will need 
a file at the URL that identifies this as your minimal repository (replacing 
the site.xml used by the old update manager), and you specify this file as the 
filter suffix in the extension.

Nigel

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:equinox-dev-
> [EMAIL PROTECTED] On Behalf Of Matthias Luebken
> Sent: Monday, April 14, 2008 12:44 PM
> To: equinox-dev@eclipse.org
> Subject: [equinox-dev] Small RCP example with p2
>
> Hi
>
> I'm trying to put together a small p2 example: An RCP-App that
> triggers an update action and updates a plugin from an update site.
> My first question: Is there something like
> "UpdateManagerUI.openInstaller()" for p2?
> My second: How would a minimal p2-update site look like?
>
> Thanks in advance.
> Matthias
>
> --
> blog: luebken.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

[equinox-dev] Small RCP example with p2

2008-04-14 Thread Matthias Luebken

Hi

I'm trying to put together a small p2 example: An RCP-App that
triggers an update action and updates a plugin from an update site.
My first question: Is there something like
"UpdateManagerUI.openInstaller()" for p2?
My second: How would a minimal p2-update site look like?

Thanks in advance.
Matthias

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

[equinox-dev] SCR debug output

2008-04-14 Thread Michael Furtak

Hi,

 

I frequently find myself in a position of trying to debug why my
declarative services are not running. Is there debug output from the SCR
that I could be taking advantage of to help this process?

 

If so, what combination of bundles and settings are required to see it?

 

Thanks,

-Mike Furtak
 
 
 
 
THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Eclipse integration build bundles repo somewhere?

2008-04-14 Thread Peter Neubauer

Hi,
I am trying to build a plugin with Maven and the maven-bundle-plugin.
I need some of the latest 3.4M6 plugins, but I don't know where to
find them.

Is there any up-to-date repo for these artifacts?

Cheers

/peter

-- 
GTalk: neubauer.peter
Skype peter.neubauer
ICQ 18762544
GTalk neubauer.peter
Phone +46704 106975
LinkedIn http://www.linkedin.com/in/neubauer

http://www.neo4j.org - New Energy for Data - the Netbase.
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
___
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 


To

Equinox development mailing list  


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  



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 

 


To

Equinox development mailing list  


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 |
+1.860.839.2465___
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] [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-14 Thread Schaefer, Doug

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

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

2008-04-14 Thread John Arthorne

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 


To
Equinox development mailing list 
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



John 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 

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 



To
Equinox development mailing list  
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 | +1.860.839.2465
___
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] [p2] plug-in versions

2008-04-14 Thread Thomas Watson


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




   
  From:   John Arthorne <[EMAIL PROTECTED]> 
   
  To: Equinox development mailing list 
   
  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]To
Equinox development mailing
list 
 04/10/2008 07:23 PMcc
   
   Subject
  Please respond to [equinox-dev] [p2] plug-in 
  Equinox development mailing list  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 | +1.860.839.2465
___
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] plug-in versions

2008-04-14 Thread John Arthorne

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 


To
Equinox development mailing list 
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 | +1.860.839.2465
___
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] p2 build contribution

[equinox-dev] [prov] p2 build contribution

[equinox-dev] Equinox projects tagged for the I-Build

Re: [equinox-dev] Small RCP example with p2

RE: [equinox-dev] Small RCP example with p2

[equinox-dev] Small RCP example with p2

[equinox-dev] SCR debug output

[equinox-dev] Eclipse integration build bundles repo somewhere?

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

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

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

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

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

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

14 matches

Site Navigation

Mail list logo

Footer information