maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cobb, Randal" <>
Subject Re: Get thee to the Core...
Date Thu, 09 Jun 2011 16:57:10 GMT

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

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:
@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

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

* 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:

if anyone is interested...

- blogs explaining the way to do various tasks inside the
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 (

To unsubscribe, e-mail:
For additional commands, e-mail:

Randal Cobb

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.

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