Thanks for you fast input. > On 21 Apr 2016, at 16:00, Bertrand Delacretaz <[email protected]> wrote: > > Hi Konrad, > > On Thu, Apr 21, 2016 at 3:23 PM, Konrad Windszus <[email protected]> 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. I tend to disagree here, because for 99% of the cases if should be that simple as outlined below!
> >> ... 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. I will create a PR below https://issues.apache.org/jira/browse/SLING-5677. > >> ....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. I agree, but IMHO this should not be part of the execution via the maven-failsafe-plugin but should happen before! > >> ...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? That part yes, only the bootstrapping is different here. > >> ...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. Yes, I would like to separate the bootstrapping part. > >> ...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. I see, thanks for the explanation! > >> ...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. Sounds like a plan. Will do so below https://issues.apache.org/jira/browse/SLING-5677. > > -Bertrand
