Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster » Best practice for RCP project organization
Best practice for RCP project organization [message #659061] Thu, 10 March 2011 20:17 Go to next message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
In trying to isolate issues, I thought it might make sense to at least have a rational consistent project structure across all of my various products / sites / features etc... Not to mention that we should be thinking about consistency acorss Eclipse projects as well. Smile

First, as background, I have my p2 site feature build for a number of p2 only features that are assembled -- this should be orthogonal to the RCP builds. This is also the way my Eclipse hosted project works.

org.eclipse.amp.releng: contains buckminster artifacts for target platform definition (amp-platform), including an mspec (do I need this?) as well as for the site itself (amp).
org.eclipse.amp.build-feature: defines all of the dependencies, plus buckminster.cspex that defines all of the ant packaging calls (package.amp-Update...) in packaging.ant.

Then -- and here's where I'm more unsure -- for an Eclipse RCP project, I've actually done it t least two different ways:

1)

a) Application Feature Project: Contains all project and non-project dependencies, no buckminster artifacts.
b) RCP Feature Project: Contains feature defining all dependencies on a) as well as .product and all buckminster artifacts.

2)

a) RCP Feature Project: Contains a feature with all of the project and non-project dependencies as well as a set of Buckminster artifacts for the feature
b) Buckminster Site Project. Not a Feature, contains buckminster artifacts for defining the build and perhaps the target platform...damn, I'm not sure what this project does!


I think the reason that I had 2 a) is if you combine a and b then Buckminster doesn't have a buckminster only project and it needs that somehow. But I'm thoroughly confused a to why. Sorry to be so unclear, but what's the most logical, simple way, trouble free way to set this up?

thanks,

Miles
Re: Best practice for RCP project organization [message #659091 is a reply to message #659061] Thu, 10 March 2011 23:14 Go to previous messageGo to next message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
Miles Parker wrote on Thu, 10 March 2011 15:17

1)

a) Application Feature Project: Contains all project and non-project dependencies, no buckminster artifacts.
b) RCP Feature Project: Contains feature defining all dependencies on a) as well as .product and all buckminster artifacts.

2)

a) RCP Feature Project: Contains a feature with all of the project and non-project dependencies as well as a set of Buckminster artifacts for the feature
b) Buckminster Site Project. Not a Feature, contains buckminster artifacts for defining the build and perhaps the target platform...damn, I'm not sure what this project does!



I got the first one wrong, so to be clear, let's just use the Ralf's mail app setup. That's:

a) Application Feature Project: Contains all project and non-project dependencies, as well as .product, no buckminster artifacts.
b) RCP Feature Project: Contains feature defining dependency on a), ant file and all buckminster artifacts.

I think that that's the way to go but would be interested in hearing other suggestions. I discovered the real reason that my app isn't working is something different. See follow up post.
Re: Best practice for RCP project organization [message #659118 is a reply to message #659091] Fri, 11 March 2011 07:07 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
On 2011-03-11 00:14, Miles Parker wrote:
> Miles Parker wrote on Thu, 10 March 2011 15:17
>> 1)
>>
>> a) Application Feature Project: Contains all project and non-project dependencies, no buckminster artifacts.
>> b) RCP Feature Project: Contains feature defining all dependencies on a) as well as .product and all buckminster
>> artifacts.
>>
>> 2)
>>
>> a) RCP Feature Project: Contains a feature with all of the project and non-project dependencies as well as a set of
>> Buckminster artifacts for the feature
>> b) Buckminster Site Project. Not a Feature, contains buckminster artifacts for defining the build and perhaps the
>> target platform...damn, I'm not sure what this project does!
>
>
> I got the first one wrong, so to be clear, let's just use the Ralf's mail app setup. That's:
>
> a) Application Feature Project: Contains all project and non-project dependencies, as well as .product, no buckminster
> artifacts.
> b) RCP Feature Project: Contains feature defining dependency on a), ant file and all buckminster artifacts.
>
> I think that that's the way to go but would be interested in hearing other suggestions. I discovered the real reason
> that my app isn't working is something different. See follow up post.

One thing that comes to mind is if you ever want your RCP application to be updatable using p2. In that case you will
publish the actual repository and you need to consider:

a) If your p2 repository should contain all artifacts that are needed or if it is OK to point the user to more than one
repository (say, the Eclipse platform or Helios/Indigo repositories).
b) Split your feature dependencies into includes and requirements. The latter would be third-party things that you're
not the original publisher for and hence, want more relaxed version constraints to.

In this scenario, I've found it favourable to have a site feature where all third-party plug-ins are listed as
'includes'. This site feature only serves as a definition of what's to be included in the repository. It will not be
present as an IU in the repository. The Application Feature would then list all third-party plug-ins as 'requires'. The
net result is a site that is self sufficient so there's no need for the user to also include other repositories when
updating. Still, your application feature will allow updates to the third-party bundles without conflict even if it is
installed together with other features.

Regards,
Thomas Hallgren
Re: Best practice for RCP project organization [message #659119 is a reply to message #659061] Fri, 11 March 2011 07:07 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
On 2011-03-10 21:18, Miles Parker wrote:

> ... including an mspec
> (do I need this?)

Probably not. The default is sufficient for most use cases.

- thomas
Re: Best practice for RCP project organization [message #659282 is a reply to message #659119] Fri, 11 March 2011 19:43 Go to previous messageGo to next message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
Thanks Thomas, readers might also be interested in: https://bugs.eclipse.org/bugs/show_bug.cgi?id=324444.
Re: Best practice for RCP project organization [message #659286 is a reply to message #659119] Fri, 11 March 2011 20:36 Go to previous message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
One other question related to this and that might clarify what I was asking WRT to assigning target platforms aforementioned bug. Is there any way to specify a different target platform for different builds with an IDE? That maybe doesn't make any sense, given that the entire workspace is built against the target platform, but I have a number of cases where I have different applications that I want to build from the same workspace for convenience. I can do that with PDE export, but it doesn't seem that there is a way to do that with the approach we discussed in the referenced bug?
Previous Topic:Indigo / 3.7 / 1.4
Next Topic:Windows->Linux migration
Goto Forum:
  


Current Time: Fri Sep 19 06:03:57 GMT 2014

Powered by FUDForum. Page generated in 0.01759 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software