[trinidad] cleanup

2011-10-05 Thread Gerhard Petracek
hi @ all, there are still over 400 deprecations (via @Deprecated) and nearly 400 via javadoc (not all of them overlap). a lot of them are in for a long time and some of them were deprecated even before [1]. however, some parts are still used and can't be removed. imo we should do a cleanup or

Re: [trinidad] cleanup

2011-10-05 Thread Mark Struberg
+1, although I like to see a release with the current status upfront and then do a minor version jump? Scott, is there any update on the LGPL licensed dependency issue? Is this only in the pom or does this get actively used? txs and LieGrue, strub From:

Re: [trinidad] cleanup

2011-10-05 Thread Scott O'Bryan
Yeah, so I got tied up with a demo. I'm thinking of just excluding the component showcase from the distribution, allowing it to be manually built, but not distributed as an artifact. WDYT? Scott Sent from my iPhone On Oct 5, 2011, at 3:16 AM, Mark Struberg strub...@yahoo.de wrote: +1,

Re: [trinidad] cleanup

2011-10-05 Thread Scott O'Bryan
Gerhard, by deprivation hints, I'm assuming you mean the javadoc deprecations and not the annotations, right? Sent from my iPhone On Oct 5, 2011, at 3:09 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, there are still over 400 deprecations (via @Deprecated) and nearly 400 via

Re: [trinidad] cleanup

2011-10-05 Thread Adam Furmanczuk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry, I could not resists to comment on Iphone: deprivation ;) Greets, Adam Gerhard, by deprivation hints, I'm assuming you mean the javadoc deprecations and not the annotations, right? Sent from my iPhone On Oct 5, 2011, at 3:09 AM,

Re: [trinidad] cleanup

2011-10-05 Thread Gerhard Petracek
both - there are just two possibilities: those parts are really deprecated and we remove them (and refactor the rest) or we can't remove them and the information (annotation and/or javadoc) isn't correct. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and

Re: [trinidad] cleanup

2011-10-05 Thread Scott O'Bryan
Well just because something is depth aged doesn't mean we can remove it. It just means that an alternate means is suggested or something may not work exactly as expected if used. A Prime example is ExternalContextUtils. That guy has been around since JSF 1.1. It contains lots of functionality

Re: [trinidad] cleanup

2011-10-05 Thread Scott O'Bryan
Argh.. Now I'm getting iPhone-isms as well.. ;) Sent from my iPhone On Oct 5, 2011, at 5:06 AM, Scott O'Bryan darkar...@gmail.com wrote: Well just because something is depth aged doesn't mean we can remove it. It just means that an alternate means is suggested or something may not work

Re: [trinidad] cleanup

2011-10-05 Thread Gerhard Petracek
some implementations of old apis are already delegating to the corresponding jsf2 apis. however, there are still even pre jsf 1.x classes in the impl. module. imo we should think about a special backward compatibility module as an alternative. regards, gerhard http://www.irian.at Your JSF

Re: [trinidad] cleanup

2011-10-05 Thread Mark Struberg
I'm not sure if I understand this correctly. Trinidad-2 is for JSF-2 upwards exclusively, isn't? If so, then we can easily get rid of all the old dust which just confuses people. Furthermore there seems to be a few compat problems with JSF-2 f:ajax which can only be resolved by carefully

[jira] [Created] (TOBAGO-1036) Assembly: Facelets and FileUpload JARs should are in the lib folder

2011-10-05 Thread Udo Schnurpfeil (Created) (JIRA)
Assembly: Facelets and FileUpload JARs should are in the lib folder --- Key: TOBAGO-1036 URL: https://issues.apache.org/jira/browse/TOBAGO-1036 Project: MyFaces Tobago Issue

Re: [trinidad] cleanup

2011-10-05 Thread Scott O'Bryan
We could, yes. But we would force people to migrate apps which, perhaps is not a bad thing but traditionally we've taken a full vote before changing/removing API's in Trinidad because, doing so, incurs additional cost on the other frameworks which are using Trinidad as a foundation. Any

Re: [trinidad] cleanup

2011-10-05 Thread Gerhard Petracek
basically i agree with mark. at some point we have to get rid of the old stuff (esp. pre jsf stuff). at least we can move the deprecated parts to the mentioned backward compatibility module (if needed). in combination with shade there shouldn't be a problem at all and it forces us to cleanup and

Re: [trinidad] cleanup

2011-10-05 Thread Scott O'Bryan
Yeah, I'm not sure we know what third parties might depend on. I can tell you, for instance, which deprications, for instance, ADFFaces depends on. I can even remove those dependencies. But the nature of Trinidad and client's like ADFFaces is that the Trinidad implementations are exposed

Re: [trinidad] cleanup

2011-10-05 Thread Scott O'Bryan
The backward compatibility library might be an interesting idea. It just won't always be possible if an existing class has deprecated methods on it. I don't know how many Deprecated classes we have. Scott On 10/05/2011 07:07 AM, Gerhard Petracek wrote: basically i agree with mark. at some

Re: [trinidad] cleanup

2011-10-05 Thread Max Starets
I think we that for 2.0.x versions of Trinidad, should definitely remove stuff that cannot be possibly used/invoked with JSF 2.0. I would not remove all deprecated APIs at once though. Perhaps we could could do it 'in waves ' - start with APIs that were decprected for the longest time,

Re: [trinidad] cleanup

2011-10-05 Thread Gerhard Petracek
most of the deprecated stuff is in the impl module. there are a lot of deprecated classes. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/5 Scott O'Bryan

Re: [trinidad] cleanup

2011-10-05 Thread Gerhard Petracek
@max: basically +1 as mentioned before most of the stuff is in the impl. module. so we can even start with the impl. module and announce the cleanup of the api in parallel - other libs have enough time to get rid of the old api calls, implementations,... (or even better: they could join the

Re: [trinidad] cleanup

2011-10-05 Thread Scott O'Bryan
Yes.. I'm totally +1 for doing this in impl.. :). I think it would greatly slim down our code. To a large extent, I think we've been a bit lazy in getting rid of old api's.. Sent from my iPhone On Oct 5, 2011, at 7:39 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: most of the

Re: [trinidad] cleanup

2011-10-05 Thread Scott O'Bryan
Yes. Cleaning up impl would be an excellent first step.. Sent from my iPhone On Oct 5, 2011, at 7:50 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: @max: basically +1 as mentioned before most of the stuff is in the impl. module. so we can even start with the impl. module and announce

Re: [trinidad] cleanup

2011-10-05 Thread Blake Sullivan
I agree that we want to get rid of the impl stuff first, but even more important would be to get rid of the last of the old UIX-based renderers and the image generation code that we don't use. -- Blake Sullivan On 10/5/11 6:18 AM, Scott O'Bryan wrote: Yeah, I'm not sure we know what third

Re: [trinidad] cleanup

2011-10-05 Thread Gerhard Petracek
+1 (see my comment about the pre jsf stuff) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/5 Blake Sullivan blake.sulli...@oracle.com I agree that we want to get rid

Re: [trinidad] cleanup

2011-10-05 Thread Scott O'Bryan
:D Okay, I missed the pre jsf comment.. ;) Totally good point. That stuff has been around since incubation and migrating them over has always been on the list of todo.. so yes again +1.. Scott On 10/05/2011 09:34 AM, Gerhard Petracek wrote: +1 (see my comment about the pre jsf stuff)

[jira] [Created] (MYFACES-3347) Improve web config param logging and enhance @JSFWebConfigParam

2011-10-05 Thread Leonardo Uribe (Created) (JIRA)
Improve web config param logging and enhance @JSFWebConfigParam --- Key: MYFACES-3347 URL: https://issues.apache.org/jira/browse/MYFACES-3347 Project: MyFaces Core Issue Type:

[jira] [Updated] (MYFACES-3347) Improve web config param logging and enhance @JSFWebConfigParam

2011-10-05 Thread Leonardo Uribe (Updated) (JIRA)
[ https://issues.apache.org/jira/browse/MYFACES-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3347: Status: Patch Available (was: Open) Improve web config param logging and enhance

[jira] [Commented] (MYFACES-3347) Improve web config param logging and enhance @JSFWebConfigParam

2011-10-05 Thread Leonardo Uribe (Commented) (JIRA)
[ https://issues.apache.org/jira/browse/MYFACES-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121125#comment-13121125 ] Leonardo Uribe commented on MYFACES-3347: - If no objections I'll commit this

[jira] [Resolved] (MYFACES-3312) Compare viewId after PreRenderView does not detect navigation to the same page

2011-10-05 Thread Leonardo Uribe (Resolved) (JIRA)
[ https://issues.apache.org/jira/browse/MYFACES-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3312. - Resolution: Fixed Fix Version/s: 2.1.4 2.0.10 Added check

[jira] [Resolved] (MYFACES-3315) @FacesValidator.isDefault() not processed

2011-10-05 Thread Leonardo Uribe (Resolved) (JIRA)
[ https://issues.apache.org/jira/browse/MYFACES-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3315. - Resolution: Fixed Fix Version/s: 2.1.4 2.0.10

[jira] [Resolved] (MYFACES-3310) javax.faces.validator.BeanValidator.createValidatorFactory should store the factory instance on the application map of the externalContext instead of casting to a serv

2011-10-05 Thread Leonardo Uribe (Resolved) (JIRA)
[ https://issues.apache.org/jira/browse/MYFACES-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3310. - Resolution: Fixed Fix Version/s: 2.1.4 2.0.10

[jira] [Resolved] (MYFACES-3345) Quotes in Messages.properties

2011-10-05 Thread Leonardo Uribe (Resolved) (JIRA)
[ https://issues.apache.org/jira/browse/MYFACES-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3345. - Resolution: Fixed Fix Version/s: 2.1.4 2.0.10

[jira] [Resolved] (MYFACES-3346) Chinese Translation for Messages.properties

2011-10-05 Thread Leonardo Uribe (Resolved) (JIRA)
[ https://issues.apache.org/jira/browse/MYFACES-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3346. - Resolution: Fixed Fix Version/s: 2.1.4 2.0.10