[
https://issues.apache.org/jira/browse/WICKET-6855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242714#comment-17242714
]
Emond Papegaaij commented on WICKET-6855:
-----------------------------------------
The example projects you mentioned use the api-package for a totally different
reason: they provide various different implementations of the same API. There
is no second implementation of the Wicket-API and there will never be one.
The problems you indicate with transitive dependencies will not be solved by
introducing another package. To use Wicket, you will still need Wicket and its
transitive dependencies on the classpath at runtime. Hiding these dependencies
at compile-time, will solve nothing.
I'm with Martin on this one, I see no benefit for Wicket to provide an API
package, unless you are planning to develop a totally new implementation of
Wicket.
> Request: Provide separate wicket-api.jar for interfaces
> -------------------------------------------------------
>
> Key: WICKET-6855
> URL: https://issues.apache.org/jira/browse/WICKET-6855
> Project: Wicket
> Issue Type: Improvement
> Reporter: Matt Pavlovich
> Priority: Minor
>
> Providing a separate wicket-api.jar would provide benefit for web application
> developers and web frameworks that are built on top of wicket by providing a
> clean separation of concerns.
> # All public interfaces into a org.apache.wicket.api.* package (IPage,
> IPanel, etc)
> # All internal interfaces into a org.apache.wicket.spi.* package (page
> stores, serializers, etc)
> This allows for a single-jar dependency for Wicket's framework and extension
> layers. The current packaging co-locates interfaces and implementations into
> the same packages, which also prevents the ability to repackage a
> distribution of Wicket that had interfaces broken out.
> Similar patterns followed in other open source projects:
> apache log4j2-api
> apache camel-api
> etc..
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
