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

List OSGI plugins in the export list #799

Merged
merged 1 commit into from
Nov 1, 2023

Conversation

alshamams
Copy link
Contributor

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:

  • The location of the pde.bnd file is always under the root folder of the plugin project
  • The filename is always constant, namely, pde.bnd.

Fixes: #600

@github-actions
Copy link

github-actions bot commented Oct 13, 2023

Test Results

     270 files  ±0       270 suites  ±0   1h 15m 29s ⏱️ + 8m 2s
  3 327 tests ±0    3 297 ✔️ ±0  30 💤 ±0  0 ±0 
10 278 runs  ±0  10 188 ✔️ ±0  90 💤 ±0  0 ±0 

Results for commit 4904fda. ± Comparison against base commit 6465a65.

♻️ This comment has been updated with latest results.

@gireeshpunathil
Copy link
Contributor

the second assumption (instruction file name is always pde.bnd) is definitely right due to:

public static final String INSTRUCTIONS_FILE_EXTENSION = ".bnd"; //$NON-NLS-1$
public static final String INSTRUCTIONS_FILE = "pde" + INSTRUCTIONS_FILE_EXTENSION; //$NON-NLS-1$

the first assumption (the project structure) looks to be correct too, but pinging @laeubi to confirm just in case.

@laeubi
Copy link
Contributor

laeubi commented Oct 15, 2023

Yes pde.bnd in the project root is a "marker file" that should always be constant.

Comment on lines 76 to 81
File bin = new File(model.getInstallLocation());
if (bin.exists()) {
File file = new File(bin.getParent(), ICoreConstants.BND_FILENAME_DESCRIPTOR);
return file.exists();
}
return false;
Copy link
Member

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?

Copy link
Member

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).

Copy link
Contributor

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.

Copy link
Contributor

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!

Copy link
Contributor Author

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).

I have implemented the changes suggested by @laeubi , which has made these changes unnecessary, and also doesn't attempt file access.

Copy link
Contributor Author

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.

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$
Copy link
Contributor

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

Suggested change
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> */
Copy link
Contributor

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?

@laeubi
Copy link
Contributor

laeubi commented Oct 27, 2023

@alshamams can you please rebase/squash and cleanup the mentioned no longer needed part? The I think this can be merged.

@alshamams alshamams force-pushed the plugin_export_bugfix branch from b03916d to d8751a7 Compare October 31, 2023 09:22
@alshamams
Copy link
Contributor Author

@alshamams can you please rebase/squash and cleanup the mentioned no longer needed part? The I think this can be merged.

Hi @laeubi ,
I have reverted the change and rebased after squashing.

Copy link
Contributor

@laeubi laeubi left a 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?

Copy link
Member

@HannesWell HannesWell left a 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.

@HannesWell
Copy link
Member

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.
@alshamams alshamams force-pushed the plugin_export_bugfix branch from f7064ef to 4904fda Compare November 1, 2023 19:09
@alshamams
Copy link
Contributor Author

Thanks @alshamams please squash all commits into one, then we can submit this.

Done @HannesWell

Copy link
Member

@HannesWell HannesWell left a 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:

grafik

Since Gireesh and Christoph were fine with this change too, I'll submit it as soon as the build completes.

@HannesWell HannesWell merged commit 3ed2ae9 into eclipse-pde:master Nov 1, 2023
14 checks passed
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.

OSGi Metadata Automatic Generation: export dialog doesn't list projects that have auto gen enabled.
4 participants