[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [pde-build-dev] Bundle Dependency Question
|
Hi Pascal,
Thanks for your reply. Basically
I am trying to do something similar to Orbit but with our in-house plugins.
Currently we have a monolithic PDE build of 12 features (basically
for modularity) which hold a total of ~50 plugins. A lot of these
plugins do not change much, but we have some issues that make our build
a challenge. In particular, we have an install handler that allows
us to update external files when we do plugin installations and updates.
So, we ship external files as part of our plugins - which basically
means their dependencies are now impossible to keep track of. A plugin
not only depends on its own source code and other plugins - now it depends
on potentially tens or hundreds of binaries from somewhere else in our
CVS repository.
So, currently every time we release
we rebuild everything. This means we rev. the qualifier on *all*
of our plugins simply because it is the easiest way to avoid disaster.
I was trying to keep track of what changed and what didn't and it
was a nightmare. The solution is a new build system with proper dependency
checking. We have jumped around a bit between rolling our own and
using Ivy - and I think we are just going to fight with Ivy and try to
use it. So we are experimenting now integrating with a CI server
and things are starting to look achievable.
Having said that - all I want to do
is be able to build plugins individually whenever its source or one of
its dependencies changes. I don't mind specifying these dependencies
manually. We are going to have to do this for Ivy anyway, and it
really isn't all that bad to maintain. 99% of things never change.
So, our build process will be to rebuild plugins on demand, and check
their resulting JAR files into a local Ivy repository. This certainly
looks achievable - but admittedly is a bit of a pain right now with PDE
because I need to ensure I have a basebuilder around and spawn a new Java
process from Ant to run a PDE build in headless mode to generate a build.xml,
then execute Ant on that generated file and run the 'build.update.jar'
target. And it seems even more of a waste for features because as
discussed - we are basically just replacing versions in feature.xml and
packaging it up.
So, if I am not mistaken - there is
no way to build a single plugin using PDE otherwise. And to be honest
- it seems easier to me to just continue using eclipse.buildScript and
running Ant on the resulting build.xml to build my features rather than
try to use the version files and call the idReplacer task myself - even
if it does mean I need to specify a few unneccessary dependencies. The
problem is when I want to build my feature I am not building all the plugins
- I am just using the binary JARs I pulled from the Ivy repository, so
I don't have all of my build.xmls around, and I don't have all of the feature
versions in those properties files. If I were building everything
and had access to this information I would just continue to use a PDE build.
In summary, I think the PDE build is
good for building everything in a feature and it does that job well. But
if only one plugin in 50 has changed, rebuilding all 50 plugins is unneccessary.
I know you will probably tell me to just avoid moving the tag on
the plugins that have not changed, and rebuild the same old versions of
the unchanged plugins. The problem is - this depends on manually
tagging things before you build, and frankly my dependencies are too complicated
to do that reliably. I could look at automating the pre-tagging of
source to make it more reliable and repeatable - but I figured it makes
more sense to focus my efforts on a finer-grained build at the plugin-level.
It will also reduce build times significantly, *and* allow people
to access versions of individual plugin JARs from the Ivy repository for
other things.
Mark.
----------------------------------------------------------
Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
Sent by: pde-build-dev-bounces@xxxxxxxxxxx
05/03/2007 08:57 PM
|
Please respond to
"Eclipse PDE Build developers list." <pde-build-dev@xxxxxxxxxxx> |
|
|
To
| "Eclipse PDE Build developers list."
<pde-build-dev@xxxxxxxxxxx>
|
|
cc
| "Eclipse PDE Build developers list."
<pde-build-dev@xxxxxxxxxxx>, pde-build-dev-bounces@xxxxxxxxxxx
|
|
Subject
| Re: [pde-build-dev] Bundle Dependency
Question |
|
When you are invoking the eclipse.buildScript task
PDE does not know that
in the end you will not try to compile something, therefore it reports
errors because the plug-in is not "resolved". It could probably
be smarter
and only fail if a plugin being compiled puts it on its classpath, but
it
gets pretty fancy. So basically what you see works as expected (see
enhancement request https://bugs.eclipse.org/bugs/show_bug.cgi?id=169991).
If what you are trying to achieve is simply replace the version numbers
in
the feature.xml, I would encourage you to directly invoke the poorly named
eclipse.idReplacer ant task (it should be called
eclipse.featureVersionReplacer, ok I'm no good at naming :-)) which does
the replacement of version in the feature. You can get all the information
about the final versions for each plug-ins and features in files named
final*Versions.properties (those files are generated when calling
eclipse.buildScript). This would require you to do the loading of those
files yourself and generate the call, or you can probably hack the
idReplacer task to directly load those files.
Now quick question, what are the requirements or pde build limitations
that forced you to resort to only using the script generators?
Thx
PaScaL
Mark_Melvin@amis.
com
Sent by:
To
pde-build-dev-bou
"Eclipse PDE Build developers
nces@xxxxxxxxxxx
list." <pde-build-dev@xxxxxxxxxxx>
cc
05/02/2007 02:59
Subject
PM
[pde-build-dev]
Bundle Dependency
Question
Please respond to
"Eclipse PDE
Build developers
list."
<pde-build-dev@ec
lipse.org>
Hi Everyone,
I am also trying to do continuous integration of plugins and features and
I
almost have a working set of Ant targets that look like they will let me
build on a plugin level - provided I do the dependency management (which
I
plan to do anyways). However, I have run across a limitation that
I think
may be a bug but I am not sure. Let me describe my scenario. I
have the
following:
Feature A
Includes: Feature B, Feature C
Includes: Plugin D
Let's assume (for simplicity) that the only other dependency is:
Plugin D
Requires: Plugin E
OK, so I have written some Ant targets that fire up a headless PDE-enabled
eclipse that gives me access to the eclipse.buildScript task. Now
I have
already successfully used my scripts to individually build all of the other
features and plugins, with the exception of the top-level Feature A. I
am
now building this feature so I get all of its dependencies (pre-built,
plugin JARs, and complete sub-feature folders created by inflating my
pre-built feature JARs) and place them in the following directory
structure:
<some_folder>/
+--builddir/
| +--features/
| | +--Feature A/ (this
is what I am building)
| +--plugins/
|
+--dependencies/
+--features/
| +--Feature B/
| +--Feature C/
+--plugins/
+--pluginD_vXXXX.jar
So in my call to eclipse.buildScript, my buildDirectory is
<some_folder>/builddir, and my pluginPath is <some_folder>/dependencies.
Now, I would think this should work perfectly fine, however the build fails
with the message (with the placeholder names substituted):
[java] [eclipse.buildScript] Some inter-plug-in dependencies
have not
been satisfied.
[java] [eclipse.buildScript] Bundle pluginD:
[java] [eclipse.buildScript] Missing
required plug-in
pluginE_[1.0.0,2.0.0).
[java]
[java] BUILD FAILED
[java] C:\Temp\autobuild\testme.xml:116: Unable to find
plug-in:
pluginD_0.0.0. Please check the error log for more details.
So, why is it required that the already-built Plugin D needs access to
its
dependencies? It is already built and therefore does not need to
resolve
anything. This seems like a bug to me. Essentially all I am
doing here is
using the eclipse.buildScript to grab the versions of its dependencies
and
substitute them into the feature manifest - then JAR up the bin.includes.
Now I have to recursively calculate/declare transitive dependencies all
way
down the plugin chain - which I think is unnecessary. Is this a bug?
Note that when I copy in pluginE_vYYYY.jar into
<some_folder>/dependencies/plugins, the build works fine.
Thanks,
Mark.
AMI Semiconductor - "Silicon Solutions for the Real World"
NOTICE:
This electronic message contains information that may be confidential or
privileged. The information is intended for the use of the individual or
entity named above. If you are not the intended recipient, please be aware
that any disclosure, copying, distribution or use of the contents of this
information is prohibited. If you received this electronic message in
error, please notify the sender and delete the copy you received.
_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev
_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev
AMI Semiconductor - "Silicon Solutions for the Real World"
NOTICE:
This electronic message contains information that may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.
