On 12/14/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
More precisely, no new *public* classes. You can have private helper classes that are not exposed in the public API, without violating the API signature tests.
Bundling is not really the most important issue. Consider the impact of an external dependency on both developers building, say, a JSF component, and on app servers that might want to embed MyFaces as their JSF implementation.
If' I'm using MyFaces as a standalone dependency, I would expect to be able to include just jsf-api.jar in my classpath. That will only work if the API jar has no external dependencies, *or* if all its dependencies are also included, inside the JAR itself. The latter scenario can be problematic, because it requires servers that embed MyFaces to expose the public APIs of those dependencies to all applications ... and that may not be desireable.
Craig
Hi,
I've had a go at building a logging lib as required. However I've
realized something to do with dependencies that I think is rather important.
It's a known rule that no new classes can be added to the " javax.faces"
namespace.
More precisely, no new *public* classes. You can have private helper classes that are not exposed in the public API, without violating the API signature tests.
Are non-javax.faces classes allowed to be bundled in the myfaces-api.jar
file? I presume not.
Bundling is not really the most important issue. Consider the impact of an external dependency on both developers building, say, a JSF component, and on app servers that might want to embed MyFaces as their JSF implementation.
If' I'm using MyFaces as a standalone dependency, I would expect to be able to include just jsf-api.jar in my classpath. That will only work if the API jar has no external dependencies, *or* if all its dependencies are also included, inside the JAR itself. The latter scenario can be problematic, because it requires servers that embed MyFaces to expose the public APIs of those dependencies to all applications ... and that may not be desireable.
Craig
