Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #20151 > unrolled thread

Getting A Build Process In Place

Back to article view | Back to comp.lang.java.programmer

Contents

  Getting A Build Process In Place Lee Theobald <lee@ltheobald.co.uk> - 2012-12-07 02:06 -0800
    Re: Getting A Build Process In Place Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-07 04:36 -0600
      Re: Getting A Build Process In Place Arne Vajhøj <arne@vajhoej.dk> - 2012-12-07 20:13 -0500
        Re: Getting A Build Process In Place Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-07 20:44 -0600
    Re: Getting A Build Process In Place Roedy Green <see_website@mindprod.com.invalid> - 2012-12-08 00:51 -0800
      Re: Getting A Build Process In Place Arne Vajhøj <arne@vajhoej.dk> - 2012-12-09 18:47 -0500
    Re: Getting A Build Process In Place Fredrik Jonson <fredrik@jonson.org> - 2012-12-08 10:45 +0000
    Re: Getting A Build Process In Place Lee Theobald <lee@ltheobald.co.uk> - 2013-01-24 01:45 -0800
      Re: Getting A Build Process In Place Roedy Green <see_website@mindprod.com.invalid> - 2013-01-26 19:24 -0800

#20151 — Getting A Build Process In Place

Hi all,

I'm trying to get our company build process a little more automated and would appreciate some feedback on where to direct our attention.  The current build process works as follows:

- Projects are normally web applications packaged in wars.  We use Maven to manage dependencies etc. & the code is stored in SVN.
- Within our pom.xml, we have a number of Maven profiles.  There is normally a "shared" profile that contains the majority of the configuration for the application (put in place with the resources plugin) followed by a more environment specific profile (dev, staging, production etc.) containing additional information.
- When it comes to building for an environment, a developer will build a war file on his local machine using a machine command similar to "mvn -P shared,production clean package".
- This gives the developer a war file.  They then SCP these up to the relevant server, extract to a Tomcat & restart that Tomcat.

This is working fine but there's a lot of room for improvement.  Recently we've looked at using Jenkins for continuous integration but haven't got too far with it.

So here are the points I'm wondering about:

1) Are Maven profiles the best way of storing this specific environment?  The pom's are certainly getting bloated with a lot of configuration & this can be quite intimidating to a newbie.  Any suggestions on alternatives
2) The whole devops movement seems to be something that could help me out here but I'm not too sure where to start.  I've heard about a pipeline using something along the lines of Maven --> Jenkins --> Puppet working well.  With Jenkins handling the build & Puppet deploying.  Does anyone have any experience with this?

Cheers for any input
Lee,

[toc] | [next] | [standalone]

#20152

Lee Theobald <lee@ltheobald.co.uk> wrote:

> 1) Are Maven profiles the best way of storing this specific
>  environment?  The pom's are certainly getting bloated with a lot of
>  configuration & this can be quite intimidating to a newbie.  Any
>  suggestions on alternatives

In my personal opinion, although Maven does a pretty good job of
dependency management, it's not a very good _build_ tool, in part
because Maven's profiles is a cumbersome, awkward way to manage
environment configurations. 

I much prefer the new generation of build systems such as Gradle or
Buildr which combines Maven style dependency management and sensible
defaults with a programmatic approach. (That said, the greater
flexibility and ease-of-change of these tools might require a little
more self-discipline when developing the builds of your projects to
keep them from becoming a mess of special rules and exceptions.)

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#20166

On 12/7/2012 5:36 AM, Leif Roar Moldskred wrote:
> In my personal opinion, although Maven does a pretty good job of
> dependency management, it's not a very good _build_ tool, in part
> because Maven's profiles is a cumbersome, awkward way to manage
> environment configurations.
>
> I much prefer the new generation of build systems such as Gradle or
> Buildr which combines Maven style dependency management and sensible
> defaults with a programmatic approach. (That said, the greater
> flexibility and ease-of-change of these tools might require a little
> more self-discipline when developing the builds of your projects to
> keep them from becoming a mess of special rules and exceptions.)

I would be tempted to say that the biggest problem of Maven is
that it has to be "the Maven way" and the biggest benefit of Maven
is that it has to be "the Maven way".

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#20176

Arne Vajhøj <arne@vajhoej.dk> wrote:
> 
> I would be tempted to say that the biggest problem of Maven is
> that it has to be "the Maven way" and the biggest benefit of Maven
> is that it has to be "the Maven way".

There's a fair bit of truth to that -- although I'd say that the
_biggest_ problem is that the Maven way is poorly laid out and very
badly marked and is often indistinguishable from the roughage along
the edges. (Its surface is also a hodgepodge of paving stones, dirt
tracks, flecks of asphalt, 1600 mm railway gauge and pieces of
developer roadkill.)

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#20181

On Fri, 7 Dec 2012 02:06:39 -0800 (PST), Lee Theobald
<lee@ltheobald.co.uk> wrote, quoted or indirectly quoted someone who
said :

>
>I'm trying to get our company build process a little more automated and wou=
>ld appreciate some feedback on where to direct our attention.  The current =
>build process works as follows:

The way I do it is use a Java program to stomp out ANT scripts.   This
way I have to specify a bare minimum to build a project and I can
change the way every build script works by changing one line of code.

ANT is very quick at compiling because it loads javac only once. It
also has GenJar which figures out by itself what to include in the
Jar.

I can't compare it with Maven. Maven docs did not speak to me in the
terms I wanted to understand what it does before I would invest in the
learning curve.


ANT is preposterously verbose, but at least is its comprehensible.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [prev] | [next] | [standalone]

#20206

On 12/8/2012 3:51 AM, Roedy Green wrote:
> On Fri, 7 Dec 2012 02:06:39 -0800 (PST), Lee Theobald
> <lee@ltheobald.co.uk> wrote, quoted or indirectly quoted someone who
> said :
>> I'm trying to get our company build process a little more automated and wou=
>> ld appreciate some feedback on where to direct our attention.  The current =
>> build process works as follows:
>
> The way I do it is use a Java program to stomp out ANT scripts.   This
> way I have to specify a bare minimum to build a project and I can
> change the way every build script works by changing one line of code.

Ant has built in ways to achieve that.

Arne

[toc] | [prev] | [next] | [standalone]

#20184

In <5e2d6688-c429-4551-956f-8e8108a339c5@googlegroups.com> Lee Theobald wrote:

>  I'm trying to get our company build process a little more automated and
>  would appreciate some feedback on where to direct our attention. The
>  current build process works as follows. Projects are normally web
>  applications packaged in wars. We use Maven to manage dependencies.

I agree that using profiles in maven builds is rather verbose and not very
simple to work with. I'd almost consider profiles a necessary evil that should
only be considered as a feature of last resort.

Have you considered using separate modules, all depending on or using the
base project as a parent? I think this approach is easier, it is straight
forward to understand that a separate module has different configuration
files, compared to how hard it is to perceive how a combination of profiles
affects a build.

What I usually do is to have a base module that contains the source code and
the development environment configuration. Then you have separate modules
for the integration test environment and production environment, each with
their set of configuration files that overrides the ones in the base module.

If you want to you can set this up as a multi module project, ie parent that
contains submodules development, integration, and production. Though
multi-module projects have their own gotchas, so if you want to keep it
simple, start by just make separate standard modules with dependencies.

BTW, I hope you are aware that when you declare a dependency of type war,
the war is unpacked, including web resources, in the dependent project. That
means that your jsp-files can be maintained in the base module, they do not
have to be copied or version managed separately in the dependent modules.

https://maven.apache.org/plugins/maven-war-plugin/overlays.html

Using Jenkins is indeed a good idea too. Though the purpose of using a
continuous build system, to me at least, is orthogonal to the goal of
having a transparent build configuration. Jenkins runs the slow and boring
integration tests and reminds you that you forgot to add that new source
file in your last commit before you pushed. It doesn't by it self make your
build configuration more understandable.

Maybe even the opposite? If you set up Jenkins to compile your rather
complicated build targets, so that you seldom have to do it yourself, then
you are confronted with that complexity less often and forget how it works.
You might end up with a cargo cult based build configuration.

-- 
Fredrik Jonson

[toc] | [prev] | [next] | [standalone]

#21634

Thanks for the responses everyone.  You've given me a few threads to investigate.

[toc] | [prev] | [next] | [standalone]

#21782

On Thu, 24 Jan 2013 01:45:21 -0800 (PST), Lee Theobald
<lee@ltheobald.co.uk> wrote, quoted or indirectly quoted someone who
said :

>Thanks for the responses everyone.  You've given me a few threads to investigate.

see http://mindprod.com/jgloss/ant.html

Maven is more abstract.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development 
time. 
~ Tom Cargill  Ninety-ninety Law 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web