Home » Eclipse Projects » Plugin Development Environment (PDE) » Generate "Ant build file" outside Eclipse
| |
Re: Generate "Ant build file" outside Eclipse [message #493838 is a reply to message #493827] |
Wed, 28 October 2009 09:13 |
valerossi46 Messages: 10 Registered: October 2009 |
Junior Member |
|
|
Thanks for your answer! It seems t be what i'm looking for!
I wrote an ant script using eclipse.buildScript :
<project name="generateBuildFiles" default="createBuildFile">
<target name="createBuildFile">
<eclipse.buildScript elements="plugins @ com.my.plugin"
buildDirectory="/home/valerossi/myWorkspace/>
</target>
</project>
But when i run it, nothing change in my workspace, nothing seem to be generated in the project folder, even if the output is:
createBuildFile:
BUILD SUCCESSFUL
Any idea of what i'm doing wrong?
Thanks!
[Updated on: Wed, 28 October 2009 09:14] Report message to a moderator
|
|
|
Re: Generate "Ant build file" outside Eclipse [message #496958 is a reply to message #493825] |
Wed, 11 November 2009 21:16 |
Rothmans Messages: 37 Registered: July 2009 |
Member |
|
|
I am seeing exactly same behaviour using Eclipse 3.5.1.
I have a
* main plugin project
* feature project containing the main plugin
* RCP plugin with .product configuration containing my feature;
* Update Site project containing my feature
Everything is checked as is into the source control system.
I can build everything using "Export" option in the Eclipse IDE.
Naturally, I need to build same stuff automatically for continuous integration.
So, I studied PDE headless build manuals for the whole 3 days already and I still cannot automatically build a feature or update site.
The only thing I could achive is to build the whole RCP app headlessly calling standard productBuild.xml.
One could think that to build a single feature from the RCP application could be easier.
Not at all!
Firstly, all feature build manuals are starting from the assumption that :
"all plug-ins and features (both to-build and pre-built) referenced from the feature being built are already locally available on disk. "
After reading this one could think that she already already has everything needed, since all plugins and features are here in the projects and are fully buildable from IDE.
But then the first error comes from the PDE's build.xml:
"${buildDirectory}/features/com.my.feature folder doesn't exist"
Hey! Do they expect me to copy my projects once more to the ${buildDirectory}/feature/com.my.feature?
Apparently they do!
If I prepare that directory the build goes further and now I see another error:
"cannot find ${buildDirectory}/feature/com.my.feature/build.xml "
Of course it's not there, I expect it to be generated automatically.
Oh, well.. Let's generate it manually and put to that deep folder in the buildDirectory... done. Does it work now? No!
cannot find ../MyPluginProjectFolder/build.xml.
Ah.. of course the build.xml was generated in the Eclipse IDE project so it took relative path to the constituent plugin project. But that path is not valid under ${buildDirectory}.
That's where I am stuck at the moment.
Hard to believe that the RCP application build is only the matter of calling standard productBuild.xml and a feature build is such a compicated thing.
And that is not yet all what I need. But I am hoping that as soon as I get feature build.xml generated for me I could use it's targets to generate my update site.
PS: the whole headless PDE building seems to be so unnecessary complicated.
Why does it require generated plugin and feature build file to be called build.xml and the name cannot be customized? I have to move my own integration build.xml files somewhere now to let Eclipse build its plugins.
The PDE build does use already custom eclipse ant tasks. Why aren't they made standalone and not requiring to be run from under Eclipse application using additional ant scripts? Except for some really minor things, like automatic build version change, and, may be, p2 repository metadata generation, I was able to repeat the whole story from scratch using standard Ant tasks. All right, I spent some time for that, which could be saved by that eclipse ant tasks. But, unfortunately, they don't do that for me yet.
|
|
| | |
Re: Generate "Ant build file" outside Eclipse [message #497160 is a reply to message #496958] |
Thu, 12 November 2009 15:59 |
Andrew Niefer Messages: 990 Registered: July 2009 |
Senior Member |
|
|
Sergey Shcherbakov wrote:
> Firstly, all feature build manuals are starting from the assumption that :
> "all plug-ins and features (both to-build and pre-built) referenced from
> the feature being built are already locally available on disk. "
PDE/Build can fetch your code from source control for you, they don't
need to be previously available on disk. The help starts here because
fetching from source control is more advanced and the help needs to
start with something simple so that people can get started.
There is a help page on fetching, you need to set up map files that
specify where your code lives in source control.
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .pde.doc.user/tasks/pde_fetch_phase.htm
> After reading this one could think that she already already has
> everything needed, since all plugins and features are here in the
> projects and are fully buildable from IDE.
>
> But then the first error comes from the PDE's build.xml:
> "${buildDirectory}/features/com.my.feature folder doesn't exist"
>
> Hey! Do they expect me to copy my projects once more to the
> ${buildDirectory}/feature/com.my.feature?
>
> Apparently they do!
> If I prepare that directory the build goes further and now I see another
> error:
> "cannot find ${buildDirectory}/feature/com.my.feature/build.xml "
While the build.xml scripts are generated dynamically where-ever the
feature/plugin is, actually running them is done from static ant scripts
that ships in the pde.build/scripts folder. These static scripts need
to know where the first top level feature is to invoke the build.xml.
By default it assumes that feature is in buildDirectory. Everything
else can be anywhere you want. If your top level feature is not in the
buildDirectory, you need to set the property "elementPath" to the
location of that feature.
>
> PS: the whole headless PDE building seems to be so unnecessary complicated.
> Why does it require generated plugin and feature build file to be called
> build.xml and the name cannot be customized? I have to move my own
> integration build.xml files somewhere now to let Eclipse build its plugins.
Building the Eclipse SDK has been the primary driver for PDE/Build.
The SDK is not a simple build and very much requires a lot of that
complexity. Effort has been made to hide/reduce this complexity when
people don't need it, hence the productBuild.xml.
It was originally named "build.xml" because that was the logical name
for the script that builds the plug-in. Changing the name of the
scripts needs to be done carefully in a way that won't break all the
existing build systems that use PDE/Build. There is a bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=120840.
> The PDE build does use already custom eclipse ant tasks. Why aren't they
> made standalone and not requiring to be run from under Eclipse
> application using additional ant scripts? Except for some really minor
> things, like automatic build version change, and, may be, p2 repository
> metadata generation, I was able to repeat the whole story from scratch
> using standard Ant tasks. All right, I spent some time for that, which
> could be saved by that eclipse ant tasks. But, unfortunately, they don't
> do that for me yet.
The PDE/Build scripts need to be run under Eclipse because to generate
the correct classpath based on the manifest files for each bundle, it
needs to create a full OSGi state to resolve all bundle dependencies.
Also, some of those "minor" things like p2 repositories turn out to not
be so minor in general.
|
|
| |
Re: Generate "Ant build file" outside Eclipse [message #497616 is a reply to message #497160] |
Fri, 13 November 2009 09:50 |
Rothmans Messages: 37 Registered: July 2009 |
Member |
|
|
Andrew, thank you for your comments!
Andrew Niefer wrote on Thu, 12 November 2009 16:59 |
PDE/Build can fetch your code from source control for you, they don't
need to be previously available on disk. The help starts here because
fetching from source control is more advanced and the help needs to
start with something simple so that people can get started.
|
For me it looks like the PDE build infrastructure tries to interfere in my development workspace too much.
The sources usually are gotten with a help of a continuous integration build system, which performs lot more stuff on them then "fetching" to locations convenient for PDE developers.
I cannot change the way our mature build system works in favor of a single project.
Andrew Niefer wrote on Thu, 12 November 2009 16:59 |
Building the Eclipse SDK has been the primary driver for PDE/Build.
The SDK is not a simple build and very much requires a lot of that
complexity.
|
I am not measuring complexity in the number of folders/files needed to be processed.
I am measuring complexity in the number of build scripts, ant tasks, temporary folder locations and duplicate copies of the artifacts during the PDE build.
Andrew Niefer wrote on Thu, 12 November 2009 16:59 |
The PDE/Build scripts need to be run under Eclipse because to generate
the correct classpath based on the manifest files for each bundle, it
needs to create a full OSGi state to resolve all bundle dependencies.
Also, some of those "minor" things like p2 repositories turn out to not
be so minor in general.
|
Sure, no problems with that.
In order to achieve that, you don't need a bunch of hidden ant scripts and internal hardly reusable Ant tasks.
|
|
|
Re: Generate "Ant build file" outside Eclipse [message #497623 is a reply to message #497162] |
Fri, 13 November 2009 10:00 |
Rothmans Messages: 37 Registered: July 2009 |
Member |
|
|
Andrew Niefer wrote on Thu, 12 November 2009 17:12 |
The build is not dependent on the workspace itself, PDE/Build does not
know anything about eclipse workspaces. It is however, dependent on the
location of the projects.
|
I was trying to build from the Worksapce folder, ${basedir}=<worksapce> and my projects were located inside of it.
But apparently it is not enough. One have to specify explicitly where the workspace is (and this is not well documented).
So I got a feeling that PDE build like some other Eclipse based building environemtns (like WindRiver Workbench) rely heaviliy on the metadata stored in the workspace. That is bad style I'd say.
Good if the PDE build doesn't do that.
Andrew Niefer wrote on Thu, 12 November 2009 17:12 |
Note that invoking the eclipse.buildScript target directly is considered
an advanced use of PDE/Build. The pde.build/scripts/build.xml does this
for you. Generally it is simpler to copy the template build.properties,
set 3 properties (topLevelElementId, baseLocation, buildDirectory) and
call the antrunner on the main build.xml.
|
That's exactly what I was starting with.
See my first message with the history of the error messages I went through from that point.
Besides of of my negative impression of the PDE build implementation, there is nothing personal and I very appreciate the help and any of your comments!
|
|
| | | |
Re: Generate "Ant build file" outside Eclipse [message #498001 is a reply to message #497712] |
Fri, 13 November 2009 16:26 |
Andrew Niefer Messages: 990 Registered: July 2009 |
Senior Member |
|
|
Rothmans wrote on Fri, 13 November 2009 06:16 | All right, here we go again trying to build a feature using standard PDE build.xml:
Directory structure:
D:\MyWorkspace
|-build
|-MyFeature
...
|-MyPlugin
|-...
|-build.xml
|-build.proerpties
build.properties (located in the worksapce folder):
builder=${basedir}
pluginPath=${basedir}${path.separator}${progtools.target.eclipse.platform}${path.separator}${deltapack}
buildTempFolder=${buildDirectory}
topLevelElementType=feature
topLevelElementId=com.my.feature
|
Because your top feature that you are building is not under the buildDirectory, you will need to set the property elementPath=${basedir}/MyFeature
The static script genericTargets.xml needs to know the entry point to the generated scripts. The default value of this is basically
elementPath=${buildDirectory}/${topLevelElementType}s/${topLevelElementId} Which is obviously incorrect in your setup.
Using the fetch mechanism would fix this, but only because it would fetch your feature into the buildDirectory where the elementPath points by default. Since you already have your source through continuous integration, it is better to just set the elementPath property.
Also, I'm sure you already are, but make sure your workspace build.xml loads this property file before calling pde.build's build.xml. Generally, PDE/Build will load the file itself, but it needs to know builder first so that it can find the file. As well, the ${basedir}'s here would resolve to the pde.build/scripts folder instead of your workspace.
|
|
| | | | |
Re: Generate "Ant build file" outside Eclipse [message #501247 is a reply to message #499958] |
Tue, 01 December 2009 16:25 |
Rothmans Messages: 37 Registered: July 2009 |
Member |
|
|
Thank you for the comment, Mike.
I am still missing some crucial point at all automated PDE build story.
The project structure I am using was not invented by me. I was simply following numerous examples on the web where projects are created without any naming convention in the flat layout.
Perhaps, those examples are adjusted to work only from Eclipse IDE and they do, but I don't understand why the build script started from IDE can work with flat structure and automated build that uses same build scripts not.
All right, you are telling that I need to follow some particular folder layout to be able to build automaticaly.
First thing that comes into my mind is that the whole temporary build temporary files, scripts etc. comes into my source folders that are under source control.
You know, this is not great to fill out the .Xignore files with all kinds of wierd file names.
Okey, that's minor you'd say.
Then what about version numbers?
The plugin/feature project folder names do must include their version numbers otherwise the build script won't find them. Am I right?
The first thing I tried when I began setting up my automatic build was to raise the folder structure you are talking about and start the PDE build against it. No chance: it expects versions to be part of the project folders names.
So do you mean, I need to create new folder each time I increment the version?
Must the folder name include the "qualifier" suffix in case it is present too? Even if I'd create the folder structure everytime anew, how would I know the correct qualifier suffix before the PDE build starts?
Actualy here I come to my next disappointment.
From historical reasons the third poart of the version gets incremented twise a week in our projects _automatically_ (!). With all those questions above it looks to me that it is (almost?) impossible to get significant version number parts to get changed/incremented automatically and passed to the PDE build.
How do you handle the build version increments? Everytime manually except for qualifier part? sigh...
|
|
| | |
Re: Generate "Ant build file" outside Eclipse [message #501513 is a reply to message #493825] |
Wed, 02 December 2009 15:50 |
Rothmans Messages: 37 Registered: July 2009 |
Member |
|
|
At last I have understood couple of basic pronciples that make possible using automated PDE build.
Apparently they considered obvious and therefore are not mentioned too often in docs and answers.
For those who is battleing to get automatic PDE build working here is what I have discovered.
There are basically two approaches to use automatic PDE build:
I. Using the build.xml exported from the IDE.
Get the plugin project working from withing Eclipse IDE and export the build.xml file.
Check that file in and call it's targets to build automatically.
You'll have to check in that build.xml every time you change anything in the plugin.
You can export the script only as "build.xml" (so, don't put your own build.xml to the project folder).
I am not sure whether this approach would always smoothly work for features.
Product builds won't work in that way I believe.
Anyway, most of my problems arose because I tried to use this approach from the beginning, sincerly believeing that building from inside IDE and using that script from outside should be the same for all kinds of PDE projects.
II. Using the right folder structure.
If you'd like to build any feature and any product you will have to obey to the folder structure the PDE build dictates.
You will need to get your sources (not binaries!!! as it may seem from the manuals) into the following directory structure:
${buildDirectory}/plugins/${your.plugin.id.as.specified.in.t he.META-INF.MANIFEST.MF.file}
${buildDirectory}/features/${your.feature.id.as.specified.in .the.META-INF.MANIFEST.MF.file}
You can put your plugin/feature projects into that folders and check them in. Or, if you want to fully rely on the SCM connection and copy all the stuff once more to your local drive, you can:
* use map files and "fetching" phase of the PDE build script to get your sources into the prescribed folders (didn't try by myself expecting further complications)
* set up your own script that copies the sources into the folder structure above.
Now you can launch the
${target.eclipse.pde.plugin.folder}/scripts/build.xml
for features or
${target.eclipse.pde.plugin.folder}/scripts/productBuild/pro ductBuild.xml
for products, where
${target.eclipse.pde.plugin.folder} is the PDE Eclipse plugin folder usually in the Eclipse distribution you build with. In my case it is
${target.eclipse.platform}/plugins/org.eclipse.pde.build_3.5 .1.R35x_20090820
You must launch these build scripts from under Eclipse and specify some directory locations before doing that.
To build a feature:
<target name="build-feature">
<!-- Input: feature.id -->
<java jar="${target.eclipse.ant.launcher}" fork="true" failonerror="true">
<arg value="-application" />
<arg value="org.eclipse.ant.core.antRunner" />
<arg value="-buildfile" />
<arg value="${target.eclipse.pde.plugin}/scripts/build.xml" />
<arg value="-DbaseLocation=${target.eclipse.platform}" />
<arg value="-DpluginPath=${builder.dir}/plugins${path.separator}${target.eclipse.platform}/plugins${path.separator}${target.eclipse.deltapack}/plugins" />
<arg value="-DbuildDirectory=${projects.root.dir}" />
<arg value="-Dbuilder=${builder.dir}" />
<arg value="-DbuildTempFolder=${temp.build.dir}" />
<arg value="-Dp2.category.definition=file:${category.xml.location}" />
<arg value="-DtopLevelElementType=feature" />
<arg value="-DtopLevelElementId=${feature.id}" />
<arg value="-Dp2.build.repo=file:${path.to.local.update.site}" />
</java>
</target>
To build a product:
<target name="build-product">
<java jar="${target.eclipse.ant.launcher}" fork="true" failonerror="true">
<arg value="-application" />
<arg value="org.eclipse.ant.core.antRunner" />
<arg value="-buildfile" />
<arg value="${target.eclipse.pde.plugin}/scripts/productBuild/productBuild.xml" />
<arg value="-DbaseLocation=${target.eclipse.platform}" />
<arg value="-DpluginPath=${builder.dir}/plugins${path.separator}${target.eclipse.platform}/plugins${path.separator}${target.eclipse.deltapack}/plugins" />
<arg value="-DbuildDirectory=${project.root.dir}" />
<arg value="-Dbuilder=${builder.dir}" />
<arg value="-DbuildTempFolder=${temp.build.dir}" />
<arg value="-Dp2.category.definition=file:${category.xml.location}" />
<arg value="-Dproduct=${product.file.location}" />
<arg value="-Dp2.build.repo=file:${path.to.update.site}" />
<arg value="-DarchivePrefix=${archive.prefix}" />
</java>
</target>
Important properties here are:
target.eclipse.platform - path to the Eclipse installation you are building with;
target.eclipse.deltapack - path to the Eclipse deltapack you'd need to build products;
projects.root.dir - the path to the folder containgin plugins/.. and features/... folders with your project sources.
builder.dir -- The build.properies and probably other template files copied from the PDE plugin folder files must be located here.
temp.build.dir - the directory you can clean after build if will be used by PDE build to store some of the temporary files it generates. You'll still need to clean up your projects and builder folders from the numerous files generated by the build.
feature.id -- id of the feature you want to build as specified in the feature.xml file of the feature project and in its folder name.
path.to.local.update.site - path where the resulting update site containing built feature will be stored.
category.xml.location and product.file.location are the pathes to the category.xml and product file correspondingly.
You don't need to put version numbers to the folder names if you use second approach.
You do have to update feature.xml and product files with the automatically changing versions.
Since eclipse.idReplacer works only once (requires specification of the original version) and is implemented without any use of an XML parser or regular expressions, I simply use optional Ant <replaceregexp> task to update changing versions related files.
Hope that this info saves at least a bit time to the next PDE build beginner.
[Updated on: Wed, 02 December 2009 16:22] Report message to a moderator
|
|
|
Re: Generate "Ant build file" outside Eclipse [message #603153 is a reply to message #493825] |
Wed, 11 November 2009 21:16 |
Rothmans Messages: 37 Registered: July 2009 |
Member |
|
|
I am seeing exactly same behaviour using Eclipse 3.5.1.
I have a
* main plugin project
* feature project containing the main plugin
* RCP plugin with .product configuration containing my feature;
* Update Site project containing my feature
Everything is checked as is into the source control system.
I can build everything using "Export" option in the Eclipse IDE.
Naturally, I need to build same stuff automatically for continuous integration.
So, I studied PDE headless build manuals for the whole 3 days already :) and I still cannot automatically build a feature or update site.
The only thing I could achive is to build the whole RCP app headlessly calling standard productBuild.xml.
One could think that to build a single feature from the RCP application could be easier.
Not at all! :)
Firstly, all feature build manuals are starting from the assumption that :
"all plug-ins and features (both to-build and pre-built) referenced from the feature being built are already locally available on disk. "
After reading this one could think that she already already has everything needed, since all plugins and features are here in the projects and are fully buildable from IDE.
But then the first error comes from the PDE's build.xml:
"${buildDirectory}/features/com.my.feature folder doesn't exist"
Hey! Do they expect me to copy my projects once more to the ${buildDirectory}/feature/com.my.feature?
Apparently they do!
If I prepare that directory the build goes further and now I see another error:
"cannot find ${buildDirectory}/feature/com.my.feature/build.xml "
Of course it's not there, I expect it to be generated automatically.
Oh, well.. Let's generate it manually and put to that deep folder in the buildDirectory... done. Does it work now? No! :)
cannot find ../MyPluginProjectFolder/build.xml.
Ah.. of course :) the build.xml was generated in the Eclipse IDE project so it took relative path to the constituent plugin project. But that path is not valid under ${buildDirectory}.
That's where I am stuck at the moment.
Hard to believe that the RCP application build is only the matter of calling standard productBuild.xml and a feature build is such a compicated thing.
And that is not yet all what I need. But I am hoping that as soon as I get feature build.xml generated for me I could use it's targets to generate my update site.
PS: the whole headless PDE building seems to be so unnecessary complicated.
Why does it require generated plugin and feature build file to be called build.xml and the name cannot be customized? I have to move my own integration build.xml files somewhere now to let Eclipse build its plugins.
The PDE build does use already custom eclipse ant tasks. Why aren't they made standalone and not requiring to be run from under Eclipse application using additional ant scripts? Except for some really minor things, like automatic build version change, and, may be, p2 repository metadata generation, I was able to repeat the whole story from scratch using standard Ant tasks. All right, I spent some time for that, which could be saved by that eclipse ant tasks. But, unfortunately, they don't do that for me yet.
|
|
| | |
Re: Generate "Ant build file" outside Eclipse [message #603186 is a reply to message #603153] |
Thu, 12 November 2009 15:59 |
Andrew Niefer Messages: 990 Registered: July 2009 |
Senior Member |
|
|
Sergey Shcherbakov wrote:
> Firstly, all feature build manuals are starting from the assumption that :
> "all plug-ins and features (both to-build and pre-built) referenced from
> the feature being built are already locally available on disk. "
PDE/Build can fetch your code from source control for you, they don't
need to be previously available on disk. The help starts here because
fetching from source control is more advanced and the help needs to
start with something simple so that people can get started.
There is a help page on fetching, you need to set up map files that
specify where your code lives in source control.
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .pde.doc.user/tasks/pde_fetch_phase.htm
> After reading this one could think that she already already has
> everything needed, since all plugins and features are here in the
> projects and are fully buildable from IDE.
>
> But then the first error comes from the PDE's build.xml:
> "${buildDirectory}/features/com.my.feature folder doesn't exist"
>
> Hey! Do they expect me to copy my projects once more to the
> ${buildDirectory}/feature/com.my.feature?
>
> Apparently they do!
> If I prepare that directory the build goes further and now I see another
> error:
> "cannot find ${buildDirectory}/feature/com.my.feature/build.xml "
While the build.xml scripts are generated dynamically where-ever the
feature/plugin is, actually running them is done from static ant scripts
that ships in the pde.build/scripts folder. These static scripts need
to know where the first top level feature is to invoke the build.xml.
By default it assumes that feature is in buildDirectory. Everything
else can be anywhere you want. If your top level feature is not in the
buildDirectory, you need to set the property "elementPath" to the
location of that feature.
>
> PS: the whole headless PDE building seems to be so unnecessary complicated.
> Why does it require generated plugin and feature build file to be called
> build.xml and the name cannot be customized? I have to move my own
> integration build.xml files somewhere now to let Eclipse build its plugins.
Building the Eclipse SDK has been the primary driver for PDE/Build.
The SDK is not a simple build and very much requires a lot of that
complexity. Effort has been made to hide/reduce this complexity when
people don't need it, hence the productBuild.xml.
It was originally named "build.xml" because that was the logical name
for the script that builds the plug-in. Changing the name of the
scripts needs to be done carefully in a way that won't break all the
existing build systems that use PDE/Build. There is a bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=120840
> The PDE build does use already custom eclipse ant tasks. Why aren't they
> made standalone and not requiring to be run from under Eclipse
> application using additional ant scripts? Except for some really minor
> things, like automatic build version change, and, may be, p2 repository
> metadata generation, I was able to repeat the whole story from scratch
> using standard Ant tasks. All right, I spent some time for that, which
> could be saved by that eclipse ant tasks. But, unfortunately, they don't
> do that for me yet.
The PDE/Build scripts need to be run under Eclipse because to generate
the correct classpath based on the manifest files for each bundle, it
needs to create a full OSGi state to resolve all bundle dependencies.
Also, some of those "minor" things like p2 repositories turn out to not
be so minor in general.
|
|
| |
Re: Generate "Ant build file" outside Eclipse [message #603238 is a reply to message #497160] |
Fri, 13 November 2009 09:50 |
Rothmans Messages: 37 Registered: July 2009 |
Member |
|
|
Andrew, thank you for your comments!
Andrew Niefer wrote on Thu, 12 November 2009 16:59
> PDE/Build can fetch your code from source control for you, they don't
> need to be previously available on disk. The help starts here because
> fetching from source control is more advanced and the help needs to
> start with something simple so that people can get started.
For me it looks like the PDE build infrastructure tries to interfere in my development workspace too much.
The sources usually are gotten with a help of a continuous integration build system, which performs lot more stuff on them then "fetching" to locations convenient for PDE developers.
I cannot change the way our mature build system works in favor of a single project.
Andrew Niefer wrote on Thu, 12 November 2009 16:59
> Building the Eclipse SDK has been the primary driver for PDE/Build.
> The SDK is not a simple build and very much requires a lot of that
> complexity.
I am not measuring complexity in the number of folders/files needed to be processed.
I am measuring complexity in the number of build scripts, ant tasks, temporary folder locations and duplicate copies of the artifacts during the PDE build.
Andrew Niefer wrote on Thu, 12 November 2009 16:59
> The PDE/Build scripts need to be run under Eclipse because to generate
> the correct classpath based on the manifest files for each bundle, it
> needs to create a full OSGi state to resolve all bundle dependencies.
> Also, some of those "minor" things like p2 repositories turn out to not
> be so minor in general.
Sure, no problems with that.
In order to achieve that, you don't need a bunch of hidden ant scripts and internal hardly reusable Ant tasks.
|
|
|
Re: Generate "Ant build file" outside Eclipse [message #603242 is a reply to message #497162] |
Fri, 13 November 2009 10:00 |
Rothmans Messages: 37 Registered: July 2009 |
Member |
|
|
Andrew Niefer wrote on Thu, 12 November 2009 17:12
> The build is not dependent on the workspace itself, PDE/Build does not
> know anything about eclipse workspaces. It is however, dependent on the
> location of the projects.
I was trying to build from the Worksapce folder, ${basedir}=<worksapce> and my projects were located inside of it.
But apparently it is not enough. One have to specify explicitly where the workspace is (and this is not well documented).
So I got a feeling that PDE build like some other Eclipse based building environemtns (like WindRiver Workbench) rely heaviliy on the metadata stored in the workspace. That is bad style I'd say.
Good if the PDE build doesn't do that.
Andrew Niefer wrote on Thu, 12 November 2009 17:12
> Note that invoking the eclipse.buildScript target directly is considered
> an advanced use of PDE/Build. The pde.build/scripts/build.xml does this
> for you. Generally it is simpler to copy the template build.properties,
> set 3 properties (topLevelElementId, baseLocation, buildDirectory) and
> call the antrunner on the main build.xml.
That's exactly what I was starting with.
See my first message with the history of the error messages I went through from that point.
Besides of of my negative impression of the PDE build implementation, there is nothing personal and I very appreciate the help and any of your comments!
|
|
| | | |
Re: Generate "Ant build file" outside Eclipse [message #603295 is a reply to message #497712] |
Fri, 13 November 2009 16:26 |
Andrew Niefer Messages: 990 Registered: July 2009 |
Senior Member |
|
|
Rothmans wrote on Fri, 13 November 2009 06:16
> All right, here we go again trying to build a feature using standard PDE build.xml:
>
> Directory structure:
>
> D:\MyWorkspace
> |-build
> |-MyFeature
> ...
> |-MyPlugin
> |-...
> |-build.xml
> |-build.proerpties
>
>
> build.properties (located in the worksapce folder):
>
> builder=${basedir}
> pluginPath=${basedir}${path.separator}${progtools.target.ecl ipse.platform}${path.separator}${deltapack}
> buildTempFolder=${buildDirectory}
> topLevelElementType=feature
> topLevelElementId=com.my.feature
Because your top feature that you are building is not under the buildDirectory, you will need to set the property elementPath=${basedir}/MyFeature
The static script genericTargets.xml needs to know the entry point to the generated scripts. The default value of this is basically
elementPath=${buildDirectory}/${topLevelElementType}s/${topL evelElementId} Which is obviously incorrect in your setup.
Using the fetch mechanism would fix this, but only because it would fetch your feature into the buildDirectory where the elementPath points by default. Since you already have your source through continuous integration, it is better to just set the elementPath property.
Also, I'm sure you already are, but make sure your workspace build.xml loads this property file before calling pde.build's build.xml. Generally, PDE/Build will load the file itself, but it needs to know builder first so that it can find the file. As well, the ${basedir}'s here would resolve to the pde.build/scripts folder instead of your workspace.
|
|
| | | | |
Re: Generate "Ant build file" outside Eclipse [message #603733 is a reply to message #603570] |
Tue, 01 December 2009 16:26 |
Rothmans Messages: 37 Registered: July 2009 |
Member |
|
|
Thank you for the comment, Mike.
I am still missing some crucial point at all automated PDE build story.
The project structure I am using was not invented by me. I was simply following numerous examples on the web where projects are created without any naming convention in the flat layout.
Perhaps, those examples are adjusted to work only from Eclipse IDE and they do, but I don't understand why the build script started from IDE can work with flat structure and automated build that uses same build scripts not.
All right, you are telling that I need to follow some particular folder layout to be able to build automaticaly.
First thing that comes into my mind is that the whole temporary build temporary files, scripts etc. comes into my source folders that are under source control.
You know, this is not great to fill out the .Xignore files with all kinds of wierd file names.
Okey, that's minor you'd say.
Then what about version numbers?
The plugin/feature project folder names do must include their version numbers otherwise the build script won't find them. Am I right?
The first thing I tried when I began setting up my automatic build was to raise the folder structure you are talking about and start the PDE build against it. No chance: it expects versions to be part of the project folders names.
So do you mean, I need to create new folder each time I increment the version?
Must the folder name include the "qualifier" suffix in case it is present too? Even if I'd create the folder structure everytime anew, how would I know the correct qualifier suffix before the PDE build starts?
Actualy here I come to my next disappointment.
From historical reasons the third poart of the version gets incremented twise a week in our projects _automatically_ (!). With all those questions above it looks to me that it is (almost?) impossible to get significant version number parts to get changed/incremented automatically and passed to the PDE build.
How do you handle the build version increments? Everytime manually except for qualifier part? sigh...
|
|
| | | | |
Goto Forum:
Current Time: Mon Sep 23 21:08:02 GMT 2024
Powered by FUDForum. Page generated in 0.08591 seconds
|