Re: [VOTE] Tapestry 5.8.6
Dmitry Gusev: +1 (binding) On Wednesday, April 10, 2024, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Hello, Tapestry community! > > I've created and uploaded a release of Tapestry 5.8.6, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > https://repository.apache.org/content/repositories/staging/ > org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.8.6, is > ready. > > I've also created a 5.8.6 tag in Git: > > https://github.com/apache/tapestry-5/tree/5.8.6 > > Vote will run for 72 hours from now and requires majority approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). > > Cheers! > > -- > Thiago H. de Paula Figueiredo > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.8.4
Dmitry Gusev: +1 (binding) On Thursday, February 1, 2024, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Hello, Tapestry community! > > I've created and uploaded a release of Tapestry 5.8.4, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > https://repository.apache.org/content/repositories/staging/ > org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.8.4, is > ready. > > I've also created a 5.8.4 tag in Git: > > https://github.com/apache/tapestry-5/tree/5.8.4 > > Vote will run for 72 hours from now and requires majority approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). > > -- > Thiago H. de Paula Figueiredo > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.8.3 release
Dmitry Gusev: +1 (binding) On Thu, Jul 13, 2023 at 6:29 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Hello, Tapestry community! > > I've created and uploaded a release of Tapestry 5.8.3, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.8.3, is > ready. > > I've also created a 5.8.3 tag in Git: > > https://github.com/apache/tapestry-5/tree/5.8.3 > > Vote will run for at least 72 hours from now and requires majority > approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). > > Cheers! > > -- > Thiago > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: [VOTE] Tapestry 5.8.2 release
Dmitry Gusev: +1 (binding) On Wed, Jun 15, 2022 at 10:38 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Hello, Tapestry community! > > I've created and uploaded a release of Tapestry 5.8.2, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.8.2, is > ready. > > I've also created a 5.8.2 tag in Git: > > > https://gitbox.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.8.2 > > Vote will run for at least three days and requires majority approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). > > -- > Thiago > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.8.1 release
Dmitry Gusev: +1 (binding) On Wed, Mar 30, 2022 at 10:52 AM Bob Harner wrote: > Bob Harner: +1 (binding) > > On Tue, Mar 29, 2022, 6:05 PM Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > Hello, Tapestry community! > > > > I've created and uploaded a release of Tapestry 5.8.1, ready to be voted > > upon. > > > > The source, binary, and documentation archives have been uploaded to: > > https://dist.apache.org/repos/dist/dev/tapestry > > > > and the Maven artifacts staged to: > > > > > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > > > > Please examine these files to determine if the new release, 5.8.1, is > > ready. > > > > I've also created a 5.8.1 tag in Git: > > > > > > > https://gitbox.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.8.1 > > > > Vote will run for at least three days and requires majority approval from > > the PMC: At least 3 binding +1 votes and more positive than > > negative binding votes. > > > > On a successful vote, I'll release the Maven artifacts, the archives, > > and make the necessary updates to JIRA and the Tapestry site. > > > > Only votes cast by Tapestry PMC members are binding, but input > > from the community is highly valued. Please indicate whether your > > vote is binding or not after your full name (as it will appear in > > the end-of-vote summary). > > > > -- > > Thiago > > > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.8.0 release
Dmitry Gusev: +1 (binding) On Wed, Jan 19, 2022 at 12:00 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > I've created and uploaded a release of Tapestry 5.8.0, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.7.3, is > ready. > > I've also created a 5.8.0 tag in Git: > > > https://gitbox.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.8.0 > > Vote will run for at least three days and requires majority approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Remove Me
Hi Deborah, This isn't something we can do, as per https://tapestry.apache.org/mailing-lists.html you will need to send an email to dev-unsubscr...@tapestry.apache.org from each of your email addresses to unsubscribe. Regards, Dmitry On Tue, Jan 11, 2022 at 11:57 AM Deborah Lockhart < deborah.thelanguages...@gmail.com> wrote: > Please remove the following emails from your distribution: > > deborah.thelanguages...@gmail.com > deborah.lockh...@thelanguageshop.org > > Thank you! > Sent from my iPhone > > > On Jan 10, 2022, at 11:21 PM, build...@apache.org wrote: > > > > The Buildbot has detected a restored build on builder > tapestry-site-production while building . Full details are available at: > >https://ci.apache.org/builders/tapestry-site-production/builds/57199 > > > > Buildbot URL: https://ci.apache.org/ > > > > Buildslave for this Build: bb-cms-slave > > > > Build Reason: The Nightly scheduler named 'tapestry-site-production' > triggered this build > > Build Source Stamp: [branch tapestry/tapestry-site] HEAD > > Blamelist: > > > > Build succeeded! > > > > Sincerely, > > -The Buildbot > > > > > > > > --------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: New Tapestry PMC member: Ben Weidig
Congratulations, Ben! On Fri, Dec 3, 2021 at 6:13 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Hello, community! > > Please join me for welcoming Ben Weidig to the Tapestry PMC! > > Cheers! > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Request for feedback: Tapestry REST support
and tell
> me
> > what you feel about it. All feedback is welcome!
> >
> > Major points:
> >
> >- New page-level events are triggered after the "activate" event is
> >triggered (i.e. onActivate()) so you can write REST endpoints as
> regular,
> >live-class-reloaded event handler methods.
> > - One for each supported HTTP method: GET, POST, DELETE, PUT, HEAD,
> > PATCH.
> > - Event name is onHttp[method name]. For example, onHttpPut.
> > - New constants in EventConstants for each supported HTTP method.
> > - Activation context for REST event handler methods exactly in the
> > same way as in onActivate().
> > - Just like onActivate(), these new events are not triggered in
> > components.
> >- New service in tapestry-http (which is included by tapestry-core),
> >RestSupport, with utility methods and Optional
> >getRequestBodyAs(Class type), which returns the request body
> converted
> >to a given type.
> > - getRequestAsBody(Class) uses HttpRequestBodyConverter.
> >- Another new service in tapestry-http, HttpRequestBodyConverter,
> >which uses an ordered configuration of itself, which provides
> conversions
> >of request body to given types.
> > - Only one method, T convert(HttpServletRequest request,
> > Class type);
> > - tapestry-http contributes one implementation, which is added as
> > the last one in the ordered configuration, which uses TypeCoercer.
> > - Out of the box, it supports conversions to String, primitive
> > types, JSONArray, JSONObject plus any other type that has a String
> -> type
> > conversion available in TypeCoercer, directly or not.
> >- New annotation for page event handler method (onActivate(), onHttp*)
> >parameters: @RequestBody, which receives the request body and
> converts it
> >to the parameter type using RestSupport.getRequestAsBody().
> >- Think of it as @RequestParameter but for the request body instead of
> > a query parameter.
> > - Example below.
> >- New annotation for page event handler method (onActivate(), onHttp*)
> >parameters: @StaticActivationContextValue("something"), for defining
> that
> >method will only be called if that page activation context value
> matches a
> >given string.
> > - Example below.
> > - Parameters with that annotation still get their values set as
> > usual.
> > - This was built mostly for REST support, but it can useful for
> > non-REST situations too when a give activation context has a
> number of
> > possible values and there's some logic tied to it.
> >- Automatic generation of Swagger/OpenAPI 3.0 REST API definition
> >files.
> > - OpenApiDescriptionGenerator service, which is an ordered
> > configuration of itself.
> > - An internal implementation generates a base JSON object
> > definition that can be customized by contributing more
> OpenApiDescription
> > implementations.
> > - Titles, names, summaries, etc can be provided by configuration
> > symbols or message files (app.properties).
> > - Messages files are live class reloaded too, so all changes
> > done to the REST endpoint event handler methods and the
> corresponding
> > messages are live reloaded.
> > - Formats for message keys and described below.
> > - Parameter descriptions not implemented yet.
> > - It will support query parameters and path parameters.
> > - [Not implemented yet] Embedded Swagger/OpenAPI viewer (i.e. the
> >right pane of https://editor.swagger.io) hooked directly to the
> >definition file generated by OpenApiDescriptionGenerator
> > - It's going to be a separate subproject/JAR to avoid bloating
> > projects not using the viewer
> >
> >
> > @StaticActivationContextValue example:
> >
> > final private String COMPLETED = "completed";
> > final private String CLOSED = "closed";
> > // Only called if first page activation context value is "completed"
> >
> > @OnEvent(EventConstants.ACTIVATE)
> > void completed(@StaticActivationContextValue(COMPLETED) String state,
> > int id) {
> > ...
> > }
> >
> > // Only called if first page activation context value is "closed"
> > @OnEvent(EventConstants.ACTIVATE)
> > void closed(@StaticActivationContextValue(CLOSED) String state, int
> > id) {
> > ...
> > }
> >
> > REST endpoint event handler method example:
> >
> > Object onHttpPatch(
> > @StaticActivationContextValue("subpath") String subpath,
> > String parameter,
> > @RequestBody String body)
> > {
> > ...
> > }
> >
> > @OnEvent(value = EventConstants.HTTP_DELETE)
> > Object delete(@StaticActivationContextValue("subpath") String
> subpath,
> > String parameter)
> > {
> > return createResponse(EventConstants.HTTP_DELETE, null,
> parameter);
> > }
> >
> > Happy coding!
> >
> > --
> > Thiago
> >
>
>
> --
> Thiago
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: [VOTE] Tapestry 5.7.3 release
Dmitry Gusev: +1 (binding) On Tue, Aug 10, 2021 at 1:46 AM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > I've created and uploaded a release of Tapestry 5.7.3, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.7.3, is > ready. > > I've also created a 5.7.3 tag in Git: > > > https://gitbox.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.7.3 > > Vote will run for at least three days and requires majority approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.7.2 release
Dmitry Gusev: +1 (binding) On Thursday, April 8, 2021, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > I've created and uploaded a release of Tapestry 5.7.2, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > > > https://repository.apache.org/content/repositories/staging/ > org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.7.1, is > ready. > > I've also created a 5.7.1 tag in Git: > > https://gitbox.apache.org/repos/asf?p=tapestry-5.git;a= > log;h=refs/tags/5.7.2 > > Vote will run for at least three days and requires majority approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.6.4 release
Dmitry Gusev: +1 (binding) On Thursday, April 8, 2021, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > I've created and uploaded a release of Tapestry 5.6.4, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > > > https://repository.apache.org/content/repositories/staging/ > org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.6.4, is > ready. > > I've also created a 5.6.4 tag in Git: > > https://gitbox.apache.org/repos/asf?p=tapestry-5.git;a= > log;h=refs/tags/5.6.4 > > Vote will run for at least three days and requires majority approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.7.1 release
Dmitry Gusev: +1 (binding) On Wed, Mar 10, 2021 at 2:34 AM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > I've created and uploaded a release of Tapestry 5.7.1, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > > > > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.7.1, is > ready. > > I've also created a 5.7.1 tag in Git: > > > https://gitbox.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.7.1 > > Vote will run for at least three days and requires majority approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). > > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.6.3 release
Dmitry Gusev: +1 (binding) On Wed, Mar 10, 2021 at 2:40 AM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > I've created and uploaded a release of Tapestry 5.6.3, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > > > > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.6.3, is > ready. > > I've also created a 5.6.3 tag in Git: > > > https://gitbox.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.6.3 > > Vote will run for at least three days and requires majority approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.7.0 release
Dmitry Gusev: +1 (binding) On Mon, Feb 15, 2021 at 10:22 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Thiago H. de Paula Figueiredo: +1 (binding) > > On Sun, Feb 14, 2021 at 6:46 PM Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > I've created and uploaded a release of Tapestry 5.7.0, ready to be voted > > upon. > > > > The source, binary, and documentation archives have been uploaded to: > > > > https://dist.apache.org/repos/dist/dev/tapestry > > > > and the Maven artifacts staged to: > > > > > > > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > > > > Please examine these files to determine if the new release, 5.7.0, is > > ready. > > > > I've also created a 5.7.0 tag in Git: > > > > > > > https://gitbox.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.7.0 > > > > Vote will run for at least three days and requires majority approval from > > the PMC: At least 3 binding +1 votes and more positive than > > negative binding votes. > > > > On a successful vote, I'll release the Maven artifacts, the archives, > > and make the necessary updates to JIRA and the Tapestry site. > > > > Only votes cast by Tapestry PMC members are binding, but input > > from the community is highly valued. Please indicate whether your > > vote is binding or not after your full name (as it will appear in > > the end-of-vote summary). > > > > -- > > Thiago > > > > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Let's test Tapestry 5.7.0-SNAPSHOT
Hi Thiago,
This release has a significant change in packages, none of the existing
3rd-party tapestry libraries will be compatible with this release -- they
all will need recompilation and mentioned fixes, even if they don't use
Java 9 modules.
So it is a major change according to semver.
Have you considered bumping the major version to 6.x?
Also if we're doing this change, maybe flatten existing interfaces left
from previous releases, like Asset2, ServiceDef2, ServiceDef3, etc.?
Regards,
Dmitry
On Wed, Dec 9, 2020 at 1:38 AM Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> Hello, community!
>
> We're close to releasing Tapestry 5.7.0, which I'd love to have it released
> before the end of year holidays to end this troubled year with something
> nice. Since there's going to be larger changes than usual, I'd like to
> invite the community to test it on their projects a bit to eventually catch
> some regressions the team and the unit tests couldn't catch yet. You can
> see a list of all changes in
>
> https://issues.apache.org/jira/issues/?jql=project%20=%20TAP5%20AND%20fixVersion%20=%205.7.0
> until a proper release notes page is added to the website.
>
> Tapestry 5.7.0-SNAPSHOT JARs were uploaded to the ASF's Maven snapshots
> repository at https://repository.apache.org/content/groups/snapshots/.
>
> Biggest change is making Tapestry easier to use in modularized (i.e. Java
> 9+ modules) projects. The work on this was done in 2 major parts and a
> small one:
> * Avoiding split packages. In other words, packages that are present in
> more than one JAR. We had to move lots of Tapestry classes around
> JARs/subprojects since there were many and populous split packages.
> * Providing automatic module names, all using the formula
> "org.apache.tapestry.[adapted JAR name]", where [adapted JAR name] is the
> current JAR name with 'tapestry-', dashes and the character '5' removed.
> For example, tapestry5-annotations automatic module name is
> org.apache.tapestry.annotations. Creation of module-info.java files are
> left for the future.
> * A simple migration tool to update fully qualified class names in Java
> source files for classes which were moved and/or renamed. It's basically a
> search-and-replace using a table of (old class name -> new class name)
> extracted out of Git commits.
>
> To run this migration tool, download the JAR at
>
> https://repository.apache.org/content/groups/snapshots/org/apache/tapestry/tapestry-version-migrator/5.7.0-SNAPSHOT/tapestry-version-migrator-5.7.0-20201208.195518-8.jar
> and run "java
> -jar tapestry-version-migrator-5.7.0-20201208.195518-8.jar upgrade 5.7.0"
> (without quotes). It will process all .java files found in the current
> folder and its subfolders, recursively.
>
> Since the stuff above was going to be needed anyway, I've also seized the
> opportunity to separate the Tapestry request pipeline classes (i.d.
> HttpServletRequestFilter, RequestFilter, Dispatcher, etc) into a new
> subproject/JAR, tapestry-http, which can be used without tapestry-core,
> which includes the page/component framework and the asset handling classes.
>
> The other breaking change in 5.7.0 is changing the TypeCoercer service from
> having an unordered configuration to a mapped one. This was done so it's
> very clear when a coercion is overriden. Here's a real example from
> Tapestry itself: if you had a contribution method like this:
>
> @Contribute(TypeCoercer.class)
> public static void provideCoercions(Configuration
> configuration)
> {
> configuration.add(CoercionTuple.create(String.class,
> JSONObject.class, new StringToJSONObject()));
> }
>
> it should be changed to this:
>
> public static void
> provideCoercions(MappedConfiguration
> configuration)
> {
> CoercionTuple stringToJsonObject =
> CoercionTuple.create(String.class, JSONObject.class, new
> StringToJSONObject());
> configuration.add(stringToJsonObject.getKey(), stringToJsonObject);
> }
>
> 5.7.0 is built with Java 11 (first long-term support version after Java 9),
> but targeting Java 8 bytecode, so It should be able to run on Java 8 to 14.
>
> Please post your findings here in the mailing list so we can coordinate the
> creation of Jira tickets and get this new version ready to be voted and
> released in the next 2 weeks.
>
> Thanks in advance! Happy testing!
>
> --
> Thiago
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Java Time API / JSR310 Type Coercers
Hi, There may be compatibility issues as the new coercions use the type `Long` as intermediate value. I.e. Long -> LocalDate -- it currently treats long as nanos, but what if Long is in milliseconds? Same with Duration (millis) and Instant (millis). If we apply these coercions unconditionally we may break existing applications who have coercions defined in their own modules. For Strings it's probably fine as every type uses its own format, so I'd suggest we remove Lond from the list of contributions. And maybe add the new conversions conditionally: it's fine to have them enabled by default, but we should at least provide a symbol to disable them? On Wed, Oct 21, 2020 at 3:00 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Fri, Oct 16, 2020 at 5:01 AM Ben Weidig wrote: > > > Hi, > > > > Hello! > > > > it would be great to see the Java Time API better integrated into > Tapestry, > > so I've started adding type coercers. > > > > As with my JSON improvements, I've prepared a short proposal to highlight > > the intentions and ramifications better. It's included in the ticket, > which > > also already has a patch: > > > > Proposal: > > https://gist.github.com/benweidig/e0e7c9a26f3805e610c4511a0a15b9e3 > > > > Ticket: https://issues.apache.org/jira/browse/TAP5-2645 > > > > Compare: > > > > > https://github.com/apache/tapestry-5/compare/master...benweidig:typecoercer-jsr310 > > > This is awesome! Thank you very much again for another great pull request! > If you agree, I shall merge it into master this week. > > > > > > > > I've excluded the more "unusual" types in java.time.chrono, like > > JapaneseDate etc. > > But if you think they should be included as well, I could create an > > additional patch. > > > > Feedback is always welcome. > > > > Cheers > > Ben > > > > -- > > > > Netzgut GmbH > > > > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapetry 5.6.1 release
Dmitry Gusev: +1 (binding) On Thu, Sep 10, 2020 at 5:20 AM Andreas Ernst wrote: > Andreas Ernst: +1 (non-binding) > > Am 09.09.20 um 21:47 schrieb Thiago H. de Paula Figueiredo: > > I've created and uploaded a release of Tapestry 5.6.1, ready to be voted > > upon. The only difference to 5.6.0 was changing some code that uses > > commons-lang, but tapestry-core doesn't actually has a compile dependency > > on it. > > > > The source, binary, and documentation archives have been uploaded to: > > > > https://dist.apache.org/repos/dist/dev/tapestry > > > > and the Maven artifacts staged to: > > > > > > > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > > > > Please examine these files to determine if the new release, 5.x, is > ready. > > > > I've also created a 5.6.0 tag in Git: > > > > > > > https://gitbox.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.6.1 > > > > Vote will run for at least three days and requires majority approval from > > the PMC: At least 3 binding +1 votes and more positive than > > negative binding votes. > > > > On a successful vote, I'll release the Maven artifacts, the archives, > > and make the necessary updates to JIRA and the Tapestry site. > > > > Only votes cast by Tapestry PMC members are binding, but input > > from the community is highly valued. Please indicate whether your > > vote is binding or not after your full name (as it will appear in > > the end-of-vote summary). > > > > -- > ae | Andreas Ernst | IT Spektrum > Postfach 5, 65612 Beselich > Schupbacher Str. 32, 65614 Beselich, Germany > Tel: +49-6484-91002 Fax: +49-6484-91003 > a...@ae-online.de | www.ae-online.de > www.tachyon-online.de > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Ready for 5.6.0? Any blockers?
Missed this, not from me also. On Wednesday, July 22, 2020, Bob Harner wrote: > None from me > > On Sun, Jul 19, 2020, 11:34 AM Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > Hello, everyone! > > > > I'd like to release Tapestry 5.6.0 as soon as possible. There's a > security > > improvement and support for Java 14 bytecode. Anything else you believe > is > > a blocker this release? > > > > Here are the tickets included in the 5.6.0 release: > > > > [image: Critical] [image: Bug] TAP5-2602 > > <https://issues.apache.org/jira/browse/TAP5-2602> 5.4 LinkSubmit does > not > > work with Prototype JS <https://issues.apache.org/jira/browse/TAP5-2602> > > Thiago > > Henrique De Paula Figueiredo > > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=thiagohp> > > CLOSED > > [image: Major] [image: Improvement] TAP5-2624 > > <https://issues.apache.org/jira/browse/TAP5-2624> Support Java 14 > bytecode > > by upgrading embedded ASM version to 8.0.1 > > <https://issues.apache.org/jira/browse/TAP5-2624> Thiago Henrique De > Paula > > Figueiredo > > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=thiagohp> > > RESOLVED > > [image: Major] [image: Improvement] TAP5-2631 > > <https://issues.apache.org/jira/browse/TAP5-2631> Make Tapestry forms > more > > accessible with automatic generation WAI-ARIA attributes > > <https://issues.apache.org/jira/browse/TAP5-2631> Thiago Henrique De > Paula > > Figueiredo > > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=thiagohp> > > CLOSED > > [image: Major] [image: Bug] TAP5-2632 > > <https://issues.apache.org/jira/browse/TAP5-2632> > > ContextAssetRequestHandler > > doesn't handle slashes in paths correctly > > <https://issues.apache.org/jira/browse/TAP5-2632> Thiago Henrique De > Paula > > Figueiredo > > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=thiagohp> > > RESOLVED > > [image: Minor] [image: Improvement] TAP5-2626 > > <https://issues.apache.org/jira/browse/TAP5-2626> Update Closure > Compiler > > to latest version available (v20200628) > > <https://issues.apache.org/jira/browse/TAP5-2626> Thiago Henrique De > Paula > > Figueiredo > > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=thiagohp> > > CLOSED > > > > -- > > Thiago > > > -- Dmitry Gusev AnjLab Team http://anjlab.com
Java 14 and TAP5-2613
Hi Thiago, Just a short notice. I see you're updating the build for latest Java, have you tried it with https://issues.apache.org/jira/browse/TAP5-2613? Kind Regards, Dmitry
Re: [VOTE] 5.5.0 release
Dmitry Gusev: +1 (binding) On Saturday, March 14, 2020, Kalle Korhonen wrote: > Kalle Korhonen: +1 (binding) > > On Thu, Mar 12, 2020 at 2:01 PM Bob Harner wrote: > > > Bob Harner: +1 (binding) > > > > On Thu, Mar 12, 2020, 5:31 AM Ben Weidig wrote: > > > > > Ben Weidig: +1 (non-binding) > > > > > > On Thu, Mar 12, 2020 at 2:08 AM Thiago H. de Paula Figueiredo < > > > thiag...@gmail.com> wrote: > > > > > > > I've created and uploaded a release of Tapestry 5.5.0, ready to be > > voted > > > > upon. > > > > > > > > The source, binary, and documentation archives have been uploaded to: > > > > > > > > https://dist.apache.org/repos/dist/dev/tapestry > > > > > > > > and the Maven artifacts staged to: > > > > > > > > > > > > > > > > > https://repository.apache.org/content/repositories/staging/ > org/apache/tapestry/ > > > > > > > > Please examine these files to determine if the new release, 5.4.3, is > > > > ready. > > > > > > > > I've also created a 5.5.0 tag in Git: > > > > > > > > > > > > > > > > > https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a= > log;h=refs/tags/5.5.0 > > > > > > > > Vote will run for at least three days and requires majority approval > > from > > > > the PMC: At least 3 binding +1 votes and more positive than > > > > negative binding votes. > > > > > > > > On a successful vote, I'll release the Maven artifacts, the archives, > > > > and make the necessary updates to JIRA and the Tapestry site. > > > > > > > > Only votes cast by Tapestry PMC members are binding, but input > > > > from the community is highly valued. Please indicate whether your > > > > vote is binding or not after your full name (as it will appear in > > > > the end-of-vote summary). > > > > > > > > > > > > -- > > > > Thiago > > > > > > > > > > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: 5.5.0 release. Let's do it?
Hi, There was one issue with assets compilation in master version in one of our apps, but I believe that's because of 3rd party dependencies and is not a general issue with the framework itself, so I'm all for it. On Fri, Jan 31, 2020 at 6:10 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Hello, everyone! > > Does someone have any blockers for finally releasing 5.5.0? I have none > and, if no one objects, I'd like to cut a release next week and have a vote > about it. > > Cheers! > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.5.0-beta-3
en artifacts staged to: > >>> > >>> > >>> > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > >>> > >>> Please examine these files to determine if the new release, > 5.5.0-beta-3, > >>> is ready. > >>> > >>> I've also created a v5.5.0-beta-3 tag in Git: > >>> > >>> > >>> > https://gitbox.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=cbedad6f1d457c883faaeaf3f9fcbbec3de99816 > >>> > >>> It includes the following tickets: > >>> > >>> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20TAP5%20AND%20fixVersion%20%3D%205.0.0 > >>> > >>> Vote will run for at least three days and requires majority approval > from > >>> the PMC: At least 3 binding +1 votes and more positive than > >>> negative binding votes. > >>> > >>> On a successful vote, I'll release the Maven artifacts, the archives, > >>> and make the necessary updates to JIRA and the Tapestry site. > >>> > >>> Only votes cast by Tapestry PMC members are binding, but input > >>> from the community is highly valued. Please indicate whether your > >>> vote is binding or not after your full name (as it will appear in > >>> the end-of-vote summary). > >>> > >>> -- > >>> Thiago > >> > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.5.0-beta-3
Dmitry Gusev: +1 (binding) On Tue, Sep 17, 2019 at 3:29 PM Bob Harner wrote: > Bob Harner: +1 (binding) > > On Tue, Sep 17, 2019, 6:19 AM Christopher Dodunski < > chrisfromtapes...@christopher.net.nz> wrote: > > > +1 Christopher Dodunski (non binding) > > > > > > > I've created and uploaded a release of Tapestry 5.5.0, ready to be > voted > > > upon. It's meant to be a preview of the next major Tapestry release, > > > 5.5.0. > > > The main new feature in 5.5.0-beta-3 is the ability of running Tapestry > > > without Bootstrap CSS (a minimal set of JavaScript Bootstrap modules is > > > included so alerts and validation message works), with Bootstrap 3 (the > > > default) or Bootstrap 4. More details in > > > https://issues.apache.org/jira/browse/TAP5-2612. > > > > > > The source, binary, and documentation archives have been uploaded to: > > > > > > https://dist.apache.org/repos/dist/dev/tapestry > > > > > > and the Maven artifacts staged to: > > > > > > > > > > > > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > > > > > > Please examine these files to determine if the new release, > 5.5.0-beta-3, > > > is ready. > > > > > > I've also created a v5.5.0-beta-3 tag in Git: > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=cbedad6f1d457c883faaeaf3f9fcbbec3de99816 > > > > > > It includes the following tickets: > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20TAP5%20AND%20fixVersion%20%3D%205.0.0 > > > > > > Vote will run for at least three days and requires majority approval > from > > > the PMC: At least 3 binding +1 votes and more positive than > > > negative binding votes. > > > > > > On a successful vote, I'll release the Maven artifacts, the archives, > > > and make the necessary updates to JIRA and the Tapestry site. > > > > > > Only votes cast by Tapestry PMC members are binding, but input > > > from the community is highly valued. Please indicate whether your > > > vote is binding or not after your full name (as it will appear in > > > the end-of-vote summary). > > > > > > -- > > > Thiago > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: dev-h...@tapestry.apache.org > > > > > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Upgrade Tapestry build to Java 11
Hi Thiago, I was thinking of merging it to 5.6. It has no functional changes and tapestry runtime jars can still run on java 8. The jars are just built with the java 11 compiler, but byte code level is still java 8 for runtime. I'm saying "for runtime", because one tapestry-javadoc would now require JDK11, so if anyone has custom javadocs for their tapestry components they will be forced to upgrade their java (or temporarily use old tapestry-javadoc dependency for compatibility). Not sure about switching to java 11 byte code for 5.6. I'd love to do this, because it would allow running tests on java 11 bytecode which we currently miss. I still plan to write a test for https://issues.apache.org/jira/browse/TAP5-2611 With java 8 as main target I have to create a new module just for java 11 compatibility in tests, on the other hand if we switch target compatibility to java 11 in 5.6 already I could create that test in existing module. All tapestry apps I'm working on are on java 11 already, but I realise not everyone is migrated and it would be nice to get some feedback from community about it. On Mon, Sep 16, 2019 at 5:27 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Mon, Aug 26, 2019 at 8:17 PM Dmitry Gusev > wrote: > > > Hi all, > > > > Hello! > > > > I managed to run a green build on my local machine on Java 11 as part of > > https://issues.apache.org/jira/browse/TAP5-2613, PR is here: > > https://github.com/apache/tapestry-5/pull/26 > > > Awesome! Thank you very much for that! I love that you fixed the taglet > support. > > > > I haven't tried Java 12 or above, not sure it's worth supporting any > > intermediate releases prior to Java 17 at this stage > > as that would be the next long term support (LTS) release as Java 11 > > currently is. All major fixes should be back ported to 11.x. > > > > Wouldn't the next LTS Java support be 2014? Looking at > https://www.oracle.com/technetwork/java/java-se-support-roadmap.html, it > seems that the Oracle's plan is to release one LTS version, then 2 non-LTS > ones, then another LTS. But, of course, I may be wrong, and often I am. :D > > Otherwise, I agree about only supporting LTS Java versions. > > Dmitry, I'm not sure whether you're suggesting merging this pull request > for 5.6 or 5.5. I still believe we should release 5.5 targeting Java 8 > bytecode, so we still support everyone who didn't upgrade to Java 11 yet, > and, as soon as possible, release 5.6 using Java 11 for both source and > target bytecode. > > The only thing I still want to do in 5.5 is the support for running > Tapestry without Bootstrap, something I'm planning to work in the next > days. The work in progress has been done on the 'bootstrapless' branch so > far. > > > > It would be nice to get a green build on Jenkins for it while we're > waiting > > for the stable 5.5.x. > > I'll try to look at it next week, but won't mind if anyone can do it :) > > > > The last build failure was due to failing to download one DTD file, > http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent, which is a little bit > weird. I'll try to rewrite that code a bit so it doesn't fail outright when > the download fails. > > > > Thiago, do you have a hint where I could read about Jenkins upgrade? > > Or maybe we could try Travis CI on GitHub. JIRA & GitHub have got a nice > > integration: JIRA ticket automatically referenced this PR. > > > > > > On Thu, Jun 27, 2019 at 9:47 PM Thiago H. de Paula Figueiredo < > > thiag...@gmail.com> wrote: > > > > > On Sat, Jun 22, 2019 at 6:56 PM Dmitry Gusev > > > wrote: > > > > > > > Hi everyone! > > > > > > > > > > Hello, everyone! > > > > > > > > > > I tried to upgrade the build to Java 11 before I found discussion in > > > > TAP5-2588, and I even upgraded most of it while experimenting and got > > all > > > > the tests green, except tapestry-javadoc module, which at first > glance > > > > requires code rewrite and not just library upgrades and minor fixes > as > > it > > > > was with core modules. > > > > > > > > > > Indeed, before we build Tapestry with Java 11, we'll need to rewrite at > > > least tapestry-javadoc, but I guess that's mostly it. If we want to > > provide > > > proper Java 9 modules too, we'll need to move some classes between > > > packages, since each package can only be in one module, and now we have > > > some packages with classes in more than one subproject/artifact/JAR. > Far > > > from trivial. &g
Re: [VOTE] Tapestry 5.5.0-beta-2
Better late than never, There should be no 72 hours limit, it's the opposite -- the vote should run for AT LEAST 72 hours: Votes should generally be permitted to run for at least 72 hours to provide > an opportunity for all concerned persons to participate regardless of their > geographic locations. > >From here: https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions Shall we create a new vote for 5.5.0-beta-3 from latest state of master? On Tue, Apr 9, 2019 at 10:24 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Vote failed due to lack of 3 binding +1 votes in the 72 hours after it was > started. :( > > On Tue, Mar 26, 2019 at 10:15 PM Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > Hello! > > > > I've created and uploaded a release of Tapestry 5.5.0-beta-2, ready to be > > voted upon. > > > > The source, binary, and documentation archives have been uploaded to: > > > > https://dist.apache.org/repos/dist/dev/tapestry > > > > and the Maven artifacts staged to: > > > > > > > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > > > > Please examine these files to determine if the new release, 5.5.0-beta-2, > > is ready. > > > > I've also created a 5.4.5-beta-2 tag in Git: > > > > > > > https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.5.0-beta-2 > > > > It includes the following tickets: > > > > Vote will run for three days and requires majority approval from > > the PMC: At least 3 binding +1 votes and more positive than > > negative binding votes. > > > > On a successful vote, I'll release the Maven artifacts, the archives, > > and make the necessary updates to JIRA and the Tapestry site. > > > > Only votes cast by Tapestry PMC members are binding, but input > > from the community is highly valued. Please indicate whether your > > vote is binding or not after your full name (as it will appear in > > the end-of-vote summary). > > > > -- > > Thiago > > > > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] 5.4.5 release
Dmitry Gusev: +1 (binding) On Tue, Sep 3, 2019 at 5:03 AM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > I've created and uploaded a release of Tapestry 5.4.3, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > > > https://repository.apache.org/content/repositories/staging/org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.4.3, is > ready. > > I've also created a 5.4.3 tag in Git: > > > https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=log;h=refs/tags/5.4.5 > > Vote will run for three days and requires majority approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [SUCCESS] Re: [VOTE] Dmitry Gusev for the PMC
Hello team, Thank you for your trust! Hope I can be helpful as a PMC member. On Fri, Aug 30, 2019 at 10:54 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > The vote was successful, with 4 binding votes (1 more than needed) and 7 > non-binding ones. > > Binding votes: > Thiago H. de Paula Figueiredo > Bob Harner > Jochen Kemnade > Kalle Korhonen > > Non-binding votes: > Numa Schmeder > Rafael Bugajewski > Andreas Ernst > Daniel Jue > Christopher Dodunski > Ben Weidig > Balazs Palcso > > On Mon, Aug 26, 2019 at 10:29 AM Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > Hello, Apache Tapestry team! > > > > Dmitry Gusev has been a steady presence on the Tapestry community for > many > > years, with many different contributions of different kinds (discussions, > > fixes, commits) He's already a committer and I believe he's very > deserving > > to be promoted to a PMC member. > > -- > > Thiago > > > > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Upgrade Tapestry build to Java 11
Hi all, I managed to run a green build on my local machine on Java 11 as part of https://issues.apache.org/jira/browse/TAP5-2613, PR is here: https://github.com/apache/tapestry-5/pull/26 I haven't tried Java 12 or above, not sure it's worth supporting any intermediate releases prior to Java 17 at this stage as that would be the next long term support (LTS) release as Java 11 currently is. All major fixes should be back ported to 11.x. It would be nice to get a green build on Jenkins for it while we're waiting for the stable 5.5.x. I'll try to look at it next week, but won't mind if anyone can do it :) Thiago, do you have a hint where I could read about Jenkins upgrade? Or maybe we could try Travis CI on GitHub. JIRA & GitHub have got a nice integration: JIRA ticket automatically referenced this PR. On Thu, Jun 27, 2019 at 9:47 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Sat, Jun 22, 2019 at 6:56 PM Dmitry Gusev > wrote: > > > Hi everyone! > > > > Hello, everyone! > > > > I tried to upgrade the build to Java 11 before I found discussion in > > TAP5-2588, and I even upgraded most of it while experimenting and got all > > the tests green, except tapestry-javadoc module, which at first glance > > requires code rewrite and not just library upgrades and minor fixes as it > > was with core modules. > > > > Indeed, before we build Tapestry with Java 11, we'll need to rewrite at > least tapestry-javadoc, but I guess that's mostly it. If we want to provide > proper Java 9 modules too, we'll need to move some classes between > packages, since each package can only be in one module, and now we have > some packages with classes in more than one subproject/artifact/JAR. Far > from trivial. > > > > So I would suggest to go straight to Java 11 after we release current > state > > of master (5.5.x). > > > > Agreed. > > What about Java 12? It was released last March. I haven't checked what are > the differences to 11, though. > > > > Starting from 5.6 all releases can remain binary compatible with java 8, > > but the build itself may leverage the java 11 compiler to start testing > > java 8+ compatibility, as required by TAP5-2611, for example. > > > > Agreed too. > > And thanks Dmitry for starting this important discussion! > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Upgrade Tapestry build to Java 11
Hi Ben! I didn't try to compile Tapestry itself to target compatibility = 11, as I mentioned above it should probably remain java 8 for some time. It isn't necessary for the time being, we may do so later when we implement proper jigsaw modules. For now I was talking mostly about using JDK 11 complier with source/targetCompatibility=8, to be able to create Java 11 compatibility tests. It shouldn't stop you from adding current state of the master branch in your Java 11 projects as regular 3rd party dependency, same as we did with ours. I can't recall any issues of using current state of the master branch with Java 11, Tapestry team and contributors already did most of the job. On Sun, Jun 23, 2019 at 4:10 PM Ben Weidig wrote: > Hi Dmitry, > > thanks for all the work towards Java 11! > > We're trying to get it up and running ourselves but without much luck... > > You committed the patch for the private instrumentations, but I don't see > any modifications on the build.gradle, I assume this is because your > suggestion of doing Java 11 support after the release of 5.5.x > > Could you give us some pointers how we could build Tapestry 5.5 with > target/source for Java 11? > > So far we've done the following trying to get the project to build with > OpenJDK 11 and gradle on the command line including all tests: > - gradle update to 4.10.3 > - spock update to 1.2-groovy-2.4 > - settings.gradle: remove unnecessary projects (e.g. javadoc, kaptcha, > mongo, clojure etc.) > - build.gradle: jdkMajorVersion convert to int and remove "--add-modules" > for Java 11" > - build.gradle: remove dependencies on tapestry-javadoc (117) > - build.gradle: remove jacoco > - build.gradle: sourceCompatibility/targetCompatibility 11 > - build.gradle: idea project languageLevel 11 > > It's building, but testing is wonky, mostly becausome unit tests are > failing. JUnit tries to run helper classes as Tests (e.g. > AccessMethodsSubject, ProtectedFieldCollaborator), which fails with > initializationError. > > Integration tests run in Quantum, but some are failing, but maybe Quantum > is the reason here, didn't dig into it. > > Did you ran into any other bigger issues with running your projects on Java > 11? > > We have a few 100k lines of code and use the IoC heavily for projects > customization and would love to test it on our end and create > issues/patches in Jira if we run into any problems. > > Cheers, > Ben > > On Sat, Jun 22, 2019 at 11:56 PM Dmitry Gusev > wrote: > > > Hi everyone! > > > > Earlier this year I worked on a project where we upgraded all Tapestry > apps > > of one of our client to Java 11 with source & target compatibility = 11. > We > > were using custom version of Tapestry with only one patch on top of > current > > state of the master which I just checked in to the main code base: > > > > https://issues.apache.org/jira/browse/TAP5-2611 > > > > However I couldn't find a way to write a test for it as it would require > > some test classes compiled with Java 11 target compatibility level. > > > > I've found the following issue discussing migration path to Java 11 for > the > > Tapestry build, but the issue is now closed and there were not conclusion > > on what should be done next: > > > > https://issues.apache.org/jira/browse/TAP5-2588 > > > > I tried to upgrade the build to Java 11 before I found discussion in > > TAP5-2588, and I even upgraded most of it while experimenting and got all > > the tests green, except tapestry-javadoc module, which at first glance > > requires code rewrite and not just library upgrades and minor fixes as it > > was with core modules. > > > > I found that current build has some customisations for Java 9, and in > > TAP5-2588 there were discussions about supporting Java 10 also, but I > don't > > think that's necessary at the moment when Java 11 -- current LTS release > -- > > is out, as those are intermediate releases and are already not supported. > > > > So I would suggest to go straight to Java 11 after we release current > state > > of master (5.5.x). > > > > Starting from 5.6 all releases can remain binary compatible with java 8, > > but the build itself may leverage the java 11 compiler to start testing > > java 8+ compatibility, as required by TAP5-2611, for example. > > > > What do you think? > > > > Best regards, > > Dmitry > > > > > -- > > Netzgut GmbH > -- Dmitry Gusev AnjLab Team http://anjlab.com
Upgrade Tapestry build to Java 11
Hi everyone! Earlier this year I worked on a project where we upgraded all Tapestry apps of one of our client to Java 11 with source & target compatibility = 11. We were using custom version of Tapestry with only one patch on top of current state of the master which I just checked in to the main code base: https://issues.apache.org/jira/browse/TAP5-2611 However I couldn't find a way to write a test for it as it would require some test classes compiled with Java 11 target compatibility level. I've found the following issue discussing migration path to Java 11 for the Tapestry build, but the issue is now closed and there were not conclusion on what should be done next: https://issues.apache.org/jira/browse/TAP5-2588 I tried to upgrade the build to Java 11 before I found discussion in TAP5-2588, and I even upgraded most of it while experimenting and got all the tests green, except tapestry-javadoc module, which at first glance requires code rewrite and not just library upgrades and minor fixes as it was with core modules. I found that current build has some customisations for Java 9, and in TAP5-2588 there were discussions about supporting Java 10 also, but I don't think that's necessary at the moment when Java 11 -- current LTS release -- is out, as those are intermediate releases and are already not supported. So I would suggest to go straight to Java 11 after we release current state of master (5.5.x). Starting from 5.6 all releases can remain binary compatible with java 8, but the build itself may leverage the java 11 compiler to start testing java 8+ compatibility, as required by TAP5-2611, for example. What do you think? Best regards, Dmitry
Re: Tapestry 5.5-beta-2 problem: @Parameter field access problem with anonymous classes
Hello,
It appears the problem is because Java 11 changed the contract for inner
classes to access state of outer classes:
https://www.baeldung.com/java-nest-based-access-control
Before Java 11 there were no direct field access instructions in inner
classes, instead java used synthetic bridge methods, like access$0001.
These accessor methods were created in outer classes and the methods were
actually exposing state of owning class as regular getters/setters.
Actual replacement of field access is done in the scope of top-level
classes by the PlasticClassImpl#interceptFieldAccess
<https://github.com/apache/tapestry-5/blob/d3928ad44714b949d247af2652c84dae3c27e1b1/plastic/src/main/java/org/apache/tapestry5/internal/plastic/PlasticClassImpl.java#L1233>
using
field instrumentations recorded by PlasticClassImpl#redirectFieldRead
<https://github.com/apache/tapestry-5/blob/d3928ad44714b949d247af2652c84dae3c27e1b1/plastic/src/main/java/org/apache/tapestry5/internal/plastic/PlasticClassImpl.java#L1616>
and PlasticClassImpl#redirectFieldWrite
<https://github.com/apache/tapestry-5/blob/d3928ad44714b949d247af2652c84dae3c27e1b1/plastic/src/main/java/org/apache/tapestry5/internal/plastic/PlasticClassImpl.java#L1604>
.
Inner classes are loaded differently (PlasticClassPool#loadInnerClass
<https://github.com/apache/tapestry-5/blob/d3928ad44714b949d247af2652c84dae3c27e1b1/plastic/src/main/java/org/apache/tapestry5/internal/plastic/PlasticClassPool.java#L388>),
they don't have access to the same field instrumentations and can only take
instrumentations from the PlasticClassPool, see
PlasticClassPool#interceptFieldAccess
<https://github.com/apache/tapestry-5/blob/d3928ad44714b949d247af2652c84dae3c27e1b1/plastic/src/main/java/org/apache/tapestry5/internal/plastic/PlasticClassPool.java#L405>
.
Although PlasticClassImpl can share field instrumentations with the pool,
it only shares instrumentations for the non-private fields of the non-proxy
classes
<https://github.com/apache/tapestry-5/blob/d3928ad44714b949d247af2652c84dae3c27e1b1/plastic/src/main/java/org/apache/tapestry5/internal/plastic/PlasticClassImpl.java#L1610>
.
Before java 11 this wasn't critical because of the bridge methods, but now
it is: nested classes, and classes declared in the same compilation unit
can still access private members of each other, hence they may need to have
access to the instrumentations.
A patch like below can fix the issue, but I'm not sure if there can be any
other side effects, i.e. why were the private field instrumentations not
shared with the pool before?
diff --git
a/plastic/src/main/java/org/apache/tapestry5/internal/plastic/PlasticClassImpl.java
b/plastic/src/main/java/org/apache/tapestry5/internal/plastic/PlasticClassImpl.java
index fffd910af..735952d32 100644
---
a/plastic/src/main/java/org/apache/tapestry5/internal/plastic/PlasticClassImpl.java
+++
b/plastic/src/main/java/org/apache/tapestry5/internal/plastic/PlasticClassImpl.java
@@ -1607,7 +1607,7 @@ public class PlasticClassImpl extends Lockable
implements PlasticClass, Internal
fieldInstrumentations.write.put(fieldName, fi);
-if (!(proxy || privateField))
+if (!(proxy/* || privateField*/))
{
pool.setFieldWriteInstrumentation(classNode.name, fieldName,
fi);
}
@@ -1619,7 +1619,7 @@ public class PlasticClassImpl extends Lockable
implements PlasticClass, Internal
fieldInstrumentations.read.put(fieldName, fi);
-if (!(proxy || privateField))
+if (!(proxy/* || privateField*/))
{
pool.setFieldReadInstrumentation(classNode.name, fieldName,
fi);
}
Best regards,
Dmitry
On Fri, Apr 12, 2019 at 11:41 AM Dmitry Gusev
wrote:
> I ran some more tests and found the problem only exists in Java 11 target
> compatibility, it works fine with Java 9 and 10.
>
> Could be a bug in ASM, am I right we're using ASM 7.0 (judging by
> plastic/LICENSE-ASM-7_0.txt)?
>
> There's version 7.1 released 3 March 2019 with some bug fixes, I haven't
> tried that yet.
>
>
> On Thu, Apr 11, 2019 at 9:29 PM Dmitry Gusev
> wrote:
>
>> Hi team!
>>
>> Just wanted to share an issue I found trying to upgrade to 5.5-beta-2 and
>> Java 11, maybe anyone have seen anything similar before.
>>
>> In our pages/components it's quite common to build anonymous classes for
>> Grid data sources, i.e. say if we have a the
>> sourceObject can be defined as anonymous class that's referencing some
>> parameter object:
>>
>> @Parameter
>> private Object parameterObject1;
>>
>> public GridDataSource getSourceObject()
>> {
>> return new GridDataSource()
>> {
>> @Override
>> public int getAvailableRows()
>> {
>> return count(parameterObject1); // this does not read from
&
Re: Tapestry 5.5-beta-2 problem: @Parameter field access problem with anonymous classes
I ran some more tests and found the problem only exists in Java 11 target
compatibility, it works fine with Java 9 and 10.
Could be a bug in ASM, am I right we're using ASM 7.0 (judging by
plastic/LICENSE-ASM-7_0.txt)?
There's version 7.1 released 3 March 2019 with some bug fixes, I haven't
tried that yet.
On Thu, Apr 11, 2019 at 9:29 PM Dmitry Gusev wrote:
> Hi team!
>
> Just wanted to share an issue I found trying to upgrade to 5.5-beta-2 and
> Java 11, maybe anyone have seen anything similar before.
>
> In our pages/components it's quite common to build anonymous classes for
> Grid data sources, i.e. say if we have a the
> sourceObject can be defined as anonymous class that's referencing some
> parameter object:
>
> @Parameter
> private Object parameterObject1;
>
> public GridDataSource getSourceObject()
> {
> return new GridDataSource()
> {
> @Override
> public int getAvailableRows()
> {
> return count(parameterObject1); // this does not read from
> parameter conduit
> }
> };
> }
>
> I've found that the read access for the parameterObject1 is not replaced
> in this case, and parameterObject1 reads its value from a field instead of
> a conduit.
>
> However, if parameter access is factored out from the anonymous class -
> the value is read as expected, i.e. this works fine:
>
> public GridDataSource getSourceObject()
> {
> return new MyDataSource(parameterObject1); // this reads the value
> from conduit as expected
> }
>
> public class MyDataSource implements GridDataSource
> {
> private final Object valueOfParameterObject1;
>
> public MyDataSource(Object parameterObject1)
> {
> this.valueOfParameterObject1 = parameterObject1;
> }
>
> @Override
> public int getAvailableRows()
> {
> return count(valueOfParameterObject1);
> }
> }
>
> I haven't dig any further yet, but assume it can be related with some
> changes in ASM / byte code.
>
> Just thought I'd ask here before I continue.
>
> Best regards,
> Dmitry
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Tapestry 5.5-beta-2 problem: @Parameter field access problem with anonymous classes
Hi team!
Just wanted to share an issue I found trying to upgrade to 5.5-beta-2 and
Java 11, maybe anyone have seen anything similar before.
In our pages/components it's quite common to build anonymous classes for
Grid data sources, i.e. say if we have a the
sourceObject can be defined as anonymous class that's referencing some
parameter object:
@Parameter
private Object parameterObject1;
public GridDataSource getSourceObject()
{
return new GridDataSource()
{
@Override
public int getAvailableRows()
{
return count(parameterObject1); // this does not read from
parameter conduit
}
};
}
I've found that the read access for the parameterObject1 is not replaced in
this case, and parameterObject1 reads its value from a field instead of a
conduit.
However, if parameter access is factored out from the anonymous class - the
value is read as expected, i.e. this works fine:
public GridDataSource getSourceObject()
{
return new MyDataSource(parameterObject1); // this reads the value from
conduit as expected
}
public class MyDataSource implements GridDataSource
{
private final Object valueOfParameterObject1;
public MyDataSource(Object parameterObject1)
{
this.valueOfParameterObject1 = parameterObject1;
}
@Override
public int getAvailableRows()
{
return count(valueOfParameterObject1);
}
}
I haven't dig any further yet, but assume it can be related with some
changes in ASM / byte code.
Just thought I'd ask here before I continue.
Best regards,
Dmitry
Re: Tapestry as an email rendering platform
Hi, I guess your answer is mostly about formatting HTML output using TML markup? It's not that trivial as it could be, mostly because tapestry rendering is built around HTTP request processing. I.e. one of it's core components -- PageLink -- relies on (http) Request service which is usually unavailable when you need to send an email, because you usually don't want to send it the scope of HTTP request but rather do this asynchronously or by some non-HTTP event, like timer. You can mock the request service for offline use, or build your own component for link rendering in offline mode, etc. which is not that difficult but still not trivial. The next thing is partial rendering: Tapestry does support partial rendering of blocks using PartialTemplateRenderer, but you still need to host the block on some page to be able to reference it. Those pages need to be "private", as you may not want to render them in normal way to your users. On Tue, Feb 20, 2018 at 8:31 AM, Coleman, JohnSteven (Agoda) < johnsteven.cole...@agoda.com> wrote: > Hi, > > Has anyone implemented Tapetsry to build html emails? Is that fairly > trivial to do? > > John > > > This message is confidential and is for the sole use of the intended > recipient(s). It may also be privileged or otherwise protected by copyright > or other legal rules. If you have received it by mistake please let us know > by reply email and delete it from your system. It is prohibited to copy > this message or disclose its content to anyone. Any confidentiality or > privilege is not waived or lost by any mistaken delivery or unauthorized > disclosure of the message. All messages sent to and from Agoda may be > monitored to ensure compliance with company policies, to protect the > company's interests and to remove potential malware. Electronic messages > may be intercepted, amended, lost or deleted, or contain viruses. > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] 5.4.2
Hi Jochen, Is there a change log that we can look at to test the release? On Mon, Apr 10, 2017 at 2:19 PM, Jochen Kemnade <kemn...@gmail.com> wrote: > I've created and uploaded a release of Tapestry 5.4.2, ready to be voted > upon. > > The source, binary, and documentation archives have been uploaded to: > > https://dist.apache.org/repos/dist/dev/tapestry > > and the Maven artifacts staged to: > > > https://repository.apache.org/content/repositories/staging/ > org/apache/tapestry/ > > Please examine these files to determine if the new release, 5.4.2, is > ready. > > I've also created a 5.4.2 tag in Git: > > > https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a= > log;h=refs/tags/5.4.2 > > Vote will run for three days and requires majority approval from > the PMC: At least 3 binding +1 votes and more positive than > negative binding votes. > > On a successful vote, I'll release the Maven artifacts, the archives, > and make the necessary updates to JIRA and the Tapestry site. > > Only votes cast by Tapestry PMC members are binding, but input > from the community is highly valued. Please indicate whether your > vote is binding or not after your full name (as it will appear in > the end-of-vote summary). > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: VOTE: Jochen Kemnade as PMC member
Dmitry Gusev: +1 (non-binding) On Fri, Feb 27, 2015 at 3:37 AM, Howard Lewis Ship hls...@gmail.com wrote: If you haven't been noticing, Jochen has been putting in a lot of time on Tapestry; closing bugs, leading discussions, and mentoring people on the mailing list. He's been at it a more than long enough to show real commitment ... I'd love to see someone this charged up added to the Tapestry PMC. This is a binding vote to run for three days. It requires majority approval: at least three binding +1's and more binding +1's than -1's. Howard M. Lewis Ship: +1 (binding) -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com @hlship -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry Release 5.3.8
Dmitry Gusev: +1 (non-binding) On Thu, Nov 20, 2014 at 10:20 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: I've created and uploaded a release of Tapestry 5.3.8, ready to be voted upon. The source and source downloads are uploaded to: http://people.apache.org/~kaosko/tapestry-releases/ and the Maven artifacts staged to: https://repository.apache.org/content/repositories/orgapachetapestry-1035 Please examine these files to determine if the new release, 5.3.8, is ready. I've also created a 5.3.8 tag in Git: https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=shortlog;h=refs/tags/ 5.3.8 Release notes page has been updated too. Vote will run for three days; On a successful vote, I'll release the Maven artifacts, and move the source and javadoc distributions from these directories to the proper distribution directories and update the Tapestry site documentation, and send out appropriate notifications. Kalle Korhonen: +1 (non-binding) -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Drop support for Java 5 in Tapestry 5.4
Dmitry Gusev: +1 (non-binding) On Sat, May 17, 2014 at 10:46 AM, Andreas Ernst a...@ae-online.de wrote: Andreas Ernst: +1 (non-binding) Am 15.05.14 15:14, schrieb Jochen Kemnade: There have been discussions whether we want to keep compatibility with Java 5 for the upcoming 5.4 release. Java 5 is EOSL since October 2009. While requiring Java 6 would not bring us much benefits, there might be some libraries that we cannot use because they do not support Java 5. Also, we'd spare ourselves some efforts not having to support Java 5 anymore. The vote will run for 3 days and, if it succeeds, I will increase the minimum required Java version to 1.6. Jochen Kemnade: +1 (non-binding) - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- ae | Andreas Ernst | IT Spektrum Postfach 5, 65612 Beselich Schupbacher Str. 32, 65614 Beselich, Germany Tel: +49-6484-91002 Fax: +49-6484-91003 a...@ae-online.de | www.ae-online.de www.tachyon-online.de - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Jochen Kemnade as Tapestry Committer
Dmitry Gusev: +1 (non-binding) On Fri, Apr 18, 2014 at 1:41 AM, Howard Lewis Ship hls...@gmail.com wrote: I've seen Jochen busy on the mailing list for quite some time, and even busier filing bugs and submitting patches. I think he'd make a fine addition to the team. Howard M. Lewis Ship: +1 (binding) -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com @hlship -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Discussion on AJAX requests need even more than a context?
Hi Geoff, How would you know on the client-side which URLs you have to update? What if some form or a link in client-side DOM isn't a tapestry URL and shouldn't be updated? Or what if I generated some event URLs on the server-side and passed them via JS initializer specification to client-side and they're located in JavaScript objects or stored as data-* attributes in DOM -- how would these URLs be updated? As for your example, it's not clear to me. You said you have filter F, list L, and editor E. Imagine that only list and filter are on screen and all event links updated on filter submit as you suggested. Then you're clicking on some link (from the list?) to display the editor E. New editor will be rendered on the server side and will appear in client-side via zone update. Note that though you will have the filter request parameter on the server side during E rendering - you can't do anything with it, because you said that E is generic and doesn't know about filters. Later if you click submit on editor, it's submit link won't contain filter information on client-side, because you invoked ajaxResponseRenderer.setQueryParameters(filter, filterValue); before editor E appeared in the client-side DOM and it's submit link haven't been updated. Am I missing something? On Wed, Mar 19, 2014 at 4:45 PM, Geoff Callender geoff.callender.jumpst...@gmail.com wrote: So it seems we're pretty much agreed that each AJAX-capable component needs a context parameter, which its containing component can use to restore its state (usually its parameters) before it makes any decisions. http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Discussion-on-all-AJAX-requests-needing-context-tt5726132.html But what if other components on the page need to know their state, too, before they can update their zoned contents? For example, a list of persons, L, in one part of the page might need to refresh itself whenever a person is edited in component E somewhere else on the page. That's easy (with a bit of bubbling up and perhaps some calls down, or perhaps a bit of pub-sub), unless L is filtered, like this: http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons E doesn't know about L or its filter, and nor should it, so the context on the submit in E will not contain filter info. In that example I found an OK-ish solution but I'm looking for a better way. The solution I found was to make L return javascript that submits the filter form. I made use of the fact that the client knows its state. But I'd prefer not to have that extra round-trip. So here's a crazy idea... What if, when the filter is submitted, we could do something like this: ajaxResponseRenderer.setQueryParameters(filter, filterValue); and Tapestry, client-side, would set that parameter on *every* Form, EventLink, Select, etc. in the page. That way, no matter what event request comes to the server, its request will be carrying the latest filter value. In the example above, L would always be able to find out the current filter: String filterValue = request.getParameter(filter); Crazy, right? I suppose that each component that wants to use this facility would need a way to tell Tapestry its initial values. Perhaps this could be declarative. Thoughts? Cheers, Geoff - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Discussion on all AJAX requests needing context
I'd agree with context for the Grid component, though the only use-case I
see for Grid's context is for paging event links, and it'd be nice and easy
to support this.
But Select component must be put into a Form, and forms have contexts, so I
see no problems here.
I don't think one should avoid using @Persist, it's just may be not the
best choice for some use-cases using it with session scope.
In such cases cookie-backed scope usually works well.
Also I don't see any problems with your 2nd and 3rd workarounds. The
question here is if you want to make the page state bookmark able, if you
do -- you have to put this information to page's context (or page params).
And you should be able to reconstruct the rest required parameters for all
your components from page's context.
On Fri, Mar 14, 2014 at 12:53 PM, Dusko Jovanovski dusk...@gmail.comwrote:
You are absolutely right. Context for Select and Grid would be a welcome
addition. Even though these are only scaffolding components that are meant
to be extended and modified to fit your use cases, most people use them as
they are. There may be some other components that need this addition, but
none come to mind at the moment.
On Fri, Mar 14, 2014 at 3:32 AM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
To all Tapestry devs,
Please, I want your thoughts before I file a JIRA, just in case I have my
wires crossed.
I'm thinking that Tapestry has real problems working with complex AJAX
pages because there are AJAX components that don't have a context
parameter.
The problem I see is that a deeply nested component, C, cannot handle an
event from an AJAX sub-component unless C can reconstruct its context,
ie.
C has to be able to restore its parameters. This has been solved in Form
and EventLink by giving them a context parameter. eg.
onPrepareForSubmit(Integer contextArg1) { etc. }
onMyevent(Integer contextArg1) { etc. }
I routinely use this context to restore C's parameters, eg.
@Parameter
private Integer parameter1;
onPrepareForSubmit(Integer parameter1) {
this.parameter1 = parameter1;
}
But what about Select and Grid? Neither of them has a context.
Without a context, C can't handle 2 or more AJAX Select components. When
one sends an event, C has no idea of the value of the other, nor of its
own
parameters. A context would fix all of this.
Without a context, an inplace request from a GridPager can't remind C was
currently selected or how the Grid was being filtered. The same goes for
Grid column select events. (See
https://issues.apache.org/jira/browse/TAP5-2297)
There are workarounds, but with a context I think we wouldn't need them:
1. Use @Persist. Well, we all try to avoid this.
2. Include C's parameters in the page's context and make sure they're
passed down through every nested component down to C. But surely that's
not
reasonable. What if the page is concerned with a Hospital, but in it our
components drill down through a Ward to a Patient and C is concerned with
the Patient's Diagnosis. Does it really make sense to pass diagnosisId in
through the page context and down through all the in-between components?
Following this logic, we could end up with every parameter of every
component in the page context.
3. Use activation request parameters, but it appears to me to be messy.
@ActivationRequestParameters is only available at the page level, so
again
we have to pass them all the way down. Even if we do this, it's a
nuisance
to pass them all the way UP in the first place. And again we could end up
with every parameter of every component being declared in the page.
4. Perhaps C can get and set request parameters by hand, but why? Isn't a
context better?
Am I seeing an issue that doesn't exist? Is there a better way?
Cheers,
Geoff
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Discussion on all AJAX requests needing context
Oh, I see you what you mean now, there's eventLink that triggers
Select#onChange for ajax selects and it doesn't include any context in the
link. Makes sense.
On Fri, Mar 14, 2014 at 1:31 PM, Chris Poulsen mailingl...@nesluop.dkwrote:
Dimitry, how can we get a hold of the form context in the onValueChanged
handler for Select? (zone/ajax case)
--
Chris
On Fri, Mar 14, 2014 at 10:16 AM, Dmitry Gusev dmitry.gu...@gmail.com
wrote:
I'd agree with context for the Grid component, though the only use-case I
see for Grid's context is for paging event links, and it'd be nice and
easy
to support this.
But Select component must be put into a Form, and forms have contexts,
so I
see no problems here.
I don't think one should avoid using @Persist, it's just may be not the
best choice for some use-cases using it with session scope.
In such cases cookie-backed scope usually works well.
Also I don't see any problems with your 2nd and 3rd workarounds. The
question here is if you want to make the page state bookmark able, if you
do -- you have to put this information to page's context (or page
params).
And you should be able to reconstruct the rest required parameters for
all
your components from page's context.
On Fri, Mar 14, 2014 at 12:53 PM, Dusko Jovanovski dusk...@gmail.com
wrote:
You are absolutely right. Context for Select and Grid would be a
welcome
addition. Even though these are only scaffolding components that are
meant
to be extended and modified to fit your use cases, most people use them
as
they are. There may be some other components that need this addition,
but
none come to mind at the moment.
On Fri, Mar 14, 2014 at 3:32 AM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
To all Tapestry devs,
Please, I want your thoughts before I file a JIRA, just in case I
have
my
wires crossed.
I'm thinking that Tapestry has real problems working with complex
AJAX
pages because there are AJAX components that don't have a context
parameter.
The problem I see is that a deeply nested component, C, cannot handle
an
event from an AJAX sub-component unless C can reconstruct its
context,
ie.
C has to be able to restore its parameters. This has been solved in
Form
and EventLink by giving them a context parameter. eg.
onPrepareForSubmit(Integer contextArg1) { etc. }
onMyevent(Integer contextArg1) { etc. }
I routinely use this context to restore C's parameters, eg.
@Parameter
private Integer parameter1;
onPrepareForSubmit(Integer parameter1) {
this.parameter1 = parameter1;
}
But what about Select and Grid? Neither of them has a context.
Without a context, C can't handle 2 or more AJAX Select components.
When
one sends an event, C has no idea of the value of the other, nor of
its
own
parameters. A context would fix all of this.
Without a context, an inplace request from a GridPager can't remind C
was
currently selected or how the Grid was being filtered. The same goes
for
Grid column select events. (See
https://issues.apache.org/jira/browse/TAP5-2297)
There are workarounds, but with a context I think we wouldn't need
them:
1. Use @Persist. Well, we all try to avoid this.
2. Include C's parameters in the page's context and make sure they're
passed down through every nested component down to C. But surely
that's
not
reasonable. What if the page is concerned with a Hospital, but in it
our
components drill down through a Ward to a Patient and C is concerned
with
the Patient's Diagnosis. Does it really make sense to pass
diagnosisId
in
through the page context and down through all the in-between
components?
Following this logic, we could end up with every parameter of every
component in the page context.
3. Use activation request parameters, but it appears to me to be
messy.
@ActivationRequestParameters is only available at the page level, so
again
we have to pass them all the way down. Even if we do this, it's a
nuisance
to pass them all the way UP in the first place. And again we could
end
up
with every parameter of every component being declared in the page.
4. Perhaps C can get and set request parameters by hand, but why?
Isn't a
context better?
Am I seeing an issue that doesn't exist? Is there a better way?
Cheers,
Geoff
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Discussion on all AJAX requests needing context
Right, actually every eventLink that is inside of core component should
support context so that server-side could restore some state on request.
On Fri, Mar 14, 2014 at 5:01 PM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
I think column sorting also needs to pass context if, for instance, you're
using a paged, filtered, GridDataSource. Without a context it might not
build the next page correctly.
Bookmarking is a different issue, that I don't yet have a good solution
for. For example, every EventLink has the page context baked into it when
it's rendered. If events in other zones modify the page context, EventLinks
outside those zones will not know the page context has changed. To address
this, the event handlers must either refresh every component that can send
a component event request (a zone around every EventLink?) or, for
simplicity, refresh the whole page. If you're refreshing the whole page
then the advantage of AJAX is kind of lost.
On 14/03/2014, at 8:16 PM, Dmitry Gusev wrote:
I'd agree with context for the Grid component, though the only use-case I
see for Grid's context is for paging event links, and it'd be nice and
easy
to support this.
But Select component must be put into a Form, and forms have contexts,
so I
see no problems here.
I don't think one should avoid using @Persist, it's just may be not the
best choice for some use-cases using it with session scope.
In such cases cookie-backed scope usually works well.
Also I don't see any problems with your 2nd and 3rd workarounds. The
question here is if you want to make the page state bookmark able, if you
do -- you have to put this information to page's context (or page
params).
And you should be able to reconstruct the rest required parameters for
all
your components from page's context.
On Fri, Mar 14, 2014 at 12:53 PM, Dusko Jovanovski dusk...@gmail.com
wrote:
You are absolutely right. Context for Select and Grid would be a welcome
addition. Even though these are only scaffolding components that are
meant
to be extended and modified to fit your use cases, most people use them
as
they are. There may be some other components that need this addition,
but
none come to mind at the moment.
On Fri, Mar 14, 2014 at 3:32 AM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
To all Tapestry devs,
Please, I want your thoughts before I file a JIRA, just in case I have
my
wires crossed.
I'm thinking that Tapestry has real problems working with complex AJAX
pages because there are AJAX components that don't have a context
parameter.
The problem I see is that a deeply nested component, C, cannot handle
an
event from an AJAX sub-component unless C can reconstruct its context,
ie.
C has to be able to restore its parameters. This has been solved in
Form
and EventLink by giving them a context parameter. eg.
onPrepareForSubmit(Integer contextArg1) { etc. }
onMyevent(Integer contextArg1) { etc. }
I routinely use this context to restore C's parameters, eg.
@Parameter
private Integer parameter1;
onPrepareForSubmit(Integer parameter1) {
this.parameter1 = parameter1;
}
But what about Select and Grid? Neither of them has a context.
Without a context, C can't handle 2 or more AJAX Select components.
When
one sends an event, C has no idea of the value of the other, nor of its
own
parameters. A context would fix all of this.
Without a context, an inplace request from a GridPager can't remind C
was
currently selected or how the Grid was being filtered. The same goes
for
Grid column select events. (See
https://issues.apache.org/jira/browse/TAP5-2297)
There are workarounds, but with a context I think we wouldn't need
them:
1. Use @Persist. Well, we all try to avoid this.
2. Include C's parameters in the page's context and make sure they're
passed down through every nested component down to C. But surely that's
not
reasonable. What if the page is concerned with a Hospital, but in it
our
components drill down through a Ward to a Patient and C is concerned
with
the Patient's Diagnosis. Does it really make sense to pass diagnosisId
in
through the page context and down through all the in-between
components?
Following this logic, we could end up with every parameter of every
component in the page context.
3. Use activation request parameters, but it appears to me to be messy.
@ActivationRequestParameters is only available at the page level, so
again
we have to pass them all the way down. Even if we do this, it's a
nuisance
to pass them all the way UP in the first place. And again we could end
up
with every parameter of every component being declared in the page.
4. Perhaps C can get and set request parameters by hand, but why?
Isn't a
context better?
Am I seeing an issue that doesn't exist
Re: Discussion on all AJAX requests needing context
I'm not sure about changing page context, but I'd suppose that if page
context changed - then page URL should reflect that, and you have to reload
the page -- and that is usually with HTTP 3xx redirect. You can't just
change the URL in browser's address bar without reloading entire page. One
exception to that if it's the URL's hash you want to change. In this case
I'd expected that you have some JS-model on client-side that would handle
routing and update other links somehow based on client-side model changes.
I haven't seen any real implementations of this approach w/ T5 though.
As for server-side updates of eventLinks -- this is why multi-zone response
support exists, isn't it? I use it when I don't want to bother updating
client-side elements one-by-one -- it's simpler to re-render entire zones.
Though, yes, that complicates things on the server-side. I'm using
Publisher service [1] for such updates to reduce this complexity, but it's
still not so simple to maintain.
[1] https://github.com/anjlab/anjlab-tapestry-commons/wiki/Publisher-API
On Fri, Mar 14, 2014 at 5:01 PM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
I think column sorting also needs to pass context if, for instance, you're
using a paged, filtered, GridDataSource. Without a context it might not
build the next page correctly.
Bookmarking is a different issue, that I don't yet have a good solution
for. For example, every EventLink has the page context baked into it when
it's rendered. If events in other zones modify the page context, EventLinks
outside those zones will not know the page context has changed. To address
this, the event handlers must either refresh every component that can send
a component event request (a zone around every EventLink?) or, for
simplicity, refresh the whole page. If you're refreshing the whole page
then the advantage of AJAX is kind of lost.
On 14/03/2014, at 8:16 PM, Dmitry Gusev wrote:
I'd agree with context for the Grid component, though the only use-case I
see for Grid's context is for paging event links, and it'd be nice and
easy
to support this.
But Select component must be put into a Form, and forms have contexts,
so I
see no problems here.
I don't think one should avoid using @Persist, it's just may be not the
best choice for some use-cases using it with session scope.
In such cases cookie-backed scope usually works well.
Also I don't see any problems with your 2nd and 3rd workarounds. The
question here is if you want to make the page state bookmark able, if you
do -- you have to put this information to page's context (or page
params).
And you should be able to reconstruct the rest required parameters for
all
your components from page's context.
On Fri, Mar 14, 2014 at 12:53 PM, Dusko Jovanovski dusk...@gmail.com
wrote:
You are absolutely right. Context for Select and Grid would be a welcome
addition. Even though these are only scaffolding components that are
meant
to be extended and modified to fit your use cases, most people use them
as
they are. There may be some other components that need this addition,
but
none come to mind at the moment.
On Fri, Mar 14, 2014 at 3:32 AM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
To all Tapestry devs,
Please, I want your thoughts before I file a JIRA, just in case I have
my
wires crossed.
I'm thinking that Tapestry has real problems working with complex AJAX
pages because there are AJAX components that don't have a context
parameter.
The problem I see is that a deeply nested component, C, cannot handle
an
event from an AJAX sub-component unless C can reconstruct its context,
ie.
C has to be able to restore its parameters. This has been solved in
Form
and EventLink by giving them a context parameter. eg.
onPrepareForSubmit(Integer contextArg1) { etc. }
onMyevent(Integer contextArg1) { etc. }
I routinely use this context to restore C's parameters, eg.
@Parameter
private Integer parameter1;
onPrepareForSubmit(Integer parameter1) {
this.parameter1 = parameter1;
}
But what about Select and Grid? Neither of them has a context.
Without a context, C can't handle 2 or more AJAX Select components.
When
one sends an event, C has no idea of the value of the other, nor of its
own
parameters. A context would fix all of this.
Without a context, an inplace request from a GridPager can't remind C
was
currently selected or how the Grid was being filtered. The same goes
for
Grid column select events. (See
https://issues.apache.org/jira/browse/TAP5-2297)
There are workarounds, but with a context I think we wouldn't need
them:
1. Use @Persist. Well, we all try to avoid this.
2. Include C's parameters in the page's context and make sure they're
passed down through every nested component down to C. But surely that's
not
reasonable. What
Re: Does Grid need a context to participate in AJAX pages?
Hi Geoff, another way to handle this situation (a workaround?) is by using @ActivationRequestParameter(paramName) attribute on page properties. This is what I do for my projects and what's working for me. On Mon, Feb 24, 2014 at 4:20 PM, Geoff Callender geoff.callender.jumpst...@gmail.com wrote: To participate in nested components in an AJAX page we can utilise Form's, EventLink's, and ActionLink's context parameter. It can be used to pass the parameters of the enclosing component. The containing component's event handlers can receive the context and set its parameters from them before making any decisions. This works well. However, Grid doesn't have a context parameter. Consequently, when the user chooses a new page in a GridPager, or a new sort order in a Grid column, the containing component doesn't know the context and consequently might not be able to render the Grid correctly. I've produced an example, in which I've created a GridWithContext to wrap a Grid, and modified GridPager to include the context in its links and bubble up a new event with the context. It's in JumpStart 7.0 preview-6: http://jumpstart.doublenegative.com.au/jumpstart7/ Without this, I would lose the selectedPersonId when I a GridPager link. So I think Grid needs a context. Or is there another existing way to handle this problem? There's an existing JIRA for this. https://issues.apache.org/jira/browse/TAP5-1162 Cheers, Geoff - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Tapestry 5.4 - Integrating angular
I thought about Angular/Tapestry integration and I see one issue so far:
Is's integrating with Tapestry5 forms
Angular can update DOM on the client-side but you won't be able to submit
that form, to be more correct because tapestry won't be able to handle
submitted data (translate values, validate, etc.) because it doesn't know
about them -- they won't be in t:hidden field
Correct me if I'm wrong, but you will have to manually handle this data by
getting it from request parameters. So maybe we will need some alternative
to default form component here, maybe using some REST endpoints for
handling of POSTs, not sure.
On Thu, Nov 7, 2013 at 6:40 PM, Michael Wyraz michael.wy...@evermind.dewrote:
Hi,
I could solve it - just needed to bootstrap angularjs manually:
- remove ng-app from my html
- add initializer code:
angular.bootstrap(document.getElementById('myapproot'),[MyApp']);
Hello Thiago,
thank you for fast reply. I'll check this as soon as my app runs.
At the moment I try to get angularjs to work as module. A while ago you
wrote that you already did this and solved the problems.
What I've done:
- downloaded angular.zip, extracted to META-INF/assets/angular
- added a new JavaScriptModuleConfiguration named angular that points
to angular.js
- changed my initializing code to
require([angular,jquery],function() {
var app = angular.module('MyApp', []);
...
Angularjs bootstrapsbut fails to find the module. I found that it starts
with bootstrapping before my var app = angular.module code is called.
Any idea what's going wrong there?
Regards,
Michael.
--
Mit freundlichen Grüßen / Regards
Michael Wyraz
evermind GmbH
Schorlemmerstraße 1
04155 Leipzig
Tel.: +49 (0)341-25 39 66 - 0
Fax:+49 (0)341-25 39 66 - 1
Funk: +49 (0)177-73 00 00 3
E-Mail: michael.wy...@evermind.de
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
Thomas Grünert
Michael Wyraz
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Accept GitHub Pull Requests for Tapestry5
I'd really like to see GitHub Pull Requests accepted in tapestry. I just googled and a first link pointed to apache project that do this, so this should be possible: https://github.com/apache/incubator-spark I can see they have pull requests and some of them were already accepted. I really think this will encourage more fixes from community and this may be really agile. As you know GitHub supports integration with Travis CI ( https://travis-ci.org) and other tools that may contribute to Tapestry development. What do you think? -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Accept GitHub Pull Requests for Tapestry5
Uli, as for license considerations there is a notice on the Spark readme, that should suffice if I understand this right: https://github.com/apache/incubator-spark#contributing-to-spark You probably right about manually applied PRs... and they also closed by https://github.com/asfgit account, which is something ASF specific. Well, at least they hold discussions on that PRs right on GitHub. So there's nothing we can do with this, right? On Fri, Nov 1, 2013 at 2:24 PM, Ulrich Stärk u...@spielviel.de wrote: Oh and the closed pull requests of the Spark projects are most likely due to github closing them automatically when a commit mentioning the request is made. Merging the request has to be done manually though. Uli On 2013-11-01 11:20, Ulrich Stärk wrote: To my knowledge, github pull requests can't be accepted directly. What's on Github is just a mirror of our repo at git-wip.us.apache.org. Apache projects that accept pull requests usually ask developers to create regular patches which are incorporated the traditional way: through patches. This is also a license concern. Having a contributor bring a patch to us makes sure that he really is knowingly contributing under the Apache License. Uli On 2013-11-01 10:20, Dmitry Gusev wrote: I'd really like to see GitHub Pull Requests accepted in tapestry. I just googled and a first link pointed to apache project that do this, so this should be possible: https://github.com/apache/incubator-spark I can see they have pull requests and some of them were already accepted. I really think this will encourage more fixes from community and this may be really agile. As you know GitHub supports integration with Travis CI ( https://travis-ci.org) and other tools that may contribute to Tapestry development. What do you think? - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Tapestry Bugs - How to get them fixed?
On Sun, Oct 27, 2013 at 6:03 PM, Lenny Primak lpri...@hope.nyc.ny.uswrote: Quick Jira search reveals bugs I care about: Basically, this is a result of a search of issues that are reported by me, voted on my me or watched by me: https://issues.apache.org/jira/browse/TAP5-2208 https://issues.apache.org/jira/browse/TAP5-2197 https://issues.apache.org/jira/browse/TAP5-2196 https://issues.apache.org/jira/browse/TAP5-2188 https://issues.apache.org/jira/browse/TAP5-2187 https://issues.apache.org/jira/browse/TAP5-2185 https://issues.apache.org/jira/browse/TAP5-2182 https://issues.apache.org/jira/browse/TAP5-2173 https://issues.apache.org/jira/browse/TAP5-2172 https://issues.apache.org/jira/browse/TAP5-2168 https://issues.apache.org/jira/browse/TAP5-2167 https://issues.apache.org/jira/browse/TAP5-2166 https://issues.apache.org/jira/browse/TAP5-2158 https://issues.apache.org/jira/browse/TAP5-2140 https://issues.apache.org/jira/browse/TAP5-2027 https://issues.apache.org/jira/browse/TAP5-1918 https://issues.apache.org/jira/browse/TAP5-1883 https://issues.apache.org/jira/browse/TAP5-1845 https://issues.apache.org/jira/browse/TAP5-1803 https://issues.apache.org/jira/browse/TAP5-1772 https://issues.apache.org/jira/browse/TAP5-1741 https://issues.apache.org/jira/browse/TAP5-1661 https://issues.apache.org/jira/browse/TAP5-1640 https://issues.apache.org/jira/browse/TAP5-1634 https://issues.apache.org/jira/browse/TAP5-1611 https://issues.apache.org/jira/browse/TAP5-1606 https://issues.apache.org/jira/browse/TAP5-1512 https://issues.apache.org/jira/browse/TAP5-1404 https://issues.apache.org/jira/browse/TAP5-970 https://issues.apache.org/jira/browse/TAP5-805 This is comprehensive list, not ordered by priority. More comments interspersed... On Oct 27, 2013, at 3:35 AM, Dmitry Gusev wrote: I'm sure if you prepare well-tested pull request it will be accepted, but you have to spend some time on it -- this is the price you should pay for using open source for free. I don't have time for that. I am willing to pay to get my bugs fixed, out of my own pocket (my clients won't pay for it) I originally built the FlowLogix library... Most of the functionality in there now is actually workarounds for various bugs and missing features in Tapestry. Tapestry has one good ability to write workarounds for the bugs in client code (via service overrides, decorators, etc.). If you have some of the bugs fixed in FlowLogix I'd recommend to separate the fixes to some FlowLogix sub-project and write some guides to corresponding JIRA issues on how to apply the workarounds you've already implemented. I have all fixes documented pretty well in the wiki. As we go forward to T5.4 and beyond, I don't see that trajectory as sustainable in the amount of time that I have to spend on this. Also, if you do split up the library into many modules, you will have 10 of them or so, a nightmare to maintain. None of these bug fixes are something that somebody wouldn't want anyway, no reason to make them that granular, the whole library is only 100k By modules I mean not maven/gradle sub projects, but tapestry modules which are simple Java classes: one module -- one class. No need to add these modules to auto discovery via manifest. Users may include these modules by using @SubModule on their AppModules. I see no extra-overhead here. Your assumption about everybody want my fixes is wrong, I don't want them in my project if they come with 3rd party library that has tons of extra dependencies like JEE stuff, etc. Also I want the ability to opt-out some fixes if I have better workaround for them. That was my point. I'm sure it is possible to write most of the workarounds as a separate tapestry modules. I'd maybe even used strategy of one tapestry submodule per one bugfix. Maybe name those modules like FixForXXX and if I want your workaround in my project I'd add this modules as a submodule to my AppModule. Already done in FlowLogix library (see my comments re: one-per-module above) that would make too many modules, and I don't have time to create / maintain all of them On Sun, Oct 27, 2013 at 10:40 AM, Lenny Primak lpri...@hope.nyc.ny.us wrote: Some of the issues I am having is more design-oriented, and a patch would not be a simple thing to do. Also, in order to produce a patch (with tests) a lot of work needs to happen. That work, for example, for someone like me will take 10x as long as for someone already familiar with the Tapestry code, or the part of the code that I am trying to fix. When someone already has built Tapestry environment / Selenium test environment, i.e. a Tapestry committer, the work will take much shorter amount of time. With all due respect, this isn't the best use of my time right now, as I have booked for more work than I can do in a day, every day. I want to be working on my clients' code
Re: Tapestry Bugs - How to get them fixed?
Jochen, what you're talking about is actually GitHub Pull Requests -- they do exactly this. On Mon, Oct 28, 2013 at 11:34 AM, Jochen Berger foober...@gmail.com wrote: Am 27.10.2013 15:03, schrieb Lenny Primak: Quick Jira search reveals bugs I care about: Basically, this is a result of a search of issues that are reported by me, voted on my me or watched by me: Maybe we can find a way to better mark low-hanging fruit, i.e. use JIRA labels to point out, which issues have patches attached and which ones include tests and so on? What about putting up a Wiki page with guidelines that patch writers should stick to when they submit patches? I think there are a lot of open issues with patches dangling around with no committer taking care of them (not even by commenting on them or requesting improvements). I find it quite annoying to find issues, submitting patches and not getting them applied because (at least that's what I suspect) they are to hard to find for people with commit access. What do you think of the following (not necessarily in that order) * Let's use the patch label for all issues that have a patch attached * Find all issues that have an attachment but do not have the patch label and assign it to them if the attachment is a patch * Create the Wiki page with the patch guidelines and link it with JIRA so that everybody who submits a patch will have to read it. Maybe even post a comment with link to the page on all open issues with patches I think there's already a lot of improvement up to here. If you're a committer and can't sleep at night, just filter for open issues with the patch label. Now for the time-consuming tasks: * Go through the issues with the patch label, check if they contain a test and apply the contains-test label * Go through the issues with the patch label, check if the patch applies cleanly to master and, if it doesn't, ask the committer to rebase it and apply the needs-rebase label I guess, some of this can be done by a script, at least the second task. * Go through the issues that have the patch and contains-test labels but not the needs-rebase label and apply the patches or leave a comment what needs to be improved. I know, some of this will take a lot of time, but I think, it can help us in getting some of the good patches that are already there applied and encourage people to write patches. And the best thing is, only the last part has to be taken care of by an actual committer, all the tinkering with the labels can be done by any regular JIRA user. Jochen --**--**- To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.orgdev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Tapestry Bugs - How to get them fixed?
in T5.4, which brings much more work and more bugs to fix. I'd like to know if any committers want to help solve this problem? I know it can be solved. What can be the motivating factor in getting these bugs fixed? I will even go as far as paying for the fixes. My clients won't pay for me to fix Tapestry, so I would have to pay out of my own pocket, just so I don't have to lose time fixing Tapestry myself. Any other suggestions? Same applies to Tynamo project as well. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Tapestry Bugs - How to get them fixed?
I can also see one technical difficulty that prevents quick patches -- this is JIRA. JIRA is not the right tool for providing patches for a git project. Looking at other open source projects that are hosted on GitHub you can notice how many pull-requests are done for them. Having pull requests being one-click away from being applied is very important I think. I'm not sure if this is some Apache requirement that Tapestry must store its codebase on Apache's git repo, but there is a Tapestry 5 mirror on GitHub: https://github.com/apache/tapestry-5 Though very few people know about it, maybe because it's not mentioned here: http://tapestry.apache.org/community.html#Community-SourceCodeAccess There is also no activity on GitHub, there is even no Issues section in there. And also zero pull-requests and no README.md with some simple instructions how to contribute. Not sure if somebody from the dev team has access to this repo, but maybe we should change this: enable issues and accept pull requests from GitHub? Will they be synced back to Apache's repo? If yes, maybe we should start using GitHub repo as a primary repo for tapestry development? On Sun, Oct 27, 2013 at 11:35 AM, Dmitry Gusev dmitry.gu...@gmail.comwrote: Every bug is individual and needs to be discussed separately. It would be good start to list all the bugs you're talking about here in this thread to be more specific. I'm sure if you prepare well-tested pull request it will be accepted, but you have to spend some time on it -- this is the price you should pay for using open source for free. I originally built the FlowLogix library... Most of the functionality in there now is actually workarounds for various bugs and missing features in Tapestry. Tapestry has one good ability to write workarounds for the bugs in client code (via service overrides, decorators, etc.). If you have some of the bugs fixed in FlowLogix I'd recommend to separate the fixes to some FlowLogix sub-project and write some guides to corresponding JIRA issues on how to apply the workarounds you've already implemented. I'm sure it is possible to write most of the workarounds as a separate tapestry modules. I'd maybe even used strategy of one tapestry submodule per one bugfix. Maybe name those modules like FixForXXX and if I want your workaround in my project I'd add this modules as a submodule to my AppModule. On Sun, Oct 27, 2013 at 10:40 AM, Lenny Primak lpri...@hope.nyc.ny.uswrote: Some of the issues I am having is more design-oriented, and a patch would not be a simple thing to do. Also, in order to produce a patch (with tests) a lot of work needs to happen. That work, for example, for someone like me will take 10x as long as for someone already familiar with the Tapestry code, or the part of the code that I am trying to fix. When someone already has built Tapestry environment / Selenium test environment, i.e. a Tapestry committer, the work will take much shorter amount of time. With all due respect, this isn't the best use of my time right now, as I have booked for more work than I can do in a day, every day. I want to be working on my clients' code, not Tapestry code. I don't want to have to get Selenium to work (which never worked in my environment) Our clients are not that advanced and we don't have integration testing, but we do a lot of unit testing. I just want to use Tapestry, report issues, and have them fixed. This problem perpetually exists in the Tapestry community, there are plenty of (valid) reasons for it (as you mentioned) but I am looking for a solution, which doesn't involve me spending more and more time on it (which I certainly do not have) On Oct 27, 2013, at 12:00 AM, Kalle Korhonen wrote: Most if not all of the committers are in the same boat as you are. They have already risked their own time and energy to patch issues themselves so many times that the previous committers thought it's simply easier to give commit access to this person than to keep applying his patches. All software has bugs but Tapestry's codebase is in general very mature, well tested and well thought out. Tapestry committers have, for various reasons, decided that the benefits of using Tapestry outweigh the drawbacks, even when patching issues themselves. Everybody needs to do their own benefit analysis. In terms of user base, Tapestry has one of the largest among Java web frameworks. The most certain way of getting your issue fixed is supplying a patch with test. It doesn't always get applied or it doesn't get applied without changes. If you think it's difficult to get a patch applied to Tapestry, you should try kernel development first. Kalle On Sat, Oct 26, 2013 at 6:31 PM, Lenny Primak lpri...@hope.nyc.ny.us wrote: Hi guys, I am struggling with a problem - how to get bugs (that I care about) fixed? I am building web apps for clients that run
Re: Status of TAP5-1973
Lenny, what cloud / cluster environments are you talking about? Do you have any concrete examples? I'm using this feature with OpenShift and Jelastic and it works fine, there's no any dynamically assigned ports. Is this even can be possible? Because as far as I know application servers require so their binding ports have to be set implicitly in configs. Or these ports can be set using app-server specific system variables, which you may read in provideApplicationDefaults and set those as value for the tapestry symbols. On Tue, Sep 3, 2013 at 8:53 PM, Lenny Primak lpri...@hope.nyc.ny.us wrote: Indeed it does (as stated in the comments of the issue also) Setting them is not a good option, as the installation is in the cloud / clusters with multiple ports, dynamically assigned ports, etc. Setting these would be a maintenance nightmare (if even possible) On Sep 3, 2013, at 9:20 AM, Massimo Lusetti wrote: On Tue, Sep 3, 2013 at 10:22 AM, Lenny Primak lpri...@hope.nyc.ny.us wrote: In this issue: https://issues.apache.org/jira/browse/TAP5-1973 If you take a look at the last comment from Alejandro Scandroli, it looks like the side effect is still not fixed in 5.4. Right now, this is being worked around in FlowLogix, but I would like to remove this code (i.e. asking for this bug to get fixed) in 5.4 Thank you Does the issue pops out only if you don't set HOSTPORT and HOSTPORT_SECURE ? -- Massimo Lusetti - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Where are all the commits?
Still my question remains: What do you expect from a person when you invite him as a committer to Tapestry project? I mean in each specific case. You just hope that he will do something useful someday with the core codebase or there is some concrete unit of work that you expect him to do? Or maybe that person asked to be committer and has some specific proposals for contribution to the code base? It is just unclear (to me) from the vote description what will the person do (or what he plan to do) as a committer? This maybe unclear because we don't have any roadmap with pool of tasks that should be implemented except for a bunch of long-living JIRA issues. On Thu, Jul 4, 2013 at 10:05 AM, Kalle Korhonen kalle.o.korho...@gmail.comwrote: On Wed, Jul 3, 2013 at 5:56 PM, Howard Lewis Ship hls...@gmail.com wrote: On Wed, Jul 3, 2013 at 2:06 PM, Dmitry Gusev dmitry.gu...@gmail.com wrote: Dmitry Gusev: +1 (non-binding) I like seeing that new Tapestry committers appear, but looking at git logs I see that (almost) the only core committer is Howard. Well, I am the most invested in things. There's a lot of people in any community who talk the talk but typically very few who walk the walk. I have a very high respect for Howard since most of the time he'll write the code instead of talking about some changes he'd like to have. From this point of view, it appears to me that having Tapestry committer status means you can apply patches, but not develop new functionality in core, which I would expect from Tapestry committer when voting for him. No the problem is committers who are not committing. Tapestry is specifically designed so that it can support a wide number of committers with different skill sets: you don't have to be a bytecode wizard to make significant improvements to the code base. I know I'd appreciate the help! Any committer can work anywhere in the codebase. In case of conflicts we'll take a vote. But even if you tried, it's very hard to keep up with Howard with plain number of commits. You might be interested in fixing your pet peeve at some point but are you going to maintain interest in the project year over year and review other people's commits while working on your things? It's not that Howard is right all the time but by the time you've made your case on the list, he's already incorporated your feedback, refactored the code and added more tests. I've seen it happening multiple times. Most devs are pretty happy with the status quo, that somebody is doing the hard lifting for you or for them. We can see that most of tapestry5 development now is third party development which occurs on GitHub and other separate repositories, resulting in a tapestry-complement libraries, like tapestry5-jquery, tynamo, stitch, tapestry-bootstrap and many other wonderful projects. This is great, though, these projects stand aside from main tapestry development, and most of them appear outdated after new tapestry releases because they released separately from tapestry core. I wouldn't say most but a successful project always creates a lively ecosystem around it. Keeping your stuff in a support library separate from the core has its benefits as well as its drawbacks. A smaller, independent library can evolve much faster but as each of them is implemented for a specific purpose, they'll typically drag behind and don't always support the latest and greatest core release. Also, the bar for bringing in your stuff to tapestry core is way higher than your typical run-of-the-mill github project. As a co-founder and author of multiple Tynamo libraries I can honestly say there's a reason why only one of the tynamo libraries have graduated to tapestry core so far. I'd really like to see more developers of those libraries as Tapestry committers so that they can support their own 3rd party libraries compatibilities as a part of main tapestry development, and may be hold tapestry core releases until all those libraries are up-to-date with new tapestry release. For most libraries, that's just not the right path. Being in the core doesn't automatically mean they'd be somehow more supported. There needs to be a general interest in a specific piece of code before it makes sense to bring it to the core. If there's only one maintainer supporting the library, it is far easier to maintain it outside the core, without having to deal with the sheer size of the core, the unstability that other changes cause, random test failures etc. The great thing about open source is that in any given project, it's pretty easy to pick up the maintenance duties and start sending sending patches if you want a library you care about to be updated. Before you know it, you'll be the committer (and surprisingly often, the only maintainer as well), with others asking you to start doing stuff for them. Kalle
Re: [VOTE] Lance Semmens as a committer
Dmitry Gusev: +1 (non-binding) I like seeing that new Tapestry committers appear, but looking at git logs I see that (almost) the only core committer is Howard. Other committers do some rare, though valuable, fixes and apply patches from JIRA. From this point of view, it appears to me that having Tapestry committer status means you can apply patches, but not develop new functionality in core, which I would expect from Tapestry committer when voting for him. We can see that most of tapestry5 development now is third party development which occurs on GitHub and other separate repositories, resulting in a tapestry-complement libraries, like tapestry5-jquery, tynamo, stitch, tapestry-bootstrap and many other wonderful projects. This is great, though, these projects stand aside from main tapestry development, and most of them appear outdated after new tapestry releases because they released separately from tapestry core. I'd really like to see more developers of those libraries as Tapestry committers so that they can support their own 3rd party libraries compatibilities as a part of main tapestry development, and may be hold tapestry core releases until all those libraries are up-to-date with new tapestry release. Not sure if this is the right place to ask, we can create a separate thread for this, but Lance, can you tell us what are you planning to do as a Tapestry committer? Is there any roadmap that you will follow? On Wed, Jul 3, 2013 at 11:43 PM, Kalle Korhonen kalle.o.korho...@gmail.comwrote: Lance Semmens (aka Lance Java) has been one of the most active members on the user list for the past two years. I've personally committed a few patches from him and he is the maintainer of tapestry-stitch ( https://github.com/uklance/tapestry-stitch/), a collection of sample components and concepts for Tapestry 5. Howard has spoke with him privately and he's interested in joining as a committer. Vote to run for a minimum of three days. Kalle Korhonen: +1 (non-binding) -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: jQuery 2.x or stick with 1.x?
If understand it right jQuery 2.0 won't support IE 9. It'd be great if it would be possible to easily enable jQuery 1.9.x for IE 9... maybe should embed both versions? By the way, if I understand it right again, that if one want to support both IE 9 and IE = 9 should declare jQuery like this: !--[if lt IE 9] script src=jquery-1.9.0.js/script ![endif]-- !--[if gte IE 9]!-- script src=jquery-2.0.0.js/script !--![endif]-- How will this work with JS stacks? On Sun, May 26, 2013 at 7:58 PM, Howard Lewis Ship hls...@gmail.com wrote: What do people think about moving the embedded jQuery library up to the 2.x version? I would tend to favor the idea, given that anyone who truly cares can switch it back. -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry Release 5.3.7
Dmitry Gusev: +0 (non-binding) On Wed, Apr 24, 2013 at 11:55 AM, Massimo Lusetti mluse...@gmail.comwrote: I've created and uploaded a release of Tapestry 5.3.7, ready to be voted upon. The source and source downloads are uploaded to: http://people.apache.org/~mlusetti/tapestry-releases/ and the Maven artifacts staged to: https://repository.apache.org/content/repositories/orgapachetapestry-133/ Please examine these files to determine if the new release, 5.3.7, is ready. I've also created a 5.3.7 tag in Git: https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=shortlog;h=refs/tags/5.3.7 Release notes page has been updated too. Vote will run for three days; On a successful vote, I'll release the Maven artifacts, and move the source and javadoc distributions from these directories to the proper distribution directories and update the Tapestry site documentation, and send out appropriate notifications. Massimo Lusetti: +1 (binding) -- Massimo -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: T5.3.7 release anyone?
I hope its not too late for 5.3.7 Can somebody review and apply the patch and test from https://issues.apache.org/jira/browse/TAP5-2107 please? Its really a tiny, but valuable improvement for me. On Mon, Apr 15, 2013 at 5:30 PM, Kalle Korhonen kalle.o.korho...@gmail.comwrote: Spent the better part of my Saturday to get the test suite going again with the latest FF on the 5.3 branch. Resolving the actual issues was easy and I don't have anything else to add to 5.3.7 at this point. There are a few test failures but I don't think I added any. I'll be testing 5.3.7 locally against a live application today, and then it's all yours Massimo. Kalle On Tue, Apr 9, 2013 at 8:37 AM, Kalle Korhonen kalle.o.korho...@gmail.comwrote: Massimo thanks! Next week please - I'm putting a few easy ones in still, actually have some real time carved out for that this week. Kalle On Tue, Apr 9, 2013 at 2:13 AM, Massimo Lusetti mluse...@gmail.com wrote: I'm going to give a whirl to the release process in the next days (maybe early next week) ... On Tue, Apr 2, 2013 at 8:43 PM, Luca Menegus luca.mene...@dbmsrl.com wrote: ... TAP5-2101 got it's first vote on jira ;) (I'll stop spamming dev right now) - Original Message - From: Luca Menegus luca.mene...@dbmsrl.com To: Tapestry development dev@tapestry.apache.org Sent: Tuesday, April 2, 2013 8:14:20 PM Subject: Re: T5.3.7 release anyone? Done TAP5-2101, thank very much to anybody taking time to review it, regards, luca [1] https://issues.apache.org/jira/browse/TAP5-2101 - Original Message - From: Kalle Korhonen kalle.o.korho...@gmail.com To: Tapestry development dev@tapestry.apache.org Sent: Tuesday, April 2, 2013 6:28:50 PM Subject: Re: T5.3.7 release anyone? Open an issue to get that in and refer to it here. I'm pretty sure that there's no hope to get an issue fixed for T5.3.7 at this point unless a committer is already working on it or there's a clean patch with a test on it. Kalle On Tue, Apr 2, 2013 at 9:11 AM, Luca Menegus luca.mene...@dbmsrl.comwrote: Hi all, do you think somebody has the time to look our problem with tapestry-beanvalidation? http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/BeanEditor-should-always-provide-a-new-BeanValidationContext-JSR-303-td5713975.html#a5714049 At the moment even: t:form validate=this t:BeanEditor object=beanA / t:BeanEditor object= beanB / t:form/ Is not (bean)validating properly In the original message i provided a patch (with test case). If anybody is interest in fixing this issue I'm ready to create a ticket, re-post the patch do whatever is needed to get it upstream Thanks, Luca - Original Message - From: Kalle Korhonen kalle.o.korho...@gmail.com To: Tapestry development dev@tapestry.apache.org Sent: Sunday, March 31, 2013 8:17:51 AM Subject: T5.3.7 release anyone? Is anybody in need of T5.3.7? I'm not quite ready myself just yet but there are a few relevant fixes for us and I could put a few more in. Is anybody else looking for a 5.3.7 release? Massimo, I think you've done the last 5.3.x releases. How's your experience been regarding the release process? Is everything documented, any gotchas, pain points etc? Or would you perhaps be willing to cut one more release yourself? Kalle - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Massimo http://meridio.blogspot.com -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: T5.3.7 release anyone?
The behavior wasn't changed, its just in previous versions shutdown was made from java.lang.Runnable wrapper which is now direct call to ServletContainerRunner.stop() I've added private field that holds reference to ServletContainerRunner instance so that I can get ServletContext from it, and I use this field's values in shutdown logic, so its basically the same. I could leave it as before but in this case we would hold two different references in different places to the same ServletContainerRunner object. On Wed, Apr 17, 2013 at 11:55 AM, Massimo Lusetti mluse...@gmail.comwrote: On Wed, Apr 17, 2013 at 9:13 AM, Dmitry Gusev dmitry.gu...@gmail.com wrote: I hope its not too late for 5.3.7 Can somebody review and apply the patch and test from https://issues.apache.org/jira/browse/TAP5-2107 please? Its really a tiny, but valuable improvement for me. Hi Dimitry, I've just scrolled down at your patch but it seems it slightly change the behavior of SeleniumTestCase during the shutdown phase, am I right? -- Massimo -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: T5.3.7 release anyone?
Massimo, you made me think it may not work as expected with multiple threads. Not sure if its possible to launch multiple containers simultaneously though, but if its possible this will not work as expected. I will check this. On Wed, Apr 17, 2013 at 12:00 PM, Dmitry Gusev dmitry.gu...@gmail.comwrote: The behavior wasn't changed, its just in previous versions shutdown was made from java.lang.Runnable wrapper which is now direct call to ServletContainerRunner.stop() I've added private field that holds reference to ServletContainerRunner instance so that I can get ServletContext from it, and I use this field's values in shutdown logic, so its basically the same. I could leave it as before but in this case we would hold two different references in different places to the same ServletContainerRunner object. On Wed, Apr 17, 2013 at 11:55 AM, Massimo Lusetti mluse...@gmail.comwrote: On Wed, Apr 17, 2013 at 9:13 AM, Dmitry Gusev dmitry.gu...@gmail.com wrote: I hope its not too late for 5.3.7 Can somebody review and apply the patch and test from https://issues.apache.org/jira/browse/TAP5-2107 please? Its really a tiny, but valuable improvement for me. Hi Dimitry, I've just scrolled down at your patch but it seems it slightly change the behavior of SeleniumTestCase during the shutdown phase, am I right? -- Massimo -- Dmitry Gusev AnjLab Team http://anjlab.com -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: T5.3.7 release anyone?
It was working ok, but I still updated the patch and moved servlet container runner instance reference from private field to ITestContext attribute. Should be fine now. On Wed, Apr 17, 2013 at 12:05 PM, Dmitry Gusev dmitry.gu...@gmail.comwrote: Massimo, you made me think it may not work as expected with multiple threads. Not sure if its possible to launch multiple containers simultaneously though, but if its possible this will not work as expected. I will check this. On Wed, Apr 17, 2013 at 12:00 PM, Dmitry Gusev dmitry.gu...@gmail.comwrote: The behavior wasn't changed, its just in previous versions shutdown was made from java.lang.Runnable wrapper which is now direct call to ServletContainerRunner.stop() I've added private field that holds reference to ServletContainerRunner instance so that I can get ServletContext from it, and I use this field's values in shutdown logic, so its basically the same. I could leave it as before but in this case we would hold two different references in different places to the same ServletContainerRunner object. On Wed, Apr 17, 2013 at 11:55 AM, Massimo Lusetti mluse...@gmail.comwrote: On Wed, Apr 17, 2013 at 9:13 AM, Dmitry Gusev dmitry.gu...@gmail.com wrote: I hope its not too late for 5.3.7 Can somebody review and apply the patch and test from https://issues.apache.org/jira/browse/TAP5-2107 please? Its really a tiny, but valuable improvement for me. Hi Dimitry, I've just scrolled down at your patch but it seems it slightly change the behavior of SeleniumTestCase during the shutdown phase, am I right? -- Massimo -- Dmitry Gusev AnjLab Team http://anjlab.com -- Dmitry Gusev AnjLab Team http://anjlab.com -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Coming soon: per-Asset checkums in URLs
I agree with Bob, isn't the whole idea of asset checksums and far-future expire headers was to reduce number of HTTP requests? Whats the advantage of ETags then? I bet the majority of assets for which HTTP 304 Not Modified would be returned would weight pretty much the same (in bytes) as returned 304 response. I'd normally use Etag when I had to implement some transactional state in some REST conversation. Keep in mind that, for instance, on AppEngine (or name any other cloud provider) such request could cost much more that just returning 304 -- AppEngine could start a new instance of application to serve this request. So I think for assets the main goal is reducing number of requests, but not optimizing the payload. Btw, I've generally assumed that URLs with query parameters are less likely to be cached in the browser, or served properly by intermediate (reverse proxy) servers, but I haven't done the research. I noticed you've integrated checksums into the path of URL, not as GET parameters... Do you have any reason for this? Done any research? Because I'm seeing this pattern with GET parameters is widely abopted on the web and it works good. On Tue, Apr 9, 2013 at 5:43 AM, Bob Harner bobhar...@gmail.com wrote: Doesn't the switch to ETags for modules make for much chattier web apps, with lots more conditional GET requests for JS modules coming in after every page request? In any case, good riddance to the application version numbers. On Mon, Apr 8, 2013 at 9:10 PM, Howard Lewis Ship hls...@gmail.com wrote: With the ETag support in place, there's no longer any need for the module asset URLs to have a checksum or version number; they are no longer given a far-future expires header. URLs (by default) look like /modules/t5/core/dom.js (where the module name is t5/core/dom). The application version number is no longer used in any URLs; it now exists just for documentation purposes (its written to the console at startup and in the exception report). This is good news, because you could screw yourself by deploying your application and NOT changing the version number (in 5.3.6). Very happy about this ... next up, thoughts on cometd/server-push support? On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship hls...@gmail.com wrote: On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev dmitry.gu...@gmail.com wrote: On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship hls...@gmail.com wrote: I've been working, a few hours a week, on getting per-asset checksums into URLs. Some parts of this have been a challenge to accomplish without completely breaking the Asset interface and a bunch of public services. For ordinary assets, it's pretty easy ... but for aggregated JavaScript libraries its been a pain that's affected a bunch of stuff. CSS files are now rewritten, since relative URLs will be broken by the addition of the checksum. I have a first (but not final) pass at this, where url() patterns in the CSS are converted into complete paths. This also opens the door to CSS aggregation as well as JavaScript aggregation. It depends on where you put the checksum. If you put it as a GET parameter - then no relative URLs will be broken. Have you read my blog post about Tapestry5 checksums in assets? http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html I'll read this shortly. I've generally assumed that URLs with query parameters are less likely to be cached in the browser, or served properly by intermediate (reverse proxy) servers, but I haven't done the research. I still don't have a great solution for JavaScript modules; RequireJS/AMD expect that there's a common root folder name (such as /assets/modules/), and module a/b is simply *root*/a/b.js. For individual modules, you can write your own overrides. In fact, Tapestry has to strip off the .js' part (which is hard-wired by RequireJS) because the actual server-side resource could be CoffeeScript or some other language that compiles to JavaScript. Short of iterating all server-side module files and writing a RequireJS config for each one (mapping each name to a URL with an embedded checksum), there isn't a great solution. Alternately, something could iterate all the server-side modules and built a composite checksum, but there are at least a couple of virtual modules generated at runtime (and locale specific for extra kicks). Modules may have to stay on the 5.3 approach: using the application version number for everything. Finding the sweet spot where assets of all kinds (CSS, JavaScript libraries, JavaScript modules, etc.) can be changed freely and the URLs automatically reflect the actual content (that is, include
Re: Coming soon: per-Asset checkums in URLs
On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship hls...@gmail.comwrote: I've been working, a few hours a week, on getting per-asset checksums into URLs. Some parts of this have been a challenge to accomplish without completely breaking the Asset interface and a bunch of public services. For ordinary assets, it's pretty easy ... but for aggregated JavaScript libraries its been a pain that's affected a bunch of stuff. CSS files are now rewritten, since relative URLs will be broken by the addition of the checksum. I have a first (but not final) pass at this, where url() patterns in the CSS are converted into complete paths. This also opens the door to CSS aggregation as well as JavaScript aggregation. It depends on where you put the checksum. If you put it as a GET parameter - then no relative URLs will be broken. Have you read my blog post about Tapestry5 checksums in assets? http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html I still don't have a great solution for JavaScript modules; RequireJS/AMD expect that there's a common root folder name (such as /assets/modules/), and module a/b is simply *root*/a/b.js. For individual modules, you can write your own overrides. In fact, Tapestry has to strip off the .js' part (which is hard-wired by RequireJS) because the actual server-side resource could be CoffeeScript or some other language that compiles to JavaScript. Short of iterating all server-side module files and writing a RequireJS config for each one (mapping each name to a URL with an embedded checksum), there isn't a great solution. Alternately, something could iterate all the server-side modules and built a composite checksum, but there are at least a couple of virtual modules generated at runtime (and locale specific for extra kicks). Modules may have to stay on the 5.3 approach: using the application version number for everything. Finding the sweet spot where assets of all kinds (CSS, JavaScript libraries, JavaScript modules, etc.) can be changed freely and the URLs automatically reflect the actual content (that is, include a checksum of that content) for ideal client-side caching ... may simply be out of reach. Perhaps for modules we should use an alternate approach based on ETags ( http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there would not need to be any version number of checksum in a module URL, but clients would request the module content more often (and based on ETag, would often get a 304 Not Modified). I would prefer to see a URL that changes when the content changes (which prevents the request entirely). -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.3.6
Dmitry Gusev: +1 (non-binding) On Tue, Oct 9, 2012 at 9:33 PM, Howard Lewis Ship hls...@gmail.com wrote: I've created and uploaded a release of Tapestry 5.3.6, ready to be voted upon. The source and source downloads are uploaded to: http://people.apache.org/~hlship/tapestry-releases/ and the Maven artifacts staged to: https://repository.apache.org/content/repositories/orgapachetapestry-113/ Please examine these files to determine if the new release, 5.3.6, is ready. I've also created a 5.3.6 tag in Git: https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=5c777afe5a99399290de8f7b56d69ca5e46c7e67 Vote will run for three days; On a successful vote, I'll release the Maven artifacts, and move the source and javadoc distributions from these directories to the proper distribution directories and update the Tapestry site documentation, and send out appropriate notifications. ** Bug * [TAP5-986] - A request can fail with an NPE in some cases, when a Tapestry page is acting as the servlet container error page * [TAP5-1735] - Most packages lack package-level javadocs * [TAP5-1903] - Client-side exception when a Zone containing a Form with an Upload component is re-rendered * [TAP5-2008] - Serialized object data stored on the client should be HMAC signed and validated * [TAP5-2009] - Downgrade bundled Prototype version back to 1.7 * [TAP5-2010] - Broken links in Javadoc pages ** Improvement * [TAP5-1996] - Add Severity.SUCCESS enum for alerts Howard M. Lewis Ship: +1 (binding) -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: HMAC signatures
Can't we just use application version by default? On Fri, Oct 5, 2012 at 11:22 AM, Ulrich Stärk u...@spielviel.de wrote: On 05.10.2012 00:22, Howard Lewis Ship wrote: On Thu, Oct 4, 2012 at 3:18 PM, Massimo Lusetti mluse...@gmail.com wrote: On Thu, Oct 4, 2012 at 9:04 PM, Howard Lewis Ship hls...@gmail.com wrote: Users will want to configure their private pass phrase using a newly defined symbol. If left unconfigured, there will be a runtime error logged (not an exception, just an error to encourage users to select a private pass phrase). Why not generate a random string if not supplied. Doesn't it work better then the DEFAULT string? That would not work in a cluster; different servers in the cluster would not be able to read each other's streams. Yes, usually, its based on sticky sessions, but even then, there's fail-over to consider. Also, a server restart would not only lose client sessions, but would generate a new random key, so any forms would become unsubmittable even if they did not depend on server-side session state. We could store a randomly generated key in the session for those requests where a session exists. If none exists use the default. I know, we are trying to store as little as possible inside the session, but the few bytes of the key shouldn't be a problem. Uli - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: HMAC signatures
I know, but isn't other default (non-random) value would be a priori known? Random value isn't good for cluster deployments, as was already mentioned before. So by default the HMAC signature wouldn't be much secure (if key equals to default), but at least it will work in cluster the same way as assets do (using application version). If you want more secure signatures you may specify passphrase explicitly also. On Fri, Oct 5, 2012 at 1:57 PM, Massimo Lusetti mluse...@gmail.com wrote: On Fri, Oct 5, 2012 at 9:35 AM, Dmitry Gusev dmitry.gu...@gmail.com wrote: Can't we just use application version by default? The whole point here is to protect against tampered data, so a known value is useless. Cheers -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Patch for TAP5-1996
Hi, Can somebody please review and apply the patch for https://issues.apache.org/jira/browse/TAP5-1996 ? I'd really like it to be in 5.3.6 to use it in new tapestry-bootstrap release. -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Massimo Lusetti as PMC member
Dmitry Gusev: +1 (non-binding) On Mon, Aug 20, 2012 at 10:30 PM, Howard Lewis Ship hls...@gmail.comwrote: Massimo has clearly demonstrated all the requirements for being a PMC member, and then some: he has been contributing code, bug fixes, and documentation; he has been actively mentoring users on the mailing list; andhe has been evangelizing Tapestry outside of Apache. I think its high time we added him to the PMC. Howard M. Lewis Ship: +1 (binding) -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Apache Tapestry 5.3.4
you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Apache Tapestry 5.3.4
Dmitry Gusev: +1 (non-binding) On Wed, Jul 4, 2012 at 7:15 PM, Igor Drobiazko igor.drobia...@gmail.comwrote: Igor Drobiazko: +1 (binding) On Tue, Jul 3, 2012 at 6:34 PM, Howard Lewis Ship hls...@gmail.com wrote: I've created and uploaded a release of Tapestry 5.3.4, ready to be voted upon. The source and source downloads are uploaded to: http://people.apache.org/~hlship/tapestry-releases/ and the Maven artifacts staged to: https://repository.apache.org/content/repositories/orgapachetapestry-021/ Please examine these files to determine if the new release, 5.3.4, is ready. I've also created a 5.3.4 tag in Git: https://git-wip-us.apache.org/repos/asf/tapestry-5/repo?p=tapestry-5.git;a=commit;h=8ca386898dd0d61582da02088624f0f399045cad Vote will run for three days; On a successful vote, I'll release the Maven artifacts, and move the source and javadoc distributions from these directories to the proper distribution directories and update the Tapestry site documentation, and send out appropriate notifications. -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Best regards, Igor Drobiazko http://tapestry5.de http://twitter.com/drobiazko -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Release 5.3.3
Igor, I've attached new patch with a test case. Can you look at it, please? On Wed, Apr 18, 2012 at 11:30, Igor Drobiazko igor.drobia...@gmail.comwrote: Well, I wouldn't say I don't care. As Kalle already said, if this is a blocker for you, you should draw committer's attention here on the list, if you feel that your issue is forgotten. BTW did I mention already that providing tests in a patch increases the probability of the patch to be applied? On Wed, Apr 18, 2012 at 7:52 AM, Dmitry Gusev dmitry.gu...@gmail.com wrote: Dmitry Gusev: -1 (non-binding) I'd like to see this issue resolved in 5.3.3: https://issues.apache.org/jira/browse/TAP5-1848 This is a blocker for deploying Tap5 applications to GAE. I've submitted a patch two months ago and I don't understand why its not resolved yet. I know Igor implemented JPA support in Tap5, and he knows about the issue and the patch, and looks like he doesn't care. This makes me very disappointed. On Wed, Apr 18, 2012 at 09:24, Kalle Korhonen kalle.o.korho...@gmail.com wrote: +1 Kalle Korhonen (non-binding) We should also link to the release notes, 5.3.3 at https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310833version=12320045 My vote's tentative so far, I just run 5.3.3 against two of my current projects so far without problems, will run more tests and change if anything comes up. Kalle On Tue, Apr 17, 2012 at 7:44 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: Thiago H. de Paula Figueredo: +1 (binding) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com -- Best regards, Igor Drobiazko http://tapestry5.de http://twitter.com/drobiazko -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Release 5.3.3
Forget to mention, the patch is against the trunk. But I guess it should be easy to back port it to 5.3.2. On Fri, Apr 20, 2012 at 17:47, Dmitry Gusev dmitry.gu...@gmail.com wrote: Igor, I've attached new patch with a test case. Can you look at it, please? On Wed, Apr 18, 2012 at 11:30, Igor Drobiazko igor.drobia...@gmail.comwrote: Well, I wouldn't say I don't care. As Kalle already said, if this is a blocker for you, you should draw committer's attention here on the list, if you feel that your issue is forgotten. BTW did I mention already that providing tests in a patch increases the probability of the patch to be applied? On Wed, Apr 18, 2012 at 7:52 AM, Dmitry Gusev dmitry.gu...@gmail.com wrote: Dmitry Gusev: -1 (non-binding) I'd like to see this issue resolved in 5.3.3: https://issues.apache.org/jira/browse/TAP5-1848 This is a blocker for deploying Tap5 applications to GAE. I've submitted a patch two months ago and I don't understand why its not resolved yet. I know Igor implemented JPA support in Tap5, and he knows about the issue and the patch, and looks like he doesn't care. This makes me very disappointed. On Wed, Apr 18, 2012 at 09:24, Kalle Korhonen kalle.o.korho...@gmail.com wrote: +1 Kalle Korhonen (non-binding) We should also link to the release notes, 5.3.3 at https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310833version=12320045 My vote's tentative so far, I just run 5.3.3 against two of my current projects so far without problems, will run more tests and change if anything comes up. Kalle On Tue, Apr 17, 2012 at 7:44 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: Thiago H. de Paula Figueredo: +1 (binding) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com -- Best regards, Igor Drobiazko http://tapestry5.de http://twitter.com/drobiazko -- Dmitry Gusev AnjLab Team http://anjlab.com -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Release 5.3.3
Kalle, thanks for your reply. As I understood from Howard's report and release notes -- 5.3.3 is a bug fix release, and what I suggested is just a small bugfix. I don't know if there will be more bug fix releases in version 5.3, so I think this is the best time to implement the fix. I'm still remember the pain I have during upgrade to 5.3 and I just want one issue less during upgrade to 5.4. Anyway, my vote is non-binding, so it won't block the release somehow and it doesn't mean anything more that a noise on the list. On Wed, Apr 18, 2012 at 10:19, Kalle Korhonen kalle.o.korho...@gmail.comwrote: Dmitry, I feel your pain but this doesn't seem to be a 5.3.3 specific issue. You really want to block 5.3.3 release because of this? It's logged against 5.3.2 but it's not a regression, rather it affects the core jpa implementation as a whole, right? I should have reacted to it, my apologies. In the future, the way to get the issue dear to you resolved is to make even more noise on the list. Kalle On Tue, Apr 17, 2012 at 10:52 PM, Dmitry Gusev dmitry.gu...@gmail.com wrote: Dmitry Gusev: -1 (non-binding) I'd like to see this issue resolved in 5.3.3: https://issues.apache.org/jira/browse/TAP5-1848 This is a blocker for deploying Tap5 applications to GAE. I've submitted a patch two months ago and I don't understand why its not resolved yet. I know Igor implemented JPA support in Tap5, and he knows about the issue and the patch, and looks like he doesn't care. This makes me very disappointed. On Wed, Apr 18, 2012 at 09:24, Kalle Korhonen kalle.o.korho...@gmail.comwrote: +1 Kalle Korhonen (non-binding) We should also link to the release notes, 5.3.3 at https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310833version=12320045 My vote's tentative so far, I just run 5.3.3 against two of my current projects so far without problems, will run more tests and change if anything comes up. Kalle On Tue, Apr 17, 2012 at 7:44 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: Thiago H. de Paula Figueredo: +1 (binding) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Release 5.3.3
Dmitry Gusev: -1 (non-binding) I'd like to see this issue resolved in 5.3.3: https://issues.apache.org/jira/browse/TAP5-1848 This is a blocker for deploying Tap5 applications to GAE. I've submitted a patch two months ago and I don't understand why its not resolved yet. I know Igor implemented JPA support in Tap5, and he knows about the issue and the patch, and looks like he doesn't care. This makes me very disappointed. On Wed, Apr 18, 2012 at 09:24, Kalle Korhonen kalle.o.korho...@gmail.comwrote: +1 Kalle Korhonen (non-binding) We should also link to the release notes, 5.3.3 at https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310833version=12320045 My vote's tentative so far, I just run 5.3.3 against two of my current projects so far without problems, will run more tests and change if anything comes up. Kalle On Tue, Apr 17, 2012 at 7:44 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: Thiago H. de Paula Figueredo: +1 (binding) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [jira] [Commented] (TAP5-1880) GZip compression should be disabled if the request is over http 1.0
Maybe this is related to https://issues.apache.org/jira/browse/TAP5-1868 somehow? On Fri, Mar 23, 2012 at 12:28, Massimo Lusetti mluse...@gmail.com wrote: On Thu, Mar 22, 2012 at 7:22 PM, Bob Harner bobhar...@gmail.com wrote: Just a guess, haven't tried it, but couldn't you check for request.getHeader(Accept-Encoding) containing gzip ? Or maybe I'm misunderstanding the problem. I guess that's exactly the issue. IE does announce accept-encoding gzip but fails afterward -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
tapestry-jpa ignores persistence provider from persistence.xml
Can somebody please look at the issue and the patch provided? https://issues.apache.org/jira/browse/TAP5-1848 One more question. When there was tynamo-jpa, I was able to implement lazy transactions, that is if request doesn't do any DB queries, EM didn't opened the transaction (and didn't rolled it back at the end of the request). How can I do this with new tapestry-jpa? What service should I override? -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Need feedback for Eclipse WTP based Tapestry 5 visual editor
Looks good to me. And I also think that its not worth it to support Eclipse Classic for TapestryTools. One note on this though: Or we will supply two update sites, one for Eclipse JavaEE, the other includes XML editor jars for Eclipse classic. You shouldn't include XML editor to your update site. Just set it as prerequisite and your plug-in won't install until user resolve this dependency. Also, I believe, Eclipse has a feature of auto resolving dependencies, so maybe you should investigate this, just to make your update site light-weight. 2012/2/15 Gavin Lei gavingui2...@gmail.com Hi All, In our coming light-weight TapestryTools, If we want to supply autocomplete features, we must implement it in some special tml editor (In current version TapestryTools,we use WTP's jsp editor). Now, we want to remove Eclipse WTP dependencies, should find some other exist editors. After talking with my GSoC mentor Igor Drobiazko, we thought the most of tapestry users are using xml editor for tml files, and decided to hook Tapestry components' autocomplete features into XML Editor which is included in Eclipse JavaEE. As Eclipse classic does not include XML editor, it will require Eclipse for JEE developers as a minimum. If there is not XML editor in users' eclipse (or they are not using Eclipse Jave EE), people can not install this feature, but they can still other plugin which do not need XML editor. It means Eclipse classic users can have all the TapestryTools' features besides autocomplete things. Or we will supply two update sites, one for Eclipse JavaEE, the other includes XML editor jars for Eclipse classic. We will concentrate on simple and useful stuff first to confirm a minimal feature set that works perfect, then consider option functions. For example, if user have installed Eclipse Java EE, it means they have installed WTP already. I want to reconstruct current TapestryTools' code, supply Tapestry components' auto-complete feature in WTP jsp editor as an option function in the future. Once more, we are still in project proposal prepare and solution survey stage, hoping for more voices from Tapestry users and developers, if you have any advises, please let me know. Thank you. -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Need feedback for Eclipse WTP based Tapestry 5 visual editor
Hi, Gavin! Thats a big step forward. But, still, I think that a huge limitation of TapestryTools is that it can't be plugged-into existing Eclipse Java EE installation through the Help - Install New Software I wish this will be resolved in future releases. 2012/2/3 Gavin Lei gavingui2...@gmail.com Hi all, I built Eclipse WTP based Tapestry 5 visual editor - TapestryTools [1] as GSoC 2011 project. Now, we plan to improve this tool and keep it as a GSoC 2012 project, before we start real develop job, we need feedback from you guys. Welcome to hava a trial of it, this is the guide [2] about how to install it, and we also have a video about how to use this tool. If you have any advises about it or you need some new features, please let me know. Thank you. [1] http://code.google.com/p/tapestrytools/ [2] http://code.google.com/p/tapestrytools/wiki/TapestryTools_Install_Guide [3] http://tapestrytools.googlecode.com/files/tapestrytools.mov -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Eclipse WTP based Tapestry visual editor project update site
Hi, Gavin! FYI I've tried to install TapestryTools to my Eclipse Indigo JavaEE and it broken my Eclipse installation. I had to switch to fresh Eclipse install. I've created new issue here: http://code.google.com/p/tapestrytools/issues/detail?id=14 2011/8/29 Gavin Lei gavingui2...@gmail.com Hi Igor 在 2011年8月29日 下午5:04，Igor Drobiazko igor.drobia...@gmail.com 写道： Hi Gavin, installing the plugin into Eclipse Indigo JavaEE the way you described works. I can confirm that the components appear in the Palette. I can drag and drop components. Autocompletion seems to be broken. It works for most of Tapestry components, but it doesn't work for custom components. I will check this point soon Also page's class properties are not available in autocompletion. This is issue 8 problem(http://code.google.com/p/tapestrytools/issues/detail?id=8), we will fix it in the future 2011/8/27 Gavin Lei gavingui2...@gmail.com Hi Igor, I have tested this install way of TapestryTools in Mac OS, it really works well, you can find the whole install progress here [1], please check the TapestryTools screen in Mac OS in the attach file. [1] http://code.google.com/p/tapestrytools/wiki/TapestryTools_Install_Guide 在 2011年8月26日 下午11:55，Gavin Lei gavingui2...@gmail.com 写道： Hi all, Now you can install TapestryTools in Eclipse JavaEE, it is simple, please check the install guide here[1]. Now we have two ways to install TapestryTools, part 1.1.1 Install TapestryTools in Eclipse Indigo JavaEE in the document described how to install TapestryTools in Eclipse JavaEE. I tried it already, it works for me in Win 7. Waiting for your feedbacks, thank you. [1] http://code.google.com/p/tapestrytools/wiki/TapestryTools_Install_Guide 在 2011年8月24日 上午1:44，Dmitry Gusev dmitry.gu...@gmail.com 写道： Gavin, having TapestryTools not working in Eclipse Indigo of JavaEE developer is a sad limitation. Are there any plans to support it in the future? 2011/8/23 Gavin Lei gavingui2...@gmail.com Hi Igor, Please notice that you should *not* use Eclipse Indigo for JavaEE developer,please just use Eclipse Indigo Classic[1]. And then install the basic tools in my guide, after that, install TapestryTools. You can find the step-by-step install document here[2]. I will explain the reason, why you should not use Eclipse Indigo for JavaEE developer, as you know, TapestryTools is developed based on Eclipes WTP, there are two parts of job: 1. Add some new Eclipse plugin projects, such as org.eclipse.jst.tapestry.ui 2. Modify WTP's source code directory (very little, usually just add some entry points), for example, modify project org.eclipse.jst.jsf.core source code So TapestryTools is just a more powerful Eclipse WTP, if you use Eclipse for JavaEE developers which includes Eclipse WTP, then you try to install TapestryTools, Eclipse will find out that there are already many projects(for example org.eclipse.jst.jsf.core) in it, it will not updated this plugin with same name includes in TapestryTools, so you will miss some features of TapestryTools. So keep in mind that please just use Eclipse Classic :-) [1] http://www.eclipse.org/downloads/packages/eclipse-classic-37/indigor [2] http://code.google.com/p/tapestrytools/wiki/TapestryTools_Install_Guide 在 2011年8月23日 下午9:42，Igor Drobiazko igor.drobia...@gmail.com 写道： Hi Gavin, I installed TapestryTools into Eclipse IDE for Java EE Developers [1]. I think this is all-in-one package and should contain all the required plugins. Unfortunately I'm experiencing problems which I reported to you in a Skype chat. After installing the mentioned plugins manually, the problem with missing components in the palette still exists. Can you please install [1] om your machine and reproduce the problem? [1] http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/indigor Thank you 2011/8/22 Gavin Lei gavingui2...@gmail.com Hi guys, Important Notice: Before you install TapestryTools in Eclipse Indigo to have a trial of it, you should install these three basic tools first: 1. EMF and XSD SDK Combined EMF and EMF-XSD SDK 2.GEF SDK 3.7 (GEF Code and Source) 3. DTP sdk v1.9 (Code and Source) You guys can find the install guide documents here[1], and the download urls for these plugins is here[2], this step is very important, or your TapestryTools can not work properly, please keep it in mind, thank you :-) [1] http://code.google.com/p/tapestrytools/wiki/TapestryTools_Install_Guide [2] http://download.eclipse.org/webtools/downloads/drops/R3.3.0/R-3.3.0-20110607160810/ 在 2011年8月21日 下午7:54，Gavin Lei gavingui2...@gmail.com 写道： Hi
Re: Eclipse WTP based Tapestry visual editor project update site
/tapestrytools/wiki/GSoC_Project_MidTerm_Evolution 2011/7/7 Dmitry Gusev dmitry.gu...@gmail.com: Hi, is there any plans to support Eclipse Indigo? 2011/7/7 Gavin Lei gavingui2...@gmail.com Hi All, TapestryTools finish development job of features 5. Add convenient way for the Web Page Editor to change-over between a Tapestry page's .tml file and .java file AND 6. Add Tapestry built in and custom components autocomplete function for WTP Web Page Editor's source view in project proposal [1]. You guys can check details here[2], i have updated TapestryTools update center and you guys can hava a trial of it. To Igor, This is current status of TapestryTools [3], a simple a document for GSoC's midterm evalution :-) [1] http://code.google.com/p/tapestrytools/ [2] http://code.google.com/p/tapestrytools/wiki/Partner_location_and_content_assist_helper [3] http://code.google.com/p/tapestrytools/wiki/GSoC_Project_MidTerm_Evolution 在 2011年6月22日 下午9:10，Gavin Lei gavingui2...@gmail.com 写道： Hi All, New version of Visual Tapestry tools are published, please have a trial of it. This version fixed these two issues: [1] http://code.google.com/p/tapestrytools/issues/detail?id=1can=1 [2] http://code.google.com/p/tapestrytools/issues/detail?id=2can=1 We plan to publish a new version in the coming 2 weeks, which includes these two features in our project proposal [3]: 5. Add convenient way for the Web Page Editor to change-over between a Tapestry page's .tml file and .java file AND 6. Add Tapestry built in and custom components autocomplete function for WTP Web Page Editor's source view [3] http://code.google.com/p/tapestrytools/ Look forward for more feedbacks, thank you :-) 在 2011年6月5日 上午10:23，Gavin Lei gavingui2...@gmail.com 写道： Hi all, I have published a new trial version of this tapestry visual editor tool, it includes 2 more features in my project proposal [1] : 4. Add Tapestry component drap-and-drop feature support for .tml file editor 7.Tapestry component's parameters property view And the version fix 3 issues in issue list [2]: 1. Default template for Tapestry pages is wrong 2. Default template for components is broken 3. Improvements for the Create component dialog Its upate site is still http://tapestrytools.googlecode.com/svn/trunk/TapestryTools_UpdateSite/ , welcome for more feedbacks, thank you [1] http://code.google.com/p/tapestrytools/ [2] http://code.google.com/p/tapestrytools/issues/list 在 2011年5月27日 上午10:55，Gavin Lei gavingui2...@gmail.com 写道： And there is a simple guide here [2] about how to install this tool in Eclipse 3.6 successful :-) [2] http://code.google.com/p/tapestrytools/wiki/TapestryTools_Install_Guide 在 2011年5月27日 上午10:54，Gavin Lei gavingui2...@gmail.com 写道： Hi all, I have build a update site [1] for this project, if you are interested, you can have a trial of this tool as you wish, it has some basic functions, and i am still working for it. Currently, i am working for add Tapestry components into Web Page Editor's palette, it will help users to add Tapestry components in *.tml file by drag-and-drop components in palette. [1] http://tapestrytools.googlecode.com/svn/trunk/TapestryTools_UpdateSite/ -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com -- - Best
Re: Eclipse WTP based Tapestry visual editor project update site
/GSoC_Project_MidTerm_Evolution
[2] http://code.google.com/p/tapestrytools/issues/detail?id=6
[3] http://code.google.com/p/tapestrytools/issues/detail?id=10
[4] http://code.google.com/p/tapestrytools/issues/detail?id=8
在 2011年7月18日 下午9:11，Gavin Lei gavingui2...@gmail.com 写道：
Hi Igor,
This is my plan for the next period about the TapestryTools
development
job:
* 7.19 - 7.31:
3. Add MetaData? for Tapestry components in Web Page Editor's
palette
Add proper icons and text label for tapestry components to improve
their looking. These tapestry components are current ugly just use
default icons and default text.
AND
1.Validation function in Tapestry .tml file source view
Beyond the basic JSP validation already provided with the JSP
editor,
this editor supplies semantic validation of the Tapestry standard
tag
libraries for both EL and non-EL attribute values.
Details about these two features can be found here[1]
*8.1 - 8.7
Add Eclipse Indigo support for TapestryTools, check details here[2]
* 8.8 - 8.15
Fix Issue 10.Add application's custom components support for
TapestryTools palette, check details here[3]
* 8.16 - 8.30 and future
Fix Issue 8, this part is difficult, i have no idea how much time it
will cost, i will design a common implement framework, use XML
document to define components' parameters, TapestryTools will load
the
parameters for each component, add content assit for all the
Tapestry
components.
It have much possibility that i can not finished this feature in
GSoC's time period, but i will keep TapestryTools as a longterm open
source tools for Tapestry developers, keep improving this tool after
GSoC.
[1]
http://code.google.com/p/tapestrytools/wiki/GSoC_Project_MidTerm_Evolution
[2] http://code.google.com/p/tapestrytools/issues/detail?id=6
[3] http://code.google.com/p/tapestrytools/issues/detail?id=10
[4] http://code.google.com/p/tapestrytools/issues/detail?id=8
在 2011年7月17日 下午12:18，Gavin Lei gavingui2...@gmail.com 写道：
Hi all,
I have finished this feature implemention job for TapestryTools:
2. Autocomplete of properties from the .java page when editing the
.tml file
In the Source Page of the Web Page Editor, add the Tapestry tag,
(for
example ${prop:index}). With the cursor inside the brackets, hit
Ctrl+spacebar, should see a pop-up with a list of all the available
properties defined in the corresponding java class. Check details
here.
And i have updated the TapestryTools update center, you guys can
have
a trial of it
在 2011年7月8日 上午10:59，Gavin Lei gavingui2...@gmail.com 写道：
Yes, it is in my next stage plan here [3]
http://code.google.com/p/tapestrytools/wiki/GSoC_Project_MidTerm_Evolution
2011/7/7 Dmitry Gusev dmitry.gu...@gmail.com:
Hi,
is there any plans to support Eclipse Indigo?
2011/7/7 Gavin Lei gavingui2...@gmail.com
Hi All,
TapestryTools finish development job of features
5. Add convenient way for the Web Page Editor to change-over
between a
Tapestry page's .tml file and .java file
AND
6. Add Tapestry built in and custom components autocomplete
function
for WTP Web Page Editor's source view
in project proposal [1]. You guys can check details here[2], i
have
updated TapestryTools update center and you guys can hava a
trial
of
it.
To Igor,
This is current status of TapestryTools [3], a simple a document
for
GSoC's midterm evalution :-)
[1] http://code.google.com/p/tapestrytools/
[2]
http://code.google.com/p/tapestrytools/wiki/Partner_location_and_content_assist_helper
[3]
http://code.google.com/p/tapestrytools/wiki/GSoC_Project_MidTerm_Evolution
在 2011年6月22日 下午9:10，Gavin Lei gavingui2...@gmail.com 写道：
Hi All,
New version of Visual Tapestry tools are published, please
have a
trial of it. This version fixed these two issues:
[1]
http://code.google.com/p/tapestrytools/issues/detail?id=1can=1
[2]
http://code.google.com/p/tapestrytools/issues/detail?id=2can=1
We plan to publish a new version in the coming 2 weeks, which
includes
these two features in our project proposal [3]:
5. Add convenient way for the Web Page Editor to change-over
between a
Tapestry page's .tml file and .java file
AND
6. Add Tapestry built in and custom components autocomplete
function
for WTP Web Page Editor's source view
[3] http://code.google.com/p/tapestrytools/
Look forward for more feedbacks, thank you :-)
在 2011年6月5日 上午10:23，Gavin Lei gavingui2...@gmail.com 写道：
Hi all,
I have published a new trial version of this tapestry visual
editor
tool, it includes 2 more features in my project proposal [1]
:
4. Add Tapestry
Re: Eclipse WTP based Tapestry visual editor project update site
Hi, maybe this will help you to start: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Feditors%2Fmanifest_editor%2Fdependencies.htm 2011/8/23 Gavin Lei gavingui2...@gmail.com Hi Dmity, This is a good idea, but depending on Eclipse's plugin install mechanism, I can not find a solution to install the prerequisites automatically, i do not know how to do it now? I will search for the solution, if i have done it, i will post the result here. Thank you for your advise :-) 在 2011年8月23日 上午12:03，Dmitry Gusev dmitry.gu...@gmail.com 写道： Hi, Gavin! Why TapestryTools can't install them automatically? Or at least forbid install in case when these prerequisites are not yet installed? I thought this is common practice to do this and not rely on user's ability to do prerequisites management by hands. 2011/8/22 Gavin Lei gavingui2...@gmail.com Hi guys, Important Notice: Before you install TapestryTools in Eclipse Indigo to have a trial of it, you should install these three basic tools first: 1. EMF and XSD SDK Combined EMF and EMF-XSD SDK 2.GEF SDK 3.7 (GEF Code and Source) 3. DTP sdk v1.9 (Code and Source) You guys can find the install guide documents here[1], and the download urls for these plugins is here[2], this step is very important, or your TapestryTools can not work properly, please keep it in mind, thank you :-) [1] http://code.google.com/p/tapestrytools/wiki/TapestryTools_Install_Guide [2] http://download.eclipse.org/webtools/downloads/drops/R3.3.0/R-3.3.0-20110607160810/ 在 2011年8月21日 下午7:54，Gavin Lei gavingui2...@gmail.com 写道： Hi Igor, I have almost finished Issue 10[1] develoment job, users can configuration custom. After user choose custom components packages, and collect all the custom components, they will be available in Web Page Editor's palette, and also in *.tml's auto-complete list. I have submited the source code to SVN workspace,updated the update center[2], and i wrote a simple guide document[3] about this feature, you guys can have a trial of it. [1] http://code.google.com/p/tapestrytools/issues/detail?id=10 [2] http://tapestrytools.googlecode.com/svn/TapestryTools_UpdateSite/ [3] http://code.google.com/p/tapestrytools/wiki/Custom_Components_support_in_TapestryTools 在 2011年8月15日 下午2:52，Igor Drobiazko igor.drobia...@gmail.com 写道： Hi Gavin, if you are stuck with supporting Live Class Reloading, please go ahead with other features, such as issue 10. Maybe we could concentrate on Live Class Reloading after GSOC deadline. Thank you. 2011/8/13 Gavin Lei gavingui2...@gmail.com Hi Igor, In the schedule, we should focus on Live Class Reloading support for TapestryTools, but according to the survey job to Eclipse's WTP, we do not have a good solution to resolve this problem, May be we should not change WTP's running time module, it is just my personal idea. If you have any good advises, we can discuss it together. Now, As GSoC's deadline is coming, i think may be we should do some thing useful before the deadline, i will start the next feature in the schedule: All the available component should appear in the palette view [1] You added this issue, it is hard to finish this feature because it ask us to change Web Page Editor's palette's items loading module, we need at least 10 days to do it. So, i would like to start this part of job and finished it in GSoC's period. Is it OK ? Meanwhile, if you have any advises about Live Class Reloading things, please talk with me, we can make a plan or something, and then discuss when to start the Live Class Reloading job. [1] http://code.google.com/p/tapestrytools/issues/detail?id=10 在 2011年7月19日 下午3:50，Gavin Lei gavingui2...@gmail.com 写道： Hi there, As i missed the Live class reload feature in the last mail, so the new plan for the next period about the TapestryTools development job is: * 7.19 - 7.31: 3. Add MetaData? for Tapestry components in Web Page Editor's palette Add proper icons and text label for tapestry components to improve their looking. These tapestry components are current ugly just use default icons and default text. AND 1.Validation function in Tapestry .tml file source view Beyond the basic JSP validation already provided with the JSP editor, this editor supplies semantic validation of the Tapestry standard tag libraries for both EL and non-EL attribute values. Details about these two features can be found here[1] *8.1 - 8.7 Tapestry's built in Live Class Reloading support * 8.8 - 8.15 Add Eclipse Indigo support for TapestryTools, check details here[2] * 8.16 - 8.23 Fix Issue 10.Add application's
Re: [VOTE] Taha Hafeez as Tapestry Committer
Dmitry Gusev: +1 (non-binding) 2011/8/13 françois facon fra.fa...@gmail.com François Facon: +1 (non-binding) 2011/8/13 Andreas Andreou andre...@gmail.com: Andreas Andreou: +1 (binding) On Sat, Aug 13, 2011 at 14:42, Massimo Lusetti mluse...@gmail.com wrote: On Fri, Aug 12, 2011 at 7:45 PM, Howard Lewis Ship hls...@gmail.com wrote: Taha has been quite active over the last several months blogging, evangalizing, mentoring on the mailing list, and doing all the other things that committers are supposed to be doing, so I think it's high time we make it official. Vote to run for three days. Binding votes from PMC members only (but all are encouraged to show their opinion). Howard M. Lewis Ship: +1 (binding) Note: please use the format above for your vote ... it saves me a lot of work compiling the final tally. Massimo Lusetti: +1 (non-binding) Cheers -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr Apache Tapestry PMC / http://chesstu.be owner Open Source / JEE Consulting - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Eclipse WTP based Tapestry visual editor project update site
Hi, is there any plans to support Eclipse Indigo? 2011/7/7 Gavin Lei gavingui2...@gmail.com Hi All, TapestryTools finish development job of features 5. Add convenient way for the Web Page Editor to change-over between a Tapestry page's .tml file and .java file AND 6. Add Tapestry built in and custom components autocomplete function for WTP Web Page Editor's source view in project proposal [1]. You guys can check details here[2], i have updated TapestryTools update center and you guys can hava a trial of it. To Igor, This is current status of TapestryTools [3], a simple a document for GSoC's midterm evalution :-) [1] http://code.google.com/p/tapestrytools/ [2] http://code.google.com/p/tapestrytools/wiki/Partner_location_and_content_assist_helper [3] http://code.google.com/p/tapestrytools/wiki/GSoC_Project_MidTerm_Evolution 在 2011年6月22日 下午9:10，Gavin Lei gavingui2...@gmail.com 写道： Hi All, New version of Visual Tapestry tools are published, please have a trial of it. This version fixed these two issues: [1] http://code.google.com/p/tapestrytools/issues/detail?id=1can=1 [2] http://code.google.com/p/tapestrytools/issues/detail?id=2can=1 We plan to publish a new version in the coming 2 weeks, which includes these two features in our project proposal [3]: 5. Add convenient way for the Web Page Editor to change-over between a Tapestry page's .tml file and .java file AND 6. Add Tapestry built in and custom components autocomplete function for WTP Web Page Editor's source view [3] http://code.google.com/p/tapestrytools/ Look forward for more feedbacks, thank you :-) 在 2011年6月5日 上午10:23，Gavin Lei gavingui2...@gmail.com 写道： Hi all, I have published a new trial version of this tapestry visual editor tool, it includes 2 more features in my project proposal [1] : 4. Add Tapestry component drap-and-drop feature support for .tml file editor 7.Tapestry component's parameters property view And the version fix 3 issues in issue list [2]: 1. Default template for Tapestry pages is wrong 2. Default template for components is broken 3. Improvements for the Create component dialog Its upate site is still http://tapestrytools.googlecode.com/svn/trunk/TapestryTools_UpdateSite/ , welcome for more feedbacks, thank you [1] http://code.google.com/p/tapestrytools/ [2] http://code.google.com/p/tapestrytools/issues/list 在 2011年5月27日 上午10:55，Gavin Lei gavingui2...@gmail.com 写道： And there is a simple guide here [2] about how to install this tool in Eclipse 3.6 successful :-) [2] http://code.google.com/p/tapestrytools/wiki/TapestryTools_Install_Guide 在 2011年5月27日 上午10:54，Gavin Lei gavingui2...@gmail.com 写道： Hi all, I have build a update site [1] for this project, if you are interested, you can have a trial of this tool as you wish, it has some basic functions, and i am still working for it. Currently, i am working for add Tapestry components into Web Page Editor's palette, it will help users to add Tapestry components in *.tml file by drag-and-drop components in palette. [1] http://tapestrytools.googlecode.com/svn/trunk/TapestryTools_UpdateSite/ -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Massimo Lusetti as Tapestry Committer
Dmitry Gusev: +1 (non-binding) On Thu, Jun 30, 2011 at 03:03, Bob Harner bobhar...@gmail.com wrote: Bob Harner: +1 (non-binding) On Wed, Jun 29, 2011 at 6:45 PM, Andreas Andreou andre...@gmail.com wrote: Andreas Andreou: +1 (binding) On Thu, Jun 30, 2011 at 01:10, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: Thiago H. de Paula Figueiredo: +1 (binding). Yay! :) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr Apache Tapestry PMC / http://chesstu.be owner Open Source / JEE Consulting - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Eclipse WTP based Tapestry visual editor project update site
It would be nice to have Popup Menu items: Show Code in template editor and Show Template in page/component java code editor. 2011/6/22 Gavin Lei gavingui2...@gmail.com Hi All, New version of Visual Tapestry tools are published, please have a trial of it. This version fixed these two issues: [1] http://code.google.com/p/tapestrytools/issues/detail?id=1can=1 [2] http://code.google.com/p/tapestrytools/issues/detail?id=2can=1 We plan to publish a new version in the coming 2 weeks, which includes these two features in our project proposal [3]: 5. Add convenient way for the Web Page Editor to change-over between a Tapestry page's .tml file and .java file AND 6. Add Tapestry built in and custom components autocomplete function for WTP Web Page Editor's source view [3] http://code.google.com/p/tapestrytools/ Look forward for more feedbacks, thank you :-) 在 2011年6月5日 上午10:23，Gavin Lei gavingui2...@gmail.com 写道： Hi all, I have published a new trial version of this tapestry visual editor tool, it includes 2 more features in my project proposal [1] : 4. Add Tapestry component drap-and-drop feature support for .tml file editor 7.Tapestry component's parameters property view And the version fix 3 issues in issue list [2]: 1. Default template for Tapestry pages is wrong 2. Default template for components is broken 3. Improvements for the Create component dialog Its upate site is still http://tapestrytools.googlecode.com/svn/trunk/TapestryTools_UpdateSite/, welcome for more feedbacks, thank you [1] http://code.google.com/p/tapestrytools/ [2] http://code.google.com/p/tapestrytools/issues/list 在 2011年5月27日 上午10:55，Gavin Lei gavingui2...@gmail.com 写道： And there is a simple guide here [2] about how to install this tool in Eclipse 3.6 successful :-) [2] http://code.google.com/p/tapestrytools/wiki/TapestryTools_Install_Guide 在 2011年5月27日 上午10:54，Gavin Lei gavingui2...@gmail.com 写道： Hi all, I have build a update site [1] for this project, if you are interested, you can have a trial of this tool as you wish, it has some basic functions, and i am still working for it. Currently, i am working for add Tapestry components into Web Page Editor's palette, it will help users to add Tapestry components in *.tml file by drag-and-drop components in palette. [1] http://tapestrytools.googlecode.com/svn/trunk/TapestryTools_UpdateSite/ -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com -- - Best Regards Gavin Lei (雷银) Email: gavingui2...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.2.5
Dmitry Gusev: +1 (non-binding) On Fri, Mar 25, 2011 at 21:39, Howard Lewis Ship hls...@gmail.com wrote: Howard M. Lewis Ship: +1 Didn't test myself, but since everyone else did, it's a matter of trust! On Fri, Mar 25, 2011 at 10:30 AM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: +1 Kalle Korhonen (non-binding) Tested against a few Tynamo libs with no issues to report On Wed, Mar 23, 2011 at 7:24 AM, Igor Drobiazko igor.drobia...@gmail.com wrote: I've created and uploaded a release of Tapestry 5.2.5, ready to be voted upon. The binary and source downloads are uploaded to: http://people.apache.org/~drobiazko/tapestry-releases/ and the Maven artifacts staged to: https://repository.apache.org/content/repositories/orgapachetapestry-025/ Please examine these files to determine if the new release, 5.2.5, is ready. I've also created a 5.2.5 tag in Subversion: http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/5.2.5/ On a successful vote, I'll move the files from these directories to the proper distribution directories and update the Tapestry site documentation. Vote will run for three days; on success I'll move the voted artifacts into place and send out appropriate notifications. -- Best regards, Igor Drobiazko http://tapestry5.de - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: JPA: Committing transactions
On Thu, Feb 17, 2011 at 11:24, Igor Drobiazko igor.drobia...@gmail.comwrote: On Wed, Feb 16, 2011 at 7:39 PM, Josh Canfield joshcanfi...@gmail.com wrote: How are you going to deal with failures when doing a multi-unit commit? This is the big question. As EntityTransaction doesn't support 2-phase commit, you can have a corrupt state in case of failures when doing a multi-unit commit. Here is for example what Seam doc says: You should avoid EntityTransaction if you have more than one persistence unit in your application. Seam does not support installing multiple EntityTransaction beans, and the EntityTransaction interface does not support two phase commit, so unless you are careful you may have data consistency issues. If you need multiple persistence units in your application then we highly recommend using an EE 6 compatible server, such as Jboss 6. - So may be we should forbid multi-unit commits in the same request? If @CommitAfter is placed and there are more than one active transactions, we can throw an exception. I think we should still add optional PUName to @CommitAfter for the case when we have multiple active transactions, but only want to commit one. Also, how do you plan to start transactions? I found tapestry-jpa doesn't do this efficiently. (see Make Tapestry-JPA Lazy section here: http://dmitrygusev.blogspot.com/2010/09/gae-and-tapestry5-data-access-layer.html ). -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Kalle Korhonen as Tapestry Committer
Dmitry Gusev: +1 (non-binding) On Tue, Jan 11, 2011 at 00:25, Howard Lewis Ship hls...@gmail.com wrote: This one seems a bit overdue ... Kalle has been active on the mailing lists for quite some time, and has been actively evangelizing Tapestry and building toolkits on top of it for a while. I fell that having Kalle as a committer will accelerate the development of both Tapestry and Tynamo, among other benefits. Howard M. Lewis Ship: +1 (binding) -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: how to cleanup threads when tapestry shutsdown
Contribute RegistryShutdownListener like this:
public MyClass buildMyClass(RegistryShutdownHub hub)
{
MyClass result = new MyClass();
// MyClass should implement RegistryShutdownListener interface
hub.addRegistryShutdownListener(result);
return result;
}
On Fri, Sep 17, 2010 at 21:02, hese 1024h...@gmail.com wrote:
Hi,
I have written a tapestry service and added it to AppModule.java (using
function buildMyClass()). This service class uses a thread to execute some
processes. Now, the question is how do I know if the web app/tapestry is
shutting down so that I can do clean up stuff in my class??
Thanks!
hese.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/how-to-cleanup-threads-when-tapestry-shutsdown-tp2844012p2844012.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: [VOTE] Josh Canfield as Committer
Dmitry Gusev: +1 (non-binding) On Fri, Sep 3, 2010 at 09:57, Robin Komiwes robin.komi...@gmail.com wrote: Robin Komiwes: +1 (non-binding) On Fri, Sep 3, 2010 at 2:48 AM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: Thiago H. de Paula Figueiredo: +1 (binding) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Another IllegalAccessError in 5.2 alpha [bug?]
I agree about backward compatibility, but introducing new features disabled by default may cause that nobody will use those features even in new applications. I like the idea to analyze if service can be made reloadable in runtime and log warning if it doesn't. This won't break compatibility but give new projects chance to use live class reloading without additional configuration. On Thu, Aug 12, 2010 at 09:55, Igor Drobiazko igor.drobia...@gmail.comwrote: For backward compatibility reasons it should be enableReloading() and not preventReloading(). Otherwise the most apps will suffer from this issue. Do you remember our promise? Making new features (that can break my app) configurable and disabling them per default is a good practise. On Thu, Aug 12, 2010 at 1:01 AM, Robert Zeigler robe...@scazdl.org wrote: Does: binder.bind(Interface.class, Implementation.class).preventReloading(); not do the trick? It's already disabled for services that use buildXXX since Tapestry won't know the implementation class of the service. Robert On Aug 11, 2010, at 8/115:40 PM , Thiago H. de Paula Figueiredo wrote: On Wed, 11 Aug 2010 19:18:42 -0300, Igor Drobiazko igor.drobia...@gmail.com wrote: But you would recreate only those services that you need right now. All other heavy services are created later on demand. These heavy service methods could be invoked by the recreated services, but I agree with you too. By the way, I couldn't find any way of disabling the services live reloading. Is there any? If not, it would be nice to have one. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Best regards, Igor Drobiazko http://tapestry5.de -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Another IllegalAccessError in 5.2 alpha [bug?]
Btw, I believe most projects deployed on GAE doesn't use JAR packaging because of GAE Eclipse plugin and *.class files are actually on the file system in production (In Eclipse GAE plugin there is just an option to deploy eclipse java project to GAE, I don't think that some packaging happens during this process). Just to clarify I understand this right: Is live class reloading turned off when application runs in production mode? On Thu, Aug 12, 2010 at 04:34, Howard Lewis Ship hls...@gmail.com wrote: Also, this only applies to development mode, where the .class files are on the file system. Classes loaded from JARs are not reloaded and use the standard class loader. On Wed, Aug 11, 2010 at 5:33 PM, Howard Lewis Ship hls...@gmail.com wrote: In most cases, they will still work. For instance, reloadable class B can extend class A and even invoke its protected methods. What gets you is package private access, or access to protected methods from non-inheriting classes within the same package. On Wed, Aug 11, 2010 at 4:35 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: On Wed, 11 Aug 2010 20:01:29 -0300, Robert Zeigler robe...@scazdl.org wrote: Does: binder.bind(Interface.class, Implementation.class).preventReloading(); not do the trick? I haven't tried, but I guess it does. I was talking about a single switch for all services in the registry. Think about projects using autobound services whose implementation is a subclass and I can't/don't want change the sources. For example, my packages and apps have several service implementations that are subclasses. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Pre-loading Tapestry pages
Why pre-load pages? Isn't this hit startup time? On Tue, Aug 10, 2010 at 00:33, Howard Lewis Ship hls...@gmail.com wrote: I was just experimenting with pre-loading Tapestry pages. It doesn't work, because if you inject an Asset, it looks for the Request.getContextPath() and hits a null (no Request object during startup). In Servlet 2.5 we could use the ServletContext.getContextPath() instead, which makes a lot more sense. At some point, we should require that 2.5 be the minimum. That's Tomcat 6 and up, and Jetty 7 and up and I think current versions of Geronimo. I wonder what app servers would be ruled out if we required 2.5? -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Tapestry 5.2.0
Dmitry Gusev: +1 (non-binding) I've just updated my app to 5.2.0 alpha and I had only one JS issue (jQuery + Prototype). Before this I used jQuery without jQuery.noConflict() and it wokred okay with T5.2, after updating to alpha I had to turn noConflict mode on. Its working now. On Sat, Aug 7, 2010 at 18:30, Christian Edward Gruber cgru...@google.comwrote: +0.5 (non-binding) We have a production app internally running against a late-april 5.2 snapshot. I haven't tried it against current trunk, so it's hard for me to honestly +1 it, but if it's april + bugfixes, then I'm +10. Now that the tag has been made, I'm going to pull it into our third-party depot and attempt to run against it. It won't be done in time for this vote, but I anticipate no issues. cheers, Christian On Aug 4, 2010, at 2:04 PM, Howard Lewis Ship wrote: I've created and uploaded a release of Tapestry 5.2.0, ready to be voted upon. This will be the first release for Tapestry 5.2, and hopefully the last alpha release. The binary and source downloads are uploaded to: http://people.apache.org/~hlship/tapestry-releases/ and the Maven artifacts staged to: https://repository.apache.org/content/repositories/orgapachetapestry-063/ Please examine these files to determine if the new release, 5.2.0, is ready. I've also created a 5.2.0 tag in Subversion: http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/5.2.0/ On a successful vote, I'll move the files from these directories to the proper distribution directories and update the Tapestry site documentation. Vote will run for three days; on success I'll move the voted artifacts into place and send out appropriate notifications. Howard M. Lewis Ship: +1 binding -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [jira] Assigned: (TAP5-335) Provide access to annotations of service implementation class
May be it would be possible to add some annotation to build methods to provide details on implementation class? This isn't brilliant, but may work for some cases when you have to use build methods. On Tue, Jul 27, 2010 at 10:33, Igor Drobiazko igor.drobia...@gmail.comwrote: I'm on the verge of committing the fix. I works pretty well but there is a limitation. Copying annotations from implementation to proxy only works for services bound with ServiceBinder inside the bind method. It will not work for services that are created inside build methods. For build methods there is no way to determine the implementation class at proxy creation time. Proxy uses an ObjectCreator which invokes build methods to create the delegates on demand. At this time you know the implementation class but it's just too late. Proxy already have been fabricated. I guess we can live with that limitation. We just have to document it very good. On Wed, Jul 21, 2010 at 8:31 PM, Igor Drobiazko igor.drobia...@gmail.com wrote: On Wed, Jul 21, 2010 at 7:51 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: That's exactly the only thing in Tapestry-IoC that isn't awesome yet IMHO. Yep, agreed. Thank you very much for fixing this issue! I even researched a little bit, but I haven't had the time to implement it. It is not fixed but hopefully this weekend. -- Best regards, Igor Drobiazko http://tapestry5.de -- Best regards, Igor Drobiazko http://tapestry5.de -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [VOTE] Committer status for Robin Komiwes
Dmitry Gusev: +1 (non-binding) On Wed, Jul 14, 2010 at 23:23, Ulrich Stärk u...@spielviel.de wrote: Robin has continued to provide valuable contributions to Tapestry in the form of a new logo, a slogan and two new website designs, one of which is currently being integrated into our new website, as well as through mentoring on the users mailing list. I'd therefore like to make Robin a committer. Please cast your votes within the next 72 hours. Please also use the scheme name: vote (binding/non-binding) when voting. That will facilitate compiling the results. Ulrich Stärk: +1 (binding) - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: [DISCUSS] Tapestry homepage redesign
This looks relly cool. Will the design fit to width or it will be fixed-width? One thing about documentation, will it have some structured TOC? On Fri, Jul 9, 2010 at 13:34, Robin Komiwes robin.komi...@gmail.com wrote: Not satisfied with my first proposals, I was waiting for new inspiration to come in order to propose something better. That happened yesterday in the train, on the return of a tapestry5 training I gave. Here is the URL for the previews: http://komiwes.fr/www-tapestry/ What do you think? -- Robin Komiwes On Fri, May 28, 2010 at 3:57 PM, Robin Komiwes robin.komi...@gmail.com wrote: Thanx Sebastian, I was waiting since the beginning for your feedback. On Fri, May 28, 2010 at 3:53 PM, Sebastian Hennebrueder use...@laliluna.de wrote: Hi Robin, this is a great design and the first impression visiting the page is amazing. Personally I prefer version 1 which remembers me of a magazin like front page. When using version 4, the following case came into my mind. If you start reading and the text starts to move away, you need to wait some time before the slide reappears. From an information point of view, the front page is great. There is a short introduction to tell the user what Tapestry is and some room for more details. In an analysis I made some time ago for Tapestry, there had been different types of users. You have already seen the remarks from the experienced Tapestry users needing a direct link to documentation and probably news and downloads. Another user type is the architect or CTO looking for quick information of the project. He is interested in key features of Tapestry, number of committers, support options, licence, release cycle, papers and presentations There is the new user who wants to learn the Tapestry and needs 'getting started' infos, documentation, community areas and finally somebody who wants to contribute. The latter needs information about contributing stands, access to community. The links you have positioned on the top do not include community and support. We do not refer to Apache as well. May be there is a place for a sentence like ' Tapestry is an Apache Foundation project.' Below you can find a information grouping I made, when we have discussed the redesign in 2009. I hope this time, we are going to succeed and get the main website updated. Go on guys and core committers don't let this effort silently die again. Best Regards Sebastian About the Project * Home * Features * Project Information * Release Notes * News * Committer * Contributions * Sponsorship * Thanks Getting started * Official Tutorial * Screencasts Documentation * User Guide * FAQ * WIKI * Component Reference * Java Doc * Nightly Java Doc * Blogs of Committers * Refcard - Tapestry on a single page * Articles and Books * Old Tapestry Documentation Support and Community * Mailinglist * IRC Chat * Issue Tracking * Commercial Support * Training Download * Binary and source downloads * Offline Documentation * Maven * Subversion source repository Tapestry Modules and Components * tapestry5-annotations * tapestry-core * tapestry-hibernate * tapestry-hibernate-core * tapestry-ioc * tapestry-spring * tapestry-test * tapestry-upload * -- * Third Party Libraries * Tapestry 360 Contributing to Tapestry * Introduction * Source Repository * Environment * Release checklist * Bible Am 27.05.10 08:34, schrieb Christophe Cordenier: Hi This one may sound a bit old-fashioned nevertheless i suggest it : Build Once Compose Everywhere 2010/5/26 Thiago H. de Paula Figueiredothiag...@gmail.com On Wed, 26 May 2010 18:57:20 -0300, Christian Riedel cr.ml...@googlemail.com wrote: Sounds like advertisement for some AOP-framework :) It could be Tapestry-IoC slogan, then. :) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Best Regards / Viele Grüße Sebastian Hennebrueder - Software Developer and Trainer for Hibernate / Java Persistence http://www.laliluna.de - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http
Re: [VOTE] Ulrich Stärk to Tapestry PMC
Dmitry Gusev: +1 (non-binding) I thought he's already in there. Uli, keep on doing a great job! On Tue, Jun 22, 2010 at 00:16, Howard Lewis Ship hls...@gmail.com wrote: In case anyone's missed, Ulrich has been doing a stellar job of organizing many different efforts within Tapestry of late; including work on the new documentation system and the new logo. He's been doing the work of a PMC member without the recognition, so let's address that. Let's add Ulrich to the PMC. Howard M. Lewis Ship: +1 (binding) -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org -- Dmitry Gusev AnjLab Team http://anjlab.com
