I'll fix it. Thanks!
On 02/18/2013 04:45 PM, Pete Muir wrote:
https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/CONTRIBUTING.md
On 18 Feb 2013, at 21:39, Sande Gilda <sgilda(a)redhat.com> wrote:
> Thanks Pete. The link in the quickstart root directory /CONTRIBUTING.md file seems to
be wrong. :-)
>
>
http://www.jboss.org/jdf/about/contributing/
>
> This gives an "Oops! Something's wrong...
>
> On 02/18/2013 04:23 PM, Pete Muir wrote:
>> The license we recommend people to use in our CONTRIBUTING.md is approved by
legal.
>>
>> On 18 Feb 2013, at 20:48, Sande Gilda
>> <sgilda(a)redhat.com>
>> wrote:
>>
>>
>>> Is there a version of the license that has been approved by legal? For
>>> example, I noticed some of these have a year, some have a variable
>>> '${year}, and some have no year.
>>>
>>> On 02/18/2013 03:20 PM, Jason Porter wrote:
>>>
>>>> Inline
>>>>
>>>> ----- Original Message -----
>>>>
>>>>> From: "Rafael Benevides" <benevides(a)redhat.com>
>>>>>
>>>>> To: "jdf-dev"
>>>>> <jdf-dev(a)lists.jboss.org>
>>>>>
>>>>> Sent: Monday, February 18, 2013 12:56:05 PM
>>>>> Subject: Re: [jdf-dev] Quickstarts and Tooling Automation - License
Header
>>>>>
>>>>>
>>>>> Hi all.
>>>>>
>>>>> The License Header check is on the way. But I have some thoughts
that
>>>>> I would like to share and ask your opinion.
>>>>>
>>>>> - I'm using the Checkstyle API to verify for the License Header.
Even
>>>>> using RegexpHeader, the check is made line by line. " Checks
the
>>>>> header of a source file against a header that contains a regular
>>>>> expression for each line of the source header." (
>>>>>
>>>>>
http://checkstyle.sourceforge.net/config_header.html
>>>>> )
>>>>>
>>>> Gotta ask why you're using the regexp version and not the file
version. I've found the regexp one to be a pain to maintain long term, but I suppose
it *can* less restrictive based on how you craft your rexegp.
>>>>
>>>>
>>>>> - We instruct the users to use some specific headers:
>>>>>
>>>>>
http://www.jboss.org/jdf/quickstarts/get-involved/
>>>>>
>>>>>
>>>>> - We also instructs the users to use the following ide
>>>>> templates/format but these templates differ from what we propose:
>>>>>
>>>>>
https://github.com/jboss/ide-config/blob/master/eclipse/jboss-java-templa...
>>>>>
>>>>>
>>>>> - Some quickstarts comming from other repos have their header
>>>>> modified like on this commit:
>>>>>
>>>>>
https://github.com/jboss-jdf/jboss-as-quickstart/commit/605d877b38f280a32...
>>>> Personally if we're seeing changes like this with a license I'd
flag it and get it fixed.
>>>>
>>>>
>>>>> So I ask you what should be better to use on the quickstarts tools ?
>>>>>
>>>>> 1 - Make IDE/JDF Site similar and refactor all non-compliant
>>>>> quickstarts? (Inflexible)
>>>>>
>>>>> 2 - Use another plugin
>>>>>
http://code.google.com/p/maven-license-plugin/
>>>>>
>>>>> that has the feature to include many distinguished and valid headers
>>>>> (Less restrictive)
>>>>>
>>>>> 3 - Manually check if the first lines of the file contains the
>>>>> following patterns: "JBoss, Home of Professional Open
Source" and
>>>>> "Licensed under the Apache License" (Almost without
restrictions on
>>>>> format)
>>>>>
>>>>> Until what point should we be too restrictive or not for this
>>>>> checking ?
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> Em 14/02/13 18:25, Rafael Benevides escreveu:
>>>>>
>>>>>
>>>>> 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
>>>> _______________________________________________
>>>> jdf-dev mailing list
>>>>
>>>> jdf-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jdf-dev
>>> _______________________________________________
>>> jdf-dev mailing list
>>>
>>> jdf-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jdf-dev