You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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...)
The text was updated successfully, but these errors were encountered:
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.
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:
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...)
The text was updated successfully, but these errors were encountered: