Community
Participate
Working Groups
In my development workspace I have a combination of PDE and regular java projects. Some of my non-PDE projects *happen* to have META-INF/MANIFEST.MF. Even though the projects do not have PDE.PLUGIN_NATURE, PDE still parses META-INF/MANIFEST.MF files and considers whatever it is able to find there during resolution of dependencies of (proper) PDE projects. These unexpected and often invalid dependencies pollute compile classpath inside workspace and, more importantly, cause runtime problems for Eclipse applications and JUnit Plug-in tests launched from the workspace. I have rather trivial fix (check for PDE natures in org.eclipse.pde.internal.core.WorkspaceModelManager isXXXProject methods), if you are interested.
(In reply to comment #0) > I have rather trivial fix (check for PDE natures in > org.eclipse.pde.internal.core.WorkspaceModelManager isXXXProject methods), if > you are interested. Suggested fixes are always welcome.
I'm surprised that there isn't already a check for the PDE nature. Marking for M1 inclusion. We just have to make sure that there isn't a case that expects this behaviour (where a plug-in is in the workspace, but doesn't have a PDE nature). The only place I could think of where this could happen would be importing binary projects, however, we do assign a PDE nature to all the imported plug-ins. Chris, Darin, any other ideas what side effects this change could have?
I recall that this is a feature, but I can't recall exactly why. Tom, do you know the history on this?
(In reply to comment #3) > I recall that this is a feature, but I can't recall exactly why. Tom, do you > know the history on this? I do not recall the history of this "feature". So the non-PDE project has a manifest with some OSGi headers (e.g. Bundle-SymbolicName and Export-Package) and other PDE-projects are able to import packages from the project or require-bundle on it? That does seem incorrect.
Created attachment 174110 [details] proposed patched that add project.hasNature to relevant methods Alright, since consensus appears to be this is a bug, attached is a proposed fix that adds project.hasNature checks to isXXXProjet methods of WorkspaceModelManager. The patch appears to work for my workspace but is not tested otherwise ;-) Also, I am not sure about possible natures of binary projects, so I added both plugins and features to isBinaryProject. Hope this helps.
Patch seems reasonable. Chris, do you know if there's any reason PDE does not require a PDE nature to consider a project a plug-in/bundle?
(In reply to comment #6) > Patch seems reasonable. Chris, do you know if there's any reason PDE does not > require a PDE nature to consider a project a plug-in/bundle? I can't think of any reason off the top of my head. Many years ago we put some things in the PDE code to help the Harmony team use PDE to develop Harmony. I would just double check with the team to see we don't break their development workflow. Other than that, this change seems reasonable.
(In reply to comment #7) > (In reply to comment #6) > > Patch seems reasonable. Chris, do you know if there's any reason PDE does not > > require a PDE nature to consider a project a plug-in/bundle? > > I can't think of any reason off the top of my head. Many years ago we put some > things in the PDE code to help the Harmony team use PDE to develop Harmony. I > would just double check with the team to see we don't break their development > workflow. Other than that, this change seems reasonable. Even in that case, is it not reasonable for the harmony projects to have a PDE nature?
(In reply to comment #8) > Even in that case, is it not reasonable for the harmony projects to have a PDE > nature? "But why do we need to check in these .project files everywhere" *sigh*
It is too late to put this in for M1. Since no one has been able to come up with a concrete case for not changing this, we'll try it in M2.
I applied the patch with one modification, I took out the changes to isBinaryProject. For a project to be 'binary' it needs to have a internal property set on the project. Only the PDE tooling should be modifying the property and if a project has that property set, we should assume it is intended to be there even if the project doesn't have a plugin or feature nature.
> we'll try it in M2. Thanks for trying :-( This causes bug 322521 and probably also bug 322515. Also, I do not see what's 'major' here.
RE-opening.
I've reverted this fix in HEAD.
(In reply to comment #0) > In my development workspace I have a combination of PDE and regular java > projects. Some of my non-PDE projects *happen* to have META-INF/MANIFEST.MF. > Even though the projects do not have PDE.PLUGIN_NATURE, PDE still parses > META-INF/MANIFEST.MF files and considers whatever it is able to find there > during resolution of dependencies of (proper) PDE projects. These unexpected > and often invalid dependencies pollute compile classpath inside workspace and, > more importantly, cause runtime problems for Eclipse applications and JUnit > Plug-in tests launched from the workspace. What sort of content is in the manifests in the regular Java projects? Are they bundle manifests or something else? Can you attach a sample?
My non-PDE projects have perfectly valid bundle manifest generated by maven-bundle-plugin.
We should document and write a test for this case as no one knew that some SDK projects were missing the nature. We should add the nature to those projects (bug 322654) so that in a future release we might be able to require that only projects with the correct nature get built.
>We should add the nature to those projects >(bug 322654) so that in a future release we might be able to require that only >projects with the correct nature get built. Right but my problem was not about building but simply launching with the SDK project in my workspace. Once the project has been built it might not be required to still have (and test for) the nature. Like the binary bundles don't keep that info either.
Marking for consideration in 4.5. In bug 434195 we discovered that when the PDE model state changes, all 'plug-in' projects get touched. However, we do not check for the PDE nature, so we end up forcing projects unrelated to PDE to build.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
