Home » Eclipse Projects » Plugin Development Environment (PDE) » Plugin Development Process
|
| Re: Plugin Development Process [message #55200 is a reply to message #55173] |
Wed, 15 April 2009 07:25   |
 Ankur Sharma
Messages: 84
Registered: July 2009 |
Member |
|
|
adscools wrote:
> Hi all,
> I am new to eclipse plugin development. I want to develop a plugin
> which will have different perspectives, views, etc. I just want to know
> whether it is better to create only one project and have all different
> gui parts as different package of it, or generate different projects for
> each GUI part and then combine it in one product plugin?
> Also i want to know the best practices to developed the plugin so
> that it can be maintainable, and can be used with different versions of
> Eclipse.
> Thanks in advance.
>
> Regards,
> Adscools
>
If having it all in one project is OK. If you look at PDE code itself...all the UI stuff goes into org.eclipse.pde.ui - this has all the perspective, views, editors, etc. This way itself for someone to locate the code - makes it intuitive.
However, if you are building a real heavy UI (heavier than eclipse) then having separate plugins would be advisable - but thats just for the sake of braking a heavy plugin into smaller chunks.
Having said all that, I believe the real criteria should be the plugin loading. If a functionality is rarely required and is fairly heavy, keep it in a separate plugin so that its loaded only when its needed.
Did I confuse you even more? :-)
--
hth,
Ankur..
|
|
| |
| Re: Plugin Development Process [message #55640 is a reply to message #55559] |
Thu, 16 April 2009 11:43 |
Ankur Sharma
Messages: 84
Registered: July 2009 |
Member |
|
|
adscools wrote:
> Hi Ankur,
> Thanks for reply. As far as I understood from your reply is,
> Break the plugin in different plugins if
> 1. It has heavy GUI
> 2. Depending upon the need of the functionality - for the loading
> sake.
> My plugin doesn't contain heavy GUI. It does contain functionalities
> which are rarely needed, but I don't think so that functionalities
> should be broken into different plugins.
> I want to know this from the maintenance and reusability perspective. If
> I want to extend/change some of the code/functionality of the plugin,
> then it should be easy. Also if it gets extended then it should be easy
> to maintain different versions of the plugin. For that sake, should I
> break the code and ui part in different plugins or should I make it in
> only one plugin? I want to know the different pros and cons of the two
> approaches.
>
> Thanks,
> adscools
>
>
So I guess in this case breaking the plugin or not is the real issue. You want reuse without
compromising on maintainability. This more a design consideration. If you wish to have more code
reuse, then make public interfaces and abstract and base classes. While keep your implementations
internal. Have a look at org.eclipse.pde.ui code. This way you expose only what could be required
for other plugins to extend the capability. Provide extension points if possible. At the same time
you keep your implementation internal to that plugin, thus easier to maintain. You can leverage API
Tooling to keep track of your API and changes to it.
--
hth,
Ankur..
|
|
|
| Re: Plugin Development Process [message #595203 is a reply to message #55173] |
Wed, 15 April 2009 07:25 |
Ankur Sharma
Messages: 84
Registered: July 2009 |
Member |
|
|
adscools wrote:
> Hi all,
> I am new to eclipse plugin development. I want to develop a plugin
> which will have different perspectives, views, etc. I just want to know
> whether it is better to create only one project and have all different
> gui parts as different package of it, or generate different projects for
> each GUI part and then combine it in one product plugin?
> Also i want to know the best practices to developed the plugin so
> that it can be maintainable, and can be used with different versions of
> Eclipse.
> Thanks in advance.
>
> Regards,
> Adscools
>
If having it all in one project is OK. If you look at PDE code itself...all the UI stuff goes into org.eclipse.pde.ui - this has all the perspective, views, editors, etc. This way itself for someone to locate the code - makes it intuitive.
However, if you are building a real heavy UI (heavier than eclipse) then having separate plugins would be advisable - but thats just for the sake of braking a heavy plugin into smaller chunks.
Having said all that, I believe the real criteria should be the plugin loading. If a functionality is rarely required and is fairly heavy, keep it in a separate plugin so that its loaded only when its needed.
Did I confuse you even more? :-)
--
hth,
Ankur..
|
|
| |
| Re: Plugin Development Process [message #595397 is a reply to message #55559] |
Thu, 16 April 2009 11:43 |
Ankur Sharma
Messages: 84
Registered: July 2009 |
Member |
|
|
adscools wrote:
> Hi Ankur,
> Thanks for reply. As far as I understood from your reply is,
> Break the plugin in different plugins if
> 1. It has heavy GUI
> 2. Depending upon the need of the functionality - for the loading
> sake.
> My plugin doesn't contain heavy GUI. It does contain functionalities
> which are rarely needed, but I don't think so that functionalities
> should be broken into different plugins.
> I want to know this from the maintenance and reusability perspective. If
> I want to extend/change some of the code/functionality of the plugin,
> then it should be easy. Also if it gets extended then it should be easy
> to maintain different versions of the plugin. For that sake, should I
> break the code and ui part in different plugins or should I make it in
> only one plugin? I want to know the different pros and cons of the two
> approaches.
>
> Thanks,
> adscools
>
>
So I guess in this case breaking the plugin or not is the real issue. You want reuse without
compromising on maintainability. This more a design consideration. If you wish to have more code
reuse, then make public interfaces and abstract and base classes. While keep your implementations
internal. Have a look at org.eclipse.pde.ui code. This way you expose only what could be required
for other plugins to extend the capability. Provide extension points if possible. At the same time
you keep your implementation internal to that plugin, thus easier to maintain. You can leverage API
Tooling to keep track of your API and changes to it.
--
hth,
Ankur..
|
|
|
Goto Forum:
Current Time: Sun Dec 22 06:03:29 GMT 2024
Powered by FUDForum. Page generated in 0.04007 seconds |
] 
Search
Help
Register
Login
Home
