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

Extract code to automatically derive data from maven-project #6362

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

laeubi
Copy link
Contributor

@laeubi laeubi commented Nov 9, 2024

Currently if one loads the configuration with
aQute.bnd.maven.lib.configuration.BndConfiguration then only the
configuration itself is loaded, but actually some implicit configuration later apply (e.g. from the maven project configuration)
that is currently only performed by the AbstractBndMavenPlugin.

This extracts this logic from the AbstractBndMavenPlugin into the
BndConfiguration class for the following benefits:

  • making the AbstractBndMavenPlugin maintain less code in the execute
    method
  • allow other users of BndConfiguration to easily inherit common
    defaults
  • separation of concerns, easier to debug and understand

@laeubi laeubi force-pushed the extract_common_code_to_maven_artifact branch 2 times, most recently from f330ad1 to f3cc8d4 Compare November 9, 2024 14:16
@laeubi
Copy link
Contributor Author

laeubi commented Nov 9, 2024

The build failure looks like my change in the shared lib is not picked up by the maven build.

@laeubi
Copy link
Contributor Author

laeubi commented Nov 9, 2024

@bjhargrave any hint / idea what could be wrong?

@bjhargrave
Copy link
Member

@bjhargrave any hint / idea what could be wrong?

I don't know.

But this PR seems to be poorly designed from an object oriented perspective. There are 2 things unrelated: reading the configuration from the pom/bnd file and setting some defaults, for bundle building, if they have not been set. I don't see why BndConfiguration should have an instance method for setting defaults since default settings never needed the configuration. That seems a poor place to put default settings for the bnd maven plugin and conflates two things.

@laeubi laeubi force-pushed the extract_common_code_to_maven_artifact branch from f3cc8d4 to aa3c4e2 Compare November 10, 2024 08:51
@laeubi
Copy link
Contributor Author

laeubi commented Nov 10, 2024

There are 2 things unrelated: reading the configuration from the pom/bnd file and setting some defaults, for bundle building, if they have not been set

I think my naming was not really good here, I have now adjusted it to better reflect the meaning. It is actually not any defaults but apply some implicit configuration (and just converted to bnd instructions). Still of course it could also be extracted in a separate class, the main point is that it should not be mangled with the Mojo so it can be used in other context as well.

Sadly this would not resolve the issue that for some reason the invoker tests seem not to "see" the bnd-build jar file with the shared code but some outdated variant :-\

@pkriens
Copy link
Member

pkriens commented Nov 11, 2024

The problem seems to be that the bnd-baseline-maven-plugin has no dependency to biz.aQute.bnd.maven in its pom.xml. Therefore, the latest biz.aQute.bnd.maven it is not copied to the testing repo. With the wonderful maven logic, it will then likely get it from some random repository, which happens to be the previous version ...

Other bnd plugins might have the same problem although the bnd-maven-plugin seems ok.

However, I'd like to see @bjhargrave 's concerns addressed.

Currently if one loads the configuration with
aQute.bnd.maven.lib.configuration.BndConfiguration then only the
configuration itself is loaded, but actually some implicit configuration
later apply (e.g. from the maven project configuration)
that is currently only performed by the AbstractBndMavenPlugin.

This extracts this logic from the AbstractBndMavenPlugin into the
BndConfiguration class for the following benefits:

- making the AbstractBndMavenPlugin maintain less code in the execute
method
- allow other users of BndConfiguration to easily inherit common
defaults
- separation of concerns, easier to debug and understand

Signed-off-by: Christoph Läubrich <[email protected]>
@laeubi laeubi force-pushed the extract_common_code_to_maven_artifact branch from aa3c4e2 to 11e675e Compare November 11, 2024 15:22
@@ -47,6 +57,160 @@ public File loadProperties(Processor processor) throws Exception {
return loadProjectProperties(processor, project, project, configuration);
}

public void loadImplicitProperties(Processor processor, String outputTimestamp) throws Exception {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps a better method name like setPropertiesDefaults. The method is not loading anything. It is setting default values for some bnd properties based upon the values of bnd properties and maven project properties.

It is unfortunate that you pass outputTimestamp here. It would be nicer if this value could be found through the plugin configuration since we may need to pass more such values in the future and end up with having to overload this method.

Comment on lines +54 to +57
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>biz.aQute.bnd.maven</artifactId>
</dependency>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this same change is needed for bnd-reporter-maven-plugin.

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

Successfully merging this pull request may close these issues.

3 participants