Liferay 7 - Overriding Bundle-Version programatically

[Denis Harder, modificado hace 7 años.]

Hello, my team used gradle to build our old liferay 6 projects. Within gradle, we set the overall project.version to the specific version we were building/publishing (with jfrog plugin). This would be applied to all projects within the overall build. Within Liferay 7, the jar mechanism appears to be overridden by the BundlePlugin which uses the bnd.bnd file for each module to override the version. I am looking for a way to set the version numbers for all my projects without updating each individual bnd.bnd file. I have tried using the build extension below, but it is still applying the version found in the project's bnd.bnd file (i.e., not using version 1.2.3).

Is the below code supposed to override the values in the bnd.bnd file or is there another way to accomplish my goal?
Thanks.

https://github.com/TomDmitriev/gradle-bundle-plugin

dependencies {
        compileOnly group: "com.liferay.portal", name: "com.liferay.portal.kernel", version: "2.0.0"
        ...
}


jar {
        manifest {
                attributes 'Bundle-Version': '1.2.3'
        }
}

bundle {
        instruction 'Bundle-Version' , '1.2.3'
}

[David H Nebinger, modificado hace 7 años.]

Sorry, but isn't this an antipattern?

The whole point of versioning things differently is that the version is dependent upon code changes, not overall build version.

[Denis Harder, modificado hace 7 años.]

Agreed.. but from our perspective we are basing the version number on the commit point of the entire codebase. We use a puppetized process that tears down and rebuilds servers when a newly released version of the entire codebase is ready. We do not need individualized modular code pushes. For us, we push all the code or nothing. The individual module pushes is great for a local development platform, but not needed for our server deployments.

So, is this not possible in liferay 7?

[David H Nebinger, modificado hace 7 años.]

Not that I know of, the bnd files control the versioning. It's not based upon gradle scripts or IDE settings.

Liferay has a similar sort of deployment; when you grab the ga3 bundle, it's all or none. But they don't version every contained module as ga3, they are all versioned independently.

I don't want to argue with your process, I'm guessing you have your reasons. This is more for the general developer that comes to the forums wondering how to version their modules. For that person, the modules all should version independently of the workspace because workspace version or workspace commit label have no real impact on individual module versioning - versions should be updated as the module code changes, and those are independent activities of the module and controlled by the bnd version tag.

[Enrico Costanzi, modificado hace 6 años.]

I managed to do what Denis asks by: and by:

- removing the Bundle-Version row from the all the bnd.bnd

- modifying the build.gradle of the parent project

allprojects {
    apply plugin: 'eclipse'
    apply plugin: 'java'
    apply plugin: 'maven'

    version = '1.1.1'

    jar {
        manifest {
            attributes("Bundle-Version": version)
        }
    }
}

I understand this is an antipattern but at least it's a way to start versioning and being aware of the state of what you have deployed. I see it as a first step before switching to a more appropriate way.