beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg <anima...@gmail.com>
Subject Re: "Hornet" controls sandbox
Date Wed, 23 Aug 2006 15:22:53 GMT
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 <kentaminator@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
>

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