Re: [equinox-dev] Prosyst contributions
> Hi Simon, > > I can commit the sources in the CVS. Here are the open issues > that should be resolved prior moving code to the CVS. > > 1. Naming. > Following the discussion the last proposed naming is: > 1.1 org.eclipse.equionx.initialprovisioning > other suggestion: org.eclipse.equionx.ip +1 for org.eclipse.equinox.initialprovisioning I think this name will reduce an confusion with the rest of the equinox provisioning work. > 1.2 org.eclipse.equionx.ds > other suggestion: org.eclipse.equionx.scr +1 for org.eclipse.equinox.scr > 1.3 org.eclipse.equinox.io > 1.4 org.eclipse.equinox.util > 1.5 org.eclipse.equinox.wireadmin > > 2. Replacing. If we use the names org.eclipse.equinox.wireadmin and > org.eclipse.equionx.ds they collide with the current one. Can we replace > the code in the CVS at this stage directly or temporary other names > will be used? There is no problem replacing the current implementations in the incubator. To be clear this is under the equinox-incubator directory at dev.eclipse.org:/cvsroot/eclipse. At this point I suggest we get the initial code released in the incubator. It is likely that a number of refactorings are going be needed to follow other eclipse coding practices (i.e. using "internal" package names etc.). I'm not fussed on getting all the names correct initially. We can easily rename them if needed in the incubator. > > 3. javax.microedition.io package > Now it is in Connector services implementation. This is not a good > choice because it is needed only on Java SE VMs. J2ME VMs > contains that package. In our equinox distribution it is a fragment of > the system bundle that is installed only on Java SE VMs. > But initially we can put it inside the connector implementation. > > -Pavlin > I think we should consider separating this out into another bundle and import the packages from org.eclipse.equinox.io (but we can do this later). I'm not sure why it has to be a system bundle fragment. I think we should make it a normal bundle (called javax.microedition.io?). Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Importing of javax packages
I agree, but we will need to import javax.microedition.io as optional and dynamic the same way javax.servlet packages are imported in org.eclipse.osgi.services. This allows for late binding of the javax.microedition.io package if it is installed later. Tom Pavlin Dobrev <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/06/2007 04:46 AM Please respond to Pavlin Dobrev <[EMAIL PROTECTED]>; Please respond to Equinox development mailing list To Equinox development mailing list cc Subject [equinox-dev] Importing of javax packages Hi all, I do some testing with OSGi test cases on equinox ( org.osgi.test.cases.signature.cpeg.jar and org.osgi.test.cases.signature.mobile.jar) and found that currently they are some missing imports: 1. org.eclipse.osgi.util does'nt import javax.xml.parsers used from org.osgi.util.xml.XMLParserActivator 2. org.eclipse.osgi.services does'nt import javax.microedition.io used from ConnectionFactory and ConnectorService in org.osgi.service.io package There is no problem test cases to pass if org.osgi.framework.bootdelegation=* ( see http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.isv/porting/3.3/incompatibilities.html ). According to the section 3.8.3 Parent Delegation from OSGi Service Platform Core Specification Release 4, Version 4.1 "The Framework must always delegate any package that starts with java. to the parent class loader.". My personal opinion is that required import must be added to the corresponding bundles. What do you think? -Pavlin - Pavlin Dobrev · Research and Development Manager ProSyst Labs EOOD 1606 Sofia, Bulgaria · 48 Vladajska Str. Tel. (+359 2) 954 91 62 . Fax. (+359 2) 953 26 17 http://www.prosyst.com · [EMAIL PROTECTED] - stay in touch with your product. - ___ 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] Prosyst contributions
OK, I'm not particular about the names right now. Since we already have a DS bundle lets just use org.eclipse.equinox.ds for declarative services. I also like org.eclipse.equinox.ip for initial provisioning but thought it might be to short :) but it is snappy. Pavlin, if these are ok with you please release with the names org.eclipse.equinox.ds and org.eclipse.equinox.ip. As I said before it is no big deal to rename the bundles if needed in the incubator later. Tom Chris Aniszczyk/Austin/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/05/2007 09:34 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] Prosyst contributions as an outsider, +1 for DS instead of SCR, there's like 5 people that would get the SCR reference :) initialprovisioning is really long Cheers, --- Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.blogspot.com | +1.860.839.2465 Jeff McAffer ---07/05/2007 09:13:02 PM---I agree with all/most Tom said. In the end we should look to have just one DS implementation, Ultimately I suggest that it be From: Jeff McAffer <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 07/05/2007 09:13 PM Subject: Re: [equinox-dev] Prosyst contributions I agree with all/most Tom said. In the end we should look to have just one DS implementation, Ultimately I suggest that it be called o.e.e.ds. Never did like "scr". I'm a little bummed by o.e.e.initialprovisioning. o.e.e.ip is snappier and I doubt that anyone would get confused with Intelectual property, or Internet Protocol or, ... In any event, it is a mild dislike so... Lets get the code in the incubator and move forward. Jeff Thomas Watson <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/05/2007 03:51 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] Prosyst contributions > Hi Simon, > > I can commit the sources in the CVS. Here are the open issues > that should be resolved prior moving code to the CVS. > > 1. Naming. > Following the discussion the last proposed naming is: > 1.1 org.eclipse.equionx.initialprovisioning > other suggestion: org.eclipse.equionx.ip +1 for org.eclipse.equinox.initialprovisioning I think this name will reduce an confusion with the rest of the equinox provisioning work. > 1.2 org.eclipse.equionx.ds > other suggestion: org.eclipse.equionx.scr +1 for org.eclipse.equinox.scr > 1.3 org.eclipse.equinox.io > 1.4 org.eclipse.equinox.util > 1.5 org.eclipse.equinox.wireadmin > > 2. Replacing. If we use the names org.eclipse.equinox.wireadmin and > org.eclipse.equionx.ds they collide with the current one. Can we replace > the code in the CVS at this stage directly or temporary other names > will be used? There is no problem replacing the current implementations in the incubator. To be clear this is under the equinox-incubator directory at dev.eclipse.org:/cvsroot/eclipse. At this point I suggest we get the initial code released in the incubator. It is likely that a number of refactorings are going be needed to follow other eclipse coding practices (i.e. using "internal" package names etc.). I'm not fussed on getting all the names correct initially. We can easily rename them if needed in the incubator. > > 3. javax.microedition.io package > Now it is in Connector services implementation. This is not a good > choice because it is needed only on Java SE VMs. J2ME VMs > contains that package. In our equinox distribution it is a fragment of > the system bundle that is installed only on Java SE VMs. > But initially we can put it inside the connector implementation. > > -Pavlin > I think we should consider separating this out into another bundle and import the packages from org.eclipse.equinox.io (but we can do this later). I'm not sure why it has to be a system bundle fragment. I think we should make it a normal bundle (called javax.microedition.io?). Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org 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 projects tagged for 3.4 I-build
Note that the bugs in the ASSIGNED state are still open for 3.3.1 consideration. Also note that the native launchers did not get recompiled so fixes related to the native exes and libraries will not be included. The map file has been updated for the following Bug changes: + Bug 178028. [registry] ExtensionTracker removal notification w/out associated Objects? (FIXED) + Bug 185977. InvalidRegistryObjectException thrown when refreshingPackages (ASSIGNED) + Bug 189013. The Signed bundle does not handle additional BundleFileWrapperFactoryHooks (ASSIGNED) + Bug 190399. console command line parsing problem (ASSIGNED) + Bug 191597. [launcher] launcher no longer brings up an exit dialog on Windows (ASSIGNED) + Bug 191652. Native code is not updated during bundle update (ASSIGNED) + Bug 192454. [server] http.jetty's SSL support for "needclientauth" and "wantclientauth" cause ClassCastExceptions (ASSIGNED) + Bug 192722. [resolver] BundleDescription order may effect singleton selection (ASSIGNED) + Bug 193201. Malformed Bundle-Classpath can result in an NPE in AbstractBundle (FIXED) + Bug 193340. Mem access violation if specify -Xmx without -Xms for Eclipse 3.3rc4 (ASSIGNED) + Bug 194261. [launcher] eclipse/jre vm not used if library not found (ASSIGNED) + Bug 195240. Possible bug in resolving dynamic imports (FIXED) + Bug 195566. ContextFinder.loadClass should not by synchronous (ASSIGNED) + Bug 195809. eclipse_1017a.dll blocks heap sizes greater 1GB (FIXED) + Bug 195811. Compile own launcher with own resources (FIXED) The following projects have changed: org.eclipse.equinox.http.jetty org.eclipse.equinox.executable org.eclipse.osgi.tests org.eclipse.equinox.registry org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Re: [platform-releng-dev] [eclipse-build]Build I20070710-0800 (Timestamp: 200707100800):updated map file listing
The Equinox team has contributed native launcher for the rebuild. The map file has been updated and we are ready for the rebuild. The following projects have changed: org.eclipse.equinox.launcher.gtk.linux.x86 org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.executable org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.launcher org.eclipse.equinox.launcher.motif.linux.x86 Tom Kim Moir <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/10/2007 08:37 AM Please respond to "Eclipse platform release engineering list." <[EMAIL PROTECTED]> To "Eclipse platform release engineering list." <[EMAIL PROTECTED]> cc Subject Re: [platform-releng-dev] [eclipse-build]BuildI20070710-0800 (Timestamp: 200707100800):updated map file listing A rebuild has been scheduled for noon in case any other teams want to recontribute. Kim Olivier Thomann/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/10/2007 08:24 AM Please respond to "Eclipse platform release engineering list." <[EMAIL PROTECTED]> To "Eclipse platform release engineering list." <[EMAIL PROTECTED]> cc Subject Re: [platform-releng-dev] [eclipse-build]BuildI20070710-0800 (Timestamp: 200707100800):updated map file listing Hi, The build will fail since the apt map has not been updated. I have done it now and a rebuild can be restarted at any time. Sorry for the inconvenience, Olivier [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 2007-07-10 08:05 Please respond to "Eclipse platform release engineering list." <[EMAIL PROTECTED]> To [EMAIL PROTECTED] cc Subject [platform-releng-dev] [eclipse-build]Build I20070710-0800 (Timestamp: 200707100800):updated map file listing Build I20070710-0800 (Timestamp: 200707100800): these map files have been updated for the build: compare.map core.map doc.map feature.map jdtcore.map jdtdebug.map jdtui.map orbit.map pde.map swt.map team.map text.map update.map userassist.map ___ platform-releng-dev mailing list [EMAIL PROTECTED] https://dev.eclipse.org/mailman/listinfo/platform-releng-dev ___ platform-releng-dev mailing list [EMAIL PROTECTED] https://dev.eclipse.org/mailman/listinfo/platform-releng-dev ___ platform-releng-dev mailing list [EMAIL PROTECTED] https://dev.eclipse.org/mailman/listinfo/platform-releng-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Initial Provisioning name and how it relates to Equinox Provisioning
bundle lets just use org.eclipse.equinox.ds for > > > >> > > > declarative services. > > > >> > > > > > > >> > > > I also like org.eclipse.equinox.ip for initial provisioning > but > > > >> > > > thought it might be to short :) but it is snappy. > > > >> > > > > > > >> > > > Pavlin, if these are ok with you please release with the > names > > org. > > > >> > > > eclipse.equinox.ds and org.eclipse.equinox.ip. As I said > > before it > > > >> > > > is no big deal to rename the bundles if needed in the > incubator > > later. > > > >> > > > > > > >> > > > Tom > > > >> > > > > > > >> > > > Chris Aniszczyk/Austin/[EMAIL PROTECTED] > > > >> > > > Sent by: [EMAIL PROTECTED] > > > >> > > > 07/05/2007 09:34 PM > > > >> > > > > > > >> > > > Please respond to > > > >> > > > Equinox development mailing list > > > >> > > > > > > >> > > > To > > > >> > > > > > > >> > > > Equinox development mailing list > > > >> > > > > > > >> > > > cc > > > >> > > > > > > >> > > > Subject > > > >> > > > > > > >> > > > Re: [equinox-dev] Prosyst contributions > > > >> > > > > > > >> > > > as an outsider, +1 for DS instead of SCR, there's like 5 > people > > that > > > >> > > > would get the SCR reference :) > > > >> > > > > > > >> > > > initialprovisioning is really long > > > >> > > > > > > >> > > > Cheers, > > > >> > > > > > > >> > > > --- > > > >> > > > Chris Aniszczyk | IBM Lotus | Eclipse Committer | > > http://mea-bloga. > > > >> > > > blogspot.com | +1.860.839.2465 > > > >> > > > > > > >> > > > [image removed] Jeff McAffer ---07/05/2007 09:13:02 PM---I > > agree > > > >> > > > with all/most Tom said. In the end we should look to have > just > > one > > > >> > > > DS implementation, Ultimately I suggest that it be > > > >> > > > > > > >> > > > [image removed] > > > >> > > > From: > > > >> > > > > > > >> > > > [image removed] > > > >> > > > Jeff McAffer <[EMAIL PROTECTED]> > > > >> > > > > > > >> > > > [image removed] > > > >> > > > To: > > > >> > > > > > > >> > > > [image removed] > > > >> > > > Equinox development mailing list > > > >> > > > > > > >> > > > [image removed] > > > >> > > > Date: > > > >> > > > > > > >> > > > [image removed] > > > >> > > > 07/05/2007 09:13 PM > > > >> > > > > > > >> > > > [image removed] > > > >> > > > Subject: > > > >> > > > > > > >> > > > [image removed] > > > >> > > > Re: [equinox-dev] Prosyst contributions > > > >> > > > > > > >> > > > I agree with all/most Tom said. In the end we should look to > > have > > > >> > > > just one DS implementation, Ultimately I suggest that it be > > called > > > >> > > > o.e.e.ds. Never did like "scr". I'm a little bummed by o.e.e. > > > >> > > > initialprovisioning. o.e.e.ip is snappier and I doubt that > > anyone > > > >> > > > would get confused with Intelectual property, or Internet > > Protocol > > > >> > > > or, ... In any event, it is a mild dislike so... > > > >> > > > > > > >> > > > Lets get the code in the incubator and move forward. > > > >> > > > > > > >> > > > Jeff > > > >> > > > > > > >> > &g
[equinox-dev] What to do with 3.3.1 candidate bugs and milestones
Each major release the same thing happens. We start fixing bugs in HEAD for the next major release but find a few fixes that we would like to also release into a maintenance release. Then we have to decide what to do with the status of the original bug report which was used to release the fix into HEAD. I have seen this handled in two ways. 1) Leave the bug open and mark the milestone to the next maintenance release milestone (e.g. 3.3.1) and make a comment in the bug report stating the fix was released to HEAD. If/When the fix gets approved and released for the maintenance release then the bug is marked as fixed; otherwise we make a note that the fix is not going to be included in the maintenance release and the milestone is updated to major milestone the fix was included and marked as fixed. 2) Resolve the bug report and mark the milestone appropriate for the next major release (e.g. 3.4 M1) and open a separate bug with a proper milestone for the maintenance release (e.g. 3.3.1). For the past couple of releases the Equinox team has used option #1 but this has a few drawbacks. First of all, it gives inaccurate search results when querying bugzilla for the list of bug fixes for the next release milestone because code was released into the milestone but the bug is left open and marked for a maintenance stream. Also I find it generally confusing that the bug status does not reflect the fixed state of the bug until we can get approval and actually release the bug into the maintenance stream. The second approach has its advantages because it accurately reflects the state of the bug for a particular stream and makes for more accurate search results for fixed bugs and milestones. But there is a risk that the open bug against the maintenance stream will not get approved for release and then we would have to resolve the bug as wontfix (or something). I'm not sure that is really a problem because at least the reason why the fix is not in the maintenance stream is recorded. Another disadvantage is that the bugs will look like duplicates which could cause confusion. What are other committers preferences? How is this handled on other teams? Is there a standard Eclipse way to handle this? Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones
No we have not done #2 in the past releases. Searching through 3.2.x bugs for Platform and Equinox you will notice that most (all?) teams seem to have done #1 for the 3.2.x releases. https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Eclipse&product=Equinox&product=Platform&target_milestone=3.2.1&target_milestone=3.2.2&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Tom Jeff McAffer <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/12/2007 09:19 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones i thought we were all already doing #2... Jeff Thomas Watson <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/11/2007 01:42 PM Please respond to Equinox development mailing list To equinox-dev@eclipse.org cc Subject [equinox-dev] What to do with 3.3.1 candidate bugs and milestones Each major release the same thing happens. We start fixing bugs in HEAD for the next major release but find a few fixes that we would like to also release into a maintenance release. Then we have to decide what to do with the status of the original bug report which was used to release the fix into HEAD. I have seen this handled in two ways. 1) Leave the bug open and mark the milestone to the next maintenance release milestone (e.g. 3.3.1) and make a comment in the bug report stating the fix was released to HEAD. If/When the fix gets approved and released for the maintenance release then the bug is marked as fixed; otherwise we make a note that the fix is not going to be included in the maintenance release and the milestone is updated to major milestone the fix was included and marked as fixed. 2) Resolve the bug report and mark the milestone appropriate for the next major release (e.g. 3.4 M1) and open a separate bug with a proper milestone for the maintenance release (e.g. 3.3.1). For the past couple of releases the Equinox team has used option #1 but this has a few drawbacks. First of all, it gives inaccurate search results when querying bugzilla for the list of bug fixes for the next release milestone because code was released into the milestone but the bug is left open and marked for a maintenance stream. Also I find it generally confusing that the bug status does not reflect the fixed state of the bug until we can get approval and actually release the bug into the maintenance stream. The second approach has its advantages because it accurately reflects the state of the bug for a particular stream and makes for more accurate search results for fixed bugs and milestones. But there is a risk that the open bug against the maintenance stream will not get approved for release and then we would have to resolve the bug as wontfix (or something). I'm not sure that is really a problem because at least the reason why the fix is not in the maintenance stream is recorded. Another disadvantage is that the bugs will look like duplicates which could cause confusion. What are other committers preferences? How is this handled on other teams? Is there a standard Eclipse way to handle this? Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones
We will bring this topic up for discussion at next week's architecture call. Personally I want to use option #2 but if we are the only team doing this then it will look pretty inconsistent with the rest of the eclipse teams. Tom BJ Hargrave/Austin/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/13/2007 10:49 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones So far, the respondents want #2. Tom was just observing that #1 has been the case in the past. Given that (a) bugzilla does not support multiple releases within a single bug (see CMVC tracks) and (b) bugzilla does have a quick and easy "Clone This Bug" link, #2 is the most practical and obvious choice. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 Jeff McAffer <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2007-07-13 11:18 Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones ok. in theory I support #2 but if everyone else is doing #1 then there may be more merit in consistency. there is some logic that says things released in 3.n.x will alos be in 3.n+1.x but that is not always true. The issue may come down to overhead in managing the bugs/process. Jeff Thomas Watson <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/13/2007 08:59 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones No we have not done #2 in the past releases. Searching through 3.2.x bugs for Platform and Equinox you will notice that most (all?) teams seem to have done #1 for the 3.2.x releases. https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Eclipse&product=Equinox&product=Platform&target_milestone=3.2.1&target_milestone=3.2.2&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Tom Jeff McAffer <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/12/2007 09:19 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones i thought we were all already doing #2... Jeff Thomas Watson <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/11/2007 01:42 PM Please respond to Equinox development mailing list To equinox-dev@eclipse.org cc Subject [equinox-dev] What to do with 3.3.1 candidate bugs and milestones Each major release the same thing happens. We start fixing bugs in HEAD for the next major release but find a few fixes that we would like to also release into a maintenance release. Then we have to decide what to do with the status of the original bug report which was used to release the fix into HEAD. I have seen this handled in two ways. 1) Leave the bug open and mark the milestone to the next maintenance release milestone (e.g. 3.3.1) and make a comment in the bug report stating the fix was released to HEAD. If/When the fix gets approved and released for the maintenance release then the bug is marked as fixed; otherwise we make a note that the fix is not going to be included in the maintenance release and the milestone is updated to major milestone the fix was included and marked as fixed. 2) Resolve the bug report and mark the milestone appropriate for the next major release (e.g. 3.4 M1) and open a separate bug with a proper milestone for the maintenance release (e.g. 3.3.1). For the past couple of releases the Equinox team has used option #1 but this has a few drawbacks. First of all, it gives inaccurate search results when querying bugzilla for the list of bug fixes for the next release milestone because code was released into the milestone but the bug is left open and marked for a maintenance stream. Also I find it generally confusing that the bug status does not reflect the fixed state of the bug until we can get approval and actually release the bug into the maintenance stream. The second approach has its advantages because it accurately reflects the state of the bug for
Re: [equinox-dev] AOSGi for Eclipse 3.3
I am not aware of any changes to the framework that would prevent AOSGi from working on 3.3. Matthew or Martin have you tested 3.3 with AOSGi yet? Tom "Oren Mishali" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/17/2007 07:47 AM Please respond to Equinox development mailing list To "'Equinox development mailing list'" cc Subject [equinox-dev] AOSGi for Eclipse 3.3 Hi, I am currently using AOSGi with Eclipse 3.2.*. Is it compatible with Eclipse 3.3.*? If not, when will it be available? Thanks, Oren___ 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 projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 95052. [prefs] does not catch up with external property removal (FIXED) + Bug 188091. [WorkbenchLauncher] org.eclipse.swt.SWTError: No more handles when RCP starts (FIXED) + Bug 189153. Improve error message when .SF file has been tampered with (FIXED) + Bug 193596. [app] Starting a non main-thread application causes an exception (FIXED) + Bug 194943. Europa Crashes During Startup (ASSIGNED) + Bug 196871. Make LocationManager.canWrite(...) a utility method (FIXED) + Bug 196889. [launcher] Eclipse 3.3 System bundle not OSGi/Minimum-1.1 compliant. (FIXED) + Bug 197173. console fails if passed a set of initial commands (FIXED) The following projects have changed: org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.launcher.gtk.linux.x86 org.eclipse.equinox.app org.eclipse.equinox.launcher org.eclipse.equinox.preferences org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.osgi org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.launcher.motif.hpux.PA_RISC org.eclipse.equinox.launcher.motif.linux.x86 Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] No available bundle exports package 'javax.swing.event'
Where do you see the error? In the java code file where you import the javax.swing.event package or in your bundle MANIFEST.MF file where you use Import-Package: javax.swing.event? This package should be exported by the system bundle (org.eclipse.osgi in equinox) when running on a J2SE-1.2 or higher VM. Tom David Leangen <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/24/2007 04:36 AM Please respond to [EMAIL PROTECTED]; Please respond to Equinox development mailing list To Equinox development mailing list cc Subject [equinox-dev] No available bundle exports package 'javax.swing.event' Hello! I am getting a bunch of errors in Eclipse like the one above. I thought that javax packages were supposed to be "automatically" imported by the framework... Is there some setting I need to set in Eclipse? Thanks! David ___ 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] No available bundle exports package 'javax.swing.event'
Please open a bug against PDE->UI and give steps to reproduce. Thanks. Tom David Leangen <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/25/2007 01:47 AM Please respond to [EMAIL PROTECTED]; Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] No available bundle exports package 'javax.swing.event' > What OS are you using? Linux > Have you configured access rules for any of the JREs in the workspace? No > And is your project dependent on a specifically installed JRE or an > OSGi execution environment? I'm using the system JRE, v 1.5.0_06. I am using a "target platform", if that's what you mean... In my target platform, I'm using org.eclipse.osgi (3.3.0v20070530). Cheers, Dave ___ 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 projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 181327. eclipse/osgi hangs using 50% CPU during some osgi operations (ASSIGNED) + Bug 192454. [server] http.jetty's SSL support for "needclientauth" and "wantclientauth" cause ClassCastExceptions (FIXED) + Bug 193617. IExtensionRegistry API request for 'removeContributor' (FIXED) + Bug 193857. [server] Use of file extension wildcards doesn't work correctly with Resources (FIXED) + Bug 195384. [launcher] Memory violation in Launcher when -vm is incorrect (FIXED) + Bug 196071. Can't stop/start apps which have a common prefix with another app (FIXED) + Bug 196497. [server] JettyConfigurator constants for supported settings (FIXED) + Bug 196883. [launcher] create eclipse launcher for Windows on x86_64 (FIXED) + Bug 197009. [server] JSPContextFinder.loadClass should not by synchronous (FIXED) + Bug 197013. [server] console command line parsing problem in FrameworkLauncher (FIXED) + Bug 197191. timestamp are not persisted correctly (FIXED) + Bug 197385. [launcher] free called twice on exitData if default error dialog is displayed (FIXED) + Bug 197811. PKCS7Processor needs to implement hashCode (FIXED) + Bug 198087. org.eclipse.equinox.internal.app.Activator contains unref. frameworkLog field (FIXED) + Bug 198130. org.eclipse.equinox.app Activator has potential threading issues (FIXED) The following projects have changed: org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.app org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.equinox.http.jetty org.eclipse.osgi org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.http.servlet org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.launcher org.eclipse.core.tests.runtime org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.executable org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.registry org.eclipse.equinox.servletbridge org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.launcher.gtk.linux.x86 org.eclipse.equinox.jsp.jasper Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for 3.4 M1 build
The map file has been updated for the following Bug changes: + Bug 181881. Unfortunate Console CommandProvider Help Formatting (FIXED) + Bug 189794. sytem bundle fragments cannot supply manifest localization (FIXED) + Bug 193802. BaseStorage adds invalid URL to a URLClassLoader (FIXED) + Bug 198405. NPE if EventManager is created with null thread name (FIXED) + Bug 198459. [Registry] Enhancement request to make hasContributor() API (FIXED) + Bug 198535. HostSpecification#getHosts() returns null (FIXED) The following projects have changed: org.eclipse.equinox.launcher.motif.hpux.PA_RISC org.eclipse.equinox.launcher org.eclipse.equinox.registry 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] Equinox projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 184283. Remove ServiceFactory code for StartLevel implementation (FIXED) + Bug 185952. EnviromentInfo defaults ws to motif on solaris and linux (FIXED) + Bug 187203. Define value for osgi.os for Symbian OS (Epoc32) (FIXED) + Bug 187237. Request for defining value for osgi.ws property for Symbian S60 platform + Bug 188089. [osgi] can't launch an osgi bundle if the path of its plugin project contains the caracter "@" (ASSIGNED) + Bug 195073. [Preferences] Some preferences are not crash safe (FIXED) + Bug 199606. getprop console command does not sort output (FIXED) + Bug 199634. IndexOutOfBoundsException during bundle resolution (ASSIGNED) + Bug 200202. Malformed javadoc tags (FIXED) + Bug 200211. Malformed javadoc tags (FIXED) + Bug 200296. [NLS] NLS.bind crashed with NegativeArraySizeException when given empty format string and short parameter (FIXED) The following projects have changed: org.eclipse.equinox.launcher org.eclipse.equinox.registry org.eclipse.equinox.preferences org.eclipse.equinox.supplement org.eclipse.equinox.common org.eclipse.equinox.app org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox coding conventions
I updated the following equinox projects to have the latest Equinox code convention settings. I also updated each project to format java files when saving. You may notice additional changes when saving java files and creating patches. In this case the code was probably not correctly formatted. org.eclipse.equinox.app org.eclipse.equinox.common org.eclipse.equinox.device org.eclipse.equinox.event org.eclipse.equinox.http org.eclipse.equinox.http.jetty org.eclipse.equinox.http.registry org.eclipse.equinox.http.servlet org.eclipse.equinox.http.servletbridge org.eclipse.equinox.jsp.jasper org.eclipse.equinox.jsp.jasper.registry org.eclipse.equinox.launcher org.eclipse.equinox.log org.eclipse.equinox.metatype org.eclipse.equinox.preferences org.eclipse.equinox.registry org.eclipse.equinox.servletbridge org.eclipse.equinox.supplement org.eclipse.equinox.useradmin org.eclipse.osgi Because of bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=200207 the org.eclipse.osgi project cannot set the "Malformed Javadoc" compiler settings to "Error". All other projects do have this set to "Error". Tom John Arthorne <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/20/2007 04:35 PM Please respond to Equinox development mailing list To equinox-dev@eclipse.org cc Subject [equinox-dev] Equinox coding conventions As more and more people are contributing to Equinox (Thanks!) we thought it would make sense to point out the Equinox coding conventions: http://www.eclipse.org/equinox/documents/coding.php In some ways these sort of guidelines can show up as restricting one's freedom of artistic code formatting or variable naming expression. In practice however, having a common set of coding practices is one of the ingredients of our success. We have a large and growing body of committers in Equinox, and a much larger community looking in and trying to understand what we write. Having common and consistent conventions makes our code easier to read and work with for everyone. In particular, check out the section around formatter and compiler settings. These we should setup in each project so that everyone is seeing the same errors and formatting the same way. We're also going to experiment with enabling automatic formatting and code cleanup on save, so we can just forget about these issues and let the tools do the work. ___ 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] Starting Eclipse platform with java webstart
What errors if any do you see? Is it a ClassCastException? We are currently investigating a webstart issue on 3.3 see https://bugs.eclipse.org/bugs/show_bug.cgi?id=198462. This bug may be causing you trouble. Tom "CHEMALY Zahi" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/23/2007 02:48 AM Please respond to Equinox development mailing list To cc Subject [equinox-dev] Starting Eclipse platform with java webstart Hi, Sorry for the mass mail, but i was trying to start the platform from a java webstart. And I still didn?t manage it to work! Could Eclipse 3.3 be started from a java webstart? (it is not the simple case of a simple RCP, but the whole platform) Has it been done before? In the jnlp example file provided in the help I have to specify an eclipse.product property value to run. I?ve tried unsuccessfully the different ones found in the osgi bundle. What did I miss? Should I create a new separate product project in eclipse and make it call the main class in osgi plugin to start it? Thanks a lot, Zahi *** This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorised to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system. ___ 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] getResources : bundleresource
I'm a bit confused by the usecase. Are these real bundles or just inner
jars which you use as inner libraries? If they are real bundles then why
don't you install them as real bundles instead?
The bundleresource protocol uses the port as an index into the list of
resources of a given name (e.g plugin.xml). In your case it sounds like
you have more resources named META-INF/MANIFEST.MF in your bundle than you
do plugin.xml so the two lists and indexes do not match up. For example,
imagine you have a bundle which has jars A, B, C, D which all have
META-INF/MANIFEST.MF resources but only C and D have plugin.xml. A call
to classloader.getResources("plugin.xml") gives you something like this:
bundleresource://26:0/plugin.xml (C)
bundleresource://26:1/plugin.xml (D)
A call to classloader.getResources("META-INF/MANIFEST.MF") gives you
something like this:
bundleresource://26:0/META-INF/MANIFEST.MF (base bundle)
bundleresource://26:1/META-INF/MANIFEST.MF (A)
bundleresource://26:2/META-INF/MANIFEST.MF (B)
bundleresource://26:3/META-INF/MANIFEST.MF (C)
bundleresource://26:4/META-INF/MANIFEST.MF (D)
As you can see the resource indexes will not match for the two different
resources (plugin.xml and METE-INF/MANIFEST.MF) from C and D.
Tom
Erik Bengtson <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
08/27/2007 01:58 PM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
[equinox-dev] getResources : bundleresource
Hi,
I have some bundles (B,C,D) that are not deployed as osgi bundles, but as
libraries within a bundle (A).
In bundle A, I have a custom internal registry of the plugin.xml from
files
(B,C,D).
1) find and load all plugin.xml files using classloader.getResources()
I get an enumeration of:
bundleresource://26:3/plugin.xml (D)
bundleresource://26:2/plugin.xml (C)
bundleresource://26:1/plugin.xml (B)
So far so good, but now I have to load the corresponding
/META-INF/MANIFEST.MF
files from each bundle (B,C,D).
2) do: -- new URL("bundleresource://26:3/META-INF/MANIFEST.MF");
My problem is that it returns the MANIFEST.MF from bundle (C), instead of
bundle
(D).
What am I doing wrong?
Background: My project JPOX, a JDO/JPA implementation, is OSGi compatible
and
uses Eclipse Extension/Extension Points for declarative services. I have
an
internal registry of bundles/extension/extension points when running
outside an
osgi container.
Regards,
Erik Bengtson
http://jpox.org
___
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] getResources : bundleresource
Erik,
Either of your options should work. I prefer option 1 though :)
Can you open a bug against Equinox->Framework and record your usecase in
the bug report. We may need to consider using the port to indicate a
classpath entry in the bundle instead of an entry into the list of
duplicate resources. I think the OSGi spec is also vague in the area of
bundle resource URLs. We may need to go back to OSGi and ask for
clarification. Thanks.
Tom
Erik Bengtson <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
08/27/2007 05:08 PM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev] getResources : bundleresource
Thomas,
You got my use case, and answered very well :). my bundles are deployed as
inner
libraries.
Two options I know to solve my issue:
1) use bundles as real bundles :)
2) use FileLocator.resolve() to resolve the URL and load MANIFEST.MF files
from
there.
If you have more options, I would appreciate.
Thanks,
Erik Bengtson
Quoting Thomas Watson <[EMAIL PROTECTED]>:
> I'm a bit confused by the usecase. Are these real bundles or just inner
> jars which you use as inner libraries? If they are real bundles then
why
> don't you install them as real bundles instead?
>
> The bundleresource protocol uses the port as an index into the list of
> resources of a given name (e.g plugin.xml). In your case it sounds like
> you have more resources named META-INF/MANIFEST.MF in your bundle than
you
> do plugin.xml so the two lists and indexes do not match up. For
example,
> imagine you have a bundle which has jars A, B, C, D which all have
> META-INF/MANIFEST.MF resources but only C and D have plugin.xml. A call
> to classloader.getResources("plugin.xml") gives you something like this:
>
> bundleresource://26:0/plugin.xml (C)
> bundleresource://26:1/plugin.xml (D)
>
> A call to classloader.getResources("META-INF/MANIFEST.MF") gives you
> something like this:
>
> bundleresource://26:0/META-INF/MANIFEST.MF (base bundle)
> bundleresource://26:1/META-INF/MANIFEST.MF (A)
> bundleresource://26:2/META-INF/MANIFEST.MF (B)
> bundleresource://26:3/META-INF/MANIFEST.MF (C)
> bundleresource://26:4/META-INF/MANIFEST.MF (D)
>
> As you can see the resource indexes will not match for the two different
> resources (plugin.xml and METE-INF/MANIFEST.MF) from C and D.
>
> Tom
>
>
>
>
> Erik Bengtson <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 08/27/2007 01:58 PM
> Please respond to
> Equinox development mailing list
>
>
> To
> Equinox development mailing list
> cc
>
> Subject
> [equinox-dev] getResources : bundleresource
>
>
>
>
>
>
> Hi,
>
> I have some bundles (B,C,D) that are not deployed as osgi bundles, but
as
> libraries within a bundle (A).
>
> In bundle A, I have a custom internal registry of the plugin.xml from
> files
> (B,C,D).
>
> 1) find and load all plugin.xml files using classloader.getResources()
>
> I get an enumeration of:
>
> bundleresource://26:3/plugin.xml (D)
> bundleresource://26:2/plugin.xml (C)
> bundleresource://26:1/plugin.xml (B)
>
> So far so good, but now I have to load the corresponding
> /META-INF/MANIFEST.MF
> files from each bundle (B,C,D).
>
> 2) do: -- new URL("bundleresource://26:3/META-INF/MANIFEST.MF");
>
> My problem is that it returns the MANIFEST.MF from bundle (C), instead
of
> bundle
> (D).
>
> What am I doing wrong?
>
> Background: My project JPOX, a JDO/JPA implementation, is OSGi
compatible
> and
> uses Eclipse Extension/Extension Points for declarative services. I have
> an
> internal registry of bundles/extension/extension points when running
> outside an
> osgi container.
>
> Regards,
>
> Erik Bengtson
> http://jpox.org
> ___
> 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] Equinox projects tagged for 3.4 I-build
Along with the following bug fixes I updated every equinox project in the SDK with the new code formatter settings for Equinox. That is why so many projects have changed this build. The map file has been updated for the following Bug changes: + Bug 127963. ContextFinder caches classes from Class#forName (FIXED) + Bug 177007. Classes in boot classloader are not properly loaded for some Eclipse plugins (FIXED) + Bug 198423. [launcher] failed to load x86_64 library on win32.x86 when self-hosting (FIXED) + Bug 198447. FileLocator needs a helper method to get the location of a bundle (FIXED) + Bug 198525. HashCode problem in org.eclipse.osgi.framework.internal.core.BundleResourceHandler (FIXED) + Bug 198823. [launcher] eclipse.ini is not portable (NEW) + Bug 200231. [app] Support creating app container without app launcher (ASSIGNED) + Bug 200296. [NLS] NLS.bind crashed with NegativeArraySizeException when given empty format string and short parameter (FIXED) + Bug 200582. [Launcher] Shared Memory Leak (FIXED) + Bug 200596. Eclipse launcher (erroneously) fails to find its companion shared library when using relative directory with a forward slash and launch directory is in your PATH (on Windows) (NEW) + Bug 200604. [Launcher] Allow relative path for --launcher.library (FIXED) + Bug 200950. [launcher] Bad memory reference after failed shared memory (FIXED) + Bug 201255. NullPointerException occurs if a fragment attaches to an uninstalled bundle (FIXED) The following projects have changed: org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.app org.eclipse.equinox.http.jetty org.eclipse.osgi.tests org.eclipse.equinox.http org.eclipse.osgi org.eclipse.equinox.metatype org.eclipse.equinox.launcher org.eclipse.equinox.log org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.jsp.jasper.registry org.eclipse.equinox.registry org.eclipse.equinox.servletbridge org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.device org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.http.servletbridge org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.http.registry org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.http.servlet org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.executable org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.preferences org.eclipse.equinox.useradmin org.eclipse.equinox.supplement org.eclipse.equinox.common org.eclipse.equinox.launcher.gtk.linux.x86 org.eclipse.equinox.event org.eclipse.equinox.jsp.jasper Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Projects tagged for 3.3.1 M-Build.
The map file has been updated for the following Bug changes: + Bug 176021. [launcher] Eclipse launcher not working OOTB on Gentoo systems (FIXED) + Bug 198462. ClassCastException: WebStartMain$BundleInfo (FIXED) + Bug 199634. IndexOutOfBoundsException during bundle resolution (FIXED) + Bug 200231. [app] Support creating app container without app launcher (FIXED) + Bug 200582. [Launcher] Shared Memory Leak (FIXED) + Bug 200604. [Launcher] Allow relative path for --launcher.library (FIXED) The following projects have changed: org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.equinox.launcher org.eclipse.osgi org.eclipse.equinox.app org.eclipse.equinox.launcher.gtk.linux.x86 org.eclipse.equinox.executable org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.launcher.win32.win32.x86m Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] restricted access setttings
Which template has the error? The jdt prefs template at (http://www.eclipse.org/equinox/documents/org.eclipse.jdt.core.prefs) has the following values for discouraged and forbidden access: org.eclipse.jdt.core.compiler.problem.discouragedReference=error org.eclipse.jdt.core.compiler.problem.forbiddenReference=error On another note I find it inconvenient that we set "Signal overriding or implementing deprecated method" to warning. In some cases we have interfaces which have deprecated methods, there is no choice for the implementer, they must implement the deprecated method. Tom Jeff McAffer <[EMAIL PROTECTED] ibm.com> To Sent by: equinox-dev@eclipse.org equinox-dev-bounc cc [EMAIL PROTECTED] Subject [equinox-dev] restricted access 08/28/2007 11:40 setttings PM Please respond to Equinox development mailing list <[EMAIL PROTECTED] pse.org> I was playing around in the provisioning test bundle and spent about 1 hour tracking down a classloading issues that turned out to be a missing package import. This should have shown up as an error but it turns out that the Test project has forbidden access set to Warning instead of Error. Please be sure that all projects conform to the Equinox coding guidelines (the template has it as error). Where there are deviations, let people know. for example, I left the test project set as Warning for discouraged use as tests sometimes need to reach in to access things not normally available. It might be worthwhile somehow scannng the projects to confirm that they are all set appropriately. Perhaps a simple tool that just looks at the relevant settings files? Jeff ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev <><><>___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] restricted access setttings
I misread Jeff's earlier post. The template is fine. I agree with Jeff,
forbidden access should always be an error, it will never work at runtime.
Thanks for the tip on deprecated methods John. This means we have to
javadoc to internal classes to add the @deprecated tag? Not really a big
deal I guess.
Tom
Jeff McAffer
<[EMAIL PROTECTED]
ibm.com> To
Sent by: Equinox development mailing list
equinox-dev-bounc
[EMAIL PROTECTED] cc
Subject
08/30/2007 06:56 Re: [equinox-dev] restricted access
AMsetttings
Please respond to
Equinox
development
mailing list
<[EMAIL PROTECTED]
pse.org>
yes, the test project did not have the pref set to "error". Note however
setting this particular one to warning is goofy since the resultant code
does not have a hope of running. it really is an error. We are talking
about Forbidden access not Discouraged.
Jeff
John Arthorne/Ottawa/[EMAIL PROTECTED]
Sent by:
[EMAIL PROTECTED]To
Equinox development mailing
list
08/29/2007 06:33 PMcc
Subject
Please respond to Re: [equinox-dev] restricted
Equinox development mailing list access setttings
I think Jeff was saying that the template has that preference set to error,
not that the template has an error. This deviation from the template for
the test project was intentional though, since tests sometimes need to
access internals. The tests also intentionally deviate from the conventions
for the "unexternalized strings" setting (ignore instead of warning).
Perhaps we need a different convention for tests/tools that aren't part of
shipping code.
Tom, for the deprecation warning, you can avoid that by marking the
implementation method as deprecated as well (a deprecated method that
implements a deprecated interface method is not flagged as a warning).
Thomas Watson
<[EMAIL PROTECTED]>
Sent by:
[EMAIL PROTECTED]To
Equinox development mailing
list
08/29/2007 09:30 AMcc
Subject
Please respond to Re: [equinox-dev] restricted
Equinox de
Re: [equinox-dev] Simple SWT App launched with OSGi Launcher hangs on Mac OS X
-Declipse.ignoreApp=true -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts Am I missing a command line option to make this work? Or is there something special I need to do in the SWT code to make this work? I also tried the RCP example that is packaged with Eclipse to see if all SWT applications have this problem but that ran just fine, and the UI did not hang. I checked bugzilla and found launcher bugs dealing with swing, swt, launcher interactions but none with just the launcher and SWT. Attached is com.eclipse.swt.sample.src.zip which contains the project com.eclipse.swt.sample and the binary bundle com.eclipse.swt.sample_1.0.0.jar[attachment "org.eclipse.swt.sample.src.zip" deleted by Thomas Watson/Austin/IBM] Thanks, Patrick ___ 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 projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 198462. ClassCastException: WebStartMain$BundleInfo (FIXED) The following projects have changed: org.eclipse.equinox.launcher Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Launching with Foundation 1.1 VM
Can you run with -noExit -console and see if the org.eclipse.equinox.registry bundle is installed and resolved. If it is not resolved then run the 'diag' command to see why the registry bundle is not resolved. Tom John Arthorne <[EMAIL PROTECTED] .ibm.com> To Sent by: equinox-dev@eclipse.org equinox-dev-bounc cc [EMAIL PROTECTED] Subject [equinox-dev] Launching with 09/06/2007 11:21 Foundation 1.1 VM AM Please respond to Equinox development mailing list <[EMAIL PROTECTED] pse.org> I am trying to run a simple Equinox-based product with J9 (Foundation 1.1 profile). Is there some trick to getting running with this setup? Here is the command line that allows me to make the most progress: eclipse -product org.eclipse.prov.client.installer.product -debug -vm jre\bin\j9.exe -vmargs -jcl:ppro11 -Dorg.osgi.framework.executionenvironment="OSGi/Minimum-1.0,OSGi/Minimum-1.1,CDC-1.0 /Foundation-1.0,CDC-1.1/Foundation-1.1" With this command line, I get various errors in the log, starting with: !ENTRY org.eclipse.equinox.app 4 0 2007-09-06 12:17:51.968 !MESSAGE !STACK 0 org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Require-Bundle: org.eclipse.equinox.registry; bundle-version="[3.2.0,4.0.0)" at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:350) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1118) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:634) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:508) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:282) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:468) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:209) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:319) I have tried invoking the VM directly rather than using eclipse.exe, but get the same result. The same launch runs fine with a 1.4 or Java 5 VM. Ideas?___ 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] Launching with Foundation 1.1 VM
The eRCP project has a XML parser they use. I believe they install them as
framework extensions.
See
http://www.eclipse.org/downloads/download.php?file=/dsdp/ercp/eRCP-v20070801.win32-x86.zip
It includes two xml bundles (org.eclipse.ercp.xml and
org.eclipse.ercp.xmlParserAPIs). These two bundles are configured as
framework extensions with the following config.ini property in eRCP.
osgi.framework.extensions=org.eclipse.ercp.xml,
org.eclipse.ercp.xmlParserAPIs
The reason they use them as framework extensions is so they can support
plugin.xml parsing for compatibility and more importantly to take advantage
of the framework code which registers the xml parsers as OSGi services.
Tom
John Arthorne
<[EMAIL PROTECTED]
.ibm.com> To
Sent by: Equinox development mailing list
equinox-dev-bounc
[EMAIL PROTECTED] cc
Subject
09/06/2007 12:08 Re: [equinox-dev] Launching with
PMFoundation 1.1 VM
Please respond to
Equinox
development
mailing list
<[EMAIL PROTECTED]
pse.org>
Thanks Tom. Registry is not resolved because it requires a SAX parser. I
tried org.apache.xerces from orbit, but it requires a 1.2 EE. Does anyone
know of a SAX parser that will run in Foundation 1.1?
Thomas Watson
<[EMAIL PROTECTED]>
Sent by: To
[EMAIL PROTECTED]Equinox development mailing
list
cc
09/06/2007 12:47 PM
Subject
Re: [equinox-dev] Launching
Please respond to with Foundation 1.1 VM
Equinox development mailing list
Can you run with -noExit -console and see if the
org.eclipse.equinox.registry bundle is installed and resolved. If it is not
resolved then run the 'diag' command to see why the registry bundle is not
resolved.
Tom
Inactive hide details for John Arthorne ---09/06/2007 11:22:26 AM---I am
trying to run a simple Equinox-based product with J9 (John Arthorne ---09
/06/2007 11:22:26 AM---I am trying to run a simple Equinox-based product
with J9 (Foundation 1.1 profile). Is there some trick to getting running
with
John Arthorne
<[EMAIL PROTECTED]>
Sent by:
[EMAIL PROTECTED]
To
09/06/2007 11:21 AM
equinox-dev@eclipse.org
Please respond to
Re: [equinox-dev] [vote] graduating the new jar processor bundle
+1 There is currently provisional API in the org.eclipse.osgi which is currently used by update to check the certificate trust and to verify the content of signed bundles. I assume the jar processor API can use an IProcessStep to which uses the API from the framework to perform this type of check? Or would verifying the signed content continue to be a separate step as it is today in update? Tom Andrew Niefer <[EMAIL PROTECTED] om>To Sent by: Equinox development mailing list equinox-dev-bounc [EMAIL PROTECTED] cc Subject 09/10/2007 10:29 Re: [equinox-dev] [vote] graduating AMthe new jar processor bundle Please respond to Equinox development mailing list <[EMAIL PROTECTED] pse.org> +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: To [EMAIL PROTECTED] Equinox development mailing list cc 09/10/2007 09:54 AM Subject Re: [equinox-dev] [vote] Please respond to graduating the new jar Equinox development mailing list 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
[equinox-dev] Equinox projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 165964. Process Bundle-NativeCode at resolve time (FIXED) + Bug 200068. AdapterManager fails to find correct IAdapterFactory if the IAdapterFactory implementation class loader cannot load the class returned by the getAdapterList() method (FIXED) + Bug 201489. [osgi R5] multiple versions of a fragment should not attach to the same host (FIXED) The following projects have changed: org.eclipse.osgi.tests org.eclipse.osgi org.eclipse.equinox.common org.eclipse.equinox.supplement Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Launcher and fragments
Both the eclipse.exe and the equinox.launcher bundle may load the native library in launcher For example when launching self-hosting, the eclipse.exe is not used. In this case the equinox.launcher java code loads the shared library. Currently there is no eclipse.exe bundle, that left us with the equinox.launcher bundle for the host of the shared library fragments. We could create an equinox.executable host bundle but I'm not sure what the motivation would be for that since it would be an empty host that does nothing other than allow the native code fragment bundles to resolve. Tom Pascal Rapicault To Sent by: Equinox development mailing list equinox-dev-bounc [EMAIL PROTECTED] cc Subject 09/11/2007 08:43 [equinox-dev] Launcher and AMfragments Please respond to Equinox development mailing list <[EMAIL PROTECTED] pse.org> Hello, I'm questioning why the launcher... bundles are fragments of the launcher bundle? If I remember correctly the launcher fragments result from the reorganization of the eclipse.exe where we tried to make the exe as small as possible. Therefore it seems to me that the declaration of the platform specific launcher bundles as fragment of the launcher.jar (formerly startup.jar) is abusive. However I found weird that we did without a precise motive. Does anyone remember it? For me, the platform specific launchers should be "fragment to the eclipse.exe". 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] Compilation warnings in latest nightly build
Thanks for the info and the lead-in Olivier. As you may have noticed the new bundles contributed by Prosyst have been added to the equinox incubator build and can now be downloaded from the equinox download page. I updated the projects with the following: - added .qualifier to the Bundle-Version - added appropriate Bundle-RequiredExecutionEnvironment headers and updated compiler settings to use the proper execution environment JRE to build. - updated the settings the equinox code formatter and to format and organize imports on Java file saves - formatted and organized imports of all the code according to the new settings - fixed the compiler warnings from the build Over the next few milestones we will be reviewing the code and getting it into shape for graduation out of the incubator. Any help from the community in testing and reviewing the code is appreciated. Please use the bundles from the equinox download page and open any bugs for issues you may find. Thanks. Tom Olivier Thomann To Sent by: equinox-dev@eclipse.org equinox-dev-bounc cc [EMAIL PROTECTED] Subject [equinox-dev] Compilation warnings 09/11/2007 09:16 in latest nightly build AM Please respond to Equinox development mailing list <[EMAIL PROTECTED] pse.org> Hi, Several warnings were found in last nightly build. Here is a list of concerned bundles: - org.eclipse.equinox.ds - org.eclipse.equinox.io - org.eclipse.equinox.ip - org.eclipse.equinox.util - org.eclipse.equinox.wireadmin Please review the warnings from the nightly build results. These warnings are trivial to address. If you wonder why it is useful to provide a serialVersionUID field, I would suggest the reading of the tutorial about serialization. The projects' settings can also be modified to prevent this kind of warnings in future builds. If you don't know how to do that, let me know. Olivier ___ 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->Bundles component is getting crowded
The Equinox project continues to grow with new components and new contributes being added. Thanks everyone!! As new contributions are graduated into Equinox proper we need to place them under one of the existing components. Currently we have the "Framework" and "Bundles" components for Equinox proper in bugzilla/cvs. A large majority of the new contributions will fall into the "Bundles" component. For example, we have a few work areas in the equinox incubator which are very active (e.g. p2, security etc). Once this work graduates it will likely to be placed into the generic "Bundles" component. This will make an already crowded component even more crowded. Should we consider creating a more diverse set of components for the work which is graduated into Equinox? I think the p2 and security work will deserve their own component when they graduate. Thoughts? Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox->Bundles component is getting crowded
For the security stuff I was referring to the security-specific bundles
like login (JAAS integration etc.)
You are right there is a lot of cross-cutting concerns with the other
security related work that will not really fit into any one component.
Tom
John Arthorne
<[EMAIL PROTECTED]
.ibm.com> To
Sent by: Equinox development mailing list
equinox-dev-bounc
[EMAIL PROTECTED] cc
Subject
09/12/2007 11:21 Re: [equinox-dev] Equinox->Bundles
AMcomponent is getting crowded
Please respond to
Equinox
development
mailing list
<[EMAIL PROTECTED]
pse.org>
Creating a new component for p2 definitely makes sense to me. I don't know
much about the security work, but that may be difficult to partition into
its own component because it's an inherently cross-cutting concern. If
there end up being a number of security-specific bundles, it may make
sense.
Generally speaking, I think more components is a good thing. It's a great
way to bring in new committers who may not be able to make the large
commitment needed to contribute across a large part of Equinox.
John
Thomas Watson
<[EMAIL PROTECTED]>
Sent by: To
[EMAIL PROTECTED] equinox-dev@eclipse.org
cc
09/12/2007 11:42 AM Subject
[equinox-dev] Equinox->Bundles
component is getting crowded
Please respond to
Equinox development mailing list
The Equinox project continues to grow with new components and new
contributes being added. Thanks everyone!!
As new contributions are graduated into Equinox proper we need to place
them under one of the existing components. Currently we have the
"Framework" and "Bundles" components for Equinox proper in bugzilla/cvs. A
large majority of the new contributions will fall into the "Bundles"
component. For example, we have a few work areas in the equinox incubator
which are very active (e.g. p2, security etc). Once this work graduates it
will likely to be placed into the generic "Bundles" component. This will
make an already crowded component even more crowded.
Should we consider creating a more diverse set of components for the work
which is graduated into Equinox? I think the p2 and security work will
deserve their own component when they graduate. Thoughts?
Tom
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<><><>___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox->Bundles component is getting crowded
There are two extreme positions to take. Lump a large number of loosely related deliverables under one component or create a separate component for each and every deliverable. I'm not sure I favor the latter extreme. Currently the Equinox download page allows you to download each bundle individually so each bundle is a separate downloadable item. Creating a separate component for each and every bundle in Equinox may prove to be too much overhead. It is my understanding that in Eclipse typically every bugzilla component has its own set of commit rights in CVS. If we have a very high number of components then we will be holding a very large number of committer elections to get all the committers the access they need :-) I think we a balance and create components as we see fit to split up the different work areas in Equinox instead of creating a component for every bundle. Tom BJ Hargrave/Austin/I [EMAIL PROTECTED] To Sent by: Equinox development mailing list equinox-dev-bounc [EMAIL PROTECTED] cc Subject 09/12/2007 12:30 Re: [equinox-dev] Equinox->Bundles PMcomponent is getting crowded Please respond to Equinox development mailing list <[EMAIL PROTECTED] pse.org> It would probably be best if each separately downloadable item had its own component against which people could file bugs. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Thomas Watson/Austin/[EMAIL PROTECTED] To: Equinox development mailing list Date: 2007-09-12 12:34 Subject: Re: [equinox-dev] Equinox->Bundles component is getting crowded For the security stuff I was referring to the security-specific bundles like login (JAAS integration etc.) You are right there is a lot of cross-cutting concerns with the other security related work that will not really fit into any one component. Tom John Arthorne ---09/12/2007 11:25:42 AM---Creating a new component for p2 definitely makes sense to me. I don't know much about the security work, but that may be diffi John Arthorne <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/12/2007 11:21 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] Equinox->Bundles component is getting crowded Creating a new component for p2 definitely makes sense to me. I don't know much about the security work, but that may be difficult to partition into its own component because it's an inherently cross-cutting concern. If there end up being a number of security-specific bundles, it may make sense. Generally speaking, I think more components is a good thing. It's a great way to bring in new committers who may not be able to make the large commitment needed to contribute across a large part of Equinox. John Thomas Watson <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/12/2007 11:42 AM Please respond to Equinox development mailing list To equinox-dev@eclipse.org cc Subject [equinox-dev] Equinox->Bundles component is getting crowded The Equinox project continues to grow with new components and new contributes being added. Thanks everyone!! As new contributions are graduated into Equinox proper we need to place them under one of the existing components. Currently we have the "Framework" and "Bundles" components for Equinox proper in bugzilla/cvs. A large majority of the new contributions will fall into the "Bundles" component. For example, we have a few work areas in the equinox incubator which are very active (e.g. p2, security etc). Once this work graduates it will likely to be placed into the gener
[equinox-dev] Equinox projects tagged for 3.4 I-build
In preparation for M2 build on Monday I have tagged the equinox projects early. If additional fixes are releases please make sure they are tagged appropriately for the M2 warm-up build. The map file has been updated for the following Bug changes: + Bug 96034. Need an API to determine if another location is locked (FIXED) + Bug 188089. [osgi] can't launch an osgi bundle if the path of its plugin project contains the caracter "@" (FIXED) + Bug 201425. [osgi R4.1] Fragments should be able to export duplicate packages (FIXED) + Bug 202282. Support a proposed extension:="ext" (FIXED) + Bug 203135. buddy classloading fails if the boot classpath contains the same class as a buddy (FIXED) The following projects have changed: org.eclipse.osgi.tests org.eclipse.osgi org.eclipse.equinox.supplement Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [security] Merged org.eclipse.osgi v20070914 tag from HEAD into security incubator
I merged the org.eclipse.osgi v20070914 tag from the Equinox 3.4 (HEAD) stream into the security incubator. There were some fixes from the HEAD stream which are important to the security work. In particular https://bugs.eclipse.org/bugs/show_bug.cgi?id=202282 is needed to be able to provide JCA security provider implementations contributed from bundles. Matt, Eric and others on the security incubator team, please let me know if you find any issues with the merge. I created the following tags and branches in the security incubator equinox-proper-dev branch - intended to contain the unmodified code from equinox proper stream (3.4 HEAD) v20070914 - tag on the equinox-proper-dev branch used after initial check of the v20070914 code v20070914-premerge - tag used before merging in the changes from the equinox-proper-dev branch to the security HEAD stream v20070914-postmerge - tag used after merging in the changes from the equinox-proper-dev branch to the security HEAD stream Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox Summit: Talks and topics
Equinox Summit 2007 attendees, The summit date is fast approaching, and it's time to firm up the agenda. The substance of the summit will be shaped by all attendees, so your help is needed in setting the agenda. To this end, can *all* attendees please add a quick summary of your areas of interest to the summit wiki. It can be just a few words, but if you don't let others know what you're here for, you probably won't get much out of the short time we have available. http://wiki.eclipse.org/Equinox_Summit_2007_topics#Areas_of_Interest Also, the summit will start off with some short talks on major work areas in and around Equinox over the coming year. Please consider adding a talk proposal here by Friday 9/18/2007: http://wiki.eclipse.org/Equinox_Summit_2007_topics#Lightning_Talks Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox Summit: Talks and topics
Sorry, I sent out the incorrect deadline date for short talk proposals. The correct deadline date is Friday 9/21/2007. Tom Thomas Watson/Austin/IBM @IBMUS To Sent by: equinox-dev@eclipse.org equinox-dev-bounc cc [EMAIL PROTECTED] Subject [equinox-dev] Equinox Summit: Talks 09/18/2007 04:20 and topics PM Please respond to Equinox development mailing list <[EMAIL PROTECTED] pse.org> Equinox Summit 2007 attendees, The summit date is fast approaching, and it's time to firm up the agenda. The substance of the summit will be shaped by all attendees, so your help is needed in setting the agenda. To this end, can *all* attendees please add a quick summary of your areas of interest to the summit wiki. It can be just a few words, but if you don't let others know what you're here for, you probably won't get much out of the short time we have available. http://wiki.eclipse.org/Equinox_Summit_2007_topics#Areas_of_Interest Also, the summit will start off with some short talks on major work areas in and around Equinox over the coming year. Please consider adding a talk proposal here by Friday 9/18/2007: http://wiki.eclipse.org/Equinox_Summit_2007_topics#Lightning_Talks 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: Re[2]: [equinox-dev] ClassNotFoundException with org.eclipse.osgi_3.3.0.v20070530
Pavlin is correct. For 3.3 we no longer set the org.osgi.framework.bootdelegation=* When using the org.eclipse.osgi jar directly (i.e java -jar org.eclipse.osgi_.jar) then the framework is starting in a "strict" mode with respect to boot classpath delegation. You must using Import-Package to get access to any packages your bundle uses outside of the java.* name space like Toni mentioned. Tom Pavlin Dobrev <[EMAIL PROTECTED] .com> To Sent by: Equinox development mailing list equinox-dev-bounc [EMAIL PROTECTED] cc Subject 09/19/2007 07:40 Re[2]: [equinox-dev] AMClassNotFoundException with org.eclipse.osgi_3.3.0.v20070530 Please respond to Pavlin Dobrev <[EMAIL PROTECTED] .com>; Please respond to Equinox development mailing list <[EMAIL PROTECTED] pse.org> The old behavior is org.osgi.framework.bootdelegation=* This is changed because of requirement of the OSGi Release 4 Specification. -Pavlin TM> Usually you should import everything other than java.* TM> (so add javax.xml.xpath, javax.crypto to your Import-Package directive) TM> Check your org.osgi.framework.bootdelegation property. Usually TM> equinox delegates everything to the bootclasspath (where javax TM> resides) for historical reasons. But this behaviour is going to TM> change and might have changed already in 3.3.. TM> /Toni TM> Original-Nachricht >> Datum: Wed, 19 Sep 2007 12:47:10 +0200 >> Von: Tony Seebregts <[EMAIL PROTECTED]> >> An: equinox-dev@eclipse.org >> Betreff: [equinox-dev] ClassNotFoundException with org.eclipse.osgi_3.3.0.v20070530 >> Hi, >> >> I'm getting a class not found Exception for (some) javax classes when >> using the latest Equinox release (org.eclipse.osgi_3.3.0.v20070530.jar) >> - specifically: >> >> ERROR: java.lang.NoClassDefFoundError: javax.xml.xpath.XPathFactory >> ERROR: java.lang.NoClassDefFoundError: javax.crypto.KeyGenerator >> >> When I switch back to an earlier (3.2) release the problem goes away - >> the environment is identical in both cases, all that changes is the >> org.eclipse.osgi jar file. >> >> If anybody has any ideas or can point me in the right direction it would >> be really appreciated. >> >> regards >> >> Tony Seebregts >> ___ >> equinox-dev mailing list >> equinox-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/equinox-dev TM> ___ TM> equinox-dev mailing list TM> equinox-dev@eclipse.org TM> https://dev.eclipse.org/mailman/listinfo/equinox-dev TM> __ NOD32 2540 (20070919) Information __ TM> This message was checked by NOD32 antivirus system. TM> http://www.eset.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] os.name for Windows 2003 Server
I opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=204110 to track
this. We will have to feed this through OSGi to get another alias defined
for Windows2003
Tom
Lukasz Bobowiec
To
Sent by: equinox-dev@eclipse.org
equinox-dev-bounc cc
[EMAIL PROTECTED]
Subject
[equinox-dev] os.name for Windows
09/20/2007 04:51 2003 Server
AM
Please respond to
Equinox
development
mailing list
<[EMAIL PROTECTED]
pse.org>
Hello,
I followed the link sent by Peter Kriens about OS names:
http://www2.osgi.org/Specifications/Reference
However on Windows 2003 Server with IBM JRE 1.5 using Peter's properties
bundle I obtain the following values:
os.name="Windows Server 2003" "windows server 2003"
os.arch="x86" "x86"
os.version= "5.2 build 3790 Service Pack 1""5.2 build 3790 service
pack 1"
java.vendor="IBM Corporation" "ibm corporation"
java.class.version= "49.0" "49.0"
java.version= "1.5.0""1.5.0"
file.separator= "\""\"
path.separator= ";"";"
org.osgi.framework.bootdelegation="*" "*"
...
org.osgi.supports.framework.extension="true" "true"
microedition.configuration="null" "null"
microedition.profiles="null" "null"
org.osgi.framework.executionenvironment="OSGi/Minimum-1.0,OSGi/Minimum-1.1,JRE-1.1,J2SE-1.2,J2SE-1.3,J2SE-1.4,J2SE-1.5""osgi/minimum-1.0,osgi/minimum-1.1,jre-1.
1,j2se-1.2,j2se-1.3,j2se-1.4,j2se-1.5"
org.osgi.supports.bootclasspath.extension="null" "null"
org.osgi.supports.framework.fragment="null""null"
org.osgi.supports.framework.requirebundle="null" "null"
org.osgi.framework.version="1.3.0" "1.3.0"
org.osgi.framework.language="pl" "pl"
org.osgi.framework.vendor="Eclipse""eclipse"
org.osgi.framework.os.name="windows server 2003" "windows server 2003"
org.osgi.framework.os.version="5.2""5.2"
org.osgi.framework.processor="x86" "x86"
OSGi r4 specification does not mention about such value "Windows Server
2003".
For IBM JRE 1.4.2 os.name is "Windows 2003".
I have lots of bundle with native code and inside the manifest file when I
do not append for the header "Bundle-NativeCode" the "Windows Server 2003"
value my bundles are invisible (they are not even in INSTALLED state).
After adding to "Windows Server 2003" to Bundle-NativeCode everything works
fine.
I found the similar problem that System.getProperty("os.name"), SunVM and
J9 reports different names
http://forum.java.sun.com/thread.jspa?threadID=769559&tstart=255
Does OSGi spec. recommend "Windows 2003" or "Windows Server 2003" for
Windows Server 2003?
---
Best regards,
Lukasz Bobowiec
Software Engineer, Common Agent Services
[EMAIL PROTECTED]
(+48 12) 628 9882
IBM SWG Lab, Cracow, Poland
IBM Polska Sp. z o.o. oddział w Krakowie
ul. Armii Krajowej 18
30 -150 Kraków
NIP: 526-030-07-24
Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy KRS
KRS 012941, Kapitał zakładowy: 3.073.600 PLN
___
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] import of super class required ?
This is related to JDT bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=122915
Summary: there are cases where the compiler is more strict than the OSGi
runtime and there are other cases where the OSGi runtime is more strict
than the compiler (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=122915#c14 for details).
Tom
"Tom Huybrechts"
<[EMAIL PROTECTED]
mail.com> To
Sent by: "Equinox development mailing list"
equinox-dev-bounc
[EMAIL PROTECTED] cc
Subject
09/22/2007 05:08 [equinox-dev] import of super class
PMrequired ?
Please respond to
Equinox
development
mailing list
<[EMAIL PROTECTED]
pse.org>
Hi all,
I have a class visibility problem I don't understand.
Suppose I have bundle A with classes A and B, and bundle C with class C.
bundle A (exports packages A and B)
package a;
public class A extends b.B { }
package b;
public class B {
public void method() { }
}
bundle C: (imports only package a)
package c:
public class C {
public C() {
new A().method();
}
C calls a method from a super class of A with it cannot see. My guess
was that this should not be possible. And indeed, it doesn't even
compile with PDE. But if I make it compile (e.g. add bundle A to the
'automated management of dependencies') then it also works at runtime!
Am I missing something here ?
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 projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 203973. Bundles in cycles that should be resolved do not get resolved (ASSIGNED) + Bug 204007. [app] need automated tests for application admin (FIXED) + Bug 204027. [app] timing issues if app handle is destroyed before the application code is run (FIXED) + Bug 204381. [app] two application admin tests fail intermittently (FIXED) The following projects have changed: org.eclipse.equinox.app org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Moving Service Activator Toolkit (SAT) from the Open Healthcare Framework (OHF) to Equinox
+1 I fully support adding this well established team with a very long OSGi history to the Equinox community. Tom Patrick Dempsey <[EMAIL PROTECTED]> Sent by: To equinox-dev-bounc Equinox development mailing list [EMAIL PROTECTED] cc 09/26/2007 02:44 Subject PM[equinox-dev] Moving Service Activator Toolkit (SAT) from the Open Healthcare Framework Please respond to (OHF) to Equinox Equinox development mailing list <[EMAIL PROTECTED] pse.org> Currently the Service Activator Toolkit (SAT) in the Open Healthcare Framework (OHF) technology project that is of great value to people programming OSGi Applications. SAT is a Java component that simplifies the building of OSGi service-oriented bundles. It is approximately 8,000 lines of Java code. By decreasing the complexity of OSGi bundle development, this toolkit provides increased acceptance of OSGi in the device community. In addition to making the use of OSGi services easier, it supports the creation of well behaved bundles, reducing development time, reducing training costs, and promotes consistent bundle behavior. It seems that this technology is somewhat misplaced and it would better serve the community if it was part of the Equinox project. I propose moving SAT from OHF to Equinox. As this code is very stable, robust and has been previously used in commercial products, I would ask that it be reviewed for eligibility for moving in the graduated Equinox bundles area, rather than the Equinox Incubator. For reference SAT is in cvs at :pserver:dev.eclipse.org:/cvsroot/technology org.eclipse.ohf/plugins/org.eclipse.soda.sat There is also lots of good information (documentations, bug reporting, downloads) at http://eclipse-sat.blogspot.com/ Patrick ___ 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 projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 204931. Wrong debug info output on console. Someone made a typo: "paserHeader" instead of "parseHeader". (FIXED) The following projects have changed: org.eclipse.equinox.http.servlet org.eclipse.osgi org.eclipse.equinox.supplement Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [p2] UI priorities for M3
There is a proposal for a new Bundle-License manifest header that will be considered for the next release of the OSGi specification. We will need to monitor this RFC #125 to ensure that it meets our needs for presentation of licenses in p2. This is not an immediate concern for p2 but we need to make sure the proposal is something we can use in the future. Tom From: Susan M Franklin/Beaverton/[EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 10/02/2007 01:57 PM Subject:[equinox-dev] [p2] UI priorities for M3 Hi, everyone. One of the goals for M3 is to try to define the conent/scope of our 3.4 deliverable. So I'm trying to balance our desire to resolve unknowns with getting current workflows more polished. I'm interested in the community's feedback on the current M3 UI plan, which currently includes - improving the install/uninstall/update workflow by providing more info (size, time, invalid states, etc.) - polling for software updates and notifying the user - improved support for browsing repos (IU categories and filtering) - more info in admin artifact repo views (You can see the expanded detail at http://wiki.eclipse.org/Equinox_p2_User_Interface#Milestone_plan). This is a rather aggressive plan but still does not address some other big UI items, most notably - UI for rollback - presentation of licenses So if you have opinions on the pressing issues and priorities in the UI, please let me know via this list, or annotating bugs you care about, etc thanks, susan___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev <><>___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] How to Debug with org.eclipse.osgi.jar
The easiest way to debug the Equinox Framework is to use the "OSGi Framework" launch configuration under Run->Open Run Dialog ... See http://help.eclipse.org/help33/topic/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html for documentation on configuration options. Tom From: "黄飞" <[EMAIL PROTECTED]> To: "equinox-dev" Date: 10/06/2007 07:37 AM Subject:[equinox-dev] How to Debug with org.eclipse.osgi.jar equinox-dev，hi！ I would like to study the eqinox framework,so i import the plugin org.eclipse.osgi_3.3.0.v20061213.jar as source project, but when i debug the project, debugging failed then on : org.eclipse.osgi Startup error java.lang.NullPointerException at org.eclipse.osgi.baseadaptor.BaseAdaptor.initializeStorage(BaseAdaptor.java:124) at org.eclipse.osgi.framework.internal.core.Framework.initialize(Framework.java:174) at org.eclipse.osgi.framework.internal.core.Framework.(Framework.java:147) at org.eclipse.osgi.framework.internal.core.OSGi.createFramework(OSGi.java:90) at org.eclipse.osgi.framework.internal.core.OSGi.(OSGi.java:31) at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:278) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:166) at org.eclipse.core.runtime.adaptor.EclipseStarter.main(EclipseStarter.java:143) Exception in thread "main" java.lang.NullPointerException at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:212) at org.eclipse.core.runtime.adaptor.EclipseStarter.main(EclipseStarter.java:143) So, again my question: how should I go about debugging equinox as standalone osgi framework, and where can I get some knowledge about all the stuff like different start configs, properties, hooks, storage organization and so. Regards 2007-10-06 -- Fei Huang Technology Center for Software Engineering Institute of Software, Chinese Academy of Sciences P.O.Box 8718, Beijing 100080, China Email:[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
[equinox-dev] Equinox projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 176021. [launcher] Eclipse launcher not working OOTB on Gentoo systems (FIXED) + Bug 198578. URLStreamHandlerFactory not found after being used (ASSIGNED) + Bug 198981. ppc/motif Xdefaults not honored on version 3.3 (FIXED) + Bug 201414. [Launcher] Launchers can't run without WS, remove static linking (FIXED) + Bug 204110. Should "Windows Server 2003" be another alias for Windows2003 (ASSIGNED) + Bug 204812. Exporters must not be counted as importers of their export. (ASSIGNED) + Bug 205060. [app] testcase testDescriptorEvents01 fails intermittently (NEW) + Bug 205117. ReferenceMap.purge has a major flaw in its implementation (FIXED) + Bug 205270. PDE tooling fails because Bundle-NativeCode causes java.lang.NullPointerException (FIXED) + Bug 205601. [launcher] possible memory leak in resolveSymlinks (FIXED) The following projects have changed: org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.osgi.tests org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.osgi org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.launcher org.eclipse.equinox.executable org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.registry org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.launcher.gtk.linux.x86 Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] OSGi R4.2 Stream
The OSGi Alliance is busy working on the next release of the specification. The release of the next OSGi specification will be long after the Eclipse 3.4 (Ganymede) release. To achieve a stable Ganymede release we will not release new OSGi R4.2 API or implement new R4.2 functions in the Ganymede stream (HEAD). We need a place where we can continue to implement and prototype the next OSGi specification release as it is being developed. I see two options. 1) Create an area in the Equinox incubator to develop the OSGi R4.2 implementation 2) Create a branch off of the current Ganymede stream (HEAD) for OSGi R4.2 implementation I prefer using a branch instead of a separate repository project in the incubator because it will make life easier when developing streams in parallel, which we will likely need to do until the Ganymede release in June 2008. I plan to create a branch based of next weeks I-Build for the OSGi R4.2 work. Please let me know if you have any issues with this. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] OSGi R4.2 Stream
I would like to publish a build of org.eclipse.osgi for OSGi R4.2. But that question is orthogonal to where the code lives. We can build out of the incubator or out of a branch, right? It is a good question though. I'm not sure where we would publish the build on the Equinox download site. In the end it is not critical to build it until the next release of OSGi is closer to being final. By that time hopefully we would have moved the code into the mainline stream and build it with the rest of the current release (post 3.4). Tom From: Pascal Rapicault <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 10/12/2007 02:26 PM Subject:Re: [equinox-dev] OSGi R4.2 Stream Do you have plan to publish builds of what will be developed? PaScaL |> | From: | |> >------| |Thomas Watson <[EMAIL PROTECTED]> | >--| |> | To:| |> >--| |equinox-dev@eclipse.org | >--| |> | Date: | |> >--| |10/12/2007 02:35 PM | >--| |> | Subject: | |> >--| |[equinox-dev] OSGi R4.2 Stream | >--| The OSGi Alliance is busy working on the next release of the specification. The release of the next OSGi specification will be long after the Eclipse 3.4 (Ganymede) release. To achieve a stable Ganymede release we will not release new OSGi R4.2 API or implement new R4.2 functions in the Ganymede stream (HEAD). We need a place where we can continue to implement and prototype the next OSGi specification release as it is being developed. I see two options. 1) Create an area in the Equinox incubator to develop the OSGi R4.2 implementation 2) Create a branch off of the current Ganymede stream (HEAD) for OSGi R4.2 implementation I prefer using a branch instead of a separate repository project in the incubator because it will make life easier when developing streams in parallel, which we will likely need to do until the Ganymede release in June 2008. I plan to create a branch based of next weeks I-Build for the OSGi R4.2 work. Please let me know if you have any issues with this. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev <><>___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] OSGi R4.2 Stream
At this point I do not think we intend on doing a major overhaul on the framework. I can only see us doing that if 1) it is evident that the current implementation is not fulfilling the Eclipse usecases which are important to the Eclipse community as a whole 2) The OSGi specification changes are so drastic that we need to restructure the code. In some cases the resolver may fall into category 1 but I would rather replace that with some existing technology instead of rewriting our own again (SAT solver, maybe look to the Felix resolver etc.). Tom From: Pascal Rapicault <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 10/12/2007 03:18 PM Subject:Re: [equinox-dev] OSGi R4.2 Stream There is no technical problems with building out of a branch or the incubator (except that we would have to run the build separately since there would be two bundles with the same BSN and therefore two map entries, etc.). In the end I was just curious about your intentions. Wrt to the actual location for the code, I think it depends on whether you want to limit your work to only spec work, or if you want to use this as a place to do bigger overhaul of the fwk. If you just want to do spec work, then a branch is fine, however for the other I would go for the incubator. Also the incubator has the nice attribute that it is easier to make people committer. PaScaL |> | From: | |> >------| |Thomas Watson <[EMAIL PROTECTED]> | >--| |> | To:| |> >--| |Equinox development mailing list | >--| |> | Date: | |> >--| |10/12/2007 04:05 PM | >--| |> | Subject: | |> >--| |Re: [equinox-dev] OSGi R4.2 Stream | >--| I would like to publish a build of org.eclipse.osgi for OSGi R4.2. But that question is orthogonal to where the code lives. We can build out of the incubator or out of a branch, right? It is a good question though. I'm not sure where we would publish the build on the Equinox download site. In the end it is not critical to build it until the next release of OSGi is closer to being final. By that time hopefully we would have moved the code into the mainline stream and build it with the rest of the current release (post 3.4). Tom (Embedded image moved to file: pic18849.gif)Inactive hide details for Pascal Rapicault ---10/12/2007 02:26:20 PM---Do you have plan to publish builds of what will be develPascal Rapicault ---10/12/2007 02:26:20 PM---Do you have plan to publish builds of what will be developed? (Embedded image (Embedded image moved to file: pic21527.gif) moved to file: Pascal Rapicault <[EMAIL PROTECTED]> pic10871.gif) From: (Embedded image (Embedded image moved to file: pic18432.gif) moved to file: Equinox development mailing list pic17038.gif) To: (Embedded image (Embedded image moved to file: pic31885.gif) moved to file: 10/12/2007 02:26 PM pic13205.gif) Date: (Embedded image (Embedded image moved to file: pic09675.gif) moved to file: Re: [equinox-dev] OSGi R4.2 Stream pic01580.gif) Subject: Do you have plan to pu
[equinox-dev] Graduation of Prosyst contributed bundles
The bundles contributed by Prosyst have been in the incubator since July. The codebase Prosyst donated is already production quality and has been used in many products at Prosyst. A small number of issues have been reported against the bundles in the incubator. But these are to be expected and the committers from Prosyst have been responsive in addressing the issues. At this point I would like to ask Prosyst which of the incubator bundles would they like to graduate and support in the Equinox-Bundles component? We have the following bundles to consider: org.eclipse.equinox.util ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181731) org.eclipse.equinox.ds ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181733) org.eclipse.equinox.ip ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181734) org.eclipse.equinox.wireadmin ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181736) org.eclipse.equinox.io ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181737) The last four bundles (ds, ip, wireadmin, io) all provide implementations to OSGi specifications and do not provide public API. I am concerned about the amount of public API in the org.eclipse.equinox.util bundle (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151). We should consider the following when making this decision: 1) Which bundles does the community need? We do not need to graduate all the bundles if we determine that the community is not interested in all of them. 2) Which bundles do we have sufficient resources to support at the graduated level. 3) How much API will be graduated. Graduated API has a long term commitment and requires a lot of review and must be positioned such that we do not break compatibility while evolving the API after graduation. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Graduation of Prosyst contributed bundles
We also will need to setup automated tests for the bundles which are graduated. (See https://bugs.eclipse.org/bugs/show_bug.cgi?id=206333) Tom From: Thomas Watson/Austin/[EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 10/15/2007 09:28 AM Subject:[equinox-dev] Graduation of Prosyst contributed bundles The bundles contributed by Prosyst have been in the incubator since July. The codebase Prosyst donated is already production quality and has been used in many products at Prosyst. A small number of issues have been reported against the bundles in the incubator. But these are to be expected and the committers from Prosyst have been responsive in addressing the issues. At this point I would like to ask Prosyst which of the incubator bundles would they like to graduate and support in the Equinox-Bundles component? We have the following bundles to consider: org.eclipse.equinox.util ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181731) org.eclipse.equinox.ds ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181733) org.eclipse.equinox.ip ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181734) org.eclipse.equinox.wireadmin ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181736) org.eclipse.equinox.io ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181737) The last four bundles (ds, ip, wireadmin, io) all provide implementations to OSGi specifications and do not provide public API. I am concerned about the amount of public API in the org.eclipse.equinox.util bundle (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151). We should consider the following when making this decision: 1) Which bundles does the community need? We do not need to graduate all the bundles if we determine that the community is not interested in all of them. 2) Which bundles do we have sufficient resources to support at the graduated level. 3) How much API will be graduated. Graduated API has a long term commitment and requires a lot of review and must be positioned such that we do not break compatibility while evolving the API after graduation. 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: Re[2]: [equinox-dev] Graduation of Prosyst contributed bundles
We should develop some of our own testcases to get complete coverage. The
OSGi test suite can be used by the committers (which are also OSGi members)
during our test pass for each mile stone. The OSGi test cases should not
be considered as a complete test suite, in many cases they will let bugs
slip by. Every bug we fix which the OSGi test suite did not catch should
likely have an automated testcase created.
We have looked into running the OSGi TCK with each build during the junit
tests, but the effort was high and in the end it was decided to run the
OSGi TCK as part of our manual milestone test pass.
Tom
From: Pavlin Dobrev <[EMAIL PROTECTED]>
To: Equinox development mailing list
Date: 10/15/2007 10:11 AM
Subject:Re[2]: [equinox-dev] Graduation of Prosyst contributed bundles
All of the bundles that implement OSGi defined services:
org.eclipse.equinox.ds
org.eclipse.equinox.ip
org.eclipse.equinox.wireadmin
org.eclipse.equinox.io
pass the corresponding OSGi test cases. How you proceed in this case
because OSGi test cases are not publicly available?
-Pavlin
> We also will need to setup automated tests for the bundles which are
> graduated. (See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=206333)
Tom
Thomas Watson---10/15/2007 09:28:05 AM---The bundles contributed by Prosyst
have been in
the incubator since July. The codebase Prosyst donated is already
production qu
From:
Thomas Watson/Austin/[EMAIL PROTECTED]
To:
equinox-dev@eclipse.org
Date:
10/15/2007 09:28 AM
Subject:
[equinox-dev] Graduation of Prosyst contributed
bundles
The bundles contributed by Prosyst have been in the incubator since July.
The codebase
Prosyst donated is already production quality and has been used in many
products at
Prosyst. A small number of issues have been reported against the bundles in
the incubator.
But these are to be expected and the committers from Prosyst have been
responsive in
addressing the issues. At this point I would like to ask Prosyst which of
the incubator
bundles would they like to graduate and support in the Equinox-Bundles
component?
We have the following bundles
[equinox-dev] Equinox projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 168281. [launcher] JNI launching fails on aix.ppc (FIXED) + Bug 196890. Equinox 3.3 HttpService bundle not OSGi/Minimum-1.1 compliant. (ASSIGNED) + Bug 202496. [Launcher] Variable substitution in .ee files (FIXED) + Bug 204812. Exporters must not be counted as importers of their export. (FIXED) + Bug 205060. [app] testcase testDescriptorEvents01 fails intermittently (FIXED) + Bug 205990. [launcher] Invalid JVM options are silently ignored (ASSIGNED) + Bug 206377. Fix compiler warning in org.eclipse.osgi BundlePermissionCollection (FIXED) The following projects have changed: org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.app org.eclipse.equinox.http org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.osgi org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.launcher org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.executable org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.launcher.gtk.linux.x86 Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Proposal for an OSGi spec work area in the equinox incubator
I would like to start a new work area in the Equinox incubator to support prototyping and investigating future OSGi specifications. The goal behind this work area is to develop an implementation of the specification as the specification is being developed. This work area will allow others to more easily join in on the investigations for future OSGi implementations. To begin with this work area would be used to implement the next release of the OSGi Framework, but other future OSGi specifications could also be contributed. This will also allow Equinox to provide reference implementations to OSGi without effecting the current Eclipse release. We would only graduate the code out of the incubator once the OSGi specification has gone public/final and we can align it with a major Eclipse release. I would like to take a vote to approve the OSGi spec work area in the equinox incubator. Tom - Forwarded by Thomas Watson/Austin/IBM on 10/16/2007 03:45 PM - From: Thomas Watson/Austin/IBM To: equinox-dev@eclipse.org Date: 10/12/2007 01:34 PM Subject:OSGi R4.2 Stream The OSGi Alliance is busy working on the next release of the specification. The release of the next OSGi specification will be long after the Eclipse 3.4 (Ganymede) release. To achieve a stable Ganymede release we will not release new OSGi R4.2 API or implement new R4.2 functions in the Ganymede stream (HEAD). We need a place where we can continue to implement and prototype the next OSGi specification release as it is being developed. I see two options. 1) Create an area in the Equinox incubator to develop the OSGi R4.2 implementation 2) Create a branch off of the current Ganymede stream (HEAD) for OSGi R4.2 implementation I prefer using a branch instead of a separate repository project in the incubator because it will make life easier when developing streams in parallel, which we will likely need to do until the Ganymede release in June 2008. I plan to create a branch based of next weeks I-Build for the OSGi R4.2 work. Please let me know if you have any issues with this. Tom <>___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 205622. Add -XX:PermGen to eclipse.ini for Mac OS X (FIXED) + Bug 205922. [app] ApplicationAdminTest failing on RHEL4U4, SUN 1.5.0 (ASSIGNED) + Bug 206614. [launcher] Cannot start I20071016-1215 on OS X (FIXED) + Bug 206813. Eclipse startup error should not be posted if we can detect that the bundle version is already installed (FIXED) + Bug 207016. Add p2 as friend of osgi verifier (FIXED) The following projects have changed: org.eclipse.equinox.launcher org.eclipse.equinox.executable org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Proposal for an OSGi spec work area in the equinox incubator
The "OSGi Next" work area http://www.eclipse.org/equinox/incubator/osgi-next/ has been created. To begin the work on the Framework I have populated the current I-Build (v20071022) of org.eclipse.osgi into the osgi-next work area in CVS (equinox-incubator/osgi-next/org.eclipse.osgi) Tom From: Thomas Watson/Austin/[EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 10/16/2007 04:23 PM Subject:[equinox-dev] Proposal for an OSGi spec work area in the equinox incubator I would like to start a new work area in the Equinox incubator to support prototyping and investigating future OSGi specifications. The goal behind this work area is to develop an implementation of the specification as the specification is being developed. This work area will allow others to more easily join in on the investigations for future OSGi implementations. To begin with this work area would be used to implement the next release of the OSGi Framework, but other future OSGi specifications could also be contributed. This will also allow Equinox to provide reference implementations to OSGi without effecting the current Eclipse release. We would only graduate the code out of the incubator once the OSGi specification has gone public/final and we can align it with a major Eclipse release. I would like to take a vote to approve the OSGi spec work area in the equinox incubator. Tom - Forwarded by Thomas Watson/Austin/IBM on 10/16/2007 03:45 PM - From: Thomas Watson/Austin/IBM To: equinox-dev@eclipse.org Date: 10/12/2007 01:34 PM Subject:OSGi R4.2 Stream The OSGi Alliance is busy working on the next release of the specification. The release of the next OSGi specification will be long after the Eclipse 3.4 (Ganymede) release. To achieve a stable Ganymede release we will not release new OSGi R4.2 API or implement new R4.2 functions in the Ganymede stream (HEAD). We need a place where we can continue to implement and prototype the next OSGi specification release as it is being developed. I see two options. 1) Create an area in the Equinox incubator to develop the OSGi R4.2 implementation 2) Create a branch off of the current Ganymede stream (HEAD) for OSGi R4.2 implementation I prefer using a branch instead of a separate repository project in the incubator because it will make life easier when developing streams in parallel, which we will likely need to do until the Ganymede release in June 2008. I plan to create a branch based of next weeks I-Build for the OSGi R4.2 work. Please let me know if you have any issues with this. 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 projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 206649. Missing .qualifier for s390 launcher fragments (FIXED) + Bug 207087. [Launcher] Launcher needed for HP-UX IA64_32 (FIXED) + Bug 207215. Regression since 3.4M1 in performance test StatePerformanceTest#testResolution1000() (FIXED) + Bug 207360. [sec] graduate BundleDescription enable/disable concept (FIXED) + Bug 207515. AbstractBundle and BundleDescriptionImpl have incorrect getKeyHashCode impls (FIXED) The following projects have changed: org.eclipse.equinox.launcher org.eclipse.equinox.launcher.gtk.linux.s390x org.eclipse.equinox.executable org.eclipse.equinox.launcher.gtk.linux.s390 org.eclipse.equinox.supplement org.eclipse.equinox.event 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] Tagged org.eclipse.osgi for next 3.4 M3 build
The map file has been updated for the following Bug changes: + Bug 208313. Bundle-NativeCode header could cause ClassCastException in PDE-Build (FIXED) The following projects have changed: org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [sec] questions about EE for security
Both John and Rem are correct. Bundles which want to run on a smaller EE than J2SE-1.4 and have access to the javax.security.auth packages should use import-package (e.g. Import-Package: javax.security.auth). You should not make J2SE-1.4 your required EE only because other bundles you depend on use the EE. Equinox is a broad community. A large number of our bundles do run on Foundation 1.1/1.0 (and even down to the minimum OSGi EE). But there are some extra features which require higher EEs. Currently parts of the security work in the incubator can only run on J2SE-1.4 or higher. For example, the core extension bundles (org.eclipse.equinox.security.boot.jre14x or org.eclipse.equinox.security.boot.jre15x) are installed into the extension classloader of the VM. This is required because we need to make the our security provider available to the VM and it will only search for providers on the boot classpath or the extension class loader. Unfortunately at that level the code will only have access to classes that are provided by the EE. They do not have the option to import additional packages which may come from other bundles installed in a Framework running on Foundation 1.1 EE. I opened a couple of bugs against the security bundles. All Equinox bundles should use Import-Package to access packages outside the java.* namespace. We could also split some of the bundles to allow parts of it to run on a Foundation EE. https://bugs.eclipse.org/bugs/show_bug.cgi?id=208399 https://bugs.eclipse.org/bugs/show_bug.cgi?id=208400 Tom From: John Arthorne <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 10/31/2007 09:30 PM Subject:Re: [equinox-dev] [sec] questions about EE for security I think the right approach is to set your bundle's EE to reflect the EE dependencies of *your* bundle, and not the bundles you depend on. I.e., if your bundle doesn't directly depend on 1.4, you could still specify an EE of Foundation 1.1 for your bundle. If it turns out that the JAAS bundle requires 1.4, then your bundle will transitively fail to resolve anyway. That way you're not building assumptions into your bundle about the EE of downstream bundles that may change in the future. John Scott Lewis <[EMAIL PROTECTED]> Sent by: To [EMAIL PROTECTED]Equinox development mailing list cc 10/31/2007 05:53 PM Subject [equinox-dev] [sec] questions Please respond to about EE for security Equinox development mailing list Hi Folks, Some questions: I thought I understood (from Equinox Summit) that the recently approved minimum EE for Equinox 3.4 (Ganymede) was CDC 1.1/Foundation 1.1. I see from looking at the equinox JAAS integration bundles (e.g. org.eclipse.equinox.security.auth) that the runtime environment minimum for those bundles is set to JRE 1.4. I understand this, as the JAAS work depends upon packages like javax.security.auth, and javax.security.auth.login, etc. which do not seem to be in CDC 1.1/Foundation 1.1. So maybe I just answered my own question: it seems that the JAAS security bundles/plugins must assume JRE 1.4 (and can't/won't run on CDC 1.1/Foundation 1.1). So the implicit (to me anyway) idea here is that bundles that use/extend/depend upon the JAAS security integration also obviously must assume JRE 1.4 and not just CDC 1.1. Correct? Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ e
Re: [equinox-dev] ConcurrentModificationException in DS implementation
Equinox has retired the old DS implementation in favor of the prosyst implementation. The old implementation never officially made it out of "incubator" status. Our plan is to graduate the DS implementation contributed by Prosyst in 3.4. To be clear, the new DS implementation contributed by Prosyst is now *the* Equinox DS implementation. Can someone from the Prosyst team go through the existing bug reports against the old DS implementation and confirm they cannot be reproduced on the new DS implementation. All of these bugs should be closed as worksforme if they are not reproduced on the new DS implementation. Tom From: Lukasz Bobowiec <[EMAIL PROTECTED]> To: equinox-dev@eclipse.org Date: 11/05/2007 04:15 AM Subject:[equinox-dev] ConcurrentModificationException in DS implementation Hello, I encountered an issue related to the lack of thread-safe in Declarative Service resolver. I found the similar bug 164574 https://bugs.eclipse.org/bugs/show_bug.cgi?id=164574 There is also a patch already provided by the bug's originator. My question is why this defect is still in NEW state and why this patch was not applied to DS implementation (I am talking about Equinox DS implementation not ProSyst). The last exposed on Equinox download site ds jar is: org.eclipse.equinox.ds_1.0.0.v20070226.jar but this patch was provided later? However it is not applied to any official Equinox version. The patch is available: https://bugs.eclipse.org/bugs/show_bug.cgi?id=181858 What is the Equinox's decision? --- Best regards, Lukasz Bobowiec Software Engineer, Common Agent Services [EMAIL PROTECTED] (+48 12) 628 9882 IBM SWG Lab, Cracow, Poland IBM Polska Sp. z o.o. oddział w Krakowie ul. Armii Krajowej 18 30 -150 Kraków NIP: 526-030-07-24 Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy KRS KRS 012941, Kapitał zakładowy: 3.073.600 PLN ___ 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 projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 194943. Europa Crashes During Startup (ASSIGNED) + Bug 198598. multi-user installs not working in Redhat 4 (FIXED) + Bug 207599. java.io.IOException: Could not save file table (FIXED) + Bug 208202. NullPointerException in thread "State Saver" during shutdown of osgi (FIXED) The following projects have changed: org.eclipse.equinox.supplement org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Proposal: declarative event notification mechanism
Sorry Oleg, we have been awfully silent to your idea. I think it is an interesting idea but I am wary of inventing another event model in Equinox. I would be in favor of investigating an enhancement to EventAdmin to allow declarative listeners (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=184021#c8) but I have the following reservations: 1) Theoretically things like a ds service component which is "immediate" could be used in conjunction with the lazy-activation model to eliminate the need to eagerly activate bundles which declare EventHandler service components. The problem with this approach is that none of the ds implementations currently understand how to handle lazy-activated bundles and will not recognize service components until a bundle is in the ACTIVE state. We did a bunch of work in OSGi R4.1 to standardize the lazy-activation policy, but the effort has not followed through the DS or Spring. It would likely take a non-trivial amount of work to enhance DS or Spring to handle lazy-activated bundles the way we want. In the end what we want is very similar to the use of http.registry to declare servlets/resources for the HttpService. A similar approach could be used in the implementation of EventAdmin and likely would not be too hard. 2) EventAdmin is very generic, which I think is a good thing. I would prefer to use the API as-is instead of somehow mapping any existing listener APIs we have in Eclipse onto the EventAdmin model or inventing yet another generic event API. EventHandlers in EventAdmin are passed objects of type Event. At a core level do you think this is good enough for the event needs in Eclipse? For example, in the extension registry we have IRegistryChangeEvent and IRegistryChangeListener. In the future would we be able to have clients implement EventHandler which are fired Event objects instead for registry change events? Currently I think the Eqinox EventAdmin implementation is pretty good, but likely could use some improvement. In particular for delivering async events. Currently EventAdmin uses the same code as the Framework for delivering events. This common code currently only supports a single thread for delivering async events. This means all async events are fired from the same "event bus" in EventAdmin. It would be interesting to see if we can expand this to a thread pool which allows different event topics to be fired from different threads in the pool. This would allow two disparate topic events to be fired in parallel from different async event threads. I'm not sure if this would violate the event admin spec though. Bottom line, I think this is a fine idea for Eclipse 4.0 but it is likely not something we can focus on in 3.4 time frame. Tom From: Oleg Besedin <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 11/02/2007 02:39 PM Subject:[equinox-dev] Proposal: declarative event notification mechanism While discussing some ongoing work, Pascal came up with a very interesting idea: why won't we create a generic mechanism for "declarative" registration of listeners? The proposed event notification mechanism would be: based on the "whiteboard" pattern [1], plus a declarative way to register listeners, plus ideas and implementation pieces from OSGi's EventAdmin [2]. To me, this sounds like a great idea. Listeners are ubiquitous and so are the problems associated with their life cycle. Details In theory, OSGi's EventAdmin service should help work with listeners. Implementations details aside (it is not in the SDK and needs to be tested for scalability), it suffers from the same problem as OSGi services in general: a listener's bundle has to be started and needs to register listener with OSGi. This creates startup order problems and works against lazy activation of bundles. For OSGi services add-on pieces that allow declarative registration of services (Declarative Servieces, SPring, This startup problem sounds similar to the OSGi services registration problem for which we are star
Re: [equinox-dev] Start level and framework timestamps
By framework timestamp I assume you mean the one returned by the resolver/state API State.getTimeStamp(). The resolver/state does not care or know about the start-level information. The bundle start-level does not effect the resolution status of the State therefore it is not reflected in the timestamp of a State object. This type data is stored separately (in the .bundledata file) from the resolver/state cache. We do not currently expose any kind of timestamp on the persistent data stored in this file. There are two types of intial start levels 1) The default bundle initial bundle start level. This is the default start-level used when a bundle is first installed into the framework. This value is persisted in the .bundledata file 2) The initial start-level used to launch the framework. This is not persisted and can be different each launch of the framework. It is also up to the framework how you specify the intial start-level of the framework when launching. Tom From: Pascal Rapicault <[EMAIL PROTECTED]> To: equinox-dev@eclipse.org Date: 11/12/2007 09:10 AM Subject:[equinox-dev] Start level and framework timestamps Hi, When at runtime the start level of a bundle is changed is that reflected in a framework timestamp? Likewise is the change of initial start level captured anywhere? 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] Equinox projects tagged for 3.4 I-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 (ASSIGNED) + Bug 202278. [eventadmin] Remove event adapters (FIXED) + Bug 205832. [Launcher] Publish the path to the native launcher (FIXED) + Bug 205990. [launcher] Invalid JVM options are silently ignored (ASSIGNED) + Bug 206936. [registry] Improving registry notification mechanism (FIXED) + Bug 208479. [launcher] Wrong vendor identified for vm on windows (MaxPermSize) (NEW) + Bug 209055. [Launcher] exclude launcher fragments from individual source bundles (FIXED) + Bug 209080. [launcher] Running with --launcher.suppressErrors hides all error messages (FIXED) + Bug 209293. [useradmin] need an event adapter (FIXED) + Bug 209478. [launcher] RCP product export for solaris motif sparc executable missing (FIXED) The following projects have changed: org.eclipse.equinox.launcher.gtk.linux.s390x org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.launcher.gtk.linux.s390 org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.osgi org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.launcher.motif.hpux.ia64_32 org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.launcher.motif.hpux.PA_RISC org.eclipse.equinox.launcher org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.executable org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.registry org.eclipse.equinox.useradmin org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.launcher.gtk.linux.x86 org.eclipse.equinox.event Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] naming examples
I agree with John. Use org.eclipse.equinox.examples.* Tom From: John Arthorne <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 11/21/2007 07:51 AM Subject:Re: [equinox-dev] naming examples My vote would be for sticking with the Eclipse project naming conventions [1] and using org.eclipse.equinox.examples.*. This convention is consistently following in platform and JDT, and it would look odd if someone downloaded the examples from the welcome page and the Equinox examples didn't match. [1] - http://wiki.eclipse.org/Naming_Conventions Jeff McAffer/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To [EMAIL PROTECTED] 11/20/2007 09:26 PM se.org cc Please respond to Subject Equinox development mailing list [equinox-dev] naming examples We have talked a few times about the need for a comprehensive set of examples in Equinox. We may be able to get some folks to work on this so it is interesting to look at the bundle/package namespace to use. The immediate choice that springs to mind is org.eclipse.equinox.examples.* This follows the precedence of org.eclipse.sdk.examples org.eclipse.jface.examples It has also been suggested that we use org.eclipse.equionox.eg.* to shorten things up. Let me know if you have other suggestions and I'll put together an email poll. Thanks Jeff___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev <><>___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] ContextFinder stops at first bundle class loader
The ContextFinder is designed to simply convert context classloader delegations into simple Class.forName calls. Then we can use standard OSGi delegation to find the classes which are trying to be loaded (i.e through Import-Package, Require-Bundle, etc). Unfortunately standard OSGi delegation does not really help for 3rd party libraries which are accustomed to using the context classloader to load things which are not known at development time (which means you cannot use any standard OSGi constraints like Import-Package). You have a couple of options. 1) use DynamicImport-Package: * 2) use Equinox buddy classloading. I try to avoid DynamicImport-Package as much as possible because it has several drawbacks (like risk of replacing any of your private classes including your bundle activator from other exporters!!). Instead you should try using the buddy classloading mechanism. Adding the following header should give you the behavior you are looking for: Eclipse-BuddyPolicy: dependent HTH. Tom From: Gunnar Wagenknecht <[EMAIL PROTECTED]> To: equinox-dev@eclipse.org Date: 11/25/2007 11:04 AM Subject:[equinox-dev] ContextFinder stops at first bundle class loader Hi, Is there a specific reason why the ContextFinder stops at the first bundle class loader? I'm trying to integrate an existing framework into the SSE world. During de-serialization it wants to load classes and the ContextFinder would be really helpful here but it stops at the first bundle class loader which prevents a good bundle architecture. Example: * ConcreteServlet definied in mybundle * ConcreteServlet extends BaseServlet * BaseServlet defined in frameworkbundle * mybundle imports package for BaseServlet from frameworkbundle * BaseServlet#decode(Request) calls code in frameworkbundle which uses context class loader which triggers ContextFinder to load classes (defined in mybundle) * ContextFinder stops at frameworkbundle's class loader but frameworkbundle does not see classes in mybundle. If ContextFinder would simply look further and try additional bundle class loaders up in the stack it would eventually get to mybundle's class loader and everything would work. Is there a specific reason for this design? I could imagine that there could by some circularity or other problems. But if there was no specific reason I wonder if I should open an enhancement request for ContextFinder? -Gunnar -- Gunnar Wagenknecht [EMAIL PROTECTED] http://wagenknecht.org/ ___ 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: ContextFinder stops at first bundle class loader
> I know about buddy class loading. But I want to avoid it. If the context > finder would look further up the stack and not abort on the first bundle > class loader it finds things would actually work without buddy class > loading. I was just wondering if the context finder could be (or should > not be) enhanced to support this. > > -Gunnar The design of ContextFinder is to be policy free. The policy comes from the OSGi delegation model + the Equinox buddy policy. We should avoid building such a policy into the ContextFinder. It is inevitable that there are scenarios where a built in policy would not work. The policy should be specified by the bundle (e.g. DynamicImport-Package, Eclipse-BuddyPolicy etc.) and not kept in a global ContextFinder TCCL. Tom.___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] ContextFinder stops at first bundle class loader
[EMAIL PROTECTED] wrote on 11/26/2007 10:52:30 AM: > How do buddy classloading and DynamicImport-Package compare with > regards to performance ? > I've had very bad experiences performance-wise with buddy classloading > and a global policy... There is an existing bug about buddy classloading performance https://bugs.eclipse.org/bugs/show_bug.cgi?id=152006 This bug is about performance where there are a large number of bundles for the "registered" buddy policy. The "global" buddy policy can be expensive because we must search the "global" set of packages for the package where the requested class is from. We could optimize this to be faster but I really hope the "global" policy is rarely used. If you have a strong usecase for using the "global" policy and are seeing bad performance then please open a bug report so we can consider improving it. DynamicImport-Package does have a performance hit also, but it is only a one time hit when trying to establish a wire. Once the wire is established we no longer have to try and resolve the import on the next class request from the same package. This is one of the differences between dynamic import and buddy classloading. Dynamic imports are statically bound a package wire once they are established. In buddy loading a wire is not kept, the search for a buddy is done each class/resource load. Tom. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox tagged for the I-Build
The map file has been updated for the following Bug changes: + Bug 206938. [Extension Registry] request a way to find current Contributors (FIXED) + Bug 209577. Extension Registry problems with invalid XML format (FIXED) + Bug 210085. Please add support for Win64 on Itanium (FIXED) The following projects have changed: org.eclipse.equinox.launcher org.eclipse.equinox.executable org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.registry Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Declarative Services with RCP Plug-in Extensions
[EMAIL PROTECTED] wrote on 11/27/2007 06:19:11 PM: > Hello. > > I need some tips in narrowing down the cause of a problem We've been > having in our RCP/OSGi application. > > Our project is using Declarative Services to manage several bundles > of services, and Eclipse Plug-in Extensions for various RCP components. > Everything seems to be running ok, but I'm having trouble with one > thing: getting the OSGi framework and all of the bundles to shut > down when the user closes the RCP Application window. > > First, a few questions: > - > > I read articles like http://www.eclipsezone.com/articles/extensions- > vs-services/ and start to worry if our use of both DS and RCP plug- > ins is somehow fundamentally problematic. There is a lot of > functional overlap, but do these two approaches ever conflict? Is > there a standard way to get them to work together to close down when > the application is done? > > Is it remotely possible that the org.eclipse.equinox.ds resolver's > ConcurrentModificationException during the startup of an OSGi > framework could have anything to do with preventing the entire OSGi > framework from shutting down automatically after the RCP Applicationis closed? Which DS implementation are you using? The latest version of DS on the Equinox download page should fix the thread safety issues. The latest DS implementation is provided by Prosyst and has many improvements over our old Equinox implementation of DS. > > Eclipse automatically seems to understand that we want the framework > to shut down when the application closes, but when we take our jars > out into the real world, the framework doesn't stop. I suppose this > is understandable, since we tell OSGi to start the applications and > to start the bundles and services. How do we tell OSGi that they are > linked, and must be shut down when the Application closes? By default the framework should be shutdown by EclipseStarter once your application has ended. This should cause all your bundles to be stopped automatically. I suspect you are having issues with non-daemon threads still being active. When shutting down we never call System.exit, we assume that all non-daemon threads will be stopped by the shutdown process. This is what Alex was describing in his response. If you use the launcher org.eclipse.equinox.launcher it does actually exit with System.exit as long as you don't use -noexit option. See the quick start guide for instructions on using the launcher. http://www.eclipse.org/equinox/documents/quickstart.php > > About our configuration: > -- > The framework is started up with the following command: > java -cp . -jar org.eclipse.osgi_3.3.0.v20070530.jar -console > > config.ini is as follows > -- > eclipse.ignoreApp=false > osgi.noShutdown=false > > osgi.bundles= \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED], \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > org.eclipse.swt.win32.win32.x86, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [EMAIL PROTECTED]:start, \ > [All of our bundles follow at run level 4] > You should not have to start every bundle here. You should only have to start equinox.common, core.runtime and update.configurator and any bundles which need to be activated because they publish OSGi services (this includes DS, event, log etc.). Something like this should work: osgi.bundles= \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [All of your bundles that publish OSGi services] In this case update.configurator should ensure all your other bundles get installed before core.runtime is started. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] org.eclipse.equinox.util bundle
[EMAIL PROTECTED] wrote on 11/30/2007 08:08:22 AM: > Hi all, > > For the org.eclipse.equinox.util bundle: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151 > I have some comments/questions. > > > 1. Can I change the name to the "org.eclipse.equinox.internal.util" > and kept here only the classes that are needed for more than one bundle? There is no precedence for doing this in Eclipse. But it does make some sense to me. This would make it obvious that the whole bundle is really just an internal implementation detail. What do others think? > > 2. Still we will keep the bundle in the equinox distribution or we will > move the classes to the org.eclipse.equinox.common.jar in the future? For now I think we should make all the packages internal and use x-friends where appropriate for the other service bundles. In the future it is possible that we could move the packages to common and make them real API with no "internal" name in the package. But we will not do that unless the gain is substantial (i.e. needed by a large set of clients in the Eclipse community). > > Next week I will work on removing dependencies and some packages from > the util bundle but I need decision about the packaging and naming > prior finishing the work. > > > -Pavlin Thanks Pavlin. For now you should move the packages out of the equinox.util into other bundles where appropriate and rename the remaining packages to include "internal" in the name with x-friends for the bundles that need the package. A final decision on the symbolic name of the util bundle can be made after the package restructuring. Tom. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for 3.4 I-Build
The map file has been updated for the following Bug changes: + Bug 44735. Unable to create platform lock file (ASSIGNED) + Bug 179619. Request for friendship: org.eclipse.core.filesystem (FIXED) + Bug 188304. Execution environment restricts access to org.w3c.dom sub packages (ASSIGNED) + Bug 207505. [registry] order in which registry events are sent vs. bundle dependencies (FIXED) + Bug 207847. Warnings in the log file when nl fragments for osgi bundles are present. (FIXED) + Bug 209344. [log] need an event adapter (FIXED) + Bug 209694. Equinox webstart launcher ignores interactive login splash handler (NEW) + Bug 210384. console is blocking in 3.3.1 (ASSIGNED) + Bug 210699. Moving AdapterFactory into the registry bundle (FIXED) + Bug 211289. osgi.services and osgi.util source bundles are broken (FIXED) + Bug 211295. equinox launcher source bundle is missing about.html (FIXED) + Bug 211823. HttpContextManager ArrayIndexOutOfBoundsException (ASSIGNED) The following projects have changed: org.eclipse.equinox.launcher.motif.hpux.ia64_32 org.eclipse.equinox.launcher org.eclipse.equinox.log org.eclipse.osgi.services org.eclipse.equinox.executable org.eclipse.osgi.util org.eclipse.equinox.registry org.eclipse.equinox.supplement org.eclipse.equinox.common org.eclipse.equinox.http.registry org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: Re[2]: [equinox-dev] org.eclipse.equinox.util bundle
At this point the packages should be renamed to have "internal" in the
package name. In the future we can look at moving the packages to true API
packages.
Tom
From: Pavlin Dobrev <[EMAIL PROTECTED]>
To: Equinox development mailing list
Date: 12/03/2007 03:34 AM
Subject:Re[2]: [equinox-dev] org.eclipse.equinox.util bundle
Hi Jeff,
Should I rename org.eclipse.equinox.util packages to
org.eclipse.equinox.internal.util or not. Some of the packages are used
only by DS bundle in equinox distribution. Others are used for more than
one bundle.
The nature of the packages used only from DS bundles are utilities - like
thread pool, xml processing, io, common utilities for access to the
framework structures etc.
In our FW implementation such utilities are packaged in one bundle putil
http://dz.prosyst.com/user-manuals/mBS_Equinox_Edition_2.0.0
/framework/bundles/prosyst/system/putilfull/introduction.html similar to
equinox.common bundle (license of PUTIL is EPL and the code is distributed
with mBS Equinox Eddition). We want after including the code in Equinox to
move our code to use donated one in order not to have duplication of the
code. It will be strange other bundle to have a dependency with DS only
for utility classes.
Now I work to remove as many as possible dependencies from util bundle but
in some cases this will decrease performance (removing of thread pool) and
increase used memory (remove usage of object pools). Do you think that
this is the right way?
-Pavlin
>
Interesting. This is a friend (no pun intended) of the problem raised
recently on the PMC mailing list. The idea
of having whole bundles as "internal". By default I suppose that if a
bundle only ever exports x-internal := true
things then there is nothing interesting for anyone to depend on the bundle
for so there is no real need to depend
on the bundle at all and the idea of marking the bundle "internal" does not
matter.
I am bummed by having another bundle that we have to ship and manage etc
but if the code really is shared and
used/useful across many bundles than having it actually shared is a good
thing.
Jeff
Thomas Watson <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/30/2007 05:43 PM
Please respond to
Equinox development mailing list
To
Equinox
development mailing list
cc
Subject
Re: [equinox-dev] Configuration Admin bug
This has already been fixed in the latest version of CM. Can you try the latest build at http://download.eclipse.org/eclipse/equinox/drops/I20071204-1547/download.php?dropFile=org.eclipse.equinox.cm_1.0.0.v20071203.jar Tom From: "Laidlaw, Don" <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 12/06/2007 11:32 AM Subject:[equinox-dev] Configuration Admin bug In org.eclipse.equinox.cm.internal.ConfigurationAdminFactory at line 812. The line: if (!config.getBundleLocation().equals(bundle.getLocation())) The config.getBundleLocation() can sometimes return null. This is especially true in a new factory configuration created by an admin bundle with a null location. So in this case it will throw NPE. The workaround is to always provide a location, but this is not required by the spec, and in fact you may want to create the configuration before the bundle is installed. Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile: 416-543-1085 | [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] Configuration Admin bug
Could you please reopen bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=212168 And provide the stacktrace log using the latest version of the code and a testcase to reproduce. Thanks. Tom From: "Laidlaw, Don" <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 12/06/2007 01:10 PM Subject:Re: [equinox-dev] Configuration Admin bug Yes, the problem still seems to be there in that version. -Don On 12/6/07 1:05 PM, "Thomas Watson" <[EMAIL PROTECTED]> wrote: This has already been fixed in the latest version of CM. Can you try the latest build at http://download.eclipse.org/eclipse/equinox/drops/I20071204-1547/download.php?dropFile=org.eclipse.equinox.cm_1.0.0.v20071203.jar Tom "Laidlaw, Don" ---12/06/2007 11:32:36 AM---In org.eclipse.equinox.cm.internal.ConfigurationAdminFactory at line 812. From: "Laidlaw, Don" <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 12/06/2007 11:32 AM Subject: [equinox-dev] Configuration Admin bug In org.eclipse.equinox.cm.internal.ConfigurationAdminFactory at line 812. The line: if (!config.getBundleLocation().equals(bundle.getLocation())) The config.getBundleLocation() can sometimes return null. This is especially true in a new factory configuration created by an admin bundle with a null location. So in this case it will throw NPE. The workaround is to always provide a location, but this is not required by the spec, and in fact you may want to create the configuration before the bundle is installed. Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile: 416-543-1085 | [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 Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile: 416-543-1085 | [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] Configuration Admin bug
Another issue here is how bundles are updated to new versions. The CM implementation uses the BundleContext.getDataFile method to obtain a location to persistently store its data. This data area is unique to the Bundle ID (long value). When a bundle is updated (using Bundle.update method) the updated content of the bundle uses the same ID and therefore can obtain the same data file location as the previous version of the bundle. Some management agents (*cough* old Eclipse Update and p2) update bundles by first uninstalling the old version and installing a new version. This means the new version of the bundle will have a different location and a different Bundle ID. This has two implications on CM. First of all, it will cause the all persistent data from the old version of CM to be lost for the new version of CM. Second, since bundle locations change (locations are used to bind CM configurations) the existing bindings will be reset for bundles that are updated to new versions. Tom From: Simon Kaegi <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 12/07/2007 09:51 AM Subject:Re: [equinox-dev] Configuration Admin bug Glad it's working now... You're point about compatability of the store data is really interesting (I think so at least). In terms of technical details as part of the graduation work we switched from using regular files to the frameworks ReliableFile infrastructure. This does change the layout on disk and so is not backwards compatible with the original File approach. As you mention this change will not work when "updating" your bundle from the earlier approach. Once the component graduates I would expect this storage format to be relatively stable. In terms of a real long term solution I thinks it's inevitable that we're going to run into "incompatible" bundle data in the CM bundle and others and in these cases we perhaps should look at using provisioning infrastructure. Deployment Admin had the notion of "Customizers" to handle these sorts of changes and this sort of thing is definitely in scope for p2. -Simon [EMAIL PROTECTED] wrote on 12/06/2007 04:27:40 PM: > > Oops, I made a mistake in the last run. I did not notice that there were two > cm bundles loaded and I was continuing to bind to the other one. > > The new cm bundle provided by Thomas does not have the problem. > > But I did notice one thing. When I changes the bundle for cm to the new > bundle, the old configurations that were stored were no longer visible. Is > that the behaviour you would expect? If so, that is a bad thing. At least it > is bad for us. We would need to ensure the configs get preserved across > updates to cm. If cm is completely replaced by a different implementation, > then of course you cannot expect the configs to be preserved. > > Thanks! > -Don > > On 12/6/07 2:28 PM, "Simon Kaegi" <[EMAIL PROTECTED]> wrote: > > > Don, > > > > Could you provide a more detailed test case. > > The code specifically checks for a null BundleLocation so I suspect you're > > getting an NPE for another reason. > > > > The code has been significantly refactored so that the relevant check I > > think you're referring to is now in > > org.eclipse.equinox.internl.cm.ConfigAdminImpl line 48. > > > > if (config.getBundleLocation() != null && > > !config.getBundleLocation().equals(bundle.getLocation())) > > > > Could you verify that this is still the NPE cause and if not it would be > > great to know where it's coming from. > > > > Thanks. > > -Simon > > > > [EMAIL PROTECTED] wrote on 12/06/2007 02:08:52 PM: > > > >> > >> Yes, the problem still seems to be there in that version. > >> > >> -Don > >> > >> > >> On 12/6/07 1:05 PM, "Thomas Watson" <[EMAIL PROTECTED]> wrote: > > > >> This has already been fixed in the latest version of CM. Can you > >> try the latest build at > >> > >> http://download.eclipse. > >> org/eclipse/equinox/drops/I20071204-1547/download.php?dropFile=org. > >> eclipse.equinox.cm_1.0.0.v20071203.jar > >> > >> Tom > >> > >> > >> > >> [image remo
Re: [equinox-dev] Configuration Admin bug
I'm not sure I understand this ...
Simple configurator has two lists 1) a list of bundles it thinks need to be
uninstalled 2) a list of bundles it thinks it need to be installed.
Right now the configurator uninstalls all the bundles in uninstallList and
then installs all the bundles in installList, but couldn't something like
the following be used instead.
for (each bundle in uninstallList) {
if (another version of bundle exists in installList) {
update(bundle with installList bundle content)
remove installList bundle from installList
}
else
uninstall(bundle)
}
for (each bundle in installList) {
install(bundle)
}
Where this breaks down is if you want to have "meaningful" bundle locations
(returned by Bundle.getLocation()) that somehow point to the actual
location on disk. When using Bundle.update() this location String remains
constant, just like the Bundle ID.
Tom
From: Pascal Rapicault <[EMAIL PROTECTED]>
To: Equinox development mailing list
Date: 12/07/2007 10:44 AM
Subject:Re: [equinox-dev] Configuration Admin bug
In fact I don't know of any management agent capable of calling update in
the way a user could do on the command line since the definition of update
support updating any bundle into any other...
In p2 we have explored solutions to this problem and were able to come up
with a solution for the trivial cases (singleton bundles) however as soon
as more complex cases showed up it seemed like any guessing of what an
update would be looked completely random. Therefore we have decided not to
support that.
From: Thomas Watson <[EMAIL PROTECTED]>
To: Equinox development mailing list
Date: 12/07/2007 11:15 AM
Subject:Re: [equinox-dev] Configuration Admin bug
Another issue here is how bundles are updated to new versions. The CM
implementation uses the BundleContext.getDataFile method to obtain a
location to persistently store its data. This data area is unique to the
Bundle ID (long value). When a bundle is updated (using Bundle.update
method) the updated content of the bundle uses the same ID and therefore
can obtain the same data file location as the previous version of the
bundle.
Some management agents (*cough* old Eclipse Update and p2) update bundles
by first uninstalling the old version and installing a new version. This
means the new version of the bundle will have a different location and a
different Bundle ID. This has two implications on CM. First of all, it will
cause the all persistent data from the old version of CM to be lost for the
new version of CM. Second, since bundle locations change (locations are
used to bind CM configurations) the existing bindings will be reset for
bundles that are updated to new versions.
Tom
(Embedded image moved to file: pic23727.gif)Inactive hide details for Simon
Kaegi ---12/07/2007 09:51:37 AM---Glad it's working now...Simon Kaegi ---12
/07/2007 09:51:37 AM---Glad it's working now...
(Embedded image (Embedded image moved to file: pic06426.gif)
moved to file: Simon Kaegi <[EMAIL PROTECTED]>
pic02520.gif)
From:
(Embedded image (Embedded image moved to file: pic26419.gif)
moved to file: Equinox development mailing list
pic31119.gif)
To:
(Embedded image (Embedded image moved to file: pic09978.gif)
moved to file: 12/07/2007 09:51 AM
pic11633.gif)
Date:
(Embedded image (Embedded image moved to file: pic08718.gif)
moved to file: Re: [equinox-dev] Configuration Admin bug
pic25032.gif)
Subject:
Glad it's working now...
You're point about compatability of the store data is really interesting (I
think so at least).
In terms of technical details as part of the graduation work we switched
from using regular files to the frameworks ReliableFile infrastructure.
This does change the layout on disk and so is not backwards compatible with
the original File approach. As you mention this change will not work when
"updating" your bundle from the earlier approach. Once the component
graduates I would expect this storage format to be relatively stable.
In terms of a real long term solution I thinks it's inevitable that we're
going to run into "incompatible" bundle data in the CM bundle and others
and in these cases we perhaps should look at using provisioning
infrastructure.
Deployment Admin had the notion of "Customizers" to handle these sorts of
changes and this sort of thing is definitely i
Re: [equinox-dev] [prov] install / uninstall / update (was Configuration Admin bug)
[EMAIL PROTECTED] wrote on 12/07/2007 12:18:09 PM: > The bundle.getLocation() does not matter, but since so many systems are > used around that it is also problematic to not having meaningful. > > For clarification to the casual reader, simple configurator does not > explicitly have two lists. The lists of things to install and to uninstall > are actually derived by analysing what is in the system and what the system > should look like. > > Now for the corner cases (in each case the bundles.txt described lists all > the bundles): > > Example 1: > In the system: Let's say that I have junit 3.8.1 and junit 4.1 installed > (boths are singleton) > case 1) In the bundles.txt: I have junit 5.0 - Do I update the two bundles > ? Do I update the highest one or the lowest one, why? > case 2) In the bundles.txt I have junit 3.8.2 - Is it an update or a > donwgrade? > case 3) In the bundles.txt I have junit 3.8.4 and junit 4.0 - Which one is > really an update? > > > Example 2: > In the system: Let's say that I have foo 1.0.0 (it is singleton) > case 1) In the bundles.txt I have foo 1.1 and foo 1.2 (these are no longer > singleton) - Which bundle do I pick to be an update of the one present? > > > Example 3: > In the system: Let's say that I have bar 1.0.0 and bar 2.0.0 (both are non > singleton) > case 1) In the bundles.txt I have bar 1.5 (singleton). - Which one do you > update? Why? We may be able to rationalize some policy for the above cases but since this is a "simple" configurator that is likely out of the question because it will get complicated fast ;-) So I punt on this and say if multiple versions of the same bundle are in the scenario then just do the uninstall(old) install(new) versions approach. In most cases where multiple versions are needed the bundle is not a singleton and is just a library. In this case it should not matter if you uninstall/install the bundle to be updated. In cases where the system should only have one version of the bundle installed it seems like you could use the update approach instead. > > The other problem with updates, is that given two systems starting from the > same initial state, if they are submitted to different bundles.txt over > time to finally get to the same one. Even though the resulting systems look > the same it is not clear that they will actually behave the same depending > on what the data file may contain. > Another one in that space is, someone starting fresh and someone applying a > bundles.txt over a system may not end up with the same runtime behavior (of > course bundles should all be written properly, etc but you know the > truth :-)) > > PaScaL Not sure what the answer is to this one. Bundles have bugs in them but should we throw away the update capability because some bundles cannot handle managing their persistent data correctly? I do not see how this is different from the other data bundles store in the configuration.area. Generally this type of data should be versioned so that when new versions are installed they can determine if they understand the data or not. This is also another option for the CM implementation. It could persist its data in the configuration.area. This area is not tied to the bundle ID or location. The drawback to this approach is that only one version of CM can manipulate this data. This is probably not an issue though since CM should probably be a singleton bundle anyway. This is essentially how the Eclipse preferences bundle persists its data. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox tagged for 3.4 M4 warm-up build.
The map file has been updated for the following Bug changes: + Bug 68922. [osgi] Comments of Main.java are outdated (FIXED) + Bug 68924. [osgi] Potential for NPE in Main.java (FIXED) + Bug 192295. Platform launcher does not keep properties in sync with command line options (FIXED) + Bug 195501. Advise callers not to use CoreException.getStatus() for logging (FIXED) + Bug 195809. eclipse_1017a.dll blocks heap sizes greater 1GB (FIXED) + Bug 208121. App model: listening on org.eclipse.equinox.app.applications (FIXED) + Bug 211891. gtk.solaris.x86 launcher (FIXED) + Bug 211904. [launcher] Running from outside current directory causes contents of .ini file to be ignored (FIXED) The following projects have changed: org.eclipse.equinox.launcher org.eclipse.equinox.executable org.eclipse.equinox.supplement org.eclipse.equinox.app org.eclipse.equinox.common org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] classLoader.getResources("META-INF/.resource")
You also posted this on the osgi mailing list. I'm posting my answer here
also for others ... but lets keep the general osgi questions on the osgi
mailing list.
With the current OSGi specification one way I can see doing this is to make
all bundles supplying META-INF/.resources a fragment bundle of the main
bundle using getResources(). This should make all resouces from the
fragments available to the host as if they were part of the host. The
problem with dynamic imports is you only get wired to a single exporter of
the resource and you do not really have much of a choice on which one you
get wired to. Although you could use some matching attributes to scope
down the list of possible supplies, but this still does not help you get
the resource from multiple suppliers.
If you are using Equinox you could use the buddy classloading mechanism.
Search Eclipse help for Eclipse-BuddyPolicy for more information.
There is ongoing discussions within OSGi for how to solve these types of
issues in a future version the specification, but that does not help you
now :)
Tom
From: [EMAIL PROTECTED]
To: equinox-dev@eclipse.org
Date: 12/16/2007 05:42 AM
Subject:[equinox-dev] classLoader.getResources("META-INF/.resource")
Hi,
I am little stuck with osgi while loading resources. My problem is to load
all "META-INF/.resource" resources from all exporting bundles in osgi
runtime. But classLoader.getResources("META-INF/.resource") returns empty
enumeration. Bundle where this is done is a legacy library converted to
Osgi plugin. Maximum I can do to legacy bundle is to change the manifest.
It does many Class.forName(), So i have put dynamic import as * there that
solves many class loading problem. All bundles that is having
META-INF/.resource is exporting META-INF package. There is also a bundle
that does not have .resource but exports META-INF for some other resource.
Unfortunately my legacy bundle gets wired to this bundle when when
getResources is done. Hence its returning empty enumeration. Had it been
wired to one of the .resource containing bundle atleast enumeration would
not been empty, though it would have returned only one.
I am kinda stuck, please help me.
-Rajesh
___
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 3.4 I-Build
The map file has been updated for the following Bug changes: + Bug 211745. [sec] Graduate signedcontent API and related services (ASSIGNED) + Bug 211904. [launcher] Running from outside current directory causes contents of .ini file to be ignored (FIXED) The following projects have changed: org.eclipse.equinox.executable org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API
Without tooling this will be difficult. If we wanted to use the big hammer approach the we would have the API tooling (or plain old PDE) mark exports without versions as a warning/error by default or update each project settings in eclipse to make it an error. Now the question is what version would all the well established packages use? Most eclipse packages do not specify a version which means they have been using the default version of 0.0.0. If a package is being versioned for the first time what should its version be? - Start off using 1.0.0 - Use the Bundle-Version I favor using the Bundle-Version for well established packages because if we decide to add versions to the maintenance streams then we have room to downgrade the versions as appropriate. Completely new packages in a release should start off with version 1.0. I have been trying to version the exports of org.eclipse.osgi for the past few releases. It is hard to keep track of without tooling. Just look at how many times we forget to increment the bundle versions in Eclipse and that is just one version number per bundle to maintain. Now we will have to maintain each package version individually which is a much bigger task. Hopefully more advanced API tooling could detect that the API package has changed since last release and needs to be incremented. Does the new API tooling currently do something like this for Bundle-Version? Tom From: Jeff McAffer <[EMAIL PROTECTED]> To: equinox-dev@eclipse.org Date: 01/11/2008 02:17 PM Subject:[equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API Tom raises a good point that we keep letting slide. Are we going to ensure that all export package statements have version numbers for 3.4? If we have API tooling for this then it would likely be reasonable to start doing. Even without tooling today, we could introduce version numbers based on the bundle version number for this release and then evolve from there (with tooling that will come in the future). Jeff - Forwarded by Jeff McAffer/Ottawa/IBM on 01/11/2008 01:22 PM - [EMAIL PROTECTED] rg To 01/11/2008 10:50 AM Jeff McAffer/Ottawa/[EMAIL PROTECTED] cc Subject [Bug 214801] [api tools] consider Export-Package as API https://bugs.eclipse.org/bugs/show_bug.cgi?id=214801 Product/Component: PDE / Incubators --- Comment #2 from Thomas Watson <[EMAIL PROTECTED]> 2008-01-11 10:50:13 -0400 --- I agree with the concept. All exported packages which are not marked x-internal:=true should be versioned. Without this it makes using Import-Package very limiting because you cannot specify what version of the package you require. Packages marked as x-friends are questionable, but I can see friend bundles depending on a particular friend package version. -- Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.___ 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] Fw: [Bug 214801] [api tools] consider Export-Package as API
I agree that tooling is needed in order to make this somewhat feasable.
On the OSGi mailing list there was a question posted about using EMF on
another framework implementation. One of the issues was that EMF uses
Require-Bundle on org.eclipse.core.runtime. This ends up pulling in lots
of dependencies, one of which is org.eclipse.osgi. This makes it
impossible to use EMF on another Framework impl. If EMF instead used
Import-Package to get its packages then it is conceivable that EMF could
have its dependancies resolved in another Framework impl. But using
Import-Package for the eclipse packages without versions is dangerous
because you do not know what you will get.
Eclipse team rarely uses Import-Package, this maybe because it is a bit
harder. But for now I would advise against it because it is dangerous
without versions. Until versions are established EMF should *not* move to
Import-Package IMO.
Tom
From: John Arthorne <[EMAIL PROTECTED]>
To: Equinox development mailing list
Date: 01/11/2008 03:27 PM
Subject:Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider
Export-Packageas API
I don't think we can even contemplate this without full tooling automation.
As Tom says, we struggle to keep our bundle version numbers correct as it
is. We can maintain package versions manually up to a point, such as base
framework packages and service packages, but any wider scope would become
unmanageable. For most of the wider Eclipse team that rarely/never uses
import package, there is no immediate need to version at the package level.
Thomas Watson
<[EMAIL PROTECTED]>
Sent by: To
[EMAIL PROTECTED]Equinox development mailing list
rg
cc
01/11/2008 03:45 PM Subject
Re: [equinox-dev] Fw: [Bug 214801]
[api tools] consider
Please respond to Export-Packageas API
Equinox development mailing
list
Without tooling this will be difficult. If we wanted to use the big hammer
approach the we would have the API tooling (or plain old PDE) mark exports
without versions as a warning/error by default or update each project
settings in eclipse to make it an error. Now the question is what version
would all the well established packages use? Most eclipse packages do not
specify a version which means they have been using the default version of
0.0.0. If a package is being versioned for the first time what should its
version be?
- Start off using 1.0.0
- Use the Bundle-Version
I favor using the Bundle-Version for well established packages because if
we decide to add versions to the maintenance streams then we have room to
downgrade the versions as appropriate. Completely new packages in a release
should start off with version 1.0.
I have been trying to version the exports of org.eclipse.osgi for the past
few releases. It is hard to keep track of without tooling. Just look at how
many times we forget to increment the bundle versions in Eclipse and that
is just one version number per bundle to maintain. Now we will have to
maintain each package version individually which is a much bigger task.
Hopefully more advanced API tooling could detect that the API package has
changed since last release and needs to be incremented. Does the new API
tooling currently do something like this for Bundle-Version?
Tom
Inactive hide details for Jeff McAffer ---01/11/2008 02:17:11 PM---Tom
raises a good point that we keep letting slide. Are we gJeff McAffer ---01
/11/2008 02:17:11 PM---Tom raises a good point that we keep l
[equinox-dev] Equinox projects tagged for I-Build
The map file has been updated for the following Bug changes: + Bug 203999. NPE in WebStartMain.findBundle (FIXED) + Bug 209694. Equinox webstart launcher ignores interactive login splash handler (FIXED) + Bug 211904. [launcher] Running from outside current directory causes contents of .ini file to be ignored (FIXED) + Bug 212815. [launcher] resolve osgi.framework relative to osgi.install.area (FIXED) + Bug 214570. [JavaWebstart] NullpointerException at org.eclipse.equinox.launcher.Main.findMax(Main.java:871) (FIXED) + Bug 214760. Uninformative error message from AdapterFactoryProxy.loadFactory(..) (FIXED) + Bug 214929. org.eclipse.equinox.registry does not include schemas in source bundle (FIXED) The following projects have changed: org.eclipse.equinox.launcher.win32.win32.ia64 org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.launcher org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.executable org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.registry Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] equinox incubator projects tagged for the I-Build
The map file has been updated. The following projects have changed: org.eclipse.equinox.ds org.eclipse.equinox.util Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API
Darin, The bug report you refer to also mentions flagging when version ranges are missing from the consumers (Import-Package/Require-Bundle). Turning both the producer (Export-Package) and consumer (Import-Package/Require-Bundle) flags to "warning" at the same time will likely cause some issues when the producer has not yet added proper versions. Now consumers of the package will not be able to fix their own warnings until the producer is fixed because they will not have a version they can refer to. I guess they could put a version of "0.0.0" to get rid of the import version warning, but that would defeat the purpose. Perhaps you should have two flags for this? One for the consumer (ignore by default) and one for the producer (warning by default) of the package. Another option would be to only flag the consumer of the package if the producer has actually defined a version. As I said earlier in the thread, I prefer using the current bundle version as the initial package version if we are going to have a quick fix. Tom From: Darin Wright <[EMAIL PROTECTED]> To: Equinox development mailing list Cc: [EMAIL PROTECTED] Date: 01/15/2008 02:25 PM Subject:Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Packageas API PDE is planning to add support to flag missing version numbers on package exports (https://bugs.eclipse.org/bugs/show_bug.cgi?id=205198). The bug report suggest the default severity for a missing package version should be "ignore", but I would suggest to start it at "warning", and add a quick fix to set the initial version to match the current bundle version (if we agree that the initial package version should be the initial bundle version). API tooling will aim to add support to detect invalid version numbers on package exports as content of a package changes - similar to the support API tooling will provide for bundle version number validation. Darin Wright Thomas Watson <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 01/11/2008 04:24 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API I agree that tooling is needed in order to make this somewhat feasable. On the OSGi mailing list there was a question posted about using EMF on another framework implementation. One of the issues was that EMF uses Require-Bundle on org.eclipse.core.runtime. This ends up pulling in lots of dependencies, one of which is org.eclipse.osgi. This makes it impossible to use EMF on another Framework impl. If EMF instead used Import-Package to get its packages then it is conceivable that EMF could have its dependancies resolved in another Framework impl. But using Import-Package for the eclipse packages without versions is dangerous because you do not know what you will get. Eclipse team rarely uses Import-Package, this maybe because it is a bit harder. But for now I would advise against it because it is dangerous without versions. Until versions are established EMF should *not* move to Import-Package IMO. Tom John Arthorne ---01/11/2008 03:27:00 PM---I don't think we can even contemplate this without full tooling automation. As Tom says, we struggle to keep our bundle version From: John Arthorne <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 01/11/2008 03:27 PM Subject: Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API I don't think we can even contemplate this without full tooling automation. As Tom says, we struggle to keep our bundle version numbers correct as it is. We can maintain package versions manually up to a point, such as base framework packages and service packages, but any wider scope would become unmanageable. For most of the wider Eclipse team that rarely/never uses import package, there is no immediate need to version at the package level. Thomas Watson <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 01/11/2008 03:45 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API Without tooling this will be difficult. If we wanted to use the big hammer approach the we would have the API tooling (or
Re: [equinox-dev] OBR
Peter, who parses the filter? If OBR uses a different syntax from the Framework spec then the FrameworkUtil#createFilter or BundleContext#createFilter cannot be used. Who is throwing the syntax error in this case? The Equinox Framework implementation of the OBR implementation? Tom From: Peter Kriens <[EMAIL PROTECTED]> To: BJ Hargrave/Austin/[EMAIL PROTECTED] Cc: Equinox development mailing list Date: 01/21/2008 02:27 AM Subject:Re: [equinox-dev] OBR This is not really true. The OSGi filter and the OBR filter are not required to be the same. RFC 112 specifically allows the > and < (as well as some other operators). Kind regards, Peter Kriens On 20 jan 2008, at 15:51, BJ Hargrave wrote: This may be a problem in the tool (from OSGi) which generates the xml. OSGi recently decide to add < and > to the set of filter operators. But this is not in the 4.1 spec. It will be in a future spec. So the tool which generates the xml should not use the new operators. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 386 848 1781 Mobile: +1 386 848 3788 - Original Message - From: ChangWoo Jung [EMAIL PROTECTED] Sent: 01/20/2008 07:43 AM To: Equinox development mailing list Cc: Peter Kriens <[EMAIL PROTECTED]> Subject: Re: [equinox-dev] OBR I guess I found little bug in the generated OBR repo ( http://download.eclipse.org/releases/europa/repository.zip) The generated filter seems to be incorrect which throws exception in the runtime. For example, Jetty Http Service (org.eclipse.equinox.http.jetty), has dependency on "javax.servlet" which is shown as Import-Package: javax.servlet;version="[2.4.0,2.5.0)" in the manifest. It turns out be generated like below, (which seems to be incorrect), so it throws "InvalidSyntaxException" when equinox tries to create the filter upon that. Import package javax.servlet ;version=2.4.0 I guess there is minor bug on creating filter and after applying my private fix it seems to be working. wrong: filter='(&(package=javax.servlet)(version>=2.4.0)(version<2.5.0))' correct: filter='(&(package=javax.servlet)(&(version>=2.4.0)(&(version!=2.5.0)(version<=2.5.0' Which component will be the right place to report a bug against that i can attach my fix there as well? Any pointers? Thanks. Sincerely, ChangWoo Jung From: Jeff McAffer <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 01/12/2008 12:43 AM Subject: Re: [equinox-dev] OBR We currently do host an OBR repo with the major releases. Don't remember the URL but the required repository.xml/zip file is there for Callisto and Europa. The OBR client code may be interesting but our strategic direction is p2. For the most part p2 has (or can be made to have) the same functionality as the OBR client but goes further towards solving the wider range of problems we see in the Eclipse provisioning space. I am all for supporting the use of OBR repositories in the sense that some people will make their function available that way. Given the p2 work however, it would be more interesting (to me at least) to write an OBR repository adaptor for p2 than to use the OBR api. Further, I hope that eclipse projects will feel comfortable making their content available as p2 repositories so that the Eclipse user community is not put in a position of having to get many different provisioning clients. In short, we in p2 would very much like to have your interaction and participation in making a provisio
[equinox-dev] Projects tagged for the I-Build
The map file has been updated for the following Bug changes: + Bug 212954. [AdapterManager] Uninstalling bundle declarating adpater factory removes all adapter factories for the adapter (FIXED) + Bug 215503. Allow KeyStoreTrustEngine to use another name (FIXED) + Bug 215648. [console] ensure console thread is a non-daemon thread (FIXED) + Bug 215901. Bundle-NativeCode resolution of org.osgi.framework.os.name and org.osgi.framework.processor is not case-insensitive (FIXED) The following projects have changed: org.eclipse.equinox.launcher.win32.win32.ia64 org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.osgi.tests org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.osgi org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.launcher org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.registry org.eclipse.equinox.supplement org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.launcher.gtk.linux.x86 Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Incubator OSGi service implementations tagged for I-Build
The map file has been updated for the following Bug changes: + Bug 214124. [config] Need to use doPrivileged when accessing config store (FIXED) The following projects have changed: org.eclipse.equinox.ds org.eclipse.equinox.io org.eclipse.equinox.wireadmin org.eclipse.equinox.util org.eclipse.equinox.cm org.eclipse.equinox.ip A reminder to all equinox committers. Each bug you release to CVS must be released with a comment that includes the text "bug ". For example, Simon used the comment "Bug 214124. [config] Need to use doPrivileged when accessing config store" when releasing the fix to org.eclipse.equinox.cm. This allows our release tools to generate a report with all the bugs which were fixed. Thanks. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] OBR
ChangWoo,
There currently is no implementation of OBR. If you look earlier in this
thread you will see talk of investigating an OBR repository adaptor for p2.
Thomas Hallgren showed interest in implementing such a repository adaptor.
Thomas, do you have any interest in doing/contributing this work to
Equinox? Perhaps start in the incubator?
For your Filter issue. I would open a bug against the apache version of
OBR. It should not be using the framework Filter implementation to
construct Filter objects.
Tom
From: Peter Kriens <[EMAIL PROTECTED]>
To: Equinox development mailing list
Date: 01/22/2008 02:09 AM
Subject:Re: [equinox-dev] OBR
RFC 112 is not a standard, but please note that > and < are specifically
allowed. Rewriting bindex will not fix the problem if you want to
interoperate, you have to use another filter impl to achieve that.
Kind regards,
Peter Kriens
On 21 jan 2008, at 16:18, ChangWoo Jung wrote:
I have been using OBR implementation from Apache Felix and it uses
"BundleContext#createFilter" to create the filter which throws the
exception in the equinox framework at the end. So if I don't modify
the bindex not to generate the < or > operator, the repo xml can't
be digested in the OBR bundle for bundle resolution in the framework.
By the way, do we also have OBR implementation from equinox?
Sincerely,
ChangWoo
Jung
From: Thomas Watson <[EMAIL PROTECTED]>
To: Equinox development mailing list
Date: 01/21/2008 11:44 PM
Subject: Re: [equinox-dev] OBR
Peter, who parses the filter? If OBR uses a different syntax from the
Framework spec then the FrameworkUtil#createFilter or
BundleContext#createFilter cannot be used. Who is throwing the syntax
error in this case? The Equinox Framework implementation of the OBR
implementation?
Tom
Peter Kriens ---01/21/2008 02:27:18 AM---This is
not really true. The OSGi filter and the OBR filter are not required
to be the same. RFC 112 specifically allows the >
From: Peter Kriens <[EMAIL PROTECTED]>
To: BJ Hargrave/Austin/[EMAIL PROTECTED]
Cc: Equinox development mailing list <
equinox-dev@eclipse.org>
Date: 01/21/2008 02:27 AM
Subject: Re: [equinox-dev] OBR
This is not really true. The OSGi filter and the OBR filter are not
required to be the same. RFC 112 specifically allows the > and < (as
well as some other operators).
Kind regards,
Peter Kriens
On 20 jan 2008, at 15:51, BJ Hargrave wrote:
This may be a problem in the tool (from OSGi) which generates the
xml. OSGi recently decide to add < and > to the set of filter
operators. But this is not in the 4.1 spec. It will be in a future
spec. So the tool which generates the xml should not use the new
operators.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 386 848 1781 Mobile: +1 386 848 3788
- Original Message -
From: ChangWoo Jung [EMAIL PROTECTED]
Re: [equinox-dev] Equinox with OSGi security?
The eclipse.security is only used by the org.eclipse.equinox.launcher jar.
The eclipse.security option is used by the launcher bootstrap code to
indicate that it should setup a policy which grants itself and the
framework ALLPermissions. Then it sets the java.security.manager to the
value of eclipse.security. Later when the Framework launches it actually
will install the SecurityManager to enable security.
When running without the launcher you need to do a bit more work to setup
your policy file. You can use a very simple policy which grants
AllPermissions to everything like this ...
## BEGIN POLICY FILE ##
grant {
permission java.security.AllPermission;
};
## END POLICY FILE ##
You would then launch equinox with the following command:
java
-Djava.security.manager=org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager
-Djava.security.policy=policy -jar org.eclipse.osgi_3.4.0.v20080107.jar
-console
The java.security.manager property tells the VM what security manager to
load. The java.security.policy property tells the VM what policy to load
to grant permissions. Note that the permissions granted to the bundles
installed into the framework are controled by the PermissionAdmin and
ConditionalPermissionAdmin services. By default these services will grant
all bundles AllPermissions.
HTH.
Tom
From: Marcel Offermans <[EMAIL PROTECTED]>
To: Equinox development mailing list
Date: 01/24/2008 10:42 AM
Subject:[equinox-dev] Equinox with OSGi security?
I would like to run Equinox with OSGi security (PermissionAdmin,
ConditionalPermissionAdmin) enabled.
I read the quickstart guide here:
http://www.eclipse.org/equinox/documents/quickstart.php
I even found some reference to a property to set that should enable
security:
-
Declipse
.security
=org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager
However, if I just run the Equinox framework like described in the
quickstart guide with that property, I still do not get any security
related service. Am I missing some piece of documentation here? It
should not be too hard to run with security, right?
Greetings, Marcel
___
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
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 From: Andrew Niefer <[EMAIL PROTECTED]> To: Equinox development mailing list 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]To Equinox development mailing list 01/25/2008 02:53 AMcc Subject Please respond toRe: [equinox-dev] [prov] Equinox development mailing listDownload manager support for pack200 Just out of curiosity, why do you use the external binary to do the pack/unpack and not the java.util.jar.Pack200 class? It seems to me that a fragment that is EE dependent (require Java 1.5 or higher) would be ideal here. Those who run lower then Java 5 simply would not have pack200 which is kind of natural isn't it? - thomas Jeff McAffer wrote: > right but there is the practical detail that the exe you need comes > with Java 5 or later and the licensing does not likely allow you to > ship just the unpack200 exe. But that is a matter for someone's legal > team. As John says, the unpack support simply cares whether or not > the exe is there. > What we really need is an open source implementation of unpack that > runs on/with Foundation... > > Jeff > > > John Arthorne wrote: >> >> Just to clarify, the JRE level doesn't matter here. Unpack is >> performed by a standalone unpack200 executable that doesn't require >> presence of a JVM. You can run with a Foundation class library, plus >> a standalone unpack200 executable from Java 5 or Java 6. >> >> >> >> *Jim Colson <[EMAIL PROTECTED]>* >> Sent by: [EMAIL PROTECTED] >> >> 01/24/2008 09:18 PM >> Please respond to >> Equinox development mailing list >> >> >> >> To >> Equinox development mailing list >> cc >> Equinox development mailing list , >> [EMAIL PROTECTED] >> Subject >> Re: [equinox-dev] [prov] Download manager support for pack200 >> >> >> >> >> >> >> >> >> >> how would that work on J2ME (CDC/Foundatoin)? >> >> >> >> Jim Colson, Chief Architect - IBM Client Software >> Distinguished Engineer >> IBM Academy of Technology >> Board Member - IT Architect Certification >> >> 11501 Burnet Rd. Austin, TX 78758 >> Ph 512-823-7357, Fax 512-838-0962 >> email: [EMAIL PROTECTED] >> >> Admin: Sandra Wallis 512-838-3241 >> email: [EMAIL PROTECTED] >> >> >> >> >> From: >> Pascal Rapicault <[EMAIL PROTECTED]> >> >> >> To: >> Equinox development mailing list >> >> >> >> Date: >> 01/24/2008 08:11 PM >> >> >>
Re: [equinox-dev] is this a service tracker bug?
Mark, I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=216648 for you. I tried to CC you to the bug but I noticed you did not seem to have a bugzilla e-mail, unless you use a different e-mail for bugzilla than the one you use to post to equinox-dev. Tom From: Mark <[EMAIL PROTECTED]> To: "Equinox development mailing list" Date: 01/25/2008 02:43 PM Subject:Re: [equinox-dev] is this a service tracker bug? :( I'll file a report - one other solution pointed out was to seperate interface (api) from the impl and the client. So I guess I should create A, B, and C (A)pi, Impl-(B)undle, and (C)lient Regards osgi> ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi> update 1 removedService osgi> update 1 osgi> ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi> start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framewor
Re: [equinox-dev] is this a service tracker bug?
Mark, This is because of the pending removal of the old class loader from bundle A which bundle B is still wired to for package bundlea.service. You do not see the new service from bundle B because you would get a ClassCastException. The Framework filters out services that it knows you do not have the correct package wiring for. The new content for the service is loaded from the new class loader of Bundle A. But since Bundle B is still wired to the old content of Bundle A it will not see the service until it is refreshed. A refresh operation will rewire Bundle B so that it gets the new content from Bundle A and everybody will be happy. Tom [EMAIL PROTECTED] wrote on 01/25/2008 10:33:33 AM: > > This is driving me mad. I have two bundles A and B. B track the > service offered by A. > > However if I call update on A then I get a remove Service > notification but no add Service notification - that is until I issue > a refresh command ? is this a bug? > > I have written the same simple code 10 time .. see the results. > > I have attached the two bundles and the two eclipse plugin projects > (as one zip) - just in case a Eclipse/OSGi guru like yourself can > figure it out? > > > > [image removed] [image removed] C:\eg>java -jar equinox.osgi.jar -console > > osgi> ss > > Framework is launched. > > id State Bundle > 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 > > osgi> install file:bundleA_1.0.0.jar > Bundle id is 1 > > osgi> install file:bundleB_1.0.0.jar > Bundle id is 2 > > osgi> ss > > Framework is launched. > > id State Bundle > 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 > 1 INSTALLED bundleA_1.0.0 > 2 INSTALLED bundleB_1.0.0 > > osgi> start 1 > > osgi> start 2 > addingService > > osgi> stop 1 > removedService > > osgi> start 1 > addingService > > osgi> update 1 > removedService <- no add ! > > osgi> stop 2 > > osgi> start 2 > > osgi> refresh <- Only get add after refresh > > osgi> addingService > > > osgi> > > On 25/01/2008, Neil Bartlett <[EMAIL PROTECTED] > wrote: > Hi Mark, > > Many thanks for your kind words! > > Regarding the service tracker problem... that's not the behaviour I > would expect to see, and I've just put together a small test case > which prints a message in the addingService, removedService and > modifiedService methods of the ServiceTracker. When I update the > bundle that registered the service, I see the following: > > osgi> update 5 > Removed service > Added service > > osgi> > > Which seems to be the way it should work. I suggest posting a > message to the equinox-dev mailing list ( https://dev.eclipse.org/ > mailman/listinfo/equinox-dev) explaining the problem in detail and > including a minimal code sample that reproduces the problem. > > Regards, > Neil > > On 25 Jan 2008, at 13:42, Mark wrote: > > Neil, > > First off I have to thank you in a big way, because it was you > articles that got me up and running on OSGI. > > I am also glad that you are putting together a book... because I was > thinking about it myself...in practice or in action!, would you like > some help? > > ..Anyway the reason for this mail... > > I was looking at the Listeners Considered Harmful: The "Whiteboard" > Pattern white paper, and I put together a very simple two bundle > example (on Equinox), > > Bundle A (offers a service) > Bundle B (consumes service A, using a Service Tracker) > > So far so good, and not exactly rocket science. > > However this morning I discovered that if you update A - then you > must refresh A in order for B to receive the added service event. > > This came as a surprise, go I Googled a while, and came up short. So > I was wondering if you had some words of widom for me on this ? > > Kind Regards > > Mark > > [attachment "bundleA_1.0.0.jar" deleted by Thomas Watson/Austin/IBM] > [attachment "bundleB_1.0.0.jar" deleted by Thomas Watson/Austin/IBM] > [attachment "eclipe-projects.zip" deleted by Thomas Watson/Austin/IBM] > ___ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] is this a service tracker bug?
Matt, please open a bug against Equinox->Framework. I have reproduced, it appears to be related to lazy activation. If you remove the Eclipse-LazyStart header from Bundle A then it works. This is an interesting corner case we may need to get a clarification from OSGi on. I assume the old content of the bundle will not have access to a BundleContext. What does it mean to get wired to old pending removal content of a bundle that is lazy activated? The classes may be in an invalid state if they cannot have access to a BundleContext. Tom From: BJ Hargrave/Austin/[EMAIL PROTECTED] To: Equinox development mailing list Date: 01/25/2008 12:10 PM Subject:Re: [equinox-dev] is this a service tracker bug? But you should not have to refresh. That is the whole point of importing the package which is exported. So that A' can import it from A which is where B imports it from. I think the IllegalStateException is is a bug in Equinox. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mark <[EMAIL PROTECTED]> To: "Equinox development mailing list" Date: 2008-01-25 13:06 Subject: Re: [equinox-dev] is this a service tracker bug? I see - It's in an IllegalState until you refresh On 25/01/2008, Mark < [EMAIL PROTECTED]> wrote: Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi> stop 1 removedService osgi> update 1 osgi> ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi> start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoa
[equinox-dev] Equinox projects tagged for the I-Build
The map file has been updated for the following Bug changes: + Bug 181832. Console's "diag" command should try to display the ID of the "Missing required bundle" (FIXED) + Bug 201068. refreshPackages() incorrect behaviour (FIXED) + Bug 214635. [Launcher] maximum .ini/.ee line length of 1024 (FIXED) + Bug 215369. [launcher] Running with --launcher.suppressErrors hides all error messages (FIXED) + Bug 215730. VM must remain active until Framework is shutdown (FIXED) + Bug 215764. Service tracker is not closed in equinox.app's DefaultApplicationListener (FIXED) + Bug 216196. [sec] Add getStatus support to AuthorizationEngine (FIXED) + Bug 216286. Compiler warnings in N20080123-0010 in osgi tests (FIXED) + Bug 216648. Updating a bundle that exports/imports same package fails (FIXED) The following projects have changed: org.eclipse.equinox.executable org.eclipse.equinox.supplement org.eclipse.equinox.app 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] Equinox Incubator OSGi implementations tagged for I-Build
The map file has been updated for the following Bug changes: + Bug 216281. [ds] Compiler warnings in N20080123-0010 (FIXED) + Bug 216282. [ip] Compiler warnings in N20080123-0010 (FIXED) + Bug 216284. [util] Compiler warnings in N20080123-0010 (FIXED) + Bug 216285. [wireadmin] Compiler warnings in N20080123-0010 (FIXED) The following projects have changed: org.eclipse.equinox.ds org.eclipse.equinox.wireadmin org.eclipse.equinox.util org.eclipse.equinox.ip Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Problems with the Export-Package "uses" directive
Hello all. I am sending this note to inform the community that the Export-Package "uses" directive can critically effect the performance of the Equinox OSGi package resolver when a system contains a large set of bundles (1000s) and there are multiple exporters of the same package name. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=216934 Unfortunately this means that as a community we should *not* include any bundles that declare the Export-Package "uses" directive in the Ganymede release. Here is an example of a bundle manifest file (META-INF/MANIFEST.MF) with an Export-Package statement that contains a "uses" directive Bundle-SymbolicName: foo Export-Package: com.foo; uses:="com.bar" More details: The Export-Package "uses" directive in OSGi is used by the Framework to ensure class space consistencies when multiple exporters of a package exist in the Framework. In the above example there may be multiple exporters of the "com.bar" package in the Framework. This Export-Package statement is informing the Framework that in order for a bundle to get wired to the "com.foo" package exported by the "foo" bundle then the importing (or requiring) bundle must be wired to the same exporter of "com.bar" as the foo bundle is. This is essential when dealing with multiple exporters of the same package. Unfortunately the problem of resolving the state with "uses" clauses appears to be an NP-hard problem to solve. Please see bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=216934 if you have ideas of how to solve such a problem. Thanks and sorry for the inconvenience. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
