Re: [equinox-dev] [prov] M3 Testing status
* Pascal Rapicault [EMAIL PROTECTED] [2007-10-30 19:33]: Okay, my problem now is that I can't get the admin UI to allow me to provision userui into an M2 profile. I heard people saying there was an issue with the 20071030-0010 build. Would this issue be affecting me being able to provision userui? These two issues should be unrelated. However on our request Kim wiped-out the update site from download.eclipse.org and therefore you will no longer find there the userui IU. With today's agent, I can provision an M2 SDK (with locally-generated metadata) but can't install userui due to a dependency on a more recent jdt.source. I'm downloading today's SDK but it's taking a while. I'll report back when it's done. Andrew pgpDOJLjzSH1g.pgp Description: PGP signature ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev]Launcher projects tagged for 6pm build
The map file has been updated for the following Bug changes: + Bug 199020. [launcher] Can't start the AWT while using new eclipse native launcher in 3.3 (NEW) The following projects have changed: org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.executable___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [sec] questions about EE for security
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
[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
On 10/31/07, Scott Lewis [EMAIL PROTECTED] wrote: 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. Those packages are marked as optional. I don't know how that all works out but I presume it means that, yes, they could theoretically not be available in that runtime environment. http://jcp.org/en/jsr/detail?id=219 (see section 2.6) http://java.sun.com/products/cdc/reference/cdc_packages.pdf (see the FP 1.1 JSR 219 column) Regards, Rem ___ 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
On 10/31/07, Scott Lewis [EMAIL PROTECTED] wrote: Right, so bundles that require those packages to compile or run would have to specify EE of JRE 1.4 (or higher)...in other words they can't specifiy 1.1 and be assured of getting those optional packages. Please correct if this is wrong in any way. Well, you could just declare an Import-Package and get by with that. If they don't have a bundle that exports that package then your consumers are out of luck. eRCP's bundles has Import-Package statements (or whatever the appropriate word in OSGi speak is) for XML packages. Regards, Rem ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] how to change the jetty port from 80 to other
Hello Simon, Thanks very much for your help and remind. 2007/10/31, Simon Kaegi [EMAIL PROTECTED]: Hi Bob, These sorts of question should normally be asked in the user newsgroup instead of the dev list. You can configure the Jetty Server in a number of different ways: 1) System properties (prefix the properties you found with the bundle name -- e.g. -Dorg.eclipse.equinox.http.jetty.http.port=8080) 2) JettyConfigurator (see http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/equinox/http/jetty/JettyConfigurator.html) 3) ConfigurationAdmin (The config.xml file you found is actually for use with the metatype service in conjunction with ConfigAdmin.) HTH -Simon [EMAIL PROTECTED] wrote on 10/31/2007 02:01:36 AM: Hello everybody, I am new to the Equinox, I am coding a sample application by following the article Embedding an HTTP server in Equinox. I coded a servlet and want to start a jetty server in Equinox. The application uses a plugin org.eclipse.equinox.http.jetty, and when it started, I got a warning says 'binding listening port to 80 failed', because I am working in the linux and I am not the root, so I need to tell the jetty plugin to use a new port such as 8080, but I don't know how to config the jetty plugin to use the new port. I checked the plugin source and found a file 'OSGI-INF/metatype/config.xml', there is a line like AD id=http.port type=Integer default=0/, but I think it's not a good idea to change source of the plugin just for choose a different listening port. any idea? thanks! Best regards Bob Yang ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [prov] M3 Testing status on Linux
Here's what I've found so far while running the tests. I'll finish the rest tomorrow. 1. Basic install, run and update - do not exit admin UI in between ✓ new profile creation ✓ installing 3.4M2 sdk ✓ running provisioned install ✓ update using admin UI ✓ run and verify updates applied ✓ verify updates in admin ui - exit admin UI in between ✓ new profile creation ✓ installing 3.4M2 sdk ✓ running provisioned install ✓ update using admin UI ✓ run and verify updates applied ✓ verify updates in admin ui 2. Basic install, and update ✓ new profile creation ✓ installing 3.4M2 sdk ✓ Using the Admin UI: ✓ - look for updates, install eclipse SDK 3.4 M3 ✓ Run and verify that the plugins have been changed ✓ Also check that the profile is properly updated in the Admin UI 3. Basic install from End User UI ✓ Using the Admin UI: ✓ Create a new profile ✓ Install the SDK 3.4 M2 ✗ Install the End User UI ✓ - can't for M2 so assume 20071030 for above SDK ✓ Exit the Admin UI ✓ Start the provisioned install ✓ Using the End User UI: ✓ - Install the releng tools ✗ Accept to restart. - bug #208293 (Susan already fixed ... will verify tomorrow) ✓ Come back up and notice the presence of the releng tools ✓ Start up the Admin UI ✓ Notice the presence of the releng tools in the profile 4. Uninstall the releng tools from End User UI ✓ From a provisioned install with end user UI ✓ - Open the end user UI (HelpSoftware Updates (Incubation)) ✓ - Go to Installed features page ✓ - Select the releng tools ✓ - Uninstall ✗ Accept to restart. - bug #208293 (Susan already fixed ... will verify tomorrow) ✗ Come back up and notice the absence of the releng tools - error: No application id has been found. ✓ Start up the Admin UI ✗ Notice the absence of the releng tools in the profile - at this point I noticed that the sdk IU was gone. I couldn't re-add it, though, because the generated featureIU qualifiers (-7O7R-E7...) didn't match between what was then installed and what was in the metadata repo (from which I installed to begin with). puzzling ... Andrew pgpv1EqY6Wspr.pgp Description: PGP signature ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [api tooling] Re: Using component.xml as a starting point
There are cases where you want a component.xml file (or something similar) when you don't want to or can't mark up the source, but I don't see any reason why someone would want to maintain both a component.xml file and javadoc tags in the source for the same API. So, a one-off tool for inserting javadoc tags based on a component.xml sounds useful, but I wouldn't bother getting any fancier than that. Darin Wright/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/29/2007 04:54 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] [api tooling] Re: Using component.xml as a starting point We are getting close the chicken and egg problem here When it's time for developers to start using the tooling, we want to make it easy - so yes, it would be handy to have a tool that inserts javadoc tags based on existing component XMLs. I think the tags replace component.xml - so I don't think we should have tooling to keep the two in synch. I would see this as a one off tool to get started. For that reason, I don't think we would want to create markers as it would require active tooling to keep the two in synch. As well, we'd have to have some mechanism for knowing if the component.xml should be considered as the source for tag generation, or the target for caching existing tags. It feels awkward to have duplicated information in the IDE - when the user can edit both. Would it be better to have a tool/action/wizard that processes the component XML and generates a report for issues (rather than makers)? Does anyone think that we should have tooling to maintain the component.xml files? I'd rather just use the javadoc tags as the source of the information in the workspace. At build time, we could also use source to generate that part of our API description. Darin Olivier Thomann/Ottawa/IBM 10/29/2007 02:17 PM To Darin Wright/Ottawa/[EMAIL PROTECTED], Michael Rennie/Ottawa/[EMAIL PROTECTED], Jeff McAffer/Ottawa/[EMAIL PROTECTED] cc Subject Using component.xml as a starting point Hi, We should use the existing component.xml file for each plugin in the SDK to tag the corresponding types with the appropriate javadoc tag. So the tool would take the component.xml and check all the API types inside the workspace. The existing text that describes the API usage would be replaced with the corresponding tag and for the API type where the existing text is not an exact match, the tag would be added and a marker created to remember that this file should be double-checked. The new API types that have been added since the component.xml was created should also be marked to be double-checked. This could allow us to get a good baseline. What do you think? 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
