[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-user] Why is Tycho manifest-first?
|
None of the problems you describe are inherent limitations of
manifest-first approach. It can be argued that pom-first is slightly
better at managing compile-time dependencies while manifest-first does a
slightly better job during integration testing, but neither has decisive
advantage. If project dependencies are available in both maven and p2
format, then choice between pom-first and manifest-first is down to
personal preferences and historical reasons, like pre-existing
hand-written manifests, like was the case in JBossTools for example.
--
Regards,
Igor
On 11-11-17 5:15 AM, Aaron Digulla wrote:
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,
