[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-user] Why is Tycho manifest-first?
|
Zitat von Mickael Istria <mickael.istria@xxxxxxxxxxxxxx>:
Hi,
MANIFEST.MF is the file that is used at dev-time by PDE and at
runtime by your OSGi Container to deal with modularization. Maven is
build-time modularization, based on pom.xml to express dependencies.
Then the general issue with Maven and OSGi is that there are 2 ways
to express dependencies. Tycho probably made the right choice
choosing the approach that is the state-of-the-art: relying on
MANIFEST.MF.
If you want to have a pom-first approach, how do you deal with PDE
at dev-time without a good MANIFEST.MF?
Simple: I'm not using PDE if I can avoid it. While the Maven
integration in Eclipse isn't perfect (for various reasons), PDE with
its infinitely recursive Ant scripts is worse.
So far, I have tried to build these projects with PDE: Equinox, SWT,
Platform, Console. I failed every time because of some obscure error
message in line 15000 of some Ant script at recursion level 97.
Enabling debug gives me a nice 150MB log file which is too big to
understand.
Error messages usually are incomprehensible to me and any Eclipse
developer that I asked.
For example, it took me 4 hours to set up a BIRT build using Maven
(that includes finding all the sources and removing any trace of PDE).
That build takes exactly 53 seconds for 4000 source files. The build
creates a working bundle and I know exactly what goes into the build.
No p2 repo is considered (see below), and no PDE script/tool is used.
My build is stable, it doesn't depend on some CVS server on the other
side of the planet, I know what it is doing, it's fast and reliable.
When I tried to build the same project with PDE, I ran into these problems:
1. The build only works on a single machine because the PDE scripts
contain absolute paths. For some reason, -Dkey=value is sometimes
ignored. All my attempts to override the paths didn't work. Even when
I changed the file, the build would checkout the files from the CVS
server and overwrite my changes.
2. The CVS checkout URLs only work inside the Eclipse network.
3. During the build, I saw error messages that no one ever saw before.
A developer from the BIRT team tried to help but he simply didn't know
what the error message meant or how to fix it. It was a typical "but
it works on my machine" situation.
4. Unlike Maven projects, PDE projects always depend on external
factors like the Target Platform. There is no simple, sure-fire way to
create a PDE project which will build out of the box for everyone.
The main problem with PDE is that it gives developers too many options.
On top of that, I haven't found a way to build a site with exactly the
version of features/plugins that I want. Even if it works perfectly,
all plugin qualifiers get updated even though the plugin code didn't
change.
In my view, one can argue that MANIFEST.MF is "state-of-the-art". But
PDE is definitely not.
I tried Buckminster but wasn't too impressed. Then we have lots of
small bugs in the PDE UI (menus sometime don't do anything without an
error, incomplete builds, the target file editor is very slow,
sometimes adding a feature doesn't work, plugins can't be found, ...)
Supporting files such as build.properties is quite convenient for
everybody in the Eclipse world. Without that, I think Tycho would
not have been so successful at Eclipse. But since these files are
originally specific to the PDE build, I think and I hope they'll
tend to disappear to have build customization in pom.xml instead of
build.properties.
About p2, I can tell you that there is not any drawback when dealing
with Eclipse projects builds. Maybe you should elaborate more your
specific use-case to teach us the limitations some people (including
me) are not aware of.
I have several concerns with p2:
- Unlike Maven Central, p2 repositories are very unreliable. Someone
uploads a new version of a plugin and my builds change.
- If you're not in the US, starting a Maven build which uses the
official Indigo repo can take up to 15 minutes for the connection
phase alone! This is unacceptable. To drive this home: "mvn clean"
takes 15 minutes!!!
From my point of view, p2 and PDE are a liability and I avoid both
technologies even at great cost.
I don't mind having a Maven build that creates a MANIFEST.MF (and
plugin.xml) from data from the POM because the POM gives me find
grained control which PDE does not.
MfG,
--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/ http://blog.pdark.de/
