Re: [equinox-dev] The org.eclipse.equinox.security.secureStorage extension point
Hi Oleg,
I still see the problem but its a fairly complex setup. I'll try to
create something simpler that simulates the same flow.
Thanks,
Thomas Hallgren
Oleg Besedin wrote:
Hi Thomas,
It has been tested without SWT; I just re-checked it to be sure -
works fine for me.
Regarding your concerns on the optional dependency: Consider that to
get to the code you copied you need:
- Not be in a headless run (the secure storage sets an option to
suppress prompts for headless runs and JUnits), and
- Have a error in the secure storage where the master password can not
be decrypted
Next, if execution path does get to that code, it catches the
NoClassDefFoundError and eventually translates it into
StorageException(StorageException.NO_PASSWORD).
In principle, VM could be constructed to load class files eagerly.
Practically, VMs try to load as little as they can to speed up the
processing. To be on the safe side, the usual approach is to isolate
code dealing with optional bundles into a separate class. (This is not
always necessary but saves a lot of thinking.)
So, that code works without SWT. As for "been thoroughly tested" I'll
leave that to the Eclipse QA team to answer.
Back to secure storage: do you still see the problem? If you see it
with the current version of the x86 fragment, please open a bug with
steps to reproduce.
Thanks,
Oleg Besedin
*Thomas Hallgren <[EMAIL PROTECTED]>*
Sent by: [EMAIL PROTECTED]
07/03/2008 10:36 AM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev] The
org.eclipse.equinox.security.secureStorageextension point
Hi Oleg,
I confused the extension id with the class name. I'm using the 3.4
release of the delta pack. The fragment.xml declares:
extension id="WindowsPasswordProvider"
which should be OK since the comparison that is made when finding it is
case insensitive.
Now I'm starting to wonder, could this be caused by the optional
dependency on org.eclipse.swt? This bundle is deliberately omitted from
my setup. I found this piece of code:
try {
if (!WinCryptoUI.canRecreatePassword())
return null;
} catch (NoClassDefFoundError exception) {
return null;
}
and that makes me wonder. Does this really work? Isn't there a fair
chance that the JVM will attempt to resolve the class before it enters
the try/catch? I wouldn't be surprised if the optimizer, while doing
first pass rudimentary inlining, in fact attempts to resolve this class
too early and thus fails. Has this been thoroughly tested without swt
present?
Regards,
Thomas Hallgren
Oleg Besedin wrote:
>
> Hi Thomas,
> You are on the right path; the
> "org.eclipse.equinox.security.win32.x86" fragment provides
> "WindowsPasswordProvider". Did you by chance get an old version of the
> fragment from the incubator?
>
> The up-to-date graduated version is in the
> ":pserver:[EMAIL PROTECTED]:/cvsroot/eclipse" repository under
> Head/org.eclipse.equinox/security/bundles.
>
> As a side note, we need to discuss during the Equinox meeting if it is
> better to remove old bundles that have been graduated from the
> repository (less confusion) or keep them (more history).
>
> Thanks,
> Oleg Besedin
>
>
>
> *Thomas Hallgren <[EMAIL PROTECTED]>*
> Sent by: [EMAIL PROTECTED]
>
> 07/03/2008 05:17 AM
> Please respond to
> Equinox development mailing list
>
>
>
> To
> Equinox development mailing list
> cc
>
> Subject
> [equinox-dev] The
org.eclipse.equinox.security.secureStorage
> extension point
>
>
>
>
>
>
>
>
>
> When running headlessly I get an exception with the following message:
>
> "Unable to locate secure storage module
> (org.eclipse.equinox.security.windowspasswordprovider)"
>
> First I thought that I'd forgotten to include the fragment
> org.eclipse.equinox.security.win32.x86 but when I look more closely I
> see that this fragment only adds a module with the id
> "org.eclipse.equinox.internal.security.win32.WinCrypto"
>
> So what bundle is it that defines the module with id
> "org.eclipse.equinox.security.windowspasswordprovider" ?
>
> 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.eclips
Re: [equinox-dev] The org.eclipse.equinox.security.secureStorage extension point
Hi Oleg,
I confused the extension id with the class name. I'm using the 3.4
release of the delta pack. The fragment.xml declares:
extension id="WindowsPasswordProvider"
which should be OK since the comparison that is made when finding it is
case insensitive.
Now I'm starting to wonder, could this be caused by the optional
dependency on org.eclipse.swt? This bundle is deliberately omitted from
my setup. I found this piece of code:
try {
if (!WinCryptoUI.canRecreatePassword())
return null;
} catch (NoClassDefFoundError exception) {
return null;
}
and that makes me wonder. Does this really work? Isn't there a fair
chance that the JVM will attempt to resolve the class before it enters
the try/catch? I wouldn't be surprised if the optimizer, while doing
first pass rudimentary inlining, in fact attempts to resolve this class
too early and thus fails. Has this been thoroughly tested without swt
present?
Regards,
Thomas Hallgren
Oleg Besedin wrote:
Hi Thomas,
You are on the right path; the
"org.eclipse.equinox.security.win32.x86" fragment provides
"WindowsPasswordProvider". Did you by chance get an old version of the
fragment from the incubator?
The up-to-date graduated version is in the
":pserver:[EMAIL PROTECTED]:/cvsroot/eclipse" repository under
Head/org.eclipse.equinox/security/bundles.
As a side note, we need to discuss during the Equinox meeting if it is
better to remove old bundles that have been graduated from the
repository (less confusion) or keep them (more history).
Thanks,
Oleg Besedin
*Thomas Hallgren <[EMAIL PROTECTED]>*
Sent by: [EMAIL PROTECTED]
07/03/2008 05:17 AM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
[equinox-dev] The org.eclipse.equinox.security.secureStorage
extension point
When running headlessly I get an exception with the following message:
"Unable to locate secure storage module
(org.eclipse.equinox.security.windowspasswordprovider)"
First I thought that I'd forgotten to include the fragment
org.eclipse.equinox.security.win32.x86 but when I look more closely I
see that this fragment only adds a module with the id
"org.eclipse.equinox.internal.security.win32.WinCrypto"
So what bundle is it that defines the module with id
"org.eclipse.equinox.security.windowspasswordprovider" ?
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
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] The org.eclipse.equinox.security.secureStorage extension point
When running headlessly I get an exception with the following message: "Unable to locate secure storage module (org.eclipse.equinox.security.windowspasswordprovider)" First I thought that I'd forgotten to include the fragment org.eclipse.equinox.security.win32.x86 but when I look more closely I see that this fragment only adds a module with the id "org.eclipse.equinox.internal.security.win32.WinCrypto" So what bundle is it that defines the module with id "org.eclipse.equinox.security.windowspasswordprovider" ? Regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] The metadataRepositories extension point
On some places in the p2 API's there are comments regarding perhaps using URI's instead of URL's. I think that would be an excellent idea. A URI is not tied to the existence of a particular scheme so for a repository URI the scheme itself could be used to find the corresponding repository factory. We use this approach successfully in the spaces project where each space provider implements their own URI scheme. At present, I need to use URL's that points to non-existent things so that I eventually end up in my factory implementation where I can peruse the URL for it to make sense. It works but it's not very clean (nor efficient). Regards, Thomas Hallgren Thomas Hallgren wrote: I'm trying to understand how to use the org.eclipse.equinox.p2.metadata.repository.metadataRepositories extension point in order to register a factory for my new IMetadataRepositoryFactory. From what I can see the current implementation relies on a 'filter' called 'suffix' but I'm unable to see the correlation between this filter and the URL that is used to identify the repository. It would help me a great deal if someone could explain how I can make sure that the MetadataRepositoryManager finds my new IMetadataRepositoryFactory implementation. Thanks, 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
[equinox-dev] The metadataRepositories extension point
I'm trying to understand how to use the org.eclipse.equinox.p2.metadata.repository.metadataRepositories extension point in order to register a factory for my new IMetadataRepositoryFactory. From what I can see the current implementation relies on a 'filter' called 'suffix' but I'm unable to see the correlation between this filter and the URL that is used to identify the repository. It would help me a great deal if someone could explain how I can make sure that the MetadataRepositoryManager finds my new IMetadataRepositoryFactory implementation. Thanks, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Classloader question
Hi Martin, I tried both solutions (buddy policy dependent) and they both work as a charm! Thanks! - thomas Martin Lippert wrote: Hi Thomas! I have converted 'jabsorb' (JSON RPC bridge) into a bundle. One of the things it does is that it performs unmarshalling strings actual java objects. When it does that, it calls Class.forName(cn) so it will use the defining classloader of the caller class. My question is, how can I make this classloader aware of classes that resides in other bundles? Is it at all possible or will I be forced to refrain from having jabsorb in a bundle and instead use a jar embedded in some other bundle with a wider classloader scope to make this happen? I think you would have different options: Option 1: "DynamicImport-Package: *" to the manifest of your json bundle. This is one possible pure OSGi solution and should do what you want. Option 2: If you are using Equinox as OSGi implementation you could also take a look at the Buddy-Loading mechanism: http://help.eclipse.org/help33/topic/org.eclipse.platform.doc.isv/reference/misc/buddy_loading.html HTH, -Martin ___ 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] Classloader question
Hi, I have converted 'jabsorb' (JSON RPC bridge) into a bundle. One of the things it does is that it performs unmarshalling strings actual java objects. When it does that, it calls Class.forName(cn) so it will use the defining classloader of the caller class. My question is, how can I make this classloader aware of classes that resides in other bundles? Is it at all possible or will I be forced to refrain from having jabsorb in a bundle and instead use a jar embedded in some other bundle with a wider classloader scope to make this happen? TIA, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[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] Unable to create a platform agnostic target
In Eclipse 3.3, after I installed the RCP delta-pack, all installed plug-ins would be visible on the "Plug-ins" tab under "Preferences" -> "Plug-in Development" -> "Target Platform", including those not designated for the current os/ws/arch. In Eclipse 3.4, this list is filtered. The same seems to be true for the PluginModelManager.getActiveModels(). I just wonder if this difference is deliberate and if so, what methods I should use in order to get "all installed" plug-ins, not just the filtered ones. The consequence at present is that when Buckminster attempts to set-up a platform agnostic workspace and is unable to find the filtered plug-ins in the target platform, it instead downloads them from the update site and imports them into the workspace. It works, but the approach taken in 3.3 with the delta-pack installed was a lot faster. Regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] p2 and non OSGi components
Hi Pascal, We are thinking about using p2 as the foundation for a lot of things that we are about to build in the future the version type issue is blocking us right now. It seems to me that approach #2 will require prior knowledge of the version types too. You cannot canonicalize a version of a certain type if you don't know how it's constituted. The whole point of recognizing the versions is to be able to put some semantics to them so that versions of a certain type can be compared with each other and ordered. Trying to squeeze them in to something understood by OSGi versioning will not cover all cases and comparing versions that origins from different types makes no sense at all. In Buckminster, and on Cloudsmith where we have the repo in a DB, we selected approach #1 and while it's true that we cannot anticipate all version types in the world, we already do a fairly good job of understanding a majority of them and it's very easy to add a new type should something pop up that we don't recognize. The same is true for component types (i.e. osgi.bundle, feature.group, etc.) Is there any chance that you would reconsider the approach chosen and add support for pluggable version types? We would of course offer our help with the implementation. Regards, Thomas Hallgren Pascal Rapicault wrote: There is basically two solutions to this problem: 1) have pluggable version numbers 2) deal with canonicalized version numbers. The first requires to have the provisioning system to know about all the version types possibility found in a repo ahead of time, or being able to download additional version handlers on the fly. This also then makes it harder to optimize repo queries when the repo could be stored in a DB. The second requires at metadata generation time some understanding of the version being read to canonicalize it, thus limiting the impacted places in the system and also allowing for more optimization later. In p2 we picked the second approach. PaScaL Inactive hide details for Thomas Hallgren ---05/12/2008 11:21:20 AM---Hi,Thomas Hallgren ---05/12/2008 11:21:20 AM---Hi, From: Thomas Hallgren <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 05/12/2008 11:21 AM Subject: [equinox-dev] p2 and non OSGi components Hi, I'm curious how p2 handles components that are not OSGi and uses version semantics hat differs from OSGi versions. Do you have any concept of "version types" or how to resolve queries that designates ranges of non-OSGi versions? Kind 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 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] p2 and non OSGi components
Hi, I'm curious how p2 handles components that are not OSGi and uses version semantics hat differs from OSGi versions. Do you have any concept of "version types" or how to resolve queries that designates ranges of non-OSGi versions? Kind regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Minimum IApplication configuration
Hi, Buckminsters headless application doesn't run with Eclipse 3.4 and all my attempts to come up with a minimal headless configuration that works have failed. Can you please help me and tell me two things: 1. What is the bare minimum set of plug-ins needed to run an IApplication with no GUI. 2. What should the config.ini look like? Perhaps this is described in detail on the wiki somewhere. If so, a pointer to that would also be greatly appreciated. Thanks in advance, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Participation opportunity
Pascal Rapicault wrote: As for the definition of what we want to do in the director application, the easiest is to start from the current command line application provided by UM (http://help.eclipse.org/help33/topic/org.eclipse.platform.doc.isv/reference/misc/update_standalone.html). OK, this seems very straight forward. I can give it a go if that's OK with everyone. And if someone could come up with a similar list of commands for the mirroring application, perhaps we can provide a resource that can do that as well. Regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Participation opportunity
This wasn't apparent to me either. We're still interested of helping out of course but with a two week timeframe I guess you already have somewhat specific requirements for what the director and mirroring applications should be able to do. Where can I find this information? Regards, Thomas Hallgren Scott Lewis wrote: Hi Jeff, Jeff McAffer wrote: While we are all loving each other I feel obliged to say that the focus of this call to action was (I believe) helping p2 *ship in 3.4* with a reasonable function level. It wasn't apparent to me that the original participation solicitation was scoped to be 'helping p2 ship in 3.4'...but if that's the intention then that's cool. Scott ___ 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] Participation opportunity
Susan Franklin McCourt wrote: I could imagine the day when - update sites, CVS repos, etc. are all using ECF And while we're at it, let's not forget Subversion. Just think about it. An EPL licensed SVN-client based on ECF. That certainly gives me that warm and fuzzy feeling :-) Regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Participation opportunity
Pascal Rapicault wrote: Thomas, This is really great news! I'm really happy to see your involvement. Please post on the mailing list or in bug reports for more specific details on what you can / want to do. We would like to help out in the following areas: 1. Enabling digest management so that all copies can be safely verified. 2. Dynamic mirroring, i.e. support the repository view that in real life is a network of repositories, backing each other on demand. 3. Repository discovery aiding in building such a network automatically. 4. Parallel, partial downloads from multiple mirrors. 5. Federations of meta-data repositories. I didn't find any specific bugs that I could comment on (perhaps I didn't look close enough) and I didn't want to enter new ones at this stage. I think there's a need to elaborate and bounce the ideas around a bit more first. How does this sound? - thomas ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Participation opportunity
Hi Pascal, this sounds very exciting. The more I understand about P2, the more I realize how similar it is to what we (Cloudsmith) are planning to do. We are very interested in participating and with a somewhat aggressive schedule that involves several committers. The work with the mirroring application is probably the most important area for us but we are also interested in the action based touchpoints. Our current headless framework contains a command line application and an installer (currently based on the Update Manager) that we plan make P2 aware. Perhaps that could serve as the "director application"? Regards, Thomas Hallgren Pascal Rapicault wrote: I'm calling out for participation from the community on the following item: - Director application. This consists in improving the "interface" of our command line client and ensure that it replaces the equivalent functionality available in update manager. - Repository mirroring application. This consists in improving the mirroring application, which is key to selectively publish content from one repository to another. - Action based contribution to touchpoints. This consists in revisiting the way actions are contributed to touchpoints by allowing them to be shared across touchpoints. If you are interested in any of these areas, please let us know. Thank you, 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] The RCP-delta feature
Hi Tom, I'd like to install the complete feature "org.eclipse.equinox.executable" into a target platform using the proper installer (Update Site or P2 depending on Eclipse version) during a headless unattended, multi-platform build of an RCP application. If the feature was available just like any other feature, I could have Buckminster find the correct version, materialize it, and install it automatically as part of the build. Regards, Thomas Hallgren Thomas Watson wrote: Hi Thomas, Are you wanting a feature to install the RCP-delta packs or a feature that contains only the launchers? The launchers for the various platforms are available from the equinox download page at http://download.eclipse.org/eclipse/equinox/drops/S-3.4M6-200803301350/index.php But I think the launcher zips suffer from the same issues you have about the RCP-delta pack zip available on the Eclipse SDK download page. What is the recommended work flow in p2 to get the RCP-delta pack installed into your target? Seems like we would need an update site for the delta pack if we want a clean way to provision it with p2. Tom Inactive hide details for Thomas Hallgren ---04/03/2008 04:48:55 AM---Hi,Thomas Hallgren ---04/03/2008 04:48:55 AM---Hi, From: Thomas Hallgren <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 04/03/2008 04:48 AM Subject: [equinox-dev] The RCP-delta feature Hi, I was trying to find the "org.eclipse.equinox.executable" feature on an update site at Eclipse.org but failed. Do I miss something here or is the only way to install the RCP-delta feature to download the zip and unpack it on top of an existing platform? Using a Buckminster build it would be great if it could be treated just like any other installable feature. 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 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] The RCP-delta feature
Hi, I was trying to find the "org.eclipse.equinox.executable" feature on an update site at Eclipse.org but failed. Do I miss something here or is the only way to install the RCP-delta feature to download the zip and unpack it on top of an existing platform? Using a Buckminster build it would be great if it could be treated just like any other installable feature. Regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] P2 artifact repositories and caching
In Buckminster, we need a global artifact cache for downloaded things. What I envision is a cache that can use different strategies to decide whether or not the local content is up-to-date. One such strategy could be to compare with a remote digest of some sort (md5 for instance). Another could be to verify the consistency of a local compressed archive and be satisfied with the exact same size (not 100% safe of course, but in some cases its sufficient). I found the BlobStore in p2 and that will help some. I was under the impression that a "download manager" was under development that would address caching issues like the ones I mention. Are there more things under development that are not covered by the current team project set? Regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] P2 UI separation
Hi, I'm looking into how to replace Buckminsters use of the Update Manager classes with classes from p2. I found my way to the IInstallOperation and the InstallUpdateProductOperation. Unfortunately, they live in a plug-in that requires SWT. This means that there's no way to create a pure java installer that can run on any platform or to create a pure headless installer without the overhead of at least one SWT implementation. Are there any plans to separate the UI parts of the installer into a UI bundle? Regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Download manager support for pack200
Just out of curiosity, why do you use the external binary to do the pack/unpack and not the java.util.jar.Pack200 class? It seems to me that a fragment that is EE dependent (require Java 1.5 or higher) would be ideal here. Those who run lower then Java 5 simply would not have pack200 which is kind of natural isn't it? - thomas Jeff McAffer wrote: right but there is the practical detail that the exe you need comes with Java 5 or later and the licensing does not likely allow you to ship just the unpack200 exe. But that is a matter for someone's legal team. As John says, the unpack support simply cares whether or not the exe is there. What we really need is an open source implementation of unpack that runs on/with Foundation... Jeff John Arthorne wrote: Just to clarify, the JRE level doesn't matter here. Unpack is performed by a standalone unpack200 executable that doesn't require presence of a JVM. You can run with a Foundation class library, plus a standalone unpack200 executable from Java 5 or Java 6. *Jim Colson <[EMAIL PROTECTED]>* Sent by: [EMAIL PROTECTED] 01/24/2008 09:18 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Equinox development mailing list , [EMAIL PROTECTED] Subject Re: [equinox-dev] [prov] Download manager support for pack200 how would that work on J2ME (CDC/Foundatoin)? Jim Colson, Chief Architect - IBM Client Software Distinguished Engineer IBM Academy of Technology Board Member - IT Architect Certification 11501 Burnet Rd. Austin, TX 78758 Ph 512-823-7357, Fax 512-838-0962 email: [EMAIL PROTECTED] Admin: Sandra Wallis 512-838-3241 email: [EMAIL PROTECTED] From: Pascal Rapicault <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 01/24/2008 08:11 PM Subject: [equinox-dev] [prov] Download manager support for pack200 I seem to remember that someone was working on adding to support to our download manager to favor downloading pack200'ed artifacts over canonical ones. Did that ever made it into the code? Thx 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 mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] OBR
Thomas Watson wrote: There currently is no implementation of OBR. If you look earlier in this thread you will see talk of investigating an OBR repository adaptor for p2. Thomas Hallgren showed interest in implementing such a repository adaptor. Thomas, do you have any interest in doing/contributing this work to Equinox? Perhaps start in the incubator? Yes, absolutely. I've already started by reading up on p2 in general and the current Update Site adaptor. How do I get committer access to the incubator? Regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Draft meeting schedule
Done. I assume all times are EST? - thomas John Arthorne wrote: So far we have just used private phone calls because there haven't been more than two sites involved in any given discussion. We'll try to figure something out for the calls that need a bridge... can you add your name to the topics you are interested in? *Thomas Hallgren <[EMAIL PROTECTED]>* Sent by: [EMAIL PROTECTED] 01/14/2008 03:16 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] [prov] Draft meeting schedule Hi John, How are these meetings conducted? Are you using a conference bridge? I'd like to listen in on some of them if you don't mind. Regards, Thomas Hallgren John Arthorne wrote: > > Can everyone involved in p2 discussions this week take a look at the > following draft schedule and let me know about conflicts. I've taken a > guess about some of the people to be involved in the various > discussions, but this is by no means complete. Feel free to add > yourself to any subject of interest to you. > > http://wiki.eclipse.org/Equinox_p2_Meeting_Week_Jan_14-18_2008 > > > ___ > 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] Draft meeting schedule
Hi John, How are these meetings conducted? Are you using a conference bridge? I'd like to listen in on some of them if you don't mind. Regards, Thomas Hallgren John Arthorne wrote: Can everyone involved in p2 discussions this week take a look at the following draft schedule and let me know about conflicts. I've taken a guess about some of the people to be involved in the various discussions, but this is by no means complete. Feel free to add yourself to any subject of interest to you. http://wiki.eclipse.org/Equinox_p2_Meeting_Week_Jan_14-18_2008 ___ 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] OBR
This makes a lot of sense. We don't have any use for the artifact fetching. Our objective is to be able to publish OSGi bundles to a generic repository (in the spaces project) and to be able to consume OBR's from Buckminster. The latter might well be Buckminster consuming p2 IU's that in turn maps to an OBR through the adapter that I intend to implement. Thanks for the pointers. I'll start there. - thomas Jeff McAffer wrote: Great! Never having looked at the OBR implementation I can't really say which is the best path. I'm imagining that they have some code that reads repositories and some code that does resolution etc. What you need is the repository reading/parsing code. You would take that input information in and create a matching metadata repo and artifact repo object in p2. These would be primed with InstallableUnits (IUs) and artifact descriptors (respectively). From there on the OBR stuff would show up in p2 just like anything else and you can install etc using the p2 resolution strategies etc. Simon is doing something similar to this right now for update sites. He has a harder challenge because update sites don't have alot of metadata that is easily accessible. OBR seems to have more metadata so should be easier to integrate. I would recommend against trying to mix OBR's resolver and artifact fetching etc with that of p2. Feels like there will be conflicts and strangeness that cannot easily be contained in the UI and the end result will confuse users. Anyway, that is the path that I would go. Perhaps the best place to start is by looking at the p2 SimpleMetadataRepository and SimpleArtifactRepository classes as well as the org.eclipse.equinox.p2.updatesite bundle. These do not directly fit what you are doing but what you need is likely some combination of the two and something that can parse OBR repos. Note also that OBR has repo federation that is currently not supported by p2 (though it seems like a good idea). For now I would start simple and go for just one OBR repo at a time. You can find the Europa OBR repo at download.eclipse.org/releases/europa/repository.zip Does this make sense? Jeff *Thomas Hallgren <[EMAIL PROTECTED]>* Sent by: [EMAIL PROTECTED] 01/11/2008 10:46 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] OBR I agree with this and I'd be willing to actually write the OBR repository adaptor for p2. Would you agree that the simplest way to do that is probably to write it on top of the OBR API's and the Felix bundle repository implementation? - thomas Jeff McAffer wrote: > > We currently do host an OBR repo with the major releases. Don't > remember the URL but the required repository.xml/zip file is there for > Callisto and Europa. The OBR client code may be interesting but our > strategic direction is p2. For the most part p2 has (or can be made > to have) the same functionality as the OBR client but goes further > towards solving the wider range of problems we see in the Eclipse > provisioning space. > > I am all for supporting the use of OBR repositories in the sense that > some people will make their function available that way. Given the p2 > work however, it would be more interesting (to me at least) to write > an OBR repository adaptor for p2 than to use the OBR api. Further, I > hope that eclipse projects will feel comfortable making their content > available as p2 repositories so that the Eclipse user community is not > put in a position of having to get many different provisioning clients. > > In short, we in p2 would very much like to have your interaction and > participation in making a provisioning solution that solves your needs. > > Jeff > > > > *Thomas Hallgren <[EMAIL PROTECTED]>* > Sent by: [EMAIL PROTECTED] > > 01/11/2008 10:19 AM > Please respond to > Equinox development mailing list > > > > To > Equinox development mailing list > cc > > Subject > [equinox-dev] OBR > > > > > > > > > > Hi, > I'm wonder if any work has been done within Eclipse to deal with OBR > repositories, and if so, how can I get access to that. If not, and if no > one has a better idea, I'm planning to start an IP-zilla to get the > Apache Felix OBR approved since we will want to map that kind of > repositories in Buckminster and also provide OBR's as an alternative to > update sites in the spaces project. > > Regards, > Thomas Hallgren > > ___ > equinox-dev mailing list > equinox-dev@eclips
Re: [equinox-dev] OBR
I agree with this and I'd be willing to actually write the OBR repository adaptor for p2. Would you agree that the simplest way to do that is probably to write it on top of the OBR API's and the Felix bundle repository implementation? - thomas Jeff McAffer wrote: We currently do host an OBR repo with the major releases. Don't remember the URL but the required repository.xml/zip file is there for Callisto and Europa. The OBR client code may be interesting but our strategic direction is p2. For the most part p2 has (or can be made to have) the same functionality as the OBR client but goes further towards solving the wider range of problems we see in the Eclipse provisioning space. I am all for supporting the use of OBR repositories in the sense that some people will make their function available that way. Given the p2 work however, it would be more interesting (to me at least) to write an OBR repository adaptor for p2 than to use the OBR api. Further, I hope that eclipse projects will feel comfortable making their content available as p2 repositories so that the Eclipse user community is not put in a position of having to get many different provisioning clients. In short, we in p2 would very much like to have your interaction and participation in making a provisioning solution that solves your needs. Jeff *Thomas Hallgren <[EMAIL PROTECTED]>* Sent by: [EMAIL PROTECTED] 01/11/2008 10:19 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject [equinox-dev] OBR Hi, I'm wonder if any work has been done within Eclipse to deal with OBR repositories, and if so, how can I get access to that. If not, and if no one has a better idea, I'm planning to start an IP-zilla to get the Apache Felix OBR approved since we will want to map that kind of repositories in Buckminster and also provide OBR's as an alternative to update sites in the spaces project. 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 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] OBR
Hi, I'm wonder if any work has been done within Eclipse to deal with OBR repositories, and if so, how can I get access to that. If not, and if no one has a better idea, I'm planning to start an IP-zilla to get the Apache Felix OBR approved since we will want to map that kind of repositories in Buckminster and also provide OBR's as an alternative to update sites in the spaces project. Regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Jetty and commons logging
Alex Blewitt wrote: Even the update sites aren't helpful. You can't browse to them, and even when you do (e.g. via a mirror) it's not clear as to which plugin is stored in which location. While I agree that there's certainly room for improvement, I don't think it's that bad. You will find most things on the Europa update site (or the Ganymede staging site if you want to be bleeding edge). You can create a target platform suitable for your builds using the current update manager and/or you can make use of the Orbit map files. The structure is not perfect but its definitely usable for automating downloads and builds. Lastly, there's no metadata available. Yes there is. You have the site.xml in every update site. All features have a feature.xml and all OSGi bundles have a manifest.mf. Getting to that meta-data can sometimes be a pain since it's embedded but features are most often very small by nature. The manifest.mf is a bit more cumbersome though. A tool that does some caching of what it reads can do a fairly good job of resolving and downloading without wasting too much bandwidth. - thomas ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Jetty and commons logging
I'd like to do some advertising for Buckminster here. With it, you can point to update sites or PDE map files (such as the Eclipse Orbit map). Buckminster will treat them in a similar way that Maven treats its repository. It will do transitive resolution of all dependencies found in plugins or features and materialize the resulting closure to your workspace. If needed, it can also read and resolve from maven repositories and pick source from CVS or SVN. You can find more information about Buckminster here: http://www.eclipse.org/buckminster A sample resource map (maps components to locations) can be found here: http://www.eclipse.org/buckminster/samples/rmaps/dogfood2.rmap. The 'default' search path in this rmap uses the Orbit repository at Eclipse.org. A cquery using this RMAP that would resolve the commons-logging OSGi bundle from Orbit looks like this: http://www.eclipse.org/buckminster/CQuery-1.0"; resourceMap="http://www.eclipse.org/buckminster/samples/rmaps/dogfood2.rmap";> componentType="osgi.bundle"/> Regards, Thomas Hallgren Alex Blewitt wrote: On Jan 5, 2008 2:38 PM, Jeff McAffer <[EMAIL PROTECTED]> wrote: Dave, there isn't one. For the most part Eclipse teams use the PDE tooling to build their bundles. Having a maven repo would be a really, really good thing for the Eclipse bundles. After all, it's just a set of directories and some meta-information (which could be automatically generated from the bundle's data). If there's anything in the pipeline for a V4.0, having the ability for the bundles to be consumed by maven users would be a really good thing. 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] Best time to engage
Hi Jeff, Jeff McAffer wrote: The main goal of M3 was to define what we actually want to do for 3.4. While that is not completely documented (M3 is this week), we are largely on track to meet that goal. The API will likely chanage somewhat over the next few milestones but you should not be afraid of that. In fact, it is this kind of interaction (others trying p2 on their usecases) that will help shape the API. Thanks. That answers my question. I think we will start working on the integration next week. Do you have a team-project set or a releng-map that can be used when populating the workspace with the p2 projects? It would be great to find out what you are planning on doing and how it goes. My first steps will be to wrap my head around the new concepts and get a good understanding of where it would make sense to connect. The first implementation exercise is probably to write a provider that will enable Buckminster to resolve and materialize using the p2 framework. I envision something similar to our current implementation on top of org.eclipse.update.core (this is what enables Buckminster headless to extend itself with new features and also the base for some of the functionality used in Ganymatic). The bigger picture includes much more. I'd like for Buckminster to align with some of the concepts that I really like in p2 (profile, touchpoint, etc.) but I need to try it out and learn more first. I'll keep you posted about my progress. - thomas ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Best time to engage
Hi, I've been following the p2 project fairly closely and the closer it gets to a stable API, the more interesting it gets for us (Buckminster) to be able to integrate with it. I regret that I missed the opportunity to attend the provisioning workshop in September as I'm sure that would have been a great opportunity to touch base. Reading the p2 plan I can see that you are now close to the M3 milestone (November 2) and I'm wondering if that would be a good time for the Buckminster team to start the integration work needed in order to consume your model artifacts. Do you consider your model fairly stable at this point or will it be significantly modified in the coming milestones? I was trying to find the XML schemas for the various artifacts mentioned but I wasn't able to. Are they published somewhere? Kind Regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] p2 / browser integration
Scott Lewis wrote: Both I and Markus Kuppe are actively working on the discovery API, and Jan Rellermeyer is working with us on jSLP. There are already some simplifications planned/scheduled for ECF 2.0/Ganymede. I can't speak for Markus and/or Jan, but would be willing to help/support/participate myself...and suspect Markus and Jan would be willing to participate as well. Communicating with existing Eclipse instances would be very interesting for Buckminster as well. I would like to help with this too if possible. Regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Prosyst contributions
As someone who spent quite some time browsing Eclipse packages, trying to understand which code that does what and grasping various concepts that are perhaps not too well documented, I've learned to appreciate package names that brings clarity. In that respect, I consider "provisioning" a much better choice then "ip". Regards, Thomas Hallgren Doug Schaefer wrote: Heck, I don’t know what half the acronyms at Eclipse mean, so this wouldn’t be the first. Doug Schaefer, //QNX Software Systems/// //Eclipse CDT Project Lead, http://cdtdoug.blogspot.com/// *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *BJ Hargrave *Sent:* Saturday, July 07, 2007 7:19 PM *To:* Equinox development mailing list *Subject:* Re: Re[2]: [equinox-dev] Prosyst contributions I also think ip is a bit too minimalist. Certtainly as the bundle symbolic name. I am less concerned as the package name. -- *BJ Hargrave* Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance <http://www.osgi.org/>_ [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> office: +1 386 848 1781 mobile: +1 386 848 3788 *"Alex Blewitt" <[EMAIL PROTECTED]>* Sent by: [EMAIL PROTECTED] 2007-07-07 17:26 Please respond to Equinox development mailing list To "Equinox development mailing list" cc Subject Re: Re[2]: [equinox-dev] Prosyst contributions I'm glad I'm not alone. I've asked the question to a wider audience to see if they'd get the reference: http://www.eclipsezone.com/eclipse/forums/t98469.html On 07/07/07, Remy Chi Jian Suen <[EMAIL PROTECTED]> wrote: > You're not alone, Alex. I think ip is a horrible name. > initprovisioning or initprov or something would've been better. > There's just no way that someone's going to know that 'ip' is 'initial > provisioning'. > > Regards, > Rem > > On 7/7/07, Alex Blewitt <[EMAIL PROTECTED]> wrote: > > Am I really the only one who thinks '.ip' is a bad name? > > > > Alex. > > > > On 07/07/07, Simon Kaegi <[EMAIL PROTECTED]> wrote: > > > That's great! I've just done a quick sanity check and everything compiles, > > > starts and is ready to try out. > > > Thanks. > > > > > > For anyone wanting to take a look, the following new projects were added to > > > the incubator. > > > > > > 1) org.eclipse.equinox.ds > > > 2) org.eclipse.equinox.io > > > 3) org.eclipse.equinox.ip > > > 4) org.eclipse.equinox.util > > > 5) org.eclipse.equinox.wireadmin > > > > > > I had one cosmetic question for equinox.util. Currently the BSN is > > > "org.eclipse.equinox.util.putifull" -- is there some reason it's not just > > > org.eclipse.equinox.util? > > > -Simon > > > > > > [EMAIL PROTECTED] wrote on 07/07/2007 06:41:23 AM: > > > > > > > In CVS under your proposed naming. > > > > > > > > -Pavlin > > > > > > > > > > > > > > > > > OK, I'm not particular about the names right now. Since we already > > > > have a DS bundle lets just use org.eclipse.equinox.ds for > > > > declarative services. > > > > > > > > I also like org.eclipse.equinox.ip for initial provisioning but > > > > thought it might be to short :) but it is snappy. > > > > > > > > Pavlin, if these are ok with you please release with the names org. > > > > eclipse.equinox.ds and org.eclipse.equinox.ip. As I said before it > > > > is no big deal to rename the bundles if needed in the incubator later. > > > > > > > > Tom > > > > > > > > Chris Aniszczyk/Austin/[EMAIL PROTECTED] > > > > Sent by: [EMAIL PROTECTED] > > > > 07/05/2007 09:34 PM > > > > > > > > Please respond to > > > > Equinox development mailing list > > > > > > > > To > > > > > > > > Equinox development mailing list > > > > > > > > cc > > > > > > > > Subject > > > > > > > > Re: [equinox-dev] Prosyst contributions > > > > > > > > as an outsider, +1 for DS instead of SCR, there's like 5 people that > > > > would get the SCR reference :) > > > > > > > > initialprovisioning is really long > > > > > > > >
