You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(23) |
Nov
(5) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(28) |
Feb
(35) |
Mar
(25) |
Apr
(2) |
May
(8) |
Jun
(4) |
Jul
|
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(32) |
Dec
|
2003 |
Jan
(4) |
Feb
|
Mar
|
Apr
(6) |
May
(5) |
Jun
(4) |
Jul
|
Aug
|
Sep
(2) |
Oct
(10) |
Nov
(4) |
Dec
(6) |
2004 |
Jan
(8) |
Feb
(21) |
Mar
(15) |
Apr
(17) |
May
(89) |
Jun
(5) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ben A. <ben...@st...> - 2007-06-25 09:05:17
|
Hello there I would greatly appreciate a small amount of your time to assist with my doctoral research at The University of Newcastle. The research concerns open source licensing and we're seeking developers working on Java projects. The research is supervised, ethics-approved, anonymous and results will be freely available. Participation will also provide a custom licensing report for your project. To learn more, please visit: http://licensing-research.newcastle.edu.au Thanks for reading this email, and I hope you'll consider participating. Best regards Ben Alex (My apologies for being off-topic; this list will not be emailed again) |
From: Stephane F. <ste...@in...> - 2004-07-05 14:57:40
|
Hi,=20 OSGi v3 has a specific section about the java API requirements. It's called "Execution Environment Specification". That speficication lists all classes that java VM needs to provide in order to build an OSGi imple= mentation. There are two flavors : foundation (which is extracted mainly from CDC profile) and minimal which is a subset (I think) centered for OSGi requirements.=20 Both Reflection and Serialisation apis are needed in both flavors.=20 You can find the API lists for both flavors on OSGi web site, as jar files.=20 The second question is now :=20 - What is .... to run a java VM compliant to the minimal requirements... No idea for the moment.=20 /stephane On Mon, Jul 05, 2004 at 08:04:14PM +0530, paramjeet chawla wrote: > Hi, >=20 > I spent some time to evaluate OSCAR/OSGi on J2ME CLDC. I thought its be= tter > to have an experts opinion. As CLDC does not support Reflect Classes an= d > Serializable, so what impact does it have on OSGi framework. Do Reflect= s and > Serializable have crucial role in implementation of the framework? >=20 > Another question is, What is amount of RAM & Flash, CPU Hz required to = run > minimum version of OSGi ? > it would be helpful to me if you provide me various break ups of CDC, F= P, > Framework size etc. >=20 > Thanking you in anticipation. >=20 > Regards >=20 > Paramjeet >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20 > digital self defense, top technical experts, no vendor pitches,=20 > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > oscar-osgi-devel mailing list > osc...@li... > https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel --=20 Stephane Frenot - Associate professor CITI/ARES - INSA lyon - Bat. L=E9onard de Vinci 20, av. A. Einstein - 69621 Villeurbanne Cedex Email: mailto:ste...@in... Web : http://ares.insa-lyon.fr/~sfrenot/ ICQ : 643346 (et oui !) Tel : +33 472 436 422 / +33 617 671 714 ----------------------------------------------------------------- |
From: paramjeet c. <par...@pa...> - 2004-07-05 14:35:33
|
Hi, I spent some time to evaluate OSCAR/OSGi on J2ME CLDC. I thought its better to have an experts opinion. As CLDC does not support Reflect Classes and Serializable, so what impact does it have on OSGi framework. Do Reflects and Serializable have crucial role in implementation of the framework? Another question is, What is amount of RAM & Flash, CPU Hz required to run minimum version of OSGi ? it would be helpful to me if you provide me various break ups of CDC, FP, Framework size etc. Thanking you in anticipation. Regards Paramjeet |
From: Richard S. H. <he...@un...> - 2004-06-11 09:38:48
|
Hello everyone. As part of Oscar's move to forge.objectweb.org, I plan to migrate the Source Forge mailing lists to ObjectWeb as well. I have created two mailing lists: * os...@ob... - this list is for general OSGi, Oscar usage, and bundle development discussion. * osc...@ob... - this list is for discussion about the internal details of Oscar's implementation, i.e., if you are interested in knowing how Oscar works or want to have input on design decisions. I will migrate everyone from the Source Forge mailing lists to the general "oscar" mailing list, but I won't include anyone by default on the "oscar-dev" list. If you do not want to be migrated, want to be on both lists, or only want to be on "oscar-dev", then please respond to this email and let me know so that I can do the right thing for you. In summary, unless you say otherwise, you will be taken off of the Source Forge mailing list and added to the new ObjectWeb "oscar" general discussion mailing list. -> richard p.s. Since the old Oscar site will become the web presence for OBR, I will eventually create at least one new mailing list on Source Forge for OBR. |
From: Richard S. H. <he...@un...> - 2004-06-02 11:07:48
|
Manuel Santillan Palencia wrote: >However, the thing is that the system hangs, even the tui, so you must >kill oscar. But if I extract the code and put it inside a BundleListener >which checks that the bundle event corresponds to BundleB.STARTED, then >it works fine. If I find a bit of time, I shall try to recreate it, for >the moment I have not been able... > > If you can find the time to recreate it, I would definitely like to take a look at it. >When a started bundle is updated it is restarted. Then when packages are >refreshed, it is restarted with the new code. > > Correct. >If a bundle is started, and then you change the platform start level to >be higher than its startlevel, it stops. If you update the bundle and >refresh and change again the platform start level to be lower than the >bundle level, it is not started. Should not the service remember which >bundles were in started state for a given startlevel even if they are >updated? > > It sounds like you reversed this, I assume you mean "change the platform start level to be lower than its start level..." Or do you mean change the bundle start level to be higher? At any rate, which version of Oscar are you using? I think this was a bug that was corrected in the latest betas, so just wait for 1.0.0 to be released and your problem should be solved. Speaking of 1.0.0, what version of Oscar were you getting your deadlock against? Perhaps I could convince you to do some testing on the 1.0.0 beta if you are not already doing so... -> richard |
From: Manuel S. P. <san...@di...> - 2004-06-02 10:20:21
|
Hello! > I think that Michel is correct when he states that it has nothing to do > with the STARTING state, however, it could very likely be an Oscar issue > in some respects. Oscar has to do some sanity locking so that it can > ensure that refreshes don't happen in the middle of other operations, > for example. > > It is difficult to explain the approach, but Oscar uses two locks, where > one is intended for simple operations and one is intended for > adminstrative operations. An administrative operation can ensure > complete mutex by getting both locks. > > So what do I guess is happening in your case? Well, I haven't used RMI > in a long, long time, but if I remember correctly, it uses threads. Most > likely, Oscar calls out to your code, which then calls back into Oscar > on a different thread trying to access the other bundle, which creates > some sort of cycle. > > My guess is you could recreate the problem without RMI, but by just > creating a separate thread that tries to load the class. > If you can create a small example that demonstrates the problem, I will > look into whether/how it is possible to loosen the concurrency control, > but this is a very tricky issue. Obviously, Oscar cannot necessarily > deal with people grabbing its thread in callbacks and then sending in a > new thread. > > I'm sorry, but I cannot recreate the problem :(( I've tried, it but it works correctly. Maybe the problem lies elsewhere. The real architecture is that bundle A has got a JMX's MBeanServer with a RMI connector server, which listens for incoming requests. At startup time, bundle B invokes a method from bundle A (the agent), through reflection and RMI (ie, a JMX remote connection), which provokes that: 1. A file is loaded. This works fine. 2. From that file, it reads which components it must instantiate. This also works fine. 3. It tries to instantiate all the stated components. Some of the components's classes are in bundle B (exported by it). 4. It returns. 5. Bundle B finishes starting However, the thing is that the system hangs, even the tui, so you must kill oscar. But if I extract the code and put it inside a BundleListener which checks that the bundle event corresponds to BundleB.STARTED, then it works fine. If I find a bit of time, I shall try to recreate it, for the moment I have not been able... Another thing, regarding start level: When a started bundle is updated it is restarted. Then when packages are refreshed, it is restarted with the new code. If a bundle is started, and then you change the platform start level to be higher than its startlevel, it stops. If you update the bundle and refresh and change again the platform start level to be lower than the bundle level, it is not started. Should not the service remember which bundles were in started state for a given startlevel even if they are updated? > -> richard Regards, Manuel |
From: Richard S. H. <he...@un...> - 2004-06-01 08:09:14
|
Manuel Santillan Palencia wrote: >I've already used a similar approach, by extracting all the problematic >code from bundle B and putting it in a bundle event listener which >executes itself when the bundle B is already started. > >The thing is that if bundle B is in INSTALLED, RESOLVED OR STARTED >state, then there is no problem in bundle A accesing a class from bundle >B. However, if bundle A tries to access a class exported when bundle B >is STARTING, he won't be able to do it. Is this the correct way of >acting? Or should bundle A be able to access bundle B classes at any >time? > > I think that Michel is correct when he states that it has nothing to do with the STARTING state, however, it could very likely be an Oscar issue in some respects. Oscar has to do some sanity locking so that it can ensure that refreshes don't happen in the middle of other operations, for example. It is difficult to explain the approach, but Oscar uses two locks, where one is intended for simple operations and one is intended for adminstrative operations. An administrative operation can ensure complete mutex by getting both locks. So what do I guess is happening in your case? Well, I haven't used RMI in a long, long time, but if I remember correctly, it uses threads. Most likely, Oscar calls out to your code, which then calls back into Oscar on a different thread trying to access the other bundle, which creates some sort of cycle. My guess is you could recreate the problem without RMI, but by just creating a separate thread that tries to load the class. >I mean, I 've already found workarounds for this problem. But I do not >know if this is a bug (and therefore should need a fix) or is it just >the way the spec says it should work. :) > If you can create a small example that demonstrates the problem, I will look into whether/how it is possible to loosen the concurrency control, but this is a very tricky issue. Obviously, Oscar cannot necessarily deal with people grabbing its thread in callbacks and then sending in a new thread. -> richard |
From: Richard S. H. <he...@un...> - 2004-06-01 07:48:40
|
Hello everyone, I am back from my conference. I did not receive any feedback from the 1.0.0beta5 release, so that means one of two things: 1. No one looked at it. 2. No one had any issues. I certainly hope that it was the latter, so I can finish updating documentation and add any final bugs fixes and features. My goal is to release within the next two weeks. -> richard |
From: Michel D'H. <mic...@tr...> - 2004-05-28 10:54:49
|
Manuel Santillan Palencia wrote: >The thing is that if bundle B is in INSTALLED, RESOLVED OR STARTED >state, then there is no problem in bundle A accesing a class from bundle >B. However, if bundle A tries to access a class exported when bundle B >is STARTING, he won't be able to do it. > Is it really because it is in Starting state, or because of what is done in the start method? I mean, if you "sleep" for 1 minute in the start method of B, and you access a class from A as you do when B is in another state (installed, resolved or started), do you still have the problem? And the other way round? If you do what is in the start method when the bundle is started, are you still blocked? >Is this the correct way of acting? Or should bundle A be able to access bundle B classes at any time? > > I don't have time to look into the source of Oscar, but from what I can imagine, the class loader of B is exporting its packages as soon as it is installed. So we are back to pure Java, not OSGi, and the state of the bundle shall have no influence. Regards Michel |
From: Manuel S. P. <san...@di...> - 2004-05-28 09:55:41
|
Hi! I answer you inside the mail. > First and foremost, this sounds like a logic/coding deadlock to me. It > seems you have a mutual dependency in your startup logic: > > - Bundle B needs Bundle A to do something before it can finish starting > - Bundle A needs to load classes from Bundle B before it can finish > starting. Not exactly. Bundle A is already started and works fine. Then I start bundle B, which tells bundle A to instantiate a class. This class is exported by bundle B and imported by bundle A. > > If I've understood this correctly, the only way you can break this > deadlock is: > > - remove one of the dependencies e.g. let Bundle B start without any > dependency on Bundle A. Sort out what Bundle B needs later, such as by > using Services and have Bundle B wait for the required services to > become available. I've already used a similar approach, by extracting all the problematic code from bundle B and putting it in a bundle event listener which executes itself when the bundle B is already started. The thing is that if bundle B is in INSTALLED, RESOLVED OR STARTED state, then there is no problem in bundle A accesing a class from bundle B. However, if bundle A tries to access a class exported when bundle B is STARTING, he won't be able to do it. Is this the correct way of acting? Or should bundle A be able to access bundle B classes at any time? I mean, I 've already found workarounds for this problem. But I do not know if this is a bug (and therefore should need a fix) or is it just the way the spec says it should work. :) Thanks!! Regards, Manuel Santillan |
From: Rob W. <ro...@as...> - 2004-05-28 08:37:28
|
Manuel Excuse me if this has already been answered - I only get the list digests, which come out a little delayed. >We 've got bundle A and B. Bundle B has got a class C, which he exports, >and bundle A imports it. > > > That part should be fine, it's the way OSGi is intended to work >Suppose A is already started. Now we start bundle B. In its activator, >it contacts bundle B via RMI and tells him to instantiate class C (by >reflection). The problem is that while bundle B is starting, bundle A >cannot instantiate classes exported by bundle B. Usually, this is not a >problem, because the call just waits until bundle B finishes starting. >But in this case, a deadlock occurs, because bundle B won't finish until >bundle A instantiates that class, and A won't instantiate that class >until bundle B finishes. > > > First and foremost, this sounds like a logic/coding deadlock to me. It seems you have a mutual dependency in your startup logic: - Bundle B needs Bundle A to do something before it can finish starting - Bundle A needs to load classes from Bundle B before it can finish starting. If I've understood this correctly, the only way you can break this deadlock is: - remove one of the dependencies e.g. let Bundle B start without any dependency on Bundle A. Sort out what Bundle B needs later, such as by using Services and have Bundle B wait for the required services to become available. - move the offending Class C (and any other dependent classes) into a pure "library" bundle that has no activator or active code, but just purely acts as a class library exporting classes for other bundles to use. Both Bundle A and Bundle B can then import these classes -- Rob |
From: Michel D'H. <mic...@tr...> - 2004-05-28 07:55:37
|
Manuel Santillan Palencia wrote: >We 've got bundle A and B. Bundle B has got a class C, which he exports, >and bundle A imports it. > >Suppose A is already started. > How does A import class C? Is it through a dynamic-import in the manifest? Otherwise, it means that either B is already INSTALLED, or package of class C is exported by another bundle. >Now we start bundle B. In its activator, it contacts bundle B > you mean "it contacts bundle A", I guess! >via RMI and tells him to instantiate class C (by >reflection). The problem is that while bundle B is starting, bundle A >cannot instantiate classes exported by bundle B. > Well, according to me, it could, as explained below. >Usually, this is not a >problem, because the call just waits until bundle B finishes starting. >But in this case, a deadlock occurs, because bundle B won't finish until >bundle A instantiates that class, and A won't instantiate that class >until bundle B finishes. > > >I think it has to do with the fact that while a bundle is STARTING it >is not RESOLVED nor INSTALLED, and therefore no classes can be exported. >Am I right? > > The sequence is INSTALLED, RESOLVED then STARTING. If you take as an example the case of a library bundle, just being INSTALLED is enough to export packages, so bundle A could access class C as soon as bundle B is installed. >I mean, is this "my fault" in the sense that the spec states that the >platform should act in this way, or is it a bug? > > I am just wondering why you are using RMI between bundles. Besides, I miss deeper knowledge on how class C is shared. Regards Michel |
From: Manuel S. P. <san...@di...> - 2004-05-27 17:36:09
|
Hi 2 everybody!! I've been squeezing my brains with a deadlock until I've finally found out why it happened. The code is a bit hard to understand, so I'll simplify it a bit. We 've got bundle A and B. Bundle B has got a class C, which he exports, and bundle A imports it. Suppose A is already started. Now we start bundle B. In its activator, it contacts bundle B via RMI and tells him to instantiate class C (by reflection). The problem is that while bundle B is starting, bundle A cannot instantiate classes exported by bundle B. Usually, this is not a problem, because the call just waits until bundle B finishes starting. But in this case, a deadlock occurs, because bundle B won't finish until bundle A instantiates that class, and A won't instantiate that class until bundle B finishes. I think it has to do with the fact that while a bundle is STARTING it is not RESOLVED nor INSTALLED, and therefore no classes can be exported. Am I right? I mean, is this "my fault" in the sense that the spec states that the platform should act in this way, or is it a bug? Thanks!! Manuel Santillan |
From: Paramjeet S. <pa...@re...> - 2004-05-24 12:50:37
|
Hi,=0A=0AThanks for ur response, currenlty we are studying fesibility to po= rt OSCAR on aJile's aJ-100 java processor. The problem is aJ-100 supports C= LDC runitme, I guess Oscar uses lot of user defined class loaders.Now I'm s= tuck as to how to make this porting possible. =0A=0AWhere can I get more In= fo on user defined class loaders & any workarounds to make this possible.= =0A=0AHav a nice day=0A=0AParamjeet=0A=0A=0A=0A>Today's Topics:=0A>=0A> = 1. Re: oscar-osgi-devel digest, Vol 1 #116 - 1 msg (Didier Donsez)=0A> 2= . Re: CLDC support (Michel D'Hooge)=0A> 3. Re: CLDC support (Richard S. = Hall)=0A>=0A>--__--__--=0A>=0A>Message: 1=0A>Date: Fri, 21 May 2004 09:37:1= 5 +0200=0A> From: Didier Donsez <did...@im...>=0A>To: oscar-osgi-d= ev...@li...=0A>Subject: [oscar-devel] Re: oscar-osgi-devel d= igest, Vol 1 #116 - 1 msg=0A>=0A>This main problem of J2ME/CLDC (Connected = limited device configuration)=0A>is the KVM.=0A>The KVM does not support us= er-defined class loader loaders such as the=0A>OSCAR class loader=0A>But so= me VM (J9) proposes the J2ME/CLDC (Connected limited device=0A>configuratio= n)=0A>and they supports user-defined class loaders=0A>=0A>Didier=0A>=0A>=0A= >=0A>--__--__--=0A>=0A>Message: 2=0A>Date: Fri, 21 May 2004 11:33:45 +0200= =0A> From: Michel D'Hooge <mic...@tr...>=0A>To: oscar-devel <o= sca...@li...>=0A>Subject: Re: [oscar-devel] CLDC s= upport=0A>=0A>Paramjeet Singh wrote:=0A>=0A> >=0A> >Hi Everybody,=0A> >=0A>= >I'm new to this forum and Oscar. Looks like Oscar is build on Jdk1.4. In = my application I want to use Oscar on J2ME based CLDC (Connected limited de= vice configuration). Is it possible to do this?=0A> >=0A> >=0A>I don't thin= k that the limitations in CLDC (I didn't find the exact=0A>list) could prev= ent you to use OSGi/Oscar. You need multiple class=0A>loaders but besides t= his OSGi is quite "standard" in the classes it uses.=0A>=0A>I know it has b= een used with Personal Java. You can look there:=0A>http://www-adele.imag.f= r/~chomats/poscar/OSCAR_porting_on_PersonalJava.html=0A>Unfortunately, Osca= r has quite changed since that time. I tried to adapt=0A>the changes to the= last version of Oscar, but I lacked of time and then=0A>I will wait for th= e 1.0 release...=0A>=0A>Finally Richard wrote that he ran Oscar unchanged o= n the experimental=0A>J2ME Personal Profile for the Sharp Zaurus...=0A>(I d= on't know why but the May emails archive is not available on=0A>sourceforge= , so I have no URL to provide)=0A>=0A>--=0A>Michel D'Hooge=0A>=0A>=0A>=0A>= =0A>--__--__--=0A>=0A>Message: 3=0A>Date: Fri, 21 May 2004 11:48:48 +0200= =0A> From: "Richard S. Hall" <he...@un...>=0A>To: oscar-devel <osc= ar-...@li...>=0A>Subject: Re: [oscar-devel] CLDC sup= port=0A>=0A>Michel D'Hooge wrote:=0A>=0A> > Finally Richard wrote that he r= an Oscar unchanged on the experimental=0A> > J2ME Personal Profile for the = Sharp Zaurus...=0A> > (I don't know why but the May emails archive is not a= vailable on=0A> > sourceforge, so I have no URL to provide)=0A>=0A>=0A>This= is correct and was recently re-verified. I will make sure that the=0A>1.0.= 0 release also works on my Zaurus.=0A>=0A>NOTE: Not all of the example bund= les work on Personal Profile, I am only=0A>talking about the core framework= and command shell bundles. Other=0A>bundles may or may not work.=0A>=0A>->= richard=0A>=0A>=0A>=0A>--__--__--=0A>=0A>_________________________________= ______________=0A>oscar-osgi-devel mailing list=0A>oscar-osgi-devel@lists.s= ourceforge.net=0A>https://lists.sourceforge.net/lists/listinfo/oscar-osgi-d= evel=0A>=0A>=0A>End of oscar-osgi-devel Digest=0A=0A=0A =A0=0A |
From: Richard S. H. <he...@un...> - 2004-05-21 09:48:48
|
Michel D'Hooge wrote: > Finally Richard wrote that he ran Oscar unchanged on the experimental > J2ME Personal Profile for the Sharp Zaurus... > (I don't know why but the May emails archive is not available on > sourceforge, so I have no URL to provide) This is correct and was recently re-verified. I will make sure that the 1.0.0 release also works on my Zaurus. NOTE: Not all of the example bundles work on Personal Profile, I am only talking about the core framework and command shell bundles. Other bundles may or may not work. -> richard |
From: Michel D'H. <mic...@tr...> - 2004-05-21 09:34:39
|
Paramjeet Singh wrote: > >Hi Everybody, > >I'm new to this forum and Oscar. Looks like Oscar is build on Jdk1.4. In my application I want to use Oscar on J2ME based CLDC (Connected limited device configuration). Is it possible to do this? > > I don't think that the limitations in CLDC (I didn't find the exact list) could prevent you to use OSGi/Oscar. You need multiple class loaders but besides this OSGi is quite "standard" in the classes it uses. I know it has been used with Personal Java. You can look there: http://www-adele.imag.fr/~chomats/poscar/OSCAR_porting_on_PersonalJava.html Unfortunately, Oscar has quite changed since that time. I tried to adapt the changes to the last version of Oscar, but I lacked of time and then I will wait for the 1.0 release... Finally Richard wrote that he ran Oscar unchanged on the experimental J2ME Personal Profile for the Sharp Zaurus... (I don't know why but the May emails archive is not available on sourceforge, so I have no URL to provide) -- Michel D'Hooge |
From: Didier D. <did...@im...> - 2004-05-21 07:38:38
|
This main problem of J2ME/CLDC (Connected limited device configuration) is the KVM. The KVM does not support user-defined class loader loaders such as the OSCAR class loader But some VM (J9) proposes the J2ME/CLDC (Connected limited device configuration) and they supports user-defined class loaders Didier |
From: Paramjeet S. <pa...@re...> - 2004-05-20 13:53:16
|
=A0=0AHi Everybody,=0A=0AI'm new to this forum and Oscar. Looks like Oscar= is build on Jdk1.4. In my application I want to use Oscar on J2ME based CL= DC (Connected limited device configuration). Is it possible to do this? =0A= =0AWhat should be the approach to make this possible, as I'm terribly stuck= . Any pointers in this direction would be really appreciated.=0A=0AHave a n= ice day!!=0AParamjeet=20 |
From: Richard S. H. <he...@un...> - 2004-05-18 22:17:37
|
Okay, I wanted to get another beta release out the door because I am leaving for ten days and I didn't want you guys to think there was no progress being made! :-) I will be at a multiple conferences and will largely be out of email contact, so if someone posts a message to the mailing list, I hope that it can wait or others try to help out. The new beta is "1.0.0beta5" and is available from the previous beta URL for all of those who requested to beta test. You can use the Oscar installer to download user and API documention...as always, please read the changes. I hope this beta release represents the last major changes before the final release of 1.0.0. In particular, I have separated the example bundle and Oscar services from the "org.ungoverned.oscar" package hierarchy, put them under "org.ungoverned.osgi.bundle" and "org.ungoverned.osgi.service", respectively. The major impact here will be if you were using Oscar's services in your bundles, for example, if you were creating custom shell commands. If that is the case, you will need to modify your bundles to use the new service names. In the end, I think this will be much better and more sustainable that the old approach. Now the Oscar package is purely for the OSGi framework implementation. Eventually, all bundles will be available via OBR and the bundle repository Web page. All bundles become separate projects into themselves, although I have crafted the build files so that they easily integrate into Oscar's build file (Ant 1.6 is now required)...I will document this more later. For now, you can access all bundles via OBR or the web. Web access is available here: http://oscar-osgi.sf.net/repo/ And for source here: http://oscar-osgi.sf.net/repo-src/ Regarding OBR, I have re-implemented most of it, although I didn't have time to implement the new "update" feature or "download source" feature, but it now use XML and has the new (and much improved) syntax. So, please check it out. I like it much better! It is quite possible that some of the bundles might be broken due to the above mentioned package renaming...I have not tested them all thoroughly. Please let me know if you run into any problems. I am really pleased with how the 1.0.0 release is shaping up. I think that is everything I wanted to say, I hope that I didn't introduce any major bugs just before I leave for ten days, but I am sure I will find out when I get to check my email. :-) Thanks. Have fun. -> richard |
From: Richard S. H. <he...@un...> - 2004-05-14 09:44:01
|
Didier Donsez wrote: > > A additional syntax could use a LDAP filter > > obr install "Service Binder" > (&(bundle-version>=1.0.0)(!(bundle-state=alpha))(signature=*)) Interesting idea, but I think I will pass on that for the time being. :-) Actually, the possibility of a "-filter" switch might not be bad, but for standard syntax it is probably overkill. -> richard |
From: Didier D. <did...@im...> - 2004-05-14 09:34:04
|
A additional syntax could use a LDAP filter obr install "Service Binder" (&(bundle-version>=3D1.0.0)(!(bundle-state=3D= alpha))(signature=3D*)) osc...@li... a =E9crit: >Send oscar-osgi-devel mailing list submissions to > osc...@li... > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel >or, via email, send a message with subject or body 'help' to > osc...@li... > >You can reach the person managing the list at > osc...@li... > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of oscar-osgi-devel digest..." > > >Today's Topics: > > 1. Re: Proposed OBR command syntax (Richard S. Hall) > >--__--__-- > >Message: 1 >Date: Wed, 12 May 2004 19:59:14 +0200 >From: "Richard S. Hall" <he...@un...> >To: oscar-devel <osc...@li...> >Subject: Re: [oscar-devel] Proposed OBR command syntax > >Stephane Frenot wrote: > > =20 > >>Yes, I already have such problems on my inner applications. >>All bundle managing scheme (rpm, deb, ebuilds) map version to archive >>names... obr should also do that. I think the earlier the better... >>=20 >> >> =20 >> > >There are many issues here: > > 1. OBR is just intended to be simple. > 2. OBR meta-data is exactly the bundle meta-data (modulo some additio= ns). > 3. Something that solved every problem would be great, but I don't > have the time to do it. > >Related to this, while working out at the gym, I began to start to think= =20 >about the fact that OBR meta-data is simply bundle meta-data, thus this=20 >means that we must probably allow spaces in bundle name. OBR "bundle=20 >name" is just the manifest "Bundle-Name", which is intended to be a=20 >human readable string. > >And more to the point, we have to realize that what we are debating is=20 >the command-line syntax to the bundle repository service. If you use the= =20 >new OBR panel for the GUI shell, then these issues sort of go away,=20 >because the user just clicks on the one they want. Thus, if there are=20 >(eventually) multiple versions, they can easily select the one they want= =20 >with the GUI and afterwards Bundle-UpdateLocation is automatically used=20 >to update that installed branch. > >The [proposed] meta-data for the new OBR probably covers most of the=20 >scenarios and it doesn't seem like command-line syntax should dictate=20 >design. > >So, while syntax like... > > obr install "Service Binder";1.2.0 > > or for non-space bundles: > > obr install log;1.1.0 > >...may seem a little verbose, is it really a problem? > >-> richard > >p.s. Most people do not really realize the fine level of decision making= =20 >that goes into project management, huh? :-) > > > >--__--__-- > >_______________________________________________ >oscar-osgi-devel mailing list >osc...@li... >https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel > > >End of oscar-osgi-devel Digest > > =20 > --=20 --------------------------------------------------------- Didier DONSEZ Laboratoire LSR, Institut Imag, Universite Joseph Fourier Bat. C, 220 rue de la Chimie, Domaine Universitaire BP 53, 38041 Grenoble Cedex 9, France GPS : lat 45=B011'37"N, lon 05=B046'15"E Tel : +33 4 76 63 55 49 Fax : +33 4 76 63 55 50 mailto:Did...@im... URL: http://www-adele.imag.fr/~donsez --------------------------------------------------------- |
From: Richard S. H. <he...@un...> - 2004-05-12 17:59:15
|
Stephane Frenot wrote: >Yes, I already have such problems on my inner applications. >All bundle managing scheme (rpm, deb, ebuilds) map version to archive >names... obr should also do that. I think the earlier the better... > > There are many issues here: 1. OBR is just intended to be simple. 2. OBR meta-data is exactly the bundle meta-data (modulo some additions). 3. Something that solved every problem would be great, but I don't have the time to do it. Related to this, while working out at the gym, I began to start to think about the fact that OBR meta-data is simply bundle meta-data, thus this means that we must probably allow spaces in bundle name. OBR "bundle name" is just the manifest "Bundle-Name", which is intended to be a human readable string. And more to the point, we have to realize that what we are debating is the command-line syntax to the bundle repository service. If you use the new OBR panel for the GUI shell, then these issues sort of go away, because the user just clicks on the one they want. Thus, if there are (eventually) multiple versions, they can easily select the one they want with the GUI and afterwards Bundle-UpdateLocation is automatically used to update that installed branch. The [proposed] meta-data for the new OBR probably covers most of the scenarios and it doesn't seem like command-line syntax should dictate design. So, while syntax like... obr install "Service Binder";1.2.0 or for non-space bundles: obr install log;1.1.0 ...may seem a little verbose, is it really a problem? -> richard p.s. Most people do not really realize the fine level of decision making that goes into project management, huh? :-) |
From: Michel D'H. <mic...@tr...> - 2004-05-12 15:27:12
|
Erik Wistrand wrote: > Granted, this makes some bootstrapping sensitive to version changes, Well, not that much. If you compare to a debian installation (from a CD, let's say), you start with packages (OSGi=bundles) from the CD, and then you can upgrade through the network (Oscar=OBR). So unless you remove the initial bundles AND you want to start a new framework (by providing a different name when Oscar starts), it should be ok. I think if we want to improve OBR, we need to consider what is used in other big projects in order not to reinvent the wheel and waste resources. It would be very nice to have something as powerful as the debian apt/dpkg tools. But who can afford to develop it? Maybe someone knows of something quite similar already in Java... in the jakarta world? > PS. I also dislike spaces, but it's kind of hard to forbid them. Well, it is just a bundle name for OBR... In debian (sorry, this is MY reference ;-) , you can't use space in package name and the underscore is reserved to separate the name from the version. So you can't even you it ;-) Michel |
From: Erik W. <er...@wi...> - 2004-05-12 14:58:54
|
Stephane Frenot wrote: > All bundle managing scheme (rpm, deb, ebuilds) map version to archive > names... obr should also do that. I think the earlier the better... I second that. I've got several request from developers needing version number on individual bundle files, just because they use an external repository for bundles (read: Maven). That's why the KF build system nowadays generates bundles on the form name-<version>.jar where version is the exakt string as in the manifest attribute Bundle-Version. Granted, this makes some bootstrapping sensitive to version changes, but you do catch the cases where APIs or important functionality actually change from one version to another. Even if obr names != bundle jar file names, I think it makes sense to handle the version number in both places to reduce errors. /Erik W PS. I also dislike spaces, but it's kind of hard to forbid them. -- Erik Wistrand, wis...@kn... |
From: Stephane F. <ste...@in...> - 2004-05-12 14:05:34
|
On Wed, May 12, 2004 at 03:46:35PM +0200, Michel D'Hooge wrote: > Richard S. Hall wrote: >=20 > >> obr -start Logger_0.1 > >> obr -start Logger > > > We can use another character to identify version number (i.e. ; or : or= =20 > whatever sounds nice). >=20 > >I don't really like to encode additional information into the name,=20 > >since we have a separate version attribute. Perhaps in the future when= =20 > >the bundle repository has multiple versions we make this a parameter=20 > >that can be passed in or we require the bundles to have different=20 > >names, like "Log" and "Log Devel". It's a too simplified view of the problem. I have two examples: - I have two identical bundles but they embedded two version of JMX (1.0 = and 2.0). - You send me two different versions of obr... Both are called obr, but interface methods signatures are differents, and it breaks only at run-= time... Of course I can name them differently, but it should be simpler to manage that immediatly. >=20 > I believe that Debian package naming policy is quite complete and well=20 > tested. But we are not that far that we need such a naming tool... Yes, I already have such problems on my inner applications. All bundle managing scheme (rpm, deb, ebuilds) map version to archive names... obr should also do that. I think the earlier the better... /stephane --=20 Stephane Frenot - Associate professor CITI/ARES - INSA lyon - Bat. L=E9onard de Vinci 20, av. A. Einstein - 69621 Villeurbanne Cedex Email: mailto:ste...@in... Web : http://ares.insa-lyon.fr/~sfrenot/ ICQ : 643346 (et oui !) Tel : +33 472 436 422 / +33 617 671 714 ----------------------------------------------------------------- |