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
