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 
> the example I gave above
Your example only shows that the current concept is bad and makes it hard to consume platform code by other parties.
Sorry that your are annoyed here by a "platform thing", but compared to the many times "platform things" annoyed/frustrated me I think its quite fair :-)
What I don't get is why platform should in this case care about annoyed consumers if it does not do so for other (not so deeply involved people)... 

> Exactly, there are bundles and that's all
Yes that's where the horizon of PDE/Platform ends, but that's not the truth. Maven (and BND) shows there is a world beyond, and I have even shown working examples that this is possible as well with PDE (with just inconvenience of course). 

> Maybe later
"later" is the project-managment term of "never" isn't it? For me, later is now. 

> Wrong. Eclipse Platform do provide in some test bundles
And as thus marks the source as test, so everything is correct. What is *not* correct is the narrow minded attitude of PDE to look beyond the border and adopting the concept as I have proposed here [1], as an alternative, library code should simply be consumed as a library (even though it might be packed as a bundle) but was also refused [2]. 

> I don't get how it is useful for Platform.
You asked for feedback not for confirmation ... if you just wanted to announce something that's already decided please make it more clear. 

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=573534
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=572627

Am 28.01.22 um 10:38 schrieb Mickael Istria:
On Fri, Jan 28, 2022 at 10:31 AM Christoph Läubrich <laeubi@xxxxxxxxxxxxxx <mailto:laeubi@xxxxxxxxxxxxxx>> wrote: 

      > The broken concept is that "test" means "non-main

    That is not true, test means it is only compiled with other test-scoped
    sources.
Look more closely at how things are implemented in practice, particulary the example I gave above and https://bugs.eclipse.org/bugs/show_bug.cgi?id=539998 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=539998> confirm that this "test" flag is capable of breaking downstream adopters in the workspace. 

    There is no such thing as "test-bundle" thats a pure PDE/Platform term,
Exactly, there are bundles and that's all, and this "test" flag is really a bad way of controlling the visibility while that's already controlled by OSGi. Maybe later we can have more and more bundles with actual "test" (not shipped) source in them to do it the Maven way, and then using the "test" flag will be correct. But at the moment, the way it's used in the context of plugin development is wrong as it relies on a misunderstanding of what this flag is supposed to achieve; it's more than a simple decoration. 

    actually you depend on something that is not supposed to be deployed as
    a bundle elsewhere and should be simple (test scoped) library
    dependency.
Wrong. Eclipse Platform do provide in some test bundles some utilities that are fine to reuse by other projects to help them writing their tests. That's what I'm doing here. 

    So it seems, it actually is useful (also for platform) but we better
    put
    workarounds into effect instead of fixing the tooling issue...
I don't get how it is useful for Platform. Can you please mention any actual issue that was fixed or prevented with addition of the flag, to compensate this issue it is causing? 

_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

Back to the top