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?

> - 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.

> 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/%... > - And probable new others like BRMS, Fuse and Switchyard Quickstarts.

> > -- > 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

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/%... >> - 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 >> >

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-us... 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/%... >>> - 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 >> >

I'm pleased to announce the first release candidate of the 1.2 series of QSTools. - I expect to have no more false violations or "you can ignore that violation". It is now much more flexible than the 1.0 series. The configuration is now centralized on github repo: Check it out the possible configurations: https://github.com/jboss-jdf/qstools/blob/master/config/qstools_config.yaml We can now add different configuration rules for each quickstarts (as it was made for jpp quickstarts and it is probable that we will have to add fuse, drools and spring quickstarts specific rules, very soon) - they will be added on demand. Main changes from 1.0: - Different rules for different quickstarts - Configuration centralized online. - Enhancement of Readmechecker - It now also checks the if the Readme metadata values are the expected values for tags like "Target Product", Level, etc. - Enhancement of BomVersionChecker - You can now define a expected bom version instead of using stacks (useful for upstream projects) - Enhancement of MavenCentralRepositoryChecker to permit skiping of this checker (useful for project quickstarts) - https://issues.jboss.org/browse/JDF-433 - Enhancement of the QSTools to read the .quickstarts_ignore file and ignore those quickstarts (useful for top level folders) - Created a PomNameChecker that checks the pom name against the pattern defined at https://issues.jboss.org/browse/JDF-430 You can try it running mvn org.jboss.maven.plugins:maven-qstools-plugin:1.2.0.CR1:check Antoine, Can you check if the behavior of this version under fuse quickstarts? If you find some bug, please let me know. Thanks Em 17/07/13 16:43, Rafael Benevides escreveu: > Amazing job, Sande! > > Thanks. It was more than I expected. > > I saw your questions and I'll review it as I get close to modify QSTools. > > I'm working on Drools examples and I'd like to have QSTools to make the job for me. So it is probable that I'll update it (depending on the necessary effort) to have it prepared to handle quickstarts from different sources and use it on Drools examples. > > Thanks once more > > > Em 17/07/13 14:52, Sande Gilda escreveu: >> 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 >> >> 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/%... >>>>> - 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 >>>> >>> >> > > > > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jdf-dev