Community
Participate
Working Groups
Throughout the years, PDE Build has never been the center of much attention. Now with the overwhelming adoption of Maven/Tycho as technology for headless builds, and the disconnect resulting from what the IDE does and what Tycho does, I think that keeping PDE Build alive is not really helping anyone. For example, when I implemented the support for the new mac layout, I had to modify PDE build in a number of places and this was definitely not fun, especially knowing that there is very few users of the technology. Consequently I think we should explore a way to get rid of PDE Build and replace it with Tycho. When I first started this thought exercise a couple years ago, it seemed complicated (especially to build just one plug-in). However the recent changes in Tycho to support pom-less builds would definitely simplify things. Of course this would mean shipping Maven (and maybe Tycho) as part of the SDK, but I think the benefits would be: - consistent story between headless and IDE builds (today there are still disconnects between PDE build and Tycho) - one codebase to work on with one focus - potential for improving the sharing of bundles between PDE and Maven Here are some of the problems to consider: - How can Tycho reuse the target platform known by PDE? - Should pom.xml generated on behalf of the user when necessary (e.g. for update site and products)? - How much of Maven / Tycho to include by default in order to make the first ever build smooth?
I'm moving this to PMC since there's where such a decision would happen.
> I think that keeping PDE Build alive is not really helping anyone There are still quite a few places with Ant based build systems that leverage PDE Build. The one that I maintain has many capabilities not present in Maven/Tycho. Re-writing everything for Maven is very difficult to justify. Perhaps PDE Build can be moved into a separate component/project where interested parties can continue to maintain it.
I assume this story would also cover the usecase where the developer exports the plugin directly out of the workspace (which leverages PDE-Build)? Not just replacing the commandline ant based PDE-Build?
(In reply to Thomas Watson from comment #3) > I assume this story would also cover the usecase where the developer exports > the plugin directly out of the workspace (which leverages PDE-Build)? Not > just replacing the commandline ant based PDE-Build? The only interesting use case from the IDE context is to replace PDE-Build when it used by the export done through wizards (so export plugin, export feaure, etc.). For the headless build use cases, people are using tycho already and they are fine.
(In reply to Konstantin Komissarchik from comment #2) > > I think that keeping PDE Build alive is not really helping anyone > > There are still quite a few places with Ant based build systems that > leverage PDE Build. The one that I maintain has many capabilities not > present in Maven/Tycho. Could you tell more about those capabilities? >Re-writing everything for Maven is very difficult to justify. > > Perhaps PDE Build can be moved into a separate component/project where > interested parties can continue to maintain it. That's fair game, as long as there is an understanding that features added to the future PDE story don't have to be added to PDE-Biuld to declare success.
>> There are still quite a few places with Ant based build systems that >> leverage PDE Build. The one that I maintain has many capabilities not >> present in Maven/Tycho. > > Could you tell more about those capabilities? Sure. Here is a few... 1. Managing multiple targets and cross-building against these 2. Create dev environment, including a dev eclipse and a dev target that's different from build target (contains source) 3. Automatic computation and setting of Require-Bundle version constraints based on rules defined against known targets (min target, max target, offset from max, etc.) 4. Automating setting of package version based on bundle version 5. Verification of copyright headers, author tags, about.html, etc. >> Perhaps PDE Build can be moved into a separate component/project where >> interested parties can continue to maintain it. > > That's fair game, as long as there is an understanding that features added to > the future PDE story don't have to be added to PDE-Biuld to declare success. That's reasonable.
Pascal, I see you changed the summary of that bug. I think it would be better to keep the original bug as an umbrella bug and add blockers, like the plug-in export. Since this is your bug, I let you decide.
"Replace PDE Build by Tycho when exporting from the IDE" Are you actually planning to ship Maven & Tycho as part of PDE? I consider the export operation a very convenient mechanism for quick experiments. Can Tycho possibly achieve the same level of convenience even in projects that have no maven configuration?
(In reply to Dani Megert from comment #7) > Pascal, I see you changed the summary of that bug. I think it would be > better to keep the original bug as an umbrella bug and add blockers, like > the plug-in export. Since this is your bug, I let you decide. I actually think that this is a more accurate title of what is intended. In its entirety (UI, Core, Build) PDE provides way more features than Tycho. For example PDE UI & Core deal with target platforms, editors, etc., whereas PDE Buils, when used from inside the IDE, only deals with export related features (feature, plugins, site, products).
(In reply to Stephan Herrmann from comment #8) > "Replace PDE Build by Tycho when exporting from the IDE" > > Are you actually planning to ship Maven & Tycho as part of PDE? Well, this is definitely one way. > I consider the export operation a very convenient mechanism for quick > experiments. Can Tycho possibly achieve the same level of convenience even > in projects that have no maven configuration? With the recent addition of pom-less buils (https://wiki.eclipse.org/Tycho/Release_Notes/0.24#POM-less_Tycho_builds) I think it would be simpler than it once was. Today PDE Build generates a large number of ant scripts to make everything exportable from the IDE, I think that this new version could generate poms where they are necessary. At least this is the hope :) Now some of the concern shipping Maven/Tycho are: - How do we sync up with Tycho's version. The existing dependencies between OSGi/p2/Tycho and the platform builds are always making things complicated, so shipping Tycho as a PDE plug-in may make things even more complicated. The other possibility would be to only ship just maven and then let the rest be downloaded. Though this would definitely harm the first time the user ever exports from the IDE since all the maven dependencies and tycho would have to be downloaded.
Christoph, do you think delivering such a thing via m2e, direct tycho invocation or smth else makes sense and is easily achievable? Getting rid of pde.build would simplify PDE maintenance.
Actually one won't need m2e or PDE to accomplish that task, I can't really tell if one would say its "easy" but at laest I don't see why one should not be able to do this. So if this feature is critical to someones business and want to sponsor such development let me know ;-)
Jonah, IMHO this is topic that IDE WG should consider as PDE build is in deep maintenance and lacks many of the latest features and thus export from inside IDE is stuck in the past.
> So if this feature is critical to someones business and want to sponsor such development let me know ;-) I think this is key. I don't know of anyone using PDE build in production anymore. I think it is only used by hobbyists and casual users. PDE build was great when I was first learning Eclipse development (a long time ago :-) because it meant I could build first versions of things from a wizard. (In reply to Alexander Kurtakov from comment #13) > Jonah, IMHO this is topic that IDE WG should consider as PDE build is in > deep maintenance and lacks many of the latest features and thus export from > inside IDE is stuck in the past. I will add to the agenda of next planning council call. But my first instinct is that the IDE WG members are probably not interested in prioritizing this work within the budget they have.
@Jonah Graham I think @Alexander Kurtakov do not have *changing* PDE build in mind, but *Replace* it inside PDE itself when using the export wizards that currently don't work well anymore because they are lacking behind new features.
(In reply to Christoph Laeubrich from comment #15) > @Jonah Graham I think @Alexander Kurtakov do not have *changing* PDE build > in mind, but *Replace* it inside PDE itself when using the export wizards > that currently don't work well anymore because they are lacking behind new > features. ^^ Absolutely
Thanks - I understood that. Having wizard driven interface for Tycho to export is certainly a nice to have and I will bring it to the planning council.
(In reply to Jonah Graham from comment #17) > Thanks - I understood that. Having wizard driven interface for Tycho to > export is certainly a nice to have and I will bring it to the planning > council. Just to clarify I think the goal should not to use Tycho directly, but to perform it like Tycho does (in many cases using P2).
That's interesting - I would have thought that a good goal was to have the wizards help bootstrap users to command line builds by generating pom.xml. If we don't do that then the users are forever at the edge of a big cliff to move from wizard to command line builds. I assume this is like export wizard having option to generate ant build scripts.
Tycho usually do not need a (project) pom.xml to build your bundle/plugin/feature/product/...: https://tycho.eclipseprojects.io/doc/master/StructuredBuild.html nerveless if one absolutely wants, Tycho can generate a pom.xml if one want it: https://github.com/eclipse-tycho/tycho/wiki/Tycho-Pomless#useful-tips So the main concern is more that one want to export a product / feature / bundle from the UI directly without setup/trigger a maven build.
> So the main concern is more that one want to export a product / feature / bundle from the UI directly without setup/trigger a maven build. OK - I guess this ties back to comment 12: > So if this feature is critical to someones business and want to sponsor such development let me know ;-)
(In reply to Jonah Graham from comment #19) > That's interesting - I would have thought that a good goal was to have the > wizards help bootstrap users to command line builds by generating pom.xml. > If we don't do that then the users are forever at the edge of a big cliff to > move from wizard to command line builds. I using IDE based PDE build once a month to build & release some of our internal R&D plugins. I don't want to see maven command line at all, it would make me unhappy. I like clicking on buttons to get (local) build done, and I don't like to think how to fix maven if the internet is broken again.
Exactly I only ever use a maven build (mostly because I need it anyways) but there are obviously some user complains about that not working, so a possible (cheaper) solution might be to disable all export wizards in PDE :-)
(In reply to Jonah Graham from comment #14) > [...] I don't know of anyone using PDE build in production anymore. Just to fill in this gap: The Object Teams project has invested significant time back in ~2004 to create a setup using PDE build in production, and I haven't yet seen any compelling reason to change that. Brief considerations to move to tycho (despite the mutual dislike between maven and me) stopped when I didn't see an obvious way to build our compiler and use in subsequently within the same build. Hence working system + no obvious migration path = don't change it. While I understand that making the wizard use tycho under the covers doesn't explicitly mean to discontinue PDE build, implicitly it does sound like I may end up being the last and only user of PDE build, which of course brings the risk of decay. (In reply to Andrey Loskutov from comment #22) > I using IDE based PDE build once a month to build & release some of our > internal R&D plugins. I don't want to see maven command line at all, it > would make me unhappy. I like clicking on buttons to get (local) build done, > and I don't like to think how to fix maven if the internet is broken again. From this I'd derive the requirement, that whatever tech is used by the wizard, it should not depend on any maven repositories (remote: undesired dependence on internet and various servers being online, local: could be corrupt, incomplete or inconsistent wrt what PDE sees during workspace builds).
