Malnormalulo: Comment provided by Malnormalulo - via ArticleComments extension - 2017-03-15 15:39:27

Comment provided by Malnormalulo - via ArticleComments extension

←Older revision Revision as of 15:39, 15 March 2017
Line 70: Line 70:
--Sergey 14:15, 23 October 2013 (CEST)
--Sergey 14:15, 23 October 2013 (CEST)
 +
</div>
 +
== Malnormalulo said ... ==
 +
 +
<div class='commentBlock'>
 +
"In my opinion the fact that I provide an Activator should mean that whenever somebody wants to use me (e.g. activate me), I want that Activator to be called. Why this is not true in OSGi?"
 +
 +
In OSGi, a bundle which has not been started can provide packages (classes), but not services (objects). To me at least, this makes intuitive sense; classes don't need to be initialized'''*''', but objects do.
 +
 +
You may object that a class might, e.g., make use of a singleton which does need initialization. This would be one reason that an OSGi best practice is to only expose an API (i.e., interfaces, exceptions, maybe some simple beans) through your exported packages, and to leave the implementation to service objects defined by private classes. This way, your exported packages remain initialization-free, and references may be made to them without worry regardless of the state of the system.
 +
 +
You may then ask what the point is in allowing an API to be used when the implementation is not available. Even if the API does not, in itself, require initialization, it doesn't necessarily seem useful to have access to it when no implementation is available. In many systems, there's no point at all, and you'd be entirely right to note this as a shortcoming!
 +
 +
But other systems take advantage of OSGi's dynamic nature by doing things like ''watching'' for services that implement the API. In the whiteboard pattern (an OSGi-specific variant of the observer pattern) an "observable" object registers no services, instead listening for observers to register services that act as callbacks. When it boots up, the observable code is probably not yet aware of any concrete implementations of the callback interface. Nevertheless, it needs to know about the interface so that it can listen for new implementations that later become available. It is therefore necessary that the API be available even when implementors are not.
 +
 +
'''''<nowiki>*</nowiki>''' This isn't always true, but if a class ''does'' need to be initialized, it can usually just be a singleton object instead, which is what OSGi would recommend.''
 +
 +
 +
"However I understand the OSGi may have problem - there does not seem to be a bulk start operation."
 +
 +
This is indeed a problem. Launching OSGi applications is tedious. Various abstractions, like Karaf's "features" and (I think) WebSphere Application Server's "Enterprise Bundle Archives", have been layered on top of OSGi to express structures composed of multiple bundles which may be started and stopped together. There is no standard, though, and I can't vouch for how well any of them actually accomplish the goal of simplifying OSGi deployment.
 +
 +
 +
"Should we threat OSGi as an assembly language for modularity hoping somebody will wrap it with higher level concepts? That would support my conclusions - OSGi helped us see the value of modularity, but proper, widely used modularity should rather not expose OSGi at all."
 +
 +
I, for one, agree. OSGi is too complex to ask every application developer to fully understand it. The assembly language analogy is spot on &ndash; OSGi is largely a ''good thing'', but it's in desperate need of higher-level abstractions. Until we have those, we should regard it as a useful way to solve specific problems, but only to be used when actually necessary.
 +
 +
--[[User:Malnormalulo|Malnormalulo]] 16:39, 15 March 2017 (CET)
</div>
</div>

Apidesign at 11:05, 28 October 2013 - 2013-10-28 11:05:36

←Older revision Revision as of 11:05, 28 October 2013
Line 63: Line 63:
--[[User:JaroslavTulach|JaroslavTulach]] 18:23, 24 November 2011 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 18:23, 24 November 2011 (UTC)
-
== Tristen said ... ==
 
-
<div class='commentBlock'>
 
-
why can't you make all 3 choices at once:-Save Page as MHTML-save html-save whole paghwey ony MHTML or only 2 last variants?
 
-
 
-
--Tristen 20:53, 25 June 2013 (CEST)
 
-
</div>
 
-
== Meganedos said ... ==
 
-
 
-
<div class='commentBlock'>
 
-
Very nice article. I just sblutmed upon your blog and wished to say that I've truly enjoyed browsing your blog articles. After all I will be subscribing to your feed and I hope you write again soon! P.S.> Here's the solution to your quest for higher profits using easy and quick content. You can instantly download hundreds of thousands of excellent articles on over 3000+ niche topics that you might edit and use as you wish. More quality content means more search results traffic and more profit. PLR Articles Marketing is really a relatively new twist on content building and effective traffic generating. Therfore get your pack now! Versie Modrak
 
-
 
-
--Meganedos 01:46, 26 June 2013 (CEST)
 
-
</div>
 
-
== Reinold said ... ==
 
-
 
-
<div class='commentBlock'>
 
-
Thanks, yeah, that was pretty much my point. I don't see how a new color being avalaible would spur buyer's remorse. If you hated the colors avalaible you wouldn't have bought the thing, I'm assuming. After that, what's the big deal?As far as a price drop, I was playing a bit of Michael Pachter there. There's higher potential for a price drop sooner than later because of the PSV, due to lukewarm 3DS sales and the unexpected competitive pricing of the Sony product spurring the sudden announcement of a new color pushing up the timetables. I find it hard to believe they'd announce a new color this quickly of their own volition. That's what they do, right? That's why the Wii and DS Lite were only avalaible in white for like the first 2 years or however long it took (seemed like forever), because they were selling gangbusters and there wasn't a need to kickstart sales yet with a new edition.No attempt at flamebait, and I do have a smartphone, which is why I don't have a pony in this race. I'm speaking strictly as an observer. :) If you're happy with your handheld that's all that shouldn't matter, and it shouldn't bother you that I don't care one way or the other.
 
-
 
-
--Reinold 08:12, 26 June 2013 (CEST)
 
-
</div>
 
-
== Allie said ... ==
 
-
 
-
<div class='commentBlock'>
 
-
Of course, that's an itenrtsnieg point, which makes this exchange of interpretations rewarding.(On the side: From a deployment perspective, everything is a bundle. Because the plugins' folder has a history tied to the original Eclipse modularity system, the name of that folder is confusing. And perhaps a candidate for a change request.Historically, the adoption of OSGi has introduced a level of blurring which makes this discussion fairly complicated. The adoption introduced an overlap in functionality, as there are now different programming patterns available to contribute' or to extend'. As it stands today, the framework taps into those different layers at the same time, creating a mix which lies at the heart of this discussion, I think.Categorizing bundles, for example as a higher-level type such as a plug-in', has become debatable because a bundle can contain a mix of fingerprint meta-data: OSGi declarative services, plugin.xml Eclipse extensions, .Still, I find that sentences like mixing bundles and plug-ins' are still valid given the specific nature of the layers in the framework. Apart from meta-data content in the bundle, there are also life-cycle aspects to consider. I do consider the framework to have become a mix of both: bundles en plug-ins.There is enough to distinguish, enough to warrant that both names remain in existence. Unfortunately, as they are related', making the distinction in some cases is like separating Siamese twins, in which case only some convention helps to make the call. But because sometimes the distinction is clear-cut, I can't help feeling that we will never be able to use a single blanket term.
 
-
 
-
--Allie 19:44, 26 June 2013 (CEST)
 
-
</div>
 
-
== Vikas said ... ==
 
-
 
-
<div class='commentBlock'>
 
-
I could suggest some IDE's or editros, but it's all personal preference. Some people like to use vim or emacs to develop, other people prefer fully functional IDE's like visual studio, netbeans, eclipse, etc.As far as IDE's concerned, you should take a look at these options:-Netbeans.Decent IDE, feels kind of slow but gets the job done.-EclipseSimilar to netbeans.-AptanaA classmate uses this for PHP development. He likes it a lot.-Visual Studio with VS.PHPVS doesn't support PHP out of the box, but there are plugins so you can develop PHP within visual studio. Haven't tried it, but you should check this out if you like visual studio.Not IDE's, but great editros:-Notepad++Simple, fast and gets the job done.-VimHighly customizable, but hard to learn.-EmacsAlso highly customizable, and hard to learn.There's probably more out there, but these are the ones i know about. Just browse through them all and try the ones you think you will like.Once again, there's no best IDE or text editor. Just use the one that you like the most. If you're wondering what i like the most: Visual studio and notepad++ for anything not microsoft related. I'm too lazy to learn emacs or vim.References : Was this answer helpful?
 
-
 
-
--Vikas 05:07, 21 October 2013 (CEST)
 
-
</div>
 
-
== Nikhil said ... ==
 
-
 
-
<div class='commentBlock'>
 
-
The problem with difineng your product based on Features is that it leaves you at the mercy of the various Eclipse projects and how they've chosen to define their Features. Not all of them do what I would consider a good job of it; some (many?) publish only one or a few very coarse-grained Features, rather than taking the time and effort to properly separate and distinguish multiple units of reuse. In the RCP apps I've worked on, bloat was a concern (justified or not) and using Features would have forced us to include and inherit a lot of stuff from Eclipse projects that we didn't really need or want.
 
-
 
-
--Nikhil 15:32, 21 October 2013 (CEST)
 
-
</div>
 
-
== Manish said ... ==
 
-
 
-
<div class='commentBlock'>
 
-
I have a team implementing a apipicatlon on top of RCP right now, and I have to say we almost went with Netbeans rather then eclipse.The biggest problems with RCP are not it's name:1) No Visual Editor for apipicatlons means that every apipicatlon we right looks like Eclipse.2) The steep steep learning curve. The technology behind RCP is solid. Why is programming it so hard? Simple wizards to make actually functional EMF/Resource apipicatlons would be welcome.3) Speaking of which. EMF is so powerful. Why isn't there a forms/wizard based proccess to guide users through:* Create a EMF model.* Create a RCP apipicatlon that edits the EMF object.* Use TENEO extensions to make it write to and from database.* Make it easy to port this apipicatlon into RAP.The EMF + RCP stuff is so powerful that you could easily write a java apipicatlon that does CRUD. If we had the right tooling, it could be as easy as Ruby on Rails, but with a full desktop apipicatlon instead of a stripped down web apipicatlon.The points that Eclipse has going for it:1) EMF is wicked powerful. But where is the documentation to write a useful applciation? Why doesn't the mail app use a EMF model for example?2) OSGI.3) Existing OSGI functionality that can be added into other apipicatlons. Update site, etc. This needs to be easier.
 
-
 
-
--Manish 19:12, 21 October 2013 (CEST)
 
-
</div>
 
-
== Maria said ... ==
 
-
 
-
<div class='commentBlock'>
 
-
I agree with you both as well. The org.eclipse.platform feature in pacariultr is not something I would add directly to a product. I usually add this feature to my target and then pull out the bundles I need into a custom feature.My argument here is really more about whether to use features at all or just stick with bundles. I can't imagine managing a non-trivial RCP app without features, but I'd be interested to hear from someone who has. Do either of you manage your product dependencies using bundles?
 
-
 
-
--Maria 04:21, 22 October 2013 (CEST)
 
-
</div>
 
-
== Rodrigo said ... ==
 
-
 
-
<div class='commentBlock'>
 
-
I agree with you both as well. The org.eclipse.platform feature in parcatulir is not something I would add directly to a product. I usually add this feature to my target and then pull out the bundles I need into a custom feature.My argument here is really more about whether to use features at all or just stick with bundles. I can't imagine managing a non-trivial RCP app without features, but I'd be interested to hear from someone who has. Do either of you manage your product dependencies using bundles?
 
-
 
-
--Rodrigo 04:43, 22 October 2013 (CEST)
 
-
</div>
 
-
== Arzo said ... ==
 
-
 
-
<div class='commentBlock'>
 
-
Features are a great feature, but I have to agree with Eric, the fartuees provided in the eclipse main P2 repository are not good citizens I've passed days trying to identify which fartuees would I use to setup a SDK IDE.There are lot of not described and lot of feature that has duplicated things.I ended up creating my own new Feature and adding the bundles that I wanted to.
 
-
 
-
--Arzo 06:00, 22 October 2013 (CEST)
 
-
</div>
 
-
== Maria said ... ==
 
-
 
-
<div class='commentBlock'>
 
-
thanks for touching this pain point . In my own execnipree when talking with non Plug-in Developers, Eclipse is always perceived as an IDE and almost never as a Application Development Platform. I'm supportive of anything that would help change that.@Josh: I have looked at Eclipse Riena, and I like lots of it, but once again, how does this technology mix and match with everything else? Not well it seems.Josh, we are currently investigating how to allow Riena to mix and match better with existing RCP code-bases. One goal is to enable developers to use parts of Riena instead of forcing them to adopt all or nothing . Another goal is to refactor Riena so one can easily use GUI tools like SWT Designer with our code base.Regards,Elias.
 
-
 
-
--Maria 11:18, 23 October 2013 (CEST)
 
-
</div>
 
-
== Vinicius said ... ==
 
-
 
-
<div class='commentBlock'>
 
-
I will listen to the poscadt, because I will never be able to listen to it live, 3:00 is prime time here, plus I have two home sick!! I am interested in this topic, for now, more as an adult child, but as my children get older I would love for them to feel empowered to have their own boundries (even as children when appropritate!) Thanks! Congratualtions, I'm sure it will be a wonderful success!Kathy recently posted..
 
-
 
-
--Vinicius 11:35, 23 October 2013 (CEST)
 
-
</div>
 
== Sergey said ... ==
== Sergey said ... ==

94.23.238.222: Comment provided by Sergey - via ArticleComments extension - 2013-10-23 12:15:06

Comment provided by Sergey - via ArticleComments extension

←Older revision Revision as of 12:15, 23 October 2013
Line 146: Line 146:
--Vinicius 11:35, 23 October 2013 (CEST)
--Vinicius 11:35, 23 October 2013 (CEST)
 +
</div>
 +
== Sergey said ... ==
 +
 +
<div class='commentBlock'>
 +
/ If I do anything in Linux for pmnigomrrag, I use Eclipse if I need an IDE. I also like doing as much as I can in terminal or even a note pad-like program. On Windows (for school), I really like using Notepad++, so the best alternative in Linux for NP++ that I've found is Geany.
 +
 +
--Sergey 14:15, 23 October 2013 (CEST)
</div>
</div>

94.23.238.222: Comment provided by Vinicius - via ArticleComments extension - 2013-10-23 09:35:33

Comment provided by Vinicius - via ArticleComments extension

←Older revision Revision as of 09:35, 23 October 2013
Line 139: Line 139:
--Maria 11:18, 23 October 2013 (CEST)
--Maria 11:18, 23 October 2013 (CEST)
 +
</div>
 +
== Vinicius said ... ==
 +
 +
<div class='commentBlock'>
 +
I will listen to the poscadt, because I will never be able to listen to it live, 3:00 is prime time here, plus I have two home sick!! I am interested in this topic, for now, more as an adult child, but as my children get older I would love for them to feel empowered to have their own boundries (even as children when appropritate!) Thanks! Congratualtions, I'm sure it will be a wonderful success!Kathy recently posted..
 +
 +
--Vinicius 11:35, 23 October 2013 (CEST)
</div>
</div>

94.23.238.222: Comment provided by Maria - via ArticleComments extension - 2013-10-23 09:18:25

Comment provided by Maria - via ArticleComments extension

←Older revision Revision as of 09:18, 23 October 2013
Line 132: Line 132:
--Arzo 06:00, 22 October 2013 (CEST)
--Arzo 06:00, 22 October 2013 (CEST)
 +
</div>
 +
== Maria said ... ==
 +
 +
<div class='commentBlock'>
 +
thanks for touching this pain point . In my own execnipree when talking with non Plug-in Developers, Eclipse is always perceived as an IDE and almost never as a Application Development Platform. I'm supportive of anything that would help change that.@Josh: I have looked at Eclipse Riena, and I like lots of it, but once again, how does this technology mix and match with everything else? Not well it seems.Josh, we are currently investigating how to allow Riena to mix and match better with existing RCP code-bases. One goal is to enable developers to use parts of Riena instead of forcing them to adopt all or nothing . Another goal is to refactor Riena so one can easily use GUI tools like SWT Designer with our code base.Regards,Elias.
 +
 +
--Maria 11:18, 23 October 2013 (CEST)
</div>
</div>

94.23.238.222: Comment provided by Arzo - via ArticleComments extension - 2013-10-22 04:00:28

Comment provided by Arzo - via ArticleComments extension

←Older revision Revision as of 04:00, 22 October 2013
Line 125: Line 125:
--Rodrigo 04:43, 22 October 2013 (CEST)
--Rodrigo 04:43, 22 October 2013 (CEST)
 +
</div>
 +
== Arzo said ... ==
 +
 +
<div class='commentBlock'>
 +
Features are a great feature, but I have to agree with Eric, the fartuees provided in the eclipse main P2 repository are not good citizens I've passed days trying to identify which fartuees would I use to setup a SDK IDE.There are lot of not described and lot of feature that has duplicated things.I ended up creating my own new Feature and adding the bundles that I wanted to.
 +
 +
--Arzo 06:00, 22 October 2013 (CEST)
</div>
</div>

94.23.238.222: Comment provided by Rodrigo - via ArticleComments extension - 2013-10-22 02:43:44

Comment provided by Rodrigo - via ArticleComments extension

←Older revision Revision as of 02:43, 22 October 2013
Line 118: Line 118:
--Maria 04:21, 22 October 2013 (CEST)
--Maria 04:21, 22 October 2013 (CEST)
 +
</div>
 +
== Rodrigo said ... ==
 +
 +
<div class='commentBlock'>
 +
I agree with you both as well. The org.eclipse.platform feature in parcatulir is not something I would add directly to a product. I usually add this feature to my target and then pull out the bundles I need into a custom feature.My argument here is really more about whether to use features at all or just stick with bundles. I can't imagine managing a non-trivial RCP app without features, but I'd be interested to hear from someone who has. Do either of you manage your product dependencies using bundles?
 +
 +
--Rodrigo 04:43, 22 October 2013 (CEST)
</div>
</div>

188.143.232.12: Comment provided by Maria - via ArticleComments extension - 2013-10-22 02:21:39

Comment provided by Maria - via ArticleComments extension

←Older revision Revision as of 02:21, 22 October 2013
Line 111: Line 111:
--Manish 19:12, 21 October 2013 (CEST)
--Manish 19:12, 21 October 2013 (CEST)
 +
</div>
 +
== Maria said ... ==
 +
 +
<div class='commentBlock'>
 +
I agree with you both as well. The org.eclipse.platform feature in pacariultr is not something I would add directly to a product. I usually add this feature to my target and then pull out the bundles I need into a custom feature.My argument here is really more about whether to use features at all or just stick with bundles. I can't imagine managing a non-trivial RCP app without features, but I'd be interested to hear from someone who has. Do either of you manage your product dependencies using bundles?
 +
 +
--Maria 04:21, 22 October 2013 (CEST)
</div>
</div>

188.143.232.12: Comment provided by Manish - via ArticleComments extension - 2013-10-21 17:12:43

Comment provided by Manish - via ArticleComments extension

←Older revision Revision as of 17:12, 21 October 2013
Line 104: Line 104:
--Nikhil 15:32, 21 October 2013 (CEST)
--Nikhil 15:32, 21 October 2013 (CEST)
 +
</div>
 +
== Manish said ... ==
 +
 +
<div class='commentBlock'>
 +
I have a team implementing a apipicatlon on top of RCP right now, and I have to say we almost went with Netbeans rather then eclipse.The biggest problems with RCP are not it's name:1) No Visual Editor for apipicatlons means that every apipicatlon we right looks like Eclipse.2) The steep steep learning curve. The technology behind RCP is solid. Why is programming it so hard? Simple wizards to make actually functional EMF/Resource apipicatlons would be welcome.3) Speaking of which. EMF is so powerful. Why isn't there a forms/wizard based proccess to guide users through:* Create a EMF model.* Create a RCP apipicatlon that edits the EMF object.* Use TENEO extensions to make it write to and from database.* Make it easy to port this apipicatlon into RAP.The EMF + RCP stuff is so powerful that you could easily write a java apipicatlon that does CRUD. If we had the right tooling, it could be as easy as Ruby on Rails, but with a full desktop apipicatlon instead of a stripped down web apipicatlon.The points that Eclipse has going for it:1) EMF is wicked powerful. But where is the documentation to write a useful applciation? Why doesn't the mail app use a EMF model for example?2) OSGI.3) Existing OSGI functionality that can be added into other apipicatlons. Update site, etc. This needs to be easier.
 +
 +
--Manish 19:12, 21 October 2013 (CEST)
</div>
</div>

188.143.232.12: Comment provided by Nikhil - via ArticleComments extension - 2013-10-21 13:32:31

Comment provided by Nikhil - via ArticleComments extension

←Older revision Revision as of 13:32, 21 October 2013
Line 97: Line 97:
--Vikas 05:07, 21 October 2013 (CEST)
--Vikas 05:07, 21 October 2013 (CEST)
 +
</div>
 +
== Nikhil said ... ==
 +
 +
<div class='commentBlock'>
 +
The problem with difineng your product based on Features is that it leaves you at the mercy of the various Eclipse projects and how they've chosen to define their Features. Not all of them do what I would consider a good job of it; some (many?) publish only one or a few very coarse-grained Features, rather than taking the time and effort to properly separate and distinguish multiple units of reuse. In the RCP apps I've worked on, bloat was a concern (justified or not) and using Features would have forced us to include and inherit a lot of stuff from Eclipse projects that we didn't really need or want.
 +
 +
--Nikhil 15:32, 21 October 2013 (CEST)
</div>
</div>