Am I doing this right?
|
|
Bryan Wooten
|
Some javascript/style in this post has been disabled (why?)
Hi all, I’d like some feedback on our Hudson configuration and
will appreciate any observations. Our development environment is Solaris / Glassfish /
Netbeans. All Netbeans projects are committed to a CVS repository
including library jar files, WAR files, EAR files and EJB jar files. When Hudson runs Ant against any project we have a
univerisal properties file that overrides the settings in the
private.properties file that the developer committed to CVS. (Using the –propertyfile
option in the Ant target). We do this for 2 reasons. First Hudson
doesn’t have rights to developer’s Netbean’s installation
directories where many of these properties point. And more importantly we
want all builds going to test and production to use jar files in what we call
the “Hudson reference Netbeans Installation”. On occasion builds will fail when a project introduces a new
Library or jar file to their project. Usually it is quick edit to the “universal
properties” file to resolve the build issue. We are currently having a debate on the best practice for
referencing jar files in Netbeans projects. Netbeans allows the developer
to either reference the jar directly (using a fixed or relative path) or the
developer can reference the jar file project it self. I have been encouraging everyone to reference the jar files
directly. I have configured Hudson to poll CVS and build library jar
files hourly. When the jar file project is included in a project Ant will
delete the dependent project jar file during the build process, this sometimes
causes a concurrent build to fail. Referencing the jar file directly
avoids this contention. Also the when the jar file project is included the Ant build
script is not set up to perform a CVS update (as is a Hudson build) and thus
the results may not be what the developer expects. Any thoughts on this? Thanks, Bryan |
||||||||||||||||
Andrew Hughes-5
|
I recommend you take a look at maven (especially in your case where you want dependency management).
On Wed, Nov 4, 2009 at 1:27 AM, Bryan Wooten <[hidden email]> wrote:
|
David Weintraub
|
You can also look into Ivy instead of Maven. Ivy does the same dependency management as Maven, but you don't have to change your entire build process around in order to make Maven happy. You can pretty much use your present build.xml files and just add the Ivy dependency part.
On Tue, Nov 3, 2009 at 9:50 PM, Andrew Hughes <[hidden email]> wrote: I recommend you take a look at maven (especially in your case where you want dependency management). -- David Weintraub [hidden email] |
||||||||||||||||
Horton, Anne B
|
Some javascript/style in this post has been disabled (why?)
Dave, Do you use Ivy? Do you prefer it over
Maven? Anne From: David Weintraub
[mailto:[hidden email]] You can also look into
Ivy instead of Maven. Ivy does the same dependency management as Maven, but you
don't have to change your entire build process around in order to make Maven
happy. You can pretty much use your present build.xml files and just add the
Ivy dependency part. On Tue, Nov 3, 2009 at 9:50 PM, Andrew Hughes <[hidden email]> wrote: I recommend you take a look at maven (especially in your case where you
want dependency management). On Wed, Nov 4, 2009 at 1:27 AM, Bryan Wooten <[hidden email]>
wrote: Hi all, I’d like some
feedback on our Our development
environment is Solaris / Glassfish / Netbeans. All Netbeans
projects are committed to a CVS repository including library jar files, WAR
files, EAR files and EJB jar files. When On occasion builds
will fail when a project introduces a new Library or jar file to their
project. Usually it is quick edit to the “universal properties” file to
resolve the build issue. We are currently
having a debate on the best practice for referencing jar files in Netbeans
projects. Netbeans allows the developer to either reference the jar
directly (using a fixed or relative path) or the developer can reference the
jar file project it self. I have been
encouraging everyone to reference the jar files directly. I have
configured When the jar file
project is included in a project Ant will delete the dependent project jar file
during the build process, this sometimes causes a concurrent build to
fail. Referencing the jar file directly avoids this contention. Also the when the
jar file project is included the Ant build script is not set up to perform a
CVS update (as is a Hudson build) and thus the results may not be what the
developer expects. Any thoughts on
this? Thanks,
|
||||||||||||||||
topher1120
|
My team is using Ivy. Some other teams in my group are using Maven, but I haven't learned Maven thoroughly enough to feel comfortable it trying it. I am finding that I understand Maven more because of my use of Ivy (which I really like). Either way, it really simplifies my inter-project dependencies and cleans up my Ant build file because of it.
Thanks, topher On Wed, Nov 4, 2009 at 8:49 AM, Horton, Anne B <[hidden email]> wrote:
|
||||||||||||||||
|
David Weintraub
|
In reply to this post
by Horton, Anne B
We do not use Ivy here because we are officially (kicking and
screaming) moving to Maven. The non-Maven projects right now store the JARs right inside the project, so we don't need to fetch them from the repository. I like the idea of Maven, but find its implementation to leave much to desire. In a very simple jar or war, Maven works quite well. However, once you start adding things like Axis, Maven turns into a very complicated beast. You spend a lot of time trying to configure your pom.xml to produce what you want. Plus, most of the documentation just stinks. Maven was suppose to allow developers to do their own build maintenance, but over here, I'm doing it all. I build most of the pom.xml files, and I am the one responsible for all the issues. My limit with Maven was hit with complex projects that are subdivided into other projects. We have one project with four wars enclosed in an ear that is packaged in an assembly. We had duplicate jar files in this package, and this caused problems with the application. I had to manually configure each war and the ear with all the various jar dependencies. I would have to figure out what jar downloaded another jar, and then manually exclude these from the war and then manually added them to the ear. If I had a choice, I'd chose Ivy over Maven, and then help the developers with their build.xml to make sure they keep them simple. That seems to do 90% of what Maven is suppose to do, and you have the flexible build system. Sure, unlike Maven, you have to tell Ant how to build something, but in the end, you're pretty much doing the same with Maven. On Wed, Nov 4, 2009 at 10:49 AM, Horton, Anne B <[hidden email]> wrote: > Dave, > > Do you use Ivy? Do you prefer it over Maven? > > Anne > > > > ________________________________ > > From: David Weintraub [mailto:[hidden email]] > Sent: Wednesday, November 04, 2009 10:47 AM > To: [hidden email] > Subject: Re: Am I doing this right? > > > > You can also look into Ivy instead of Maven. Ivy does the same dependency > management as Maven, but you don't have to change your entire build process > around in order to make Maven happy. You can pretty much use your present > build.xml files and just add the Ivy dependency part. > > On Tue, Nov 3, 2009 at 9:50 PM, Andrew Hughes <[hidden email]> wrote: > > I recommend you take a look at maven (especially in your case where you want > dependency management). > > > > > > On Wed, Nov 4, 2009 at 1:27 AM, Bryan Wooten <[hidden email]> wrote: > > Hi all, > > > > I’d like some feedback on our Hudson configuration and will appreciate any > observations. > > > > Our development environment is Solaris / Glassfish / Netbeans. > > > > All Netbeans projects are committed to a CVS repository including library > jar files, WAR files, EAR files and EJB jar files. > > > > When Hudson runs Ant against any project we have a univerisal properties > file that overrides the settings in the private.properties file that the > developer committed to CVS. (Using the –propertyfile option in the Ant > target). We do this for 2 reasons. First Hudson doesn’t have rights to > developer’s Netbean’s installation directories where many of these > properties point. And more importantly we want all builds going to test and > production to use jar files in what we call the “Hudson reference Netbeans > Installation”. > > > > On occasion builds will fail when a project introduces a new Library or jar > file to their project. Usually it is quick edit to the “universal > properties” file to resolve the build issue. > > > > We are currently having a debate on the best practice for referencing jar > files in Netbeans projects. Netbeans allows the developer to either > reference the jar directly (using a fixed or relative path) or the developer > can reference the jar file project it self. > > > > I have been encouraging everyone to reference the jar files directly. I > have configured Hudson to poll CVS and build library jar files hourly. > > > > When the jar file project is included in a project Ant will delete the > dependent project jar file during the build process, this sometimes causes a > concurrent build to fail. Referencing the jar file directly avoids this > contention. > > > > Also the when the jar file project is included the Ant build script is not > set up to perform a CVS update (as is a Hudson build) and thus the results > may not be what the developer expects. > > > > > > Any thoughts on this? > > > > Thanks, > > > > Bryan > > > > > -- > David Weintraub > [hidden email] -- David Weintraub [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
