Cheap Local Branching

Git is the new standard

The post Why Git is Better than X | Git or X appeared first on scmGalaxy.

The post Comparison Between UCC, CLOC, POWERSOFTWARE,EZ-Metrics and Metrixware appeared first on scmGalaxy.

The post SLOC Tools Comparison | SLOC Tools Differences | SLOC Tools Comparison Table appeared first on scmGalaxy.

My main experience is with ClearCase. I have read various descriptive comparisons between ClearCase and other available Software Management Version tools. Which tool has your company implemented? What were the key features helped you select this tool over another one?

Configuration Management Tools Discussion

The post Configuration Management Tools Discussion appeared first on scmGalaxy.

What is Maven 2?
Maven 2.0 is a complete rewrite of the ‘original’ Maven application (‘Maven 1’). As such, it is very different from Maven 1, and not backwards-compatible (eg, it cannot execute Maven 1 plugins). However, Maven 2.0 is the latest stable release of the Maven application, and new users are generally encouraged to use it for all new projects.
If you are familiar with Maven 1, you can find some information about moving to Maven 2 here or on the main Maven site.

Maven 1
To access the repository from your project, add the following line to your project.properties or build.properties.
maven.repo.remote=http://download.java.net/maven/1/,http://www.ibiblio.org/maven/

Maven 2
For Maven2, one needs to add the following into a project’s pom.xml, or into conf/settings.xml // (NOT in mirrors/mirror) where Maven2 is installed:

java.net
http://download.java.net/maven/1
legacy

Maven 2 Lifecycles

Lifecycles are groupings of goals that define a process for building a project. Goals are bound to lifecycles to define a sequence that must be accomplished to produce results. Lifecycles ensure that users building projects with Maven only need to learn a small set of commands. Whereas Maven defines a default set of goals for each typical lifecycle, developers can bind additional goals to lifecycles to transparently add functionality to a build.
Typical lifecycles include:

• compile—compile the source code
• test—unit test the compiled source.

Note: Unit tests should not require the classes to be packaged or deployed.

• package—bundle the compile and tested source code into a distributable package, such as a jar or war.
• integration-test—employ the package as necessary and run integration tests.
• install—install the package into the local repository. This allows the package to be utilized as a dependency of other projects.
• deploy—copies the final package into the remote repositories for sharing and use with other projects.

As you can see, each lifecycle depends upon and builds upon the next. As a result, when a goal is bound to the compile lifecycle, all lifecycles will ensure its execution.
Lifecycles can be executed in conjunction with standalone goals. For instance, commonly the clean:clean goal is executed before the install goal. This is done by invoking:

m2 clean:clean install

Native Multiproject Support

One of the best practices that Maven strongly encourages is the idea that a single project should result in a single artifact, or package, being created. This best practice results in simplified builds and organized project structures. By natively supporting a hierarchical structure of projects, Maven now makes developing enterprise projects which implement this approach easier.
Maven 1 included a plugin for working with related of projects—or multiprojects. Maven 2 takes multiproject builds a step further by including a specialized parent descriptor and native multiproject execution support. As a result, any goals or lifecycles invoked upon a multiproject POM will result in each subproject goal being achieved.

Other Enhancements

Several other changes are included in Maven 2. Maven has been rewritten to be smaller and faster. The architectural changes make embedding Maven into other tools easier and allows for faster command line execution. Maven 2 depends upon fewer dependencies, resulting in a smaller distribution.
The way extensions are made to Maven has been changed in Maven 2. Instead, developers are encouraged to utilize JavaBeans for enhancements. Whereas scripting is allowed (through marmalade support—which includes a jelly facade), it is no longer the tool of choice. All extensions are made through the development of plugins (projects can no longer be customized through scripting in the maven.xml).
The introduction of a settings.xml file replaces the need for properties files. The settings file can be defined at a system, user, or project level. Settings are used to define private configuration information, including usernames and passwords. Project properties (including plugin configuration) are now all defined in the pom.xml.

Understanding Maven 2 Project Types

The first step to creating a maven project is determining which project template, or archetype, your Maven project should be configured as. Archetypes define which type of artifact will be produced by a project. Several archetype templates exist. The standard archetype will produce a standard library jar file. Templates also exist for webapps/wars, Maven plugin projects, documentation Web sites, and more.

Creating Project Descriptors

The archetype:create goal can be utilized to create a basic pom.xml for you project. This basic POM will allow you to execute all of the lifecycles and goals associated with any maven project. The archetype:create goal should be executed as follows:

m2 archetype:create -DgroupdId=com.daviddewolf.maven -DartifactId=example

This simple command creates the basic infrastructure needed for a project. It creates the pom.xml as well as the basic directory structure of for both source and test code. The following structure indicates the directories and files produced by issuing the archetype:goal command as listed above.

+ root

  - pom.xml

  + src

    + main

      + java

        + com

          + daviddewolf

            + maven

              + example

                - App.java

    + test

      + java

        + com

          + daviddewolf

            + maven

              + example

                - TestApp.java

This simple structure that is created is enough to get started with Maven. All of the lifecycles now can be utilized. A simple invocation of the install lifecycle will compile, test, and package the application and then deploy it to the local system repository for use by other projects.
Once created, the POM can be customized to meet the requirements of the specific project. Documentation on the Maven POM can be found on the Maven2 Web site.

Goals You Should Know About

The introduction of lifecycles in Maven 2 has greatly reduced the number of goals that a developer must be aware of. Still, the following goals will undoubtedly be found useful (and can be utilized as soon as the basic descriptor has been generated).

• clean:clean Clean all artifacts and intermediary files created by Maven
• idea:idea Generate project files for the IntelliJ IDEA IDE
• eclipse:eclipse Generate project files for the Eclipse IDE
• javadoc:javadoc Generate the javadocs for the project
• antrun:run Run a specified ant target
• clover:clover Generate a coverage report for the project
• checkstyle:checkstyle Generate a checkstyle report for the project
• site:site Generate a documentation Web site for the project. This site will include many information reports concerning the project.

For more information concerning these and other goals, see the Maven2 Web site.
Conclusions
Learning Maven is not difficult; it simply requires a willingness to accept a new philosophy for building applications. Maven utilizes a a centralized project descriptor to intelligently build applications with prebuilt build tools. This differs greatly from ant and other build tools in that project developers are no longer required to write build systems by using a comprehensive set of utilities. This change will save development teams significant time and has started a revolution in build tools.
It is important to remember that Maven2 is still currently only released as Beta Software. Although it is mature enough to utilize in most projects, all of the Maven 1 plugins have not yet been migrated to Maven 2. With time, Maven 2 will become more widely accepted and the number of available plugins will grow beyond what is even available in Maven 1.
Reference:
http://www.developer.com/open/print.php/10930_3552026_2
http://www.sonatype.com/books/maven-book/reference/installation-sect-upgrade-detail.html

The post Difference between Maven 1 and Maven 2 | Maven 1 Vs Maven 2 appeared first on scmGalaxy.

Advantages of CVSNT over CVS

The post Benefits of CVSNT, What are the advantages of CVSNT over CVS ? appeared first on scmGalaxy.

Major differences between CVS and CVSNT | CVS Vs CVSNT

CVSNT was started as a variation (or branch) of CVS in 1999 because patches contributed to CVS were not considered to be suitable for that project by those responsible for making such decisions at that time.
CVSNT has continued to add features to the original CVS that support modern version control and configuration management best practice as well as maintain feature parity with CVS.
Today CVSNT is the most widely deployed version of CVS and is distributed with TortoiseCVS and WinCVS.

Similarities between CVS and CVSNT

• From a SCM perpective, they share similarity in purpose, Commands including syntax and functionality
• Both are freeware
• Both can be accessed through clients.
• Both are supported with Unix-like, Windows, Mac OS X

Difference between CVS and CVSNT

• An alternative to CVS with advance features and support
• CVS is being maintained but new features are not being added henceforth CVSNT is being maintained and new features are under development.
• CVS is having only merge function instead of CVSNT is having merge and locking system as well.
• CVS is having limited features than CVSNT

The post Major differences between CVS and CVSNT | CVS Vs CVSNT appeared first on scmGalaxy.