animal sniffer could be adapted to assist, for example
On 31 October 2017 at 16:32, Jesse Glick wrote:
> On Tue, Oct 31, 2017 at 11:43 AM, Robert Sandell
> wrote:
> > Not having to
> > also browse through potentially thousands of lines of code in one or more
> > PRs
>
> I fully agree that this
On Tue, Oct 31, 2017 at 11:43 AM, Robert Sandell wrote:
> Not having to
> also browse through potentially thousands of lines of code in one or more
> PRs
I fully agree that this can be painful; my suggestion was however that
the list of API changes be mechanically verified in a PR build. Do you
r
I had tried that earlier today, but I got the same message. I'm not sure
what else to try at this point. I even tried simply creating a project
from the hello-world archetype and trying to run that without making any
changes, but it also threw the same error.
On Tuesday, October 31, 2017 at 2
Try running mvn package hpi:run
There is a filled issue about that if you have run clean before hpi:run
On Tue, Oct 31, 2017, 21:18 Jean-Karlo Accetta
wrote:
> Hi all,
>
> I am new to developing plugins for Jenkins, and I was reading several of
> the related pages on getting started. The proble
Hi all,
I am new to developing plugins for Jenkins, and I was reading several of
the related pages on getting started. The problem is that whenever I try
to run any build step or goal, it fails. I tried first with the hpi:run
command they say to use for debugging, but any goal will result in
Proposed change to Add an option JIRA header has been merged.
On Monday, October 30, 2017 at 11:28:29 AM UTC-7, Liam Newman wrote:
>
> FYI
> Jesse has proposed the adding an optional JIRA header.
> https://github.com/jenkinsci/jep/pull/21
>
> It seems reasonable to me. Unless there is strong o
On Tue, Oct 31, 2017 at 5:28 AM Daniel Beck wrote:
>
> > On 31. Oct 2017, at 11:12, Robert Sandell
> wrote:
> >
> > Thoughts?
> >
>
> If it's relevant enough and not just implementation detail, it can always
> be added by the author even in the current format. But expecting a complete
> list of
I was mostly thinking of it as an aid to the reader so that you don't have
to do a ton of detective work when browsing the list of JEPs. Not having to
also browse through potentially thousands of lines of code in one or more
PRs and perhaps wiki docs etc. linked from the JEP.
In Jesse's case it wou
On Tue, Oct 31, 2017 at 8:28 AM, Daniel Beck wrote:
> quite a bit of what's in Jesse's JEP exists there only because the
> implementation is basically already done.
In this case, yes, excepting whatever might be turned up by further
testing or discussion.
> I think that's not a goal of the JEP
> On 31. Oct 2017, at 11:12, Robert Sandell wrote:
>
> Thoughts?
>
If it's relevant enough and not just implementation detail, it can always be
added by the author even in the current format. But expecting a complete list
of added/deprecated/removed APIs will just make proposing any change
Now that I've read Jesse's "JEP-: Switch Remoting/XStream blacklist to
a whitelist" I'm thinking that maybe some form of "API summary" at the end
for applicable JEPs would be nice to have.
Just listing suggested deprecations, added methods, environment vars etc.
previously mentioned in the text
11 matches
Mail list logo
