[#12] moved all settings to ext folder; use templates from mvn central #13
Conversation
cnf/ext/central.maven
Outdated
| @@ -0,0 +1,4 @@ | |||
| # List repository contents using GAV coordinates | |||
| org.bndtools:org.bndtools.templates.osgi:5.2.0 | |||
There was a problem hiding this comment.
The versions should use a macro so that it can be centrally edited.
There was a problem hiding this comment.
Good point. Do we actually something like a prepared macro like current_bndversion?
There was a problem hiding this comment.
Seems like it might be a nice macro to add.
| aQute.bnd.repository.maven.pom.provider.BndPomRepository; \ | ||
| snapshotUrls=https://oss.sonatype.org/content/repositories/osgi/; \ | ||
| releaseUrls=https://repo.maven.apache.org/maven2/; \ | ||
| revision=org.osgi.enroute:osgi-api:7.0.0; \ |
There was a problem hiding this comment.
I guess I am not sure of the ongoing status of enRoute with the shutdown of the OSGi Alliance and the movement of OSGi specification development to Eclipse. I think Bndtools should consider moving away from enRoute artifacts and use OSGi artifacts.
There was a problem hiding this comment.
I guess we can clarify this in the upcoming weeks in our steering Committee calls and I will change it accordingly.
| @@ -0,0 +1,16 @@ | |||
| -releaserepo: Release | |||
There was a problem hiding this comment.
What is the value of moving these from build.bnd? You just leave an empty build.bnd behind when these values should still be there. Users can add there own ext files to override the values in the central build.bnd file.
There was a problem hiding this comment.
The idea is to keep the build.bnd empty in our template, to avoid conflicts when reapplying the workspace template to update to e.g. a newer bnd version. A build.bnd will always be there and chances are good, that people will edit it and add there own stuff. If so, one can simply uncheck it and it will not be overwritten on update. With the current version of the workspace, I could always update our projects, by simply ignoring the osgi_repo.bnd plus its maven file and the settings.bnd.
There was a problem hiding this comment.
So you just move the problem to this file since the template will want to replace this file too. There is no practical difference that I can see.
There was a problem hiding this comment.
In our cases I don't really care. A lot of workspaces of others I've seen have their settings in the build.bnd however. Having the default settings in an extra file, would make it easier to to update such workspaces. If we e.g. provide a new property for e.g. mockito one could update the WS, skip the build.bnd, copy the desired content from the settings.bnd to where ever it is needed and delete the file. Als this can be done without leaving bndtools.
I know that we will never hit all cases (e.g. if somebody already has a settings.bnd), but I don't see any disadvantage. Especially given the fact that the build.bnd in the bndtools workspace would be exactly such a candidate.
There was a problem hiding this comment.
Having the default values in build.bnd is nice since an ext bnd file can override it since they are read after. If you put the defaults in an ext bnd file, then someone must edit that file (or create another ext bnd file which is read after the settings.bnd fie) to override.
There was a problem hiding this comment.
I would say we both have a valid point here. I would suggest we discuss this on our Friday bash and wait what the others think.
…n central Signed-off-by: Jürgen Albert <j.albert@data-in-motion.biz>
juergen-albert
force-pushed
the
remodeling
branch
from
fb5553f
to
e8ea176
Compare
Signed-off-by: Jürgen Albert j.albert@data-in-motion.biz