[
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 broken concept is that "test" means "non-main
That is not true, test means it is only compiled with other test-scoped
sources.
> while code inside a test bundle is the main code and is
> visible according to usual OSGi rules without further filtering, not
> some sidekick stuff.
There is no such thing as "test-bundle" thats a pure PDE/Platform term,
actually you depend on something that is not supposed to be deployed as
a bundle elsewhere and should be simple (test scoped) library dependency.
Sure one could package such thing as a bundle just for the sake of "as
we have always done" and I suggested to PDE to support that specific
case but it was refused as not useful, same as with allowing library
dependencies for (pde)tests.
So it seems, it actually is useful (also for platform) but we better put
workarounds into effect instead of fixing the tooling issue...
> I'm talking here about things working as expected according to usual
> workflows and artifacts that have worked for 20 years
We heard the same complains when moving from java 8 > java 11 so
"working for years" is not a valid argument I think, times are changing
... the pity is more that PDE has not evolved in these 20 years.
Am 28.01.22 um 09:56 schrieb Mickael Istria:
On Fri, Jan 28, 2022 at 9:40 AM Christoph Läubrich
<laeubi@xxxxxxxxxxxxxx <mailto:laeubi@xxxxxxxxxxxxxx>> wrote:
1) making a rule that forbids marking tests as "test" is really not
helping in any case but only shows we try to fix a broken concept.
The broken concept is that "test" means "non-main, need a flag to
consume", while code inside a test bundle is the main code and is
visible according to usual OSGi rules without further filtering, not
some sidekick stuff.
So what's broken is marking test sources inside test bundles as
"non-main, need a flag to consume" while they are regular source.
2) The concept of "test-fragments" is and was always broken, its just
PDE that refuses to support common concepts and thus we where forced to
use them for years leading to hard to find, hard to manage and hard to
run tests.
So it would be better to (now that Tycho supports this and its still
possible to run them in JDT/PDE) migrate to either
a) put *unit* tests that test /internal/ state (e.g. not exported API)
in a 'src_test' folder
b) put *integration* tests that test the /exported/ state (e.g. public
exported API, interaction with the UI) ...
then there is no need for "test-fragments" and no need for annoyance
and
all this maps perfectly to whats common to most developers.
> 1. it's "contaminating": changing it requires downstream
consumers to
> also act on their .classpath to get things working again
I would say it gives consumers a "valuable warning that they do assume
wrong things" :-)
> 2. it's adding no value in the traditional plugin development
workflow
It does as the "traditional plugin development workflow" was always a
workaround because the tools we are using refused to support this. As
this is different now I don't see any reason for keeping this
workarounds.
> 3. it can even cause troubles now that support for test folders in
> Plugins can be interpreted differently by PDE or Tycho (just like
> tests in Maven world).
They are not interpreted differently, PDE simply do not make any
distinction (JDT does!).
By the way its not PDE adding that meta-data as far as I know, the only
one doing it automatically is m2eclipse.
All that is another topic, I'm talking here about things working as
expected according to usual workflows and artifacts that have worked for
20 years and basically suggesting we fix the current state to restore
consistency with OSGi runtime: what is exported in the main jar is not test.
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/pde-dev
