You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsrp4j-dev@portals.apache.org by Diego Louzán <dl...@apache.org> on 2005/08/26 18:02:01 UTC
Some questions about design
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Right now the new repository is split in 4 main modules: commons, consumer (for
proxyportlet) and producer. I would probably rename consumer to
consumer-proxyportlet to be able to add a new module consumer-swingconsumer.
But this mail is for another purpose.
In the current repository, we have org.apache.wsrp4j.producer and
org.apache.wsrp4j.consumer packages in the main src directory. As this code is
code that would be shared by any producer (consumer) implementation, initially
I took the decision to include it in commons module, so in that module we have
org.apache.wsrp4j.commons.consumer and org.apache.wsrp4j.commons.producer
packages. Take a look at the source directory if I didn't explain this very
well (sorry for broken English).
My question is: should I move these packages to new modules (like
commons-consumer and commons-producer), so we'll end having this repository
structure:
wsrp4j/ -->
commons/
Common code.
commons-consumer/
Common code to any consumer implementation.
Depends on commons.
commons-producer/
Common code to any producer implementation.
Depends on commons.
consumer-proxyportlet/
JSR-168 portlet consumer implementation.
Depends on commons and commons-consumer.
consumer-swingconsumer/
Java Swing application consumer implementation.
Depends on commons and commons-consumer.
producer/
Axis-based producer implementation.
Depends on commons and commons-producer.
or should I continue with the current structure? Suggestions welcome.
Regards.
Diego.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDDzz5gyzZYflJelERAnvoAKCSy/92RC8tAvtg9/17XidvMkpFvQCgmFJ+
ykiVC3PrsQ1sw6Ofr1EDVgs=
=u6Ed
-----END PGP SIGNATURE-----
Re: Some questions about design
Posted by Diego Louzán <dl...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
How about adding another module named "persistence"? I found that the xml
implementation included in org.apache.wsrp4j.commons.persistence.xml depends on
some interfaces from commons-consumer/ and commons-producer/ modules
(logically, as this implementation maps those classes to xml files). So I think
we have two options:
a) leave generic persistence classes in commons/ and create another module
named persistence-xml with xml implementation (using castor):
wsrp4j/ -->
commons/
Common code.
commons-consumer/
Common code to any consumer implementation.
Depends on commons.
commons-producer/
Common code to any producer implementation.
Depends on commons.
persistence-xml/
XML mapping persistence implementation.
Depends on commons, commons-producer and commons-consumer.
consumer-proxyportlet/
JSR-168 portlet consumer implementation.
Depends on commons, commons-consumer and persistence-xml.
consumer-swingconsumer/
Java Swing application consumer implementation.
Depends on commons, commons-consumer and persistence-xml.
producer-axis/
Axis-based producer implementation.
Depends on commons, commons-producer and persistence-xml.
b) refactor all persistence code to a persistence/ module that includes the
xml implementation.
wsrp4j/ -->
commons/
Common code.
commons-consumer/
Common code to any consumer implementation.
Depends on commons.
commons-producer/
Common code to any producer implementation.
Depends on commons.
persistence/
Includes all persistence code.
Depends on commons, commons-producer and commons-consumer.
consumer-proxyportlet/
JSR-168 portlet consumer implementation.
Depends on commons, commons-consumer and persistence.
consumer-swingconsumer/
Java Swing application consumer implementation.
Depends on commons, commons-consumer and persistence.
producer-axis/
Axis-based producer implementation.
Depends on commons, commons-producer and persistence.
Which one do you prefer? If you have another approach, please tell me ^_^
Regards.
Diego.
Julie MacNaught wrote:
> I like the finer grained modules. I think org.apache.wsrp4j.producer
> and org.apache.wsrp4j.consumer should be in different modules.
>
> What do you also think of then changing the axis producer to
> producer-axis, so the modules look like this:
>
> wsrp4j/ -->
> commons/
> Common code.
> commons-consumer/
> Common code to any consumer implementation.
> Depends on commons.
> commons-producer/
> Common code to any producer implementation.
> Depends on commons.
> consumer-proxyportlet/
> JSR-168 portlet consumer implementation.
> Depends on commons and commons-consumer.
> consumer-swingconsumer/
> Java Swing application consumer implementation.
> Depends on commons and commons-consumer.
> producer-axis/
> Axis-based producer implementation.
> Depends on commons and commons-producer.
>
> Then additional producer implementations would get new modules. The
> current implementation is heavily dependent on axis, so this would help
> to isolate this dependency. Looking ahead to version 2.0 of WSRP, we
> will be implementing new port types, so the producer-axis module will be
> have to be re-written. Hopefully we will be able to leverage the code
> in producer-commons.
>
> Diego Louzán wrote:
>
> Right now the new repository is split in 4 main modules: commons,
> consumer (for
> proxyportlet) and producer. I would probably rename consumer to
> consumer-proxyportlet to be able to add a new module
> consumer-swingconsumer.
> But this mail is for another purpose.
>
> In the current repository, we have org.apache.wsrp4j.producer and
> org.apache.wsrp4j.consumer packages in the main src directory. As this
> code is
> code that would be shared by any producer (consumer) implementation,
> initially
> I took the decision to include it in commons module, so in that module
> we have
> org.apache.wsrp4j.commons.consumer and org.apache.wsrp4j.commons.producer
> packages. Take a look at the source directory if I didn't explain this
> very
> well (sorry for broken English).
>
> My question is: should I move these packages to new modules (like
> commons-consumer and commons-producer), so we'll end having this
> repository
> structure:
> wsrp4j/ -->
> commons/
> Common code.
> commons-consumer/
> Common code to any consumer implementation.
> Depends on commons.
> commons-producer/
> Common code to any producer implementation.
> Depends on commons.
> consumer-proxyportlet/
> JSR-168 portlet consumer implementation.
> Depends on commons and commons-consumer.
> consumer-swingconsumer/
> Java Swing application consumer implementation.
> Depends on commons and commons-consumer.
> producer/
> Axis-based producer implementation.
> Depends on commons and commons-producer.
>
> or should I continue with the current structure? Suggestions welcome.
>
> Regards.
> Diego.
>>
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDEhuDgyzZYflJelERAj8XAJ45B6pG3RwixYw1GjanUQphLdmHIACdHFWv
3uHgrHXW3EEcBqNAL5nE0Vg=
=BCSq
-----END PGP SIGNATURE-----
Re: Some questions about design
Posted by Julie MacNaught <jm...@apache.org>.
I like the finer grained modules. I think org.apache.wsrp4j.producer and org.apache.wsrp4j.consumer should be in different modules.
What do you also think of then changing the axis producer to producer-axis, so the modules look like this:
wsrp4j/ -->
commons/
Common code.
commons-consumer/
Common code to any consumer implementation.
Depends on commons.
commons-producer/
Common code to any producer implementation.
Depends on commons.
consumer-proxyportlet/
JSR-168 portlet consumer implementation.
Depends on commons and commons-consumer.
consumer-swingconsumer/
Java Swing application consumer implementation.
Depends on commons and commons-consumer.
producer-axis/
Axis-based producer implementation.
Depends on commons and commons-producer.
Then additional producer implementations would get new modules. The current implementation is heavily dependent on axis, so this would help to isolate this dependency. Looking ahead to version 2.0 of WSRP, we will be implementing new port types, so the producer-axis module will be have to be re-written. Hopefully we will be able to leverage the code in producer-commons.
Diego Louzán wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Right now the new repository is split in 4 main modules: commons, consumer (for
> proxyportlet) and producer. I would probably rename consumer to
> consumer-proxyportlet to be able to add a new module consumer-swingconsumer.
> But this mail is for another purpose.
>
> In the current repository, we have org.apache.wsrp4j.producer and
> org.apache.wsrp4j.consumer packages in the main src directory. As this code is
> code that would be shared by any producer (consumer) implementation, initially
> I took the decision to include it in commons module, so in that module we have
> org.apache.wsrp4j.commons.consumer and org.apache.wsrp4j.commons.producer
> packages. Take a look at the source directory if I didn't explain this very
> well (sorry for broken English).
>
> My question is: should I move these packages to new modules (like
> commons-consumer and commons-producer), so we'll end having this repository
> structure:
> wsrp4j/ -->
> commons/
> Common code.
> commons-consumer/
> Common code to any consumer implementation.
> Depends on commons.
> commons-producer/
> Common code to any producer implementation.
> Depends on commons.
> consumer-proxyportlet/
> JSR-168 portlet consumer implementation.
> Depends on commons and commons-consumer.
> consumer-swingconsumer/
> Java Swing application consumer implementation.
> Depends on commons and commons-consumer.
> producer/
> Axis-based producer implementation.
> Depends on commons and commons-producer.
>
> or should I continue with the current structure? Suggestions welcome.
>
> Regards.
> Diego.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDDzz5gyzZYflJelERAnvoAKCSy/92RC8tAvtg9/17XidvMkpFvQCgmFJ+
> ykiVC3PrsQ1sw6Ofr1EDVgs=
> =u6Ed
> -----END PGP SIGNATURE-----
>
>
--
Julie MacNaught
IBM Research
jmacna@apache.org
jmacna@us.ibm.com
DADB E3B5 8CB7 6B9B F4A0 8BF7 E830 1848 16A8 D3AB