-
Notifications
You must be signed in to change notification settings - Fork 194
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
Fix pom.model properties read for bundle-projects and add it-tests #1090
Conversation
Thanks Hannes for looking into this, about the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good and the enhanced test-cases are great, just a little "code-move" so we only address the properties here.
@@ -162,6 +161,10 @@ protected File getRealArtifactFile(File polyglotArtifactFile) { | |||
return polyglotArtifactFile; | |||
} | |||
|
|||
File getArtifactDirectory(Map<String, ?> options) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should not use this method here in the abstract class as on some places as we specifically want to support "directory poms". instead I think it would be better to move Reading-code of the build properties into getEnhancementProperties
and instead have a (non static) getBuildProperties
method that returns the location of the file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that getBuildProperties(File)
is used in multiple other places (i.e.. findParent()
or isTestBundle()
) where the project root file is at hand and that cannot use getEnhancementProperties()
.
Therefore in the end I think that this will make it more complicated.
If you think that this method is not suitable for the read() methods I can revert that, as I said I never hit that code and are therefore not certain that part of the change is good.
Great. Additionally I think it is not the right way if to add Maven-properties via build.properties when there is a 'real' pom.xml that can have a
Thanks. Yes after my first attempt to fix this also broke the reading I convinced myself to better have a good test coverage. |
@HannesWell if you could apply the suggested change so we d not change "too much" I think this is ready to be merged and backported to 2.x |
I would like to do that, but as said in my reply to your remark I'm struggeling to apply it. |
Could it be that you have not yet submit your reply? I don't see one here :-D |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed I forgot to submit my own review/replay. 😅
Sorry for that.
@@ -108,8 +108,7 @@ public ModelWriter getWriter() { | |||
|
|||
@Override | |||
public Model read(InputStream input, Map<String, ?> options) throws IOException, ModelParseException { | |||
String location = PolyglotModelUtil.getLocation(options); | |||
File file = new File(location); | |||
File file = getArtifactDirectory(options); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I'm uncertain that this is correct in case of a bundle-project. But I never hit this code-path and therefore cannot check it.
@@ -134,7 +133,7 @@ public Model read(File input, Map<String, ?> options) throws IOException, ModelP | |||
|
|||
@Override | |||
public Model read(Reader input, Map<String, ?> options) throws IOException, ModelParseException { | |||
File file = new File(PolyglotModelUtil.getLocation(options)); | |||
File file = getArtifactDirectory(options); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As above, I'm uncertain that this is correct at this place. But I never hit this code-path and therefore cannot check it.
tycho-its/src/test/java/org/eclipse/tycho/test/buildextension/PomlessTest.java
Outdated
Show resolved
Hide resolved
@@ -162,6 +161,10 @@ protected File getRealArtifactFile(File polyglotArtifactFile) { | |||
return polyglotArtifactFile; | |||
} | |||
|
|||
File getArtifactDirectory(Map<String, ?> options) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that getBuildProperties(File)
is used in multiple other places (i.e.. findParent()
or isTestBundle()
) where the project root file is at hand and that cannot use getEnhancementProperties()
.
Therefore in the end I think that this will make it more complicated.
If you think that this method is not suitable for the read() methods I can revert that, as I said I never hit that code and are therefore not certain that part of the change is good.
@@ -277,8 +280,7 @@ protected static Properties getBuildProperties(File dir) throws IOException { | |||
|
|||
@Override | |||
public Properties getEnhancementProperties(Map<String, ?> options) { | |||
String location = PolyglotModelUtil.getLocation(options); | |||
File file = new File(location); | |||
File file = getArtifactDirectory(options); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about something like:
@Override
public Properties getEnhancementProperties(Map<String, ?> options) {
String location = PolyglotModelUtil.getLocation(options);
File file = new File(location);
try {
return getEnhancementProperties(file);
} catch (IOException e) {
logger.warn("reading EnhancementProperties encountered a problem and was skipped for this reason", e);
}
return null;
}
protected Properties getEnhancementProperties(File file) throws IOException {
if (file.isDirectory()) {
return getBuildProperties(file);
}
return getBuildProperties(file.getParentFile());
}
and then we override in TychoBundleMapping:
Properties getEnhancementProperties(File file)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good suggestion. Thank you. I applied it!
I also thought about simply moving the isDirectory()/isFile() logic into getBuildProperties()
and then overwriting that in TychoBundleMapping
, that would have worked for all other callers of getBuildProperties()
in AbstractTychoMapping
, but when being overridden in TychoBundleMapping
it would break the other callers since getEnhancementProperties()
is the only affected caller of that method. So this is a suitable solution.
4f34e3e
to
eecbb1e
Compare
I still suspect that the two But since the relevant scenarios I can think of are covered I think that should be OK for now. But we should keep this mind if problems in this area occur. |
The TychoBundleMapping tried to look up the buiild.properties of a 'eclipse-plugin' project in its 'META-INF' folder instead of the project root. This change fixes that. + Add extensive integration tests to ensure all pom.model attributes are correctly read + Remove DefaultTychoResolver.setBuildProperties() because its functionality is already handled by AbstractTychoMapping and it is currently not working
eecbb1e
to
a9eaf32
Compare
As soon as we have merged this I can create PR against the 2.7.x branch with a back-port of this commit. |
The interface contains some methods that are actually not called by the polyglot manager, so we should not care to much unless it causes problems :-) |
The TychoBundleMapping tried to look up the buiild.properties of a 'eclipse-plugin' project in its 'META-INF' folder instead of the project root. This change fixes that. + Add extensive integration tests to ensure all pom.model attributes are correctly read + Remove DefaultTychoResolver.setBuildProperties() because its functionality is already handled by AbstractTychoMapping and it is currently not working Backport of commit: 4c2db22 See eclipse-tycho#1090
Yep. If we want to be sure those methods are not used accidentally, they could throw an UnsupportedOperationException. In case it is used one day at least we would notice immediately and not use a maybe or maybe not correctly working method. Anyway, I did the backport of this in #1094. |
The TychoBundleMapping tried to look up the buiild.properties of a 'eclipse-plugin' project in its 'META-INF' folder instead of the project root. This change fixes that. + Add extensive integration tests to ensure all pom.model attributes are correctly read + Remove DefaultTychoResolver.setBuildProperties() because its functionality is already handled by AbstractTychoMapping and it is currently not working Backport of commit: 4c2db22 See eclipse-tycho#1090
The TychoBundleMapping tried to look up the buiild.properties of a 'eclipse-plugin' project in its 'META-INF' folder instead of the project root. This change fixes that. + Add extensive integration tests to ensure all pom.model attributes are correctly read + Remove DefaultTychoResolver.setBuildProperties() because its functionality is already handled by AbstractTychoMapping and it is currently not working Backport of commit: 4c2db22 See eclipse-tycho#1090
The TychoBundleMapping tried to look up the buiild.properties of a 'eclipse-plugin' project in its 'META-INF' folder instead of the project root. This change fixes that. + Add extensive integration tests to ensure all pom.model attributes are correctly read + Remove DefaultTychoResolver.setBuildProperties() because its functionality is already handled by AbstractTychoMapping and it is currently not working Backport of commit: 4c2db22 See #1090
The
TychoBundleMapping
tried to look up the buiild.properties of a 'eclipse-plugin' project in its META-INF folder instead of the project root and therefore made it impossible to set pom.model attributes as described in the Tycho-wiki, at least from the build.properties in the project root.Add extensive integration test to ensure all pom.model attributes are correctly read
Remove
DefaultTychoResolver.setBuildProperties()
because its functionality is already provided byAbstractTychoMapping
and it is currently not working. It seems to have operated on another project and its properties than those that are used later during execution.