We're starting a project written in Java in a company which works purely on MS technologies. Microsoft Team System is used as source control tool. A question is whether we should try to integrate Eclipse with MTS (which makes sense from the top level as there would be still a single repository for the company) or we should try to setup another source control tool - most likely Subversion (which makes sense from developers perspective)?
Anyone tried to marry Team System with Java projects? Does it makes any sense?
You can use Team Foundation Server with Eclipse with Teamprise.
As for whether it makes sense or not depends on the environment. If you are one of many projects, just one that happens to be Java, it does not make sense to reinvent the wheel and implement SVN, unless the business is making a clean deliniation between Java projects and MS projects ... and realizing they have two places to get metrics for projects, which can be nasty.
I would vote on TFS, personally, as there is already an investment in TFS.
I work on a project that uses eclipse and teamprise to use TFS with java. While the experience isn't perfect, it does work fairly well.
Since your company already has an investment in TFS I would stick with that if you and your team have comfort with TFS as a version control system. However, if you are comfortable with subversion and not with TFS, then I say just make the switch to subverison and you won't look back.
My team is in a similar situation...our company has recently standardized on TFS for source control, and we are a Java group (with many other teams in my company being Microsoft...thus the decision to go with TFS). We are migrating from VSS, so we're actually pretty happy to get to a more modern system (although I would have preferred SVN).
We use IntelliJ IDEA, and with version 8.1 they now have integrated TFS support. So far it seems to be working quite well. We also use Hudson for our continuous integration server and there is a nice TFS plugin for that, too. From our Ant scripts we are using the free Teamprise Ant Tasks when we need to access TFS.
One thing the might be helpful if you end up using tfs (but not teamprise) is the Team Foundation Power Tools 2008 adds Window Explorer extension support (although I wish it has ‘get specific version’ as a menu option)
http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx
From the above link...
"Windows Shell Extension - Allows core version control operations within Windows Explorer without using Team Explorer."
It's free now (after March 2012).
Microsoft.com; Download
Related
For this question, assume that Java code (domain classes) exist for some problem domain for which no tools are available in Eclipse. One could then write a "rich client" based on the Eclipse platform to provide tools. Assuming that the tools are intended to be used by developers, an Eclipse plugin (instead of a full rich client) will do.
Building an Eclipse plugin has disadvantages. Most notably: Long development cycles. Anyone who wants to develop the tools has to dive into plugin development.
My intention is to allow writing tools that are integrated into Eclipse, while at the same time staying out of Eclipse plugin development as much as possible.
As one possible apporach, I'm thinking along the lines of some "generic" tooling plugin to which a Java application -- which gets run as a normal application being developed in the same Eclipse instance -- connects and "remote controls" the UI. This would require a one-time effort to build the generic plugin (including maintenance, of course), but development of the actual tools would happen outside of plugin development.
Now my question: What are the existing options towards such a generic plugin, as well as the more general problem of integrating with Eclipse without actually writing a plugin? The idea being that I wouldn't hesitate to build exactly that, but of course I don't want to reinvent the wheel.
For past 4 years, I have been programming with Eclipse (for Java), and Visual Studio Express (for C#). The IDEs mentioned always seemed to provide every facility a programmer might ask for (related to programming, of course).
Lately I have been hearing about something called "build tools". I heard they're used almost in all kind of real world development. What are they exactly? What problems are they designed to solve? How come I never needed them in past four years? Are they kind of command-line stripped down IDEs?
What are build tools?
Build tools are programs that automate the creation of executable
applications from source code (e.g., .apk for an Android app). Building
incorporates compiling,linking and packaging the code into a usable or
executable form.
Basically build automation is the act of scripting or automating a
wide variety of tasks that software developers do in their day-to-day
activities like:
Downloading dependencies.
Compiling source code into binary code.
Packaging that binary code.
Running tests.
Deployment to production systems.
Why do we use build tools or build automation?
In small projects, developers will often manually invoke the build
process. This is not practical for larger projects, where it is very
hard to keep track of what needs to be built, in what sequence and
what dependencies there are in the building process. Using an
automation tool allows the build process to be more consistent.
Various build tools available(Naming only few):
For java - Ant,Maven,Gradle.
For .NET framework - NAnt
c# - MsBuild.
For further reading you can refer following links:
1.Build automation
2.List of build automation software
Thanks.
Build tools are tools to manage and organize your builds, and are very important in environments where there are many projects, especially if they are inter-connected. They serve to make sure that where various people are working on various projects, they don't break anything. And to make sure that when you make your changes, they don't break anything either.
The reason you have not heard of them before is that you have not been working in a commercial environment before. There is a whole lot of stuff that you have probably not encountered that you will within a commercial environments, especially if you work in software houses.
As others have said, you have been using them, however, you have not had to consider them, because you have probably been working in a different way to the usual commercial way of working.
Build tools are usually run on the command line, either inside an IDE or completely separate from it.
The idea is to separate the work of compiling and packaging your code from creation, debugging, etc.
A build tool can be run on the command or inside an IDE, both triggered by you. They can also be used by continuous integration tools after checking your code out of a repository and onto a clean build machine.
make was an early command tool used in *nix environments for building C/C++.
As a Java developer, the most popular build tools are Ant and Maven. Both can be run in IDEs like IntelliJ or Eclipse or NetBeans. They can also be used by continuous integration tools like Cruise Control or Hudson.
Build tools are generally to transform source code into binaries - it organize source code, set compile flags, manage dependencies... some of them also integrate with running unit test, doing static analysis, a generating documentation.
Eclipse or Visual Studio are also build systems (but more of an IDE), and for visual studio it is the underlying msbuild to parse visual studio project files under the hood.
The origin of all build systems seems like the famous 'make'.
There are build systems for different languages:
C++: make, cmake, premake
Java: ant+ivy, maven, gradle
C#: msbuild
Usually, build systems either using a propriety domain specific language (make, cmake), or xml (ant, maven, msbuild) to specify a build. The current trend is using a real scripting language to write build script, like lua for premake, and groovy for gradle, the advantage of using a scripting is it is much more flexible, and also allows you the to come up with a set of standard APIs(as build DSL).
These are different types of processes by which you can get your builds done.
1. Continuous Integration build: In this mainly developers check-in their code and right after their check-in a build initiates for building of the recent changes so we should know whether the changes done by the developer has worked or not right after the check-in is done. This is preferred for smaller projects or components of the projects. In case where multiple teams are associated with the project or there are a large no. of developers working on the same project this scenario becomes difficult to handle as if there are 'n' no. of check-in’s and the build fails at certain points it becomes highly difficult to trace whether all the breakage has occurred because of one issue or with multiple issues so if the older issues are not addressed properly than it becomes very difficult to trace down the later defects that occurred after that change. The main benefit of these builds is that we get to know whether a particular check-in is successful or not.
2. Gated check-in builds: In this type of check in a build is initiated right after the check in is done keeping the changes in a shelve sets. In this case if the build succeeds than the shelve-set check-in gets committed otherwise it will not be committed to the Team Foundation Server. This gives a slightly better picture from the continuous integration build as only the successful check-in's are allowed to get committed.
3. Nightly builds: This is also referred as Scheduled builds. In this case we schedule the builds to run for a specific time in order to build the changes. All the previous uncommitted changes from the last build are built during this build process. This is practiced when we want to check in multiple times but do not want a build every time we check in our code so we can have a fixed time or period in which we can initiate the build for building of the checked-in code.
The more details about these builds can be found at the below location.
Gated-check in Builds
Continuous Integration Builds
Nightly Builds
Build Process is a Process of compiling your source code for any errors using some build tools and creating builds(which are executable versions of the project). We(mainly developers) do some modifications in the source code and check-in that code for the build process to happen. After the build process it gives two results :
1. Either build PASSES and you get an executable version of your project(Build is ready).
2. It fails and you get certain errors and build is not created.
There are different types of build process like :
1. Nightly Build
2. gated Build
3. Continuous integration build etc.
Build tools help and automates the process of creating builds.
*So in Short Build is a Version of Software in pre-release format used by the Developer or Development team to gain confidence for the final result of their Product by continuously monitoring their Product and solving any issues early during the development process.*
You have been using them - IDE is a build tool. For the command line you can use things like make.
People use command line tools for things like a nightly build - so in the morning with a hangover the programmer has realised that the code that he has been fiddling with with the latest builds of the libraries does not work!
"...it is very hard to keep track of what needs to be built" - Build tools does not help with that all. You need to know what you want to build. (Quoted from Ritesh Gun's answer)
"I heard they're used almost in all kind of real-world development" - For some reason, software developers like to work in large companies. They seem to have more unclear work directives for every individual working there.
"How come I never needed them in past four years". Probably because you are a skilled programmer.
Pseudo, meta. I think build tools do not provide any really real benefit at all. It is just there to add a sense of security arising from bad company practices, lack of direction - bad software architectural leadership leading to bad actual knowledge of the project. You should never have to use build tools(for testing) in your project. To do random testing with a lack of knowledge of the software project does not give any sort of help at all.
You should never ever add something to a project without knowing it's purpose, and how it will work with the other components. Components can be functional separate, but not work together. (This is the responsibility of the software architect I assume).
What if 4-5 components are added into the project. You add a 6th component. Together with the first added component, it might screw up everything. No automatic would help to detect that.
There is no shortcut other than to think think think.
Then there is the auto download from repositories. Why would you ever want to do that? You need to know what you download, what you add to the project. How do you detect changes in versions of the repositories? You need to know. You can't "auto" anything.
What if we were to test bicycles and baby transports blindfolded with a stick and just randomly hit around with it. That seems to be the idea of build tool testing.
I'm sorry there are no shortcut
https://en.wikipedia.org/wiki/Scientific_method
and
https://en.wikipedia.org/wiki/Analysis
Do you know any product like Microsoft Team Foundation Server 2010 that solves the parallel
development pain/conflict for Java EE development?
subversion + jira + wiki ...
I have no experience with Microsoft Team Foundation Server, but a combination of source control, continous integration (like Hudson) and a good issue tracker / collaboration tool (like Trac) gives a good overview of current activities / quality over time / current issues / progress while allowing for collaboration through wikis and the issue tracker. Mailing lists and an IRC channel can be a good additions for more permanent and live discussions respectively.
In my opinion Trac is really nice since it is easy to use, has a 'team timeline' and shows great information - code diffs along with issue numbers and developer comments bundled together - giving a great 'togetherness' feeling in the team.
The continous integration solution can provide many different code and quality metrics over time without manual intervention. Great for management.
If you don't mind to pay for good products you can look at Teamcity & Youtrack by Jetbrains. They provide useful tools for team programming.
If you work on an open source project, you can give a try to Hudson & Jira.
And Subversion or git will be a good way to manage your sources.
(Teamcity is free for an open source projects too)
Saros - Distributed Collaborative Editing and Distributed Party Programming
Pretty cool, just requires eclipse and a xmpp server.
I'm currently working in a team of 15 or so Java devs. I don't feel any pain of development. This is an environment using Maven, Subversion & Atlassian tools mainly. Maven makes it comparatively easy to build even large projects. Subversion does a decent job of updating & merging where necessary. Atlassian tools handle bug tracking, code review and automated builds but cost $$$. You could get by with Bugzilla and Hudson.
If by parallel you mean everyone gets their own branch then I suppose you could go with Clearcase but get ready to kiss your budget, sanity and productivity goodbye. Git might be a better choice for that kind of thing.
What is BPMS? and when to go for BPMS? is there any free tools for .net or java? is there any plug-in available for eclipse?
It is short for Business Process Management System or Software and basically is a tool for very high level modelling how the business will do whatever they do and how automation tools are integrated.
These things are typically huge and composed of a big collection of tools and infrastructure stuff. Eclipse based tooling may be a part of that, but it is much larger than just a plugin.
If you want to dip your toe in these waters you might look at JBoss Tools which has support for JBPM and Webservices which is a workflow package and the infrastructure which is usually core to these systems.
Good Luck!
As Peter said, BPMS is a huge topic. To get an idea of its scope, check out IBM's home page on it here: http://www-142.ibm.com/software/products/us/en/category/bpm-software
Have a look at the Activiti BPMN 2.0 engine. It is still in beta but a project everybody interested in BPM software should know about. It is implemented in Java and an Eclipse plugin also will be part of the set of tools.
Stardust, the Eclipse Process Manager,is a comprehensive and mature BPMS which is part of the Eclipse release train since the Kepler release. With over 2.5M lines of code and 726 person years Stardust is the largest Open Source BPMS.
As opposed to many Java-centric BPMS, Stardust also provides proven .NET integration capabilities on servcie and UI level.
The process modeler is avalibe for Eclipse or purely browser-based. The runtime environment can be used from inside Eclipse (WTP integration) or standalone (maven build).
Please see http://www.eclipse.org/stardust/ for more details.
Best regards
Rob
BPM - Business Process Management is a systematic approach to streamline an organization’s process to make it efficient and effective, to suit the changing environment around.
We're in an early stage of a new web project. The project will grow and become complex over time. From the beginning we will have unit and integration tests using JUnit and system tests using HtmlUnit. We might also add some static code analysis tools to the build process if they prove to be of value to us.
If you're or have been involved in a project which uses continuous integration. Which software do/did you use and do you think it has payed off? Which software would you recommend for continuous integration of a Java web project?
Hudson (the best). Hudson Website
JetBrains TeamCity Pro. http://www.jetbrains.com/teamcity/index.html
The Professional Edition does not require any license key. TeamCity starts running automatically with the Professional Edition Server if no license key is entered in the program. A single Professional Edition Server installation grants the rights to setup:
3 Build Agents at no additional cost
20 User Accounts
20 Build Configurations
Having used both CruiseControl and Hudson , I can recommend Hudson as the easier of the two to config (easily done via the web GUI, though direct configfile editing is also supported).
Hudson is great and free:
http://hudson.dev.java.net/
Bamboo is great but costs $$
http://www.atlassian.com/software/bamboo/
I've been very pleased with Atlassian's Bamboo. Even though it is commercial, the Starter Pack license is just $10 for 10 users. It's very well documented, easy to set up and flexible.
CruiseControl works reasonably well once you get it configured.
http://cruisecontrol.sourceforge.net/
I've used CruiseControl for Java projects, and CruiseControl.NET for .NET projects, and both work great.
I setup CruiseControl for a project that's been running for 4 years with several dozen developers, and while the configuration has been tweaked several times in the interim, it works great. (I don't actively support that project anymore, but I still work with the people who do.)
In my current position, CruiseControl.NET is being used to support several .Net projects, and has been used for 2+ years.
CruiseControl
CruiseControl is both a continuous integration tool and an extensible framework for creating a custom continuous build process. It includes dozens of plugins for a variety of source controls, build technologies, and notifications schemes including email and instant messaging. A web interface provides details of the current and previous builds. And the standard CruiseControl distribution is augmented through a rich selection of 3rd Party Tools.