Closed HannesWell closed 2 years ago
A concern I have with pom-less builds is what happens if we want to go bundle manifest-less? Instead have something like BND generate our manifest for us based on annotations and such?
A concern I have with pom-less builds is what happens if we want to go bundle manifest-less? Instead have something like BND generate our manifest for us based on annotations and such?
Well, for maven, you would need different poms for sure. Or go gradle :-)
A concern I have with pom-less builds is what happens if we want to go bundle manifest-less? Instead have something like BND generate our manifest for us based on annotations and such?
Actually, BND could support a "pomless" as well (or Tycho could support it here) if e.g. a bnd file is enough to describe what should happen here, this is on my todo list but haven't had a strong use case yet to make it happen.
Actually, BND could support a "pomless" as well
Bnd cannot do this in a maven build since maven is in charge and needs poms for each project. I am assuming you are not planning on going to a full Bnd workspace model (cnf folder) build but just using Bnd's maven plugins.
Bnd cannot do this in a maven build since maven is in charge and needs poms for each project.
The same is for tycho-pomless, if there is enough information (e.g. knowing what project depends on each other) you do not need a traditional pom but could use a polyglot build like tycho-pomless do.
if there is enough information (e.g. knowing what project depends on each other) you do not need a traditional pom but could use a polyglot build like tycho-pomless do.
This can be done for PDE builds since the manifest is used for project dependency graph building. But in a maven build using Bnd maven plugins, the bnd files do not contain project dependency information (e.g. no -buildpath). So poms are required for this.
Thats why I wrote "if there is enough information (e.g. knowing what project depends on each other)", e.g. if I declare all dependencies in the master pom and assume that the order of modules (or I know from somewhere else) is the build order I do not need individual pom.xml files for sub-folders. pomless don't mean we have no poms, or do not use maven, these are just generated on the fly from existing meta-data (e.g. MANIFEST.MF, feature.xml, products,...) and then the usual maven build kicks in and to the actual graph building (tycho don't do that).
A concern I have with pom-less builds is what happens if we want to go bundle manifest-less? Instead have something like BND generate our manifest for us based on annotations and such?
This would be a change of the the underlying toolset which likely would require more work to do. If this happens one day the poms can be re-generated by Tycho. In the meantime I think it is not necessary to carry duplicated information around that cause extra maintenance work.
Nevertheless I think Eclipse should favor its own tools if it provides some, in this case PDE. I don't want to argue if PDE or BND is better (for example in m2e we use the bnd at multiple places), but in the sense of 'eat your own dog food' a vendor should be convinced enough from its tools, to use it.
If you are fine with this change, I would like to submit it.
The Maven-foo in the community (Eclipse TLP committers) is far worse than Manifest-foo so such an effort would alienate a good number of people immediately thus it's not good idea to be done. Technically I don't see a difference whether one handcrafts Manifest.mf or pom.xml file - in both cases it requires understanding of the underlying technology to do it properly.
Technically I don't see a difference whether one handcrafts Manifest.mf or pom.xml file
The main difference is that the manifest is an output file (to be generated by the build) and not an input file. PDE made a bad choice to use it as an input file too and thus it effectively encourages people to use Require-Bundle, since that is easy like dependencies in a maven pom, instead of Import-Package which is awkward to hand craft since you don't always know what packages you need before your build the code.
Technically I don't see a difference whether one handcrafts Manifest.mf or pom.xml file
The main difference is that the manifest is an output file (to be generated by the build) and not an input file. PDE made a bad choice to use it as an input file too and thus it effectively encourages people to use Require-Bundle, since that is easy like dependencies in a maven pom, instead of Import-Package which is awkward to hand craft since you don't always know what packages you need before your build the code.
I haven't been detailed in my statement it seems :). What you say is true from OSGi POV , from releng/Maven POV - people feel the need to hardcode maven versions to whatever version they spotted first, add maven plugins that are not needed , not pay attention/share configuration in parent pom.xml files and so on and on. So we end up trading pom.xml for Manifest.mf weirdness or vice-versa.
So we end up trading pom.xml for Manifest.mf weirdness or vice-versa.
Yes, people are lazy :-)
But at least with maven, you get a lot of other tools to help, e.g. dependabot, because the maven universe is large enough to attract such additional tools. PDE/p2 is basically Eclipse only. Tycho is a bridge from PDE/p2 to the larger maven universe, but it some point, it is better to take the punch and move to maven.
Landing this in as it's immediate relief for both developer and releng. If in the future someone wants to drive a change to pom-first polyglot.pom.xml files can always be used as a base.
Actually, BND could support a "pomless" as well
Bnd cannot do this in a maven build since maven is in charge and needs poms for each project. I am assuming you are not planning on going to a full Bnd workspace model (cnf folder) build but just using Bnd's maven plugins.
Just let you know about tycho-pomless now has also support for "pomless-bnd":
This is the simple part of: https://github.com/eclipse-equinox/equinox/issues/9