I opened MNG-5119 to track this. We can use the Wiki too [2], if useful at any 
time.
I already did some minor improvements and published 3.0.4-SNAPSHOT site [3] 
(sync pending) to see the actual state, to be compared with 3.0.3 [4]

I'm starting to test ideas on shared components, since they are the other 
place where components (not plugins) need documentation improvement

Regards,

Hervé

[1] http://jira.codehaus.org/browse/MNG-5119

[2] https://cwiki.apache.org/confluence/display/MAVEN/Proposals

[3] http://maven.apache.org/ref/3.0.4-SNAPSHOT/

[4] http://maven.apache.org/ref/3.0.3/

Le samedi 18 juin 2011, Benson Margulies a écrit :
> Returning to the very start of this thread:
> 
> Now that I seem to have caught up with my current box of itches on
> plugins for the moment, I'd be more than happy to join this parade.
> Could some more experience committer grab a defect JIRA that has a
> some value to it, throw it up here on the list, and shout 'pull'?
> 
> On Mon, Jun 13, 2011 at 5:25 PM, Hervé BOUTEMY <herve.bout...@free.fr> 
wrote:
> > While we have a good standard for plugin site organization [1] that was
> > debated a few years ago to improve Maven documentation, we have nothing
> > for components. And the actual state is not good: see Maven core, where
> > even simplest description of every component is not done but inherited
> > from parent...
> > 
> > I think we could define something for components like plugins, relatively
> > easy to follow and definitely useful as a starting point.
> > I have a few ideas:
> > - a site descriptor with links to javadoc and jxr (since code is the most
> > important thing expected from components), and a FAQ
> > - an introduction with a list of component interfaces and implementations
> > provided (I have no precise idea on the form)
> > 
> > Any other idea?
> > 
> > I'll try to implement some ideas on Maven core for the next version:
> > we'll write a guide later with practices found.
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1]
> > http://maven.apache.org/guides/development/guide-plugin-documentation.ht
> > ml
> > 
> > Le vendredi 10 juin 2011, Evgeny Mandrikov a écrit :
> >> HI all,
> >> Just my 2 cents :
> >> 
> >> Main problem with jumping into Maven core development is understanding
> >> of internal architecture and core parts. Also this affects development
> >> of plugins. Thus IMO improving this can definitely animate Maven
> >> ecosystem (Core, Core Plugins, Mojo, ...) in general.
> >> 
> >> Another point is that improving core without visible user features
> >> doesn't bring a lot of value. But such things (like slf4j, @Inject)
> >> also interesting as a paralel process together with new features.
> >> 
> >> On Thu, Jun 9, 2011 at 20:21, John Casey <jdca...@commonjava.org> 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
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to