Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [pde-dev] [platform-dev] main vs test source causing annoyance

Just yesterday I resolved long standing PDE Bug 351396 [1] and ignore 'test'-fragments when adding requirements to a Eclipse/Equinox launch.
The check to identify 'test'-fragments is based on the classpath's test-attribute because it seems to be the most reliable indication for it and there is actually no precise specification for something as 'test-fragment', as it has been already said. At least it is more precise than just a naming convention.
Test-Fragments should not be part of a launched Eclipse/Equinox application, unless it is a Plug-in test contained in that test-fragment, because they can pollute or even break the application with their contributed test-resources. Examples would be extra extensions to Extension-Points that already caused some pain for me.
 
This work is part of the greater goal to simplify the creation of Eclipse products that can be launched in the IDE by automatically adding dependencies as suggested in Bug 570760 respectively to fix feature-based launches in this regard that already automatically add requirements. This involes a few more bugs, but the mentioned one is the 'top' of them.
 
An alternative solution to avoid unintended inclusion of test-fragments would be to not add fragments at all when adding requirements to a launch.
 
> >Also I'm not sure PDE adds something to metadata to enforce this warning.
> It has some operations that do set the flag according to the bundle name, but maybe not automatically, could be on import.
 
At the moment ClasspathComputer.updateTestAttribute() adds the classpath test-attribute automatically. IIRC this method is called when a new plugin projects are created whose name ends with .test(s). [3]
 
> So I have no other choice that setting this flag in LSP4E or I cannot develop. It's interrupting my workflow and I do not see any value to compensate this interruption; and luckily I know deeply all those projects to easily find how to remediate, I can imagine some people who are less aware of those things get lost.
 
I'm not sure if this would be a good idea, but I already wondered if it would be useful to add a warning if a plug-in projects ends with name .test(s) but has no test-attribute on its classpath.
The intention was more to replace the weak naming convention with the IMHO stronger attribute but it could also help in this regard (if your test projects comply with the naming convention).
 
 
 
Gesendet: Freitag, 28. Januar 2022 um 10:48 Uhr
Von: "Mickael Istria" <mistria@xxxxxxxxxx>
An: "Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>
Cc: "Eclipse platform general developers list." <platform-dev@xxxxxxxxxxx>
Betreff: Re: [pde-dev] [platform-dev] main vs test source causing annoyance
 
 
On Fri, Jan 28, 2022 at 10:41 AM Andrey Loskutov <loskutov@xxxxxx> wrote:
to avoid possible issues in production environment where the test bundle will be most likely not deployed.
 
We're in a modular world, you never know what's deployed and in which context; and you can't assume how things are consumed.
M
 
So what is the problem? Just add the flag to test bundles you are working on and that's it.
 
The problem is that it's inconsistent: build works fine because it does OSGi, and just opening the project in my workspace will cause an error to pop-up. Then I'll need to put the same flag, potentially annoying transitively other consumers of my test bundle if their are any.
 
It might have no value for you because you know which bundles are supposed to be deployed and which not in the production
 
Define "production". Here for Platform, there are committers that are all supposed to understand that kind of things when merging or reviewing. I suspect if there is no value for me, there is no value for any committer, thus no compelling value for the project.
 
but other people might not have that knowledge and happily consume API from the test projects inside production projects.
 
There are already API tools, internal, x-friends... flags to highlight all that in a more OSGi-native way, so the value added by this flag is 0 compared to it.
And the org.eclipse.ui.tests.harness bundle can be interesting in some cases in production of other projects (eg SWTBot is using IIRC in its "production").
 
I'm still not convinced about the value and would really like to read some existing discussion or bug report where this flag has helped anyone; because I could see here, and earlier in Tycho (that interprets that flag differently/correctly as opposed to how Platform/PDE sets it) that is has caused some trouble.
_______________________________________________ pde-dev mailing list pde-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/pde-dev
 
 

Back to the top