[
https://issues.apache.org/jira/browse/TAP5-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14054271#comment-14054271
]
Lance edited comment on TAP5-2192 at 7/8/14 12:09 AM:
------------------------------------------------------
How's this for a compromise... my main problem is requiring the configuration
inside tapestry. I don't necessarily mind that it's modelled inside tapestry.
1. Remove getComponentLibraryInfo() from LibraryMapping
2. Add ComponentLibraryInfoSource
{code}
public interface ComponentLibraryInfoSource {
ComponentLibraryInfo getComponentLibraryInfo(String libraryName);
}
{code}
3. Change ComponentLibraryInfo to use Resource instead of String URL's. eg
{code}
public interface ComponentLibraryInfo {
Resource getHomePageRoot();
Resource getSourceRoot();
Resource getJavadocRoot();
// etc
}
{code}
This way, ComponentLibraryInfoSource could be contributed to and overridden.
Perhaps driven by an XML file generated at build time etc. Or better yet,
library authors could add the maven version / artifact to the jar manifest and
the service could look it up.
Using Resource also allows javadoc and sources to be sourced from classpath or
a URL etc.
This feels much more like 'the tapestry way' of doing things.
was (Author: uklance):
How's this for a compromise... my main problem is requiring the configuration
inside tapestry. I don't necessarily mind that it's modelled inside tapestry.
1. Remove getComponentLibraryInfo() from LibraryMapping
2. Add ComponentLibraryInfoSource
{code}
public interface ComponentLibraryInfoSource {
ComponentLibraryInfo getComponentLibraryInfo(String libraryName);
}
{code}
3. Change ComponentLibraryInfo to use Resource instead of String URL's. eg
{code}
public interface ComponentLibraryInfo {
Resource getHomePageRoot();
Resource getSourceRoot();
Resource getJavadocRoot();
// etc
}
{code}
This way, ComponentLibraryInfoSource could be contributed to and overridden.
Perhaps driven by an XML file generated at build time etc. Using Resource also
allows javadoc to be sourced from classpath or a URL etc.
This feels much more like 'the tapestry way' of doing things.
> Add support for distributed documentation
> -----------------------------------------
>
> Key: TAP5-2192
> URL: https://issues.apache.org/jira/browse/TAP5-2192
> Project: Tapestry 5
> Issue Type: Improvement
> Affects Versions: 5.4
> Reporter: Barry Books
> Assignee: Thiago H. de Paula Figueiredo
> Labels: documentation, month-of-tapestry
>
> Please add support for a distributed documentation system. The basic
> requirements are:
> 1. Access to a list of Pages/Compoents/Mixins. (ComponentClassResolver
> supports pages)
> 2. Access to a Map of all Configurations. The map would have the
> configuration class as the Key and contain an object such a list or map that
> contains the configuration.
> 3. Access to a list of configured services.
> From this it should be possible to build documentation of a running system.
> Thanks
> Barry
--
This message was sent by Atlassian JIRA
(v6.2#6252)
