commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [ALL] POM file standardisation of layout
Date Thu, 15 Aug 2019 21:54:31 GMT
I've produced a draft layout on the Wiki.
Comments welcome!
https://cwiki.apache.org/confluence/x/yg94Bw

On Thu, 15 Aug 2019 at 14:43, Matt Sicker <boards@gmail.com> wrote:
>
> The layout you propose sounds reasonable to me.
>
> On Thu, Aug 15, 2019 at 08:32, sebb <sebbaz@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 <sebbaz@gmail.com> wrote:
> > >
> > > On Thu, 15 Aug 2019 at 13:06, Claude Warren <claude@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 <sebbaz@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-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > --
> Matt Sicker <boards@gmail.com>

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


Mime
View raw message