Hi,
i think we should not use the version to distinguish between the 1.2
and 1.1 branch of commons (in the release artifacts name),
because the 1.2 (trunk) is not a improved 1.1 version.
afaik there could be circumstances where maven prefers the higher
version even in a jsf 1.1 application.
Regards,
Volker
2008/6/17 Leonardo Uribe <[EMAIL PROTECTED]>:
> Ahhh, Ok, thanks for the information. That's right. If exists a vote, no
> way.
>
> Checking the svn there is a jsf 1.1 branch here:
>
> http://svn.apache.org/repos/asf/myfaces/commons/branches/jsf_11/
>
> And the trunk is the jsf 1.2 branch:
>
> http://svn.apache.org/repos/asf/myfaces/commons/trunk/
>
> But if this is the case I don't feel very good using myfaces builder plugin
> unpack goal. There are about 12 or more files to be shared, so it's not a
> big deal maintaining as two trunks.
>
> Actually the version number of commons is 0.0.1-SNAPSHOT. It should be
> 1.2.0-SNAPSHOT, for keep simple the identification of which version is
> compatible.
>
> According to this layout, tomahawk12 should depends of
> myfaces-commons-1.2.0-SNAPSHOT, but tomahawk11 do not depends with 1.1
> commons branch.
>
> regards
>
> Leonardo Uribe
>
> On Tue, Jun 17, 2008 at 12:10 PM, Andrew Robinson
> <[EMAIL PROTECTED]> wrote:
>>
>> Please see here:
>>
>>
>> http://www.nabble.com/-VOTE--Commons-API-JSF-1.2-only-tp14178115p14180119.html
>>
>> The consensus was to have commons be JSF 1.2 and a separate branch for
>> JSF 1.1 if desired. Therefore, we should place the 1.1 code in a
>> separate location and the main trunk folders should be JSF 1.2 only.
>>
>> Here was the result vote for JSF 1.2 being the trunk:
>>
>> Vote summary
>>
>> +1:
>> Andrew Robinson
>> Mike Kienenberger
>> Simon Lessard
>> Bruno Aranda
>> Cagatay Civici
>> Grant Smith
>> Mario Ivankovits
>> Scott O'Bryan
>> Paul Spencer
>>
>> -0.9:
>> Volker Weber (not official vote)
>> Bernd Bohmann (was -1, but then got a "I'm fine if we are starting
>> with 1.2 only" response)
>>
>> In keeping with the Apache process the vote should be honored and JSF
>> 1.1 folders should not included in the trunk.
>>
>>
>>
>> On Tue, Jun 17, 2008 at 6:35 AM, Andrew Robinson
>> <[EMAIL PROTECTED]> wrote:
>> > BTW, I believe a vote was already taken on commons, and the result was
>> > that commons would be JSF 1.2 only with a 1.1 branch if ppl. wanted to
>> > create one.
>> >
>> > With this in mind, I am strongly -1 for the 1.2 code using 1.1
>> > artifacts.
>> >
>> > On Mon, Jun 16, 2008 at 5:24 PM, Leonardo Uribe <[EMAIL PROTECTED]>
>> > wrote:
>> >>
>> >>
>> >> On Mon, Jun 16, 2008 at 6:16 PM, Andrew Robinson
>> >> <[EMAIL PROTECTED]> wrote:
>> >>>
>> >>> How about moving the JSF version to a folder?
>> >>>
>> >>> commons-utils/
>> >>> commons-11/myfaces-commons-converters
>> >>> commons-11/myfaces-commons-validators
>> >>> commons-12/myfaces-commons-converters
>> >>> commons-12/myfaces-commons-validators
>> >>>
>> >>> Just makes for a cleaner structure IMO and makes it look less like 1.2
>> >>> support is the bastard child of JSF 1.1.
>> >>>
>> >>> If a different name were made, I would suggest 1.2 is the default and
>> >>> 1.1 gets the exception as it is now legacy / deprecated.
>> >>
>> >> Ok, let's use this layout. Only we have to remember that the idea is
>> >> use
>> >> myfaces builder plugin unpack goal to share 1.1 code with 1.2 like in
>> >> tomahawk right now, because one objective is reduce the amount of files
>> >> and
>> >> code to be maintained.
>> >>
>> >>>
>> >>> -Andrew
>> >>>
>> >>> On Mon, Jun 16, 2008 at 4:56 PM, Leonardo Uribe <[EMAIL PROTECTED]>
>> >>> wrote:
>> >>> > Hi
>> >>> >
>> >>> > I'll start to refactor myfaces-commons to the new proposed layout
>> >>> > (I'm
>> >>> > not
>> >>> > started this yet because it was necessary check the actual state of
>> >>> > converters and validators and solve some related issues):
>> >>> >
>> >>> > myfaces-commons-converters
>> >>> > myfaces-commons-converters12
>> >>> > myfaces-commons-validators
>> >>> > myfaces-commons-validators12
>> >>> > myfaces-commons-utils
>> >>> >
>> >>> > It could be good if we have also a:
>> >>> >
>> >>> > myfaces-commons-examples
>> >>> >
>> >>> > As a simple web app with all examples related to myfaces commons
>> >>> > stuff
>> >>> > (converters and validators). I is obvious to have this project, so I
>> >>> > don't
>> >>> > think this require a vote.
>> >>> >
>> >>> > The list of components that should be moved to this location are
>> >>> > this:
>> >>> >
>> >>> > mcc:convertBoolean
>> >>> > mcc:convertDateTime
>> >>> > mcc:convertNumber
>> >>> > mcv:validateCompareTo
>> >>> > mcv:validateCSV
>> >>> > mcv:validateISBN
>> >>> > mcv:validateUrl
>> >>> > mcv:validateCreditCard
>> >>> > mcv:validateEmail
>> >>> > mcv:validateRegExpr
>> >>> >
>> >>> > validateEqual should be deprecated because validateCompareTo it is
>> >>> > better
>> >>> > (according to the suggestion of Mike), so this validator should stay
>> >>> > on
>> >>> > tomahawk. The rest of converters and validators only be referenced
>> >>> > by
>> >>> > tomahawk tld (so myfaces-commons becomes a tomahawk dependency).
>> >>> >
>> >>> > Suggestions are welcome
>> >>> >
>> >>> > regards
>> >>> >
>> >>> > Leonardo Uribe
>> >>> >
>> >>> > On Fri, Jun 13, 2008 at 9:24 PM, Matthias Wessendorf
>> >>> > <[EMAIL PROTECTED]>
>> >>> > wrote:
>> >>> >>
>> >>> >> On Fri, Jun 6, 2008 at 1:06 PM, Mike Kienenberger
>> >>> >> <[EMAIL PROTECTED]>
>> >>> >> wrote:
>> >>> >> > I'd recommend not migrating t:validateEqual across to
>> >>> >> > myfaces-commons.
>> >>> >> > t:validateEquals is a special case of t:validateCompareTo, and,
>> >>> >> > if I
>> >>> >> > recall correctly, the code in validateEquals is not as flexible
>> >>> >> > as
>> >>> >> > the
>> >>> >> > code in validateCompareTo. There's no point in maintaining the
>> >>> >> > inferior limited version in the reorganization.
>> >>> >>
>> >>> >> +1
>> >>> >>
>> >>> >> >
>> >>> >> > On 6/6/08, Leonardo Uribe <[EMAIL PROTECTED]> wrote:
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> On Fri, Jun 6, 2008 at 8:54 AM, Paul Spencer <[EMAIL PROTECTED]>
>> >>> >> >> wrote:
>> >>> >> >> > Leonardo Uribe wrote:
>> >>> >> >> >
>> >>> >> >> > >
>> >>> >> >> > > Hi
>> >>> >> >> > >
>> >>> >> >> > > I'll start to upgrade component from sandbox to tomahawk.
>> >>> >> >> > >
>> >>> >> >> > > The first item on my list of todos is move this converters
>> >>> >> >> > > and
>> >>> >> >> validators
>> >>> >> >> > > (first check and solve possible issues on JIRA)
>> >>> >> >> > >
>> >>> >> >> > > s:convertBoolean
>> >>> >> >> > > s:convertDateTime
>> >>> >> >> > > s:convertNumber
>> >>> >> >> > > s:validateCompareTo
>> >>> >> >> > > s:validateCSV
>> >>> >> >> > > s:validateISBN
>> >>> >> >> > > s:validateUrl
>> >>> >> >> > >
>> >>> >> >> > > Please note that long time ago this upgrade was approved,
>> >>> >> >> > > but
>> >>> >> >> > > this
>> >>> >> >> > > was
>> >>> >> >> not
>> >>> >> >> > > applied due to code generation discussion.
>> >>> >> >> > >
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> <file:///C:/GSOC/workspace/tomahawk-compgen/oldsandbox-site/tlddoc/s/validateUrl.html>
>> >>> >> >> > >
>> >>> >> >> > >
>> >>> >> >> > > Actually on tomahawk exists this validators:
>> >>> >> >> > >
>> >>> >> >> > > t:validateCreditCard
>> >>> >> >> > > t:validateEmail
>> >>> >> >> > > t:validateEqual
>> >>> >> >> > > t:validateRegExpr
>> >>> >> >> > >
>> >>> >> >> > > The idea is that all this converters and validators be on
>> >>> >> >> myfaces-commons.
>> >>> >> >> > > But originally tomahawk is 1.1 compatible, and there was
>> >>> >> >> > > comments
>> >>> >> >> > > about
>> >>> >> >> > > commons should have 1.1 and 1.2 converters and validators.
>> >>> >> >> > > If
>> >>> >> >> > > this
>> >>> >> >> > > is
>> >>> >> >> true,
>> >>> >> >> > > tomahawk should refer myfaces commons converters and
>> >>> >> >> > > validators
>> >>> >> >> > > on
>> >>> >> >> > > its
>> >>> >> >> tld,
>> >>> >> >> > > and have dependecies to commons (if false this is valid only
>> >>> >> >> > > for
>> >>> >> >> > > 1.2).
>> >>> >> >> > >
>> >>> >> >> > >
>> >>> >> >> >
>> >>> >> >> > +1 for true. The thought of maintaining 2 sets of
>> >>> >> >> > converts/valdiators
>> >>> >> >> > is
>> >>> >> >> unnerving.
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> > > The new unpack plugin allow us to manage this issues more
>> >>> >> >> > > easily,
>> >>> >> >> enforcing
>> >>> >> >> > > just the necessary files to maintain.
>> >>> >> >> > >
>> >>> >> >> > > In order to be consistent with this intentions my first
>> >>> >> >> > > approach
>> >>> >> >> > > would
>> >>> >> >> be:
>> >>> >> >> > >
>> >>> >> >> > > 1. Use this layout for myfaces-commons:
>> >>> >> >> > >
>> >>> >> >> > > myfaces-commons-converters
>> >>> >> >> > > myfaces-commons-converters12
>> >>> >> >> > > myfaces-commons-validators
>> >>> >> >> > > myfaces-commons-validators12
>> >>> >> >> > > myfaces-commons-utils
>> >>> >> >> > >
>> >>> >> >> > > 2. Use myfaces-builder-plugin for this stuff.
>> >>> >> >> > >
>> >>> >> >> > > 3. Refer converters and validator from commons to tomahawk
>> >>> >> >> > > tld
>> >>> >> >> > > (the
>> >>> >> >> > > intention is avoid changes on existing applications).
>> >>> >> >> > >
>> >>> >> >> > >
>> >>> >> >> > I suggest deprecating the existing converters/validators.
>> >>> >> >> >
>> >>> >> >>
>> >>> >> >> Good idea but needs some concensus about this. Deprecate means
>> >>> >> >> do
>> >>> >> >> not
>> >>> >> >> exclude it but refer the users to myfaces commons.
>> >>> >> >>
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> > > Suggestions are welcome
>> >>> >> >> > >
>> >>> >> >> > >
>> >>> >> >> >
>> >>> >> >> > o What is the impact on the other components, i.e.
>> >>> >> >> > Trinidad/Tobago/...?
>> >>> >> >> >
>> >>> >> >>
>> >>> >> >> no impact, myfaces commons does not have any release yet and
>> >>> >> >> does
>> >>> >> >> not
>> >>> >> >> have
>> >>> >> >> dependencies with anything (the idea of this discussion is
>> >>> >> >> organize
>> >>> >> >> this
>> >>> >> >> stuff and make a release of this!).
>> >>> >> >>
>> >>> >> >> >
>> >>> >> >> > o Is this to be included in Tomahawk 1.1.7?
>> >>> >> >> >
>> >>> >> >>
>> >>> >> >> yes
>> >>> >> >> >
>> >>> >> >> > o How long do you expect this to take, i.e.
>> >>> >> >> > days/weeks/months/...
>> >>> >> >> > ?
>> >>> >> >> > (I am only asking to set expectation on release schedules)
>> >>> >> >> >
>> >>> >> >>
>> >>> >> >> days, at max weeks
>> >>> >> >>
>> >>> >> >> >
>> >>> >> >> > o Where is the "new unpack plugin" documented?
>> >>> >> >> >
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> http://myfaces.apache.org/build-tools/plugins/myfaces-builder-plugin/unpack-mojo.html
>> >>> >> >>
>> >>> >> >> There is more doc on the source code (the site has not been
>> >>> >> >> updated,
>> >>> >> >> but
>> >>> >> >> this doc is fine). This is a work in progress.
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> > > regards
>> >>> >> >> > >
>> >>> >> >> > > Leonardo Uribe
>> >>> >> >> > >
>> >>> >> >> > >
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> > Paul Spencer
>> >>> >> >> >
>> >>> >> >>
>> >>> >> >>
>> >>> >> >
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> Matthias Wessendorf
>> >>> >>
>> >>> >> further stuff:
>> >>> >> blog: http://matthiaswessendorf.wordpress.com/
>> >>> >> sessions: http://www.slideshare.net/mwessendorf
>> >>> >> mail: matzew-at-apache-dot-org
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>
>
--
inexso - information exchange solutions GmbH
Bismarckstraße 13 | 26122 Oldenburg
Tel.: +49 441 4082 356 |
FAX: +49 441 4082 355 | www.inexso.de
