On 6/8/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 6/8/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>
>
> OT, but how tightly will you have to work with Tomcat to support the
> common
> EL?
isn't EL maintained in jakarta?
Jakarta Commons EL is pretty much Chapter 2 out of J
On 6/8/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> in [the JSF API] there are lots of classes with lots of code and logic.
Not uncommon, which is why I generally consider an API project to be a bit
of a waste.
depends on what you mean by project :)
if a top level project is meant, i no
On 6/7/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
Hi,
this is possibly OT, so I apologize in advance. A while ago there has
been a discussion around a separate project for specifications on this
list, which grew into nothing. Currently I am on the way to publish a
clean room implementation o
> in [the JSF API] there are lots of classes with lots of code and logic.
Not uncommon, which is why I generally consider an API project to be a bit
of a waste. Instead, projects that implement specifications should populate
the standards part of http://projects.apache.org:
http://projects.apa
i've posted a first draft at
http://wiki.apache.org/jakarta/SpecificationRepository but luckily i did see
this point coming :-)
(it's rough so please feel free to dive in and improve)
On 6/7/06, Manfred Geiler <[EMAIL PROTECTED]> wrote:
Don't forget, that the JSF API is a little bit different
An alternative would be XML Commons Externals where we already have the
whole JAXP and W3C DOM family of APIs. Maybe we should make an inventory
of all those APIs on a Wiki page and write down where they are currently
located. That should give us a better overall picture. Charging into
uncontrolled
Don't forget, that the JSF API is a little bit different to other spec
APIs. Other than common spec APIs that almost consist of interfaces
only, in JSF there are lots of classes with lots of code and logic.
So, when I think of JSF API 1.2, I doubt that it would be easy to
separate api development
On 6/7/06, James Strachan <[EMAIL PROTECTED]> wrote:
On 6/7/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> On 6/7/06, James Strachan <[EMAIL PROTECTED]> wrote:
> >
> > Am kinda thinking it needs a very different kind of pmc/committer
> > model so a new top level project might be simplest
On 6/7/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 6/7/06, James Strachan <[EMAIL PROTECTED]> wrote:
>
> Am kinda thinking it needs a very different kind of pmc/committer
> model so a new top level project might be simplest.
>
> e.g. any comitter at apache should be pretty much welcom
On 6/7/06, James Strachan <[EMAIL PROTECTED]> wrote:
Am kinda thinking it needs a very different kind of pmc/committer
model so a new top level project might be simplest.
e.g. any comitter at apache should be pretty much welcome to come in
and add a spec or fix any errors in the specs or build
+1 for tlp
I think folks like Geronimo or Myfaces should be able to commit to
*their* API (sub)project of the Java Spec TLP
-Matthias
On 6/7/06, James Strachan <[EMAIL PROTECTED]> wrote:
Am kinda thinking it needs a very different kind of pmc/committer
model so a new top level project might be
Am kinda thinking it needs a very different kind of pmc/committer
model so a new top level project might be simplest.
e.g. any comitter at apache should be pretty much welcome to come in
and add a spec or fix any errors in the specs or build system or
documentation - as they are generally static
I wonder if Jakarta would be willing to mange the specs. When I
think of Java at Apache, I think of Jakarta so it seems like a
natural place to keep specs. Also Jakarta has experience dealing
with lots of small code bases.
just an idea...
-dain
On Jun 7, 2006, at 9:08 AM, James Strachan
On 6/7/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
So, then the APIs will be in that special "spec project" and impls
will be done in their own projects?
Yes - as there could be many implementations
For MyFaces this would mean
javax.faces.** will be developed in that "spec project"
an
So, then the APIs will be in that special "spec project" and impls
will be done in their own projects?
For MyFaces this would mean
javax.faces.** will be developed in that "spec project"
and the JSF runtime in the *traditional* MyFaces project, right ?
-Matthias
On 6/7/06, Davanum Srinivas <[EM
+1
Guillaume
Davanum Srinivas wrote:
Ah. I got confused between the API and the IMPL. Sure, we have talked
about it before, maybe this will generate the momentum :) +1 to a java
spec project.
thanks,
dims
On 6/7/06, James Strachan <[EMAIL PROTECTED]> wrote:
Agreed - I think a shared java s
Ah. I got confused between the API and the IMPL. Sure, we have talked
about it before, maybe this will generate the momentum :) +1 to a java
spec project.
thanks,
dims
On 6/7/06, James Strachan <[EMAIL PROTECTED]> wrote:
Agreed - I think a shared java spec project makes sense where we can
unify
Agreed - I think a shared java spec project makes sense where we can
unify stuff across all projects like jaxb, geronimo-spec, harmony,
servicemix (we've got the JBI API) into one place.
On 6/7/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
There was a thread about a java spec central repositor
There was a thread about a java spec central repository back in december.
I wish it exists as it would be the best location...
Cheers,
Guillaume Nodet
Jochen Wiedmann wrote:
Hi,
this is possibly OT, so I apologize in advance. A while ago there has
been a discussion around a separate project f
Jochen,
Awesome!!! Personally, my preference would be JaxMe as it is the
next rev of the JAXB spec.
thanks,
dims
On 6/7/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
Hi,
this is possibly OT, so I apologize in advance. A while ago there has
been a discussion around a separate project for
20 matches
Mail list logo
