Is there a tool to convert a Buckminster project into Maven? - maven

I'm tasked with migrating our product's build/dependency-management technology from Buckminster to Maven. I'm quite decent with Maven, but before I drill down into Buckminster's inner-workings (which I'm not currently very knowledgeable on), I thought I'd see if there was an available tool to automate this, as it would be a rather lengthy task if done manually. If not, I guess I'll write one myself.
Any input would be much appreciated! Thanks!

Related

Ant to Gradle Build Project - Help/Assistance Needed

Nice to be in this channel.
I have a specific need that I'm hoping some of you might be able to help with.
We have a large project where we are migrating from ant to Gradle. The Java code has been built up over the past 15 years so there is a lot of it.
We are struggling with this migration as we don't know gradle at a deep level. We know how it works & have used it lots of times to build java projects. However, this is different as the projects are so large, we need somebody with a deep understanding of how gradle works at a low level.
So, I'm putting this message out there, asking if anybody is interested in working with us on this for 3,6,9+ months. If you know of anybody who could help us then I would really appreciate an intro.
Thanks in advance, John.

Maven online training

I'm some kind of 'Maven expert' in my company, the problem being that I have a good basic knowledge of Maven, but I'm absolutely not an expert when it comes to release, etc...
I'm desperately searching for some kind of good online training for Maven that is not for beginners and that will speak about release and other advanced stuff.
I have no problem to have a course that starts at the very beginning of Maven, but I want to go further than basic dependency management, basic lifecycle and simple project build, my real goal being to be comfortable with full Maven release.
Has anyone a good website, or something for me ?
Thank you,
Seb
This is a question that's broader than just Maven. Because what you do with Maven is determined by the dev process.
If you're interested in general in dev/release process, you could research Continuous Deliver topic as well as Continuous Integration. You could start with Continuous Delivery book which gives a good perspective on both CI & CD (it's pretty boring though).
As for the videos, you could just search in the internet for Continuous Delivery. I like in particular videos from Sam Newman.
As for the Maven itself, there are books like Maven Complete Reference or Apache Maven 2 Effective Implementation (which is a bit old, but Maven was pretty stable from the end user perspective, so not much changed).

why do we need complexity in dependency management

I am not sure if the title of the question is correct, but please read the question.
I have been working on C/C++ for most part of my work life (close to 11 years). we only had C/C++ source/header files and all dependencies were managed by Makefiles. things were simple and manageable.
for the last 1.5 years i have shifted to Java domain. and i feel extremely irritated that most difficult aspect of working with anything new is the dependency managers. e.g. maven, leiningen, builder, sbt, etc etc etc.
whenever i download anything new from the open source world, there is a significant amount of time to be spent to just to setup the compilation, build, run environment. that too when i am using eclipse. why can't all the dependencies be placed along with the software to be downloaded?? why the tools like maven,leiningen, etc must make a separate internet connection to download the dependencies. i know that maven forms a local repository and should be able to find the dependency locally as it downloads whole internet anyway, but why is this model used. I am behind a firewall and not everything is accessible, and the tools fail to download dependencies. i am sure the same situation is there in most work environments.
recently i started with clojure, and boy it has been a pain to get eclipse configured for clojure. leiningen is supposed to be some magic which must be used with any clojure development. sometimes it feels learning leiningen is more important than learning concepts of clojure. i downloaded so called 'standalone' jar file for leiningen as 'self-install' was not working for me. but it fooled me. as soon as i run 'lein' command it is making an internet connection and trying to download somethings. WHY? it wont even print the help menu without connecting with the internet. WHY? there is no way i can fulfill its demands without bypassing my internet firewall, as i dont know, and no one can tell me what all things this guy wants. there is simply no other way.
And every one seems to be inventing their own. Java had ant which was simple, and went to Maven, some project uses Ruby based Builder, Clojure has leiningen, Scala has sbt. Go has something else. WHY? Why we need this added complexity in a world already full of complexity. why cant there be just one tool.
All you experts in Java technology please excuse my rant. I am sure this question will be downvoted and closed as from someone who is not trying hard enough to understand the things. But please believe me i have spend enough hours battling with this unnecessary complexity.
I just want to know how others get around this, or am i the only unfortunate one facing these issues.
I guess this question cannot accept an answer. I humbly can provide you with elements, hopefully they will help you get some perspective on the problem.
There are mainly 2 problems I identify with Java build systems:
some of them are declarative while others are using scripts
the fragmentation of the Java tools for building and exercising control is tied to people and Java stewardship of the space, not so much the technological choices.
Maven is the paramount of a method of defining your build using a formal grammar in a standard manner. Your pom.xml file contains a lot more than just your build : it is the identity of your artifacts, the project metadata, the modules and the plugins brought in. It treats with particular attention of the declaration of the dependencies and repositories.
Maven is declarative.
For a certain population of programmers, this is great, and they don't create new projects very often. It works well over time, it consolidates the build nicely.
Ant is a different system where you define tasks that will execute, chained in a particular order. All the definitions are made using XML and in effect, you are writing scripts and declaring how they will be stitched together.
Buildr (full disclosure: I am a committer there) is a build system which was created off the frustration of dealing with the inefficiency of the declarative approach for cases where the build needed to do additional steps and complex testing and the rigidity of using XML for a build. It is script-based, enforcing conventions over configuration (expecting a few good defaults, but letting you drive if you need to change things).
I am not familiar with Gradle and SBT but I think they extend and build on this approach, from what I heard.
So this gives you I hope a better picture of the landscape in terms of build tools.
The reason why no standard build tool emerged is probably tied to the fact Sun didn't push one with Java. Eventually, I think they adopted Ant (I have some most JSR jars being built with it). There also has been some products built in this space over extending some of those build systems ; there is always going to be a huge difference between people being paid to maintain code rather than doing it on the side.
And well, people argue. Build systems are a great way to start a flame war. We have a hard time agreeing on a standard though some of the common elements are now settling well around the Maven artifacts.
As for the need to download the Internet over and over again, it's a rather long story but here are a few things that may trigger the need for an unnecessary download:
any of the dependencies using SNAPSHOT will try to get the latest snapshot. This is a great scheme but it takes its toll. You might depend on something that depends on a snapshot, and get a download because of that.
Maven doesn't redownload the artifacts but sometimes checks md5. This is easy to fix, just use the -O option from the command line.
Tools like Buildr were built around fixing this issue once for all. First off, you only download what you said you would. Second, no connection is made again unless you asked for it. By default, Buildr doesn't play the transitive dependencies game though you can ask for it, but you have to do it explicitly.
I hope this was informative and that your journey in Java land becomes less painful going forward.

Build system for multi-language project

I am getting ready to embark on a project mainly for experimenting with languages, but also with a hint of usefulness. It will consist of a server-application, written in Erlang, and client-libraries in a number of languages. Initially I will want to write clients in Java, Ruby and Python. The actual protocol for communication will be Thrift.
I'm looking for a build system that will allow me to build the server and all the client libraries in one go, running unit-tests in each language, then packaging up a releasable artifact of some sort in whatever way is the "standard" for each language.
That means a Jar for Java, a RubyGem and a distribute/setuptools tarball for Python. Erlang probably has something too, but I'm not yet familiar with that. It should also be able to run the Thrift compiler to generate the various Thrift-stubs in each language.
On the pad at the start is Maven. I'm fairly certain Maven can do all I need, but I fear it's too Java-centric, and leaves me with a ton of work for every new language I need to add.
well one should know what the requirements are for every language to create a deliverable artifact.
if copy files from here to there and zip it is enough maven could cover most of the scripting languages.
But you may end up writing plug-ins to support a custom packaging (which is not that complicated, so if there is no build system that may be a good choice).
It might not suit the build systems for every language to force maven upon them. So Maybe use the specific build tools available and wrap them in simple script and execute them using a continuous integration server (like bamboo, jenkings/hudson, teamcity, ...) to have them build in a specific order (to 'fake' dependencies)?
I'm not aware of a cross language system.
Gradle might be more flexible as its approach is more script oriented.
And there is http://eclipse.org/buckminster/ - just for completeness (havent had a look for quite some time)
regards
werner
"It will consist of a server-application, written in Erlang,
and client-libraries in a number of languages.
Initially I will want to write clients in Java, Ruby and Python. "
Maven is good if you follow its way. It is actually more of my way or high way.
See: http://community.jboss.org/wiki/MavenVsGradle
For a lot of standard java projects it is actually very good. But if you need to use other things it becomes fairly complicated very quickly.
From your description it is on its way to become complicated very quickly.
I suggest to look gant (groovy + ant) and gradle. You can call other scripts from gant and/or gradle. JPython, JRuby will be your friend. Ant has a lot of tasks which will be very useful.
I have successfully implemented complicated Java/C++/C build project using Gant. Groovy scripting is powerful and easy to use. Gradle is similar and in some ways more powerful than gant.

Is Hudson a mature continuous integration tool now?

I have searched the SO site for question about Hudson but some of it are a little dated now say 2 years or more. Some comments link Hudson as 'newbie' ing the CI Field
I just would like to know if Hudson is mature right now and is the best option for a CI tool.
Thanks
P.S. I just would like to hear latest feedback from community.
I would thoroughly recommend Jenkins, which is a fork of Hudson made in late 2010/early 2011 (wikipedia has more information on the split if you're interested). You'll find more contemporary resources if you do a search for Jenkins - but at the moment most Hudson tutorials are still relevant.
As to stability/maturity, we've been using it for many months without any issues that I'd attribute to maturity :)
We are using Jenkins for our continuous integration and found it quite useful.
All the basics are there, regarding starting builds, getting and generating statistics from i.e. build results, unit tests, function tests. It is also very flexible as you can ask Jenkins to execute a script which does pretty much anything you need.
Jenkins is the best I've tested so far, and also it is free.
I think nobody can answer if it is the best option for you. It might be mature and everything, but that doesn't mean it's the best for your particular problem

Resources