[chain] dependencies

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[chain] dependencies

Wendy Smoak
I'm trying to sort out the dependencies for Chain-- right now the pom
in the repository (for Maven 2) is bringing the Servlet and Portlet
APIs plus a beta version of MyFaces into any project that depends on
it.

From the project home page, it looks like all three of these are optional.

Can someone please confirm (for a non-portlet developer) that Portlet
works the same way as Servlet, that is, the container provides the API
at runtime?

In addition, the docs say, "To maximize the usefulness of the Chain of
Responsibility pattern APIs, the fundamental interface contracts are
defined in a manner with zero dependencies other than an appropriate
JDK."

Does that mean that the BeanUtils, Digester and Logging dependencies
are also optional?

Thanks,
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain] dependencies

craigmcc
On 11/15/05, Wendy Smoak <[hidden email]> wrote:
>
> I'm trying to sort out the dependencies for Chain-- right now the pom
> in the repository (for Maven 2) is bringing the Servlet and Portlet
> APIs plus a beta version of MyFaces into any project that depends on
> it.
>
> From the project home page, it looks like all three of these are optional.


At runtime, that's true unless you use the corresponding Context
implementation class. It's also true at compile time if you use the Ant
script (which has conditional compilation targets -- don't know whether you
can do that in Maven or not).

Can someone please confirm (for a non-portlet developer) that Portlet
> works the same way as Servlet, that is, the container provides the API
> at runtime?


It *can* work that way. However, the portlet API is not a required part of
the J2EE (now Java EE) platform, so you cannot be guaranteed that it will be
in your average servlet container. For example, the portlet API jar is not
shipped with Tomcat by default.

In addition, the docs say, "To maximize the usefulness of the Chain of
> Responsibility pattern APIs, the fundamental interface contracts are
> defined in a manner with zero dependencies other than an appropriate
> JDK."
>
> Does that mean that the BeanUtils, Digester and Logging dependencies
> are also optional?


If you take the intended meaning of "fundamental APIs" to mean the interface
definitions in org.apache.commons.chain (which was the intent of that
statement, since I wrote it :-) then yes, they are optional. However,
logging is required by most of the impl subpackage implementations.
Digester/BeanUtils are only required if you use the provided utility classes
to parse XML based configuration files. Nothing in Commons Chain actually
requires this ... you are perfectly free to create Catalog, Chain, and
Command instances manually and integrate them appropriately.

Thanks,
> Wendy


Craig

---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [chain] dependencies

Carlos Sanchez-4
What maven2 tries to address with "optional" means that there's a very
high chance for that jar not to be needed. Let's say you can use chain
in a standalone (not servlet) environment,  then servlet dependency is
optional.

This is a way to solve problems that usually would be easier solved
having a chain-core, chain-jsf, chain-portlet, chain-servlet. (I'm
just guesing up)

I don't believe BeanUtils, Digester and Logging are optional at all.
Of course if you use a class from the jar you won't need a lot of
dependencies, but that's not the point of the optional tag in maven2.

Regards

On 11/15/05, Craig McClanahan <[hidden email]> wrote:

> On 11/15/05, Wendy Smoak <[hidden email]> wrote:
> >
> > I'm trying to sort out the dependencies for Chain-- right now the pom
> > in the repository (for Maven 2) is bringing the Servlet and Portlet
> > APIs plus a beta version of MyFaces into any project that depends on
> > it.
> >
> > From the project home page, it looks like all three of these are optional.
>
>
> At runtime, that's true unless you use the corresponding Context
> implementation class. It's also true at compile time if you use the Ant
> script (which has conditional compilation targets -- don't know whether you
> can do that in Maven or not).
>
> Can someone please confirm (for a non-portlet developer) that Portlet
> > works the same way as Servlet, that is, the container provides the API
> > at runtime?
>
>
> It *can* work that way. However, the portlet API is not a required part of
> the J2EE (now Java EE) platform, so you cannot be guaranteed that it will be
> in your average servlet container. For example, the portlet API jar is not
> shipped with Tomcat by default.
>
> In addition, the docs say, "To maximize the usefulness of the Chain of
> > Responsibility pattern APIs, the fundamental interface contracts are
> > defined in a manner with zero dependencies other than an appropriate
> > JDK."
> >
> > Does that mean that the BeanUtils, Digester and Logging dependencies
> > are also optional?
>
>
> If you take the intended meaning of "fundamental APIs" to mean the interface
> definitions in org.apache.commons.chain (which was the intent of that
> statement, since I wrote it :-) then yes, they are optional. However,
> logging is required by most of the impl subpackage implementations.
> Digester/BeanUtils are only required if you use the provided utility classes
> to parse XML based configuration files. Nothing in Commons Chain actually
> requires this ... you are perfectly free to create Catalog, Chain, and
> Command instances manually and integrate them appropriately.
>
> Thanks,
> > Wendy
>
>
> Craig
>
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]