Hello, I've only been lurking on the dev@ list for a couple of months, so, some of these may have already been asked, shot-down, stomped on like a cockroach, etc. but I've used maven for a couple of years now and wondered.... I caveat my requests/suggestions with: These could already be intended in the suggestions below, but with me not being familiar with the intent or detail of all the forwarded suggestions below, please feel free to slap me if they are well known intents. Also, my comments may not even be considered "core", but they are something I've always wondered about, so I'm throwing them out there; you did say "fresh ideas"...:
Why not allow an expanded dialect for the pom files (if it's not already in progress)? By that I mean open-up the format via some sort of plugin mechanism or core support so pom files could be written in other languages aside from XML. Perhaps something like JSON? I'm no JSON expert, but it seems to be alot less hand-coding and concise when compared to XML and could lead to much less tedium when writing poms by hand and should be just as flexible. No intention to start a war with this comment, it's just always been a curiosity point for me. Not even close to any sort of "thorough thought-out process", but, what about adding an annotation mechanism to source files that Maven could use in-lieu of a pom file? It may require a pre-processor of some sort to get the proverbial ball rolling, but could be almost entirely dynamic from there. For example, if a class is annotated with something such as this: @MVN package com.foo; @MVNDep(groupId="bar", artifactID="bar", version="1.0", ...) import bar.baz.MyDep ... could tell a maven plugin/pre-processor task to dynamically build a pom in-memory (or even serialized output to a physical pom file). Classes that aren't annotated could be excluded from the dynamic pom or use the default dynamic generated pom. Regardless, those were just a few of my ramblings... On Jun 9, 2011, at 12:21 PM, John Casey wrote: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven components. Or rather, how does Maven go about doing a particular task? Maybe this would turn into documentation eventually...but I almost see it as more of a forum at first. We have email for this, and that will be the eventual response, that we should use email...but blogs are so much more accessible from places like feedly and google. I think we need to create documentation that is accessible from the main site. Perhaps the tooling isn't quite there to do that easily. Personally I'd love to see a beginners walkthrough of how maven is architected with diagrams and links to the code. Yes, documentation is the bane of most open-source projects...and we certainly have a weakness there. Part of the documentation needs to be fueled by a wish list from the community though...I'm too close to things personally to know which parts aren't easy to understand. :-) It's on my todo list, but that would require time to actually work on that list. Brett's last thing was "All good things to discuss on the dev list :)". -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Randal Cobb [cid:image001.gif@01CC160B.14BC0720] ADP Workforce Now / Configuration Management Norcross Campus | 678-825-7391 (Blackberry) ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
