RE: Upgrade to the latest Pluto - another ToDo / FixMe

["Rudnev, Alex (OCTO)" <Al...@dc.gov>]

>>In addition to that is not it a good time to move
>>SwingConsumer to consumer/swing or provider/swing folder and add another
>>consumer sub-project(?) for that many time mentioned proxy portlet? Do you
>>have any draft for that or plans / expected timeframes?
>>
>>
> yes maybe wise to move the swing consumer code out of the general
> consumer code packages.
I meant moving SwingConsumer from root in folder structure, but renaming
packages sounds like a good idea :)

There is another, more important change that probably should be added to
ToDo list - refactoring of persistence and log (for log it would be just
fixes of dirty hacks in LogManager) mechanism implementation. I believe that
it would be nice to have libraries that can be separated into shared,
consumer and produces groups. My understanding is that currently either
there are some classes in persistence and log packages, which refer classes
from consumer and producer at the same time, or some of the classes refer
producer classes, while other refer consumer classes (from the same
package). While in second case it would be just some complications with
build file (because we would need to split classes from single package into
two categories manually), in first case (as with
ServerPersistentInformationProviderImpl from
org.apache.wsrp4j.persistence.xml.driver) it creates additional unnecessary
inter-package dependences. Please correct me if I'm missing something here
(i.e. that all the classes in producer and consumer packages, which are not
part of Pluto or Swing providers, should be considered as part of shared
lib, so there is no point for such restructuring).

I looked one more time at build.xml and found that it is intended that 5
jars will be build: 1.1 - shared, 2.1 - server, 2.2 - consumer, 3.1 -
pluto-provider, 3.2 - swing-consumer. So, it's sounds like a good idea to
compile 1.1 first, then 2.1 and 2.2 in any order, and then 3.1, 3.2, 3.x,
which is not possible with current class dependences.

Probably good place to start would be to fix LogManager and by doing so
remove (probably) requirement for servlet.jar (or is it done already and I
just missed it?). [ToDo / FixMe]

> On the proxy portlet we started to work on this, but then came vacation,
> illness,....
> I hope to have an answer for that soon.
> 
> -cu
> Richard