[news.eclipse.platform.pde] Re: Trying to have automated PDE build for l

["Mohamed Hussein" <mamado+eclipse@xxxxxxxxx>]

WOW, This is perfectly what I was looking for.

Thanks a LOT Ivica, this worked like a charm.

"Ivica Loncar" <iloncar.mlIQTEST@xxxxxxxxx> wrote in message 
news:d8d7224183c08cbfedc104fff28@xxxxxxxxxxxxxxxxxxx
> Hello Mohamed,
>
>> Hello,
>>
>> I am trying to setup an automated PDE build for a large RCP project,
>> but I am getting a lot of issues.
>>
>> I have tried a smaller application with less dependencies and it
>> worked fine.
>>
>> The main areas I am having issues with are:
>> 1- Setting correct feature definitions for the product (I will post
>> about
>> this separately) but the question here. Is it required to have my
>> product
>> depends on featurs, or can it work with plugins? (I don't need p2
>> update)
>
> You can get away with plugins but I wouldn't recommend it. It will be 
> easier if you use features. It's relatively easy to define features.
> The only issue is that we have to update them when we change target 
> platform.
> Fortunately it doesn't happen very often so it's not a big problem.
>
>> 2- Target Platform dependency
>> I have setup my target platform in separate directories: 1 folder
>> contains eclipse sdk, another contains delta-pack, another one contains
> CDT,
>> other contains other plugins, ...
>
> Same here. We have directory that represent target platform. It's 
> structure looks like this:
>
> workspace
>  +-target_platform_project
>     +- features
>     +- plugins
>     +- deltapack
>     +- sources
>         +-
>     +- spring
>         +- plugins
>             +- ... springsource bundles ....
>     +- slf4j
>         +- jcl-over-slf4j
>         +- .....
>     +-hibernate
>         +....
>     +....
>
> This directory layout can be built from an ant script or by hand and 
> checked into the repository
> (that's the easiest way to give common platform to all developers on the 
> project).
>
> features and plugins are from eclipse RCP SDK. Notice that you don't have 
> to use this layout.
> You could be more consistent and have:
>
> workspace
>  +-target_platform_project
>     + RCP_SDK
>        +- features
>        +- plugins
>        .....
>     +- deltapack
>     +- sources
>         +-
>     ....
>
>> I don't understand what does the baseLocation property mean in that
>> case?
>
> It represents directory containing prebuilt features and plug-ins against 
> which the product is compiled and assembled.
> In the example above it would be path to: 
> ${workspace}/target_platform_project since it contains features and 
> plugins folders from eclipse RCP SDK that we compile against.
>
>> it is currently pointing to the eclipse sdk folder, and I am getting
>> errors about missing dependencies (CDT).
>> I tried to set the pluginPath variable to contain the directories
>> containing my plugins in addition to all the target platform directories,
>> but it doesn't seem to have an effect.
>> a. Do I need to "install" all the dependencies in the eclipse platform
>> installation? Can't I keep it in separate folders?
>
> You're right. pluginPath should be enough. You have to set it up 
> correctly.
> For example, in our build file we use something like this to set 
> pluginPath:
>
> <path id="target.platform.plugins">
> <fileset dir="${baseLocation}/slf4j">
> <include name="*.jar"/>
> </fileset>
> <fileset dir="${baseLocation}/spring-security/plugins">
> <include name="*.jar"/>
> </fileset>
> <fileset dir="${baseLocation}/spring/plugins">
> <include name="*.jar"/>
> </fileset>
>                          <!-- ...... -->
> <fileset dir="${baseLocation}/openoffice">
> <include name="**/*.jar"/>
> </fileset>
>                          <pathelement 
> location="${baseLocation}/deltapack/eclipse"/>
>             </path>
>
>             <property name="pluginPath" refid="target.platform.plugins" 
> description="A platform path-separator separated list of locations to find 
> additional plug-ins and features." />
>
> Also, we do not use feature based build since we're building a product so 
> instead of importing
>            <import file="${eclipse.pdebuild.scripts}/build.xml" />
>
> we import
> <import file="${eclipse.pdebuild.scripts}/productBuild/productBuild.xml" 
> />
>
>
> You have to be careful with pluginPath and not forget something... I guess 
> the easiest way would be to have an ant task that would import .target 
> definition but unfortunately I think there is no such task.
>
>> 2. Must I copy my plugins and features into the plugins and features
>> directories in the build area, or can I use pluginPath to avoid that?
>> I thought from Andrew's post
>> http://aniefer.blogspot.com/2008/06/example-headless-build-for-rcp-product.html
>> that pluginPath can eliminate that need.
>
> You have to copy all your plugins and features that you intend to build. 
> If you have prebuilt artifacts in your artifact repository (like nexus) or 
> directory, you can add them to the pluginPath as above and it should work.
>
> -- 
> Ivica Loncar
>
>