-
Notifications
You must be signed in to change notification settings - Fork 45
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 #20 - XMLParser should not require a bundle context but a Parser in the constructor #21
Conversation
15b9f6d
to
01e2de3
Compare
the constructor
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.
Please restore visibility of unrelated flags to not introduce unrelated extra risk as part of this commit.
@@ -192,31 +192,31 @@ private Location getLockLocation(URI repositoryLocation) throws IOException { | |||
// Constants defining the structure of the XML for a SimpleArtifactRepository | |||
|
|||
// A format version number for simple artifact repository XML. | |||
public static final Version COMPATIBLE_VERSION = Version.createOSGi(1, 0, 0); |
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.
Why changing that here? Is it required as part of the change?
I'd rather not change visibility here as it's very likely some other stuff (wrongly) depends on it; and it doesn't seem related to the desired improvement.
Also, static final
should at least remain.
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.
"public static final" is the default in interfaces and thus my eclipse-sdk removes unnecessary modifiers here. It seems I have to somewhat fore ommph not reformatting/cleanup code, but maybe we simply could keep it as it is equivalent?
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.
My bad. Let's merge.
It looks like this change requires some adjustments in Tycho. |
After I simply reverted this change locally P2 and subsequently Tycho build fine without further changes. |
Can you share a Stack trace that shows where the problem occurs? |
Yes. After basically removing the BundleContext argument from the constructors of
|
Could it be due to the recent removed / changed providers of some packages? I have a while back already did as you said and removed the BC from constructor and it has worked, so I'm a bit surprised we are seeing issues here. Are you sure that you have only P2 changed / consumed from your local repo? I generally use |
Strange.
Relatively sure. I cannot remember having installed another Eclipse project into my local Maven-repo. And I deleted the org/eclipse/equinox respectively tycho folders in my local m2-repo before a p2+tycho installation round. I can only say that reverting this change on top of my change in #64 and building/installation p2+tycho again fixed the issue for me locally. But you are right. The potential for interference is great here. I will try your suggestion later this evening and can report back. |
At least the error does not indicate a problem in the code itself but some class-path issues, so there must have changed something else beside the usual removing of the BC that triggers this, one thing that might interfere here is that we use P2 in pom and in target (and thus maybe the pom.xml has to be adjusted as well), but I don't see yet why reverting this change should make a difference here... this reminds me of #23 and that we should get a faster feedback cycle from p2->tycho ... |
That sounds reasonable. I'll try that.
Agree. :) |
No description provided.