[parent] roadmap to version 1

[Simone Tripodi <si...@apache.org>]

Hi all,

before releasing the first onami parent, I'd like to discuss few points:

 * scm-plugin: I didn't understand why its configuration cannot be
declared just in the parent so it can be inherited by all modules, I
also tried to code something on ONAMI-14 but didn't have enough time
to test/complete it;

 * javadoc versions, this is something Stuart hopefully can help:
Google Guice documentation[1] supports a nice "Filter by API Level"
filter that would help on keeping one single entry-point for APIdocs,
rather than having 1 set of javadoc for each released version; there
is also the javadoc-diff that is interesting and would be nice to have
it;

 * code conventions: while everybody agrees that the ALv2.0 header is
mandatory, I'm for giving freedom to each component to chose the
preferred source code convention, the most important thing IMHO is
that when choosing a convention it is respected. This is something to
setup at parent level, since at 99soft we were Maven's conventions
fans and we just set that one :P

 * anything else?

TIA, all the best,
-Simo

[1] http://google-guice.googlecode.com/git/javadoc/packages.html

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

Re: [parent] roadmap to version 1

[Simone Tripodi <si...@apache.org>]

Hi Christian,

thanks a lot, priceless feedback! It helped me looking at things from
a different point of view.
While having freedom would be good, having a shared, agreed common
convention would be much better to make component consistent to the
ecosystem. It would be like a group of people living in a village
respecting the same code of conduct. The Maven community is a good
sample to follow on that.
I like that way of thinking and I am +1 on what you said.

Personally I'm +1 (of course) on keeping the original codestyle, since
no additional work has to be done on migrating components.

The checkstyle-plugin has already been configured (see below) to use
the checkstyle rules provided by the plugin itself, that makes easier
to have them shared across modules.
So checkstyle reports should be already available and they are
non-blocking during the build.

Thanks again, all the best!
-Simo

+--------------------+
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-checkstyle-plugin</artifactId>
        <version>2.9.1</version>
        <configuration>
          <configLocation>config/maven_checks.xml</configLocation>
          <headerLocation>config/maven-header.txt</headerLocation>
        </configuration>
        <inherited>true</inherited>
        <reportSets>
          <reportSet>
            <reports>
              <report>checkstyle-aggregate</report>
            </reports>
          </reportSet>
        </reportSets>
      </plugin>
+--------------------+

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Dec 5, 2012 at 9:54 AM, Christian Grobmeier <gr...@gmail.com> wrote:
> Can't say anything on the other items, but:
>
> On Wed, Dec 5, 2012 at 12:06 AM, Simone Tripodi
> <si...@apache.org> wrote:
>>  * code conventions: while everybody agrees that the ALv2.0 header is
>> mandatory, I'm for giving freedom to each component to chose the
>> preferred source code convention, the most important thing IMHO is
>> that when choosing a convention it is respected. This is something to
>> setup at parent level, since at 99soft we were Maven's conventions
>> fans and we just set that one :P
>
> I am in favor to have one code convention for all components.
>
> It really annoys me all the time at Commons: every each component does
> have different rules of writing code. Once I get used to a style, I
> need to adapt another. Although I am not a fan of the Maven
> conventions, I still would like to suggest the following we ask
> initial developers on this list if they are fine with the Mvn
> conventions. If yes, please make it sticky for the whole project.
> Commons feels much like a mess to me. Once done i also suggest we
> include a checkstyle test. It should not break the build, if that is
> possible. If that is not possible we could distribute the checkstyle
> rules for our IDEs in the /svn/onami/committers folder
>
> That all said, I am ready for adapting the Maven style and prefer it
> before long redundant discussion on code formatting of various
> components
>
> Cheers
> Christian

Re: [parent] roadmap to version 1

[Christian Grobmeier <gr...@gmail.com>]

Can't say anything on the other items, but:

On Wed, Dec 5, 2012 at 12:06 AM, Simone Tripodi
<si...@apache.org> wrote:
>  * code conventions: while everybody agrees that the ALv2.0 header is
> mandatory, I'm for giving freedom to each component to chose the
> preferred source code convention, the most important thing IMHO is
> that when choosing a convention it is respected. This is something to
> setup at parent level, since at 99soft we were Maven's conventions
> fans and we just set that one :P

I am in favor to have one code convention for all components.

It really annoys me all the time at Commons: every each component does
have different rules of writing code. Once I get used to a style, I
need to adapt another. Although I am not a fan of the Maven
conventions, I still would like to suggest the following we ask
initial developers on this list if they are fine with the Mvn
conventions. If yes, please make it sticky for the whole project.
Commons feels much like a mess to me. Once done i also suggest we
include a checkstyle test. It should not break the build, if that is
possible. If that is not possible we could distribute the checkstyle
rules for our IDEs in the /svn/onami/committers folder

That all said, I am ready for adapting the Maven style and prefer it
before long redundant discussion on code formatting of various
components

Cheers
Christian