Re: Get thee to the Core...

[Benson Margulies <bi...@gmail.com>]

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 <he...@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 <he...@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 <jd...@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-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

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