On 9/24/2013 11:58 AM, Andrew Wnuk wrote:
> Endi,
>
> According to
>
http://pki.fedoraproject.org/wiki/PKI_Interface_Design_%28Legacy%29 you
> moved PublisherProcessor from private to public area.
> Could you provide more details why is this necessary?
>
> Andrew
Andrew,
I'm trying to remove the circular dependencies between the packages so
eventually they will be able to be built separately in this order:
1. certsrv
2. cmscore
3. cms
Currently they appear to be compiled separately (see javac invocations
in base/common/src/CMakeLists.txt), but it actually only works because
they are all stored in the same source folder. Once you separate the
packages into different folders the build will fail due to these
'hidden' dependencies.
The main reason for separation is because certsrv is distributed on
the client machine but the cms and cmscore are not, so we need to make
sure certsrv can be built independently. About cms and cmscore, I
think they actually can be merged into the same package, but for now
they will remain separate for historical reasons. But still, I think
we should remove any circular dependency between them, otherwise there
really is no technical reason to keep them separate because one will
not work without the other.
Originally I thought the build order should be certsrv, cms, then
cmscore (because usually private implementation is build last), but
after some discussions it appears that cmscore contains utilities used
by cms, so the order should be certsrv, cmscore, and cms. Is this the
correct order?
Since originally PublisherProcessor was in cmscore and it depends on
other classes in cms package (FileBasedPublisher, LdapCertSubjMap,
etc.), there are several ways to fix the dependency:
1. Move PublisherProcessor into cms package. This is the simplest
solution, which this patch is trying to do.
2. Move the classes used by PublisherProcessor from cms into cmscore,
but there are quite a few of them, I'm not sure if it makes sense.
3. Create interfaces of those classes in certsrv and modify
PublisherProcessor to use the interfaces. This makes the code more
complicated than necessary.
Let me know what you think. Thanks.
Endi,
Would you mind if we would discuss this on Monday's meeting to make sure
that we have a consensus?
Andrew