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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >
