The layout you propose sounds reasonable to me. On Thu, Aug 15, 2019 at 08:32, sebb <seb...@gmail.com> wrote:
> The Ruby tool and some sample output: > > http://svn.apache.org/repos/asf/commons/scripts/ > examples/ > pomskel.rb > > On Thu, 15 Aug 2019 at 14:08, sebb <seb...@gmail.com> wrote: > > > > On Thu, 15 Aug 2019 at 13:06, Claude Warren <cla...@xenei.com> wrote: > > > > > > Since the POM is an XML document how about a simple XSLT that will > convert > > > them all to the same format. > > > > Unfortunately I don't think it's simple. > > > > Comments on their own line apply to the following tag -- but not always. > > And a comment at the end of a line applies to the line it is on, but > > appears after it in the DOM. > > There may be some white-space issues as well. > > > > > Alternatively an XML diff could be performed where each leaf node is > > > contextualized by generating the the path from the root to the leaf, > the > > > can be sorted and a standard diff performed to determine where they are > > > different. > > > > I've written a simple Ruby script to produce a skeleton file showing > > the major components. > > This can be used to analyse the existing layouts. > > Once a standard has been chosen, the tool can show which sections need > > to be moved. > > > > > The above being said, having a standard POM format makes sense to me. > > > > Great. > > > > > Claude > > > > > > On Thu, Aug 15, 2019 at 11:40 AM sebb <seb...@gmail.com> wrote: > > > > > > > I think it might be useful to try to work towards standardising the > > > > order of sections within POMs. > > > > > > > > This will make it easier to compare them across components. > > > > (e.g. to see why one pom works and another fails!) > > > > And should be easier to maintain. > > > > > > > > In particular, I would like to move the developer and contributor > > > > sections to the end. > > > > They can be quite long, so they make it harder to read the pom. > > > > > > > > Also to move properties near the beginning, as they are the most > > > > likely to need change. > > > > i.e. the main custom elements should be near the start. > > > > > > > > I'm hoping that many poms will have a similar layout (probably many > > > > were copied from another component). > > > > > > > > Maybe start by extracting layouts from existing poms to create a few > > > > skeleton poms. > > > > Once a suitable layout has been agreed, components can be updated as > > > > they are worked on. > > > > > > > > Poms have a very regular structure, so it should be possible to > > > > automate a lot of the work. > > > > > > > > Thoughts? > > > > > > > > I have had a look at the Maven Model [1] and Maven Code Style [2], > > > > however I don't think they are suitable. The developer/contributor > > > > sections are in the middle, which makes navigation harder. > > > > Also the customised sections are scattered throughout. > > > > > > > > Sebb. > > > > [1] https://maven.apache.org/ref/3.6.1/maven-model/maven.html > > > > [2] > > > > > http://maven.apache.org/developers/conventions/code.html#POM_Code_Convention > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > -- > > > I like: Like Like - The likeliest place on the web > > > <http://like-like.xenei.com> > > > LinkedIn: http://www.linkedin.com/in/claudewarren > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker <boa...@gmail.com>
