File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Ant, Maven and Other Build Tools and the fly likes OS on Build Machine Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » Ant, Maven and Other Build Tools
Bookmark "OS on Build Machine" Watch "OS on Build Machine" New topic
Author

OS on Build Machine

Michele Smith
Ranch Hand

Joined: Oct 27, 2010
Posts: 412
Hello:

I need to develop specifications for a build machine. I need it to be a pristine environment, utilizing jdk 1.6 and jre 1.6 variant.

I need to know the specs for this machine. I have a separate development machine.

How should i configure the build machine? My needs are as follows:

Windows 8.1 Windows 8 Windows 7 64-bit Windows 7 Windows Vista Windows XP SP3 Windows XP SP2

Chrome 33 FF 3.5 Safari 5 IE 8.0

It is a Eclipse Junos app utilizing a variant of jdk/jre 1.6

Many Thanks,
Michele
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41068
    
  43
I'm confused. What does the list of Windows versions have to do with setting up a build server? Or the list of browsers? Are they used for automated testing happening as part of the build in those environments? Also, what do you mean by "Eclipse Junos app" - is the app to be built a desktop app? And what do you use as build tool - Jenkins?


Ping & DNS - my free Android networking tools app
Michele Smith
Ranch Hand

Joined: Oct 27, 2010
Posts: 412
Hello, I inherited the application from another developer who did not use Jenkins, ant, or maven.

In the short term, I need to develop a pristine development machine and build machine

The application utilizes the aforementioned oses and browsers for the exception of the chrome 33 browser.

I need to get a build machine up and running which does not use Jenkins, ant or maven.

Then i need to get a build machine up and running which does use ant or maven, I am still deciding which one to use. I am learning towards maven.

I need some basic advice on how to configure the build machine and some info on how to get the files to the build machine. The development machine utilizes jre 1.6/ jdk 1.6 variant and is created utilizing Eclipse Juno.

thank you,
Michele
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41068
    
  43
I would start by making the build independent of any IDE - just tools like Ant, Maven, Jenkins etc.

The application utilizes the aforementioned oses and browsers for the exception of the chrome 33 browser.

What does "utilize" mean? Those are the supported OSes it's supposed to run on? Unless the build should run automated tests of the app on all those OS I don't see how that would otherwise be relevant. Or does the app need some Windows-specific functionality?

Since you're only talking about Windows, shared directories (on the build servers or on a common file server) should work fine for distributing any involved files.
Michele Smith
Ranch Hand

Joined: Oct 27, 2010
Posts: 412
Hello:

I mean the supported browsers for the application I am really concerned about pristine state of dev and build mchine nd need to develop specs can you help me? I need to dev specs for build machine and figure out how to get files from dev machine to build machine.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41068
    
  43
Why does it matter so much that the machines are "pristine" (I'm not even sure what exactly you mean by that)? A web app -which I assume we're talking about, since you mention "supported browsers for the application"- should not care much about what kind of machine it's built on.

Getting files from one machine to another should be almost trivial - any OS supports shared directories/drives.

With respect to the specs - that would depend on what you intend to do on the machine. Obviously, a fast CPU and lots of RAM help, but we're not talking about a production web or app server. Start by defining what the machine must be capable of doing - like, no more than X minutes for a build, and then measure how long the build takes on an existing machine. That should give you starting point. RAM and disks are cheap enough to make it a no-brainer to load the machine with those.
Michele Smith
Ranch Hand

Joined: Oct 27, 2010
Posts: 412
Hello thank you for your recent response. It is sincerely appreciated.

My question is that I am highly concerned about dependencies and libraries and I want to make sure the dev and build machines are separated and that there are no "messes involved with dependencies or libraries" being attached by accident to the build machine.

Does this help you to understand better?

Thank you,
Michele
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41068
    
  43
Not really, actually. Build systems are generally set up so that dependencies are managed by the build, not via some pre-installation. I think you're placing too much emphasis on this. Do you have concrete reasons (past experience, maybe) to assume otherwise? It would help if you told us what kind of app this is; I've assumed web app, but you haven't said.
Michele Smith
Ranch Hand

Joined: Oct 27, 2010
Posts: 412
yes it is a web app.

i really want to be super careful

I used to be a microsoft asp .net vb developer. There are dependencies in that scenario.

Thanks,
Michele
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41068
    
  43
Yep, I can easily imagine how that gets tricky, and dependent on the machine. But Java web apps are fundamentally different.
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2271
    
  28

Ahh. Good old Microsoft. I used to be in Microsoft world long time ago, and back then it was a big mess. We had this thing called DLL Hell. Visual Studio comes with it's own dlls that need to be packaged with your applications. When you installed your application, the DLLs would go into the path. The problem is that if you had 2 applications built in Visual studio, they would step on each others toes. This and the lack of dependency management and version control of dependencies caused a lot of confusion. You never knew what DLLs you were dependent on and what version. On top of that, a lot of configuration was stored in the registry, and it was messy to edit the registry. So, to assist in troubleshooting, you would maintain this pristine environment that had all the DLLs that you needed. Whenever your application didn't work, the first thing is that you copy all the DLLs from your pristine env into your target machine. It broke someone else though... but screw em! If copying DLLs didn't solve the problem, you tried tinkering around with the Registry, in which case, you will either fix the problem or nothing else will work. I mean like Windows might stop working. Either restore from backup, or reinstall everything from scratch. Remember this is not your "build" machine, in the sense that this is not where you build your artifacts. This is an environment that you have carefully and lovingly built. It's your baby. You don;t let anyone touch that machine. It's your sweet little delicate flower.

I don;t know how things are with .NET. I think they probably have made some progress

Java, OTH, was built with the notion of classpath from the very begginning. All the depdnencies are packaged into jars. Each Java application has a classpath, and you put all the jars that your application needs into the classpath. Since, each app can have it's own classpath, you solve the DLL hell problem. You just put all the jars that an application needs into it's own folder. You still need to keep the pristine jars somewhere. However, you can just check in all the jars that you need into your source control repo. "installing" an application requires you to only copy the jars from your one place to another. There's nothing else to mess with. This is why you don;t need "pristine" builds. You instead have a "build" machine, which most java developers understand as a machine that is responsible for building your application. You don't keep the build anywhere. You just build it from scratch everytime you want. A much less flaky solution

You still have a verison of DLL Hell that I call Jar Purgatory. You usually end up having a lib folder in your source control that has all the jars that you need. Everytime, you use a new library, you figure out what other libraries it needs, and you copy the jars of all these libraries into the lib folder. The problem is people always add jars, but no one removes jars. Why? Because who is going to risk it? Who knows where the library is being used? So, over time you end up bloating your lib folder. And when you run into a situation where you have to upgrade a jar, you are never sure what other jars you need to upgrade. So, you never upgrade any jar. In 2 years, you dare not go to latest version of hibernate because you don't want to upgrade apache common lang :p

This problem is solved by maven which provides robust dependency management and version control of artifacts. Anyways, no point in going into this in much detail

Michele the way you should approach this is that you shouldn;t depend on a pristine environment. Instead think about having your build be self contained. Your code should build anywhere. All it should need is sme sort of build tool. The build tool could be plain old JDK or ANT or Maven. Everything else should be checked into the source control. This allows you to put something like Jenkins on your build machine. Jenkins can be setup to check out the source from repo, and run the build script. If you do this, you will be worried less about having a pristine environment, and more about having a pristine release in your source code repo (which is a more manageable problem)
Michele Smith
Ranch Hand

Joined: Oct 27, 2010
Posts: 412
Wowie! Thank you for your comments kind sir!

Thank you again,
Michele
Michele Smith
Ranch Hand

Joined: Oct 27, 2010
Posts: 412
Hello:

I have never built an application requiring ant. I have been told that maven is the way to go, however, I do have a local mentor who could help me with ant if I got into troubles. The application I am responsible for is breaking and it has not been built with ant. What happens is that everytime a bug is fixed, another bug pops up. I am trying to stabilize the development environment. Would you have any places you would recommend I go to to learn more about how to integrate ant into an application J2EE application which does not currently utilize ant?

The way I understand it is this: ant is an executable wrapper for the main java functionality.

I know how to put the ant executable on my path.

Can you help point me in the right direction?

Thanks,
Michele
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41068
    
  43
The way I understand it is this: ant is an executable wrapper for the main java functionality.

That is one tiny part of what Ant can do, and far from the main part. Ant is a build system, not so much a runtime system. You can learn about it at http://ant.apache.org/
Michele Smith
Ranch Hand

Joined: Oct 27, 2010
Posts: 412
Okay great.

Many Thanks,
Michele
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15951
    
  19

Michele Smith wrote:
I need to get a build machine up and running which does not use Jenkins, ant or maven.


Red Alert!


If you're doing production builds using an IDE instead of a command-line builder, expect major pain. I speak from bitter experience.

Any build that's dependent on an IDE is subject to 2 exposures, in my experience.

1. There's almost invariably a lot of quirky configuration that differentiates the IDE environment on one machine from that on another. One place I worked had certain resource configurations in effect in one department that were substantially incompatible with how we were set up in our department.

2. I won't say that batch-mode build processes won't break with time - Microsoft makefiles taught me otherwise. However, Ant and Maven are far less likely to sting you than what you'll routinely experience when an IDE used to build a critical system has been upgraded. I got horribly close to having to install a vintage version of Windows in order to install an antique version of Visual Studio in order to compile a 2-line change that could be edited - but not built - with Notepad. All in a rushed panic environment. And had similar things happen more than once.

Another reason for avoiding IDE-based production builds is that it's a lot easier to do a build for products that run on other OS's, such as IBM iSeries mainframes, Linux, or Solaris from a batch process than it is from an IDE that may not even run on those platforms.

Jenkins is a good resource to have if you're the buildmaster, since it can handle build dependencies above and beyond what basic Maven and Ant setups can do, but at least consider using Maven or Ant over using an IDE.


Customer surveys are for companies who didn't pay proper attention to begin with.
Michele Smith
Ranch Hand

Joined: Oct 27, 2010
Posts: 412
Ah HA! That is what I was looking for.

Many Thanks,
Michele
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: OS on Build Machine
 
Similar Threads
Why doesn't this code work in Netbeans 7.0?
Problem in executing jar with windows 7 64 bit
why jre after exe produced
Question Regarding the Need for JDK/JREs
Who uses Java 7?