[security-dev] common module in picketlink

Anil Saldhana Anil.Saldhana at redhat.com
Fri Jan 18 12:26:43 EST 2013

   I support this except the class file movement to the common module has to
maintain history because there may be a lot of contributors on 
individual classes.

git mv   is all we require.

But making any refactor right now will throw the schedules a bit off.

Let us get others to chime in their thoughts. :)


On 01/18/2013 11:09 AM, Marek Posolda wrote:
> I mentioned yesterday that it may be good to have something like
> separate "common" module, which will contain some stuff and
> functionalities, which may be needed across all other picketlink modules.
> Example of such things could be:
> - Class StringUtil from federation module (Some stuff in this class is
> specific to federation, but some common methods like
> StringUtil.isNotNull, StringUtil.getSystemPropertyAsString etc. are
> useful in other modules as well)
> - Probably some other util classes in federation
> - Some parts of logging
> - Reflection and properties helper classes from IDM module
> - Base64 util class (Currently we have same class forked two times in
> picketlink project. Once in "federation" module and once in "idm" module)
> - Probably some more...
> wdyt?
> Marek

More information about the security-dev mailing list