| Re: [tycho-user] Why is Tycho manifest-first? |
On 17/11/2011 11:15, Aaron Digulla wrote:
Zitat von Mickael Istria <mickael.istria@xxxxxxxxxxxxxx>:I think you are confusing PDE (IDE Tooling) and PDE Build. Also I am not sure of what you mean by "worse". This is a contextual word, without the context, it is not easy to get what are the concrete issues ;) 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.That's true, and that's why Tycho is meant for: replace PDE build with a more transparent build system. I think it is no more time to say the PDE Build is not that good. PDE Build is past, everybody on this mailing list agrees with it. 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.Ok. 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.So is a Tycho-based build. It does not rely on a CVS server; it relies on p2 repositories; you know what it is doing, it is reliable. But IMHO, it is still much easier as a plugin developer to have MANIFEST-first approach, because the tooling (IDE) works well doing so. Also the MANIFEST.MF is a very important file for the developer, I prefer editing it than having it generated. When I tried to build the same project with PDE, I ran into these problems:Ok, PDE Build is now bad. I agree. But I meant PDE Tooling in the IDE. I have several concerns with p2:That's true, it is up to project providing repositories to set up a policy to have reliable p2 repositories. However, having your build changing is not that important IMHO, because if the p2 repository is updated, you have a build that changes, but it follows update of different projects. Think about how your end-users will consume your product: in Eclipse, if they use a p2 repository to install it, they'll probably have also the latest versions of other repositories. As a plugin developer, I am pretty happy to see my build automatically switching to the maintenance release of Indigo because the content of the repo changed. It ensures me people who get a latest release of Eclipse will see the project working. - 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!!!That's true. I've never reached 15 minutes, but that's long. Maybe the idea behing this issue is the lack of mirroring support in p2 or Maven in general. You should open a bug against p2 explaining that an install should be able to delegate downloads to a mirror. That would be a valuable improvement. From my point of view, p2 and PDE are a liability and I avoid both technologies even at great cost."even at great cost": That's probably where we have different ways of thinking. For me, Tycho is low-cost and reliable enough. All other approaches I've seen to build plugins are much more expensive for results that are less satisfying, 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.You don't; but I do mind. The great tooling providing in Eclipse IDE needs this MANIFEST.MF and plugin.xml, I cannot work without it, and it is an easier approach since they are the concrete files that are consumed at runtime. Seens like we have different use-cases and requirements for a build. But AFAIK, I am not aware of an Eclipse project (plugin or RCP) that have suffered from moving to Tycho, even with p2 ;) |