You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Leonardo Uribe <lu...@gmail.com> on 2008/09/03 07:59:09 UTC
[VOTE] release for tomahawk 1.1.7
Hi,
I was running the needed tasks to get the 1.1.7 release of Apache
MyFaces Tomahawk out.
Release notes can be found at [4].
Please note that this vote concerns all of the following parts:
1. Maven artifact group "org.apache.myfaces.tomahawk" v1.1.7 [1]
The artifacts are deployed to my private Apache account ([1]).
There is also binary and source packages available on [2]
Please take a look at the "1.1.7" artifacts and vote!
Please note: This vote is "majority approval" with a minimum of three
+1 votes (see [3]).
------------------------------------------------
[ ] +1 for community members who have reviewed the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be released,
and why..............
------------------------------------------------
Thanks,
Leonardo Uribe
[1] http://people.apache.org/~lu4242/tomahawk117
[2] http://people.apache.org/~lu4242/tomahawk117binsrc
[3] http://www.apache.org/foundation/voting.html#ReleaseVotes
[4]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310272&styleName=Html&version=12313398
Re: [VOTE] release for tomahawk 1.1.7
Posted by Hazem Saleh <ha...@apache.org>.
very cool!
On Fri, Sep 5, 2008 at 1:18 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>
> On Fri, Sep 5, 2008 at 4:33 AM, Simon Kitching <sk...@apache.org>wrote:
>
>> The new TomahawkFacesContexFactory stuff looks great to me.
>> As you may have seen, I made one minor change: a public class is now
>> package-scoped.
>>
>> I don't know of any other issues blocking a tomahawk release, and am
>> looking forward to checking a new release candidate!
>>
>> Cheers, Simon
>>
>>
> Ok, I'll run the release tasks the monday, so we can review with calm the
> bits
>
> regards
>
> Leonardo Uribe
>
--
Hazem Ahmed Saleh Ahmed
Web blog: http://www.jroller.com/page/HazemBlog
[Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j:
http://code.google.com/p/gmaps4jsf/
Re: [VOTE] release for tomahawk 1.1.7
Posted by Leonardo Uribe <lu...@gmail.com>.
On Fri, Sep 5, 2008 at 4:33 AM, Simon Kitching <sk...@apache.org> wrote:
> The new TomahawkFacesContexFactory stuff looks great to me.
> As you may have seen, I made one minor change: a public class is now
> package-scoped.
>
> I don't know of any other issues blocking a tomahawk release, and am
> looking forward to checking a new release candidate!
>
> Cheers, Simon
>
>
Ok, I'll run the release tasks the monday, so we can review with calm the
bits
regards
Leonardo Uribe
Re: [VOTE] release for tomahawk 1.1.7
Posted by Simon Kitching <sk...@apache.org>.
The new TomahawkFacesContexFactory stuff looks great to me.
As you may have seen, I made one minor change: a public class is now
package-scoped.
I don't know of any other issues blocking a tomahawk release, and am
looking forward to checking a new release candidate!
Cheers, Simon
Re: [VOTE] release for tomahawk 1.1.7
Posted by simon <sk...@apache.org>.
On Wed, 2008-09-03 at 20:14 +0300, Hazem Saleh wrote:
> Leonardo Uribe schrieb:
>
>
> If you can do a list of things to do for release tomahawk it
> could be good (and please be more accurate. It is difficult to
> guess ;) ). Then we can discuss what it is blocker or not.
>
>
>
> Simon, please open JIRA issues about the pending things, and Me and
> Leonardo will work on them in our free times.
Ok, I've done it. See
TOMAHAWK-1323
TOMAHAWK-1324
Creating issue 1324 feels somewhat odd to me. This is just correct
release processing, and really should be part of every release process.
It is less obvious for myfaces core because the "public api" is so
strictly locked down by the standard, but I would expect that all other
projects would do those checks for each release. They certainly get done
for each Orchestra release. And every apache-commons project checks
these items before every release too. But having a jira task to track it
certainly doesn't do any harm.
Regards,
Simon
Re: [VOTE] release for tomahawk 1.1.7
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Sep 3, 2008 at 12:14 PM, Hazem Saleh <ha...@apache.org> wrote:
> Leonardo Uribe schrieb:
>
>>
>> If you can do a list of things to do for release tomahawk it could be good
>> (and please be more accurate. It is difficult to guess ;) ). Then we can
>> discuss what it is blocker or not.
>>
>>
> Simon, please open JIRA issues about the pending things, and Me and
> Leonardo will work on them in our free times.
>
> Thanks very much.
> --
> Hazem Ahmed Saleh Ahmed
>
> Web blog: http://www.jroller.com/page/HazemBlog
>
> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j:
> http://code.google.com/p/gmaps4jsf/
>
Hi
I have rollback the release while we handle the proposed points
regards
Leonardo Uribe
Re: [VOTE] release for tomahawk 1.1.7
Posted by Hazem Saleh <ha...@apache.org>.
Leonardo Uribe schrieb:
>
> If you can do a list of things to do for release tomahawk it could be good
> (and please be more accurate. It is difficult to guess ;) ). Then we can
> discuss what it is blocker or not.
>
>
Simon, please open JIRA issues about the pending things, and Me and Leonardo
will work on them in our free times.
Thanks very much.
--
Hazem Ahmed Saleh Ahmed
Web blog: http://www.jroller.com/page/HazemBlog
[Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j:
http://code.google.com/p/gmaps4jsf/
Re: [VOTE] release for tomahawk 1.1.7
Posted by Simon Kitching <sk...@apache.org>.
Leonardo Uribe schrieb:
>
>
> On Wed, Sep 3, 2008 at 8:37 PM, Hazem Saleh <hazems@apache.org
> <ma...@apache.org>> wrote:
>
> https://issues.apache.org/jira/browse/TOMAHAWK-1323 is solved now.
>
>
> TOMAHAWK-1324 it is fixed right now too.
>
> If any developer in the community feels that something is missing to
> release tomahawk, this is the right moment to talk and contribute.
Thanks Hazem and Leonardo for all the work! Can you give me until
tomorrow to have a final look at the new code? From a quick glance at
the emailed patches it looks good....
Cheers, Simon
Re: [VOTE] release for tomahawk 1.1.7
Posted by Leonardo Uribe <lu...@gmail.com>.
On Thu, Sep 4, 2008 at 1:08 AM, Jan Nielsen <ja...@gmail.com>wrote:
> Well, since you asked :-) I would be delighted if you would apply this
> patch:
>
> https://issues.apache.org/jira/browse/TOMAHAWK-1249
>
This part of the patch:
+ scroller.getChildren().clear();
it is not a good way to do this. The idea could be remove the children
commandLinks created inside the renderer, rather than all children.
Unfortunately the solution is incomplete (I can't apply it as is), but is a
good start to solve this issue
> Thanks!
>
> -Jan
>
> On Wed, Sep 3, 2008 at 10:40 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> >
> >
> > On Wed, Sep 3, 2008 at 8:37 PM, Hazem Saleh <ha...@apache.org> wrote:
> >>
> >> https://issues.apache.org/jira/browse/TOMAHAWK-1323 is solved now.
> >
> > TOMAHAWK-1324 it is fixed right now too.
> >
> > If any developer in the community feels that something is missing to
> release
> > tomahawk, this is the right moment to talk and contribute.
> >
> > In this release there is a lot of changes and enhancements (about 227
> issues
> > fixed). The full tag class and component class hierarchy was reorganized
> > according to myfaces-builder-plugin introduction (in clirr report almost
> all
> > binary incompatibilities are related to this fact), and a lot of code now
> is
> > generated to allow easy migration to 1.2. Facelets support was added too,
> > and required tag handler classes are now inside tomahawk.
> >
> > If no suggestions/objections, I'll try again a vote of this stuff soon.
> >
> > regards
> >
> > Leonardo Uribe
> >
> >
> >>
> >> On Thu, Sep 4, 2008 at 12:05 AM, simon <sk...@apache.org> wrote:
> >>>
> >>> On Wed, 2008-09-03 at 04:06 -0500, Leonardo Uribe wrote:
> >>>
> >>> >
> >>>
> >>> >
> >>> > Ok, I understand the missing point. There are some config init
> params
> >>> > for use TomahawkFacesContextWrapper or not (this was discussed and
> >>> > solved). But it could be good to have config params for set the
> values
> >>> > used by TomahawkFacesContextWrapper for handle the multipart request
> >>> > case (what you are proposing in a difficult to understand way).
> >>>
> >>> Yes, that's what I meant.
> >>>
> >>> >
> >>> > One problem is do any cast to PortletContext to get the init param
> >>> > (any cast to PortletContext or any portlet class creates a
> requeriment
> >>> > portlet api when loading this class, so introduce
> >>> > ClassNotFoundExceptions on servlet environments). I believe it is
> >>> > possible to do this using reflection (or create a separate class that
> >>> > has the portlet api code, so it is only called when the app is on
> >>> > portlet environment).
> >>>
> >>> Yep, agreed. Some reflection stuff will probably be needed, but not too
> >>> complex.
> >>>
> >>> > Suggestions, patches and any help are welcome (if you want it do it
> >>> > yourself!).
> >>>
> >>> I'll do my best to find some time to help. I would love to see a
> >>> tomahawk release out, and know that you've already put a huge amount of
> >>> time into getting things into shape for a release.
> >>>
> >>> However I am really really busy at the moment, and can't promise a lot.
> >>> I have never written a Portlet before, so testing any patch that I
> >>> prepare would be tricky for a start...
> >>>
> >>> Just as a side note: when someone proposes a new feature, I agree that
> >>> the burden is on them to provide a patch. But this is a QA issue, which
> >>> is somewhat different; it's not entirely fair to people who have spent
> >>> time reviewing code to also be solely responsible for providing patches
> >>> for stuff they find. Reading patches is a thankless enough task without
> >>> that!
> >>>
> >>> But changing this after it is part of an official release will be
> >>> tricky/impossible without breaking backwards compatibility so it's
> >>> really worth doing now.
> >>>
> >>> Cheers,
> >>> Simon
> >>>
> >>> >
> >>>
> >>
> >>
> >>
> >> --
> >> Hazem Ahmed Saleh Ahmed
> >>
> >> Web blog: http://www.jroller.com/page/HazemBlog
> >>
> >> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j:
> >> http://code.google.com/p/gmaps4jsf/
> >
> >
>
Re: [VOTE] release for tomahawk 1.1.7
Posted by Jan Nielsen <ja...@gmail.com>.
Well, since you asked :-) I would be delighted if you would apply this patch:
https://issues.apache.org/jira/browse/TOMAHAWK-1249
Thanks!
-Jan
On Wed, Sep 3, 2008 at 10:40 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>
> On Wed, Sep 3, 2008 at 8:37 PM, Hazem Saleh <ha...@apache.org> wrote:
>>
>> https://issues.apache.org/jira/browse/TOMAHAWK-1323 is solved now.
>
> TOMAHAWK-1324 it is fixed right now too.
>
> If any developer in the community feels that something is missing to release
> tomahawk, this is the right moment to talk and contribute.
>
> In this release there is a lot of changes and enhancements (about 227 issues
> fixed). The full tag class and component class hierarchy was reorganized
> according to myfaces-builder-plugin introduction (in clirr report almost all
> binary incompatibilities are related to this fact), and a lot of code now is
> generated to allow easy migration to 1.2. Facelets support was added too,
> and required tag handler classes are now inside tomahawk.
>
> If no suggestions/objections, I'll try again a vote of this stuff soon.
>
> regards
>
> Leonardo Uribe
>
>
>>
>> On Thu, Sep 4, 2008 at 12:05 AM, simon <sk...@apache.org> wrote:
>>>
>>> On Wed, 2008-09-03 at 04:06 -0500, Leonardo Uribe wrote:
>>>
>>> >
>>>
>>> >
>>> > Ok, I understand the missing point. There are some config init params
>>> > for use TomahawkFacesContextWrapper or not (this was discussed and
>>> > solved). But it could be good to have config params for set the values
>>> > used by TomahawkFacesContextWrapper for handle the multipart request
>>> > case (what you are proposing in a difficult to understand way).
>>>
>>> Yes, that's what I meant.
>>>
>>> >
>>> > One problem is do any cast to PortletContext to get the init param
>>> > (any cast to PortletContext or any portlet class creates a requeriment
>>> > portlet api when loading this class, so introduce
>>> > ClassNotFoundExceptions on servlet environments). I believe it is
>>> > possible to do this using reflection (or create a separate class that
>>> > has the portlet api code, so it is only called when the app is on
>>> > portlet environment).
>>>
>>> Yep, agreed. Some reflection stuff will probably be needed, but not too
>>> complex.
>>>
>>> > Suggestions, patches and any help are welcome (if you want it do it
>>> > yourself!).
>>>
>>> I'll do my best to find some time to help. I would love to see a
>>> tomahawk release out, and know that you've already put a huge amount of
>>> time into getting things into shape for a release.
>>>
>>> However I am really really busy at the moment, and can't promise a lot.
>>> I have never written a Portlet before, so testing any patch that I
>>> prepare would be tricky for a start...
>>>
>>> Just as a side note: when someone proposes a new feature, I agree that
>>> the burden is on them to provide a patch. But this is a QA issue, which
>>> is somewhat different; it's not entirely fair to people who have spent
>>> time reviewing code to also be solely responsible for providing patches
>>> for stuff they find. Reading patches is a thankless enough task without
>>> that!
>>>
>>> But changing this after it is part of an official release will be
>>> tricky/impossible without breaking backwards compatibility so it's
>>> really worth doing now.
>>>
>>> Cheers,
>>> Simon
>>>
>>> >
>>>
>>
>>
>>
>> --
>> Hazem Ahmed Saleh Ahmed
>>
>> Web blog: http://www.jroller.com/page/HazemBlog
>>
>> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j:
>> http://code.google.com/p/gmaps4jsf/
>
>
Re: [VOTE] release for tomahawk 1.1.7
Posted by Gertjan van Oosten <ge...@West.NL>.
Hi Leonardo,
As quoted from Leonardo Uribe <lu...@gmail.com>:
> There was a typo error on the pom.xml of 1.2 branch (the modelId on tomahawk
> core12 is tomahawk12). I have committed the solution.
Things look much better now; thank you!
> Thanks for the help on find this.
You're most welcome.
Kind regards,
--
-- Gertjan van Oosten, Principal Consultant, West Consulting B.V.
-- gertjan@West.NL +31 15 2191 600 www.west.nl
Re: [VOTE] release for tomahawk 1.1.7
Posted by Leonardo Uribe <lu...@gmail.com>.
On Thu, Sep 4, 2008 at 9:53 AM, Simon Kitching <sk...@apache.org> wrote:
> Gertjan van Oosten schrieb:
>
>> As quoted from Leonardo Uribe <lu...@gmail.com>:
>>
>>
>>> [..] a lot of code now is generated to allow easy migration to 1.2.
>>> Facelets support was added too, and required tag handler classes are
>>> now inside tomahawk.
>>>
>>>
>>
>> Too bad the taglib descriptors in the 1.2 versions of the jars are still
>> more or less empty:
>>
>>
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk12/1.1.7-SNAPSHOT/
>>
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk-sandbox12/1.1.7-SNAPSHOT/
>> [both from today]
>>
>> The taglib descriptors are wrong:
>>
>> % jar tvf tomahawk12-1.1.7-SNAPSHOT.jar | grep 'META-INF/.*taglib.xml'
>> 1274 Thu Sep 04 05:09:22 CEST 2008 META-INF/tomahawk.taglib.xml
>> % jar tvf tomahawk-sandbox12-1.1.7-SNAPSHOT.jar | grep
>> 'META-INF/.*taglib.xml'
>> 1273 Thu Sep 04 05:16:54 CEST 2008 META-INF/sandbox.taglib.xml
>>
>> This will need to be corrected!
>>
>>
>
> Those names look ok to me. An app will use either tomahawk.jar *or*
> tomahawk12.jar; the two are mutually exclusive and provide the same
> components (just optimised for different environments). So it seems sensible
> to me that they use the same taglib name.
>
> The files are completely empty of component declarations though, which will
> indeed be a tiny wee problem :-).
>
>
There was a typo error on the pom.xml of 1.2 branch (the modelId on tomahawk
core12 is tomahawk12). I have committed the solution. Thanks for the help on
find this.
regards
Leonardo Uribe
Re: [VOTE] release for tomahawk 1.1.7
Posted by Simon Kitching <sk...@apache.org>.
Gertjan van Oosten schrieb:
> As quoted from Leonardo Uribe <lu...@gmail.com>:
>
>> [..] a lot of code now is generated to allow easy migration to 1.2.
>> Facelets support was added too, and required tag handler classes are
>> now inside tomahawk.
>>
>
> Too bad the taglib descriptors in the 1.2 versions of the jars are still
> more or less empty:
>
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk12/1.1.7-SNAPSHOT/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk-sandbox12/1.1.7-SNAPSHOT/
> [both from today]
>
> The taglib descriptors are wrong:
>
> % jar tvf tomahawk12-1.1.7-SNAPSHOT.jar | grep 'META-INF/.*taglib.xml'
> 1274 Thu Sep 04 05:09:22 CEST 2008 META-INF/tomahawk.taglib.xml
> % jar tvf tomahawk-sandbox12-1.1.7-SNAPSHOT.jar | grep 'META-INF/.*taglib.xml'
> 1273 Thu Sep 04 05:16:54 CEST 2008 META-INF/sandbox.taglib.xml
>
> This will need to be corrected!
>
Those names look ok to me. An app will use either tomahawk.jar *or*
tomahawk12.jar; the two are mutually exclusive and provide the same
components (just optimised for different environments). So it seems
sensible to me that they use the same taglib name.
The files are completely empty of component declarations though, which
will indeed be a tiny wee problem :-).
Re: [VOTE] release for tomahawk 1.1.7
Posted by Gertjan van Oosten <ge...@West.NL>.
As quoted from Leonardo Uribe <lu...@gmail.com>:
> [..] a lot of code now is generated to allow easy migration to 1.2.
> Facelets support was added too, and required tag handler classes are
> now inside tomahawk.
Too bad the taglib descriptors in the 1.2 versions of the jars are still
more or less empty:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk12/1.1.7-SNAPSHOT/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk-sandbox12/1.1.7-SNAPSHOT/
[both from today]
The taglib descriptors are wrong:
% jar tvf tomahawk12-1.1.7-SNAPSHOT.jar | grep 'META-INF/.*taglib.xml'
1274 Thu Sep 04 05:09:22 CEST 2008 META-INF/tomahawk.taglib.xml
% jar tvf tomahawk-sandbox12-1.1.7-SNAPSHOT.jar | grep 'META-INF/.*taglib.xml'
1273 Thu Sep 04 05:16:54 CEST 2008 META-INF/sandbox.taglib.xml
This will need to be corrected!
Kind regards,
--
-- Gertjan van Oosten, Principal Consultant, West Consulting B.V.
-- gertjan@West.NL +31 15 2191 600 www.west.nl
Re: [VOTE] release for tomahawk 1.1.7
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Sep 3, 2008 at 8:37 PM, Hazem Saleh <ha...@apache.org> wrote:
> https://issues.apache.org/jira/browse/TOMAHAWK-1323 is solved now.
>
>
TOMAHAWK-1324 it is fixed right now too.
If any developer in the community feels that something is missing to release
tomahawk, this is the right moment to talk and contribute.
In this release there is a lot of changes and enhancements (about 227 issues
fixed). The full tag class and component class hierarchy was reorganized
according to myfaces-builder-plugin introduction (in clirr report almost all
binary incompatibilities are related to this fact), and a lot of code now is
generated to allow easy migration to 1.2. Facelets support was added too,
and required tag handler classes are now inside tomahawk.
If no suggestions/objections, I'll try again a vote of this stuff soon.
regards
Leonardo Uribe
>
> On Thu, Sep 4, 2008 at 12:05 AM, simon <sk...@apache.org> wrote:
>
>>
>> On Wed, 2008-09-03 at 04:06 -0500, Leonardo Uribe wrote:
>>
>> >
>>
>> >
>> > Ok, I understand the missing point. There are some config init params
>> > for use TomahawkFacesContextWrapper or not (this was discussed and
>> > solved). But it could be good to have config params for set the values
>> > used by TomahawkFacesContextWrapper for handle the multipart request
>> > case (what you are proposing in a difficult to understand way).
>>
>> Yes, that's what I meant.
>>
>> >
>> > One problem is do any cast to PortletContext to get the init param
>> > (any cast to PortletContext or any portlet class creates a requeriment
>> > portlet api when loading this class, so introduce
>> > ClassNotFoundExceptions on servlet environments). I believe it is
>> > possible to do this using reflection (or create a separate class that
>> > has the portlet api code, so it is only called when the app is on
>> > portlet environment).
>>
>> Yep, agreed. Some reflection stuff will probably be needed, but not too
>> complex.
>>
>> > Suggestions, patches and any help are welcome (if you want it do it
>> > yourself!).
>>
>> I'll do my best to find some time to help. I would love to see a
>> tomahawk release out, and know that you've already put a huge amount of
>> time into getting things into shape for a release.
>>
>> However I am really really busy at the moment, and can't promise a lot.
>> I have never written a Portlet before, so testing any patch that I
>> prepare would be tricky for a start...
>>
>> Just as a side note: when someone proposes a new feature, I agree that
>> the burden is on them to provide a patch. But this is a QA issue, which
>> is somewhat different; it's not entirely fair to people who have spent
>> time reviewing code to also be solely responsible for providing patches
>> for stuff they find. Reading patches is a thankless enough task without
>> that!
>>
>> But changing this after it is part of an official release will be
>> tricky/impossible without breaking backwards compatibility so it's
>> really worth doing now.
>>
>> Cheers,
>> Simon
>>
>> >
>>
>>
>
>
> --
> Hazem Ahmed Saleh Ahmed
>
> Web blog: http://www.jroller.com/page/HazemBlog
>
> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j:
> http://code.google.com/p/gmaps4jsf/
>
Re: [VOTE] release for tomahawk 1.1.7
Posted by Hazem Saleh <ha...@apache.org>.
https://issues.apache.org/jira/browse/TOMAHAWK-1323 is solved now.
On Thu, Sep 4, 2008 at 12:05 AM, simon <sk...@apache.org> wrote:
>
> On Wed, 2008-09-03 at 04:06 -0500, Leonardo Uribe wrote:
>
> >
>
> >
> > Ok, I understand the missing point. There are some config init params
> > for use TomahawkFacesContextWrapper or not (this was discussed and
> > solved). But it could be good to have config params for set the values
> > used by TomahawkFacesContextWrapper for handle the multipart request
> > case (what you are proposing in a difficult to understand way).
>
> Yes, that's what I meant.
>
> >
> > One problem is do any cast to PortletContext to get the init param
> > (any cast to PortletContext or any portlet class creates a requeriment
> > portlet api when loading this class, so introduce
> > ClassNotFoundExceptions on servlet environments). I believe it is
> > possible to do this using reflection (or create a separate class that
> > has the portlet api code, so it is only called when the app is on
> > portlet environment).
>
> Yep, agreed. Some reflection stuff will probably be needed, but not too
> complex.
>
> > Suggestions, patches and any help are welcome (if you want it do it
> > yourself!).
>
> I'll do my best to find some time to help. I would love to see a
> tomahawk release out, and know that you've already put a huge amount of
> time into getting things into shape for a release.
>
> However I am really really busy at the moment, and can't promise a lot.
> I have never written a Portlet before, so testing any patch that I
> prepare would be tricky for a start...
>
> Just as a side note: when someone proposes a new feature, I agree that
> the burden is on them to provide a patch. But this is a QA issue, which
> is somewhat different; it's not entirely fair to people who have spent
> time reviewing code to also be solely responsible for providing patches
> for stuff they find. Reading patches is a thankless enough task without
> that!
>
> But changing this after it is part of an official release will be
> tricky/impossible without breaking backwards compatibility so it's
> really worth doing now.
>
> Cheers,
> Simon
>
> >
>
>
--
Hazem Ahmed Saleh Ahmed
Web blog: http://www.jroller.com/page/HazemBlog
[Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j:
http://code.google.com/p/gmaps4jsf/
Re: [VOTE] release for tomahawk 1.1.7
Posted by simon <sk...@apache.org>.
On Wed, 2008-09-03 at 04:06 -0500, Leonardo Uribe wrote:
>
>
> Ok, I understand the missing point. There are some config init params
> for use TomahawkFacesContextWrapper or not (this was discussed and
> solved). But it could be good to have config params for set the values
> used by TomahawkFacesContextWrapper for handle the multipart request
> case (what you are proposing in a difficult to understand way).
Yes, that's what I meant.
>
> One problem is do any cast to PortletContext to get the init param
> (any cast to PortletContext or any portlet class creates a requeriment
> portlet api when loading this class, so introduce
> ClassNotFoundExceptions on servlet environments). I believe it is
> possible to do this using reflection (or create a separate class that
> has the portlet api code, so it is only called when the app is on
> portlet environment).
Yep, agreed. Some reflection stuff will probably be needed, but not too
complex.
> Suggestions, patches and any help are welcome (if you want it do it
> yourself!).
I'll do my best to find some time to help. I would love to see a
tomahawk release out, and know that you've already put a huge amount of
time into getting things into shape for a release.
However I am really really busy at the moment, and can't promise a lot.
I have never written a Portlet before, so testing any patch that I
prepare would be tricky for a start...
Just as a side note: when someone proposes a new feature, I agree that
the burden is on them to provide a patch. But this is a QA issue, which
is somewhat different; it's not entirely fair to people who have spent
time reviewing code to also be solely responsible for providing patches
for stuff they find. Reading patches is a thankless enough task without
that!
But changing this after it is part of an official release will be
tricky/impossible without breaking backwards compatibility so it's
really worth doing now.
Cheers,
Simon
>
Re: [VOTE] release for tomahawk 1.1.7
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Sep 3, 2008 at 3:39 AM, Simon Kitching <sk...@apache.org> wrote:
> Hi Leonardo,
>
> Leonardo Uribe schrieb:
>
>>
>>
>> On Wed, Sep 3, 2008 at 2:38 AM, Simon Kitching <skitching@apache.org<mailto:
>> skitching@apache.org>> wrote:
>>
>> Sorry, but I must vote -1 on this.
>>
>> Most of the issues I raised earlier about the ExtensionsFilter
>> refactoring have still not been addressed.
>>
>> One change has been made: the ExtensionsFilter now does actually
>> do the work, and the FacesContextFactory does not wrap the object
>> in that case.
>>
>>
>> I believe that you didn't see the latest code. Please check it.
>>
>
> Sorry, I don't understand what you mean.
>
> To rephrase what I said above:
> * I suggested a change to re-enable the ExtensionsFilter
> * The change was made
> * This is good
>
>
>>
>> But the rest of the concerns I had still exist. In particular,
>> there is a large amount of new code that exists to parse the
>> web.xml file looking for config properties - and I don't see why
>> any of this code should exist. I had thought that an earlier email
>> by you (Leonardo) meant that you agreed and would change this to
>> just looking for servlet init parameters via the normal APIs.
>>
>>
>> Check the code please.
>>
> I did, right before writing the email :-)
>
>>
>>
>> In particular, I think we should delete the ExtensionsFilterConfig
>> class completely.
>>
>>
>> I'm open to suggestions, but no alternative has been put on the table.
>>
>
> I did make a suggestion. And I thought you agreed.
>
> The suggestion was for the TomahawkFacesContext* classes to simply use
> ServletContext.getInitParameter -- for servlet config
> PortletContext.getInitParameter -- for portlet config
>
> As I pointed out earlier, we *do* need to be backwards-compatible for code
> that still uses ExtensionsFilter. But because the old filter code has been
> restored, this continues to work as before.
>
> For new code, the config params can just be configured as global options
> rather than as options within a filter-mapping. Because the ability to use
> tomahawk "extensions" functionality without a filter-mapping is new, there
> is no backwards-compatibility requirement.
>
Ok, I understand the missing point. There are some config init params for
use TomahawkFacesContextWrapper or not (this was discussed and solved). But
it could be good to have config params for set the values used by
TomahawkFacesContextWrapper for handle the multipart request case (what you
are proposing in a difficult to understand way).
One problem is do any cast to PortletContext to get the init param (any cast
to PortletContext or any portlet class creates a requeriment portlet api
when loading this class, so introduce ClassNotFoundExceptions on servlet
environments). I believe it is possible to do this using reflection (or
create a separate class that has the portlet api code, so it is only called
when the app is on portlet environment). Suggestions, patches and any help
are welcome (if you want it do it yourself!).
>
>
>
>>
>> Minor points:
>> * Why is new class AbstractAttributeMap in the "servlet" package?
>> * Should AbstractAttributeMap be named "_AbstractAttributeMap"
>> instead, ie is it part of tomahawk's "stable public api" or just
>> an internal implementation detail?
>> * New classes should have @since annotations
>> * etc
>>
>> Any of this points has been proposed before. The problem is if the points
>> are blocker or not for a release.
>>
>
> Another interesting question would be: what other new classes have been
> added?
> A clirr report would be useful here...
If you can do a list of things to do for release tomahawk it could be good
(and please be more accurate. It is difficult to guess ;) ). Then we can
discuss what it is blocker or not.
regards
Leonardo Uribe
>
> Regards,
> Simon
>
>
Re: [VOTE] release for tomahawk 1.1.7
Posted by Simon Kitching <sk...@apache.org>.
Hi Leonardo,
Leonardo Uribe schrieb:
>
>
> On Wed, Sep 3, 2008 at 2:38 AM, Simon Kitching <skitching@apache.org
> <ma...@apache.org>> wrote:
>
> Sorry, but I must vote -1 on this.
>
> Most of the issues I raised earlier about the ExtensionsFilter
> refactoring have still not been addressed.
>
>
> One change has been made: the ExtensionsFilter now does actually
> do the work, and the FacesContextFactory does not wrap the object
> in that case.
>
>
> I believe that you didn't see the latest code. Please check it.
Sorry, I don't understand what you mean.
To rephrase what I said above:
* I suggested a change to re-enable the ExtensionsFilter
* The change was made
* This is good
>
>
>
> But the rest of the concerns I had still exist. In particular,
> there is a large amount of new code that exists to parse the
> web.xml file looking for config properties - and I don't see why
> any of this code should exist. I had thought that an earlier email
> by you (Leonardo) meant that you agreed and would change this to
> just looking for servlet init parameters via the normal APIs.
>
>
> Check the code please.
I did, right before writing the email :-)
>
>
>
> In particular, I think we should delete the ExtensionsFilterConfig
> class completely.
>
>
> I'm open to suggestions, but no alternative has been put on the table.
I did make a suggestion. And I thought you agreed.
The suggestion was for the TomahawkFacesContext* classes to simply use
ServletContext.getInitParameter -- for servlet config
PortletContext.getInitParameter -- for portlet config
As I pointed out earlier, we *do* need to be backwards-compatible for
code that still uses ExtensionsFilter. But because the old filter code
has been restored, this continues to work as before.
For new code, the config params can just be configured as global options
rather than as options within a filter-mapping. Because the ability to
use tomahawk "extensions" functionality without a filter-mapping is new,
there is no backwards-compatibility requirement.
>
>
>
> Minor points:
> * Why is new class AbstractAttributeMap in the "servlet" package?
> * Should AbstractAttributeMap be named "_AbstractAttributeMap"
> instead, ie is it part of tomahawk's "stable public api" or just
> an internal implementation detail?
> * New classes should have @since annotations
> * etc
>
>
> Any of this points has been proposed before. The problem is if the
> points are blocker or not for a release.
Another interesting question would be: what other new classes have been
added?
A clirr report would be useful here...
Regards,
Simon
Re: [VOTE] release for tomahawk 1.1.7
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Sep 3, 2008 at 2:38 AM, Simon Kitching <sk...@apache.org> wrote:
> Sorry, but I must vote -1 on this.
>
> Most of the issues I raised earlier about the ExtensionsFilter refactoring
> have still not been addressed.
> One change has been made: the ExtensionsFilter now does actually do the
> work, and the FacesContextFactory does not wrap the object in that case.
>
I believe that you didn't see the latest code. Please check it.
>
> But the rest of the concerns I had still exist. In particular, there is a
> large amount of new code that exists to parse the web.xml file looking for
> config properties - and I don't see why any of this code should exist. I had
> thought that an earlier email by you (Leonardo) meant that you agreed and
> would change this to just looking for servlet init parameters via the normal
> APIs.
>
Check the code please.
>
> In particular, I think we should delete the ExtensionsFilterConfig class
> completely.
>
I'm open to suggestions, but no alternative has been put on the table.
>
> Minor points:
> * Why is new class AbstractAttributeMap in the "servlet" package?
> * Should AbstractAttributeMap be named "_AbstractAttributeMap" instead, ie
> is it part of tomahawk's "stable public api" or just an internal
> implementation detail?
> * New classes should have @since annotations
> * etc
Any of this points has been proposed before. The problem is if the points
are blocker or not for a release.
>
> Regards,
> Simon
>
>
Re: [VOTE] release for tomahawk 1.1.7
Posted by Simon Kitching <sk...@apache.org>.
Sorry, but I must vote -1 on this.
Most of the issues I raised earlier about the ExtensionsFilter
refactoring have still not been addressed.
One change has been made: the ExtensionsFilter now does actually do the
work, and the FacesContextFactory does not wrap the object in that case.
But the rest of the concerns I had still exist. In particular, there is
a large amount of new code that exists to parse the web.xml file looking
for config properties - and I don't see why any of this code should
exist. I had thought that an earlier email by you (Leonardo) meant that
you agreed and would change this to just looking for servlet init
parameters via the normal APIs.
In particular, I think we should delete the ExtensionsFilterConfig class
completely.
Minor points:
* Why is new class AbstractAttributeMap in the "servlet" package?
* Should AbstractAttributeMap be named "_AbstractAttributeMap" instead,
ie is it part of tomahawk's "stable public api" or just an internal
implementation detail?
* New classes should have @since annotations
* etc
Regards,
Simon
Re: [VOTE] release for tomahawk 1.1.7
Posted by Hazem Saleh <ha...@apache.org>.
+1
On Wed, Sep 3, 2008 at 9:02 AM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>
> On Wed, Sep 3, 2008 at 12:59 AM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>> Hi,
>>
>> I was running the needed tasks to get the 1.1.7 release of Apache
>> MyFaces Tomahawk out.
>>
>> Release notes can be found at [4].
>>
>> Please note that this vote concerns all of the following parts:
>> 1. Maven artifact group "org.apache.myfaces.tomahawk" v1.1.7 [1]
>>
>> The artifacts are deployed to my private Apache account ([1]).
>>
>> There is also binary and source packages available on [2]
>>
>> Please take a look at the "1.1.7" artifacts and vote!
>>
>> Please note: This vote is "majority approval" with a minimum of three
>> +1 votes (see [3]).
>>
>> ------------------------------------------------
>> [ ] +1 for community members who have reviewed the bits
>> [ ] +0
>> [ ] -1 for fatal flaws that should cause these bits not to be released,
>> and why..............
>> ------------------------------------------------
>>
>> Thanks,
>> Leonardo Uribe
>>
>> [1] http://people.apache.org/~lu4242/tomahawk117<http://people.apache.org/%7Elu4242/tomahawk117>
>> [2] http://people.apache.org/~lu4242/tomahawk117binsrc<http://people.apache.org/%7Elu4242/tomahawk117binsrc>
>> [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
>> [4]
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310272&styleName=Html&version=12313398
>>
>>
> +1
>
--
Hazem Ahmed Saleh Ahmed
Web blog: http://www.jroller.com/page/HazemBlog
[Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j:
http://code.google.com/p/gmaps4jsf/
Re: [VOTE] release for tomahawk 1.1.7
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Sep 3, 2008 at 12:59 AM, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi,
>
> I was running the needed tasks to get the 1.1.7 release of Apache
> MyFaces Tomahawk out.
>
> Release notes can be found at [4].
>
> Please note that this vote concerns all of the following parts:
> 1. Maven artifact group "org.apache.myfaces.tomahawk" v1.1.7 [1]
>
> The artifacts are deployed to my private Apache account ([1]).
>
> There is also binary and source packages available on [2]
>
> Please take a look at the "1.1.7" artifacts and vote!
>
> Please note: This vote is "majority approval" with a minimum of three
> +1 votes (see [3]).
>
> ------------------------------------------------
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be released,
> and why..............
> ------------------------------------------------
>
> Thanks,
> Leonardo Uribe
>
> [1] http://people.apache.org/~lu4242/tomahawk117<http://people.apache.org/%7Elu4242/tomahawk117>
> [2] http://people.apache.org/~lu4242/tomahawk117binsrc<http://people.apache.org/%7Elu4242/tomahawk117binsrc>
> [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
> [4]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310272&styleName=Html&version=12313398
>
>
+1