[#12] moved all settings to ext folder; use templates from mvn central #13
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,76 +1,2 @@ | ||
| # All settings moved to the bnd files in the ext directory. | ||
| # bnd files found there will be included automatically. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,4 @@ | ||
| # List repository contents using GAV coordinates | ||
| org.bndtools:org.bndtools.templates.osgi:${bndversion} | ||
| org.bndtools:org.bndtools.templates.template:${bndversion} | ||
|
|
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,55 @@ | ||
| # Configure Repositories | ||
| -plugin.1.R7.API: \ | ||
| 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; \ | ||
| readOnly=true; \ | ||
| name="OSGi R7 API" | ||
| -plugin.2.Enterprise.API: \ | ||
| 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:enterprise-api:7.0.0; \ | ||
| readOnly=true; \ | ||
| name="Enterprise Java APIs" | ||
| -plugin.3.R7.Impl: \ | ||
| 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:impl-index:7.0.0; \ | ||
| readOnly=true; \ | ||
| name="OSGi R7 Reference Implementations" | ||
| -plugin.4.Test: \ | ||
| 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:test-bundles:7.0.0; \ | ||
| readOnly=true; \ | ||
| name="Testing Bundles" | ||
| -plugin.5.Debug: \ | ||
| 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:debug-bundles:7.0.0; \ | ||
| readOnly=true; \ | ||
| name="Debug Bundles" | ||
|
|
||
| -plugin.6.Central: \ | ||
| aQute.bnd.repository.maven.provider.MavenBndRepository; \ | ||
| releaseUrl=https://repo.maven.apache.org/maven2/; \ | ||
| index=${.}/central.maven; \ | ||
| readOnly=true; \ | ||
| name="Maven Central" | ||
|
|
||
| -plugin.7.Local: \ | ||
| aQute.bnd.deployer.repository.LocalIndexedRepo; \ | ||
| name = Local; \ | ||
| pretty = true; \ | ||
| local = ${build}/local | ||
|
|
||
| -plugin.9.Release: \ | ||
| aQute.bnd.deployer.repository.LocalIndexedRepo; \ | ||
| name = Release; \ | ||
| pretty = true; \ | ||
| local = ${build}/release | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| -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. |
||
| -baselinerepo: Release | ||
|
|
||
| # Always use contracts | ||
| -contract: * | ||
|
|
||
| # Set Git revision information in the manifests of built bundles | ||
| Git-Descriptor: ${system-allow-fail;git describe --dirty --always} | ||
| Git-SHA: ${system-allow-fail;git rev-list -1 HEAD} | ||
|
|
||
| # JUnit | ||
| junit: org.apache.servicemix.bundles.junit; version=4.12 | ||
| mockito: org.mockito.mockito-core; version=2.13.0 | ||
| mockito-deps: org.objenesis; version=2.6.0,\ | ||
| net.bytebuddy.byte-buddy; version=1.7.9,\ | ||
| net.bytebuddy.byte-buddy-agent; version=1.7.9 | ||
|
|
||
| bndversion: 5.2.0 | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we can clarify this in the upcoming weeks in our steering Committee calls and I will change it accordingly.