Tobago and ADF --> Was .. Re: [proposal] Split Up JIRA Projects

[Sean Schofield <se...@gmail.com>]

Volker,

Interesting proposal but I don't we have to address this just yet. 
But since you brought it up, do you think its possible that ADF and
Tobago could merge into a single project?  I don't know enough about
either to say for sure.

I'm -1 on having saveState in 3 separate projects (tomahawk, tobago
and adf.)  Why would it need to be in commons when it could just be in
tomahawk?  Is there anything in tobago that *requires* save state?  Or
is more accurate to say tobago provides a save state and so does
tomahawk?  Again, I'm not too familiar with tobago ATM (but I will
learn!)

Sean

On 2/14/06, Volker Weber <us...@weber-oldenburg.de> wrote:
> Hi,
>
> +1 for jira split, imho it's needed for different release cycles.
>
> But before doing so we should think about another distributed jar file
> we may want, I think we should have one :-).
>
> I had mentioned before when talking about naming for commons.jar, we
> should have another jar for shared components/classes between tomahawk,
> tobago( and adf?). Non rendering tags like aliasBean, saveState,
> validators and other stuff which could used in both.
>
> I don't like to have impl depends on this, so commons.jar is imho not
> the right place for those.
>
> Regards,
>   Volker
>
> Erik Gustavson wrote:
> > It'll also make sense once ADF Faces gets into the mix.
> >
> > +1 for Jira split, esp. when tomahawk and core, etc... start having
> > different release cycles.
> >
> > +1 for the snapshot naming convention
> >
> > +1 for Tomahawk components being listed as Jira components... that would
> > make it very easy to assess the maturity of any given component for an
> > end user.
> >
> > "commons" would make sense as a Jira component of MyFaces. What other
> > Jira components would make sense under MyFaces then?
> >
> > commons
> > (web) site
> > documentation
> > impl
> > build (maven)
>
> --
> Don't answer to From: address!
> Mail to this account are droped if not recieved via mailinglist.
> To contact me direct create the mail address by
> concatenating my forename to my senders domain.
>

Re: Tobago and ADF --> Was .. Re: [proposal] Split Up JIRA Projects

[Adam Winer <aw...@gmail.com>]

On 2/14/06, Sean Schofield <se...@gmail.com> wrote:
> Volker,
>
> Interesting proposal but I don't we have to address this just yet.
> But since you brought it up, do you think its possible that ADF and
> Tobago could merge into a single project?  I don't know enough about
> either to say for sure.
>
> I'm -1 on having saveState in 3 separate projects (tomahawk, tobago
> and adf.)  Why would it need to be in commons when it could just be in
> tomahawk?  Is there anything in tobago that *requires* save state?  Or
> is more accurate to say tobago provides a save state and so does
> tomahawk?  Again, I'm not too familiar with tobago ATM (but I will
> learn!)

100% agreement that it's darn silly to have multiple implementations
of any non-rendering "utility"-ish things.  Confusing to the users,
wasted development effort, etc. etc.  One obvious example
of that is the file upload filter provided by ADF Faces.  That's
gotta go - the JSF-specific parts merged into MyFaces core
only where they provide new value, and the generic upload
implementation chucked for Apache commons.

I do think there is some value is thinking about things like
saveState as independent of tomahawk, that tomahawk
could be considered as a set of rendering functionality, then
separately MyFaces has a set of utilities that are entirely
independent of any sort of JSF rendering architecture you choose.

For the other question of the thread, merging the subprojects,
I would think our first goal (once all the incubator, etc., Apache
process has cleared) would be merging the non-rendering
functionality.  For instance, ADF Faces has a custom
StateManager - and obviously, we should take the best
features of that and merge it down into the core.  That's the
best way to get the most bang (users benefit) for the buck
(developer time).

ADF Faces should be very mergeable with Tomahawk with
a weak definition of "mergeable":  using Tomahawk and
ADF Faces in the same page, or making them the
same taglib.  Doing the merge in a strong sense - making
all the components and renderers work off of the same
base classes from an internal implementation standpoint,
in particular - will be a bigger challenge.  Worth taking on,
but it'll take time.

-- Adam


> On 2/14/06, Volker Weber <us...@weber-oldenburg.de> wrote:
> > Hi,
> >
> > +1 for jira split, imho it's needed for different release cycles.
> >
> > But before doing so we should think about another distributed jar file
> > we may want, I think we should have one :-).
> >
> > I had mentioned before when talking about naming for commons.jar, we
> > should have another jar for shared components/classes between tomahawk,
> > tobago( and adf?). Non rendering tags like aliasBean, saveState,
> > validators and other stuff which could used in both.
> >
> > I don't like to have impl depends on this, so commons.jar is imho not
> > the right place for those.
> >
> > Regards,
> >   Volker
> >
> > Erik Gustavson wrote:
> > > It'll also make sense once ADF Faces gets into the mix.
> > >
> > > +1 for Jira split, esp. when tomahawk and core, etc... start having
> > > different release cycles.
> > >
> > > +1 for the snapshot naming convention
> > >
> > > +1 for Tomahawk components being listed as Jira components... that would
> > > make it very easy to assess the maturity of any given component for an
> > > end user.
> > >
> > > "commons" would make sense as a Jira component of MyFaces. What other
> > > Jira components would make sense under MyFaces then?
> > >
> > > commons
> > > (web) site
> > > documentation
> > > impl
> > > build (maven)
> >
> > --
> > Don't answer to From: address!
> > Mail to this account are droped if not recieved via mailinglist.
> > To contact me direct create the mail address by
> > concatenating my forename to my senders domain.
> >
>

Re: Tobago and ADF --> Was .. Re: [proposal] Split Up JIRA Projects

[Mike Kienenberger <mk...@gmail.com>]

On 2/14/06, Sean Schofield <se...@gmail.com> wrote:
> Interesting proposal but I don't we have to address this just yet.
> But since you brought it up, do you think its possible that ADF and
> Tobago could merge into a single project?  I don't know enough about
> either to say for sure.
>
> I'm -1 on having saveState in 3 separate projects (tomahawk, tobago
> and adf.)  Why would it need to be in commons when it could just be in
> tomahawk?  Is there anything in tobago that *requires* save state?  Or
> is more accurate to say tobago provides a save state and so does
> tomahawk?  Again, I'm not too familiar with tobago ATM (but I will
> learn!)

I'm still under the impression that the eventual goal is for Togabo,
ADF Faces, and Tomahawk to merge.   Is this wrong?

If it's correct, then everything that can be "shared" among the
subprojects should be in Tomahawk, and everything else needs to
gradually migrate to tomahawk.   The stuff which should be easy to
migrate over would include things like converters, validators,
non-rendering components, and filters like the non-faces servlet
filter.

If we're not planning to merge them, or it becomes technically
impossible to do so, then we need to create a new subproject so that
the sharable stuff above is shared between all three subprojects.

Re: Tobago and ADF --> Was .. Re: [proposal] Split Up JIRA Projects

[Bruno Aranda <br...@gmail.com>]

And, being not familiar with tobago, the million dollar question:
couldn't be tobago and tomahawk work together. Couldn't we think of a
way to success on this? Am I speaking nonsense?

Regards,

Bruno

On 2/14/06, Volker Weber <us...@weber-oldenburg.de> wrote:
>
> Sean Schofield wrote:
> > Volker,
> >
> > Interesting proposal but I don't we have to address this just yet.
> > But since you brought it up, do you think its possible that ADF and
> > Tobago could merge into a single project?  I don't know enough about
> > either to say for sure.
>
> I don't think so, should be easier to merge adf in tomahawk, but i don't
> know mutch about adf.
>
> >
> > I'm -1 on having saveState in 3 separate projects (tomahawk, tobago
> > and adf.)  Why would it need to be in commons when it could just be in
> > tomahawk?  Is there anything in tobago that *requires* save state?  Or
> > is more accurate to say tobago provides a save state and so does
> > tomahawk?  Again, I'm not too familiar with tobago ATM (but I will
> > learn!)
>
> tobago has no saveState, and did not require it, but i like the ability
> to use it (and other tomahawk goodies) in applications. But none of the
> rendering components could used in tobago. I think adding the full
> tomahawk.jar to a application will mislead to use also non compatible
> components from the lib.
>
> Regards,
>   Volker
>
> >
> > Sean
> >
> > On 2/14/06, Volker Weber <us...@weber-oldenburg.de> wrote:
> >
> >>Hi,
> >>
> >>+1 for jira split, imho it's needed for different release cycles.
> >>
> >>But before doing so we should think about another distributed jar file
> >>we may want, I think we should have one :-).
> >>
> >>I had mentioned before when talking about naming for commons.jar, we
> >>should have another jar for shared components/classes between tomahawk,
> >>tobago( and adf?). Non rendering tags like aliasBean, saveState,
> >>validators and other stuff which could used in both.
> >>
> >>I don't like to have impl depends on this, so commons.jar is imho not
> >>the right place for those.
> >>
> >>Regards,
> >>  Volker
> >>
> >>Erik Gustavson wrote:
> >>
> >>>It'll also make sense once ADF Faces gets into the mix.
> >>>
> >>>+1 for Jira split, esp. when tomahawk and core, etc... start having
> >>>different release cycles.
> >>>
> >>>+1 for the snapshot naming convention
> >>>
> >>>+1 for Tomahawk components being listed as Jira components... that would
> >>>make it very easy to assess the maturity of any given component for an
> >>>end user.
> >>>
> >>>"commons" would make sense as a Jira component of MyFaces. What other
> >>>Jira components would make sense under MyFaces then?
> >>>
> >>>commons
> >>>(web) site
> >>>documentation
> >>>impl
> >>>build (maven)
> >>
> >>--
> >>Don't answer to From: address!
> >>Mail to this account are droped if not recieved via mailinglist.
> >>To contact me direct create the mail address by
> >>concatenating my forename to my senders domain.
> >>
> >
> >
>
> --
> Don't answer to From: address!
> Mail to this account are droped if not recieved via mailinglist.
> To contact me direct create the mail address by
> concatenating my forename to my senders domain.
>

Re: Tobago and ADF --> Was .. Re: [proposal] Split Up JIRA Projects

[Mike Kienenberger <mk...@gmail.com>]

Yes, I think it's reasonable to make a case to separate all of the non
rendering-kit stuff into a separate jar, so long as we have enough
components to make it worthwhile.   After all, it was good enough for
the JSF Expert Group -- it's probably good enough for us :)

On 2/14/06, Matthias Wessendorf <mw...@gmail.com> wrote:
> > tobago has no saveState, and did not require it, but i like the ability
> > to use it (and other tomahawk goodies) in applications. But none of the
> > rendering components could used in tobago. I think adding the full
> > tomahawk.jar to a application will mislead to use also non compatible
> > components from the lib.
>
> This issue seems to be similar to stuff like <f:xxx>, which is also
> independent from *any* RenderKit. use it with (standard) html or with
> custom RenderKits (WML, XUL, Tobago,...)
>
> -Matthias
>

Re: Tobago and ADF --> Was .. Re: [proposal] Split Up JIRA Projects

[Matthias Wessendorf <mw...@gmail.com>]

> tobago has no saveState, and did not require it, but i like the ability
> to use it (and other tomahawk goodies) in applications. But none of the
> rendering components could used in tobago. I think adding the full
> tomahawk.jar to a application will mislead to use also non compatible
> components from the lib.

This issue seems to be similar to stuff like <f:xxx>, which is also
independent from *any* RenderKit. use it with (standard) html or with
custom RenderKits (WML, XUL, Tobago,...)

-Matthias

Re: Tobago and ADF --> Was .. Re: [proposal] Split Up JIRA Projects

[Volker Weber <us...@weber-oldenburg.de>]

Sean Schofield wrote:
> Volker,
> 
> Interesting proposal but I don't we have to address this just yet. 
> But since you brought it up, do you think its possible that ADF and
> Tobago could merge into a single project?  I don't know enough about
> either to say for sure.

I don't think so, should be easier to merge adf in tomahawk, but i don't
know mutch about adf.

> 
> I'm -1 on having saveState in 3 separate projects (tomahawk, tobago
> and adf.)  Why would it need to be in commons when it could just be in
> tomahawk?  Is there anything in tobago that *requires* save state?  Or
> is more accurate to say tobago provides a save state and so does
> tomahawk?  Again, I'm not too familiar with tobago ATM (but I will
> learn!)

tobago has no saveState, and did not require it, but i like the ability
to use it (and other tomahawk goodies) in applications. But none of the
rendering components could used in tobago. I think adding the full
tomahawk.jar to a application will mislead to use also non compatible
components from the lib.

Regards,
  Volker

> 
> Sean
> 
> On 2/14/06, Volker Weber <us...@weber-oldenburg.de> wrote:
> 
>>Hi,
>>
>>+1 for jira split, imho it's needed for different release cycles.
>>
>>But before doing so we should think about another distributed jar file
>>we may want, I think we should have one :-).
>>
>>I had mentioned before when talking about naming for commons.jar, we
>>should have another jar for shared components/classes between tomahawk,
>>tobago( and adf?). Non rendering tags like aliasBean, saveState,
>>validators and other stuff which could used in both.
>>
>>I don't like to have impl depends on this, so commons.jar is imho not
>>the right place for those.
>>
>>Regards,
>>  Volker
>>
>>Erik Gustavson wrote:
>>
>>>It'll also make sense once ADF Faces gets into the mix.
>>>
>>>+1 for Jira split, esp. when tomahawk and core, etc... start having
>>>different release cycles.
>>>
>>>+1 for the snapshot naming convention
>>>
>>>+1 for Tomahawk components being listed as Jira components... that would
>>>make it very easy to assess the maturity of any given component for an
>>>end user.
>>>
>>>"commons" would make sense as a Jira component of MyFaces. What other
>>>Jira components would make sense under MyFaces then?
>>>
>>>commons
>>>(web) site
>>>documentation
>>>impl
>>>build (maven)
>>
>>--
>>Don't answer to From: address!
>>Mail to this account are droped if not recieved via mailinglist.
>>To contact me direct create the mail address by
>>concatenating my forename to my senders domain.
>>
> 
> 

-- 
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.