Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add core option for provisioning bundle directly from project module target directory #1025

Open
amichair opened this issue Apr 5, 2021 · 3 comments

Comments

@amichair
Copy link

amichair commented Apr 5, 2021

When a project is built using 'mvn install' then CoreOptions.mavenBundle() can be used to provision its bundles from the local maven repository where it was installed. However, in some circumstances the bundles are not installed, e.g. when run via 'mvn verify', in which case mavenBundle cannot find them. In these cases it would be useful to have a utility method such as a CoreOptions.projectBundle() method that will do the job.

Here is a very basic implementation of the idea:

    public static Option projectBundle(String module, String groupId, String artifactId) {
        String version = MavenUtils.getArtifactVersion(groupId, artifactId);
        String url = OSGiContainerIT.class.getResource("/") + "../../../"
            + module + "/target/" + artifactId + "-" + version + ".jar";
        return bundle(url);
    }

though it should probably be more robust... one option I thought of is to have the same signature as mavenBundle, i.e. accept just the groupId and artifactId, then find the project root dir (topmost dir with pom?), and recurse through all the subdirectories to find a "target" folder under which a jar with the constructed name exists and then use it.

There are various ways to go about this, but whatever is chosen, it would be quite useful and simple to add such a utility to the built-in CoreOptions rather than everyone re-implementing it on their own (I know I'm not the first to do this...)

@amichair
Copy link
Author

amichair commented Apr 8, 2021

(or use maven env variable or such to find root dir, if possible)

@oliverlietz
Copy link
Member

Flexible and robust (https://sling.apache.org/documentation/development/testing-paxexam.html#2-configure-the-build-artifact-to-use-in-integration-testing):

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <executions>
      <execution>
        <goals>
          <goal>integration-test</goal>
          <goal>verify</goal>
        </goals>
      </execution>
    </executions>
    <configuration>
      <redirectTestOutputToFile>true</redirectTestOutputToFile>
      <systemProperties>
        <property>
          <name>bundle.filename</name>
          <value>${basedir}/target/${project.build.finalName}.jar</value>
        </property>
      </systemProperties>
    </configuration>
  </plugin>
    public static Option testBundle(final String systemProperty) {
        final String filename = System.getProperty(systemProperty);
        final File file = new File(filename);
        return bundle(file.toURI().toString());
    }

@amichair
Copy link
Author

When dealing with a multi-module project (with nested modules etc.) this can get quite messy, no?

The idea, if possible, is to have a drop-in replacement for mavenBundle() that does the same but uses the current project structure rather than the local maven repo to resolve the artifacts automatically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants