During the last 5 months I have been slowly transitioning us from ANT+CVS to
SVN+Maven+Hudson+Proximity...
One large problem was the source repo. It is all in one big com/... tree.
All jars are built from this one tree. So it doesn't use the typical concept
of many source trees, one per Jar source tree. All of the build processes
basically cuts a specific list of files from CVS and creates a Jar from it.
There are Jars that cover the same code as other Jars. Basically a mess.
My approach...
Phase 1: First task was to make Maven operate in the same way Ant did. So I
built a plugin (it was very easy to do since Maven plugins are created so
easily). This allows me to make a pom with the following configuration:
<plugin>
<groupId>com.xxxxx</groupId>
<artifactId>xxx_mvn_integration</artifactId>
<version>1.2</version>
<executions>
<execution>
<id>Sources</id>
<phase>generate-sources</phase>
<goals><goal>cvscheckout</goal></goals>
<configuration>
<checkoutFolder>src/main/java/</checkoutFolder>
<pathsToCheckout>
<param>-l com/xxx com/xxx...</param>
<param>com/xxx ...</param>
</pathsToCheckout>
<isSources>true</isSources>
</configuration>
</execution>
The plugin detects if the checkout folder exists, and if it does, a CVS
update is performed, otherwise CVS checkout. It works different than the
Maven SCM plugin, which is why I went custom here. After the code is checked
out there is an option to make the directory a "sources" directory to maven.
The above is kind of redundant, but there are cases in which it will
checkout to a java2/ folder instead.
Phase 2: The next phase was to start covering more and more of the CVS tree
with poms. I think I have a little over half right now. (The whole thing
doesn't build in one jar because we require JDK 1.4 jars in some places, and
some of the code is for JDK 5.) I'm placing all of these in Hudson so our
Java code gets some integrity. In addition to this phase I am adding Junit
tests (we didn't have a single one before I started here).
Phase 2.5: Put the poms in Svn, and use Hudson to build them. The build
process does the CVS checkout.
Phase 3: Refactoring of code. I am using Hudson to make sure any changes I
make allow all of the other modules to still build. That and Netbeans
refactoring is keeping our code very stable. After any finished refactoring
I add JUnit tests.
Phase 3.5: Start copying code into Svn. and start recording history too.
Eventually there will be a cut-off point where CVS is no longer supported.
Phase 4: (not started yet) Assuming the refactoring leads to Java code being
placed in suitable packages that build with all of the other code in the
same package, and correct dependencies, we will be able to migrate to SVN.
Subversion and CVS have one major difference that is making us wait: you
can't check out a single file from SVN, when you can in CVS. I don't want to
try to modify Svn either for this because I want universal tooling, not
custom tooling everywhere.
Basically that's it. When we get to phase 4 there will be other benefits
like Hudson emailing the people that break builds and such. Right now that
can't happen because of the secondary SCM step inside the build process,
that Hudson doesn't know anything about. I don't want to write Hudson
plugins just for this feature either because our builds are not failing
uncontrollably anyway.
It has been pretty difficult convincing people to use Maven. As of yet
no-one else has touched it because I'm still working to finish putting all
our code on a proximity installation. My company is heavy on training so I
am allowed to spend some of my time creating training sessions on Maven,
Hudson, Java dependency issues, etc... Overall I am extremely happy with
Maven 2. I hope that the JSR 277 (corr?) aligns well with Maven 2, or falls
apart because of Maven 2. I'm still hoping someone will create a Maven class
loader that can do what JSR 277 is trying to do... (Basically distribute a
Java app as 1 Jar instead of 50, and leverage a repository for the rest.)
After understanding Maven2 I am able to solve all of my build problems very
quickly. It integrates with Netbeans very well. I haven't tried the Ant
tasks for Maven 2 yet. I will eventually get people that use Ant to use it,
but I hope they switch directly to Maven 2 instead.
Ravi
On 7/6/07, Jeff Jensen <[EMAIL PROTECTED]> wrote:
Perforce
Maven
Proximity
CruiseControl
Eclipse and RAD, many plugins
Works great.
Like them all a lot (Perforce is the main commercial dev tool; is great
value, great features, I don't know of a better package and have used a
lot
of SCMs).
While CC is pretty good, I would consider changing from CruiseControl to
Hudson, if Hudson supported Perforce.
-----Original Message-----
From: Trevor Spackman [mailto:[EMAIL PROTECTED]
Sent: Friday, July 06, 2007 10:50 AM
To: [email protected]
Subject: Which technology stack are you using?
So here's the question: what are YOU using? There have been a number of
posts about what CAN be used, but only a couple of people have mentioned
what they DO use.
Why do I ask?
We recently made the jump from CVS & ant to Subversion & maven. There
have been a few growing pains, but things seem to have stabilized. Now
I could use the advice of someone who has already been there. We're
using maven-proxy for our internal repository - but we haven't been
entirely pleased and want to look at alternatives. We also need to get
a good CI system set up (yes, we don't have one :-(). We went for the
obvious Continuum, but it's been nothing but headaches trying to make it
play nicely.
The questions:
Which SCM are you using: CVS, Subversion or something else?
I'll assume you're using maven as your build system...
Which internal repo proxy are you using: maven-proxy, Archiva,
Artifactory, Proximity, Gatekeeper?
Which CI system are you using: Hudson, Bamboo, Continuum, Cruise
Control?
Which IDE do you use: Eclipse, IDEA?
Which plugins for your IDE?
And, most importantly, do you LIKE them? Are they friendly/easy to use?
Do you wish you could change, but don't have the time/resources?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
