+1 for a clear cut.
When you upgrade your app to a new version of MyFaces, you'll surely
be happy to have some of the components you used upgraded to tomahawk
from the sandbox. You'll be ok with going through the code-base and
doing a string-search-replace for the affected component-instances.
Isn't that the risk of using components of the sandbox? IMHO, sandbox
components should always be subject to change without notice. If they
are promoted to 'production quality', then so much the better.
Therefore, my personal preference would be to remove all references in
the sandbox after the
I agree with you here, I think pulling the defs the hard way
is the only option otherwise we will get into an utter mess.
Since we have not promoted too many components yet,
I was not sure if pulling the sandbox defs was a viable option,
given the userbase this code already has.
Scheper,
On one hand it is right that components of the sandbox are potential subjects
for change, but would it really hurt to do a slower deprecation? Like Werner
pointed out, some people are already using sandbox components in their
production environments although this may never have been recommended
Ernst Fastl schrieb:
On one hand it is right that components of the sandbox are potential
subjects
for change, but would it really hurt to do a slower deprecation? Like
Werner
pointed out, some people are already using sandbox components in their
production environments although this may never
I agree ,If deprecation is not really possible ( for now I could also
not think of
a appropriate way to do so) then the clear cut has to be done sooner or
later anyway. And as erik-berndt already pointed out, the migration
for the users will be just a text-replace in their jsps or facelet-xhtml
