You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Olivier Lamy <ol...@apache.org> on 2013/01/09 11:16:00 UTC
ETA SvnPubSub site migration
Hi Folks,
I have started importing some content for sub projects (exec,
collections). I will try to do more later.
Where is the place to document that ?
Note: currently some content is imported which could be removed (I
think about cobertura for modules which use sonar).
What is the status about moving cobertura to a dedicated profile in
parent pom ?
Can I move it to a reporting profile in parent pom ?
Thanks,
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Olivier Lamy <ol...@apache.org>.
2013/1/9 Gary Gregory <ga...@gmail.com>:
> On Wed, Jan 9, 2013 at 8:11 AM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
>> On Wed, Jan 09, 2013 at 07:25:45AM -0500, Gary Gregory wrote:
>> > IMO code coverage should be part of the standard documentation for a
>> > component. Looking at code coverage helps establish or shake my
>> > confidence in a component. It should definitively be part of ones
>> > development checklist, I like to have the best code coverage for any
>> > new code that I check in.
>> >
>> > Gary
>> >
>> > On Jan 9, 2013, at 5:16, Olivier Lamy <ol...@apache.org> wrote:
>> >
>> > > Hi Folks,
>> > > I have started importing some content for sub projects (exec,
>> > > collections). I will try to do more later.
>> > >
>> > > Where is the place to document that ?
>> > >
>> > > Note: currently some content is imported which could be removed (I
>> > > think about cobertura for modules which use sonar).
>> > >
>> > > What is the status about moving cobertura to a dedicated profile in
>> > > parent pom ?
>> > > Can I move it to a reporting profile in parent pom ?
>> > >
>>
>> For [Math] it would be much better (since AFAIK nobody came up with a way
>> to
>> disable Cobertura on a per-component basis).
>>
>> From what I infer from looking at the Sonar report page, we could have the
>> best of all worlds if every Commons project were registered indepently in
>> Sonar. Currently, there is one "Commons Proper Aggregator Project
>> 1.0-SNAPSHOT" (which does not represent the actual situation that the
>> components are independent from each other). However, it seems that with
>> several projects registered, it could be possible to compare two versions
>> of the same project, thereby providing complete information on the
>> evolution
>> of the code. Am I wrong?
>>
>
> Sonar has no value for local development though (before you commit). I need
> the reports to run locally when, for example, I am improving code coverage,
> fixing FindBugs, PMD, and Checkstyle issues.
>
will be still possible with adding -Preporting
> Gary
>
>
>>
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
--
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Olivier Lamy <ol...@apache.org>.
2013/1/9 Phil Steitz <ph...@gmail.com>:
> On 1/9/13 7:14 AM, Olivier Lamy wrote:
>> What about having a reporting profile (enabled per default).
>> And using -DskipReports to not generated cobertura, findbugs etc..
>>
>> Perso I like this idea as currently when you want to test a typo fix
>> in a .apt or .xdoc it's very long to generate the site only for a typo
>> fix in documentation.
>
> Agreed. Back in the very old m1 days, you could do something like
> "maven xdoc" to just gen the xdoc-based html. Is there a m2 way to
> do this?
nope or I don't know this feature.
>
> Phil
>>
>> 2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
>>> On Wed, Jan 09, 2013 at 08:37:33AM -0500, Gary Gregory wrote:
>>>> On Wed, Jan 9, 2013 at 8:11 AM, Gilles Sadowski <
>>>> gilles@harfang.homelinux.org> wrote:
>>>>
>>>>> On Wed, Jan 09, 2013 at 07:25:45AM -0500, Gary Gregory wrote:
>>>>>> IMO code coverage should be part of the standard documentation for a
>>>>>> component. Looking at code coverage helps establish or shake my
>>>>>> confidence in a component. It should definitively be part of ones
>>>>>> development checklist, I like to have the best code coverage for any
>>>>>> new code that I check in.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Jan 9, 2013, at 5:16, Olivier Lamy <ol...@apache.org> wrote:
>>>>>>
>>>>>>> Hi Folks,
>>>>>>> I have started importing some content for sub projects (exec,
>>>>>>> collections). I will try to do more later.
>>>>>>>
>>>>>>> Where is the place to document that ?
>>>>>>>
>>>>>>> Note: currently some content is imported which could be removed (I
>>>>>>> think about cobertura for modules which use sonar).
>>>>>>>
>>>>>>> What is the status about moving cobertura to a dedicated profile in
>>>>>>> parent pom ?
>>>>>>> Can I move it to a reporting profile in parent pom ?
>>>>>>>
>>>>> For [Math] it would be much better (since AFAIK nobody came up with a way
>>>>> to
>>>>> disable Cobertura on a per-component basis).
>>>>>
>>>>> From what I infer from looking at the Sonar report page, we could have the
>>>>> best of all worlds if every Commons project were registered indepently in
>>>>> Sonar. Currently, there is one "Commons Proper Aggregator Project
>>>>> 1.0-SNAPSHOT" (which does not represent the actual situation that the
>>>>> components are independent from each other). However, it seems that with
>>>>> several projects registered, it could be possible to compare two versions
>>>>> of the same project, thereby providing complete information on the
>>>>> evolution
>>>>> of the code. Am I wrong?
>>>>>
>>>> Sonar has no value for local development though (before you commit). I need
>>>> the reports to run locally when, for example, I am improving code coverage,
>>>> fixing FindBugs, PMD, and Checkstyle issues.
>>> Nothing will prevent you to run Cobertura by calling the new profile
>>> explicitly. We've explained that Cobertura is a PITA for Commons Math
>>> developers.
>>>
>>>
>>> Thanks,
>>> Gilles
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Phil Steitz <ph...@gmail.com>.
On 1/9/13 7:14 AM, Olivier Lamy wrote:
> What about having a reporting profile (enabled per default).
> And using -DskipReports to not generated cobertura, findbugs etc..
>
> Perso I like this idea as currently when you want to test a typo fix
> in a .apt or .xdoc it's very long to generate the site only for a typo
> fix in documentation.
Agreed. Back in the very old m1 days, you could do something like
"maven xdoc" to just gen the xdoc-based html. Is there a m2 way to
do this?
Phil
>
> 2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
>> On Wed, Jan 09, 2013 at 08:37:33AM -0500, Gary Gregory wrote:
>>> On Wed, Jan 9, 2013 at 8:11 AM, Gilles Sadowski <
>>> gilles@harfang.homelinux.org> wrote:
>>>
>>>> On Wed, Jan 09, 2013 at 07:25:45AM -0500, Gary Gregory wrote:
>>>>> IMO code coverage should be part of the standard documentation for a
>>>>> component. Looking at code coverage helps establish or shake my
>>>>> confidence in a component. It should definitively be part of ones
>>>>> development checklist, I like to have the best code coverage for any
>>>>> new code that I check in.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Jan 9, 2013, at 5:16, Olivier Lamy <ol...@apache.org> wrote:
>>>>>
>>>>>> Hi Folks,
>>>>>> I have started importing some content for sub projects (exec,
>>>>>> collections). I will try to do more later.
>>>>>>
>>>>>> Where is the place to document that ?
>>>>>>
>>>>>> Note: currently some content is imported which could be removed (I
>>>>>> think about cobertura for modules which use sonar).
>>>>>>
>>>>>> What is the status about moving cobertura to a dedicated profile in
>>>>>> parent pom ?
>>>>>> Can I move it to a reporting profile in parent pom ?
>>>>>>
>>>> For [Math] it would be much better (since AFAIK nobody came up with a way
>>>> to
>>>> disable Cobertura on a per-component basis).
>>>>
>>>> From what I infer from looking at the Sonar report page, we could have the
>>>> best of all worlds if every Commons project were registered indepently in
>>>> Sonar. Currently, there is one "Commons Proper Aggregator Project
>>>> 1.0-SNAPSHOT" (which does not represent the actual situation that the
>>>> components are independent from each other). However, it seems that with
>>>> several projects registered, it could be possible to compare two versions
>>>> of the same project, thereby providing complete information on the
>>>> evolution
>>>> of the code. Am I wrong?
>>>>
>>> Sonar has no value for local development though (before you commit). I need
>>> the reports to run locally when, for example, I am improving code coverage,
>>> fixing FindBugs, PMD, and Checkstyle issues.
>> Nothing will prevent you to run Cobertura by calling the new profile
>> explicitly. We've explained that Cobertura is a PITA for Commons Math
>> developers.
>>
>>
>> Thanks,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Olivier Lamy <ol...@apache.org>.
What about having a reporting profile (enabled per default).
And using -DskipReports to not generated cobertura, findbugs etc..
Perso I like this idea as currently when you want to test a typo fix
in a .apt or .xdoc it's very long to generate the site only for a typo
fix in documentation.
2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
> On Wed, Jan 09, 2013 at 08:37:33AM -0500, Gary Gregory wrote:
>> On Wed, Jan 9, 2013 at 8:11 AM, Gilles Sadowski <
>> gilles@harfang.homelinux.org> wrote:
>>
>> > On Wed, Jan 09, 2013 at 07:25:45AM -0500, Gary Gregory wrote:
>> > > IMO code coverage should be part of the standard documentation for a
>> > > component. Looking at code coverage helps establish or shake my
>> > > confidence in a component. It should definitively be part of ones
>> > > development checklist, I like to have the best code coverage for any
>> > > new code that I check in.
>> > >
>> > > Gary
>> > >
>> > > On Jan 9, 2013, at 5:16, Olivier Lamy <ol...@apache.org> wrote:
>> > >
>> > > > Hi Folks,
>> > > > I have started importing some content for sub projects (exec,
>> > > > collections). I will try to do more later.
>> > > >
>> > > > Where is the place to document that ?
>> > > >
>> > > > Note: currently some content is imported which could be removed (I
>> > > > think about cobertura for modules which use sonar).
>> > > >
>> > > > What is the status about moving cobertura to a dedicated profile in
>> > > > parent pom ?
>> > > > Can I move it to a reporting profile in parent pom ?
>> > > >
>> >
>> > For [Math] it would be much better (since AFAIK nobody came up with a way
>> > to
>> > disable Cobertura on a per-component basis).
>> >
>> > From what I infer from looking at the Sonar report page, we could have the
>> > best of all worlds if every Commons project were registered indepently in
>> > Sonar. Currently, there is one "Commons Proper Aggregator Project
>> > 1.0-SNAPSHOT" (which does not represent the actual situation that the
>> > components are independent from each other). However, it seems that with
>> > several projects registered, it could be possible to compare two versions
>> > of the same project, thereby providing complete information on the
>> > evolution
>> > of the code. Am I wrong?
>> >
>>
>> Sonar has no value for local development though (before you commit). I need
>> the reports to run locally when, for example, I am improving code coverage,
>> fixing FindBugs, PMD, and Checkstyle issues.
>
> Nothing will prevent you to run Cobertura by calling the new profile
> explicitly. We've explained that Cobertura is a PITA for Commons Math
> developers.
>
>
> Thanks,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Wed, Jan 09, 2013 at 08:37:33AM -0500, Gary Gregory wrote:
> On Wed, Jan 9, 2013 at 8:11 AM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
> > On Wed, Jan 09, 2013 at 07:25:45AM -0500, Gary Gregory wrote:
> > > IMO code coverage should be part of the standard documentation for a
> > > component. Looking at code coverage helps establish or shake my
> > > confidence in a component. It should definitively be part of ones
> > > development checklist, I like to have the best code coverage for any
> > > new code that I check in.
> > >
> > > Gary
> > >
> > > On Jan 9, 2013, at 5:16, Olivier Lamy <ol...@apache.org> wrote:
> > >
> > > > Hi Folks,
> > > > I have started importing some content for sub projects (exec,
> > > > collections). I will try to do more later.
> > > >
> > > > Where is the place to document that ?
> > > >
> > > > Note: currently some content is imported which could be removed (I
> > > > think about cobertura for modules which use sonar).
> > > >
> > > > What is the status about moving cobertura to a dedicated profile in
> > > > parent pom ?
> > > > Can I move it to a reporting profile in parent pom ?
> > > >
> >
> > For [Math] it would be much better (since AFAIK nobody came up with a way
> > to
> > disable Cobertura on a per-component basis).
> >
> > From what I infer from looking at the Sonar report page, we could have the
> > best of all worlds if every Commons project were registered indepently in
> > Sonar. Currently, there is one "Commons Proper Aggregator Project
> > 1.0-SNAPSHOT" (which does not represent the actual situation that the
> > components are independent from each other). However, it seems that with
> > several projects registered, it could be possible to compare two versions
> > of the same project, thereby providing complete information on the
> > evolution
> > of the code. Am I wrong?
> >
>
> Sonar has no value for local development though (before you commit). I need
> the reports to run locally when, for example, I am improving code coverage,
> fixing FindBugs, PMD, and Checkstyle issues.
Nothing will prevent you to run Cobertura by calling the new profile
explicitly. We've explained that Cobertura is a PITA for Commons Math
developers.
Thanks,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Jan 9, 2013 at 8:11 AM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> On Wed, Jan 09, 2013 at 07:25:45AM -0500, Gary Gregory wrote:
> > IMO code coverage should be part of the standard documentation for a
> > component. Looking at code coverage helps establish or shake my
> > confidence in a component. It should definitively be part of ones
> > development checklist, I like to have the best code coverage for any
> > new code that I check in.
> >
> > Gary
> >
> > On Jan 9, 2013, at 5:16, Olivier Lamy <ol...@apache.org> wrote:
> >
> > > Hi Folks,
> > > I have started importing some content for sub projects (exec,
> > > collections). I will try to do more later.
> > >
> > > Where is the place to document that ?
> > >
> > > Note: currently some content is imported which could be removed (I
> > > think about cobertura for modules which use sonar).
> > >
> > > What is the status about moving cobertura to a dedicated profile in
> > > parent pom ?
> > > Can I move it to a reporting profile in parent pom ?
> > >
>
> For [Math] it would be much better (since AFAIK nobody came up with a way
> to
> disable Cobertura on a per-component basis).
>
> From what I infer from looking at the Sonar report page, we could have the
> best of all worlds if every Commons project were registered indepently in
> Sonar. Currently, there is one "Commons Proper Aggregator Project
> 1.0-SNAPSHOT" (which does not represent the actual situation that the
> components are independent from each other). However, it seems that with
> several projects registered, it could be possible to compare two versions
> of the same project, thereby providing complete information on the
> evolution
> of the code. Am I wrong?
>
Sonar has no value for local development though (before you commit). I need
the reports to run locally when, for example, I am improving code coverage,
fixing FindBugs, PMD, and Checkstyle issues.
Gary
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: ETA SvnPubSub site migration
Posted by Olivier Lamy <ol...@apache.org>.
2013/1/10 Gilles Sadowski <gi...@harfang.homelinux.org>:
> On Wed, Jan 09, 2013 at 09:23:26PM +0100, Olivier Lamy wrote:
>> 2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
>> > On Wed, Jan 09, 2013 at 04:46:43PM +0100, Olivier Lamy wrote:
>> >> 2013/1/9 Olivier Lamy <ol...@apache.org>:
>> >> > 2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
>> >> >> Hi.
>> >> >>
>> >> >>> >> [...]
>> >> >>> >> > Note: currently some content is imported which could be removed (I
>> >> >>> >> > think about cobertura for modules which use sonar).
>> >> >>> >> >
>> >> >>> >> > What is the status about moving cobertura to a dedicated profile in
>> >> >>> >> > parent pom ?
>> >> >>> >> > Can I move it to a reporting profile in parent pom ?
>> >> >>> >> >
>> >> >>> >
>> >> >>> > For [Math] it would be much better (since AFAIK nobody came up with a way to
>> >> >>> > disable Cobertura on a per-component basis).
>> >> >>> >
>> >> >>> > From what I infer from looking at the Sonar report page, we could have the
>> >> >>> > best of all worlds if every Commons project were registered indepently in
>> >> >>> > Sonar. Currently, there is one "Commons Proper Aggregator Project
>> >> >>> > 1.0-SNAPSHOT" (which does not represent the actual situation that the
>> >> >>> > components are independent from each other). However, it seems that with
>> >> >>> > several projects registered, it could be possible to compare two versions
>> >> >>> > of the same project, thereby providing complete information on the evolution
>> >> >>> > of the code. Am I wrong?
>> >> >>>
>> >> >>> Something like https://analysis.apache.org/dashboard/index/org.apache.commons:commons-exec
>> >> >>> or https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
>> >> >>> ?
>> >> >>
>> >> >> What I'd like to be clear on the report page is the release versions (of
>> >> >> Commons Math): the timelines always refer to a non-existent "1.0-SNAPSHOT".
>> >> >> See e.g.
>> >> >> https://analysis.apache.org/dashboard/index/122571?did=4&period=3
>> >> >>
>> >> >
>> >> > I see (this generates extra maintenance on analysis.a.o as I need to
>> >> > created a job per project)
>> >> > But I will
>> >> done see: https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
>> >
>> > Thanks.
>> > Will there be something to be done for each release, or is there some
>> > automagic link between sonar and Jira (or SVN?) that can remember when some
>> > release happened and add the little triangle?
>> Not sure of that but it looks sonar detect versions from pom.
>> As sample see https://analysis.apache.org/dashboard/index/35142?did=4
>
> That's close, but the ideal would be that official release also appear in
> the tables. And that will not happen by reading the pom file because there,
> the version is always in the form "x.y[.z]-SNAPSHOT".
>
> Would it be possible to request a "one-time" analysis by pointing Sonar to
> the SVN tag of the new official release? [And have that analysis inserted in
> the time-line of course ;-).]
>
on request only :-)
>
> Best regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Wed, Jan 09, 2013 at 09:23:26PM +0100, Olivier Lamy wrote:
> 2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
> > On Wed, Jan 09, 2013 at 04:46:43PM +0100, Olivier Lamy wrote:
> >> 2013/1/9 Olivier Lamy <ol...@apache.org>:
> >> > 2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
> >> >> Hi.
> >> >>
> >> >>> >> [...]
> >> >>> >> > Note: currently some content is imported which could be removed (I
> >> >>> >> > think about cobertura for modules which use sonar).
> >> >>> >> >
> >> >>> >> > What is the status about moving cobertura to a dedicated profile in
> >> >>> >> > parent pom ?
> >> >>> >> > Can I move it to a reporting profile in parent pom ?
> >> >>> >> >
> >> >>> >
> >> >>> > For [Math] it would be much better (since AFAIK nobody came up with a way to
> >> >>> > disable Cobertura on a per-component basis).
> >> >>> >
> >> >>> > From what I infer from looking at the Sonar report page, we could have the
> >> >>> > best of all worlds if every Commons project were registered indepently in
> >> >>> > Sonar. Currently, there is one "Commons Proper Aggregator Project
> >> >>> > 1.0-SNAPSHOT" (which does not represent the actual situation that the
> >> >>> > components are independent from each other). However, it seems that with
> >> >>> > several projects registered, it could be possible to compare two versions
> >> >>> > of the same project, thereby providing complete information on the evolution
> >> >>> > of the code. Am I wrong?
> >> >>>
> >> >>> Something like https://analysis.apache.org/dashboard/index/org.apache.commons:commons-exec
> >> >>> or https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
> >> >>> ?
> >> >>
> >> >> What I'd like to be clear on the report page is the release versions (of
> >> >> Commons Math): the timelines always refer to a non-existent "1.0-SNAPSHOT".
> >> >> See e.g.
> >> >> https://analysis.apache.org/dashboard/index/122571?did=4&period=3
> >> >>
> >> >
> >> > I see (this generates extra maintenance on analysis.a.o as I need to
> >> > created a job per project)
> >> > But I will
> >> done see: https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
> >
> > Thanks.
> > Will there be something to be done for each release, or is there some
> > automagic link between sonar and Jira (or SVN?) that can remember when some
> > release happened and add the little triangle?
> Not sure of that but it looks sonar detect versions from pom.
> As sample see https://analysis.apache.org/dashboard/index/35142?did=4
That's close, but the ideal would be that official release also appear in
the tables. And that will not happen by reading the pom file because there,
the version is always in the form "x.y[.z]-SNAPSHOT".
Would it be possible to request a "one-time" analysis by pointing Sonar to
the SVN tag of the new official release? [And have that analysis inserted in
the time-line of course ;-).]
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Olivier Lamy <ol...@apache.org>.
2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
> On Wed, Jan 09, 2013 at 04:46:43PM +0100, Olivier Lamy wrote:
>> 2013/1/9 Olivier Lamy <ol...@apache.org>:
>> > 2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
>> >> Hi.
>> >>
>> >>> >> [...]
>> >>> >> > Note: currently some content is imported which could be removed (I
>> >>> >> > think about cobertura for modules which use sonar).
>> >>> >> >
>> >>> >> > What is the status about moving cobertura to a dedicated profile in
>> >>> >> > parent pom ?
>> >>> >> > Can I move it to a reporting profile in parent pom ?
>> >>> >> >
>> >>> >
>> >>> > For [Math] it would be much better (since AFAIK nobody came up with a way to
>> >>> > disable Cobertura on a per-component basis).
>> >>> >
>> >>> > From what I infer from looking at the Sonar report page, we could have the
>> >>> > best of all worlds if every Commons project were registered indepently in
>> >>> > Sonar. Currently, there is one "Commons Proper Aggregator Project
>> >>> > 1.0-SNAPSHOT" (which does not represent the actual situation that the
>> >>> > components are independent from each other). However, it seems that with
>> >>> > several projects registered, it could be possible to compare two versions
>> >>> > of the same project, thereby providing complete information on the evolution
>> >>> > of the code. Am I wrong?
>> >>>
>> >>> Something like https://analysis.apache.org/dashboard/index/org.apache.commons:commons-exec
>> >>> or https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
>> >>> ?
>> >>
>> >> What I'd like to be clear on the report page is the release versions (of
>> >> Commons Math): the timelines always refer to a non-existent "1.0-SNAPSHOT".
>> >> See e.g.
>> >> https://analysis.apache.org/dashboard/index/122571?did=4&period=3
>> >>
>> >
>> > I see (this generates extra maintenance on analysis.a.o as I need to
>> > created a job per project)
>> > But I will
>> done see: https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
>
> Thanks.
> Will there be something to be done for each release, or is there some
> automagic link between sonar and Jira (or SVN?) that can remember when some
> release happened and add the little triangle?
Not sure of that but it looks sonar detect versions from pom.
As sample see https://analysis.apache.org/dashboard/index/35142?did=4
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Wed, Jan 09, 2013 at 04:46:43PM +0100, Olivier Lamy wrote:
> 2013/1/9 Olivier Lamy <ol...@apache.org>:
> > 2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
> >> Hi.
> >>
> >>> >> [...]
> >>> >> > Note: currently some content is imported which could be removed (I
> >>> >> > think about cobertura for modules which use sonar).
> >>> >> >
> >>> >> > What is the status about moving cobertura to a dedicated profile in
> >>> >> > parent pom ?
> >>> >> > Can I move it to a reporting profile in parent pom ?
> >>> >> >
> >>> >
> >>> > For [Math] it would be much better (since AFAIK nobody came up with a way to
> >>> > disable Cobertura on a per-component basis).
> >>> >
> >>> > From what I infer from looking at the Sonar report page, we could have the
> >>> > best of all worlds if every Commons project were registered indepently in
> >>> > Sonar. Currently, there is one "Commons Proper Aggregator Project
> >>> > 1.0-SNAPSHOT" (which does not represent the actual situation that the
> >>> > components are independent from each other). However, it seems that with
> >>> > several projects registered, it could be possible to compare two versions
> >>> > of the same project, thereby providing complete information on the evolution
> >>> > of the code. Am I wrong?
> >>>
> >>> Something like https://analysis.apache.org/dashboard/index/org.apache.commons:commons-exec
> >>> or https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
> >>> ?
> >>
> >> What I'd like to be clear on the report page is the release versions (of
> >> Commons Math): the timelines always refer to a non-existent "1.0-SNAPSHOT".
> >> See e.g.
> >> https://analysis.apache.org/dashboard/index/122571?did=4&period=3
> >>
> >
> > I see (this generates extra maintenance on analysis.a.o as I need to
> > created a job per project)
> > But I will
> done see: https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
Thanks.
Will there be something to be done for each release, or is there some
automagic link between sonar and Jira (or SVN?) that can remember when some
release happened and add the little triangle?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Olivier Lamy <ol...@apache.org>.
2013/1/9 Olivier Lamy <ol...@apache.org>:
> 2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
>> Hi.
>>
>>> >> [...]
>>> >> > Note: currently some content is imported which could be removed (I
>>> >> > think about cobertura for modules which use sonar).
>>> >> >
>>> >> > What is the status about moving cobertura to a dedicated profile in
>>> >> > parent pom ?
>>> >> > Can I move it to a reporting profile in parent pom ?
>>> >> >
>>> >
>>> > For [Math] it would be much better (since AFAIK nobody came up with a way to
>>> > disable Cobertura on a per-component basis).
>>> >
>>> > From what I infer from looking at the Sonar report page, we could have the
>>> > best of all worlds if every Commons project were registered indepently in
>>> > Sonar. Currently, there is one "Commons Proper Aggregator Project
>>> > 1.0-SNAPSHOT" (which does not represent the actual situation that the
>>> > components are independent from each other). However, it seems that with
>>> > several projects registered, it could be possible to compare two versions
>>> > of the same project, thereby providing complete information on the evolution
>>> > of the code. Am I wrong?
>>>
>>> Something like https://analysis.apache.org/dashboard/index/org.apache.commons:commons-exec
>>> or https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
>>> ?
>>
>> What I'd like to be clear on the report page is the release versions (of
>> Commons Math): the timelines always refer to a non-existent "1.0-SNAPSHOT".
>> See e.g.
>> https://analysis.apache.org/dashboard/index/122571?did=4&period=3
>>
>
> I see (this generates extra maintenance on analysis.a.o as I need to
> created a job per project)
> But I will
done see: https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
>
>>
>> Regards,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Olivier Lamy <ol...@apache.org>.
2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
> Hi.
>
>> >> [...]
>> >> > Note: currently some content is imported which could be removed (I
>> >> > think about cobertura for modules which use sonar).
>> >> >
>> >> > What is the status about moving cobertura to a dedicated profile in
>> >> > parent pom ?
>> >> > Can I move it to a reporting profile in parent pom ?
>> >> >
>> >
>> > For [Math] it would be much better (since AFAIK nobody came up with a way to
>> > disable Cobertura on a per-component basis).
>> >
>> > From what I infer from looking at the Sonar report page, we could have the
>> > best of all worlds if every Commons project were registered indepently in
>> > Sonar. Currently, there is one "Commons Proper Aggregator Project
>> > 1.0-SNAPSHOT" (which does not represent the actual situation that the
>> > components are independent from each other). However, it seems that with
>> > several projects registered, it could be possible to compare two versions
>> > of the same project, thereby providing complete information on the evolution
>> > of the code. Am I wrong?
>>
>> Something like https://analysis.apache.org/dashboard/index/org.apache.commons:commons-exec
>> or https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
>> ?
>
> What I'd like to be clear on the report page is the release versions (of
> Commons Math): the timelines always refer to a non-existent "1.0-SNAPSHOT".
> See e.g.
> https://analysis.apache.org/dashboard/index/122571?did=4&period=3
>
I see (this generates extra maintenance on analysis.a.o as I need to
created a job per project)
But I will
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> >> [...]
> >> > Note: currently some content is imported which could be removed (I
> >> > think about cobertura for modules which use sonar).
> >> >
> >> > What is the status about moving cobertura to a dedicated profile in
> >> > parent pom ?
> >> > Can I move it to a reporting profile in parent pom ?
> >> >
> >
> > For [Math] it would be much better (since AFAIK nobody came up with a way to
> > disable Cobertura on a per-component basis).
> >
> > From what I infer from looking at the Sonar report page, we could have the
> > best of all worlds if every Commons project were registered indepently in
> > Sonar. Currently, there is one "Commons Proper Aggregator Project
> > 1.0-SNAPSHOT" (which does not represent the actual situation that the
> > components are independent from each other). However, it seems that with
> > several projects registered, it could be possible to compare two versions
> > of the same project, thereby providing complete information on the evolution
> > of the code. Am I wrong?
>
> Something like https://analysis.apache.org/dashboard/index/org.apache.commons:commons-exec
> or https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
> ?
What I'd like to be clear on the report page is the release versions (of
Commons Math): the timelines always refer to a non-existent "1.0-SNAPSHOT".
See e.g.
https://analysis.apache.org/dashboard/index/122571?did=4&period=3
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Olivier Lamy <ol...@apache.org>.
2013/1/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
> On Wed, Jan 09, 2013 at 07:25:45AM -0500, Gary Gregory wrote:
>> IMO code coverage should be part of the standard documentation for a
>> component. Looking at code coverage helps establish or shake my
>> confidence in a component. It should definitively be part of ones
>> development checklist, I like to have the best code coverage for any
>> new code that I check in.
>>
>> Gary
>>
>> On Jan 9, 2013, at 5:16, Olivier Lamy <ol...@apache.org> wrote:
>>
>> > Hi Folks,
>> > I have started importing some content for sub projects (exec,
>> > collections). I will try to do more later.
>> >
>> > Where is the place to document that ?
>> >
>> > Note: currently some content is imported which could be removed (I
>> > think about cobertura for modules which use sonar).
>> >
>> > What is the status about moving cobertura to a dedicated profile in
>> > parent pom ?
>> > Can I move it to a reporting profile in parent pom ?
>> >
>
> For [Math] it would be much better (since AFAIK nobody came up with a way to
> disable Cobertura on a per-component basis).
>
> From what I infer from looking at the Sonar report page, we could have the
> best of all worlds if every Commons project were registered indepently in
> Sonar. Currently, there is one "Commons Proper Aggregator Project
> 1.0-SNAPSHOT" (which does not represent the actual situation that the
> components are independent from each other). However, it seems that with
> several projects registered, it could be possible to compare two versions
> of the same project, thereby providing complete information on the evolution
> of the code. Am I wrong?
Something like https://analysis.apache.org/dashboard/index/org.apache.commons:commons-exec
or https://analysis.apache.org/dashboard/index/org.apache.commons:commons-math3
?
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Wed, Jan 09, 2013 at 07:25:45AM -0500, Gary Gregory wrote:
> IMO code coverage should be part of the standard documentation for a
> component. Looking at code coverage helps establish or shake my
> confidence in a component. It should definitively be part of ones
> development checklist, I like to have the best code coverage for any
> new code that I check in.
>
> Gary
>
> On Jan 9, 2013, at 5:16, Olivier Lamy <ol...@apache.org> wrote:
>
> > Hi Folks,
> > I have started importing some content for sub projects (exec,
> > collections). I will try to do more later.
> >
> > Where is the place to document that ?
> >
> > Note: currently some content is imported which could be removed (I
> > think about cobertura for modules which use sonar).
> >
> > What is the status about moving cobertura to a dedicated profile in
> > parent pom ?
> > Can I move it to a reporting profile in parent pom ?
> >
For [Math] it would be much better (since AFAIK nobody came up with a way to
disable Cobertura on a per-component basis).
>From what I infer from looking at the Sonar report page, we could have the
best of all worlds if every Commons project were registered indepently in
Sonar. Currently, there is one "Commons Proper Aggregator Project
1.0-SNAPSHOT" (which does not represent the actual situation that the
components are independent from each other). However, it seems that with
several projects registered, it could be possible to compare two versions
of the same project, thereby providing complete information on the evolution
of the code. Am I wrong?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ETA SvnPubSub site migration
Posted by Gary Gregory <ga...@gmail.com>.
IMO code coverage should be part of the standard documentation for a
component. Looking at code coverage helps establish or shake my
confidence in a component. It should definitively be part of ones
development checklist, I like to have the best code coverage for any
new code that I check in.
Gary
On Jan 9, 2013, at 5:16, Olivier Lamy <ol...@apache.org> wrote:
> Hi Folks,
> I have started importing some content for sub projects (exec,
> collections). I will try to do more later.
>
> Where is the place to document that ?
>
> Note: currently some content is imported which could be removed (I
> think about cobertura for modules which use sonar).
>
> What is the status about moving cobertura to a dedicated profile in
> parent pom ?
> Can I move it to a reporting profile in parent pom ?
>
> Thanks,
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org