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