You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Greg <an...@gmail.com> on 2006/08/23 17:22:53 UTC
Re: "Hornet" controls sandbox
Ken,
I am trying to build the Hornet controls per your instructions and am
encountering the following error:
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: org.codehaus.plexus:plexus-compiler-api
Reason: Error getting POM for 'org.codehaus.plexus:plexus-compiler-api' from
the repository: Error transferring file
org.codehaus.plexus:plexus-compiler-api:pom:1.5.2
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
apache.snapshots (http://svn.apache.org/maven-snapshot-repository),
snapshots (http://snapshots.maven.codehaus.org/maven2)
Any suggestions on how to resolve this issue is greatly appreciated.
FWIW, I really like your ideas WRT Hornet and would really like to hear some
of your other ideas as well.
-- Greg
On 7/12/06, Kenneth Tam <ke...@gmail.com> wrote:
>
> I just checked in a sandbox project named "Hornet", that has code
> exploring some ideas I'm having about controls. It's a maven2 project
> and should be really easy to build; just sync sandbox/hornet, install
> maven 2.0.4 and run "mvn" inside sandbox/hornet/controls.
>
> Beehive "Hornet"
>
> Guiding Principals
> ==================
>
> Features should be as modular and independent as possible; user buy-in
> can be incremental, you only pay for what you need.
>
> Proposal: Eliminate generated ControlBean construct. All access is
> via control interface, implying that all functionality that used to
> exist only on the controlbean either has to get surfaced to the
> interface, removed, or exposed via some other mechanism.
>
> Benefits: Significantly reduces the complexity of the controls model
> by removing an entire conceptual artifact. Having a generated control
> bean, understanding why it exists and when to use it vs the control
> interface has always been confusing for users. It also complicated
> integration with other technologies, since the controlbean essentially
> defined its own container, complete with injection. Testability is
> improved; you can mock a control by mocking the control interface
> without losing surface area, and instantiation/configuration is
> simplified.
>
> ---
>
> Feature: Control instantiation/declaration:
> ===========================================
>
> Proposal: Simple control instantiation consists merely of calling the
> implementation constructor. Extensible control instantiation consists
> of constructing a dynamic proxy that implements the control interface
> and delegates to the control implementation.
>
> Benefits: Simplifies integration into other frameworks; minimal
> overhead, proxy only when necessary.
>
> ---
>
> Feature: Class and instance level properties:
> =============================================
>
> (Currently, such properties were defined via nested annotation
> definition on the interface, and results in generated accessors on the
> controlbean (a point of some user confusion))
>
> Proposal: Follow standard JavaBean model for class & instance level
> properties -- define them via the presence of accessors on the control
> interface (property name is inferred from the accessor name per
> standard JavaBean property conventions).
>
> Proposal: For class and instance level properties, @PropertySet
> annotations are optional and sub-ordinate to accessors for property
> definition. @PropertySet naming and prefix must correspond to
> accessor names rather than the other way around.
>
> Benefits: Developers already understand what JavaBean properties are;
> rather than force them to think about them in terms of annotations
> (@PropertySets) in order to define them, this makes it clearer that
> annotations are just another (optional) way to set properties -- they
> don't attempt to _define_ properties. Simplifies integration with
> other injection frameworks, which get to treat the interface as a 1st
> class entity (functionality is not hidden). Annotation overriding is
> more obvious (just use the setters). Removes the artifical limitation
> annotations impose on property types.
>
> Drawbacks: Control authors have to think about potentially keeping
> accessor methods & PropertySet annotations synchronized. Tooling is a
> has a straightforward solution to this, but even in its absence,
> command-line compilation tools can help greatly.
>
> Proposal: Expand tooling support for enforcing strong property types
> and constraints on all properties, not just those that are set using
> annotations (ie, allow @AnnotationConstraints and
> @AnnotationMemberTypes functionality to generic JavaBean properties by
> annotating accessors). Note that Spring supports container
> enforcement like this via RequiredAnnotationBeanPostProcessor; we
> could expand this to include "all if any" and other rules in
> @AnnotationConstraints, and provide that support in container-neutral
> form.
>
> ---
>
> Feature: Method and parameter level properties:
> ===============================================
> It's unclear how much real value there is in providing a richer
> backing store for method and param level property data; there are
> namespacing issues, and I haven't seen many interesting usecases for
> being able to set a method-level property via e.g. an accessor -- I'd
> love to hear some and dig into what might be a good model for
> supporting that.
>
> Per the last proposal bullet re: tooling support for enforcing
> property types/constraints, that's definitely a point of continued
> value-add for method and parameter level properties.
>
> ---
>
> Feature: Support for runtime access to method parameter names:
> ==============================================================
>
> Proposal: Explicitly expose parameter name via an @PName annotation on
> parameters.
>
> While the current approach of generating BeanInfo requires less
> authoring, the cost of additional artifact generation is high. Other
> frameworks have addressed the parameter naming problem (c.f. Spring's
> *SqlParameterSource classes), and the language itself is in-flight to
> addressing it (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5082475
> ).
> Requiring an explicit annotation is redundant, but easily tooled, and
> makes the feature very lightweight, modular and pluggable.
>
> There's a ton of other stuff I haven't elaborated on.. getting out of
> the interceptor business, exposing contextual services as just another
> kind of injected dependency, questioning the value of the eventing
> model and how to make it more a la carte, etc.
>
> The sandbox code is really primitive, but my main goal is to
> illustrate some of the points I mention above.. A key to guiding my
> approach here was looking at the system controls (which are probably
> among the more complex and interesting use cases) and trying to see
> how the core functionality they used could be supported in as
> lightweight a fashion as possible. I started with the JDBC control;
> the sandbox has a forked copy to which I made the minimum # of changes
> to get to compile against the the new API/runtime.. no runtime tests
> yet, but it should be pretty close.
>
> k
>
Re: "Hornet" controls sandbox
Posted by Greg Mally <an...@gmail.com>.
Sorry for not replying sooner, but I did try the build later and all worked
fine :-D
I believe your suspicions were correct.
-- Greg
On 9/19/06, Ken Tam <ke...@gmail.com> wrote:
>
> Hi Greg,
>
> I note that the artifact it's complaining about is actually present in
> one of the repos your build is searching (see
>
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-compiler-api/1.5.2/
> ),
> leading me to suspect that it was a transient network problem; that
> often happens when a lot of jars required for the build need to be
> downloaded at once (it's one of the little maven annoyances). Have
> you tried it again?
>
> On 8/23/06, Greg <an...@gmail.com> wrote:
> > Ken,
> >
> > I am trying to build the Hornet controls per your instructions and am
> > encountering the following error:
> >
> > [INFO]
> > ------------------------------------------------------------------------
> > [ERROR] BUILD ERROR
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Error building POM (may not be this project's POM).
> >
> >
> > Project ID: org.codehaus.plexus:plexus-compiler-api
> >
> > Reason: Error getting POM for 'org.codehaus.plexus:plexus-compiler-api'
> from
> > the repository: Error transferring file
> > org.codehaus.plexus:plexus-compiler-api:pom:1.5.2
> >
> > from the specified remote repositories:
> > central (http://repo1.maven.org/maven2),
> > apache.snapshots (http://svn.apache.org/maven-snapshot-repository),
> > snapshots (http://snapshots.maven.codehaus.org/maven2)
> >
> > Any suggestions on how to resolve this issue is greatly appreciated.
> >
> > FWIW, I really like your ideas WRT Hornet and would really like to hear
> some
> > of your other ideas as well.
> >
> > -- Greg
> >
> > On 7/12/06, Kenneth Tam <ke...@gmail.com> wrote:
> > >
> > > I just checked in a sandbox project named "Hornet", that has code
> > > exploring some ideas I'm having about controls. It's a maven2 project
> > > and should be really easy to build; just sync sandbox/hornet, install
> > > maven 2.0.4 and run "mvn" inside sandbox/hornet/controls.
> > >
> > > Beehive "Hornet"
> > >
> > > Guiding Principals
> > > ==================
> > >
> > > Features should be as modular and independent as possible; user buy-in
> > > can be incremental, you only pay for what you need.
> > >
> > > Proposal: Eliminate generated ControlBean construct. All access is
> > > via control interface, implying that all functionality that used to
> > > exist only on the controlbean either has to get surfaced to the
> > > interface, removed, or exposed via some other mechanism.
> > >
> > > Benefits: Significantly reduces the complexity of the controls model
> > > by removing an entire conceptual artifact. Having a generated control
> > > bean, understanding why it exists and when to use it vs the control
> > > interface has always been confusing for users. It also complicated
> > > integration with other technologies, since the controlbean essentially
> > > defined its own container, complete with injection. Testability is
> > > improved; you can mock a control by mocking the control interface
> > > without losing surface area, and instantiation/configuration is
> > > simplified.
> > >
> > > ---
> > >
> > > Feature: Control instantiation/declaration:
> > > ===========================================
> > >
> > > Proposal: Simple control instantiation consists merely of calling the
> > > implementation constructor. Extensible control instantiation consists
> > > of constructing a dynamic proxy that implements the control interface
> > > and delegates to the control implementation.
> > >
> > > Benefits: Simplifies integration into other frameworks; minimal
> > > overhead, proxy only when necessary.
> > >
> > > ---
> > >
> > > Feature: Class and instance level properties:
> > > =============================================
> > >
> > > (Currently, such properties were defined via nested annotation
> > > definition on the interface, and results in generated accessors on the
> > > controlbean (a point of some user confusion))
> > >
> > > Proposal: Follow standard JavaBean model for class & instance level
> > > properties -- define them via the presence of accessors on the control
> > > interface (property name is inferred from the accessor name per
> > > standard JavaBean property conventions).
> > >
> > > Proposal: For class and instance level properties, @PropertySet
> > > annotations are optional and sub-ordinate to accessors for property
> > > definition. @PropertySet naming and prefix must correspond to
> > > accessor names rather than the other way around.
> > >
> > > Benefits: Developers already understand what JavaBean properties are;
> > > rather than force them to think about them in terms of annotations
> > > (@PropertySets) in order to define them, this makes it clearer that
> > > annotations are just another (optional) way to set properties -- they
> > > don't attempt to _define_ properties. Simplifies integration with
> > > other injection frameworks, which get to treat the interface as a 1st
> > > class entity (functionality is not hidden). Annotation overriding is
> > > more obvious (just use the setters). Removes the artifical limitation
> > > annotations impose on property types.
> > >
> > > Drawbacks: Control authors have to think about potentially keeping
> > > accessor methods & PropertySet annotations synchronized. Tooling is a
> > > has a straightforward solution to this, but even in its absence,
> > > command-line compilation tools can help greatly.
> > >
> > > Proposal: Expand tooling support for enforcing strong property types
> > > and constraints on all properties, not just those that are set using
> > > annotations (ie, allow @AnnotationConstraints and
> > > @AnnotationMemberTypes functionality to generic JavaBean properties by
> > > annotating accessors). Note that Spring supports container
> > > enforcement like this via RequiredAnnotationBeanPostProcessor; we
> > > could expand this to include "all if any" and other rules in
> > > @AnnotationConstraints, and provide that support in container-neutral
> > > form.
> > >
> > > ---
> > >
> > > Feature: Method and parameter level properties:
> > > ===============================================
> > > It's unclear how much real value there is in providing a richer
> > > backing store for method and param level property data; there are
> > > namespacing issues, and I haven't seen many interesting usecases for
> > > being able to set a method-level property via e.g. an accessor -- I'd
> > > love to hear some and dig into what might be a good model for
> > > supporting that.
> > >
> > > Per the last proposal bullet re: tooling support for enforcing
> > > property types/constraints, that's definitely a point of continued
> > > value-add for method and parameter level properties.
> > >
> > > ---
> > >
> > > Feature: Support for runtime access to method parameter names:
> > > ==============================================================
> > >
> > > Proposal: Explicitly expose parameter name via an @PName annotation on
> > > parameters.
> > >
> > > While the current approach of generating BeanInfo requires less
> > > authoring, the cost of additional artifact generation is high. Other
> > > frameworks have addressed the parameter naming problem (c.f. Spring's
> > > *SqlParameterSource classes), and the language itself is in-flight to
> > > addressing it (
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5082475
> > > ).
> > > Requiring an explicit annotation is redundant, but easily tooled, and
> > > makes the feature very lightweight, modular and pluggable.
> > >
> > > There's a ton of other stuff I haven't elaborated on.. getting out of
> > > the interceptor business, exposing contextual services as just another
> > > kind of injected dependency, questioning the value of the eventing
> > > model and how to make it more a la carte, etc.
> > >
> > > The sandbox code is really primitive, but my main goal is to
> > > illustrate some of the points I mention above.. A key to guiding my
> > > approach here was looking at the system controls (which are probably
> > > among the more complex and interesting use cases) and trying to see
> > > how the core functionality they used could be supported in as
> > > lightweight a fashion as possible. I started with the JDBC control;
> > > the sandbox has a forked copy to which I made the minimum # of changes
> > > to get to compile against the the new API/runtime.. no runtime tests
> > > yet, but it should be pretty close.
> > >
> > > k
> > >
> >
> >
>
Re: "Hornet" controls sandbox
Posted by Ken Tam <ke...@gmail.com>.
Hi Greg,
I note that the artifact it's complaining about is actually present in
one of the repos your build is searching (see
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-compiler-api/1.5.2/),
leading me to suspect that it was a transient network problem; that
often happens when a lot of jars required for the build need to be
downloaded at once (it's one of the little maven annoyances). Have
you tried it again?
On 8/23/06, Greg <an...@gmail.com> wrote:
> Ken,
>
> I am trying to build the Hornet controls per your instructions and am
> encountering the following error:
>
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Error building POM (may not be this project's POM).
>
>
> Project ID: org.codehaus.plexus:plexus-compiler-api
>
> Reason: Error getting POM for 'org.codehaus.plexus:plexus-compiler-api' from
> the repository: Error transferring file
> org.codehaus.plexus:plexus-compiler-api:pom:1.5.2
>
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> apache.snapshots (http://svn.apache.org/maven-snapshot-repository),
> snapshots (http://snapshots.maven.codehaus.org/maven2)
>
> Any suggestions on how to resolve this issue is greatly appreciated.
>
> FWIW, I really like your ideas WRT Hornet and would really like to hear some
> of your other ideas as well.
>
> -- Greg
>
> On 7/12/06, Kenneth Tam <ke...@gmail.com> wrote:
> >
> > I just checked in a sandbox project named "Hornet", that has code
> > exploring some ideas I'm having about controls. It's a maven2 project
> > and should be really easy to build; just sync sandbox/hornet, install
> > maven 2.0.4 and run "mvn" inside sandbox/hornet/controls.
> >
> > Beehive "Hornet"
> >
> > Guiding Principals
> > ==================
> >
> > Features should be as modular and independent as possible; user buy-in
> > can be incremental, you only pay for what you need.
> >
> > Proposal: Eliminate generated ControlBean construct. All access is
> > via control interface, implying that all functionality that used to
> > exist only on the controlbean either has to get surfaced to the
> > interface, removed, or exposed via some other mechanism.
> >
> > Benefits: Significantly reduces the complexity of the controls model
> > by removing an entire conceptual artifact. Having a generated control
> > bean, understanding why it exists and when to use it vs the control
> > interface has always been confusing for users. It also complicated
> > integration with other technologies, since the controlbean essentially
> > defined its own container, complete with injection. Testability is
> > improved; you can mock a control by mocking the control interface
> > without losing surface area, and instantiation/configuration is
> > simplified.
> >
> > ---
> >
> > Feature: Control instantiation/declaration:
> > ===========================================
> >
> > Proposal: Simple control instantiation consists merely of calling the
> > implementation constructor. Extensible control instantiation consists
> > of constructing a dynamic proxy that implements the control interface
> > and delegates to the control implementation.
> >
> > Benefits: Simplifies integration into other frameworks; minimal
> > overhead, proxy only when necessary.
> >
> > ---
> >
> > Feature: Class and instance level properties:
> > =============================================
> >
> > (Currently, such properties were defined via nested annotation
> > definition on the interface, and results in generated accessors on the
> > controlbean (a point of some user confusion))
> >
> > Proposal: Follow standard JavaBean model for class & instance level
> > properties -- define them via the presence of accessors on the control
> > interface (property name is inferred from the accessor name per
> > standard JavaBean property conventions).
> >
> > Proposal: For class and instance level properties, @PropertySet
> > annotations are optional and sub-ordinate to accessors for property
> > definition. @PropertySet naming and prefix must correspond to
> > accessor names rather than the other way around.
> >
> > Benefits: Developers already understand what JavaBean properties are;
> > rather than force them to think about them in terms of annotations
> > (@PropertySets) in order to define them, this makes it clearer that
> > annotations are just another (optional) way to set properties -- they
> > don't attempt to _define_ properties. Simplifies integration with
> > other injection frameworks, which get to treat the interface as a 1st
> > class entity (functionality is not hidden). Annotation overriding is
> > more obvious (just use the setters). Removes the artifical limitation
> > annotations impose on property types.
> >
> > Drawbacks: Control authors have to think about potentially keeping
> > accessor methods & PropertySet annotations synchronized. Tooling is a
> > has a straightforward solution to this, but even in its absence,
> > command-line compilation tools can help greatly.
> >
> > Proposal: Expand tooling support for enforcing strong property types
> > and constraints on all properties, not just those that are set using
> > annotations (ie, allow @AnnotationConstraints and
> > @AnnotationMemberTypes functionality to generic JavaBean properties by
> > annotating accessors). Note that Spring supports container
> > enforcement like this via RequiredAnnotationBeanPostProcessor; we
> > could expand this to include "all if any" and other rules in
> > @AnnotationConstraints, and provide that support in container-neutral
> > form.
> >
> > ---
> >
> > Feature: Method and parameter level properties:
> > ===============================================
> > It's unclear how much real value there is in providing a richer
> > backing store for method and param level property data; there are
> > namespacing issues, and I haven't seen many interesting usecases for
> > being able to set a method-level property via e.g. an accessor -- I'd
> > love to hear some and dig into what might be a good model for
> > supporting that.
> >
> > Per the last proposal bullet re: tooling support for enforcing
> > property types/constraints, that's definitely a point of continued
> > value-add for method and parameter level properties.
> >
> > ---
> >
> > Feature: Support for runtime access to method parameter names:
> > ==============================================================
> >
> > Proposal: Explicitly expose parameter name via an @PName annotation on
> > parameters.
> >
> > While the current approach of generating BeanInfo requires less
> > authoring, the cost of additional artifact generation is high. Other
> > frameworks have addressed the parameter naming problem (c.f. Spring's
> > *SqlParameterSource classes), and the language itself is in-flight to
> > addressing it (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5082475
> > ).
> > Requiring an explicit annotation is redundant, but easily tooled, and
> > makes the feature very lightweight, modular and pluggable.
> >
> > There's a ton of other stuff I haven't elaborated on.. getting out of
> > the interceptor business, exposing contextual services as just another
> > kind of injected dependency, questioning the value of the eventing
> > model and how to make it more a la carte, etc.
> >
> > The sandbox code is really primitive, but my main goal is to
> > illustrate some of the points I mention above.. A key to guiding my
> > approach here was looking at the system controls (which are probably
> > among the more complex and interesting use cases) and trying to see
> > how the core functionality they used could be supported in as
> > lightweight a fashion as possible. I started with the JDBC control;
> > the sandbox has a forked copy to which I made the minimum # of changes
> > to get to compile against the the new API/runtime.. no runtime tests
> > yet, but it should be pretty close.
> >
> > k
> >
>
>