Re: merging MNG-6308 display packaging

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: merging MNG-6308 display packaging

rfscholte
I still think it is ugly to use the HR for this kind of info.
If you *really* want this info, I'd prefer a new line, offering more space  
for additional info.
Other option is to leave it as it is. If developers want it, they can put  
it in the name.

So -1 for me.

Robert


On Sun, 10 Dec 2017 11:01:41 +0100, Hervé BOUTEMY <[hidden email]>  
wrote:

> is there a seconder for this enhancement?
>
> CI:  
> https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/
> job/MNG-6308_display_packaging/
>
> Jira issue: https://issues.apache.org/jira/browse/MNG-6308
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: merging MNG-6308 display packaging

stephenconnolly
On Sun 10 Dec 2017 at 10:06, Robert Scholte <[hidden email]> wrote:

> I still think it is ugly to use the HR for this kind of info.


I think the HR use with space *not [] is a beautiful solution


> If you *really* want this info, I'd prefer a new line, offering more space
> for additional info.


Ugh no... build log has too many lines as is


> Other option is to leave it as it is. If developers want it, they can put
> it in the name.
>
> So -1 for me.


+1 from me


>
> Robert
>
>
> On Sun, 10 Dec 2017 11:01:41 +0100, Hervé BOUTEMY <[hidden email]>
> wrote:
>
> > is there a seconder for this enhancement?
> >
> > CI:
> > https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/
> > job/MNG-6308_display_packaging/
> >
> > Jira issue: https://issues.apache.org/jira/browse/MNG-6308
> >
> > Regards,
> >
> > Hervé
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: merging MNG-6308 display packaging

stephenconnolly
In reply to this post by rfscholte
On Sun 10 Dec 2017 at 17:12, Robert Scholte <[hidden email]> wrote:

> On Sun, 10 Dec 2017 17:46:10 +0100, Hervé BOUTEMY <[hidden email]>
> wrote:
>
> > Le dimanche 10 décembre 2017, 11:06:32 CET Robert Scholte a écrit :
> >> I still think it is ugly to use the HR for this kind of info.
> >> If you *really* want this info, I'd prefer a new line, offering more
> >> space
> >> for additional info.
> > yes, I *really* want this info: the precise details on how to display it
> > is
> > less important
> >
> >> Other option is to leave it as it is. If developers want it, they can
> >> put
> >> it in the name.
> > the idea is that ${project.packaging} drives the default build, before
> > additional plugins bindings: it's useful to display it as it is a key
> > info
> >
> >>
> >> So -1 for me.
> > how do you want to proceed to choose the best display?
>
> Is it acceptable to add it to the "Reactor Build Order"? It has enough
> space for this kind of information.


I’d like it in both places. ;-)


>
> >
> > Regards,
> >
> > Hervé
> >
> >>
> >> Robert
> >>
> >>
> >> On Sun, 10 Dec 2017 11:01:41 +0100, Hervé BOUTEMY
> >> <[hidden email]>
> >>
> >> wrote:
> >> > is there a seconder for this enhancement?
> >> >
> >> > CI:
> >> >
> >>
> https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/
> >> > job/MNG-6308_display_packaging/
> >> >
> >> > Jira issue: https://issues.apache.org/jira/browse/MNG-6308
> >> >
> >> > Regards,
> >> >
> >> > Hervé
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: merging MNG-6308 display packaging

Hervé BOUTEMY
Le dimanche 10 décembre 2017, 19:26:53 CET Robert Scholte a écrit :

> On Sun, 10 Dec 2017 18:38:55 +0100, Stephen Connolly
>
> <[hidden email]> wrote:
> > On Sun 10 Dec 2017 at 17:12, Robert Scholte <[hidden email]> wrote:
> >> On Sun, 10 Dec 2017 17:46:10 +0100, Hervé BOUTEMY
> >> <[hidden email]>
> >>
> >> wrote:
> >> > Le dimanche 10 décembre 2017, 11:06:32 CET Robert Scholte a écrit :
> >> >> I still think it is ugly to use the HR for this kind of info.
> >> >> If you *really* want this info, I'd prefer a new line, offering more
> >> >> space
> >> >> for additional info.
> >> >
> >> > yes, I *really* want this info: the precise details on how to display
> >>
> >> it
> >>
> >> > is
> >> > less important
> >> >
> >> >> Other option is to leave it as it is. If developers want it, they can
> >> >> put
> >> >> it in the name.
> >> >
> >> > the idea is that ${project.packaging} drives the default build, before
> >> > additional plugins bindings: it's useful to display it as it is a key
> >> > info
> >> >
> >> >> So -1 for me.
> >> >
> >> > how do you want to proceed to choose the best display?
> >>
> >> Is it acceptable to add it to the "Reactor Build Order"? It has enough
> >> space for this kind of information.
> >
> > I’d like it in both places. ;-)
+1
if we have info only on "Reactor Build Order", I see one missing case: when
it's a simple module build, without reactor

>
> Seems like I'm one of the few who doesn't understand what this info adds.
> If it says pom, it'll run *at least* the m-install-p and m-deploy-p.
> If I only see the m-install-p and m-deploy-p being executed, it must be a
> pom.
> In general I can see by the name what will happen.
>
> If we're discussing module "header" information:
> What I am missing is a timestamp when the module started.
> Reason: in case of a long build I would like to be able to estimate if the
> build is still active or hanging.
on this requirement, I'd more add some timer "since the last log" than a
timestamp on each line

> Also in some cases I would like to see GAV instead of the name, because
> that can help investigating in case of a multimodule project when there
> are issues with some dependency (=GAV).
dependency between modules in the reactor? I don't really understand
But for this, we already have "@ artifactId" on each goal start, and version
in the "Building" message: groupId, for the reactor, I don't see the need

>
> So there's enough to think of to fill an extra row ;)
sorry, I don't think we'll fill a row with really useful additional info

any other opinion?

Regards,

Hervé

>
> >> > Regards,
> >> >
> >> > Hervé
> >> >
> >> >> Robert
> >> >>
> >> >>
> >> >> On Sun, 10 Dec 2017 11:01:41 +0100, Hervé BOUTEMY
> >> >> <[hidden email]>
> >> >>
> >> >> wrote:
> >> >> > is there a seconder for this enhancement?
> >>
> >> >> > CI:
> >> https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/
> >>
> >> >> > job/MNG-6308_display_packaging/
> >> >> >
> >> >> > Jira issue: https://issues.apache.org/jira/browse/MNG-6308
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Hervé
> >>
> >> ---------------------------------------------------------------------
> >>
> >> >> > To unsubscribe, e-mail: [hidden email]
> >> >> > For additional commands, e-mail: [hidden email]
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [hidden email]
> >> >> For additional commands, e-mail: [hidden email]
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >> --
> >
> > Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: merging MNG-6308 display packaging

rfscholte
How about surrounding the packaging with spaces, there's enough room and  
it looks friendlier to me.

On Fri, 22 Dec 2017 15:35:30 +0100, Hervé BOUTEMY <[hidden email]>  
wrote:

> as discussed on IRC, split information in 2 separate parts:
> - project groupId + artifactId coordinates in header
> - packaging in footer (not part of coordinates)
>
> to me, the result is now ok to merge (after squashing...)
>
> no objection from anybody?
>
> Regards,
>
> Hervé
>
> Le vendredi 22 décembre 2017, 11:50:24 CET Robert Scholte a écrit :
>> Now MNG-6308 looks fine to me. If you agree you can merge it.
>>
>> Robert
>>
>> On Sun, 10 Dec 2017 20:46:38 +0100, Hervé BOUTEMY  
>> <[hidden email]>
>>
>> wrote:
>> > Le dimanche 10 décembre 2017, 19:26:53 CET Robert Scholte a écrit :
>> >> On Sun, 10 Dec 2017 18:38:55 +0100, Stephen Connolly
>> >>
>> >> <[hidden email]> wrote:
>> >> > On Sun 10 Dec 2017 at 17:12, Robert Scholte <[hidden email]>
>> >>
>> >> wrote:
>> >> >> On Sun, 10 Dec 2017 17:46:10 +0100, Hervé BOUTEMY
>> >> >> <[hidden email]>
>> >> >>
>> >> >> wrote:
>> >> >> > Le dimanche 10 décembre 2017, 11:06:32 CET Robert Scholte a  
>> écrit :
>> >> >> >> I still think it is ugly to use the HR for this kind of info.
>> >> >> >> If you *really* want this info, I'd prefer a new line, offering
>> >>
>> >> more
>> >>
>> >> >> >> space
>> >> >> >> for additional info.
>> >> >> >
>> >> >> > yes, I *really* want this info: the precise details on how to
>> >>
>> >> display
>> >>
>> >> >> it
>> >> >>
>> >> >> > is
>> >> >> > less important
>> >> >> >
>> >> >> >> Other option is to leave it as it is. If developers want it,  
>> they
>> >>
>> >> can
>> >>
>> >> >> >> put
>> >> >> >> it in the name.
>> >> >> >
>> >> >> > the idea is that ${project.packaging} drives the default build,
>> >>
>> >> before
>> >>
>> >> >> > additional plugins bindings: it's useful to display it as it is  
>> a
>> >>
>> >> key
>> >>
>> >> >> > info
>> >> >> >
>> >> >> >> So -1 for me.
>> >> >> >
>> >> >> > how do you want to proceed to choose the best display?
>> >> >>
>> >> >> Is it acceptable to add it to the "Reactor Build Order"? It has
>> >>
>> >> enough
>> >>
>> >> >> space for this kind of information.
>> >> >
>> >> > I’d like it in both places. ;-)
>> >
>> > +1
>> > if we have info only on "Reactor Build Order", I see one missing case:
>> > when
>> > it's a simple module build, without reactor
>> >
>> >> Seems like I'm one of the few who doesn't understand what this info
>> >> adds.
>> >> If it says pom, it'll run *at least* the m-install-p and m-deploy-p.
>> >> If I only see the m-install-p and m-deploy-p being executed, it must  
>> be
>> >> a
>> >> pom.
>> >> In general I can see by the name what will happen.
>> >>
>> >> If we're discussing module "header" information:
>> >> What I am missing is a timestamp when the module started.
>> >> Reason: in case of a long build I would like to be able to estimate  
>> if
>> >> the
>> >> build is still active or hanging.
>> >
>> > on this requirement, I'd more add some timer "since the last log"  
>> than a
>> > timestamp on each line
>> >
>> >> Also in some cases I would like to see GAV instead of the name,  
>> because
>> >> that can help investigating in case of a multimodule project when  
>> there
>> >> are issues with some dependency (=GAV).
>> >
>> > dependency between modules in the reactor? I don't really understand
>> > But for this, we already have "@ artifactId" on each goal start, and
>> > version
>> > in the "Building" message: groupId, for the reactor, I don't see the  
>> need
>> >
>> >> So there's enough to think of to fill an extra row ;)
>> >
>> > sorry, I don't think we'll fill a row with really useful additional  
>> info
>> >
>> > any other opinion?
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> >> >> > Regards,
>> >> >> >
>> >> >> > Hervé
>> >> >> >
>> >> >> >> Robert
>> >> >> >>
>> >> >> >>
>> >> >> >> On Sun, 10 Dec 2017 11:01:41 +0100, Hervé BOUTEMY
>> >> >> >> <[hidden email]>
>> >> >> >>
>> >> >> >> wrote:
>> >> >> >> > is there a seconder for this enhancement?
>> >>
>> >> >> >> > CI:
>> >>  
>> https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/
>> >>
>> >> >> >> > job/MNG-6308_display_packaging/
>> >> >> >> >
>> >> >> >> > Jira issue: https://issues.apache.org/jira/browse/MNG-6308
>> >> >> >> >
>> >> >> >> > Regards,
>> >> >> >> >
>> >> >> >> > Hervé
>> >> >>
>> >> >>  
>> ---------------------------------------------------------------------
>> >> >>
>> >> >> >> > To unsubscribe, e-mail: [hidden email]
>> >> >> >> > For additional commands, e-mail: [hidden email]
>> >>
>> >> ---------------------------------------------------------------------
>> >>
>> >> >> >> To unsubscribe, e-mail: [hidden email]
>> >> >> >> For additional commands, e-mail: [hidden email]
>> >>
>> >> ---------------------------------------------------------------------
>> >>
>> >> >> > To unsubscribe, e-mail: [hidden email]
>> >> >> > For additional commands, e-mail: [hidden email]
>> >> >>
>> >> >>  
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: [hidden email]
>> >> >> For additional commands, e-mail: [hidden email]
>> >> >>
>> >> >> --
>> >> >
>> >> > Sent from my phone
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]