[jdf-dev] QSTools - Quickstarts tooling automation update to meet remote quickstarts

[Sande Gilda]

My first cut at modifying the QSTools to verify by product is under " 
Modify the QSTools to use Product Specific Requirements" here: 
https://docspace.corp.redhat.com/docs/DOC-132902 
<https://docspace.corp.redhat.com/docs/DOC-132902#modify-the-qstools-to-use-product-specific-requirements>

Feedback and suggestions are welcome!

On 07/15/2013 08:51 PM, Rafael Benevides wrote:
>
> Em 15/07/13 20:54, Sande Gilda escreveu:
>>
>> On 07/15/2013 06:18 PM, Rafael Benevides wrote:
>>> Hi all, Sande and Pete,
>>>
>>> One significant change in JDF Quickstarts repo is the use of git 
>>> submodules to bring remote quickstarts to JDF. But... Sometimes 
>>> remote quickstarts doesn't ( and don't want/need to ) follow JDF 
>>> Contributing guide ( 
>>> https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/CONTRIBUTING.md 
>>> ).
>>>
>>> There are some requirements from QSTools ( 
>>> https://docspace.corp.redhat.com/docs/DOC-132902 ) that I believe 
>>> that we should update to split in two categories ( desired and 
>>> mandatory ).
>>>
>>> The definitions bellow are what I see differences across JBoss projects:
>>>  - package and groupId name (of course) - We already defined that 
>>> using org.jboss.quickstarts.(eap|wfk|...) is optional from other 
>>> Quickstarts (not JDF) but should be consistent within the product
>> Agreed. Could we define properties or some other type of file that 
>> could define the valid packages, groups, etc for each product?
>
> Yes. That's Pete's suggestion. We could keep this definition file on 
> QStools github repo. I thought in a yaml format to keep it.
>
> Sande, Can you edit the QSTools requirement docspace to define what 
> should be a "per product" Checker ? Nobody other than you is the best 
> to provide this definition. I understand that what will not be a "per 
> product" Checker, it should be a mandatory instruction.
>
> With this in hand I can start a QSTools refactoring. I was wondering 
> that a "per product" violation is a "warning" level violation and I'll 
> sign it on QSTools report with a yellow color. In a mandatory 
> violation I'll sign it with a red color.
>
> I'm trying to make QSTools a tooling to help us and it should be 
> update as we need. But recently, the reported violations seems more a 
> barrier than a gate.
>
> Pete,
>
> Any objections ?
>>>  - License Headers
>> Yes. We saw this with the Spring-based quickstarts that originate 
>> elsewhere. I'd still like to see this reported in case they are EAP 
>> quickstarts.
>>>  - Spacing and Indentation formats
>>>
>> I don't see this as being something someone would object too. But 
>> maybe I'm wrong? Again, I'd still like to see this reported in case 
>> they are EAP quickstarts.
>>
> One example: The Infinispan project is the one who uses a different 
> format. They use 3-space for indentation.
>
>>> What do you think? Is it it desired to be more or less restrictive 
>>> for other quickstarts and also turn it in an automated pattern?
>>>
>>> I'm bringing this discussion mainly because it is a recurrent 
>>> discussion for remote projects like
>>> - Infinispan: 
>>> https://github.com/infinispan/jdg-quickstart/pull/20#issuecomment-20968520
>>> - GateIn: 
>>> http://transcripts.jboss.org/channel/irc.freenode.org/%23jboss-jdf/2013/%23jboss-jdf.2013-06-21.log.html#t2013-06-21T13:39:31
>>> - And probable new others like BRMS, Fuse and Switchyard Quickstarts.
> - Adding Spring Quickstarts to the list :)
>>>
>>> -- 
>>> 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
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jdf-dev/attachments/20130717/89f32075/attachment.html