-
Notifications
You must be signed in to change notification settings - Fork 83
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
List OSGI plugins in the export list #799
Conversation
the second assumption (instruction file name is always eclipse.pde/ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/natures/BndProject.java Lines 24 to 26 in 27cf508
the first assumption (the project structure) looks to be correct too, but pinging @laeubi to confirm just in case. |
Yes |
File bin = new File(model.getInstallLocation()); | ||
if (bin.exists()) { | ||
File file = new File(bin.getParent(), ICoreConstants.BND_FILENAME_DESCRIPTOR); | ||
return file.exists(); | ||
} | ||
return false; |
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.
Wouldn't it be better to operate on IResources
here?
I.e. check if model.getUnderlyingResource()
returns non null and then check for the pde.bnd
file of that resource's project?
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.
Furthermore it is actually not necessary to check for the existance of the directory and file.
File
, just like Path
or IFile/IFolder/...
are just handles/pointers and one can create them regardless of if they exist.
Just checking if the finally constructed (I)File
is an existing file saves one call to the file-system (given the file exists).
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.
If you have a project handle one can also use org.eclipse.pde.internal.core.natures.BndProject.isBndProject(IProject)
(that will only validate the nature) or org.eclipse.pde.internal.core.bnd.BndProjectManager.getBndProject(IProject)
if also want to validate is has a valid instruction 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.
Wouldn't it be better to operate on IResources here?
I.e. check if model.getUnderlyingResource() returns non null and then check for the pde.bnd file of that resource's project?
As far as I can see on the callerside the project is already known!
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.
Furthermore it is actually not necessary to check for the existance of the directory and file.
File
, just likePath
orIFile/IFolder/...
are just handles/pointers and one can create them regardless of if they exist. Just checking if the finally constructed(I)File
is an existing file saves one call to the file-system (given the file exists).
I have implemented the changes suggested by @laeubi , which has made these changes unnecessary, and also doesn't attempt file access.
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.
If you have a project handle one can also use
org.eclipse.pde.internal.core.natures.BndProject.isBndProject(IProject)
(that will only validate the nature) ororg.eclipse.pde.internal.core.bnd.BndProjectManager.getBndProject(IProject)
if also want to validate is has a valid instruction file.
I have implemented the changes, kindly look through and let me know @laeubi .
@@ -60,6 +60,9 @@ public interface ICoreConstants { | |||
/** Constant for the string <code>build.properties</code> */ | |||
String BUILD_FILENAME_DESCRIPTOR = "build.properties"; //$NON-NLS-1$ | |||
|
|||
/** Constant for the string <code>pde.bnd</code> */ | |||
String BND_FILENAME_DESCRIPTOR = "pde.bnd"; //$NON-NLS-1$ |
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.
There is already org.eclipse.pde.internal.core.natures.BndProject.INSTRUCTIONS_FILE
so you should at laest reference it here
String BND_FILENAME_DESCRIPTOR = "pde.bnd"; //$NON-NLS-1$ | |
String BND_FILENAME_DESCRIPTOR = BndProject.INSTRUCTIONS_FILE; |
@@ -60,6 +60,9 @@ public interface ICoreConstants { | |||
/** Constant for the string <code>build.properties</code> */ | |||
String BUILD_FILENAME_DESCRIPTOR = "build.properties"; //$NON-NLS-1$ | |||
|
|||
/** Constant for the string <code>pde.bnd</code> */ |
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 seems not used anymore in your PR maybe revert this change?
@alshamams can you please rebase/squash and cleanup the mentioned no longer needed part? The I think this can be merged. |
b03916d
to
d8751a7
Compare
Hi @laeubi , |
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.
For me it looks all sane @HannesWell @gireeshpunathil any concerns to merge?
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.
No concern from me, just a minor, Not required suggestion.
...g.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/wizards/exports/PluginExportWizardPage.java
Outdated
Show resolved
Hide resolved
Thanks @alshamams please squash all commits into one, then we can submit this. |
The commit fixes OSGi plugins (that have been created using standard OSGi framework with 'Generate OSGi metadata automatically' feature) not being displayed in the export dialog box. This happens because an OSGi project has a pde.bnd file, unlike the eclipse plugins, which has build.properties. Therefore the previous behaviour was to check for the presence of a build.properties file for validating a plugin project. This assumption breaks with the new type.
f7064ef
to
4904fda
Compare
Done @HannesWell |
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.
Thanks @alshamams.
In general you can actually always squash locally or just amend existing commits and force push as one commit (unless you eventually want to make a change with multiple commits that are self-contained by themself).
After force-push you can still see in the Github UI what as changed by clicking the Compare
button in the feed:
Since Gireesh and Christoph were fine with this change too, I'll submit it as soon as the build completes.
The commit fixes OSGi plugins (that have been created using standard OSGi framework with 'Generate OSGi metadata automatically' feature) not being displayed in the export dialog box. This happens because an OSGi project has a pde.bnd file, unlike the eclipse plugins, which has build.properties. Therefore the previous behaviour was to check for the presence of a build.properties file for validating a plugin project. This assumption breaks with the new type.
The commit relies on the following assumptions in case of OSGi template projects:
Fixes: #600