Re: Does Tapestry 5.4 bring client-side ui/controller logic?
Hello Michael, Tapestry 5.4 does not force you to use a specific JavaScript frontend or embraces a specific kind of architecture. The way tapestry-core is implemented is very good for an understanding, how things work in the new requirejs / html5 way. I am using angularjs and it works pretty well together with tapestry (resteasy for data, META-INF/modules for structure, tapestry components for templates). The only thing that is a bit hard, is to get requirejs working together with angularjs, especially if you have a modular design and not all angular controllers and services are predefined. TL;DR: there is no specific way to do frontend javascript in 5.4, just have a look how the javascript in tapestry-core is arranged. Felix P.S.: it is ultimatively productive to use coffeescript with tapestry - give it a try if you did'nt already ;) On Tue, Oct 1, 2013 at 7:47 PM, Michael Wyraz michael.wy...@evermind.dewrote: Hello, with big interest I have read http://tapestryjava.blogspot.** de/2011/11/tapestry-54-focus-**on-javascript.htmlhttp://tapestryjava.blogspot.de/2011/11/tapestry-54-focus-on-javascript.htmlwhich gives an outlook what tapestry 5.4 might bring. Will these breaking ideas be realized in upcoming tapestry 5.4? Especially will it be possible to move all this controller/view stuff to the client (e.g. by using angularjs or similar)? I could not see anything from this at http://tapestry.apache.org/**release-notes-54.htmlhttp://tapestry.apache.org/release-notes-54.html. If it's there, where can I found an entry points or examples? If not, what has to be done to reach the goal? Regards, Michael. --**--**- To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.orgdev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [jira] [Commented] (TAP5-2169) Core stack is not included by default
jepp - that works.
but be aware - if you use the alerts component, the core stack will be
imported nevertheless: https://issues.apache.org/jira/browse/TAP5-2190
On Tue, Sep 24, 2013 at 2:17 AM, Bob Harner bobhar...@gmail.com wrote:
You mean just this?
public void
contributeMarkupRenderer(OrderedConfigurationMarkupRendererFilter
configuration) {
configuration.override(ImportCoreStack, null);
}
On Mon, Sep 23, 2013 at 12:49 PM, Howard Lewis Ship hls...@gmail.com
wrote:
Right on the money, but you can also override with null for the same
effect.
On Mon, Sep 23, 2013 at 2:38 AM, Felix Gonschorek fe...@netzgut.net
wrote:
intermediate solution. put this in your AppModule:
public void
contributeMarkupRenderer(OrderedConfigurationMarkupRendererFilter
configuration) {
MarkupRendererFilter NOOP = new MarkupRendererFilter() {
@Override
public void renderMarkup(MarkupWriter writer, MarkupRenderer renderer)
{
renderer.renderMarkup(writer);
}
};
configuration.override(ImportCoreStack, NOOP);
}
On Mon, Sep 23, 2013 at 11:29 AM, Felix Gonschorek fe...@netzgut.net
wrote:
Can we get a switch to turn off the auto-include of the core stack?
Please? ;-)
On Thu, Sep 19, 2013 at 2:58 AM, Barry Books trs...@gmail.com
wrote:
I agree with Geoff. It's easy to include the core stack in a Layout
component.
On Wed, Sep 18, 2013 at 7:48 PM, Lenny Primak
lpri...@hope.nyc.ny.us
wrote:
Technically I agree but it breaks compatibility. So I reluctantly
disagree.
On Sep 18, 2013, at 7:39 PM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
What changed? The JIRA issue says fixed but there's no info
about
how.
IMHO, it was a FABULOUS decision to emit minimal css classes and
NO
stylesheet. Developers are free to add the core stack if they
wish
and
free
to add refining css classes to the tml.
Who agrees/disagreees?
On 12 September 2013 11:57, Hudson (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/TAP5-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765081#comment-13765081
]
Hudson commented on TAP5-2169:
--
SUCCESS: Integrated in tapestry-trunk-freestyle #1159 (See [
https://builds.apache.org/job/tapestry-trunk-freestyle/1159/])
TAP5-2169: Always import the core stack (hlship: rev
ec83d78d77c7dfde8688dd1f4db351414f42be7f)
* 54_RELEASE_NOTES.md
*
tapestry-core/src/main/java/org/apache/tapestry5/modules/TapestryModule.java
Core stack is not included by default
-
Key: TAP5-2169
URL:
https://issues.apache.org/jira/browse/TAP5-2169
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.4
Reporter: Lenny Primak
Assignee: Howard M. Lewis Ship
Priority: Minor
Fix For: 5.4
For simple applications, core stack is not included, which
breaks
the
UI,
because bootstrap.css and other assets are not loaded.
I think core stack should be forced to be included (possibly
optionally turned off by config)
but it should be included by default
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
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
Re: [jira] [Commented] (TAP5-2169) Core stack is not included by default
Can we get a switch to turn off the auto-include of the core stack? Please? ;-) On Thu, Sep 19, 2013 at 2:58 AM, Barry Books trs...@gmail.com wrote: I agree with Geoff. It's easy to include the core stack in a Layout component. On Wed, Sep 18, 2013 at 7:48 PM, Lenny Primak lpri...@hope.nyc.ny.us wrote: Technically I agree but it breaks compatibility. So I reluctantly disagree. On Sep 18, 2013, at 7:39 PM, Geoff Callender geoff.callender.jumpst...@gmail.com wrote: What changed? The JIRA issue says fixed but there's no info about how. IMHO, it was a FABULOUS decision to emit minimal css classes and NO stylesheet. Developers are free to add the core stack if they wish and free to add refining css classes to the tml. Who agrees/disagreees? On 12 September 2013 11:57, Hudson (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/TAP5-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765081#comment-13765081 ] Hudson commented on TAP5-2169: -- SUCCESS: Integrated in tapestry-trunk-freestyle #1159 (See [ https://builds.apache.org/job/tapestry-trunk-freestyle/1159/]) TAP5-2169: Always import the core stack (hlship: rev ec83d78d77c7dfde8688dd1f4db351414f42be7f) * 54_RELEASE_NOTES.md * tapestry-core/src/main/java/org/apache/tapestry5/modules/TapestryModule.java Core stack is not included by default - Key: TAP5-2169 URL: https://issues.apache.org/jira/browse/TAP5-2169 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Lenny Primak Assignee: Howard M. Lewis Ship Priority: Minor Fix For: 5.4 For simple applications, core stack is not included, which breaks the UI, because bootstrap.css and other assets are not loaded. I think core stack should be forced to be included (possibly optionally turned off by config) but it should be included by default -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: [jira] [Commented] (TAP5-2169) Core stack is not included by default
intermediate solution. put this in your AppModule:
public void
contributeMarkupRenderer(OrderedConfigurationMarkupRendererFilter
configuration) {
MarkupRendererFilter NOOP = new MarkupRendererFilter() {
@Override
public void renderMarkup(MarkupWriter writer, MarkupRenderer renderer) {
renderer.renderMarkup(writer);
}
};
configuration.override(ImportCoreStack, NOOP);
}
On Mon, Sep 23, 2013 at 11:29 AM, Felix Gonschorek fe...@netzgut.netwrote:
Can we get a switch to turn off the auto-include of the core stack?
Please? ;-)
On Thu, Sep 19, 2013 at 2:58 AM, Barry Books trs...@gmail.com wrote:
I agree with Geoff. It's easy to include the core stack in a Layout
component.
On Wed, Sep 18, 2013 at 7:48 PM, Lenny Primak lpri...@hope.nyc.ny.us
wrote:
Technically I agree but it breaks compatibility. So I reluctantly
disagree.
On Sep 18, 2013, at 7:39 PM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
What changed? The JIRA issue says fixed but there's no info about
how.
IMHO, it was a FABULOUS decision to emit minimal css classes and NO
stylesheet. Developers are free to add the core stack if they wish and
free
to add refining css classes to the tml.
Who agrees/disagreees?
On 12 September 2013 11:57, Hudson (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/TAP5-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765081#comment-13765081
]
Hudson commented on TAP5-2169:
--
SUCCESS: Integrated in tapestry-trunk-freestyle #1159 (See [
https://builds.apache.org/job/tapestry-trunk-freestyle/1159/])
TAP5-2169: Always import the core stack (hlship: rev
ec83d78d77c7dfde8688dd1f4db351414f42be7f)
* 54_RELEASE_NOTES.md
*
tapestry-core/src/main/java/org/apache/tapestry5/modules/TapestryModule.java
Core stack is not included by default
-
Key: TAP5-2169
URL: https://issues.apache.org/jira/browse/TAP5-2169
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.4
Reporter: Lenny Primak
Assignee: Howard M. Lewis Ship
Priority: Minor
Fix For: 5.4
For simple applications, core stack is not included, which breaks
the
UI,
because bootstrap.css and other assets are not loaded.
I think core stack should be forced to be included (possibly
optionally turned off by config)
but it should be included by default
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Failing to load asset / stylesheet with @Import annotation in subclassed component / TAP5-2083 (Tapestry 5.4-SNAPSHOT)
hi guys, had a closer look at this since our upgrade to 5.4 is blocked by this issue. It looks like the line 148 in AssetSourceImpl causes this behaviour (tapestry-5.4-alpha3): code String metaRoot = META-INF/assets/ + toPathPrefix(resources.getComponentModel().getLibraryName()); /code the method call toPathPrefix(libraryName) resolves the path relative to the component model, which in turn does not take into consideration, that the component may be subclassed. I tried to find a intermediate solution with javaScriptSupport(asset) in the parent class, but this does'nt work either. Some of my subclassed components are not in the same library, so that should also be checked when searching for a solution. i would contribute a solution on my own, but i can't think of a possible solution that is easy to implement - i think that someone with more insight into the new tapestry internals has to take care here. In the current state it's defineately not possible to subclass components which reside in different packages or libraries. if you have any idea how to solve this properly i would try to implement it and contribute a patch with test case etc. thanks! On Fri, Mar 8, 2013 at 4:22 PM, Felix Gonschorek fe...@netzgut.net wrote: Hi guys, we are upgrading our system to tapestry5.4 (snapshot). importing a stylesheet with the @Import annotation fails, when subclassing a component which is in a different folder: tapestry tries to load the asset in the folder of the subclassed component instead of the folder, where the class resides where the @Import annotation is put on. https://issues.apache.org/jira/browse/TAP5-2083 this was working in 5.3.4-rc-5 (which we still are on because this version has hibernate 4 support by accident ;-) ) thanks! felix
Failing to load asset / stylesheet with @Import annotation in subclassed component / TAP5-2083 (Tapestry 5.4-SNAPSHOT)
Hi guys, we are upgrading our system to tapestry5.4 (snapshot). importing a stylesheet with the @Import annotation fails, when subclassing a component which is in a different folder: tapestry tries to load the asset in the folder of the subclassed component instead of the folder, where the class resides where the @Import annotation is put on. https://issues.apache.org/jira/browse/TAP5-2083 this was working in 5.3.4-rc-5 (which we still are on because this version has hibernate 4 support by accident ;-) ) thanks! felix
Re: Getting current tapestry 5.4-SNAPSHOT head running in eclipse with git and gradle
-Duser.country and -Duser.language didn't help - but i found out, that it's manageable through firefox - setting the default locale in the firefox profile helps. file: /tapestry-core/src/test/conf/ff_profile_template/prefs.js content: user_pref(intl.accept_languages, en-us,en); three remaining tests that fail - but this wil have to wait until after chrismas :-) cheers felix On Fri, Dec 21, 2012 at 10:51 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: This is just a guess but try setting -Duser.country=US -Duser.language=en (e.g. http://stackoverflow.com/questions/8809098/how-do-i-set-the-default-locale-for-my-jvm ) in your GRADLE_OPTS and see if that makes a difference. Kalle On Fri, Dec 21, 2012 at 1:27 PM, Felix Gonschorek fe...@netzgut.net wrote: hello again, hopefully someone finds a minute to solve my problem, i try to summarize a little: my tapestry-5 5.4-SNAPSHOT build fails, because my system is a German windows box. approx. 30 tests don't pass, because they assume English form validation error messages and English formatting of dates and numbers. i tried seveal fixes (including setting the LANG environment variable and adding -Dtapestry,supported-locales=en) but with no success. does anybody have a hint for me, how to configure the system to use English as a locale or how to fix the general setup? happy holiday everybody! felix On Thu, Dec 20, 2012 at 2:43 AM, Felix Gonschorek fe...@netzgut.net wrote: Thank you Lance and Uli, with your help I made some important steps into the right direction. I now use the grade eclipse plugin, it works very well. I also changed the java version in the main build.gradle file from 1.5 to 1.6 (Uli: you changed it back from 1.6 back to 1.5 in 209efb827 8 weeks ago). the remaining compilation errors where from some missing java source files the the org.apache.tapestry5.internal.antlr package - i assumed they are being generated with the first full gradle buid. So I tried to build everything from command line (cygwin, windows 7 ./gradlew build). But here my next problems arise: The build fails very soon when building tapestry-beanvalidator in the TapestryBeanValidationIntegrationTest and the antlr files are not being generated. After looking into things, i found out that the tests assert that there are english bean-validation messages present - my environment is german and the integration-apps output german messages and formatting, so the tests fail. Fix was easy: i added configuration.add(SymbolConstants.SUPPORTED_LOCALES, en); in the AppModule of the beanvalidator integration test. now beanvalidator module builds and all tests pass - but now in tapestry-core there are other tests failing - also because of german localized messages and formatting (dates, numbers) - the tests assert english messages and formatting. the first four failing tests are: 1372 methods, 24 failed, 1348 passed basic_grid: //img[@class='t-sort-icon']/@alt was '[aufw.]' not '[Asc]' bean_editor: Page did not contain 'You must provide at least 3 characters for First Name.'. calendar_field_inside_bean_editor: Page did not contain 'Apr 6, 1978'. cancel_button ERROR: Element //input[@value='Cancel'] not found Now i am stuck - i would like not to have to add the fixed english locale in every AppModule and every Integration test. I tried to set the locale before building the tests from command line but with no success. I tried: export LANG=en_US export LC_ALLen_US ./gradlew -Dtapestry.supported-locales=en build I also added the line JAVA_OPTS=-Dtapestry.supported-locales=en on top of the gradlew build script without success - the tests continue to fail. Is this a bug? I would like to help and try to fix it and improve the tests or the test environment, that the locale of the user where the build runs is not used and english is being used instead. Or is my build setup wrong and cygwin is in some way not supported? Any ideas? Thanks you guys Felix On Tue, Dec 18, 2012 at 3:56 PM, Ulrich Stärk u...@spielviel.de wrote: On 18.12.2012 13:29, Felix Gonschorek wrote: Okay, i would like to contribute back to the tapestry project and submit patches and tests. I have difficulties to get tapestry running in my current dev environment: - eclipse 3.8.1 (jdt, gradle plugin, git team provider and m2 plugin installed) - win 7 usually i work with mercurial and m2eclipse, but git and gradle should'nt be a problem. This is what i do: git clone http://git-wip-us.apache.org/repos/asf/tapestry-5.git cd tapestry-5 ./gradlew eclipse in eclipse: import - existing project into workspace - select tapestry-5
Re: Getting current tapestry 5.4-SNAPSHOT head running in eclipse with git and gradle
hello again, hopefully someone finds a minute to solve my problem, i try to summarize a little: my tapestry-5 5.4-SNAPSHOT build fails, because my system is a German windows box. approx. 30 tests don't pass, because they assume English form validation error messages and English formatting of dates and numbers. i tried seveal fixes (including setting the LANG environment variable and adding -Dtapestry,supported-locales=en) but with no success. does anybody have a hint for me, how to configure the system to use English as a locale or how to fix the general setup? happy holiday everybody! felix On Thu, Dec 20, 2012 at 2:43 AM, Felix Gonschorek fe...@netzgut.net wrote: Thank you Lance and Uli, with your help I made some important steps into the right direction. I now use the grade eclipse plugin, it works very well. I also changed the java version in the main build.gradle file from 1.5 to 1.6 (Uli: you changed it back from 1.6 back to 1.5 in 209efb827 8 weeks ago). the remaining compilation errors where from some missing java source files the the org.apache.tapestry5.internal.antlr package - i assumed they are being generated with the first full gradle buid. So I tried to build everything from command line (cygwin, windows 7 ./gradlew build). But here my next problems arise: The build fails very soon when building tapestry-beanvalidator in the TapestryBeanValidationIntegrationTest and the antlr files are not being generated. After looking into things, i found out that the tests assert that there are english bean-validation messages present - my environment is german and the integration-apps output german messages and formatting, so the tests fail. Fix was easy: i added configuration.add(SymbolConstants.SUPPORTED_LOCALES, en); in the AppModule of the beanvalidator integration test. now beanvalidator module builds and all tests pass - but now in tapestry-core there are other tests failing - also because of german localized messages and formatting (dates, numbers) - the tests assert english messages and formatting. the first four failing tests are: 1372 methods, 24 failed, 1348 passed basic_grid: //img[@class='t-sort-icon']/@alt was '[aufw.]' not '[Asc]' bean_editor: Page did not contain 'You must provide at least 3 characters for First Name.'. calendar_field_inside_bean_editor: Page did not contain 'Apr 6, 1978'. cancel_button ERROR: Element //input[@value='Cancel'] not found Now i am stuck - i would like not to have to add the fixed english locale in every AppModule and every Integration test. I tried to set the locale before building the tests from command line but with no success. I tried: export LANG=en_US export LC_ALLen_US ./gradlew -Dtapestry.supported-locales=en build I also added the line JAVA_OPTS=-Dtapestry.supported-locales=en on top of the gradlew build script without success - the tests continue to fail. Is this a bug? I would like to help and try to fix it and improve the tests or the test environment, that the locale of the user where the build runs is not used and english is being used instead. Or is my build setup wrong and cygwin is in some way not supported? Any ideas? Thanks you guys Felix On Tue, Dec 18, 2012 at 3:56 PM, Ulrich Stärk u...@spielviel.de wrote: On 18.12.2012 13:29, Felix Gonschorek wrote: Okay, i would like to contribute back to the tapestry project and submit patches and tests. I have difficulties to get tapestry running in my current dev environment: - eclipse 3.8.1 (jdt, gradle plugin, git team provider and m2 plugin installed) - win 7 usually i work with mercurial and m2eclipse, but git and gradle should'nt be a problem. This is what i do: git clone http://git-wip-us.apache.org/repos/asf/tapestry-5.git cd tapestry-5 ./gradlew eclipse in eclipse: import - existing project into workspace - select tapestry-5 folder in workspace Result: i get a single tapestry-5 project, but no classpaths are set. after some investigation i see, that eclipse only sees the .project files in the project root folder, not in the sub-projects. so i remove the projects in eclipse without removing the files on the disk. then i delete the .project file in the root folder and import the existing projects into workspace again. Now the subprojects (tapestry-core, tapestry-ioc, tapestry-test) are being detected and i can import the projects. Result: i have now 20 seperate projects in my eclipse workspace. Don't use the eclipse gradle target. Do Import - Gradle Project after git clone and select the parent module. Worked like a charm for me. Eclipse's git integration sucks though. I get a lot of compilation errors: 1) The projects are set up for java 1.5 and in java 1.5 the @Override annotation on methods that implement an interface are not allowed. The @Override annotation is only allowed for methods overriding the method
Re: Getting current tapestry 5.4-SNAPSHOT head running in eclipse with git and gradle
Thank you Lance and Uli, with your help I made some important steps into the right direction. I now use the grade eclipse plugin, it works very well. I also changed the java version in the main build.gradle file from 1.5 to 1.6 (Uli: you changed it back from 1.6 back to 1.5 in 209efb827 8 weeks ago). the remaining compilation errors where from some missing java source files the the org.apache.tapestry5.internal.antlr package - i assumed they are being generated with the first full gradle buid. So I tried to build everything from command line (cygwin, windows 7 ./gradlew build). But here my next problems arise: The build fails very soon when building tapestry-beanvalidator in the TapestryBeanValidationIntegrationTest and the antlr files are not being generated. After looking into things, i found out that the tests assert that there are english bean-validation messages present - my environment is german and the integration-apps output german messages and formatting, so the tests fail. Fix was easy: i added configuration.add(SymbolConstants.SUPPORTED_LOCALES, en); in the AppModule of the beanvalidator integration test. now beanvalidator module builds and all tests pass - but now in tapestry-core there are other tests failing - also because of german localized messages and formatting (dates, numbers) - the tests assert english messages and formatting. the first four failing tests are: 1372 methods, 24 failed, 1348 passed basic_grid: //img[@class='t-sort-icon']/@alt was '[aufw.]' not '[Asc]' bean_editor: Page did not contain 'You must provide at least 3 characters for First Name.'. calendar_field_inside_bean_editor: Page did not contain 'Apr 6, 1978'. cancel_button ERROR: Element //input[@value='Cancel'] not found Now i am stuck - i would like not to have to add the fixed english locale in every AppModule and every Integration test. I tried to set the locale before building the tests from command line but with no success. I tried: export LANG=en_US export LC_ALLen_US ./gradlew -Dtapestry.supported-locales=en build I also added the line JAVA_OPTS=-Dtapestry.supported-locales=en on top of the gradlew build script without success - the tests continue to fail. Is this a bug? I would like to help and try to fix it and improve the tests or the test environment, that the locale of the user where the build runs is not used and english is being used instead. Or is my build setup wrong and cygwin is in some way not supported? Any ideas? Thanks you guys Felix On Tue, Dec 18, 2012 at 3:56 PM, Ulrich Stärk u...@spielviel.de wrote: On 18.12.2012 13:29, Felix Gonschorek wrote: Okay, i would like to contribute back to the tapestry project and submit patches and tests. I have difficulties to get tapestry running in my current dev environment: - eclipse 3.8.1 (jdt, gradle plugin, git team provider and m2 plugin installed) - win 7 usually i work with mercurial and m2eclipse, but git and gradle should'nt be a problem. This is what i do: git clone http://git-wip-us.apache.org/repos/asf/tapestry-5.git cd tapestry-5 ./gradlew eclipse in eclipse: import - existing project into workspace - select tapestry-5 folder in workspace Result: i get a single tapestry-5 project, but no classpaths are set. after some investigation i see, that eclipse only sees the .project files in the project root folder, not in the sub-projects. so i remove the projects in eclipse without removing the files on the disk. then i delete the .project file in the root folder and import the existing projects into workspace again. Now the subprojects (tapestry-core, tapestry-ioc, tapestry-test) are being detected and i can import the projects. Result: i have now 20 seperate projects in my eclipse workspace. Don't use the eclipse gradle target. Do Import - Gradle Project after git clone and select the parent module. Worked like a charm for me. Eclipse's git integration sucks though. I get a lot of compilation errors: 1) The projects are set up for java 1.5 and in java 1.5 the @Override annotation on methods that implement an interface are not allowed. The @Override annotation is only allowed for methods overriding the method of a superclass. Fix: i changed the sourceCompatibility and targetCompatibility in the root build.gradle to 1.6, run the ./gradlew eclipse task again and refresh all projects. Result: The most compilation errors are gone. Question: How can i override the sourceCompatiblity and targetCompatibility settings without changing the main build.gradle file? Strictly speaking, the sourceCompatibility is not 1.5 as far as i understand the setting... should this be fixed in general? I thought I fixed that in 209efb827. 2) I am missing some clojure dependency. There are 49 compilation errors, as far as i can see all of them are related to that: The import clojure cannot be resolved. File: /tapestry-clojure
Re: Cleaning up JIRA
This is not directly related, but: I would love to help by submitting patches (at least for my bug report: https://issues.apache.org/jira/browse/TAP5-1941), but it's really hard to get tapestry running from source in eclipse (and i work with eclipse and java based projects every day). I will open another thread with my experience in trying to get the current tapestry head running in my dev environment. If one is volunteering to clean up Jira by hand i would think this is the best idea. Antother approach would be to: 1) put all tickets to status On Hold and add a comment, that the bug reporter is asked to confirm, that the bug/feature request is still valid. 2) After 4 weeks close the tickets with status on hold with resolution wont fix felix On Tue, Dec 18, 2012 at 12:55 PM, Bob Harner bobhar...@gmail.com wrote: Uli, my only objection is to bulk closing the issues. On Dec 18, 2012 6:52 AM, Ulrich Stärk u...@spielviel.de wrote: Ok, so we keep piling them up because we don't want to hurt people's feelings? Don't you think that people deserve to be told the truth: Guys, we are sorry, but this stuff is old, we most likely won't look at it ever because we have a lot of other tasks with higher priorities, but if you feel this is still an issue please confirm with a newer version of Tapestry? Same goes for feature requests. If we really cared we could have implemented those old requests by now, but we don't. So let's be honest and tell our users that we might find the ideas interesting but lack time to implement them. Everything else is just lying to ourselves and our users that we will someday - maybe - look at it. So let's be honest and tell them what they know anyway: Won't fix. Uli On 18.12.2012 12:38, Bob Harner wrote: Robert Z. has volunteered to prune the list manually. I think we should see where that gets us. Let's not forget that every bug report represents a significant investment of time by a Tapestry user who earnestly wants to make the framework better, and we definitely want to encourage that. A few of the bugs are pure junk, but many are well-described, with good proposed solutions, patches and, yes, even tests in some cases. I know if I were to submit a thoughtful bug report or patch to an open source project and it got casually rejected by an automated process (and I was told not to reopen it), I would be greatly discouraged from making any further contributions. On Tue, Dec 18, 2012 at 2:37 AM, Ulrich Stärk u...@spielviel.de wrote: Folks, there is no sense in hording issues that we know will never be addressed and that do nothing else but clutter our issue tracker and block our view on the really useful ones. Please overcome the gatherer in you. Even the best idea won't help us if there is nobody interested in implementing it and it only contributes to obstrucing our view on important issues. Besides, those tickets aren't gone. They are simply closed. Below is a draft of a text that I'm going to attach to the issues that will be bulk closed. It makes clear that the reporter is free to reopen the issue if it still persists or he feels strongly about it. In case of a feature request they are required to discuss it on the dev mailing list first. I hope that this will increase the chances of having only well thought-out ideas that are also supported by the development community in our tracker. And I really recommend reading [1]. Cheers, Uli [1] http://www.joelonsoftware.com/items/2012/07/09.html draft comment This issue has been closed because it affects an old version of Tapestry or has no affected version number set, and is not currently assigned to any developer. This ticket will most likely never be resolved or already has been resolved as a side-effect of a newer version of Tapestry. DO NOT REOPEN IT! DO NOT CREATE A NEW TICKET WITH THE SAME CONTENT! If you feel that the issue still persists, do the following: 1. Try again with the most recent version of Apache Tapestry 2a. If you still find a bug, open a new bug report, specify the exact version of Tapestry and those of any components you are using, describe expected and observed behavior, and attach a minimal test case demonstrating the issue. You will earn additional merit by attaching an automated test and/or a fix for the issue. 2b. If you want to request a new feature, you are expected to discuss it with the Tapestry developer community on the dev@tapestry.apache.org mailing list first. Include a link to the discussion in the mail archives in your ticket. If you don't, chances are that your ticket will be closed right away. /draft comment On 18.12.2012 03:33, Robert Zeigler wrote: I think I can find some time over the
Getting current tapestry 5.4-SNAPSHOT head running in eclipse with git and gradle
Okay, i would like to contribute back to the tapestry project and submit
patches and tests. I have difficulties to get tapestry running in my
current dev environment:
- eclipse 3.8.1 (jdt, gradle plugin, git team provider and m2 plugin
installed)
- win 7
usually i work with mercurial and m2eclipse, but git and gradle should'nt
be a problem.
This is what i do:
git clone http://git-wip-us.apache.org/repos/asf/tapestry-5.git
cd tapestry-5
./gradlew eclipse
in eclipse:
import - existing project into workspace - select tapestry-5 folder
in workspace
Result: i get a single tapestry-5 project, but no classpaths are set.
after some investigation i see, that eclipse only sees the .project files
in the project root folder, not in the sub-projects. so i remove the
projects in eclipse without removing the files on the disk. then i delete
the .project file in the root folder and import the existing projects into
workspace again.
Now the subprojects (tapestry-core, tapestry-ioc, tapestry-test) are
being detected and i can import the projects.
Result: i have now 20 seperate projects in my eclipse workspace.
I get a lot of compilation errors:
1) The projects are set up for java 1.5 and in java 1.5 the @Override
annotation on methods that implement an interface are not allowed. The
@Override annotation is only allowed for methods overriding the method of a
superclass.
Fix: i changed the sourceCompatibility and targetCompatibility in the
root build.gradle to 1.6, run the ./gradlew eclipse task again and
refresh all projects.
Result: The most compilation errors are gone.
Question: How can i override the sourceCompatiblity and
targetCompatibility settings without changing the main build.gradle file?
Strictly speaking, the sourceCompatibility is not 1.5 as far as i
understand the setting... should this be fixed in general?
2) I am missing some clojure dependency. There are 49 compilation errors,
as far as i can see all of them are related to that:
The import clojure cannot be resolved. File:
/tapestry-clojure/src/main/java/org/apache/tapestry5/internal/clojure/ClojureBuilderImpl.java
Path: line 19
Question: How can i fix this? In the build.gradle file of the
tapestry-clojure is this statement:
dependencies {
provided org.clojure:clojure:1.4.0
}
Obviously it is not provided ;-)
Any help would be highly appreciated, maybe this helps other eclipse users
who are willing to contribute to master the first steps.
Felix
