beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Mally" <anima...@gmail.com>
Subject Re: "Hornet" controls sandbox
Date Wed, 20 Sep 2006 01:50:33 GMT
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 <kentaminator@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 <animally@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 <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