[
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