Re: [jdf-dev] Quickstarts and Tooling Automation

Sonar looks like it would help a lot, and we can extend it with our own custom rules. There is an instance running internally at Red Hat, and it probably wouldn't be a bad idea to get CI setup for these as well (I think we talked about that actually). Then Sonar could simply be another job that's run. We could also tie this into Github and perhaps Gerrit to test pull requests before we merge them. Note I'm not entirely familiar with the solution(s) for this, but I do know it's doable. ----- Original Message ----- > From: "Rafael Benevides" <benevides(a)redhat.com&gt; > To: "jdf-dev" <jdf-dev(a)lists.jboss.org&gt; > Sent: Thursday, February 14, 2013 1:25:06 PM > Subject: [jdf-dev] Quickstarts and Tooling Automation > > > Hi all, > > JDF is growing each day. As a consequence, keep the quickstarts > consistent is becoming a hard work. > > To mitigate this and help the maintenance of the quickstart and also > to help the contributors to see if their quickstarts are ready to > review, we are planning and starting the development of a tooling > for quickstart automation. > > This tool will make use of some other well know and opensource > projects like PMD (pmd.sf.net), checkstyke (checkstyle.sf.net), > Maven Enforcer plugin, etc to attend the following requirements: > > > > * Validating quickstart POM files: > * Check for the License header ( checkstyle headers ) > * Check for proper spacing and Indentation (try checkstyle - > whitespace rule and indentation rule ) > * Check and verify if all quickstarts are using the > same/latest BOM versions > * Verify is it using the standard properties names (We will > provide the standard properties name) > * Check for non bom versions (and identify if we should > create a new BOM) > * Check javascript and css versions > * Check for duplicate properties and dependencies > * Check the pom.xml elements order > * Create scripts to update versions (quickstart, boms, etc) > * When a new quickstart is added, if it has a pom.xml file, > make sure the <module> is defined in one of the following > profiles: default, requires-postgres, complex-dependencies, > requires-full, requires-xts, non-maven. > > > > > * Validating quickstart README files: > * Check for the required metadata tags in README (Level, > Author, Target Product, etc) > * Verify the quickstart name in the README matches the folder > name and the project name > > > > > * Validating quickstart source code > * Check the quantity of comments in the code (evaluate PMD ) > > > > > * General validation (desired): > * If a quickstart with a source other than the current > repository is modified, create an alert of some sort so we > can notify the upstream repository of the change. > * When we update a BOM property version in the quickstarts, > we need to make the same changes in the archetypes. > * Also, if there is a code fix in the kitchensink or > kitchensink-ear, we need to make the same fix in the > archetype code and check other quickstarts based on the same > archetype to see if they need the fixes applied. > > If you have some comments, I will be glad to hear you. > > Thanks > -- > Rafael Benevides | Senior Software Engineer > Red Hat Brazil > +55-61-9269-6576 > > Better technology. Faster innovation. Powered by community > collaboration. > See how it works at redhat.com > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jdf-dev