You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Adam Winer <aw...@gmail.com> on 2006/04/14 06:35:39 UTC
ADF Faces package name - a first pass
While I'm waiting for a clear spot to start checking in,
we can talk to resolve some basic issues up front.
First up is a package name. There's no requirement for
any final decision until we leave incubator, but I'd like
something better than "oracle.Anything" for the first
checkin.
Does "org.apache.myfaces.adf" sound reasonable?
And "org.apache.myfaces.adfinternal" for all of our
internal code? ADF Faces uses package partitioning for
solidified public APIs vs. internal private APIs, and
I'd like to continue that here.
And, FWIW, "org.apache.myfaces.adfbuild" and
"org.apache.myfaces.adfdemo" for our build tools
and demo code.
This'd also carry over to constants, init params, component
families, renderer types, etc.
-- Adam
Re: ADF Faces package name - a first pass
Posted by John Fallows <jo...@gmail.com>.
On 4/14/06, Adam Winer <aw...@gmail.com> wrote:
>
> I think a good start on that will be just getting it checked in
> here in our incubator, all licensed properly, etc., and indicating
> to the Apache Maven devs that we won't feel the tiniest
> bit slighted if they grab that code from us.
Agreed. I'll ping Brett and the gang once we have an initial checkin for
adffaces incubator.
tc,
-john.
--
http://apress.com/book/bookDisplay.html?bID=10044
Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: ADF Faces package name - a first pass
Posted by Adam Winer <aw...@gmail.com>.
I think a good start on that will be just getting it checked in
here in our incubator, all licensed properly, etc., and indicating
to the Apache Maven devs that we won't feel the tiniest
bit slighted if they grab that code from us. I don't think I'd
have the time to work on it personally.
-- Adam
On 4/14/06, Matthias Wessendorf <ma...@apache.org> wrote:
> nice to hear.
>
> from my pov it sounds reasonable to host that stuff there
>
> -Matthias
>
> On 4/14/06, John Fallows <jo...@gmail.com> wrote:
> > Sounds like a good start.
> >
> > There is interest from the Apache Maven team to host the general purpose
> > Maven plugin work we have done, especially the Maven JDeveloper plugin to
> > generate a JDeveloper workspace and projects for multi-module Maven
> > projects.
> >
> > What is the most appropriate way to proceed?
> >
> > I'm trying to adopt the "Apache Way" here. :-)
> >
> > tc,
> > -john.
> >
> > On 4/13/06, Adam Winer <aw...@gmail.com> wrote:
> > >
> > > While I'm waiting for a clear spot to start checking in,
> > > we can talk to resolve some basic issues up front.
> > >
> > > First up is a package name. There's no requirement for
> > > any final decision until we leave incubator, but I'd like
> > > something better than "oracle.Anything" for the first
> > > checkin.
> > >
> > > Does "org.apache.myfaces.adf" sound reasonable?
> > > And "org.apache.myfaces.adfinternal" for all of our
> > > internal code? ADF Faces uses package partitioning for
> > > solidified public APIs vs. internal private APIs, and
> > > I'd like to continue that here.
> > >
> > > And, FWIW, "org.apache.myfaces.adfbuild" and
> > > "org.apache.myfaces.adfdemo" for our build tools
> > > and demo code.
> > >
> > > This'd also carry over to constants, init params, component
> > > families, renderer types, etc.
> > >
> > > -- Adam
> > >
> >
> >
> >
> > --
> > http://apress.com/book/bookDisplay.html?bID=10044
> > Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
> >
> >
>
>
> --
> Matthias Wessendorf
> Aechterhoek 18
> 48282 Emsdetten
> http://jroller.com/page/mwessendorf
> mwessendorf-at-gmail-dot-com
>
Re: ADF Faces package name - a first pass
Posted by Matthias Wessendorf <ma...@apache.org>.
nice to hear.
from my pov it sounds reasonable to host that stuff there
-Matthias
On 4/14/06, John Fallows <jo...@gmail.com> wrote:
> Sounds like a good start.
>
> There is interest from the Apache Maven team to host the general purpose
> Maven plugin work we have done, especially the Maven JDeveloper plugin to
> generate a JDeveloper workspace and projects for multi-module Maven
> projects.
>
> What is the most appropriate way to proceed?
>
> I'm trying to adopt the "Apache Way" here. :-)
>
> tc,
> -john.
>
> On 4/13/06, Adam Winer <aw...@gmail.com> wrote:
> >
> > While I'm waiting for a clear spot to start checking in,
> > we can talk to resolve some basic issues up front.
> >
> > First up is a package name. There's no requirement for
> > any final decision until we leave incubator, but I'd like
> > something better than "oracle.Anything" for the first
> > checkin.
> >
> > Does "org.apache.myfaces.adf" sound reasonable?
> > And "org.apache.myfaces.adfinternal" for all of our
> > internal code? ADF Faces uses package partitioning for
> > solidified public APIs vs. internal private APIs, and
> > I'd like to continue that here.
> >
> > And, FWIW, "org.apache.myfaces.adfbuild" and
> > "org.apache.myfaces.adfdemo" for our build tools
> > and demo code.
> >
> > This'd also carry over to constants, init params, component
> > families, renderer types, etc.
> >
> > -- Adam
> >
>
>
>
> --
> http://apress.com/book/bookDisplay.html?bID=10044
> Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
>
>
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
http://jroller.com/page/mwessendorf
mwessendorf-at-gmail-dot-com
Re: ADF Faces package name - a first pass
Posted by John Fallows <jo...@gmail.com>.
Sounds like a good start.
There is interest from the Apache Maven team to host the general purpose
Maven plugin work we have done, especially the Maven JDeveloper plugin to
generate a JDeveloper workspace and projects for multi-module Maven
projects.
What is the most appropriate way to proceed?
I'm trying to adopt the "Apache Way" here. :-)
tc,
-john.
On 4/13/06, Adam Winer <aw...@gmail.com> wrote:
>
> While I'm waiting for a clear spot to start checking in,
> we can talk to resolve some basic issues up front.
>
> First up is a package name. There's no requirement for
> any final decision until we leave incubator, but I'd like
> something better than "oracle.Anything" for the first
> checkin.
>
> Does "org.apache.myfaces.adf" sound reasonable?
> And "org.apache.myfaces.adfinternal" for all of our
> internal code? ADF Faces uses package partitioning for
> solidified public APIs vs. internal private APIs, and
> I'd like to continue that here.
>
> And, FWIW, "org.apache.myfaces.adfbuild" and
> "org.apache.myfaces.adfdemo" for our build tools
> and demo code.
>
> This'd also carry over to constants, init params, component
> families, renderer types, etc.
>
> -- Adam
>
--
http://apress.com/book/bookDisplay.html?bID=10044
Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: ADF Faces package name - a first pass
Posted by Jonas Jacobi <jo...@oracle.com>.
Adam Winer wrote:
> While I'm waiting for a clear spot to start checking in,
> we can talk to resolve some basic issues up front.
>
> First up is a package name. There's no requirement for
> any final decision until we leave incubator, but I'd like
> something better than "oracle.Anything" for the first
> checkin.
>
> Does "org.apache.myfaces.adf" sound reasonable?
> And "org.apache.myfaces.adfinternal" for all of our
> internal code? ADF Faces uses package partitioning for
> solidified public APIs vs. internal private APIs, and
> I'd like to continue that here.
>
+1 It would be strange to keep the Oracle package name although it can
be changed later. The sooner we can come up with a new "name" for this
project the better for everyone, but for now this is fine by me.
> And, FWIW, "org.apache.myfaces.adfbuild" and
> "org.apache.myfaces.adfdemo" for our build tools
> and demo code.
>
+ 1
> This'd also carry over to constants, init params, component
> families, renderer types, etc.
>
> -- Adam
>
- Jonas
--
*Author*: Pro JSF and Ajax: Building Rich Internet Components
<http://apress.com/book/bookDisplay.html?bID=10044>
*Blog*: http://www.orablogs.com/jjacobi
Re: ADF Faces package name - a first pass
Posted by Matthias Wessendorf <mw...@gmail.com>.
> First up is a package name. There's no requirement for
> any final decision until we leave incubator, but I'd like
> something better than "oracle.Anything" for the first
> checkin.
+1
> Does "org.apache.myfaces.adf" sound reasonable?
> And "org.apache.myfaces.adfinternal" for all of our
> internal code? ADF Faces uses package partitioning for
> solidified public APIs vs. internal private APIs, and
> I'd like to continue that here.
+1 on that too, since this *reflects* the current structure, only with
the o.a.m.*** in front
> And, FWIW, "org.apache.myfaces.adfbuild" and
> "org.apache.myfaces.adfdemo" for our build tools
> and demo code.
sounds good. Before we leave the incubator, there is also the
possibility to *change* the package issue again. but for now, we
should start on that discussed packages
-Matthias
> This'd also carry over to constants, init params, component
> families, renderer types, etc.
>
> -- Adam
>
--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com
Re: ADF Faces package name - a first pass
Posted by Adam Winer <aw...@gmail.com>.
My goal's to get it done within the next couple of weeks;
this wasn't the best timing relative to my work schedule. :(
-- Adam
On 4/18/06, John Fallows <jo...@gmail.com> wrote:
> On 4/18/06, Adam Winer <aw...@gmail.com> wrote:
> >
> > Yep, that was the rationale. Though I'd be up for using "adfimpl"
> > instead of "adfinternal". I'm a bit fuzzy why we chose
> > "internal" over "impl", but I think there were some other
> > teams around in Oracle that had a meaning for "impl" that
> > didn't jibe with this.
>
>
> Yep, I'd also prefer "impl" over "internal", but either one is okay.
>
> I'm also not in love with having the bonus "api" package level, which
> > is unnecessary with the "adfimpl"/etc. scheme.
>
>
> Agreed.
>
> BTW, nope, I haven't done the repackaging yet - busy at work,
> > and I want to get some branches merged in too before the drop.
> > So, this is definitely still an excellent time to talk about packaging!
>
>
> What is the ETA for a code drop to the repository?
>
> tc,
> -john.
>
> On 4/18/06, John Fallows <jo...@gmail.com> wrote:
> > > On 4/18/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > >
> > > > On 4/18/06, John Fallows <jo...@gmail.com> wrote:
> > > > >
> > > > > On 4/18/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > > > >
> > > > > > Already done the package renaming?
> > > > > > If not, what about having one more additional namespace level:
> > > > > > org.apache.myfaces.adf.api
> > > > > > org.apache.myfaces.adf.internal (or impl? - which sounds more
> > common
> > > > to
> > > > > > me)
> > > > > > org.apache.myfaces.adf.build
> > > > > > org.apache.myfaces.adf.demo
> > > > > >
> > > > > > I think this would separate things even more clearly: All ADF
> > stuff in
> > > > > one
> > > > > > "master" package.
> > > > >
> > > > >
> > > > > Understood. However, the downside of this is that the "internal" /
> > > > > "impl"
> > > > > subpackage would show up during IDE code completion. Branching the
> > > > > package
> > > > > namespace early between API and impl helps to address this issue.
> > > >
> > > >
> > > > Not sure I understood.
> > > > When I add org.apache.myfaces.adf.api (ie the API jar) to my IDE there
> > > > will
> > > > be no code completion for internal/impl
> > > > (org.apache.myfaces.adf.internalpackage). Right?
> > >
> > >
> > > Yes that is correct. However, if you want to actually run the code,
> > you'll
> > > need the impl as well. IDEs don't always make a distinction between
> > > compilation dependencies and runtime dependencies, so the impl stuff
> > tends
> > > to end up on the classpath anyway.
> > >
> > > When users type "org.apache.myfaces.adf." and observe the code
> > completion
> > > suggestions, it would be preferable if the unsupported impl packages are
> > not
> > > shown.
> > >
> > > tc,
> > > -john.
> > > --
> > > http://apress.com/book/bookDisplay.html?bID=10044
> > > Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
> > >
> > >
> >
>
>
>
> --
> http://apress.com/book/bookDisplay.html?bID=10044
> Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
>
>
Re: ADF Faces package name - a first pass
Posted by John Fallows <jo...@gmail.com>.
On 4/18/06, Adam Winer <aw...@gmail.com> wrote:
>
> Yep, that was the rationale. Though I'd be up for using "adfimpl"
> instead of "adfinternal". I'm a bit fuzzy why we chose
> "internal" over "impl", but I think there were some other
> teams around in Oracle that had a meaning for "impl" that
> didn't jibe with this.
Yep, I'd also prefer "impl" over "internal", but either one is okay.
I'm also not in love with having the bonus "api" package level, which
> is unnecessary with the "adfimpl"/etc. scheme.
Agreed.
BTW, nope, I haven't done the repackaging yet - busy at work,
> and I want to get some branches merged in too before the drop.
> So, this is definitely still an excellent time to talk about packaging!
What is the ETA for a code drop to the repository?
tc,
-john.
On 4/18/06, John Fallows <jo...@gmail.com> wrote:
> > On 4/18/06, Manfred Geiler <ma...@gmail.com> wrote:
> > >
> > > On 4/18/06, John Fallows <jo...@gmail.com> wrote:
> > > >
> > > > On 4/18/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > > >
> > > > > Already done the package renaming?
> > > > > If not, what about having one more additional namespace level:
> > > > > org.apache.myfaces.adf.api
> > > > > org.apache.myfaces.adf.internal (or impl? - which sounds more
> common
> > > to
> > > > > me)
> > > > > org.apache.myfaces.adf.build
> > > > > org.apache.myfaces.adf.demo
> > > > >
> > > > > I think this would separate things even more clearly: All ADF
> stuff in
> > > > one
> > > > > "master" package.
> > > >
> > > >
> > > > Understood. However, the downside of this is that the "internal" /
> > > > "impl"
> > > > subpackage would show up during IDE code completion. Branching the
> > > > package
> > > > namespace early between API and impl helps to address this issue.
> > >
> > >
> > > Not sure I understood.
> > > When I add org.apache.myfaces.adf.api (ie the API jar) to my IDE there
> > > will
> > > be no code completion for internal/impl
> > > (org.apache.myfaces.adf.internalpackage). Right?
> >
> >
> > Yes that is correct. However, if you want to actually run the code,
> you'll
> > need the impl as well. IDEs don't always make a distinction between
> > compilation dependencies and runtime dependencies, so the impl stuff
> tends
> > to end up on the classpath anyway.
> >
> > When users type "org.apache.myfaces.adf." and observe the code
> completion
> > suggestions, it would be preferable if the unsupported impl packages are
> not
> > shown.
> >
> > tc,
> > -john.
> > --
> > http://apress.com/book/bookDisplay.html?bID=10044
> > Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
> >
> >
>
--
http://apress.com/book/bookDisplay.html?bID=10044
Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: ADF Faces package name - a first pass
Posted by Adam Winer <aw...@gmail.com>.
Yep, that was the rationale. Though I'd be up for using "adfimpl"
instead of "adfinternal". I'm a bit fuzzy why we chose
"internal" over "impl", but I think there were some other
teams around in Oracle that had a meaning for "impl" that
didn't jibe with this.
I'm also not in love with having the bonus "api" package level, which
is unnecessary with the "adfimpl"/etc. scheme.
BTW, nope, I haven't done the repackaging yet - busy at work,
and I want to get some branches merged in too before the drop.
So, this is definitely still an excellent time to talk about packaging!
-- Adam
On 4/18/06, John Fallows <jo...@gmail.com> wrote:
> On 4/18/06, Manfred Geiler <ma...@gmail.com> wrote:
> >
> > On 4/18/06, John Fallows <jo...@gmail.com> wrote:
> > >
> > > On 4/18/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > >
> > > > Already done the package renaming?
> > > > If not, what about having one more additional namespace level:
> > > > org.apache.myfaces.adf.api
> > > > org.apache.myfaces.adf.internal (or impl? - which sounds more common
> > to
> > > > me)
> > > > org.apache.myfaces.adf.build
> > > > org.apache.myfaces.adf.demo
> > > >
> > > > I think this would separate things even more clearly: All ADF stuff in
> > > one
> > > > "master" package.
> > >
> > >
> > > Understood. However, the downside of this is that the "internal" /
> > > "impl"
> > > subpackage would show up during IDE code completion. Branching the
> > > package
> > > namespace early between API and impl helps to address this issue.
> >
> >
> > Not sure I understood.
> > When I add org.apache.myfaces.adf.api (ie the API jar) to my IDE there
> > will
> > be no code completion for internal/impl
> > (org.apache.myfaces.adf.internalpackage). Right?
>
>
> Yes that is correct. However, if you want to actually run the code, you'll
> need the impl as well. IDEs don't always make a distinction between
> compilation dependencies and runtime dependencies, so the impl stuff tends
> to end up on the classpath anyway.
>
> When users type "org.apache.myfaces.adf." and observe the code completion
> suggestions, it would be preferable if the unsupported impl packages are not
> shown.
>
> tc,
> -john.
> --
> http://apress.com/book/bookDisplay.html?bID=10044
> Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
>
>
Re: ADF Faces package name - a first pass
Posted by John Fallows <jo...@gmail.com>.
On 4/18/06, Manfred Geiler <ma...@gmail.com> wrote:
>
> On 4/18/06, John Fallows <jo...@gmail.com> wrote:
> >
> > On 4/18/06, Manfred Geiler <ma...@gmail.com> wrote:
> > >
> > > Already done the package renaming?
> > > If not, what about having one more additional namespace level:
> > > org.apache.myfaces.adf.api
> > > org.apache.myfaces.adf.internal (or impl? - which sounds more common
> to
> > > me)
> > > org.apache.myfaces.adf.build
> > > org.apache.myfaces.adf.demo
> > >
> > > I think this would separate things even more clearly: All ADF stuff in
> > one
> > > "master" package.
> >
> >
> > Understood. However, the downside of this is that the "internal" /
> > "impl"
> > subpackage would show up during IDE code completion. Branching the
> > package
> > namespace early between API and impl helps to address this issue.
>
>
> Not sure I understood.
> When I add org.apache.myfaces.adf.api (ie the API jar) to my IDE there
> will
> be no code completion for internal/impl
> (org.apache.myfaces.adf.internalpackage). Right?
Yes that is correct. However, if you want to actually run the code, you'll
need the impl as well. IDEs don't always make a distinction between
compilation dependencies and runtime dependencies, so the impl stuff tends
to end up on the classpath anyway.
When users type "org.apache.myfaces.adf." and observe the code completion
suggestions, it would be preferable if the unsupported impl packages are not
shown.
tc,
-john.
--
http://apress.com/book/bookDisplay.html?bID=10044
Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: ADF Faces package name - a first pass
Posted by Manfred Geiler <ma...@gmail.com>.
On 4/18/06, John Fallows <jo...@gmail.com> wrote:
>
> On 4/18/06, Manfred Geiler <ma...@gmail.com> wrote:
> >
> > Already done the package renaming?
> > If not, what about having one more additional namespace level:
> > org.apache.myfaces.adf.api
> > org.apache.myfaces.adf.internal (or impl? - which sounds more common to
> > me)
> > org.apache.myfaces.adf.build
> > org.apache.myfaces.adf.demo
> >
> > I think this would separate things even more clearly: All ADF stuff in
> one
> > "master" package.
>
>
> Understood. However, the downside of this is that the "internal" /
> "impl"
> subpackage would show up during IDE code completion. Branching the
> package
> namespace early between API and impl helps to address this issue.
Not sure I understood.
When I add org.apache.myfaces.adf.api (ie the API jar) to my IDE there will
be no code completion for internal/impl
(org.apache.myfaces.adf.internalpackage). Right?
Manfred
Re: ADF Faces package name - a first pass
Posted by John Fallows <jo...@gmail.com>.
On 4/18/06, Manfred Geiler <ma...@gmail.com> wrote:
>
> Already done the package renaming?
> If not, what about having one more additional namespace level:
> org.apache.myfaces.adf.api
> org.apache.myfaces.adf.internal (or impl? - which sounds more common to
> me)
> org.apache.myfaces.adf.build
> org.apache.myfaces.adf.demo
>
> I think this would separate things even more clearly: All ADF stuff in one
> "master" package.
Understood. However, the downside of this is that the "internal" / "impl"
subpackage would show up during IDE code completion. Branching the package
namespace early between API and impl helps to address this issue.
Kind Regards,
John Fallows.
--
http://apress.com/book/bookDisplay.html?bID=10044
Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: ADF Faces package name - a first pass
Posted by Manfred Geiler <ma...@gmail.com>.
Already done the package renaming?
If not, what about having one more additional namespace level:
org.apache.myfaces.adf.api
org.apache.myfaces.adf.internal (or impl? - which sounds more common to me)
org.apache.myfaces.adf.build
org.apache.myfaces.adf.demo
I think this would separate things even more clearly: All ADF stuff in one
"master" package.
But that's just my 2 cents. Never mind if renaming is already done.
Manfred
On 4/14/06, Adam Winer <aw...@gmail.com> wrote:
>
> While I'm waiting for a clear spot to start checking in,
> we can talk to resolve some basic issues up front.
>
> First up is a package name. There's no requirement for
> any final decision until we leave incubator, but I'd like
> something better than "oracle.Anything" for the first
> checkin.
>
> Does "org.apache.myfaces.adf" sound reasonable?
> And "org.apache.myfaces.adfinternal" for all of our
> internal code? ADF Faces uses package partitioning for
> solidified public APIs vs. internal private APIs, and
> I'd like to continue that here.
>
> And, FWIW, "org.apache.myfaces.adfbuild" and
> "org.apache.myfaces.adfdemo" for our build tools
> and demo code.
>
> This'd also carry over to constants, init params, component
> families, renderer types, etc.
>
> -- Adam
>