Future of the Maven Project Type

[Mark Bidewell]

In my current position, I inherited a Jenkins server that makes heavy use of the Maven Project Type and M2 Release Plugin.  As Jenkins is moving forward, I am now understanding why many people do not like that project type due to the shims needed to support Java 6 builds.

What is the future of the Maven project type? should I be making plans to migrate from it?  If so what is the best alternative (right now I am thinking workflows)?

Thanks

[R. Tyler Croy]

(replies inline)

NOTE: This doesn't represent any sort of official view or whatever.



Migrating off of the Maven project type is, in my opinion, always a good
decision. I've found that it is in some ways too tightly integrated, like with
the JDK version you mentioned, and in other ways not well integrated into the
plugin ecosystem.

The downside, in my personal opinion, to switching over to Workflow right now
is that there might be plugins which aren't fully compatible with the workflow
job type, see here:
<https://github.com/jenkinsci/workflow-plugin/blob/master/COMPATIBILITY.md>


I think Workflow is the right choice long-term, and in 2.0 will be fairly
front-and-center in the experience, but there are some hiccups such as those
with compatibility right now.


Hope that helps raise new questions :P


Cheers
- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>

% gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
------------------------------------------------------

[Arnaud Héritier]

It mainly depends of the usage you have of it.

There are some specific features (post build deployment, snapshots dependencies) which aren't available in others jobs types.

The migration to freestyle jobs is probably the easiest one from now as you may have a large part of maven job types features but you'll need some manual configuration.

Using the workflow is a solution but for now it doesn't cover all integrations with plugins (contributions are welcome) and thus it may be blocker depending of the current usage you have of it

Arnaud

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/45849d7b-990e-4232-a8dd-c4d37b9b2310%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

[Mark Bidewell]

The primary usage is for the M2 release plugin integration.  We are not making use of many other features.

[Arnaud Héritier]

yes this one won't be compatible with workflow or freestyle jobs.

You'll have to replace it with a call of "release:prepare release;perform" with few parameters defined as workflow user inputs or freestyle parameters.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b613e575-7b8a-419b-b5a6-0aeb798e519d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mark Bidewell]

Thanks that was my plan and use workflow to emulate as much of the release plugin functionality as possible (version verification for example).  I just wanted to be sure that was the best course of action and there wasn't a better way forward.

[Stephen Connolly]

My plan, once I come up with a better name for literate, is to have that project type be able to provide smart builds of Maven projects with near zero configuration (other than adding a marker file to say literate should consider this as a valid branch)

I see s/workflow/pipelines/g as the project type for the 10% of jobs that need to do more complicated things such as orchestrating across multiple source control systems, deploying into production, etc.

For the 90% of jobs you just want a simple build...

I would have thought that adding a README.md to your project with content like

# How to build

```

mvn clean verify

```

Would not be objectionable to anyone, and would advance the future maintainability of your projects (who doesn't want a README file in every project that at least tells you what command to type in order to build the project... well from the lack of feedback on literate it would seem that very few people are interested in that README file... I suspect it is a form of job security through obscurity but whatever)

So instead it seems that literate needs a sexier name and some way to obscure the "how to build" and "what you need to build" information...

# Introduction

This is the whiz-bang connector module to connect a whiz to multiple bang instances.

# Environment

You need the following toolchains to build:

* `java-1.8`

* `maven-3.3.9`

* `docker-1.9`

# Build

The following command will build the module and run all the tests

```

mvn clean verify

```

# Release

To release this module run the following command

```

mvn release:prepare release:perform -B

```

I am a sad panda that this project type did not take off... but whatever

-Stephen 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/3a3718a8-f2f3-473c-a2eb-cdff95dcee25%40googlegroups.com.

[Christopher Orr]

On 18/11/15 11:47, Stephen Connolly wrote:
> My plan, once I come up with a better name for literate, is to have that
> project type be able to provide smart builds of Maven projects with near
> zero configuration (other than adding a marker file to say literate
> should consider this as a valid branch)

Sounds good!

> I am a sad panda that this project type did not take off... but whatever

Am I missing something? There are posts here every so often that
mention the amazingness of Literate, yet it's never had a release, so
nobody can install it, so I'm not surprised it hasn't taken off...

Unless you scroll to the bottom of a blog post on jenkins-ci.org from
2013, or to the bottom of the infobox-less wiki page, and then change
your Update Centre, you'll never see the plugin.

If it works even half-decently, just release it.. right? :)

Regards,
Chris