svn commit: r891019 - in /websites/production/tapestry/content: ./ 2009/09/13/ 2009/10/27/ 2009/11/25/ 2010/07/18/ 2010/07/24/ 2010/10/11/ 2010/10/31/ 2010/11/18/ 2010/11/19/ 2010/12/16/ 2010/12/17/ 2
Author: buildbot Date: Thu Dec 19 03:25:56 2013 New Revision: 891019 Log: Production update by buildbot for tapestry [This commit notification would consist of 62 parts, which exceeds the limit of 50 ones, so it was shortened to the summary.]
[CONF] Apache Tapestry > Building Tapestry from Source
Bob Harner edited the page: Building Tapestry from Source Comment: Just testing the publishing process This is a guide to building Tapestry itself from source code. This is primarily of interest to Tapestry contributors, rather than Tapestry users. ... Clone Tapestry from the Git repo: Command-line git users: Non Committers: git clone http://git-wip-us.apache.org/repos/asf/tapestry-5.git Committers: git clone https://git-wip-us.apache.org/repos/asf/tapestry-5.git Eclipse EGit users: Switch to Git perspective; then copy one of the URLs above into paste buffer Right-click > Paste repository path or URI. This will bring up the Clone Git Repository dialog. Committers: make sure Protocol is https, and enter your Apache commiter LDAP user name & password click Next. Select the branches you're interested in (e.g 5.3 and master), click Next Select Directory to where you want the project source code (e.g. ~/git/tapestry-5 or %HOME%\git\tapestry-5) Select whichever "Initial Branch" you're interested in (e.g. master) Set "Remote name" to "origin" (the default) VERY IMPORTANT: uncheck the "Import all existing projects" checkbox (we'll do this using Gradle, below) Click Finish. (Be patient; the clone operation might take a few minutes.) ... Command-line users: ./gradlew build -x test You can skip tests on a specific module by adding a colon and the module name. For example: -x test:tapestry-ioc
[jira] [Updated] (TAP5-2029) Copy annotations from service implementation to proxy (was JPA annotations expose implementation details in service interfaces)
[
https://issues.apache.org/jira/browse/TAP5-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo updated TAP5-2029:
Labels: month-of-tapestry (was: )
> Copy annotations from service implementation to proxy (was JPA annotations
> expose implementation details in service interfaces)
> ---
>
> Key: TAP5-2029
> URL: https://issues.apache.org/jira/browse/TAP5-2029
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
>Affects Versions: 5.3.6
>Reporter: John Coleman
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: month-of-tapestry
>
> The commit after and persistence context annotations are required on the
> service interface definition thereby exposing internal implementation details
> (see below example from docs). Details of implementation should be hidden at
> the interface level, both these annotations break the rule.
> Perhaps this code could appear in the Impl classes, or be provided in
> configuration somehow?
> public interface UserDAO {
>@CommitAfter
>@PersistenceContext(unitName = "DemoUnit")
>void add(User user);
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (TAP5-2266) @code JavaDoc is stripped entirely from component reference output
Howard M. Lewis Ship created TAP5-2266:
--
Summary: @code JavaDoc is stripped entirely from component
reference output
Key: TAP5-2266
URL: https://issues.apache.org/jira/browse/TAP5-2266
Project: Tapestry 5
Issue Type: Bug
Components: documentation, tapestry-component-report
Affects Versions: 5.4
Reporter: Howard M. Lewis Ship
Noticed this in the description of the navbar parameter here:
http://people.apache.org/~hlship/t5api/apidocs//org/apache/tapestry5/corelib/components/DevTool.html
Some content that was inside {@code} was removed entirely, making the result a
bit gibberish.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo updated TAP5-1611:
Component/s: (was: tapestry-ioc)
tapestry-core
Labels: component (was: IOC component)
> out-of-the-box way in Tapestry for replacing components
> ---
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-core
>Affects Versions: 5.3
>Reporter: Jens Breitenstein
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Labels: component
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
