I'm 100% in agreement with Vladimir ! :-) We have chosen not to include the jars in Cactus CVS. There are 2 types of persons involved with Cactus :
1/ Cactus developers, 2/ End users I don't think Cactus developers will have any trouble to find the jars needed to build Cactus (BTW, Gump publishes all the jars every day on http://gump.covalent.net/jars/). End users will generally not build Cactus from the sources. However, they will download the Cactus distribution (either the released one or nightly distribution). In any case, the Cactus distribution contains most of the needed jars in a lib/ directory. There is only 1 jar missing : servlet.jar. The reason is that this jar is provided by your container (either as servlet.jar or j2ee.jar, or packaged inside another jar - weblogic packages everything in weblogic.jar). The only thing we could improve is that in the Cactus sample delivered as part of the distribution, we could have a default.properties as we include the jars in lib/. However, the end user will still need to have a build.properties as servlet.jar is not provided. We could provide it as it is not very big. However, Cactus will soon provide a sample-j2ee (in addition to sample-servlet) and j2ee.jar is much bigger. And I don't think end users will like to download an additional few MBs just to avoid editing build.properties (as they already have j2ee.jar in the container). -Vincent > -----Original Message----- > From: Vladimir Bossicard [mailto:[EMAIL PROTECTED]] > Sent: 11 March 2002 02:37 > To: [EMAIL PROTECTED] > Subject: Re: cvs commit: jakarta- > cactus/anttasks/src/java/org/apache/cactus/ant RunServerTestsTask.java > StartServerHelper.java StopServerHelper.java > > > Properties should (IMHO) be set inside build.xml and > > build.properties is used to override them in exceptional circumstances, > but > > is typically not needed. > > This is I think a matter of taste. In a lot of Jakarta projects, external > jar files are saved into cvs. If by pulling the cvs tree, you can compile > your project without problems, I agree that in that case, the properties > should be placed into the main build.xml file (there's no need to an > external build.properties file because everything needed is available in > the project's directory). > > However, as soon as you don't place your jar files in a 'lib' directory of > your cvs repository, there's no point in defining their default location > when you don't have any idea where they could be. In that case, you > _have_ to define a build.properties file. > > In the end, everything can be resumed in: do we save the external jar > files in the cvs repository (and distribute them in our releases) or not. > I know that there is not strict policy for jakarta projects but I > personally think that external jars shouldn't be placed in the CVS tree. > That's why I find the solution of an external build.properties file > totally ok. If the developer is not able to figure out what to do with > the build.properties file... well I doubt he can really be helpful to the > project. > > My 2 cents > > -Vladimir > > -- > Vladimir Bossicard > www.bossicard.com > > -- > To unsubscribe, e-mail: <mailto:cactus-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:cactus-dev- > [EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
