I took a run at JXR-88, and ended up creating JXR-89, which claims that aggregation is not functional at all in JXR at the moment. I'd be happy to be proved confused.
On Sun, Jun 19, 2011 at 4:33 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org