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
+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:
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,
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
-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,
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
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
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
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
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
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
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
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
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
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
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,
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
@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
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
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
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
+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
: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)
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:
[
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
[
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
[
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
[
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
[
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
[
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
[
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
31 matches
Mail list logo