You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Grover Blue <gr...@gmail.com> on 2014/09/22 23:20:33 UTC
usage with Jenkins
Is there anything special that needs to be added to a pom in order to work
with Jenkins? For some reason, by CI build/packages successfully but not
artifacts are listed on the jobs page (they are hidden on the file-system
in a "default/*" directory).
Re: usage with Jenkins
Posted by Grover Blue <gr...@gmail.com>.
That's interesting, James. Something to consider. We're using the open
source version of Artifactory, btw, and I the Artifactory Plugin has it's
own post build option. I'd probably use that.
Curtis, I had Netbeans create the new job for me through it's Hudson
plugin. It created a "multi-configuration project" and didn't have the
"publish artifacts" options you mentioned. All my Ant projects, do,
though. I'm going to do a free-style and report back.
On Tue, Sep 23, 2014 at 9:56 AM, James Green <ja...@gmail.com>
wrote:
> News to me. Ironically I'm just setting up a new Jenkins job so tried the
> freeform style - I can no longer see "Deploy artifacts to Maven repository"
> as a post-build action.
>
> Dare I ask what I'm missing having chosen the full-fat option..?
>
> On 23 September 2014 14:02, Curtis Rueden <ct...@wisc.edu> wrote:
>
> > The Maven style build will also lock you in to a small subset of
> Jenkins's
> > usual features. And when you eventually need a feature not available
> with a
> > Maven-style build, there is no conversion path from Maven-style to
> > Freestyle -- you have to recreate the job (losing the build history
> etc.).
> >
> > -Curtis
> > On Sep 23, 2014 7:33 AM, "Stephen Connolly" <
> > stephen.alan.connolly@gmail.com>
> > wrote:
> >
> > > Freestyle does not mess with your build and change it from building the
> > way
> > > maven intends. Google "stephen's java adventures Jenkins maven
> considered
> > > evil" for a more detailed discussion
> > >
> > > On Tuesday, 23 September 2014, James Green <ja...@gmail.com>
> > > wrote:
> > >
> > > > On 23 September 2014 02:23, Curtis Rueden <ctrueden@wisc.edu
> > > > <javascript:;>> wrote:
> > > > >
> > > > >
> > > > > Also, stay away from the Jenkins "Maven" style job. Freestyle is
> more
> > > > > flexible and less buggy.
> > > > >
> > > >
> > > > Based on ..?
> > > >
> > >
> > >
> > > --
> > > Sent from my phone
> > >
> >
>
--
“If the American people ever allow private banks to control the issue of
their currency, first by inflation, then by deflation, the banks...will
deprive the people of all property until their children wake-up homeless on
the continent their fathers conquered... The issuing power should be taken
from the banks and restored to the people, to whom it properly belongs."
-- Thomas Jefferson
"Government big enough to supply everything...is big enough to take
everything you have. The course of history shows that as a government
grows, liberty decreases" --- Thomas Jefferson
www.CampaignForLiberty.org
Re: usage with Jenkins
Posted by domi <do...@fortysix.ch>.
I fully agree with James, I never used the module reporting and I the action to remove undefined Modules does not add any added value either.
The less configuration required the better and thats where this type really shines.
Also its integration with the m2release plugin is what cuts down the number of required Jobs a lot.
Domi
On 25.09.2014, at 09:53, James Nord (jnord) <jn...@cisco.com> wrote:
> Hi Stephen,
>
> I'm not sure why you think that per module reporting is the killer feature.
>
> For me I couldn’t give a hoot if I saw all reports from maven modules munged in a single report or spread across 100 different pages (in fact I generally use the top level aggregate anyway).
>
> What's the killer feature is
> 1) automatic (zero conf) finding of artifacts / test reports / findbugs report pickup etc etc...
>
> And also being able to lock down what the CI system will run to deploy... That is if some devs have control of their own builds when an enforcer rule fails (your build is not repeatable) they will look up enforcer and add -Denforcer.skip
> Yes they could add <phase>none</phase> to the enforcer config - but the ones that are intelligent enough to do that know better and fix the issue rather than hide it!
> Neither of the above are possible with the literate job type.
>
> /James
>
>
>> -----Original Message-----
>> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>> Sent: 23 September 2014 19:44
>> To: Maven Users List
>> Subject: Re: usage with Jenkins
>>
>> FYI my aim is to supersede the evil job type with some enhanced reporting in
>> what is currently called the literate job type.
>>
>> That would mean you'd get the per-module reporting.
>>
>> The current evil job type's other "killer" feature is automatic downstream job
>> triggering... Which is actually broken as it does not take into account the local
>> repo that the -SNAPSHOTs may or may not have been deployed into and
>> assumes that `package` is the same as `deploy` as far as triggering is
>> concerned as well as ignoring that deployment might be to a staging repo, so
>> the artifacts may not be available downstream... However, despite being
>> fundamentally broken at every level, you would be surprised how many
>> people feel locked into the evil job type because of this...
>>
>> In short, there is so many issues with it that I cannot recommend its use...
>> The only semi useful feature from my PoV is per module reporting.
>>
>> (Sadly my day job has me having to support the evil job type from time to
>> time... Though usually those tickets get picked up by Kohsuke if I start
>> another "evil job type" tirade ;-) )
>>
>> On Tuesday, 23 September 2014, Curtis Rueden <ct...@wisc.edu>
>> wrote:
>>
>>> Hi James,
>>>
>>>> I can no longer see "Deploy artifacts to Maven repository"
>>>> as a post-build action.
>>>
>>> Just add a build step that does "mvn deploy" or similar.
>>>
>>>> Dare I ask what I'm missing having chosen the full-fat option..?
>>>
>>> If you're asking what you cannot do with freeform jobs: I don't know
>>> of anything. I think the Maven-style job is just a convenience to get
>>> very basic CI set up as quickly as possible, for people without much
>>> technical know-how.
>>>
>>> If you're asking for more details on limitations of the Maven-style job:
>>> it's been awhile, but IIRC my group had several problems. One such was
>>> that the Jenkins Git plugin did not fire Maven-style jobs upon
>>> receiving the push notification from GitHub. Another really serious
>>> problem is that you can't add arbitrary shell script as a post-build
>>> step. And needing to do this is, in my experience, extremely common.
>>>
>>> It wouldn't be that big of an issue if there were an easy way to later
>>> "convert" a Maven-style job to a freestyle job should the need arise.
>>> But try a web search on that topic and you'll see what I mean about it
>>> being a highly non-trivial problem.
>>>
>>> Regards,
>>> Curtis
>>>
>>> On Tue, Sep 23, 2014 at 8:56 AM, James Green
>> <james.mk.green@gmail.com
>>> <javascript:;>>
>>> wrote:
>>>
>>>> News to me. Ironically I'm just setting up a new Jenkins job so
>>>> tried the freeform style - I can no longer see "Deploy artifacts to
>>>> Maven
>>> repository"
>>>> as a post-build action.
>>>>
>>>> Dare I ask what I'm missing having chosen the full-fat option..?
>>>>
>>>> On 23 September 2014 14:02, Curtis Rueden <ctrueden@wisc.edu
>>> <javascript:;>> wrote:
>>>>
>>>>> The Maven style build will also lock you in to a small subset of
>>>> Jenkins's
>>>>> usual features. And when you eventually need a feature not
>>>>> available
>>>> with a
>>>>> Maven-style build, there is no conversion path from Maven-style to
>>>>> Freestyle -- you have to recreate the job (losing the build
>>>>> history
>>>> etc.).
>>>>>
>>>>> -Curtis
>>>>> On Sep 23, 2014 7:33 AM, "Stephen Connolly" <
>>>>> stephen.alan.connolly@gmail.com <javascript:;>>
>>>>> wrote:
>>>>>
>>>>>> Freestyle does not mess with your build and change it from
>>>>>> building
>>> the
>>>>> way
>>>>>> maven intends. Google "stephen's java adventures Jenkins maven
>>>> considered
>>>>>> evil" for a more detailed discussion
>>>>>>
>>>>>> On Tuesday, 23 September 2014, James Green
>>>>>> <james.mk.green@gmail.com
>>> <javascript:;>>
>>>>>> wrote:
>>>>>>
>>>>>>> On 23 September 2014 02:23, Curtis Rueden <ctrueden@wisc.edu
>>> <javascript:;>
>>>>>>> <javascript:;>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Also, stay away from the Jenkins "Maven" style job.
>>>>>>>> Freestyle is
>>>> more
>>>>>>>> flexible and less buggy.
>>>>>>>>
>>>>>>>
>>>>>>> Based on ..?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from my phone
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: usage with Jenkins
Posted by Stephen Connolly <st...@gmail.com>.
On 25 September 2014 15:13, James Nord (jnord) <jn...@cisco.com> wrote:
> > > What's the killer feature is
> > > 1) automatic (zero conf) finding of artifacts / test reports /
> > > findbugs report pickup etc etc...
> > >
> >
> > Well James, you do know *you* could use templates (as you have the
> > enterprise plugins ;-) ) and give a locked down build.
>
> With literate? How - I did raise a call about that (feel free to take
> this off list :-) )
>
> I already use templates for the maven2/3 project type to lock it down!
>
I was more saying you could use templates to lock down a freestyle and that
way avoid the evil one!
>
> > > And also being able to lock down what the CI system will run to
> deploy...
> > > That is if some devs have control of their own builds when an enforcer
> > > rule fails (your build is not repeatable) they will look up enforcer
> > > and add -Denforcer.skip
> > >
> >
> > So you are missing the full context. The literate-api allows for
> different
> > providers. There are actually two providers in literate-api at present:
> the
> > README.md driven one and a .travis.yml driven one (with a very incomplete
> > parser... but I always like to test plugable APIs with more than one
> > implementation to make sure the design is right)
> >
> > The way I see literate having advanced Maven support is via two modes:
> >
> > 1. Wherein you specify the literate commands as being for a "maven
> shell"...
> > something like
> >
> > > # Build
> > >
> > > We build with Maven using the following phases
> > >
> > > ```mvnsh
> > > clean verify
> > > ```
> >
> > When I add asciidoc support, that has a much nicer way to specify the
> syntax
> >
> > 2. Wherein you just tell it to use the pom.xml directly (i.e. a
> literate-api pom
> > based parser that is activated by just having a pom.xml in the root
> (plus a
> > marker file to say this is a buildable branch)
> >
> > Then in the config for the literate job you would specify the goals you
> want
> > executed for that parser
>
> So that's more what I'm after - but I also want Jenkins to be intelligent
> about picking up reports/artifacts (clover is a PITA and if you do
> target/*.jar **/target/*.rpm it will pick up clovers instrumented jars /
> rpm...) - even though they are never installed into the local repo. (the
> Maven2/3 type job is clever in this regard and won't pickup those
> artifacts).
>
Nahh my idea is to have an execution listener and get that to report
artifacts back to jenkins
> And I also want to be able to make releases with Jenkins for this branch
> :-) (did I say moon on a stick?)
>
Literate already has lightweight promotions for that... a pom based parser
would just report the release goals as a "promotion"
>
> > > Yes they could add <phase>none</phase> to the enforcer config - but
> > > the ones that are intelligent enough to do that know better and fix
> > > the issue rather than hide it!
> > > Neither of the above are possible with the literate job type.
> > >
> >
> > Not yet... but once I get the time to write some code...
>
> Until that time you'll get people continue to use the job that you
> consider evil :(
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
RE: usage with Jenkins
Posted by "James Nord (jnord)" <jn...@cisco.com>.
> > What's the killer feature is
> > 1) automatic (zero conf) finding of artifacts / test reports /
> > findbugs report pickup etc etc...
> >
>
> Well James, you do know *you* could use templates (as you have the
> enterprise plugins ;-) ) and give a locked down build.
With literate? How - I did raise a call about that (feel free to take this off list :-) )
I already use templates for the maven2/3 project type to lock it down!
> > And also being able to lock down what the CI system will run to deploy...
> > That is if some devs have control of their own builds when an enforcer
> > rule fails (your build is not repeatable) they will look up enforcer
> > and add -Denforcer.skip
> >
>
> So you are missing the full context. The literate-api allows for different
> providers. There are actually two providers in literate-api at present: the
> README.md driven one and a .travis.yml driven one (with a very incomplete
> parser... but I always like to test plugable APIs with more than one
> implementation to make sure the design is right)
>
> The way I see literate having advanced Maven support is via two modes:
>
> 1. Wherein you specify the literate commands as being for a "maven shell"...
> something like
>
> > # Build
> >
> > We build with Maven using the following phases
> >
> > ```mvnsh
> > clean verify
> > ```
>
> When I add asciidoc support, that has a much nicer way to specify the syntax
>
> 2. Wherein you just tell it to use the pom.xml directly (i.e. a literate-api pom
> based parser that is activated by just having a pom.xml in the root (plus a
> marker file to say this is a buildable branch)
>
> Then in the config for the literate job you would specify the goals you want
> executed for that parser
So that's more what I'm after - but I also want Jenkins to be intelligent about picking up reports/artifacts (clover is a PITA and if you do target/*.jar **/target/*.rpm it will pick up clovers instrumented jars / rpm...) - even though they are never installed into the local repo. (the Maven2/3 type job is clever in this regard and won't pickup those artifacts).
And I also want to be able to make releases with Jenkins for this branch :-) (did I say moon on a stick?)
> > Yes they could add <phase>none</phase> to the enforcer config - but
> > the ones that are intelligent enough to do that know better and fix
> > the issue rather than hide it!
> > Neither of the above are possible with the literate job type.
> >
>
> Not yet... but once I get the time to write some code...
Until that time you'll get people continue to use the job that you consider evil :(
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: usage with Jenkins
Posted by Stephen Connolly <st...@gmail.com>.
On 25 September 2014 08:53, James Nord (jnord) <jn...@cisco.com> wrote:
> Hi Stephen,
>
> I'm not sure why you think that per module reporting is the killer feature.
>
>
Well any time we suggest switching to freestyle, the feedback we get is "oh
but we can't because we'd loose the per-module reports"
> For me I couldn’t give a hoot if I saw all reports from maven modules
> munged in a single report or spread across 100 different pages (in fact I
> generally use the top level aggregate anyway).
>
> What's the killer feature is
> 1) automatic (zero conf) finding of artifacts / test reports / findbugs
> report pickup etc etc...
>
Well James, you do know *you* could use templates (as you have the
enterprise plugins ;-) ) and give a locked down build.
>
> And also being able to lock down what the CI system will run to deploy...
> That is if some devs have control of their own builds when an enforcer rule
> fails (your build is not repeatable) they will look up enforcer and add
> -Denforcer.skip
>
So you are missing the full context. The literate-api allows for different
providers. There are actually two providers in literate-api at present: the
README.md driven one and a .travis.yml driven one (with a very incomplete
parser... but I always like to test plugable APIs with more than one
implementation to make sure the design is right)
The way I see literate having advanced Maven support is via two modes:
1. Wherein you specify the literate commands as being for a "maven
shell"... something like
> # Build
>
> We build with Maven using the following phases
>
> ```mvnsh
> clean verify
> ```
When I add asciidoc support, that has a much nicer way to specify the syntax
2. Wherein you just tell it to use the pom.xml directly (i.e. a
literate-api pom based parser that is activated by just having a pom.xml in
the root (plus a marker file to say this is a buildable branch)
Then in the config for the literate job you would specify the goals you
want executed for that parser
> Yes they could add <phase>none</phase> to the enforcer config - but the
> ones that are intelligent enough to do that know better and fix the issue
> rather than hide it!
> Neither of the above are possible with the literate job type.
>
Not yet... but once I get the time to write some code...
>
> /James
>
>
> > -----Original Message-----
> > From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > Sent: 23 September 2014 19:44
> > To: Maven Users List
> > Subject: Re: usage with Jenkins
> >
> > FYI my aim is to supersede the evil job type with some enhanced
> reporting in
> > what is currently called the literate job type.
> >
> > That would mean you'd get the per-module reporting.
> >
> > The current evil job type's other "killer" feature is automatic
> downstream job
> > triggering... Which is actually broken as it does not take into account
> the local
> > repo that the -SNAPSHOTs may or may not have been deployed into and
> > assumes that `package` is the same as `deploy` as far as triggering is
> > concerned as well as ignoring that deployment might be to a staging
> repo, so
> > the artifacts may not be available downstream... However, despite being
> > fundamentally broken at every level, you would be surprised how many
> > people feel locked into the evil job type because of this...
> >
> > In short, there is so many issues with it that I cannot recommend its
> use...
> > The only semi useful feature from my PoV is per module reporting.
> >
> > (Sadly my day job has me having to support the evil job type from time to
> > time... Though usually those tickets get picked up by Kohsuke if I start
> > another "evil job type" tirade ;-) )
> >
> > On Tuesday, 23 September 2014, Curtis Rueden <ct...@wisc.edu>
> > wrote:
> >
> > > Hi James,
> > >
> > > > I can no longer see "Deploy artifacts to Maven repository"
> > > > as a post-build action.
> > >
> > > Just add a build step that does "mvn deploy" or similar.
> > >
> > > > Dare I ask what I'm missing having chosen the full-fat option..?
> > >
> > > If you're asking what you cannot do with freeform jobs: I don't know
> > > of anything. I think the Maven-style job is just a convenience to get
> > > very basic CI set up as quickly as possible, for people without much
> > > technical know-how.
> > >
> > > If you're asking for more details on limitations of the Maven-style
> job:
> > > it's been awhile, but IIRC my group had several problems. One such was
> > > that the Jenkins Git plugin did not fire Maven-style jobs upon
> > > receiving the push notification from GitHub. Another really serious
> > > problem is that you can't add arbitrary shell script as a post-build
> > > step. And needing to do this is, in my experience, extremely common.
> > >
> > > It wouldn't be that big of an issue if there were an easy way to later
> > > "convert" a Maven-style job to a freestyle job should the need arise.
> > > But try a web search on that topic and you'll see what I mean about it
> > > being a highly non-trivial problem.
> > >
> > > Regards,
> > > Curtis
> > >
> > > On Tue, Sep 23, 2014 at 8:56 AM, James Green
> > <james.mk.green@gmail.com
> > > <javascript:;>>
> > > wrote:
> > >
> > > > News to me. Ironically I'm just setting up a new Jenkins job so
> > > > tried the freeform style - I can no longer see "Deploy artifacts to
> > > > Maven
> > > repository"
> > > > as a post-build action.
> > > >
> > > > Dare I ask what I'm missing having chosen the full-fat option..?
> > > >
> > > > On 23 September 2014 14:02, Curtis Rueden <ctrueden@wisc.edu
> > > <javascript:;>> wrote:
> > > >
> > > > > The Maven style build will also lock you in to a small subset of
> > > > Jenkins's
> > > > > usual features. And when you eventually need a feature not
> > > > > available
> > > > with a
> > > > > Maven-style build, there is no conversion path from Maven-style to
> > > > > Freestyle -- you have to recreate the job (losing the build
> > > > > history
> > > > etc.).
> > > > >
> > > > > -Curtis
> > > > > On Sep 23, 2014 7:33 AM, "Stephen Connolly" <
> > > > > stephen.alan.connolly@gmail.com <javascript:;>>
> > > > > wrote:
> > > > >
> > > > > > Freestyle does not mess with your build and change it from
> > > > > > building
> > > the
> > > > > way
> > > > > > maven intends. Google "stephen's java adventures Jenkins maven
> > > > considered
> > > > > > evil" for a more detailed discussion
> > > > > >
> > > > > > On Tuesday, 23 September 2014, James Green
> > > > > > <james.mk.green@gmail.com
> > > <javascript:;>>
> > > > > > wrote:
> > > > > >
> > > > > > > On 23 September 2014 02:23, Curtis Rueden <ctrueden@wisc.edu
> > > <javascript:;>
> > > > > > > <javascript:;>> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Also, stay away from the Jenkins "Maven" style job.
> > > > > > > > Freestyle is
> > > > more
> > > > > > > > flexible and less buggy.
> > > > > > > >
> > > > > > >
> > > > > > > Based on ..?
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sent from my phone
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
RE: usage with Jenkins
Posted by "James Nord (jnord)" <jn...@cisco.com>.
Hi Stephen,
I'm not sure why you think that per module reporting is the killer feature.
For me I couldn’t give a hoot if I saw all reports from maven modules munged in a single report or spread across 100 different pages (in fact I generally use the top level aggregate anyway).
What's the killer feature is
1) automatic (zero conf) finding of artifacts / test reports / findbugs report pickup etc etc...
And also being able to lock down what the CI system will run to deploy... That is if some devs have control of their own builds when an enforcer rule fails (your build is not repeatable) they will look up enforcer and add -Denforcer.skip
Yes they could add <phase>none</phase> to the enforcer config - but the ones that are intelligent enough to do that know better and fix the issue rather than hide it!
Neither of the above are possible with the literate job type.
/James
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: 23 September 2014 19:44
> To: Maven Users List
> Subject: Re: usage with Jenkins
>
> FYI my aim is to supersede the evil job type with some enhanced reporting in
> what is currently called the literate job type.
>
> That would mean you'd get the per-module reporting.
>
> The current evil job type's other "killer" feature is automatic downstream job
> triggering... Which is actually broken as it does not take into account the local
> repo that the -SNAPSHOTs may or may not have been deployed into and
> assumes that `package` is the same as `deploy` as far as triggering is
> concerned as well as ignoring that deployment might be to a staging repo, so
> the artifacts may not be available downstream... However, despite being
> fundamentally broken at every level, you would be surprised how many
> people feel locked into the evil job type because of this...
>
> In short, there is so many issues with it that I cannot recommend its use...
> The only semi useful feature from my PoV is per module reporting.
>
> (Sadly my day job has me having to support the evil job type from time to
> time... Though usually those tickets get picked up by Kohsuke if I start
> another "evil job type" tirade ;-) )
>
> On Tuesday, 23 September 2014, Curtis Rueden <ct...@wisc.edu>
> wrote:
>
> > Hi James,
> >
> > > I can no longer see "Deploy artifacts to Maven repository"
> > > as a post-build action.
> >
> > Just add a build step that does "mvn deploy" or similar.
> >
> > > Dare I ask what I'm missing having chosen the full-fat option..?
> >
> > If you're asking what you cannot do with freeform jobs: I don't know
> > of anything. I think the Maven-style job is just a convenience to get
> > very basic CI set up as quickly as possible, for people without much
> > technical know-how.
> >
> > If you're asking for more details on limitations of the Maven-style job:
> > it's been awhile, but IIRC my group had several problems. One such was
> > that the Jenkins Git plugin did not fire Maven-style jobs upon
> > receiving the push notification from GitHub. Another really serious
> > problem is that you can't add arbitrary shell script as a post-build
> > step. And needing to do this is, in my experience, extremely common.
> >
> > It wouldn't be that big of an issue if there were an easy way to later
> > "convert" a Maven-style job to a freestyle job should the need arise.
> > But try a web search on that topic and you'll see what I mean about it
> > being a highly non-trivial problem.
> >
> > Regards,
> > Curtis
> >
> > On Tue, Sep 23, 2014 at 8:56 AM, James Green
> <james.mk.green@gmail.com
> > <javascript:;>>
> > wrote:
> >
> > > News to me. Ironically I'm just setting up a new Jenkins job so
> > > tried the freeform style - I can no longer see "Deploy artifacts to
> > > Maven
> > repository"
> > > as a post-build action.
> > >
> > > Dare I ask what I'm missing having chosen the full-fat option..?
> > >
> > > On 23 September 2014 14:02, Curtis Rueden <ctrueden@wisc.edu
> > <javascript:;>> wrote:
> > >
> > > > The Maven style build will also lock you in to a small subset of
> > > Jenkins's
> > > > usual features. And when you eventually need a feature not
> > > > available
> > > with a
> > > > Maven-style build, there is no conversion path from Maven-style to
> > > > Freestyle -- you have to recreate the job (losing the build
> > > > history
> > > etc.).
> > > >
> > > > -Curtis
> > > > On Sep 23, 2014 7:33 AM, "Stephen Connolly" <
> > > > stephen.alan.connolly@gmail.com <javascript:;>>
> > > > wrote:
> > > >
> > > > > Freestyle does not mess with your build and change it from
> > > > > building
> > the
> > > > way
> > > > > maven intends. Google "stephen's java adventures Jenkins maven
> > > considered
> > > > > evil" for a more detailed discussion
> > > > >
> > > > > On Tuesday, 23 September 2014, James Green
> > > > > <james.mk.green@gmail.com
> > <javascript:;>>
> > > > > wrote:
> > > > >
> > > > > > On 23 September 2014 02:23, Curtis Rueden <ctrueden@wisc.edu
> > <javascript:;>
> > > > > > <javascript:;>> wrote:
> > > > > > >
> > > > > > >
> > > > > > > Also, stay away from the Jenkins "Maven" style job.
> > > > > > > Freestyle is
> > > more
> > > > > > > flexible and less buggy.
> > > > > > >
> > > > > >
> > > > > > Based on ..?
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sent from my phone
> > > > >
> > > >
> > >
> >
>
>
> --
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: usage with Jenkins
Posted by Grover Blue <gr...@gmail.com>.
Thanks for the educations! :)
On Tue, Sep 23, 2014 at 3:55 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> On Tuesday, 23 September 2014, Grover Blue <gr...@gmail.com> wrote:
>
> > I'd like to weigh in on this. The maven-based job type is great for
> quick
> > or single-dimensional project, especially when you know the scope will
> not
> > change. I tend to prefer freestyle because of flexibility.
> >
> > In reality, the solution is to just have one project type with varied
> > initialization types. I'm pretty sure that's happening in the backend,
>
>
> Ha! So not the case.
>
> The evil job type sets up a remoting connection to within the maven process
> and this lets Jenkins muck about.
>
> Regular jobs fork a shell on the slave doing the "obvious" thing... Ie
> Jenkins drives the build
>
> Maven jobs have two back-to-back remoting channels and "drive" Jenkins to
> an extent
>
> When I say its evil, I'm not joking
>
> but
> > the details are hidden (needs confirmation).
> >
> > BTW, in order to have artifacts listed one has to enable artifact
> > archiving, not publishing.
> >
> > Everything works now (except for the job stalling on deployment to a
> > self-signed cert GF 4.1 installation. :)
> >
> >
> >
> > On Tue, Sep 23, 2014 at 2:43 PM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> >
> > > FYI my aim is to supersede the evil job type with some enhanced
> reporting
> > > in what is currently called the literate job type.
> > >
> > > That would mean you'd get the per-module reporting.
> > >
> > > The current evil job type's other "killer" feature is automatic
> > downstream
> > > job triggering... Which is actually broken as it does not take into
> > account
> > > the local repo that the -SNAPSHOTs may or may not have been deployed
> into
> > > and assumes that `package` is the same as `deploy` as far as triggering
> > is
> > > concerned as well as ignoring that deployment might be to a staging
> repo,
> > > so the artifacts may not be available downstream... However, despite
> > being
> > > fundamentally broken at every level, you would be surprised how many
> > people
> > > feel locked into the evil job type because of this...
> > >
> > > In short, there is so many issues with it that I cannot recommend its
> > > use... The only semi useful feature from my PoV is per module
> reporting.
> > >
> > > (Sadly my day job has me having to support the evil job type from time
> to
> > > time... Though usually those tickets get picked up by Kohsuke if I
> start
> > > another "evil job type" tirade ;-) )
> > >
> > > On Tuesday, 23 September 2014, Curtis Rueden <ctrueden@wisc.edu
> > <javascript:;>> wrote:
> > >
> > > > Hi James,
> > > >
> > > > > I can no longer see "Deploy artifacts to Maven repository"
> > > > > as a post-build action.
> > > >
> > > > Just add a build step that does "mvn deploy" or similar.
> > > >
> > > > > Dare I ask what I'm missing having chosen the full-fat option..?
> > > >
> > > > If you're asking what you cannot do with freeform jobs: I don't know
> of
> > > > anything. I think the Maven-style job is just a convenience to get
> very
> > > > basic CI set up as quickly as possible, for people without much
> > technical
> > > > know-how.
> > > >
> > > > If you're asking for more details on limitations of the Maven-style
> > job:
> > > > it's been awhile, but IIRC my group had several problems. One such
> was
> > > that
> > > > the Jenkins Git plugin did not fire Maven-style jobs upon receiving
> the
> > > > push notification from GitHub. Another really serious problem is that
> > you
> > > > can't add arbitrary shell script as a post-build step. And needing to
> > do
> > > > this is, in my experience, extremely common.
> > > >
> > > > It wouldn't be that big of an issue if there were an easy way to
> later
> > > > "convert" a Maven-style job to a freestyle job should the need arise.
> > But
> > > > try a web search on that topic and you'll see what I mean about it
> > being
> > > a
> > > > highly non-trivial problem.
> > > >
> > > > Regards,
> > > > Curtis
> > > >
> > > > On Tue, Sep 23, 2014 at 8:56 AM, James Green <
> james.mk.green@gmail.com
> > <javascript:;>
> > > > <javascript:;>>
> > > > wrote:
> > > >
> > > > > News to me. Ironically I'm just setting up a new Jenkins job so
> tried
> > > the
> > > > > freeform style - I can no longer see "Deploy artifacts to Maven
> > > > repository"
> > > > > as a post-build action.
> > > > >
> > > > > Dare I ask what I'm missing having chosen the full-fat option..?
> > > > >
> > > > > On 23 September 2014 14:02, Curtis Rueden <ctrueden@wisc.edu
> > <javascript:;>
> > > > <javascript:;>> wrote:
> > > > >
> > > > > > The Maven style build will also lock you in to a small subset of
> > > > > Jenkins's
> > > > > > usual features. And when you eventually need a feature not
> > available
> > > > > with a
> > > > > > Maven-style build, there is no conversion path from Maven-style
> to
> > > > > > Freestyle -- you have to recreate the job (losing the build
> history
> > > > > etc.).
> > > > > >
> > > > > > -Curtis
> > > > > > On Sep 23, 2014 7:33 AM, "Stephen Connolly" <
> > > > > > stephen.alan.connolly@gmail.com <javascript:;> <javascript:;>>
> > > > > > wrote:
> > > > > >
> > > > > > > Freestyle does not mess with your build and change it from
> > building
> > > > the
> > > > > > way
> > > > > > > maven intends. Google "stephen's java adventures Jenkins maven
> > > > > considered
> > > > > > > evil" for a more detailed discussion
> > > > > > >
> > > > > > > On Tuesday, 23 September 2014, James Green <
> > > james.mk.green@gmail.com <javascript:;>
> > > > <javascript:;>>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On 23 September 2014 02:23, Curtis Rueden <ctrueden@wisc.edu
> > <javascript:;>
> > > > <javascript:;>
> > > > > > > > <javascript:;>> wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Also, stay away from the Jenkins "Maven" style job.
> Freestyle
> > > is
> > > > > more
> > > > > > > > > flexible and less buggy.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Based on ..?
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sent from my phone
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Sent from my phone
> > >
> >
> >
> >
> > --
> > “If the American people ever allow private banks to control the issue of
> > their currency, first by inflation, then by deflation, the banks...will
> > deprive the people of all property until their children wake-up homeless
> on
> > the continent their fathers conquered... The issuing power should be
> taken
> > from the banks and restored to the people, to whom it properly belongs."
> > -- Thomas Jefferson
> >
> > "Government big enough to supply everything...is big enough to take
> > everything you have. The course of history shows that as a government
> > grows, liberty decreases" --- Thomas Jefferson
> >
> > www.CampaignForLiberty.org
> >
>
>
> --
> Sent from my phone
>
--
“If the American people ever allow private banks to control the issue of
their currency, first by inflation, then by deflation, the banks...will
deprive the people of all property until their children wake-up homeless on
the continent their fathers conquered... The issuing power should be taken
from the banks and restored to the people, to whom it properly belongs."
-- Thomas Jefferson
"Government big enough to supply everything...is big enough to take
everything you have. The course of history shows that as a government
grows, liberty decreases" --- Thomas Jefferson
www.CampaignForLiberty.org
Re: usage with Jenkins
Posted by Stephen Connolly <st...@gmail.com>.
On Tuesday, 23 September 2014, Grover Blue <gr...@gmail.com> wrote:
> I'd like to weigh in on this. The maven-based job type is great for quick
> or single-dimensional project, especially when you know the scope will not
> change. I tend to prefer freestyle because of flexibility.
>
> In reality, the solution is to just have one project type with varied
> initialization types. I'm pretty sure that's happening in the backend,
Ha! So not the case.
The evil job type sets up a remoting connection to within the maven process
and this lets Jenkins muck about.
Regular jobs fork a shell on the slave doing the "obvious" thing... Ie
Jenkins drives the build
Maven jobs have two back-to-back remoting channels and "drive" Jenkins to
an extent
When I say its evil, I'm not joking
but
> the details are hidden (needs confirmation).
>
> BTW, in order to have artifacts listed one has to enable artifact
> archiving, not publishing.
>
> Everything works now (except for the job stalling on deployment to a
> self-signed cert GF 4.1 installation. :)
>
>
>
> On Tue, Sep 23, 2014 at 2:43 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>
> > FYI my aim is to supersede the evil job type with some enhanced reporting
> > in what is currently called the literate job type.
> >
> > That would mean you'd get the per-module reporting.
> >
> > The current evil job type's other "killer" feature is automatic
> downstream
> > job triggering... Which is actually broken as it does not take into
> account
> > the local repo that the -SNAPSHOTs may or may not have been deployed into
> > and assumes that `package` is the same as `deploy` as far as triggering
> is
> > concerned as well as ignoring that deployment might be to a staging repo,
> > so the artifacts may not be available downstream... However, despite
> being
> > fundamentally broken at every level, you would be surprised how many
> people
> > feel locked into the evil job type because of this...
> >
> > In short, there is so many issues with it that I cannot recommend its
> > use... The only semi useful feature from my PoV is per module reporting.
> >
> > (Sadly my day job has me having to support the evil job type from time to
> > time... Though usually those tickets get picked up by Kohsuke if I start
> > another "evil job type" tirade ;-) )
> >
> > On Tuesday, 23 September 2014, Curtis Rueden <ctrueden@wisc.edu
> <javascript:;>> wrote:
> >
> > > Hi James,
> > >
> > > > I can no longer see "Deploy artifacts to Maven repository"
> > > > as a post-build action.
> > >
> > > Just add a build step that does "mvn deploy" or similar.
> > >
> > > > Dare I ask what I'm missing having chosen the full-fat option..?
> > >
> > > If you're asking what you cannot do with freeform jobs: I don't know of
> > > anything. I think the Maven-style job is just a convenience to get very
> > > basic CI set up as quickly as possible, for people without much
> technical
> > > know-how.
> > >
> > > If you're asking for more details on limitations of the Maven-style
> job:
> > > it's been awhile, but IIRC my group had several problems. One such was
> > that
> > > the Jenkins Git plugin did not fire Maven-style jobs upon receiving the
> > > push notification from GitHub. Another really serious problem is that
> you
> > > can't add arbitrary shell script as a post-build step. And needing to
> do
> > > this is, in my experience, extremely common.
> > >
> > > It wouldn't be that big of an issue if there were an easy way to later
> > > "convert" a Maven-style job to a freestyle job should the need arise.
> But
> > > try a web search on that topic and you'll see what I mean about it
> being
> > a
> > > highly non-trivial problem.
> > >
> > > Regards,
> > > Curtis
> > >
> > > On Tue, Sep 23, 2014 at 8:56 AM, James Green <james.mk.green@gmail.com
> <javascript:;>
> > > <javascript:;>>
> > > wrote:
> > >
> > > > News to me. Ironically I'm just setting up a new Jenkins job so tried
> > the
> > > > freeform style - I can no longer see "Deploy artifacts to Maven
> > > repository"
> > > > as a post-build action.
> > > >
> > > > Dare I ask what I'm missing having chosen the full-fat option..?
> > > >
> > > > On 23 September 2014 14:02, Curtis Rueden <ctrueden@wisc.edu
> <javascript:;>
> > > <javascript:;>> wrote:
> > > >
> > > > > The Maven style build will also lock you in to a small subset of
> > > > Jenkins's
> > > > > usual features. And when you eventually need a feature not
> available
> > > > with a
> > > > > Maven-style build, there is no conversion path from Maven-style to
> > > > > Freestyle -- you have to recreate the job (losing the build history
> > > > etc.).
> > > > >
> > > > > -Curtis
> > > > > On Sep 23, 2014 7:33 AM, "Stephen Connolly" <
> > > > > stephen.alan.connolly@gmail.com <javascript:;> <javascript:;>>
> > > > > wrote:
> > > > >
> > > > > > Freestyle does not mess with your build and change it from
> building
> > > the
> > > > > way
> > > > > > maven intends. Google "stephen's java adventures Jenkins maven
> > > > considered
> > > > > > evil" for a more detailed discussion
> > > > > >
> > > > > > On Tuesday, 23 September 2014, James Green <
> > james.mk.green@gmail.com <javascript:;>
> > > <javascript:;>>
> > > > > > wrote:
> > > > > >
> > > > > > > On 23 September 2014 02:23, Curtis Rueden <ctrueden@wisc.edu
> <javascript:;>
> > > <javascript:;>
> > > > > > > <javascript:;>> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Also, stay away from the Jenkins "Maven" style job. Freestyle
> > is
> > > > more
> > > > > > > > flexible and less buggy.
> > > > > > > >
> > > > > > >
> > > > > > > Based on ..?
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sent from my phone
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sent from my phone
> >
>
>
>
> --
> “If the American people ever allow private banks to control the issue of
> their currency, first by inflation, then by deflation, the banks...will
> deprive the people of all property until their children wake-up homeless on
> the continent their fathers conquered... The issuing power should be taken
> from the banks and restored to the people, to whom it properly belongs."
> -- Thomas Jefferson
>
> "Government big enough to supply everything...is big enough to take
> everything you have. The course of history shows that as a government
> grows, liberty decreases" --- Thomas Jefferson
>
> www.CampaignForLiberty.org
>
--
Sent from my phone
Re: usage with Jenkins
Posted by Grover Blue <gr...@gmail.com>.
I'd like to weigh in on this. The maven-based job type is great for quick
or single-dimensional project, especially when you know the scope will not
change. I tend to prefer freestyle because of flexibility.
In reality, the solution is to just have one project type with varied
initialization types. I'm pretty sure that's happening in the backend, but
the details are hidden (needs confirmation).
BTW, in order to have artifacts listed one has to enable artifact
archiving, not publishing.
Everything works now (except for the job stalling on deployment to a
self-signed cert GF 4.1 installation. :)
On Tue, Sep 23, 2014 at 2:43 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> FYI my aim is to supersede the evil job type with some enhanced reporting
> in what is currently called the literate job type.
>
> That would mean you'd get the per-module reporting.
>
> The current evil job type's other "killer" feature is automatic downstream
> job triggering... Which is actually broken as it does not take into account
> the local repo that the -SNAPSHOTs may or may not have been deployed into
> and assumes that `package` is the same as `deploy` as far as triggering is
> concerned as well as ignoring that deployment might be to a staging repo,
> so the artifacts may not be available downstream... However, despite being
> fundamentally broken at every level, you would be surprised how many people
> feel locked into the evil job type because of this...
>
> In short, there is so many issues with it that I cannot recommend its
> use... The only semi useful feature from my PoV is per module reporting.
>
> (Sadly my day job has me having to support the evil job type from time to
> time... Though usually those tickets get picked up by Kohsuke if I start
> another "evil job type" tirade ;-) )
>
> On Tuesday, 23 September 2014, Curtis Rueden <ct...@wisc.edu> wrote:
>
> > Hi James,
> >
> > > I can no longer see "Deploy artifacts to Maven repository"
> > > as a post-build action.
> >
> > Just add a build step that does "mvn deploy" or similar.
> >
> > > Dare I ask what I'm missing having chosen the full-fat option..?
> >
> > If you're asking what you cannot do with freeform jobs: I don't know of
> > anything. I think the Maven-style job is just a convenience to get very
> > basic CI set up as quickly as possible, for people without much technical
> > know-how.
> >
> > If you're asking for more details on limitations of the Maven-style job:
> > it's been awhile, but IIRC my group had several problems. One such was
> that
> > the Jenkins Git plugin did not fire Maven-style jobs upon receiving the
> > push notification from GitHub. Another really serious problem is that you
> > can't add arbitrary shell script as a post-build step. And needing to do
> > this is, in my experience, extremely common.
> >
> > It wouldn't be that big of an issue if there were an easy way to later
> > "convert" a Maven-style job to a freestyle job should the need arise. But
> > try a web search on that topic and you'll see what I mean about it being
> a
> > highly non-trivial problem.
> >
> > Regards,
> > Curtis
> >
> > On Tue, Sep 23, 2014 at 8:56 AM, James Green <james.mk.green@gmail.com
> > <javascript:;>>
> > wrote:
> >
> > > News to me. Ironically I'm just setting up a new Jenkins job so tried
> the
> > > freeform style - I can no longer see "Deploy artifacts to Maven
> > repository"
> > > as a post-build action.
> > >
> > > Dare I ask what I'm missing having chosen the full-fat option..?
> > >
> > > On 23 September 2014 14:02, Curtis Rueden <ctrueden@wisc.edu
> > <javascript:;>> wrote:
> > >
> > > > The Maven style build will also lock you in to a small subset of
> > > Jenkins's
> > > > usual features. And when you eventually need a feature not available
> > > with a
> > > > Maven-style build, there is no conversion path from Maven-style to
> > > > Freestyle -- you have to recreate the job (losing the build history
> > > etc.).
> > > >
> > > > -Curtis
> > > > On Sep 23, 2014 7:33 AM, "Stephen Connolly" <
> > > > stephen.alan.connolly@gmail.com <javascript:;>>
> > > > wrote:
> > > >
> > > > > Freestyle does not mess with your build and change it from building
> > the
> > > > way
> > > > > maven intends. Google "stephen's java adventures Jenkins maven
> > > considered
> > > > > evil" for a more detailed discussion
> > > > >
> > > > > On Tuesday, 23 September 2014, James Green <
> james.mk.green@gmail.com
> > <javascript:;>>
> > > > > wrote:
> > > > >
> > > > > > On 23 September 2014 02:23, Curtis Rueden <ctrueden@wisc.edu
> > <javascript:;>
> > > > > > <javascript:;>> wrote:
> > > > > > >
> > > > > > >
> > > > > > > Also, stay away from the Jenkins "Maven" style job. Freestyle
> is
> > > more
> > > > > > > flexible and less buggy.
> > > > > > >
> > > > > >
> > > > > > Based on ..?
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sent from my phone
> > > > >
> > > >
> > >
> >
>
>
> --
> Sent from my phone
>
--
“If the American people ever allow private banks to control the issue of
their currency, first by inflation, then by deflation, the banks...will
deprive the people of all property until their children wake-up homeless on
the continent their fathers conquered... The issuing power should be taken
from the banks and restored to the people, to whom it properly belongs."
-- Thomas Jefferson
"Government big enough to supply everything...is big enough to take
everything you have. The course of history shows that as a government
grows, liberty decreases" --- Thomas Jefferson
www.CampaignForLiberty.org
Re: usage with Jenkins
Posted by Stephen Connolly <st...@gmail.com>.
FYI my aim is to supersede the evil job type with some enhanced reporting
in what is currently called the literate job type.
That would mean you'd get the per-module reporting.
The current evil job type's other "killer" feature is automatic downstream
job triggering... Which is actually broken as it does not take into account
the local repo that the -SNAPSHOTs may or may not have been deployed into
and assumes that `package` is the same as `deploy` as far as triggering is
concerned as well as ignoring that deployment might be to a staging repo,
so the artifacts may not be available downstream... However, despite being
fundamentally broken at every level, you would be surprised how many people
feel locked into the evil job type because of this...
In short, there is so many issues with it that I cannot recommend its
use... The only semi useful feature from my PoV is per module reporting.
(Sadly my day job has me having to support the evil job type from time to
time... Though usually those tickets get picked up by Kohsuke if I start
another "evil job type" tirade ;-) )
On Tuesday, 23 September 2014, Curtis Rueden <ct...@wisc.edu> wrote:
> Hi James,
>
> > I can no longer see "Deploy artifacts to Maven repository"
> > as a post-build action.
>
> Just add a build step that does "mvn deploy" or similar.
>
> > Dare I ask what I'm missing having chosen the full-fat option..?
>
> If you're asking what you cannot do with freeform jobs: I don't know of
> anything. I think the Maven-style job is just a convenience to get very
> basic CI set up as quickly as possible, for people without much technical
> know-how.
>
> If you're asking for more details on limitations of the Maven-style job:
> it's been awhile, but IIRC my group had several problems. One such was that
> the Jenkins Git plugin did not fire Maven-style jobs upon receiving the
> push notification from GitHub. Another really serious problem is that you
> can't add arbitrary shell script as a post-build step. And needing to do
> this is, in my experience, extremely common.
>
> It wouldn't be that big of an issue if there were an easy way to later
> "convert" a Maven-style job to a freestyle job should the need arise. But
> try a web search on that topic and you'll see what I mean about it being a
> highly non-trivial problem.
>
> Regards,
> Curtis
>
> On Tue, Sep 23, 2014 at 8:56 AM, James Green <james.mk.green@gmail.com
> <javascript:;>>
> wrote:
>
> > News to me. Ironically I'm just setting up a new Jenkins job so tried the
> > freeform style - I can no longer see "Deploy artifacts to Maven
> repository"
> > as a post-build action.
> >
> > Dare I ask what I'm missing having chosen the full-fat option..?
> >
> > On 23 September 2014 14:02, Curtis Rueden <ctrueden@wisc.edu
> <javascript:;>> wrote:
> >
> > > The Maven style build will also lock you in to a small subset of
> > Jenkins's
> > > usual features. And when you eventually need a feature not available
> > with a
> > > Maven-style build, there is no conversion path from Maven-style to
> > > Freestyle -- you have to recreate the job (losing the build history
> > etc.).
> > >
> > > -Curtis
> > > On Sep 23, 2014 7:33 AM, "Stephen Connolly" <
> > > stephen.alan.connolly@gmail.com <javascript:;>>
> > > wrote:
> > >
> > > > Freestyle does not mess with your build and change it from building
> the
> > > way
> > > > maven intends. Google "stephen's java adventures Jenkins maven
> > considered
> > > > evil" for a more detailed discussion
> > > >
> > > > On Tuesday, 23 September 2014, James Green <james.mk.green@gmail.com
> <javascript:;>>
> > > > wrote:
> > > >
> > > > > On 23 September 2014 02:23, Curtis Rueden <ctrueden@wisc.edu
> <javascript:;>
> > > > > <javascript:;>> wrote:
> > > > > >
> > > > > >
> > > > > > Also, stay away from the Jenkins "Maven" style job. Freestyle is
> > more
> > > > > > flexible and less buggy.
> > > > > >
> > > > >
> > > > > Based on ..?
> > > > >
> > > >
> > > >
> > > > --
> > > > Sent from my phone
> > > >
> > >
> >
>
--
Sent from my phone
Re: usage with Jenkins
Posted by James Green <ja...@gmail.com>.
On 23 September 2014 18:37, Curtis Rueden <ct...@wisc.edu> wrote:
> Hi James,
>
> > I can no longer see "Deploy artifacts to Maven repository"
> > as a post-build action.
>
> Just add a build step that does "mvn deploy" or similar.
>
See this for me is a post-build action. I guess Jenkins doesn't see it that
way.
Raises the question of how to use the release plugin since that performs
deployment itself.
>
> > Dare I ask what I'm missing having chosen the full-fat option..?
>
> If you're asking what you cannot do with freeform jobs: I don't know of
> anything. I think the Maven-style job is just a convenience to get very
> basic CI set up as quickly as possible, for people without much technical
> know-how.
>
I rather suspect despite it's technical weaknesses, it's the de-facto
unless an organisation hits on it's limitations. I've not spotted a
tutorial on building maven projects with Jenkins that does not use the
Maven style job. We have virtually all our jobs as Maven style ones - we've
not hit any limitations yet.
Re: usage with Jenkins
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi James,
> I can no longer see "Deploy artifacts to Maven repository"
> as a post-build action.
Just add a build step that does "mvn deploy" or similar.
> Dare I ask what I'm missing having chosen the full-fat option..?
If you're asking what you cannot do with freeform jobs: I don't know of
anything. I think the Maven-style job is just a convenience to get very
basic CI set up as quickly as possible, for people without much technical
know-how.
If you're asking for more details on limitations of the Maven-style job:
it's been awhile, but IIRC my group had several problems. One such was that
the Jenkins Git plugin did not fire Maven-style jobs upon receiving the
push notification from GitHub. Another really serious problem is that you
can't add arbitrary shell script as a post-build step. And needing to do
this is, in my experience, extremely common.
It wouldn't be that big of an issue if there were an easy way to later
"convert" a Maven-style job to a freestyle job should the need arise. But
try a web search on that topic and you'll see what I mean about it being a
highly non-trivial problem.
Regards,
Curtis
On Tue, Sep 23, 2014 at 8:56 AM, James Green <ja...@gmail.com>
wrote:
> News to me. Ironically I'm just setting up a new Jenkins job so tried the
> freeform style - I can no longer see "Deploy artifacts to Maven repository"
> as a post-build action.
>
> Dare I ask what I'm missing having chosen the full-fat option..?
>
> On 23 September 2014 14:02, Curtis Rueden <ct...@wisc.edu> wrote:
>
> > The Maven style build will also lock you in to a small subset of
> Jenkins's
> > usual features. And when you eventually need a feature not available
> with a
> > Maven-style build, there is no conversion path from Maven-style to
> > Freestyle -- you have to recreate the job (losing the build history
> etc.).
> >
> > -Curtis
> > On Sep 23, 2014 7:33 AM, "Stephen Connolly" <
> > stephen.alan.connolly@gmail.com>
> > wrote:
> >
> > > Freestyle does not mess with your build and change it from building the
> > way
> > > maven intends. Google "stephen's java adventures Jenkins maven
> considered
> > > evil" for a more detailed discussion
> > >
> > > On Tuesday, 23 September 2014, James Green <ja...@gmail.com>
> > > wrote:
> > >
> > > > On 23 September 2014 02:23, Curtis Rueden <ctrueden@wisc.edu
> > > > <javascript:;>> wrote:
> > > > >
> > > > >
> > > > > Also, stay away from the Jenkins "Maven" style job. Freestyle is
> more
> > > > > flexible and less buggy.
> > > > >
> > > >
> > > > Based on ..?
> > > >
> > >
> > >
> > > --
> > > Sent from my phone
> > >
> >
>
Re: usage with Jenkins
Posted by James Green <ja...@gmail.com>.
News to me. Ironically I'm just setting up a new Jenkins job so tried the
freeform style - I can no longer see "Deploy artifacts to Maven repository"
as a post-build action.
Dare I ask what I'm missing having chosen the full-fat option..?
On 23 September 2014 14:02, Curtis Rueden <ct...@wisc.edu> wrote:
> The Maven style build will also lock you in to a small subset of Jenkins's
> usual features. And when you eventually need a feature not available with a
> Maven-style build, there is no conversion path from Maven-style to
> Freestyle -- you have to recreate the job (losing the build history etc.).
>
> -Curtis
> On Sep 23, 2014 7:33 AM, "Stephen Connolly" <
> stephen.alan.connolly@gmail.com>
> wrote:
>
> > Freestyle does not mess with your build and change it from building the
> way
> > maven intends. Google "stephen's java adventures Jenkins maven considered
> > evil" for a more detailed discussion
> >
> > On Tuesday, 23 September 2014, James Green <ja...@gmail.com>
> > wrote:
> >
> > > On 23 September 2014 02:23, Curtis Rueden <ctrueden@wisc.edu
> > > <javascript:;>> wrote:
> > > >
> > > >
> > > > Also, stay away from the Jenkins "Maven" style job. Freestyle is more
> > > > flexible and less buggy.
> > > >
> > >
> > > Based on ..?
> > >
> >
> >
> > --
> > Sent from my phone
> >
>
Re: usage with Jenkins
Posted by Curtis Rueden <ct...@wisc.edu>.
The Maven style build will also lock you in to a small subset of Jenkins's
usual features. And when you eventually need a feature not available with a
Maven-style build, there is no conversion path from Maven-style to
Freestyle -- you have to recreate the job (losing the build history etc.).
-Curtis
On Sep 23, 2014 7:33 AM, "Stephen Connolly" <st...@gmail.com>
wrote:
> Freestyle does not mess with your build and change it from building the way
> maven intends. Google "stephen's java adventures Jenkins maven considered
> evil" for a more detailed discussion
>
> On Tuesday, 23 September 2014, James Green <ja...@gmail.com>
> wrote:
>
> > On 23 September 2014 02:23, Curtis Rueden <ctrueden@wisc.edu
> > <javascript:;>> wrote:
> > >
> > >
> > > Also, stay away from the Jenkins "Maven" style job. Freestyle is more
> > > flexible and less buggy.
> > >
> >
> > Based on ..?
> >
>
>
> --
> Sent from my phone
>
Re: usage with Jenkins
Posted by Stephen Connolly <st...@gmail.com>.
Freestyle does not mess with your build and change it from building the way
maven intends. Google "stephen's java adventures Jenkins maven considered
evil" for a more detailed discussion
On Tuesday, 23 September 2014, James Green <ja...@gmail.com> wrote:
> On 23 September 2014 02:23, Curtis Rueden <ctrueden@wisc.edu
> <javascript:;>> wrote:
> >
> >
> > Also, stay away from the Jenkins "Maven" style job. Freestyle is more
> > flexible and less buggy.
> >
>
> Based on ..?
>
--
Sent from my phone
Re: usage with Jenkins
Posted by James Green <ja...@gmail.com>.
On 23 September 2014 02:23, Curtis Rueden <ct...@wisc.edu> wrote:
>
>
> Also, stay away from the Jenkins "Maven" style job. Freestyle is more
> flexible and less buggy.
>
Based on ..?
Re: usage with Jenkins
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Grover,
> CI build/packages successfully but not
> artifacts are listed on the jobs page
For Jenkins to publish artifacts (for any build, not just Maven-based ones)
you must use the "publish artifacts" option and specify the file path
patterns to publish.
Also, stay away from the Jenkins "Maven" style job. Freestyle is more
flexible and less buggy.
Regards,
Curtis
On Sep 22, 2014 4:21 PM, "Grover Blue" <gr...@gmail.com> wrote:
> Is there anything special that needs to be added to a pom in order to work
> with Jenkins? For some reason, by CI build/packages successfully but not
> artifacts are listed on the jobs page (they are hidden on the file-system
> in a "default/*" directory).
>