myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <>
Subject Re: [JSF 2.0] which shared source branch for 2.0
Date Wed, 08 Jul 2009 05:32:30 GMT

2009/7/7 Jan-Kees van Andel <>

> 2009/7/6 Leonardo Uribe <>:
> > Hi
> >
> >  Just note that all tag hierarchy is generated on all myfaces core
> versions,
> > so all classes on org.apache.myfaces.shared_impl.taglib package and inner
> > packages but UIComponentELTagBase and core.SelectItemTagBase are not
> used.
> >
> >  Right now, shared project contains:
> >
> > - Renderer code, to make possible reutilize it in tomahawk
> > - Utility jsf code.
> >
> >  I think it is a good time to create shared/trunk_4.0.x branch and add it
> as
> > dependency to myfaces core 2.0.x. Note that this branch needs a
> dependency
> > to myfaces api 2.0.0-SNAPSHOT. We need to add shared 4.0.x branch (and
> > myfaces core 2.0.0-SNAPSHOT) to continuum server to get nightly builds (I
> > don't have access to that location, so I can't do it!).
> Do you mean Shared needs a dependency to Core and Core needs a
> dependency to Shared? Why is that? It sounds like a bad thing.

It is necessary to have this dependency. There is nothing we can do, and
there is a
similar dependency problem with shale test api.

> > I remember an approved vote to put myfaces core 2.0.x as trunk, but it
> was
> > delayed to way 1.2.7 and 1.1.7 release. This is a good time to change it,
> > create shared branch, put on continuum and also solve shale test (or
> myfaces
> > test) jsf 2.0 problem.
> I can remember that discussion. Who can fix the SVN thing? And
> Continuum, who has admin rights to set up Continuum? I don't even know
> the URL to Continuum. :-)
> I can fix the tests if no one is working on it. What do you think is a
> good package name? Shall I refactor org.apache.shale.test.* to
> org.apache.myfaces.test.*? I can also implement the mocks, since they
> simply return null most of the times. I can also imaging Shared being
> a better place to put such code (than Core)...

In my local machine, using the patch provided on MYFACES-2151, all tests
works fine,
but note we need to commit some code provided in that patch to "myfaces
test" code.

I think (my personal opinion) we need to create several modules for maintain
test code in
a similar way tomahawk do with core and core12 modules. In this case we have
this structure:


and use myfaces-builder-plugin unpack goal to share code between modules.
Right now,
it is not clear if some version of shale test is compatible with jsf 1.1 or
1.2. From other
side, note that shale-test 1.0.5 is compatible with both jsf versions but
the binary jar
file was compiled against jsf 1.2.

This approach makes easier maintain code because it is more easier to see
what code
is specific to some version, and you are sure all code in some module
against some expected jsf version after a build.

I'm not have any objection about change package naming to

It is not possible to put myfaces test code on shared, because this is a jsf
test library, and the intention
is add it as a test dependency. But it could be on myfaces commons, because
is a test framework
common to all myfaces projects.

If no objections I'll start the changes previously described about create
shared 4.0.x branch
and test framework (not move it to myfaces commons, instead change the
Any help with change jsf 2.0 branch to make is trunk and nightly build
configuration is very appreciated.


Leonardo Uribe

> /Jan-Kees

View raw message