Hi Konrad,

On Thu, Apr 21, 2016 at 3:23 PM, Konrad Windszus <konra...@gmx.de> wrote:
> I would like to revive this old thread, because I now want to leverage the 
> TeleporterRule...

Very cool!

> ...There are two customizers available..

The idea is that one creates their own customizer (which can be dead
simple) as needed, there's no point in having "standard" customizers.

>... The only customization being necessary is in most cases
> the ClientSideTeleporter.include/excludeDependencyPrefix....

The client-side teleporter also needs to have the connection
parameters of the server under test.

> ...That I would rather like to parameterize through system properties!...

That's not transparent in many cases, we end up having lots of
properties which have not convenient to manage in some environments.

But you could of course create a property-driven customizer that
people who want to work like that can use.

>....for me the optimal way developing ITs is the following
>
> 1) Create a new JAR (not bundle)
> 2) Leverage slingstart-maven-plugin to bootstrap and start Sling or just
> connect to an existing already running instance (only through pom.xml
> changes achievable)...

I'd like to stay flexible about the mechanisms used to start the
instance under test.

> ...3) Put the ITs in src/test/java and with the suffix IT
> 4) Let maven-failsafe-plugin execute the IT containing the TeleporterRule
> (which leads to deployment of the temp bundle containing the ITs)..

That's how things happen now in the bundle-with-it sample, isn't it?

> ...testing/samples/bundle-with-it...
> 1) Still uses the SlingTestBase (through its own Customizer) ...

SlingTestBase is used in this case to map system properties to the URL
of the server under test...which is what you suggested above ;-)

But maybe this can be replaced with a more focused utility, or a
standard customizer that does that, I agree.

> ...2) Is of packaging "bundle" for whatever reason...

The reason is having the bundle under test and its integration tests
in the same Maven module. That's not always desired but in this case
that's the goal of this sample.

> ...How do you feel about reworking the Teleporter, that this simple setup is
> supported without any Customizer at all?...

There will be a customizer even if it's not that Customizer
interface...baking the system property names into the teleporter is
not a good idea IMO.

OTOH if you want to add such a default customizer in the teleporter
module, and define clear rules about when it's used, that's certainly
possible. As we have released the teleporter we need to stay backwards
compatible, but it's probably possible to support your simplified use
case while keeping the existing functionality.

Keep in mind that the server must have no knowledge of the client-side
classes, which is why I've been using some loadClass methods and
slightly unusual way of getting at things.

At this point I suppose the best is for you to create a minimal
example that exposes what you'd like to do, and we can then discuss
it.

-Bertrand

Reply via email to