incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Robinson" <dannyjrobin...@gmail.com>
Subject Re: Building ADF on JDK 1.4
Date Wed, 31 May 2006 21:06:29 GMT
Thanks Adam.

You mention your eventual target is JSF 1.2.  Will the project come out of
incubation before then?

I guess you're not going to make the JSF 1.1 branch anytime soon though.  So
that makes life a little difficult for any immediate JDK 1.4 efforts.  Does
JSF 1.2 really 'require' JDK 1.5, surely 1.4 code would work too.

I kindof see limiting this stuff to 1.5 as removing a large amount of
enterprise users from being able to adopt this earlier then they're able to
if they have to wait for their companies to move forward to 1.5.

Anyway, many thanks for the effort and I'm still keeping my fingers
crossed.  Perhaps there are lots of others who want to wade into the
conversation .... perhaps not ;-)

D.

On 5/31/06, Adam Winer <awiner@gmail.com> wrote:
>
> There's a decent quantity of JDK 1.5 specific code in there;  and
> JSF 1.2, which is our eventual target, will require JDK 1.5.  I'm
> personally reluctant to put in the work to go back to JDK 1.4 just to
> undo that work when we move to JSF 1.2.
>
> When we do go to JSF 1.2, we'll certainly leave behind a
> JSF 1.1-based branch, since adoption of JSF 1.2 will take
> awhile.  I'd be very happy to see others go through the JSF 1.1
> branch to move it back to JDK 1.4.
>
> MyFaces core only requires JDK 1.3, but that's because JCP
> compatibility rules require this for a JSF 1.1 implementation.
> Dunno what Tobago requires.
>
> -- Adam
>
>
> On 5/31/06, Benj Fayle <bfayle@maketechnologies.com> wrote:
> > I would prefer to see ADF remain 1.4 compliant for some time as well. We
> > are currently using Java 1.5 for many new projects but there are still a
> > large number of our enterprise customers who will continue to use Java
> > 1.4 for at least another year, possibly longer. It is for some of these
> > larger projects  that ADF is particularly attractive but they are
> > restricted to Java 1.4.
> >
> > I would be willing to assist in this effort as well.
> >
> > Benj Fayle
> >
> > -----Original Message-----
> > From: Dan Robinson [mailto:dannyjrobinson@gmail.com]
> > Sent: Wednesday, May 31, 2006 12:35 PM
> > To: adffaces-user@incubator.apache.org
> > Subject: Re: Building ADF on JDK 1.4
> >
> > Thanks for the clarification.  Could someone confirm that this the final
> > decision for the Apache ADF code, or just the version as supplied by
> > Oracle.  A recent email on the MyFaces list as of February Sean
> > Schofield
> > said
> >
> > "The ADF stuff is in incubation right now so there are all sorts of
> > possibilities for change.  I envision a lively discussion where discuss
> > the
> > pros and cons of allowing tomahawk, tobago or adf to use jdk
> > 1.5functionality.  Currently tomahawk does not have any jdk
> > 1.5 stuff (that I am aware of.)"
> >
> > We're really wanting to use ADF for our application development, but are
> > currently hampered by the JDK 1.5 requirement, given not all App Servers
> > have made it to this JDK yet.  We're also wanting to deploy this
> > technology
> > to our existing users with 1.4 powered servers.
> >
> > I don't believe that MyFaces (as of 1.1.2) has mandated this JVM
> > version, so
> > it seems strange for a library that runs on MyFaces to have this
> > restriction.  If there's support we could provide assistance in making
> > these
> > changes to allow 1.4.
> >
> > Thanks ... and I wait to be corrected ;-)
> >
> > D.
> >
> > On 5/26/06, Gabrielle Crawford <gabrielle.crawford@oracle.com> wrote:
> > >
> > > ADF Faces requires 1.5.
> > >
> > > Thanks,
> > >
> > > Gabrielle
> > >
> > > Dan Robinson wrote:
> > >
> > > > Could anyone advise the steps to building ADF against JDK 1.4?  I
> > have
> > > it
> > > > building correctly using the Maven Wiki instructions which seem to
> > > > rely on
> > > > JDK 1.5.
> > > >
> > > > Many thanks,
> > > >
> > > > D.
> > > >
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message