Re: [equinox-dev] Which C file for launcher on mac
The files under library/carbon are used for cocoa, there are ifdefs separating the pieces that are different between carbon cocoa. The dll will contain eclipseCarbon.c and eclipseCarbonCommon.c. If you look near the top of the make_cocoa.mak file, you can see the full list of files for both the executable and the library. The executable contains everything from MAIN_OBJS COMMON_OBJS, the library contains COMMON_OBJS DLL_OBJS. -Andrew From: Pascal Rapicault pas...@rapicault.net To: Equinox development mailing list equinox-dev@eclipse.org, Date: 11/16/2012 11:09 AM Subject:[equinox-dev] Which C file for launcher on mac Sent by:equinox-dev-boun...@eclipse.org When the executable for mac / cocoa, is it the eclipseCarbon.c file that finds it way into the dll? Pascal ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Welcome Bogdan Gheorghe as a new rt.equinox.framework Committer
rt.equinox.framework Committers, This automatically generated message marks the completion of all the legal paperwork and webmaster provisioning for Bogdan Gheorghe. Bogdan Gheorghe is a new full Committer on the rt.equinox.framework project. Welcome! ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Welcome Silenio Quarti as a new rt.equinox.framework Committer
rt.equinox.framework Committers, This automatically generated message marks the completion of all the legal paperwork and webmaster provisioning for Silenio Quarti. Silenio Quarti is a new full Committer on the rt.equinox.framework project. Welcome! ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Committer vote for Bogdan Gheorghe has concluded successfully
rt.equinox.framework Committers, This automatically generated message marks the successful completion of voting for Bogdan Gheorghe to receive full Committer status on the rt.equinox.framework 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: 4/0/0 with 3 not voting ? Sonia Dimitrov +1 BJ Hargrave ? DJ Houghton ? Kim Moir +1 Andrew Niefer +1 Pascal Rapicault +1 Thomas Watson 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] Committer vote for Silenio Quarti has concluded successfully
rt.equinox.framework Committers, This automatically generated message marks the successful completion of voting for Silenio Quarti to receive full Committer status on the rt.equinox.framework 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: 4/0/0 with 3 not voting ? Sonia Dimitrov +1 BJ Hargrave ? DJ Houghton ? Kim Moir +1 Andrew Niefer +1 Pascal Rapicault +1 Thomas Watson 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] Tagging git using the e4 shell scripts
Hello All, e4 releng has updated the shell scripts used to tag git and update map files for an IBuild. If you have not yet moved to git, or are not using these scripts, then you can ignore this message. I have updated the wiki page here: http://wiki.eclipse.org/E4/Git#Submitting_for_a_build with a description of how the new shell scripts work. They should be easier to use than the old scripts and require fewer steps. Please feel free to update the wiki or let me know if anything needs clarification. -Andrew___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] equinox git repo
The repositories you want are git://git.eclipse.org/gitroot/equinox/rt.equinox.framework.git git://git.eclipse.org/gitroot/equinox/rt.equinox.bundles.git git://git.eclipse.org/gitroot/equinox/rt.equinox.p2.git git://git.eclipse.org/gitroot/equinox/rt.equinox.security.git “git://dev.eclipse.org/org.eclipse.equinox/org.eclipse.equinox.git” is a read only mirror of the cvs repository. (http://wiki.eclipse.org/Git#Git_mirrors_of_CVS_repositories) -Andrew From: Kapukaranov, Borislav borislav.kapukara...@sap.com To: equinox-dev@eclipse.org equinox-dev@eclipse.org Date: 08/09/2011 11:07 AM Subject: [equinox-dev] equinox git repo Sent by: equinox-dev-boun...@eclipse.org Hi, Is “git://dev.eclipse.org/org.eclipse.equinox/org.eclipse.equinox.git” the correct git repo for equinox at the moment, meaning up-to-date, where-all-the-action-is, etc.? Also does it include also the migrated incubator projects? I noticed it’s larger than 2.03GB… and cloned for more than 2 hours, so I suspect I got the wrong one. If it actually is the correct repo, can’t it be optimized, e.g. separating the incubator, bundles, components, framework, etc. subfolders into separate repos? It’s a bit inconvenient to clone for 2+ hours just to get the source of org.eclipse.osgi. Thanks, Borislav___ 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] Eclipse and e4 4.M1 and 0.12M1 now available
4.2M1 http://download.eclipse.org/e4/sdk/drops/S-4.2M1-201108051200/index.php p2 repo http://download.eclipse.org/eclipse/updates/4.2-I-builds 0.12M1 http://download.eclipse.org/e4/downloads/drops/S-0.12M1-201108051200/index.html p2 repo http://download.eclipse.org/e4/updates/0.12-I-builds From: Kim Moir/Ottawa/IBM@IBMCA To: platform-releng-...@eclipse.org, equinox-dev@eclipse.org, eclipse-...@eclipse.org Date: 08/05/2011 06:14 PM Subject: [equinox-dev] Eclipse and Equinox 3.8M1 now available Sent by: equinox-dev-boun...@eclipse.org New and Noteworthy http://download.eclipse.org/eclipse/downloads/drops/S-3.8M1-201108031800/eclipse-news-M1.html p2 repo http://download.eclipse.org/eclipse/updates/3.8milestones Eclipse http://download.eclipse.org/eclipse/downloads/drops/S-3.8M1-201108031800/index.php Equinox http://download.eclipse.org/equinox/drops/S-3.8M1-201108031800/index.php 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
[equinox-dev] Equinox intends to fix bug 347475 in 3.7 RC4
Equinox intends to fix https://bugs.eclipse.org/bugs/show_bug.cgi?id=347475 for 3.7RC4 This is a problem in the launcher which prevents it from displaying graphics (ie, the splash screen) on aix.ppc64. -Andrew From: Markus Keller markus_kel...@ch.ibm.com To: platform-releng-...@eclipse.org Date: 05/27/2011 11:17 AM Subject: [platform-releng-dev] JDT UI intends to fix bug 347302 in 3.7 RC4 Sent by: platform-releng-dev-boun...@eclipse.org JDT UI intends to fix bug 347302 in 3.7 RC4. This reverts a bad fix for a minor bug to the pre-M7 version. Markus ___ 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
Re: [equinox-dev] Equinox tagged for the next RC1 build
The map file has been updated for the following Bug changes: + Bug 344270. Eclipse launcher can still set MOZILLA_FIVE_HOME to an invalid renderer (NEW) The following projects have changed: org.eclipse.equinox.executable org.eclipse.equinox.launcher.gtk.aix.ppc org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.launcher.gtk.linux.s390 org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.launcher.motif.solaris.sparc org.eclipse.equinox.launcher.gtk.aix.ppc64 org.eclipse.equinox.launcher.gtk.linux.ppc64 org.eclipse.equinox.launcher.gtk.linux.s390x org.eclipse.equinox.launcher.gtk.solaris.x86 org.eclipse.equinox.launcher.gtk.linux.x86 -Andrew From: Thomas Watson tjwat...@us.ibm.com To: equinox-dev@eclipse.org Date: 05/03/2011 11:28 PM Subject: [equinox-dev] Equinox tagged for the next RC1 build Sent by: equinox-dev-boun...@eclipse.org The map file has been updated for the following Bug changes: + Bug 344347. [region] linear search to find a bundle's region hurts performance (FIXED) + Bug 344524. compile warning in official build (FIXED) + Bug 344567. [region] all singletons are treated as non-singletons (FIXED) + Bug 344631. singleton selection algorithm incorrectly allows singleton collisions to resolve (FIXED) The following projects have changed: org.eclipse.equinox.region.tests org.eclipse.equinox.region org.eclipse.osgi 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] Equinox tagged for the next Helios Maintenance build
The map file has been updated for the following Bug changes: + Bug 319123. [launcher] Application becomes unresponsive when code completion tooltip shows (NEW) The following projects have changed: org.eclipse.equinox.launcher.gtk.linux.ppc64 org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.equinox.launcher.gtk.solaris.x86 org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.launcher.releng org.eclipse.equinox.executable org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.launcher.gtk.linux.x86___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox contribution to the Helios Maintenance build.
This is a compile of the launchers to pick up the 3.6.1 fixes on the s390 and s390x platforms: 315939 [launcher] Crash in formatVmCommandMsg 316975 [launcher] memory leak on failure to read launcher.ini file The map file has been updated for the following Bug changes: + Bug 322291. [launcher] remember to compile for S390(x) (FIXED) The following projects have changed: org.eclipse.equinox.launcher.gtk.linux.s390 org.eclipse.equinox.launcher.gtk.linux.s390x org.eclipse.equinox.executable___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox tagged for next Helios SR1 build.
The map file has been updated for the following Bug changes: + Bug 315746. --launcher.openFile on Solaris fails with error about unresolved symbol sem_open (FIXED) + Bug 315939. [launcher] Crash in formatVmCommandMsg (FIXED) + Bug 316975. [launcher] memory leak on failure to read launcher.ini file (FIXED) The following projects have changed: org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.launcher.cocoa.macosx org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.launcher.cocoa.macosx.x86_64 org.eclipse.equinox.launcher.gtk.solaris.x86 org.eclipse.equinox.launcher.motif.solaris.sparc org.eclipse.equinox.launcher.gtk.linux.ppc64 org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.launcher.win32.win32.ia64 org.eclipse.equinox.launcher.motif.hpux.ia64_32 org.eclipse.equinox.launcher.gtk.linux.x86 org.eclipse.equinox.executable___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox tagged for the next Helios SR1 build.
I have branched org.eclipse.equinox.executable and org.eclipse.equinox.launcher. I have gone ahead and tagged the following for Helios SR1: The map file has been updated for the following Bug changes: + Bug 320005. [launcher] --launcher.XXMaxPermSize: isSunVM should return true for Oracle (FIXED) The following projects have changed: org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.executable org.eclipse.equinox.launcher.win32.win32.ia64 org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.launcher.wpf.win32.x86 | | From: | | --| |Thomas Watson tjwat...@us.ibm.com | --| | | To:| | --| |equinox-dev@eclipse.org | --| | | Date: | | --| |07/12/2010 02:52 PM | --| | | Subject: | | --| |[equinox-dev] Equinox tagged for the next Helios SR1 build. | --| | | Sent by: | | --| |equinox-dev-boun...@eclipse.org | --| I went ahead and tagged for the Helios SR1 build. Please let me know if you branch and release any other equinox projects for Helios SR1. Thanks. The map file has been updated for the following Bug changes: + Bug 311579. [DS] Factory component configurations are not disposed when cannot be activated (FIXED) + Bug 313234. -console port terminating OSGi framework in 3.6.RC1 (FIXED) The following projects have changed: org.eclipse.equinox.ds org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Generated configuration file overwrites specified properties
BUILD FAILED C:\galileo-3.5.2\workspace\adt.builder\buildADT.xml:34: The following error occurred while executing this line: C:\galileo-3.5.2\workspace\adt.builder\buildADT.xml:19: Problem: failed to create task or type p2.publish.featuresAndBundles Cause: The name is undefined. Action: Check the spelling. Action: Check that any custom tasks/types have been declared. Action: Check that any presetdef/macrodef declarations have taken place. Make sure you run the ant script in the same JRE as the workspace, this is a setting on the JRE tab of the external tools launch configuration. http://4.bp.blogspot.com/_iiaKuwyHAlw/SlPIFntIfYI/Adw/YSA0GiIyGdQ/s1600-h/screen2.PNG -Andrew___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Generated configuration file overwrites specified properties
I updated the examples, one of the links they are downloading from was out of date. Yes, if you have metadata for your own product then this problem would be solved. The config.ini and eclipse.ini files are updated by p2 because they often need to change when new stuff is installed or existing bundles are updated. If you already have a build process which produces your features and plugins, it should be simple to modify the ADT Part 2 example to package them together with the CDT Eclipse Platform into a product. In that example the adt.feature.builder/product/adt.product describes the product. You can search for references to mylyn and replace those with your own feature. Alternatively this example can also build your feature directly if you were to replace the adt.feature. -Andrew From: Richard Horbach richard.horb...@altium.com To: Equinox development mailing list equinox-dev@eclipse.org Date: 03/24/2010 07:10 AM Subject: Re: [equinox-dev] Generated configuration file overwrites specified properties Sent by: equinox-dev-boun...@eclipse.org We have a different model of building and installing the product. We do not use ant nor the Eclipse environment to build the product. For installing required items, we do not depend on Eclipse. Our (GUI) product -part of a complete C Compiler toolchain- is build on top of Eclipse and CDT. The plugins are build from the command line, using the java compiler and the jar program. The complete Compiler product is installed using install shield. All plugins, including CDT and Eclipse platform plugins, are installed at installation time in the plugins directory, no need for downloading or updating. We ship a feature.xml file in the features/myproduct directory, that sums up all self developed plugins. Furtermore we supply an eclipse.ini and the config.ini, the one I mentioned earlier, in the configuration directory. These files are not generated, but put together manually. That is basically all. Until now it was not necessary to create p2 metadata (and admittedly, we did not investigate the p2 mechanism very thorough yet), so we have no metadata available for our product, just the feature.xml. I want to avoid that the configuration settings are regenerated, and that the org.eclipse.platform.ide product is used. If I have the p2 metadata available, than this problem would be solved, right? (FYI: the examples you are referring to, do not build anymore.) Thanks, Richard Andrew Niefer wrote: How did you build this product? The metadata for the product generally specifies the settings for these properties. Here it looks like you are getting the settings that are specified by the org.eclipse.platform.ide product. Are you just taking the platform.ide and copying your stuff over top of it? It sounds like the p2 metadata just has the platform.ide settings, on first start p2 discovers the bundles you copied on top of everything reconciles the install for you, this would cause the configuration settings to be regenerated. I would suggest taking a look at these two examples I wrote last year: http://aniefer.blogspot.com/2009/07/composing-and-updating-custom-eclipse.html http://aniefer.blogspot.com/2009/07/adt-part-2-more-like-epp.html It is probably simplest to build things as described in the second post (ADT part 2: More like the EPP), though it would be good to read the first post as well. They both contain references to examples in cvs that you can download and run. -Andrew From: Richard Horbach richard.horb...@altium.com To:equinox-dev@eclipse.org Date: 03/23/2010 10:01 AM Subject: [equinox-dev] Generated configuration file overwrites specifiedproperties Sent by: equinox-dev-boun...@eclipse.org We start our product, based on Eclipse, with our own splash screen. In the configuration directory we therefore have specified the following properties in the config.ini file: - eclipse.product=com.mycompany.myproduct.ide - osgi.splashPath=platform\:/base/plugins/com.mycompany.myprod uct - osgi.configuration.area = @user.home/.eclipse/configuration When starting the product for the very first time, the proper splash screen shows up. Therefore, the local config.ini file was read and parsed correctly. When closing the application again, a new created configuration file is written (written by EquinoxFwConfigFileParser) to the location specified in 'osgi.configuration.area'. This generated config.ini file however, contains wrong/overwritten properties: - eclipse.product=org.eclipse.platform.ide - osgi.splashPath=platform\:/base/plugins/org.eclipse.platform If I now restart the product for a second/next time, the default Eclipse splash screen is shown; The setting in the configuration area apparently takes precedence over
Re: [equinox-dev] Generated configuration file overwrites specified properties
How did you build this product? The metadata for the product generally specifies the settings for these properties. Here it looks like you are getting the settings that are specified by the org.eclipse.platform.ide product. Are you just taking the platform.ide and copying your stuff over top of it? It sounds like the p2 metadata just has the platform.ide settings, on first start p2 discovers the bundles you copied on top of everything reconciles the install for you, this would cause the configuration settings to be regenerated. I would suggest taking a look at these two examples I wrote last year: http://aniefer.blogspot.com/2009/07/composing-and-updating-custom-eclipse.html http://aniefer.blogspot.com/2009/07/adt-part-2-more-like-epp.html It is probably simplest to build things as described in the second post (ADT part 2: More like the EPP), though it would be good to read the first post as well. They both contain references to examples in cvs that you can download and run. -Andrew From: Richard Horbach richard.horb...@altium.com To: equinox-dev@eclipse.org Date: 03/23/2010 10:01 AM Subject: [equinox-dev] Generated configuration file overwrites specified properties Sent by: equinox-dev-boun...@eclipse.org We start our product, based on Eclipse, with our own splash screen. In the configuration directory we therefore have specified the following properties in the config.ini file: - eclipse.product=com.mycompany.myproduct.ide - osgi.splashPath=platform\:/base/plugins/com.mycompany.myprod uct - osgi.configuration.area = @user.home/.eclipse/configuration When starting the product for the very first time, the proper splash screen shows up. Therefore, the local config.ini file was read and parsed correctly. When closing the application again, a new created configuration file is written (written by EquinoxFwConfigFileParser) to the location specified in 'osgi.configuration.area'. This generated config.ini file however, contains wrong/overwritten properties: - eclipse.product=org.eclipse.platform.ide - osgi.splashPath=platform\:/base/plugins/org.eclipse.platform If I now restart the product for a second/next time, the default Eclipse splash screen is shown; The setting in the configuration area apparently takes precedence over the local setting. I have this problem since I switched over from Eclipse 3.5.0 to version 3.5.2. In Eclipse 3.5.0 this mechanism worked well, since no entries for 'eclipse.product' and 'osgi.splashPath' were written back. Should I log a bug in bugzilla for this issue, or could there be something wrong with my configuration? Regards, Richard Horbach ___ 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] Updated for integration build
I also tagged org.eclipse.equinox.gtk.solaris.x86 for + Bug 305916. [launcher] launcher crashes on Linux GTK when using --launcher.defaultAction (FIXED) It was not included in DJ's tag because that change wasn't releaed for solaris.x86 like it was for all the other platforms. From: DJ Houghton/Ottawa/i...@ibmca To: equinox-dev@eclipse.org Date: 03/22/2010 05:37 PM Subject: [equinox-dev] Updated for integration build Sent by: equinox-dev-boun...@eclipse.org The map file has been updated for the following Bug changes: + Bug 25. [launcher] Mark org.eclipse.equinox.launcher as singleton (FIXED) + Bug 275762. [server-side] easier creation of Equinox server with servletbridge, p2 (ASSIGNED) + Bug 304558. [launcher] Main#findMax fails with bundle names containing '_' (FIXED) + Bug 305916. [launcher] launcher crashes on Linux GTK when using --launcher.defaultAction (FIXED) + Bug 306181. Cannot install new software after updating to last I-build (FIXED) + Bug 306219. Deadlock on startup using Java 2 security on WAS (FIXED) + Bug 306587. [ds][equinox.cm] NPE in SCRManager.configAdminRegistered after starting with a configuration (FIXED) The following projects have changed: org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.servletbridge.extensionbundle org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.launcher.motif.solaris.sparc org.eclipse.equinox.launcher.cocoa.macosx org.eclipse.equinox.ds org.eclipse.equinox.launcher.gtk.linux.x86 org.eclipse.equinox.launcher.cocoa.macosx.x86_64 org.eclipse.equinox.launcher.gtk.linux.ppc64 org.eclipse.equinox.launcher.motif.hpux.ia64_32 org.eclipse.osgi org.eclipse.equinox.launcher org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.equinox.launcher.win32.win32.ia64 org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.osgi.tests org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.launcher.wpf.win32.x86 ___ 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 nightly in testing framework
When running under Eclipse with the org.eclipse.ant.core.antRunner
application, there are two possibilities here.
The first is to use p2. There is a p2 repository
http://download.eclipse.org/eclipse/updates/3.6-N-builds; which contains
the results of the nightly builds.
You can get the osgi bundle from there using a p2 mirror task. (
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_repositorytasks.htm
).
This would look something like :
p2.mirror source=
http://download.eclipse.org/eclipse/updates/3.6-N-builds; destination=
file:${basedir}/osgi
iu id=org.eclipse.osgi /
/p2.mirror
- This will create a p2 repository at ${basedir}/osgi, and the osgi jar
will be at ${basedir}/osgi/plugins/org.eclipse.osgi_version.jar. The
version here will still contain a timestamp like N20091215-2000
- In general, this also gets all the dependencies of the listed
installable units, org.eclipse.osgi doesn't have any.
- 3.6-N-builds is actually a composite of several builds, this will just
get the highest version of osgi.
The other option, is to get the source from CVS, the build.xml script can
be generated using pde.build. This can get complicated in general, but
for osgi it isn't too bad (because there are no dependencies):
eclipse.buildScript
elements=plu...@org.eclipse.osgi
buildDirectory=${basedir}
pluginPath=
${basedir}/../org.eclipse.osgi
forceContextQualifier=N123
/
- forceContextQualifier will be the built version qualifier
- pluginPath will be the location of the osgi bundle on disk
- buildDirectory just needs to be set, it isn't really used here, but in
general other scripts will be generated there
- the osgi build.xml will require a property CDC-1.1/Foundation-1.1
specifying the bootclasspath for foundation.
Both of these options need to run under Eclipse because of the
dependencies on p2 and/or pde.build. If you are running the script using
an external tools configuration, be sure to select Run in the same JRE as
the workspace on the JRE tab.
-Andrew
From:
Walter Treur wtr...@gmail.com
To:
equinox-dev@eclipse.org
Date:
12/15/2009 05:44 AM
Subject:
[equinox-dev] Equinox nightly in testing framework
Sent by:
equinox-dev-boun...@eclipse.org
Hello all,
I'm working on a OSGi testing framework, testing the OSGi
specification conformance for the most popular OSGi core framework
implementations. (equinox, knopferfish, felix)
Public testresults are already available for the most recent popular
core frameworks at
http://opensource.luminis.net/svn/OSGITESTRESULTS/trunk/index.html.
At this moment, I have an own nightly build script to test the latest
(nightly) framework builds from the svn/cvs trunk. It uses ant to
download, build and test the latest trunk version for knopflerfish and
felix and post these results online. However, I'm unable to require or
build the latest nightly equinox version.
The url's to the latest snapshot on the equinox download page contains
a version number and time and it isn't therefore possible to point to
in my ant script since it varies every time. A form post about this
issue wasn't helpful either:
http://www.eclipse.org/forums/index.php?t=msggoto=501643S=1c814a9fba21ff6dcb1d7e7e1890a7f8#msg_501643
I decided to try to build the latest equinox version from the trunk
and this is were I ran into a problem. I did a checkout of the module
org.eclipse.equinox/framework/bundles/org.eclipse.osgi from
dev.eclipse.org Inside eclipse I could create an ant buildfile with
PDE Tools - Create Ant Build File from the contextmenu on the
build.properties file. Running the generated ant script worked fine
and the build was successful.
My question is: Is it possible to generate this ant-build file from a
console or at least without the eclipse UI so I can include it in the
framework's ant script. Of course, if you have another option to
automatically retrieve or build the latest equinox nightly I would be
very pleased to hear.
Regards,
Walter Treur
___
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 tagged for next Helios M4 build.
The launchers have been updated for Helios M4 The map file has been updated for the following Bug changes: + Bug 282758. Add support for 64-bit Power architecture (ASSIGNED) The following projects have changed: org.eclipse.equinox.launcher.gtk.linux.ppc64 org.eclipse.equinox.executable From: Thomas Watson tjwat...@us.ibm.com To: equinox-dev@eclipse.org Date: 12/04/2009 05:58 PM Subject: [equinox-dev] Equinox tagged for next Helios M4 build. Sent by: equinox-dev-boun...@eclipse.org The map file has been updated for the following Bug changes: + Bug 284397. Plugin.isDebugging does not deliver true after Plugin.setDebugging has been called. (FIXED) + Bug 296933. security tests should clean up temp directories (FIXED) The following projects have changed: org.eclipse.equinox.supplement org.eclipse.osgi.tests org.eclipse.osgi 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] New time for equinox call
equinox-dev-boun...@eclipse.org wrote on 07/21/2009 01:02:02 PM: The new selected time for the equinox call is Tuesday at 10:00 AM US/Central (EST). Sorry, is this 10 am central or 10 am eastern? -Andrew ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] AutoStarting Bundles in a Feature Definition
This is possible with something as shown below. This will result in a new
requirement being added to the generated feature.group metadata for your
feature. The requirement is on an IU named toolingorg.acme.bundle. This
IU is a fragment (also commonly called CU for configuration unit), it's
host is com.acme.bundle. The rest of the properties generate that
toolingorg.acme.bundle CU (the $version$ will be replaced with the version
of the feature).
Start level and installation actions are generally delivered as CU
fragments instead of in the bundle metadata directly. You need to be
careful because currently a bundle IU can only have one fragment CU
attached to it. If there is more than one CU fragment available, it is
unpredictable which one wins.
This is the mechanism that pde/build uses to generate default product
start levels for you. Except in that case instead of the p2.inf being
with a feature, it is with the .product file.
requires.1.namespace=org.eclipse.equinox.p2.iu
requires.1.name=toolingorg.acme.bundle
requires.1.range=[$version$,$version$]
requires.1.greedy=true
units.1.id=toolingorg.org.acme.bundle
units.1.version=$version$
units.1.provides.1.namespace=org.eclipse.equinox.p2.iu
units.1.provides.1.name=toolingorg.acme.bundle
units.1.provides.1.version=$version$
units.1.provides.2.namespace=org.eclipse.equinox.p2.flavor
units.1.provides.2.name=tooling
units.1.provides.2.version=1.0.0
units.1.instructions.install=installBundle(bundle:${artifact});
units.1.instructions.uninstall=uninstallBundle(bundle:${artifact});
units.1.instructions.unconfigure=setStartLevel(startLevel:-1);markStarted(started:false);
units.1.instructions.configure=setStartLevel(startLevel:3);markStarted(started:true);
units.1.hostRequirements.1.namespace=osgi.bundle
units.1.hostRequirements.1.name=org.acme.bundle
units.1.hostRequirements.1.range=[1.0.100.v20090520-1905,1.0.100.v20090520-1905]
units.1.hostRequirements.1.greedy=false
units.1.hostRequirements.2.namespace=org.eclipse.equinox.p2.eclipse.type
units.1.hostRequirements.2.name=bundle
units.1.hostRequirements.2.range=[1.0.0,2.0.0)
units.1.hostRequirements.2.greedy=false
units.1.requires.1.namespace=osgi.bundle
units.1.requires.1.name=org.acme.bundle
units.1.requires.1.range=[1.0.100.v20090520-1905,1.0.100.v20090520-1905]
units.1.requires.1.greedy=false
units.1.requires.2.namespace=org.eclipse.equinox.p2.eclipse.type
units.1.requires.2.name=bundle
units.1.requires.2.range=[1.0.0,2.0.0)
units.1.requires.2.greedy=false
cwolfing chase.wolfin...@gmail.com
Sent by: equinox-dev-boun...@eclipse.org
05/18/2009 05:28 PM
Please respond to
Equinox development mailing list equinox-dev@eclipse.org
To
equinox-dev@eclipse.org
cc
Subject
Re: [equinox-dev] AutoStarting Bundles in a Feature Definition
Hi Martin - I saw this example and it works when I have access to the
contained bundle's META-INF. The issue I have is that there are a number
of
cases where I do not have access to the contained bundle's META-INF (these
are prepackaged bundles) and I would like to autostart the bundles during
feature definition.
Chase
Martin Lippert wrote:
Hi!
This is an example that we use for automatically start some of the
Equinox Aspects bundles after p2 installation:
instructions.configure = \
setStartLevel(startLevel:4); \
markStarted(started: true);
HTH,
-Martin
cwolfing wrote:
Hello - Is there a way to use the p2.inf configuration on a feature to
indicate which bundles to mark as started?
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
View this message in context:
http://www.nabble.com/AutoStarting-Bundles-in-a-Feature-Definition-tp23604530p23605733.html
Sent from the Equinox - Dev mailing list archive at Nabble.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: 3.5M6 missing eclipse directory
You can see an example of using the equinox zip in a build here:
dev.eclipse.org:/cvsroot/eclipse/pde-build-home/examples/org.eclipse.pde.build.examples.rcp.cloud.releng
It downloads the equinox repo, and puts it in base/zippedRepos, the
build.properties specifies:
repoBaseLocation=${base}/zippedRepos
transformedRepoLocation=${base}/transformedRepos
This results in a call with the following:
p2.repo2runnable destination=${transformedRepoLocation}
source dir=${repoBaseLocation}/ includes=*/
/p2.repo2runnable
To do this in 3.4, you will need the 3.5 p2 bundles. You can make the
repo2runnable call yourself and then you will also need to add
repoBaseLocation to the pluginPath property.
Alternatively, for this specific case, we know that the runnable form of
all the bundles in the equinox repo is actually a jar with the exception
of the launcher fragments. You can unzip the repo into some location
seperate from your base, and add that location to your pluginPath
property. If you are using the launchers, you will need to unzip those as
well
-Andrew
Pascal Rapicault/Ottawa/i...@ibmca
Sent by: equinox-dev-boun...@eclipse.org
03/17/2009 09:06 AM
Please respond to
Equinox development mailing list equinox-dev@eclipse.org
To
Equinox development mailing list equinox-dev@eclipse.org
cc
Equinox development mailing list equinox-dev@eclipse.org,
equinox-dev-boun...@eclipse.org
Subject
Re: [equinox-dev] Re: 3.5M6 missing eclipse directory
PDE has support for n - 2 but has never guaranteed forward compatibility.
You can always try to run the p2.repo2runnable task to make the repo in a
format against which you can run.
Christian Campo ---03/17/2009 04:15:05 AM---So what do you do, if you use
a 3.4 build process to build a 3.5 target ? which isnt so unusual
From:
Christian Campo christian.ca...@gmail.com
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
03/17/2009 04:15 AM
Subject:
Re: [equinox-dev] Re: 3.5M6 missing eclipse directory
So what do you do, if you use a 3.4 build process to build a 3.5 target ?
which isnt so unusual
2009/3/16 Chris Aniszczyk z...@eclipsesource.com
2009/3/16 Christian Campo christian.ca...@gmail.com
Some more stupid questions.:-)
Ok so that .zip as I learned looks that way because it is p2-ized. No
idea how to tell the PDE Build to use it, but that explains it at least.
In 3.5M5, PDE Build added support to use p2 repos as a target:
http://download.eclipse.org/eclipse/downloads/drops/S-3.5M5-200902021535/eclipse-news-M5.html#PDE
See the 'repoBaseLocation' and 'transformedRepoLocation' properties.
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
--
christian campo (gmail.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
image/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gif___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Showsplash vs SplashPath
There are 3 ways to specify the splash screen: -showsplash, osgi.splashLocation and osgi.splashPath. Order of precendence is as follows: 1) -showsplash this is interpreted by the native launcher, it displays the native early splash screen before starting the vm. This requires a bitmap on the disk (ie in a folder shaped bundle). There is some detail on the wiki http://wiki.eclipse.org/Equinox_Launcher#Command_line_arguments regard the possible values here. If -showsplash is specified to the launcher, and a bitmap is found there, then this will cause the property osgi.splashLocation to be set with the path to that bitmap. 2) osgi.splashLocation (in config.ini or system property). Interpreted by Main, this is a path to the bitmap on disk 3) osgi.splashPath (in config.ini or system property). Interpreted by Main, is a url to a bundle platform:/base urls are resolved relative to osgi.install.area. I don't recal if p2 is setting this, if it doesn't then osgi.install.area is based on the location of the equinox.launcher jar. file: urls would also work here, absolute urls being the best, (see bug 263280 for relative urls). When the final segment is something like org.eclipse.platform, Main is just searching the disk for the highest version org.eclipse.platform_version, it doesn't know which bundles are actually installed into the running system (ie bundles.info) Once a bundle is resolved, we look inside it based on the current osgi.nl value, and we also support jars here (the bitmap is extraced and placed under the configuration area). platform:/base is probably your best bet, however bundle pools may complicate this depending on how p2 manages osgi.install.area, and whether or not the splash bundle is colocated with org.eclipse.equinox.launcher -Andrew Ian Bull irb...@eclipsesource.com Sent by: equinox-dev-boun...@eclipse.org 02/02/2009 12:30 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] Showsplash vs SplashPath Tom (and others), What is the difference between the showsplash and splashpath parameters (properties)? I am working on the publisher for a .product file, and I am trying to figure out what to do with the splash screen. PDE export appears to use splashPath for the splash screen, and if the bundle that contains the splash screen is org.foo, PDE export wold generate: osgi.splashPath=platform:/base/plugins/org.foo Should p2 just use the prefix platform:/base/plugins? Or is this something that will be determined at install time? (i.e. does a shared install need a different prefix)? cheers, Ian -- R. Ian Bull, PhD Software Developer, EclipseSource http://www.ianbull.com http://blog.ianbull.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] Equinox Lauchers for S390
I don't recall ever receiving any S390 binaries. We made the changes to create the fragment and modify the build, but I don't believe the results were ever contributed back. You could ask on the bug, perhaps releng has more details. -Andrew O'Flynn, Dennis dennis.ofl...@compuware.com Sent by: equinox-dev-boun...@eclipse.org 01/14/2009 10:27 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] Equinox Lauchers for S390 Are the equinox launchers for S390/S390x that were contributed for Eclipse v3.3 available anywhere? Reference: https://bugs.eclipse.org/bugs/show_bug.cgi?id=171518 The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. ___ 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] Integrating plugin bundles in normal Java
That main method will end up calling System.exit unless you define a
system property osgi.noShutdown.
You should instead call org.eclipse.equinox.launcher.Main#run(String[]).
(ie new Main().run(args) ).
-Andrew
Tom Hsu tom@oracle.com
Sent by: equinox-dev-boun...@eclipse.org
01/09/2009 01:34 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] Integrating plugin bundles in normal Java
Hi experts,
I have successfully my app A from another main POJO class like the
following:
public static void main(String[] args) {
String[] launcherArgs = {
-configuration,
C:\\pathTto\\configuration,
-install,
C:\\pathToIntall,
-DJavaAgentLogConfigFile=C:\\pathToLogConfig\\log4j-commandline.xml,
-application,
org.my.Application,
};
org.eclipse.core.launcher.Main.main(launcherArgs);
}
The above requires the use of startup.jar's
org.eclipse.core.launcher.Main.main. However, I notice I do not have
control once I called Main.main. I do not have a way for my App A to
return the control to the calling main java file. I tried throwing an
Exception in my app A to see if it will bubble up to the POJO main method,
but it does not. I cannot use System.exit(0) since it terminates the whole
JVM. snippet:
try {
org.eclipse.core.launcher.Main.main(launcherArgs);
} catch (Exception ex)
{
System.out.println(I am done with app A);
}
in app A's terminate method:
terminate() {
System.out.println();
//System.exit();
throw new RuntimeException(I am done. get me out of here);
}
What is a better way to achieve this? Bascially I want to run App A which
through eclipse and use osgi from another program. Once App A is done, it
needs to terminate and return control to the my POJO.
Regards,
Tom
Thomas Watson wrote:
I would recommend that you launch app A in a way that is consistent with
the normal launch of eclipse. By that I mean use a configuration folder
with a config.ini that is the same as if you are launching your
application with the eclipse.exe. The config.ini configures a set of
bundles into the framework for your application. You should be able to do
something like this
String[] equinoxArgs = { -console, -noExit,
-configuration /path/to/configuration,
-application, myApp.Application};
BundleContext context = EclipseStarter.startup(equinoxArgs, null);
Object appResult = EclipseStarter.run(null);
Tom
Tom Hsu ---10/29/2008 01:41:44 PM---Hi experts,
From:
Tom Hsu tom@oracle.com
To:
equinox-dev@eclipse.org
Date:
10/29/2008 01:41 PM
Subject:
[equinox-dev] Integrating plugin bundles in normal Java
Hi experts,
I am new to equinox so please excuse me for some obvious/stupid
questions. However, I am still trying to wrap my head around this module
system.
I am tasked with integrating an existing application A that is build
using bundles and equinox osgi in eclipse into another standalone Java
program B that will be traditional jar based program. I would like to
invoke the Equinox OSGi system to load these bundles/packages in the
standalone Java program through code and execute the main method of the
app A through program B.
My setup is as follows:
/plugins/ all the bundles that app A requires are here.
also app A has a main bundle here
I can use Eclipse Application run option to launch it or comandline
java -cp startup.jar org.eclipse.core.launcher.Main -
application myApp.Application ...
However, I am exploring the option to launch app A with another existing
java program B. As a prototype, I am writing a plain POJO with main
method:
public static void main(String[] args) throws Exception {
String[] equinoxArgs = { -console, -noExit };
BundleContext context = EclipseStarter.startup(equinoxArgs, null);
String pluginDir = file:C:\\work\\;
String commonJarName =
org.eclipse.equinox.common_3.2.0.v20060603.jar;
String configJarName =
org.eclipse.update.configurator_3.2.2.R32x_v20070111.jar;
Bundle commonBundle = context.installBundle(pluginDir +
commonJarName);
Bundle configBundle = context.installBundle(pluginDir +
configJarName);
configBundle.start();
String jarName = fetchlets.jar;
String directoryPath = file:C:\\work\\plugins\\;
String locationStr = directoryPath + jarName;
Bundle bundle = context.installBundle(locationStr);
bundle.start();
}
However, my bundle fetchlets.jar cannot be started because, the
configurator bundle does not auto-discover all the required bundles in
the plugins directory. Can someone help me figure out if I can tell the
EclipseStarter to auto-load all bundles at a specific locations?
Or is there another approach I can use that
Re: [equinox-dev] normalized jar
I would suggest trying 3.4M7 where that bug was first fixed, or just move up to 3.4. Or if there are other problems upgrading, try at least taking org.eclipse.update.core from 3.4 -Andrew Janet Dmitrovich [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2008 05:29 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] normalized jar The build is using eclipse-SDK-I20071127-0800-win32 ( to do the normalization and signing ) this looks to be a milestone build of 3.4 They had some issue moving up to the 3.4 GM level. I am using eclipes 20080617 for packing. All of our jars contain eclipse.inf with pack200.conditioned=true Janet Dmitrovich WPLC Expeditor Software Development [EMAIL PROTECTED] 512-838-4912 T/L:678-4912 FAX:512-838-3703 11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372) Andrew Niefer ---10/07/2008 05:38:19 PM---Which version of the jarprocessor are you using? Andrew Niefer [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/07/2008 05:37 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] normalized jar Which version of the jarprocessor are you using? There was a bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=226850) fixed in 3.4. This was leading to verification errors on the META-INF/eclipse.inf files. Though if I remember correctly, it could have potentially led to different pack effort levels used on the pack step compared to the conditioning step which might affect .class files. The org.eclipse.equinox.p2.jarprocessor contains a Verifier class which will unpack pack.gz files and verify their signatures. It has a static main method that you can run. If you have the conditioned jars from before packing, they should contain an eclipse.inf file containing pack200.conditioned=true. Janet Dmitrovich [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/07/2008 05:55 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] normalized jar Hi thanks for the reply Andrew. If you are getting differences after unpack, you may not actually be using pack200 conditioned/normalized jars, or something went wrong in that -repack normalization step. So I am finding differences in the jar sizes ( pre and post pack ) I'm fairly certain that I am using pack200 conditioned/normalized jars, since they were built with the -repack option. Is there some way to validate this? What type if things could go wrong in the -repack/ normalization step. Janet Dmitrovich WPLC Expeditor Software Development [EMAIL PROTECTED] 512-838-4912 T/L:678-4912 FAX:512-838-3703 11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372) Andrew Niefer ---10/07/2008 04:24:57 PM---The contents of the jar should be bit-wise the same, so the only difference between pre post pack (for a previously condition Andrew Niefer [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/07/2008 04:18 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] normalized jar The contents of the jar should be bit-wise the same, so the only difference between pre post pack (for a previously conditioned jar), if any, would be in the format of the jar itself. Differences could be, for example, in size crc information for a given zip entry appearing before or after the entry itself. I'm not sure that these differences would amount to a size difference for the jar. In the case of nested jars which are checked against their containers, we do need the jars to be bitwise the same even in jar format. For this reason, the jarProcessor in eclipse does an additional normalization step which is different from the pack200 -repack conditioning. If you are getting differences after unpack, you may not actually be using pack200 conditioned/normalized jars, or something went wrong in that -repack normalization step. -Andrew Janet Dmitrovich [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/07/2008 03:58 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] normalized jar Should the size of the jar ( Normalized and signed jar ) be the same pre-packand post-unpack ? Janet Dmitrovich WPLC Expeditor Software Development [EMAIL PROTECTED] 512-838-4912 T/L:678-4912 FAX:512-838-3703 11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372) ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] normalized jar
The contents of the jar should be bit-wise the same, so the only difference between pre post pack (for a previously conditioned jar), if any, would be in the format of the jar itself. Differences could be, for example, in size crc information for a given zip entry appearing before or after the entry itself. I'm not sure that these differences would amount to a size difference for the jar. In the case of nested jars which are checked against their containers, we do need the jars to be bitwise the same even in jar format. For this reason, the jarProcessor in eclipse does an additional normalization step which is different from the pack200 -repack conditioning. If you are getting differences after unpack, you may not actually be using pack200 conditioned/normalized jars, or something went wrong in that -repack normalization step. -Andrew Janet Dmitrovich [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/07/2008 03:58 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] normalized jar Should the size of the jar ( Normalized and signed jar ) be the same pre-packand post-unpack ? Janet Dmitrovich WPLC Expeditor Software Development [EMAIL PROTECTED] 512-838-4912 T/L:678-4912 FAX:512-838-3703 11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372) ___ 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] normalized jar
Which version of the jarprocessor are you using? There was a bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=226850) fixed in 3.4. This was leading to verification errors on the META-INF/eclipse.inf files. Though if I remember correctly, it could have potentially led to different pack effort levels used on the pack step compared to the conditioning step which might affect .class files. The org.eclipse.equinox.p2.jarprocessor contains a Verifier class which will unpack pack.gz files and verify their signatures. It has a static main method that you can run. If you have the conditioned jars from before packing, they should contain an eclipse.inf file containing pack200.conditioned=true. Janet Dmitrovich [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/07/2008 05:55 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] normalized jar Hi thanks for the reply Andrew. If you are getting differences after unpack, you may not actually be using pack200 conditioned/normalized jars, or something went wrong in that -repack normalization step. So I am finding differences in the jar sizes ( pre and post pack ) I'm fairly certain that I am using pack200 conditioned/normalized jars, since they were built with the -repack option. Is there some way to validate this? What type if things could go wrong in the -repack/ normalization step. Janet Dmitrovich WPLC Expeditor Software Development [EMAIL PROTECTED] 512-838-4912 T/L:678-4912 FAX:512-838-3703 11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372) Andrew Niefer ---10/07/2008 04:24:57 PM---The contents of the jar should be bit-wise the same, so the only difference between pre post pack (for a previously condition Andrew Niefer [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/07/2008 04:18 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] normalized jar The contents of the jar should be bit-wise the same, so the only difference between pre post pack (for a previously conditioned jar), if any, would be in the format of the jar itself. Differences could be, for example, in size crc information for a given zip entry appearing before or after the entry itself. I'm not sure that these differences would amount to a size difference for the jar. In the case of nested jars which are checked against their containers, we do need the jars to be bitwise the same even in jar format. For this reason, the jarProcessor in eclipse does an additional normalization step which is different from the pack200 -repack conditioning. If you are getting differences after unpack, you may not actually be using pack200 conditioned/normalized jars, or something went wrong in that -repack normalization step. -Andrew Janet Dmitrovich [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/07/2008 03:58 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] normalized jar Should the size of the jar ( Normalized and signed jar ) be the same pre-packand post-unpack ? Janet Dmitrovich WPLC Expeditor Software Development [EMAIL PROTECTED] 512-838-4912 T/L:678-4912 FAX:512-838-3703 11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372) ___ 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 image/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] is there an option (per jar ) that can be used to skip normalize
There is no option to skip just the -repack normalization and not the packing. The only way to do this is to just not run the -repack in the first place, which I guess means separating that one jar from the rest when processing. Is there a particular reason why you would want to skip this normalization? Without it, the pack step essentially becomes the normalization. Later on unpack, you get different bits which are the same as you would have gotten from the repack. -Andrew Janet Dmitrovich [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/03/2008 04:25 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] is there an option (per jar ) that can be used to skip normalize On this jarprocessor options page, http://wiki.eclipse.org/JarProcessor_Options It mentions that you can add an option per jar to not sign or not pack But is there an option to not normalize? So we are normalizing and signing a full update site but there is one jar we do not want to normalize before packing. Janet Dmitrovich WPLC Expeditor Software Development [EMAIL PROTECTED] 512-838-4912 T/L:678-4912 FAX:512-838-3703 11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372) ___ 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] Installer and agent data location
Note that there are command line options to the director for both the p2 data area and whether or not to install features. See the help: Platform Plug-in Developer Guide - Programmer's Guide -? Packaging and delivering Eclipse based products - Provisioning platform (p2) - Installing software using p2 director application In the Section Installing a complete product, see the arguments: -profileProperties org.eclipse.update.install.features=true -vmargs -Declipse.p2.data.area=D:/eclipse/p2 -Andrew John Arthorne/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 06/11/2008 02:30 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] Installer and agent data location Torkild/Pedro: I suggest entering bug reports to track these two issues. I'm not aware of existing bug reports about it. John Torkild Ulvøy Resheim [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 06/11/2008 10:13 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] Installer and agent data location On Wed, 2008-06-11 at 06:57 -0700, Pedro Carneiro wrote: As you mentioned earlier, the /p2 directory is not created by the installer in the installation directory. I also noticed that the /p2 directory is created and updated [when the eclipse is running] in the install directory (the directory where the installer was). I think that the installer forget to move or, somehow, is not moving the /p2 directory to the installation directory. Yes, it looks like that. And if you delete the installer, your installation will be broken and cannot be updated. 1. I did not find a bug for this. Is there one to keep me on track of this? In RC4, I noticed that the /features directory is back. The installer delivered in the RC4 is not creating the /features directory also. The installer found in HEAD is not creating the features directory. That is a result of setting IProfile.PROP_INSTALL_FEATURES of the profile to true. For our installer I've set this property inInstallUpdateProductOperation.createProfile(). I have no idea if the installer should install features or not. 2. I did not find a bug for this. Is there one to keep me on track of this? Thanks, Pedro Carneiro I've not found any bugs to track these issues either. Could someone from the p2 team please comment on this thread? Regards, Torkild ___ 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: Need help building a product with p2
) Create a complete product layout from (2) and (3) 5) Run the p2 metadata generator on (4) 6) Run the p2 director on (5), generating a p2 directory in (4) Thanks, Warren -- Message: 3 Date: Sat, 31 May 2008 07:41:37 -0500 From: [EMAIL PROTECTED] Subject: [equinox-dev] RE: Need help building a product with p2 To: equinox-dev@eclipse.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain;charset=us-ascii Hi Andrew, Changing the paths to URL's helped. It now finds the product id installIU, and takes a couple of minutes. But it eventually comes back with Installation failed. I wasn't sure what to put for profile. I assume PlatformProfile? I tried that, SDKProfile, and remove the profile option altogether. I get the same error each time. Is there a way to get more details on what failed? A verbose option perhaps? Here's exactly how I'm invoking the director: eclipsec.exe -nosplash -application org.eclipse.equinox.p2.director.app.application -metadataRepository file:C:\testproduct2\repository -artifactRepository file:C:\testproduct2\repository -installIU com.nokia.carbide.cpp.product -destination C:\testproduct2\eclipse -profile PlatformProfile -profileProperties org.eclipse.update.install.features=true -bundlepool C:\testproduct2\eclipse -p2.os win32 -p2.ws win32 -p2.arch x86 -roaming -vmargs -Declipse.p2.data.area=C:\testproduct2\eclipse\p2 where C:\testproduct2\eclipse is where I exported the product to, and C:\testproduct2\repository is what PDE generated for the product. Thanks, Warren Date: Fri, 30 May 2008 16:20:35 -0400 From: Andrew Niefer [EMAIL PROTECTED] Subject: Re: [equinox-dev] Need help building a product with p2 To: Equinox development mailing list equinox-dev@eclipse.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Warren, 1) This is what I notice when I tried running your director command on a product I exported: - the -metadataRepository and -artifactRepository values need to be URLs: use file:C:\testproduct\repository - I found I needed to specify -installIU to get anything out. In this case the IU is the product ID - althrough not strictly necessary since the generated config.ini will specify its location, you might want to put the p2.data.area in the same folder as -destination. My test product does not contain p2 bundles so I have not tried the Software updates. [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 05/29/2008 08:25 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] Need help building a product with p2 I've received some help from Andrew in this Bugzilla ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=226614) but I'm still having problems so I thought I'd take it to the list rather than in that Bugzilla. We've been shipping an IDE product based on Eclipse for a few years now. The way we've built our product in the past is essentially this: 1) Download the platform runtime, EMF, GEF, etc.. from eclipse.org and extract them into a product layout directory. 2) Checkout and tag our features and plugins 3) Use headless feature build on all of our features, and extract the generated archives into the product layout directory. 4) Copy our modified version of config.ini, .eclipseproduct, etc. into the product layout directory. 5) Generate an update site based on the generated features/plugins. This gives us a full product layout for new installs, and allows users with older installs of our product to update to the new version using the update site. This process broke when we moved to Eclipse 3.4M6 when p2 was introduced. I've come to discover that we weren't really building it in the ideal fashion to begin with, so I'm trying to do it the proper way so we can get a properly p2-ized product layout and update site. Andrew provided several useful links in that Bugzilla. I've read about doing product builds, using the p2 meta generator and p2 director. I've also played with the examples from EclipseCon presentation. Here are some of the problems I'm having: 1) I created a .product file based on features. I included our features as well as those org.eclipse features that we bundle with. When I export it using the PDE product export from the UI, it generates a directory containing everything we need - all features and plugins (ours and org.eclipse.*), our branded launcher and ini file, .eclipseproduct file, config.ini file, jre, etc.. It of course does not contain the p2 data though. I told the exporter to generate a metadata repository which it did. I think I'm then supposed to run it through the p2 director to get the proper p2 directory. I tried this, and it generated something, but I get the error Cannot launch the Update UI. This installation has not been configured properly for Software Updates when I try to go to Help-Software Updates. I assume I didn't get
Re: [equinox-dev] pack200 - are packed features supported?
Janet, From a brief look at the code, it appears that the old update (org.eclipse.update.core) only runs unpack on plugin jars and not on feature jars. It shouldn't even look for .pack.gz files for the features, if you are failing does that mean your update site only contains pack.gz files and not the normal jars? (Generally, it was suggested that both should be placed on the update site in case of a failure with pack200). I'm not sure for certain, but I expect that p2 would support pack200 on all jars since everything is an IU and they are just artifacts. As an aside, note that the pack200 compression works on .class files. So, in general there is not much to be gained by packing features. -Andrew Janet Dmitrovich [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 06/04/2008 04:52 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] pack200 - are packed features supported? Question on pack200 I packed a feature jar and the associated plugins, and packaged them into an update site. Tried to install via update manager - the install failed. However if I use an unpacked feature jar, but include packed plugins in the update site then the install is successful. Is there something special about feature jars and pack200 thanks, Janet Janet Dmitrovich WPLC Expeditor Software Development [EMAIL PROTECTED] 512-838-4912 T/L:678-4912 FAX:512-838-3703 11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372) ___ 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] Need help building a product with p2
Warren,
1) This is what I notice when I tried running your director command on a
product I exported:
- the -metadataRepository and -artifactRepository values need to be
URLs: use file:C:\testproduct\repository
- I found I needed to specify -installIU to get anything out. In this
case the IU is the product ID
- althrough not strictly necessary since the generated config.ini will
specify its location, you might want to put the p2.data.area in the same
folder as -destination.
My test product does not contain p2 bundles so I have not tried the
Software updates.
[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
05/29/2008 08:25 PM
Please respond to
Equinox development mailing list equinox-dev@eclipse.org
To
equinox-dev@eclipse.org
cc
Subject
[equinox-dev] Need help building a product with p2
I've received some help from Andrew in this Bugzilla (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=226614) but I'm still having
problems so I thought I'd take it to the list rather than in that
Bugzilla.
We've been shipping an IDE product based on Eclipse for a few years now.
The way we've built our product in the past is essentially this:
1) Download the platform runtime, EMF, GEF, etc.. from eclipse.org and
extract them into a product layout directory.
2) Checkout and tag our features and plugins
3) Use headless feature build on all of our features, and extract the
generated archives into the product layout directory.
4) Copy our modified version of config.ini, .eclipseproduct, etc. into the
product layout directory.
5) Generate an update site based on the generated features/plugins.
This gives us a full product layout for new installs, and allows users
with older installs of our product to update to the new version using the
update site.
This process broke when we moved to Eclipse 3.4M6 when p2 was introduced.
I've come to discover that we weren't really building it in the ideal
fashion to begin with, so I'm trying to do it the proper way so we can get
a properly p2-ized product layout and update site.
Andrew provided several useful links in that Bugzilla. I've read about
doing product builds, using the p2 meta generator and p2 director. I've
also played with the examples from EclipseCon presentation.
Here are some of the problems I'm having:
1) I created a .product file based on features. I included our features
as well as those org.eclipse features that we bundle with. When I export
it using the PDE product export from the UI, it generates a directory
containing everything we need - all features and plugins (ours and
org.eclipse.*), our branded launcher and ini file, .eclipseproduct file,
config.ini file, jre, etc.. It of course does not contain the p2 data
though. I told the exporter to generate a metadata repository which it
did. I think I'm then supposed to run it through the p2 director to get
the proper p2 directory. I tried this, and it generated something, but I
get the error Cannot launch the Update UI. This installation has not
been configured properly for Software Updates when I try to go to
Help-Software Updates. I assume I didn't get the command line correct
for the p2 director. This is what I did:
eclipsec.exe -nosplash -application
org.eclipse.equinox.p2.director.app.application -metadataRepository
C:\testproduct\repository\ -artifactRepository C:\testproduct\repository\
-destination C:\testproduct\eclipse\ -profile PlatformProfile
-profileProperties org.eclipse.update.install.features=true -bundlepool
C:\testproduct\eclipse -p2.os win32 -p2.ws win32 -p2.arch x86 -roaming
-vmargs -Declipse.p2.data.area=C:\testproduct2\eclipse\p2
Any idea what I'm doing wrong? I thought I should be passing -installIU
but wasn't sure what to pass with it. I tried the product id but it
errored out saying it couldn't find the IU.
2) What I did in 1) was really just a test because we'll need to build
everything from the command line and not from the export wizard. I tried
to build the product from the command line and kept getting an error that
org.eclipse.rcp could not be found. I removed all org.eclipse.* features
from our product file and tried again. Now it builds, and it generates
the repo directory because I added the stuff to our build.properties file
as instructed:
generate.p2.metadata=true
p2.metadata.repo = file:${buildDirectory}/repo
p2.artifact.repo = file:${buildDirectory}/repo
p2.metadata.repo.name = Carbide.c++ Metadata Repository
p2.artifact.repo.name = Carbide.c++ Artifact Repository
p2.flavor = tooling
p2.publish.artifacts=true
This repo directory only contains the two xml files though (artifacts.xml
and content.xml), unlike the product export which generated those as well
as binary, features and plugins directories.
The other issue is that none of the org.eclipse.* features/plugins are
included. This is presumably because they're no longer in the .product
file, but I had to do that to get the build to work. I
Re: [equinox-dev] How to use p2.generator in PDE build
Torkild,
In addition to any manual calls you may want to make to the p2.generator,
there is some integration with PDE.Build.
Unfortunately there is not yet any documentation here.
If the org.eclipse.equinox.p2.metadata.generator bundle is present in the
builder at script generation time, then there are potentially 4N + 1
generated calls to the p2.generator.
For N configurations:
1) In the assemble.[feature].[config].xml scripts: a) Once on
assembled features and plugins
b) a second time on
assembled rootfiles.
2) In the package.[feature].[config].xml scripts: a) Once of the
packaged features and plugins
b) again on rootfiles from
packaging
And one final call:
3) In the assemble.all.xml or package.all.xml : A final call to generate a
root product IU
These calls are all conditional on the generate.p2.metadata property
being set. In the case of a product build, the final result at the end of
these calls is a repo with an installable product IU.
To get an actual p2ized install out of this, you then need to call the
p2.director on the repo and install
As an example, the SDK is built by first building a master zip containing
everything. p2.generator is called on this in a custom step to generate
IUs for all the plugins and features. Then the build runs the pde build
packager with a .product file and metadata integration to assemble all the
rootfiles and generate p2 data on them (steps 2 3 above). Then finally
in custom steps it calls p2.director to install the SDK and zip up the
results.
-Andrew
Some properties to define are:
generate.p2.metadata=true
p2.metadata.repo = file:${buildDirectory}/repo
p2.artifact.repo = file:${buildDirectory}/repo
p2.metadata.repo.name = Meta Repo Name
p2.artifact.repo.name = Artifact Repo Name
p2.flavor = tooling
p2.publish.artifacts=true
John Arthorne/Ottawa/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
05/20/2008 10:27 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] How to use p2.generator in PDE build
Hi Torkild,
Here is a document describing the metadata generator:
http://wiki.eclipse.org/Equinox_p2_Metadata_Generator
The ant task doesn't yet have documentation, but it takes the same
arguments as the generator application. You just need to convert the
command line syntax to Ant syntax. For an example, you could look at the
Eclipse project scripts that p2-enable the platform itself. See
/cvsroot/eclipse/org.eclipse.releng.eclipsebuilder/equinox/buildConfigs/equinox.prov/run.xml,
particularly the run.generator target.
Feel free to annotate the wiki page with any other details you find
useful.
John
Torkild Ulvøy Resheim [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
05/20/2008 09:50 AM
Please respond to
Equinox development mailing list equinox-dev@eclipse.org
To
equinox-dev@eclipse.org
cc
Subject
[equinox-dev] How to use p2.generator in PDE build
Hi all,
I'm in the process of migrating our Eclipse based product to Ganymede and
have
a few issues with p2.
Building the product as usual using the PDE build scripts works nicely but
creates a product that cannot be updated as it states 'Cannot launch the
Update UI. This installation has not been configured properly for Software
Updates.'
After quite a lot of digging I've found that the product must be p2-ized
which
seems like a good idea. I also found a reference to the p2.generator ANT
task but absolutely no information on how to use it.
Could someone please point me to the right direction here? I guess I must
use
this task somewhere in customCallbacks.xml or the new customAssembly.xml
but
I cannot figure out where and which attributes to set.
--
Torkild Ulvøy Resheim
Senior Design Engineer
Atmel Norway AS
___
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] pack200 M5 question
Janet, Changing startup.jar to org.eclipse.equinox.launcher should work, note that you need to make sure you reference the actual jar in your install which will have a version number on it. Eg: java -jar /eclipse/plugins/org.eclipse.equinox.launcher_1.0.100.v20080303.jar -application -Andrew Janet Dmitrovich [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 04/04/2008 02:35 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] pack200 M5 question Using the example on this page http://wiki.eclipse.org/index.php/Pack200 Specifically : java -jar /eclipse/startup.jar -application org.eclipse.update.core.siteOptimizer -jarProcessor -processAll -repack -sign signing-script.sh -outputDir ./out sample.jar For Eclipse 3.2.x - this seems to work ok For Eclipse 3.4 M5 - I thought I would only have to change startup.jar to org.eclipse.equinox.launcher.jar but this did not seem to work. What else needs to change? Janet Dmitrovich WPLC Expeditor Software Development [EMAIL PROTECTED] 512-838-4912 T/L:678-4912 FAX:512-838-3703 11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372) ___ 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] Committer vote for Andrew Niefer has been approved by the PMC
Thanks everyone. I wonder if this is a new speed record for a vote, only a little over 9.5 hours from first to last email :) -Andrew [EMAIL PROTECTED] (portal on behalf of Jeff McAffer) Sent by: [EMAIL PROTECTED] 02/28/2008 09:42 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] Committer vote for Andrew Niefer has been approved by the PMC 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 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [launcher] Showsplash
In the case of the splash screen, it is a simple line in the eclipse.ini file which indicates the splash bitmap to use. The difference between an english and a german splash screen could be as simple as -showsplash org.foo.branding/en/splash.bmp -showsplash org.foo.branding/de/splash.bmp I expect that since the launcher fragments can contribute --launcher.library lines to the .ini file, it should be possible for branding IUs to contribute -showsplash. Though I'm not sure if a single IU can contribute different arguments depending on a platform/nl filter, it might require branding fragments? -Andrew Stefan Liebig [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 02/07/2008 09:44 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] [launcher] Showsplash I am using a freeware tool (http://www.angusj.com/resourcehacker/) to modify our win32 NL for smartup so that is possible to change (branding) the splash screen and string resources without the need of recompiling our NL. However, this is not done at install time, although it might be possible, because this tool can run in command line mode. Just another thought. Jeff McAffer wrote: alternatively is it possible to have the installer configure the launcher with the right splash? of course that assumes that the NL is fixed from install time. Just a thought Jeff Andrew Niefer wrote: James, The native code that is showing the early splash screen does not have support to change the bitmap that is being shown. This means that you need to wait until swt is available before it can be refreshed. With SWT I believe changing the image is just setting the BackgroundImage on the shell. The simplest way of contributing SWT to the splash screen is to use the workbench org.eclipse.ui.splashHandlers extension point and extend the EclipseSplashHandler class. The only problem is that the code that handles the osgi.splashPath and searches for NL variants (Main.getSplashLocation Main.searchForSplash) is not available available outside of Main. You will probably have to do that search yourself. -Andrew *James D Miles [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 02/06/2008 11:01 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] [launcher] By using the -showsplash I can get an early splash screen. However when not using this mechanism we were able to set osgi.splashPath with a comma separated list of URLs. We still need the splash selection based on nl that we got when using osgi.splashPath. How can we get the splashpath bmp refreshed after early startup? The default behavior seems to be to continue using the early splash screen.___ 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] [prov] I20080207-0010 metadata not usable
The problem here comes down to the feature versions not incrementing when one of their contained plug-ins increases it version. The root cause of this is the generated feature version suffixes which are supposed to account for the changes in the nested plugins. These suffixes were turning out to be too long and so we ended up truncating them to avoid path length issues. When the actual version deltas are small enough (ie in a runup to a milestone build where only 1 or 2 plugins change), the change in the feature suffix is not significant enough to escape the truncation. We have in the past investigated methods of making the suffixes shorter (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=175714) but where unable to come up with a satisfactory solution. In the short term, all that can be done is to increase the length at which we truncate the suffixes in the sdk build. Path length is a smaller issue now because of individual source bundles. However, this is not a real solution and may not actually help if the version deltas are small enough. Any ideas about what can be done to address this problem are welcome. Currently the only idea I have is to compare generated versions against the results of a previous build. -Andrew Pascal Rapicault/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 02/07/2008 09:48 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] [prov] I20080207-0010 metadata not usable Because of PDE bu https://bugs.eclipse.org/bugs/show_bug.cgi?id=208143, it is not possible to install I20080207-0010. 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] [launcher] Showsplash
James, The native code that is showing the early splash screen does not have support to change the bitmap that is being shown. This means that you need to wait until swt is available before it can be refreshed. With SWT I believe changing the image is just setting the BackgroundImage on the shell. The simplest way of contributing SWT to the splash screen is to use the workbench org.eclipse.ui.splashHandlers extension point and extend the EclipseSplashHandler class. The only problem is that the code that handles the osgi.splashPath and searches for NL variants (Main.getSplashLocation Main.searchForSplash) is not available available outside of Main. You will probably have to do that search yourself. -Andrew James D Miles [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 02/06/2008 11:01 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] [launcher] By using the -showsplash I can get an early splash screen. However when not using this mechanism we were able to set osgi.splashPath with a comma separated list of URLs. We still need the splash selection based on nl that we got when using osgi.splashPath. How can we get the splashpath bmp refreshed after early startup? The default behavior seems to be to continue using the early splash screen. ___ 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] Download manager support for pack200
I was thinking a new separate classloader containing just the Pack200 classes. We would still want to delegate to the bootclassloader for everything else. However, I doubt the Pack200 classes are by themselves in their own jar that we could just create a URLClassloader for. This was really just an idea and I haven't really thought very hard about the details :) -Andrew Thomas Watson [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/25/2008 11:54 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] [prov] Download manager support for pack200 If the Pack200 class is loaded from the VM then it will fall under the boot class loader. There is no way we can throw that class loader away. Are you suggesting that we could somehow load this class from an isolated class loader that is not connected to the boot class loader? Tom Andrew Niefer ---01/25/2008 09:57:39 AM---As Pascal mentioned, when we first started experimenting with Pack200 we had memory problems. It seemed that Pack200's interna From: Andrew Niefer [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/25/2008 09:57 AM Subject: Re: [equinox-dev] [prov] Download manager support for pack200 As Pascal mentioned, when we first started experimenting with Pack200 we had memory problems. It seemed that Pack200's internal data was static and not cleared between each jar that was packed. So once we had packed a reasonable number of jars we started running out of memory. It could be that we had been doing something wrong. It is also possible that we could work around this by playing with class loaders (under the assumption that if the classloader was garbage collected, all that static memory would go away). -Andrew Thomas Hallgren [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/25/2008 02:53 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] [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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Equinox development mailing list equinox-dev@eclipse.org, [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 equinox-dev@eclipse.org 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
Re: [equinox-dev] [prov] Download manager support for pack200
As Pascal mentioned, when we first started experimenting with Pack200 we had memory problems. It seemed that Pack200's internal data was static and not cleared between each jar that was packed. So once we had packed a reasonable number of jars we started running out of memory. It could be that we had been doing something wrong. It is also possible that we could work around this by playing with class loaders (under the assumption that if the classloader was garbage collected, all that static memory would go away). -Andrew Thomas Hallgren [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/25/2008 02:53 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] [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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Equinox development mailing list equinox-dev@eclipse.org, [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 equinox-dev@eclipse.org 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 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] Could not find main-class org.eclipse.core.laun cher.WebStartMain
A NullPointerException at this location implies that the org.eclipse.osgi bundle was not found. It was looked for in the in the results returned from Enumeration resources = WebStartMain.class .getClassLoader().getResources(JarFile.MANIFEST_NAME); -Andrew Swanson, Dennis [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/29/2007 02:31 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] Could not find main-class org.eclipse.core.laun cher.WebStartMain My bad Alex... Apparently I can't read. The following did work afterall. application-desc main-class=org.eclipse.equinox.launcher.WebStartMain argument-nosplash/argument /application-desc Now we're getting a null pointer exception. But at least we've gotten past that part. Here's the NPE that we're getting if anyone has a suggestion on that. java.lang.NullPointerException at java.util.Hashtable.put(Unknown Source) at org.eclipse.equinox.launcher.WebStartMain.basicRun(WebStartMain.java:77) at org.eclipse.equinox.launcher.Main.run(Main.java:1173) at org.eclipse.equinox.launcher.WebStartMain.main(WebStartMain.java:56) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sun.javaws.Launcher.executeApplication(Unknown Source) at com.sun.javaws.Launcher.executeMainClass(Unknown Source) at com.sun.javaws.Launcher.continueLaunch(Unknown Source) at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source) at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source) at com.sun.javaws.Launcher.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Dennis From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Swanson, Dennis Sent: Thursday, November 29, 2007 9:47 AM To: 'Equinox development mailing list' Subject: RE: [equinox-dev] Could not find main-class org.eclipse.core.laun cher.WebStartMain Not sure if this helps, but I did some more searching and it appears that we're having the same problems that Tejah had back in August. http://www.eclipsepowered.org/forums/thread.jspa?messageID=92168477#92168477 The link suggests that culprit may be that the org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar could be referenced from the wrong jnlp. I verified our jnlp and it looks right to me. So there's something else funky going on. Anybody have any more ideas? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Swanson, Dennis Sent: Wednesday, November 28, 2007 5:51 PM To: 'Equinox development mailing list' Subject: RE: [equinox-dev] Could not find main-class org.eclipse.core.laun cher.WebStartMain. class If only It was that easy. =) I made the change as you suggested, but got the same error: Could not find main-class org.eclipse.core.launcher.WebStartMain in http://localhost:18080/AgileCourtWebStart/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Niefer Sent: Wednesday, November 28, 2007 5:40 PM To: Equinox development mailing list Subject: Re: [equinox-dev] Could not find main-class org.eclipse.core.launcher.WebStartMain. class In 3.3 the Webstart main class is org.eclipse.equinox.launcher.WebStartMain. We left a stub org.eclipse.core.launcher.Main, but it looks like we forgot to put a stub for the old WebStartMain. I expect you simply need to change application-desc main-class=org.eclipse.equinox.launcher.WebStartMain.class argument-nosplash/argument /application-desc -Andrew Swanson, Dennis [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/28/2007 05:29 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To 'equinox-dev@eclipse.org' equinox-dev@eclipse.org cc Subject [equinox-dev] Could not find main-class org.eclipse.core.launcher.WebStartMain. class We are trying to migrate our RCP application from Eclipse 3.2 to 3.3.1.1. When we deploy the application, we get the following error: Could not find main-class org.eclipse.core.launcher.WebStartMain.class in http://localhost:18080/AgileCourtWebStart/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar Below is the full exception with the JNLP file included. Does anyone have any suggestions? Thanks, Dennis JNLPException[category: Launch File Error : Exception: null : LaunchDesc: jnlp spec=1.0+ codebase=http://localhost:18080/AgileCourtWebStart/; information titleAgileCourt Rich Client 1.0/title vendor(c) 2007 ACS/vendor homepage href= http://localhost:18080/AgileCourtWebStart/www.acs-inc.com/ descriptionAgileCourt Rich
Re: [equinox-dev] Could not find main-class org.eclipse.core.launcher.WebStartMain. class
In 3.3 the Webstart main class is org.eclipse.equinox.launcher.WebStartMain. We left a stub org.eclipse.core.launcher.Main, but it looks like we forgot to put a stub for the old WebStartMain. I expect you simply need to change application-desc main-class=org.eclipse.equinox.launcher.WebStartMain.class argument-nosplash/argument /application-desc -Andrew Swanson, Dennis [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/28/2007 05:29 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To 'equinox-dev@eclipse.org' equinox-dev@eclipse.org cc Subject [equinox-dev] Could not find main-class org.eclipse.core.launcher.WebStartMain. class We are trying to migrate our RCP application from Eclipse 3.2 to 3.3.1.1. When we deploy the application, we get the following error: Could not find main-class org.eclipse.core.launcher.WebStartMain.class in http://localhost:18080/AgileCourtWebStart/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar Below is the full exception with the JNLP file included. Does anyone have any suggestions? Thanks, Dennis JNLPException[category: Launch File Error : Exception: null : LaunchDesc: jnlp spec=1.0+ codebase=http://localhost:18080/AgileCourtWebStart/; information titleAgileCourt Rich Client 1.0/title vendor(c) 2007 ACS/vendor homepage href= http://localhost:18080/AgileCourtWebStart/www.acs-inc.com/ descriptionAgileCourt Rich Client 1.0/description /information security all-permissions/ /security resources j2se initial-heap-size=134217728 max-heap-size=134217728 version=1.5+/ extension href=http://localhost:18080/RcpWebStart/RcpWebStart.jnlp; name=RCP Framework/ jar href= http://localhost:18080/AgileCourtWebStart/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar download=eager main=false/ jar href= http://localhost:18080/AgileCourtWebStart/acs.ui.AgileCourt_0.1.73321606.jar download=eager main=false/ property name=osgi.configuration.area value=@user.home/AgileCourt/configuration/ property name=osgi.instance.area value=@user.home/AgileCourt/workspace/ property name=osgi.bundles value=[EMAIL PROTECTED]:start,[EMAIL PROTECTED]:start,[EMAIL PROTECTED], com.ibm.icu,flute,itext,javax.servlet,js,org.apache.batik.bridge,org.apache.batik.css,org.apache.batik.dom.svg,org.apache.batik.dom, org.apache.batik.ext.awt,org.apache.batik.parser,org.apache.batik.svggen,org.apache.batik.transcoder,org.apache.batik.util.gui, org.apache.batik.util,org.apache.batik.xml,org.apache.commons.codec,org.apache.xerces,org.apache.xml.resolver, org.eclipse.ant.core,org.eclipse.birt.chart.engine.extension,org.eclipse.birt.chart.engine,org.eclipse.birt.chart.reportitem, org.eclipse.birt.core,org.eclipse.birt.data,org.eclipse.birt.report.data.adapter,org.eclipse.birt.report.engine.emitter.html, org.eclipse.birt.report.engine.emitter.pdf,org.eclipse.birt.report.engine.emitter.postscript,org.eclipse.birt.report.engine.emitter.ppt, org.eclipse.birt.report.engine.emitter.prototype.excel,org.eclipse.birt.report.engine.emitter.wpml,org.eclipse.birt.report.engine, org.eclipse.birt.report.model,org.eclipse.core.commands,org.eclipse.core.contenttype,org.eclipse.core.databinding, org.eclipse.core.expressions, org.eclipse.core.filesystem.win32.x86,org.eclipse.core.filesystem,org.eclipse.core.jobs,org.eclipse.core.resources.compatibility, org.eclipse.core.resources.win32,org.eclipse.core.resources,org.eclipse.core.runtime.compatibility.auth, org.eclipse.core.runtime.compatibility,org.eclipse.core.runtime,org.eclipse.core.variables, org.eclipse.datatools.connectivity.oda.consumer,org.eclipse.datatools.connectivity.oda.profile,org.eclipse.datatools.connectivity.oda, org.eclipse.datatools.connectivity,org.eclipse.datatools.enablement.oda.xml, org.eclipse.draw2d,org.eclipse.emf.common,org.eclipse.emf.ecore.xmi,org.eclipse.emf.ecore, org.eclipse.equinox.app,org.eclipse.equinox.common,org.eclipse.equinox.preferences,org.eclipse.equinox.launcher,org.eclipse.equinox.registry, org.eclipse.help,org.eclipse.jface.databinding,org.eclipse.jface, org.eclipse.osgi.services,org.eclipse.osgi,org.eclipse.swt.win32.win32.x86,org.eclipse.swt,org.eclipse.ui.forms,org.eclipse.ui.workbench, org.eclipse.ui,org.eclipse.update.configurator,org.w3c.css.sac,org.w3c.dom.smil,org.w3c.dom.svg/ property name=eclipse.product value=acs.ui.AgileCourt.Client/ /resources application-desc main-class=org.eclipse.core.launcher.WebStartMain.class argument-nosplash/argument /application-desc /jnlp ] at com.sun.javaws.LaunchDownload.getMainClassName(Unknown Source) at com.sun.javaws.Launcher.continueLaunch(Unknown Source) at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source) at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source) at com.sun.javaws.Launcher.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
[equinox-dev]Launcher projects tagged for 6pm build
The map file has been updated for the following Bug changes: + Bug 199020. [launcher] Can't start the AWT while using new eclipse native launcher in 3.3 (NEW) The following projects have changed: org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.executable___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] +1 for Oleg Besedin
+1 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] [vote] graduating the new jar processor bundle
+1 As for doing it now, is there any benefit to waiting? There is some amount of work that will depend on this change. Both update.core and pde.build will need to be updated after this change. As well, the p2.jarprocessor is considered HEAD for bug fixes (there is at least https://bugs.eclipse.org/bugs/show_bug.cgi?id=190064 that should be fixed). and clients would not get these fixes until it is promoted. While there is no particular rush on these changes, it is good to get anything that might block them out of the way. -Andrew Pascal Rapicault/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/10/2007 09:54 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] [vote] graduating the new jar processor bundle In the long, there is no discussion about doing this change. However the benefits of doing it right away are not clear to me. +0 PaScaL From: Jeff McAffer/Ottawa/[EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 09/09/2007 11:07 PM Subject:[equinox-dev] [vote] graduating the new jar processor bundle As you may know, we used to have the JARProcessor embedded in the bowels of Update manager. Turns out that there are several uses for the processor (pack200 support, signing, verifying, ...) and having this function as a stand-alone bundle would be a good thing(tm). So in the p2 work we did just that and created org.eclipse.equinox.p2.jarprocessor. Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=198564 talks about updating update to use the new processor. Of course, the current JarProcessor bundle is in the Equinox Incubator. To date I think we have avoided cases where we build the mainstream SDK based on content from an incubator. We have two choices, we can wait to move Update over or we can graduate the current JARProcessor bundle. Here I popose the latter since the code in the bundle is unchanged from the original that shipped in 3.3. All we are doing is putting it in a separate bundle. The only thing at issue is the shape of the API and that can evolve until the API freeze just as any other bundle in HEAD. So consider this a formal call for voting on graduating the org.eclipse.equinox.p2.jarprocessor bundle. +1 from me. 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
