Yeah, the conversation has already gone on longer then I intended. I
was merely expressing sentiments that the moving of shale-test is not
something I would oppose. It is frustrating though to have to port the
bridges ExternalContext logic to another platform. The logic in JSF is
largely tivial, but the Bridge environment has some extra complexities.
Understand also that I was in no way proposing the need to make
configuration of your webapp matter for your test environment. Just
because one may use a piece of implementation from another project
doesn't mean you need to use the whole thing. My point was that much of
the code in shale-test is unnecessary *IF* you are able to leverage the
same work from an already built faces container. This is something that
shale cannot do currently and it leaves maintenance for changes to
ExternalContext (in both the portal and servlet environments)
co-existing in two locations.
Moving on, Gary, since your a PMC of shale, what would be the chances
that we can add Portlet 1.0/JSF 1.2 testcases to shale-test. I believe
Kito was looking at doing some of this work and I would be interrested
also. I know that the Bridge can certainly use it (not necessarily for
the TCK, but for build-time unit tests, and certainly my
myfaces-commons-configurator project and my ExternalContextUtils in the
myfaces-commons-util. Would the community be open to adding portlet
support?
Scott
Paul Spencer wrote:
Gary,
I also use shale-test. One of the feature in the unreleased 1.1.0
allows you the test against any JSF 1.1/1.2 implementation without
having to replace the faces.xml configuration inside the test. Thus
keeping the test framework independent from an implantation. Which is a
good thing and something I support. Gary VanMatre has been named
Shale's PMC, and hopefully he, with our help, will revive the community.
FYI: Their have been many threads related to moving parts of Shale into
MyFaces. Lets not start another one while Shale is still alive.
Paul Spencer
Gary VanMatre wrote:
-------------- Original message ----------------------
From: "Scott O'Bryan" <[EMAIL PROTECTED]>
I don't really see why the physical location affects the ability to
fix bugs
or do enhancements in parallel, unless it depends on some common
implementation classes. Or, are you talking more about releases?
Well releases are part of it. I was meerly bringing up that the
Bridge (even MyFaces) have impls which perform the logic for
"ExternalContext" expected of their various specs. These are
duplicated somewhat in the shale-tests. If it were moved over to
faces, both the core-team and the bridge team would be able to
maintain the test harnesses with the code they are writing. For
instance, Mock the Bridge and Servlet API's and Mock the
FacesContextFactory. It would, in turn, return an ExternalContext
which (while being based off the myfaces or bridge impl) would also
expose the setters needed to test thing. But ultimately, the
underlying implementations would run under the covers. This would
much easier reflect reality.
That said, I was just bringing up the idea that I wouldn't argue
against it. The Bridge (and some of the projects I'm doing in
commons) need released versions of a portlet test harness and I
wouldn't mind adding these test cases to Trinidad either. Whether I
pull them from Shale or MyFaces makes no real difference to me, but
I could help maintain them better if they were in MyFaces -- for a
current committer of shale I am not. :)
Well, I'm not a MyFaces committer either. Ok, I'll bore you - I had
to work on Clay under Struts for 6 months submitting patches to the
code I contributed before I
was nominated to join.
Of course, that was then and this is now but I'd like to see Shale
grow as a community.
The reality is that the majority of Shale was Craig's work. I don't
think that anyone would
dispute that. David Geary also had a hand in the inception. That's
why I'm into the all or nothing versus the cafeteria plan. Shale
test is one of the nuggets. The annotation and remoting are also
being used as the foundation - point of discussion for JSF 2.0.
Shale controller + shale dialog is a simplified version of ADFc 11g.
I don't know... I think we all know how to work together amongst
apache communities. I'm sorta disappointed but at the same time it
makes sense. I remember Ted Husted
(someone else I have great respect for) saying open source is
sometimes like a jealous mistress. I think he might have told me
that just before the merger with webwork.
The interesting bit there is that struts 1.x code base still exists.
Gary
Scott
Well, I'm happy whether it's in MyFaces or Shale, as long as we can
update
it for JSF 1.2 and the Bridge. So, if you want it to be part of
MyFaces and
are willing to deal with the work of getting it established, I
think you'd
have a good case.
What do others think (especially Gary)?
Kito D. Mann wrote:
*From:* Gary VanMatre [mailto:[EMAIL PROTECTED]
*Sent:* Wednesday, April 02, 2008 11:16 AM
*To:* MyFaces Development; [EMAIL PROTECTED]; 'MyFaces Development'
*Cc:* Kito D. Mann
*Subject:* RE: JSF 2.0 component set
From: "Kito D. Mann" <[EMAIL PROTECTED]>
I just want to add that when we were talking about moving Shale
over to
MyFaces, people were worried about resources for maintaining it.
And
Shale
is an *existing* code base :-). I think it'd make a lot more sense
to
migrate the existing suites to JSF 2 branches.
The big issue I had with merging was that the majority didn't
want to
bring over all of shale. At this point, I don't think it would be
responsible just to drop support unless you could offer a comparable
feature.
True. I thought it might make sense to bring the biggest pieces over
to MyFaces, but if we can revive part of Shale's development, I'm
fine
with that too. I just wanted to avoid atrophy of the entire Shale
code
base :-).
The shale's test library is one of the few that have not been
reinvented over and over and that seemed to be where the root
interest
is with myfaces.
In terms of maintaining Shale, we most certainly encourage
contributions the same as myfaces :-)
Of course :-).
Gary
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and
mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988
-----Original Message-----
From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2008 4:39 PM
To: MyFaces Development
Subject: Re: JSF 2.0 component set
Bruno, I totally agree, but we don't want a lot of dead projects
out
there either. My point, and I think Simon's as well, is that much
of
the contributions to the MyFaces Projects and renderkits comes
from
companies and individuals who have a vested interest in
supporting
the
exis! ting re nderkits going forward. Getting MyFaces core up to
2.0 is
going to take away interest from the new project as is getting
renderkits like Trinidad to be JSF 2.0 compatible. This is not to
say
that there isn't an interest in this, but one could spend
hundreds of
developer hours getting their head around Trinidad alone, and
without
the support of the majority of those currently active in the
community,
this project may be doomed from the start. You may be able to
leverage
some resources from other projects by moving as much stuff as
possible
into the commons, but projects of this scope take a lot of time
and my
guess is that you're basically looking at growing a new
community.
I would seriously look at bringing a project of this scope into
incubator first. It'll hopefully help you to build the community
you
&! gt; > ; need.
Scott
Bruno Aranda wrote:
I don't see why not we could start a new component set for jsf
2.0 if
there is enough interest within the developers and users. This
is a
community thing and if people worked heavily in such a project
and
the
result was good, I don't see why it should not exist. If others
want
to maintain Trinidad and Tobago, any help is welcome too. At
the
end,
it is up to each individual :)
Cheers,
Bruno
On 31/03/2008, *simon*
wrote:
Tomahawk certainly does need a radical refresh. It's got some
useful
stuff, but ! is very ugly internally.
There is slow work going on at the moment on something called
the
myfaces "commons projects" (or some similar name). The idea is
to
split
up tomahawk into about 4 different pieces. At the same time
it's
therefore possible to discard the bits that have too much
overlap
with
other projects (esp Trinidad).
That doesn't mean that the current Tomahawk will be abandoned,
but
it is
an opportunity to scavenge the best bits for commons and
discard
the
rest. But I'd really like to see new stuff go into the
"commons"
projects myself. Whether commons is JSF1.2 or JSF2.0 depends on
the
relative progress of commons vs the JSF spec I suppose :-).
! > &g t;
I can't see Trinidad being rewritten anytime soon; that's a
pretty big
job. Just getting a core JSF-2.0 implementation done is likely
to
suck
up all the spare time of the current myfaces contributors. And,
like for
Tomahawk, there is a big pool of people who want to use
Trinidad
on
JSF1.2 (including the committers employed by Oracle) so the
current form
of Trinidad will not be going away in the near future.
I'm not aware of anything in JSF2.0 that is a radical
improvement
over
JSF1.2. Lots of nice bits, but does it really make components
work
faster or vastly more efficient than can be done within JSF1.2?
Regards,
! > &g t; Simon
On Mon, 2008-03-31 at 13:50 -0600, Scott O'Bryan wrote:
+0
While I see the merit of starting over (and certainly
wouldn't
argue
against a new component set based off of 2.0), I don't think
we
should
abadon/restrict renderkits from continuing to support
emerging
standards. I know that many of the folks on Trinidad are
interested in
supporting 2.0 going forward and I would suspect the other
renderkits
are as well.
Scott
Jesse Alexander (KSFH 323) wrote:
I am wondering whether the event of JSF 2.0 would not be a
good > > > > > moment to create a new component set.
Well... another component set?
The main thoughts behind it are
- the 3 MyFaces component sets
- are somewhat incompatible
- have each their good points
- have some weak points
- are missing some "cool" components
- partially have duplicated components
- are partially missing important concepts
JSF 2.0 brings a new concept to do components.
Now it would be possible to update each component set to
JSF
2.0...
but a Tomahawk/JSF2 is "expected" to ! be back ward
compatible.
So it
would be difficult to radically change components or
eliminate
some
duplicates...
Whereas a new component set that would
- take all good concepts from the existing 3 component sets
(and maybe some more from other comp-sets?)
- deliver a clean set of components
- just do it for JSF 2.0
- not have to take backwards compatibility into
consideration
I think if such a new component set would fit, then it
would
be now the
right time to think about the requirements... and as soon
as
a
&g! t; work able beta is around the first steps for the
realization
could be
made...
regards
Alexander