Refactoring of picketlink-integration-tests
by Ondra Lukas
Hi,
we would like to do some refactoring of PicketLink integration testsuite for easier QE testing with new versions of EAP. We have some ideas how to improve it and I want to ask you what do you think about that. Here is the list, we would like to:
1) change of configuration which running specified tests for specified container. It is currently set by @TargetContainers annotation. We prefer to using better usage of maven profiles and for instance Java subpackages according to profiles. Every subpackage will contain tests which will run only in that profile (for example org.picketlink.test.trust.tests.eap6 will contain tests for EAP6 profile). Tests which run in every profile will stay in current packages. Tests which run in more profiles (but not in all of them) will be added by include/exclude parameters of maven-failsafe-plugin.
Why?
It will be easier to configurate it for QE testing. We need some easy way how to see each test of some profile. Currently we have all tests together and it's quite uncomfortable. It will be simpler to add a new container too.
2) avoid use of Ant and try to rewrite it to maven (using Maven Resource Plugin etc.).
Why?
We want to have ability of setting properties from command line (which is not handled correctly by maven-antrun-plugin). Also we want to have only one type of configuration files.
3) create Arquillian's ServerSetupTasks for setting containters (setting security domains for testing etc.).
Why?
We want to avoid XSLT because it is sometimes out of work in diffrent type of JDKs.
4) remove "dist" folders from every container (/integration-tests/CONTAINER/dist) and remove distributions from dist. We will use only one dist folder which will be located in integration-tests folder.
Why?
If anybody is cloning picketlink-integration-tests from git, he have to clone distributions, but it take a lot of unnecessary time. We think that better way is have one empty folder for all distributions. User can input nedded distributions.
What do you think about that? Does anybody have any idea about improvement of picketlink-integration-tests testsuite?
Thanks,
Ondrej Lukas
12 years, 11 months
Authorization constructs in PicketLink3
by Anil Saldhana
Shane/Pedro - we should start discussing the constructs for
authorization in PL3. We have a few options on the table. We need to
figure out what we need such that for PL3 users, we have some options.
Lets use this thread to figure out the various options/strategies.
13 years
PicketLink SCIM Module
by Shane Bryzak
I've been reviewing the capabilities of the SCIM module (which are
defined by the SCIM specification [1]) and someone correct me if I'm
wrong, but it only seems to provide a subset of the features that we
support in PicketLink. Specifically missing are authentication, and
support for the extended relationship types (basically everything
besides group membership). I'm wondering if it might be worth providing
a PicketLink REST module instead, which would provide two sets of
RESTful services; the first being a SCIM-compliant service, the second
being a more proprietary service that exposes all of the capabilities of
PicketLink.
On top of this, I think it would be of huge benefit to provide both Java
and JavaScript clients to consume both services. Anil has already
implemented a Java-based SCIM client in the SCIM module, but imagine if
we provided PicketLink JavaScript scripts that web application
developers could drop into their app - this would be a huge development
time saver. I'm also thinking that the JavaScript clients should
support a variety of authentication mechanisms; BASIC, DIGEST, X509,
user/password, OAuth, etc. This is kind of uncharted territory for me
(REST-based auth) so any feedback or opinions on this would be appreciated.
Shane
[1] http://www.simplecloud.info/specs/draft-scim-api-01.html
13 years
PicketLink Integration Github organization
by Anil Saldhana
Hi All,
footprint of PicketLink is pretty huge considering the components it
has - idm,core,saml,social,scim etc. Currently PicketLink components are
housed in the GitHub PicketLink organization
(https://github.com/picketlink). The PL2 workspaces have been moved to
a separate organization called picketlink2 (https://github.com/picketlink2).
We will need to host integration code for at least the following projects:
a) Camel
b) Undertow
c) Infinispan
Since the integration workspaces is only going to grow over time, I
would like to propose a separate github organization called
picketlinkintegration.
This is just an attempt to de-clutter and separate concerns.
Wdyt?
Regards,
Anil
13 years
Caching Interfaces
by Anil Saldhana
Shane/Pedro,
friday, I put in a PR for a caching interface (api/impl) that will
allow external integration to various caching frameworks. This feature
is a gap we have. We did broach caching few weeks back.
https://github.com/picketlink/picketlink/pull/107
We can modify the PR based on your feedback.
Regards,
Anil
13 years
QE Testing for IDM
by Anil Saldhana
Hi All,
Pedro has setup Jenkins build for the PicketLink workspace long ago.
This covers building the workspace and running the unit tests.
But the IDM component needs to be tested against various DB/LDAP
servers. We need to setup some automated builds for this.
Bolek did extensive testing for 1.x IDM long ago. Since we have the IDM
tests, we just need to test against various products.
I started a document
(https://docs.jboss.org/author/display/PLINK/QE+Testing) toward this.
The references at the bottom show Bolek's matrix.
Peter Skopek will coordinate this from Brno getting guidance from
Dominik (GateIn QE).
Regards,
Anil
13 years
The PicketLink formerly known as 3.0
by Shane Bryzak
Hi guys,
We've recently been reviewing our plans with the product management team for EAP, amongst others. There was immediate confusion around the version numbers for PicketLink.
PicketLink Federation 2.x is included in EAP 6.x, and there was an expectation that an upgrade to PicketLink 3 would involve substantial changes to PicketLink Federation. This is not actually the case, PicketLink 3 contains only new components such as IDM and the CDI integration.
This got us thinking that in fact it might be less confusing to NOT bump the version to 3.x. We looked at the version history, and realised that PicketLink IDM 1.x was never upgraded to 2.x, so this also makes sense, and brings all the components to 2.x.
With this in mind, I'd like to propose that we release all the cool new features/modules that we've been working on lately as PicketLink 2.5. Hopefully this isn't going to cause any major issues for anyone, but if you do have objections please let me know.
Thanks,
Shane
13 years
