Currently when writing OSGi tests, the distribution is created and then the feature is tested. Therefore the distribution is created using the defined version for depended features. IMO this is wrong since with CI/CD releases are continuously happening and OSGi tests should be executed using it latest dependent feature.
Therefore need to support a range in the p2-repo generation and feature installation so that the latest version based on the range is downloaded and installed.

In the current implementation of carbon-maven-plugins/carbon-feature-plugin/src/main/java/org/wso2/maven/p2/utils/P2ApplicationLaunchManager.java , the -shared argument of the method addArgumentsToUnInstallFeatures does not points to the correct location of p2. This makes feature uninstallation fails.

In the goal "generate", the version mentioned should match with the version mentioned in the bundle's manifest.mf. It was assumed that the artifact dependency version and the version defined in the bundle will be the same. but this is not the case. The symbolic name and version defined in the manifest.mf can be different to the artifact id and version. Therefore this needs to be handled properly.

"null.ini" doesn't sound like a good enough name to be used as a configuration file. Almost all the product distributions seem to ship this.

Currently version (3.0.0), carbon-feature-plugin supports only standalone director runtime. In tycho, it supports osgi and standalone runtime. Carbon-maven-plugin also needs to support similarly osgi runtime.

The Carbon feature plugin has to be changed to incorporate new C5 kernel OSGi related directory structure change.

When trying to uninstall the feature in the sample [1], in a separate pom, it is failing.
https://wso2.org/jira/browse/CMVNPLG-11

Sample available : https://wso2.org/jira/projects/CMVNPLG/issues/CMVNPLG-12

For example in Carbon 5.1.0, there is a configuration file called launch.properties and Carbon-security maintains a copy of the file since it needs to add some properties to it. Need a mechanism to merge the two files when installing the feature.
Different types of configuration files are:

• properties file #48
• xml file #49
• yaml file #50

Currently the carbon.product is required for the following goals: publish-product and generate-runtime. Improve the plugin so that it does not require this file.

Currently the carbon.product is required for the following goals: publish-product and generate-runtime. Improve the plugin so that it does not require this file.

For uninstalling the current feature version and installing the new version using the same pom.xml, we need to specify the dependencies of both the feature versions (old and new) under the <dependencies>...</dependencies> tag, but due to how maven was designed it will picks only one version of a given dependency due the use of nearest in the dependency tree strategy, So a p2 repo with multiple version of the same feature cannot be created by using the release tag v3.1.3.

In the documentation of carbon feature plugin found at carbon-maven-plugins/docs/CarbonFeaturePlugin.md, the documentation for generate-repo goal is not present even though a link is provided at top of the documentation

Subtask of #47

Subtask of #47

Subtask of #47

#39 is not backward compatible and the version needs to be updated to 3.0.0-SNAPSHOT

Since Paths.get() returns automatically the resulting path by combining the strings supplied to it as arguments with the system-dependent default file separator , there is no need to use the File.separator explicitly.