Build failed in Jenkins: tapestry-trunk-freestyle #347

See Changes: [kaosko] Ignore ide resources [kaosko] Revert direct dependency to plastic as unnecessary -- [...truncated 58 lines...] :tapestry-core:classes UP-TO-DATE :tapestry-co

Re: svn commit: r1126839 - in /tapestry/tapestry5/trunk: pom.xml tapestry-core/pom.xml

Yes, you are right of course. My build didn't see the dependency until I did clean, reverted and sorry for the noise. Just installed gradle as well. Kalle On Mon, May 23, 2011 at 10:52 PM, Howard Lewis Ship wrote: > Not sure why this was necessary ... tapestry-core has a transitive > dependency

Re: Generic Protected mixin for mulitple components

On Tue, 24 May 2011 19:19:39 -0300, Lenny Primak wrote: For Q1 I would use class transformation technique to add a method to each component that Inserts the CSRF token. i.e. InsertCSRFToken() and call that from the mixin. That way there are no if statements and it's easier just to implem

Re: Generic Protected mixin for mulitple components

For Q1 I would use class transformation technique to add a method to each component that Inserts the CSRF token. i.e. InsertCSRFToken() and call that from the mixin. That way there are no if statements and it's easier just to implement this globally. On May 24, 2011, at 2:04 PM, Markus Jung

Generic Protected mixin for mulitple components

Hi, currently I have a generic mixin called Protected that I can use for all components to inject the CSRF token. So the usage looks like: Logout or In the mixin I have a if/elseif structure where I use the instanceof operator to determine the exact component: @InjectContainer private ClientE

Re: CSRF protection

Hi, I just want to give an update about the progress and about my plan for the next weeks. The options fine-grained or global CSRF protection make both sense to me. Therefore I would like to provide them both for Tapestry. Fine-grained means having a component mixin that is used to inject the pr

Re: TAP5-1528 --- almost time for first alpha?

I haven't been busy with my web development in a number of weeks due to some C work at the university. I was still planning to champion the multiple databases via configuration groups IoC patch, but I have to study the possible "solution" that was posted a few weeks ago. I don't know if it i

Re: svn commit: r1126839 - in /tapestry/tapestry5/trunk: pom.xml tapestry-core/pom.xml

The command line works well for me, but a Gradle-aware plugin for Eclipse was just released. I haven't checked it out yet. I'm looking forward to deleting the Maven POM files, once all the tools and such are ready. For the moment, I'm maintaining things in two places. On Tue, May 24, 2011 at 5:4

Re: svn commit: r1126839 - in /tapestry/tapestry5/trunk: pom.xml tapestry-core/pom.xml

There's technically a plugin available for IntelliJ, although I found it faster/easier to use command-line gradle rather than the plugin. Robert On May 24, 2011, at 5/247:38 AM , Igor Drobiazko wrote: > As far as I know there is no plugin available that provides a comparable > functionality as

Re: svn commit: r1126839 - in /tapestry/tapestry5/trunk: pom.xml tapestry-core/pom.xml

As far as I know there is no plugin available that provides a comparable functionality as m2eclipse. You can generate eclipse project configuration by executing "gradle eclipse". http://www.gradle.org/eclipse_plugin.html On Tue, May 24, 2011 at 2:15 PM, Ulrich Stärk wrote: > Btw, how good is ID

Re: svn commit: r1126839 - in /tapestry/tapestry5/trunk: pom.xml tapestry-core/pom.xml

Btw, how good is IDE integration for Gradle? Until now I just pointed m2eclipse to the Tapestry SVN repo and it imported everything including setting up the multi-module project, populating the classpath with Maven dependencies and so on so that it was extremely easy to get up and running. Uli

Re: svn commit: r1126839 - in /tapestry/tapestry5/trunk: pom.xml tapestry-core/pom.xml

Gradle creates maven artifacts, so our users will not even know that we switched to gradle. Tapestry jars will be still available in Maven repos. However, I'm not sure about the status of the migration progress. On Tue, May 24, 2011 at 1:37 PM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> w

Re: svn commit: r1126839 - in /tapestry/tapestry5/trunk: pom.xml tapestry-core/pom.xml

On Tue, 24 May 2011 07:10:27 -0300, Igor Drobiazko wrote: Why do we actually still maintain Maven poms? Shouldn't we remove them as we are on gradle now? Unless Gradle is set up Maven POMs, removing the existing ones would be a pain to all the Maven users out there (including me), and th

Re: svn commit: r1126839 - in /tapestry/tapestry5/trunk: pom.xml tapestry-core/pom.xml

Why do we actually still maintain Maven poms? Shouldn't we remove them as we are on gradle now? On Tue, May 24, 2011 at 7:52 AM, Howard Lewis Ship wrote: > Not sure why this was necessary ... tapestry-core has a transitive > dependency on plastic via tapestry-ioc. > > On Mon, May 23, 2011 at 8:1