You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jason van Zyl <jv...@zenplex.com> on 2002/03/19 14:35:54 UTC

Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)

On Mon, 2002-03-18 at 23:41, Craig R. McClanahan wrote: 

> 
> The projects that inherit their build philosophy from Turbine definitely
> like lib.repo, because they tend to put all the dependency JAR files in
> one place.
> 
> The projects that inherit their build philosophy from Struts and Tomcat
> definitely like base.path, because they assume that you have checked out
> and built each of the dependent JARs, in a common base subdirectory.

Just as a point to mention, this is how most of the Turbine developers
work. We generally check everything out we just have the additional step
of placing each produced JAR in a shared directory before building.

This process is now used in Maven, what Turbine is now using for all its
builds and for producing the Turbine sites, and it uses this method but
it could easily be made to accommodate other modes of developing.

We're trying to encourage the use of a central repository of JARs.
Having the one repository makes things like automatically downloading
JARs easier for those who are interested in only developing or fixing
the single package they are interested in.

I'm only pointing out that we work in a similiar fashion in that we like
to have everything checked out, that's generally how I work at any rate.

I think that having a central repository of JARs would make a
generalized continuous integration mechanism a little easier. Where a
project is working against a known set of binaries and you're building
every 5 minutes to find errors that have been introduced into a build.
With a central repository of JARs this would work for any project.

I'm also adjusting Maven to use a "dist" directory because I release all
of Turbine family yesterday trying to use Maven and it was a bit
cumbersome so I'm going to adopt the "dist" directory to try and make
this easier.

> (For
> me, for example, that is /home/craigmcc/Jakarta, with a subdirectory under
> it for each CVS repository I care about, and I maintain the results of
> "ant dist" builds in each case for the code that I currently develop
> against).
> 
> The defaults from Digester have inherited the latter philosophy (because
> of where the code came from), so base.path is a better name for
> build.properties.sample in this case.
> 
> NOTE:  This isn't a value judgement on which philosophy is better -- both
> are equally valid, but consistency within a particular philosophy is even
> more important than choosing one or the other.

Right, I think we have just evolved in different ways but I think a
central store of JARs may be easier for people to work with and this
doesn't prevent someone from creating these JARs on their own machines.
We use this method in Turbine coupled with an automatic JAR downloading
mechanism to help people who are not interested in building all the
dependencies.

-- 
jvz.

Jason van Zyl
jvanzyl@apache.org

http://tambora.zenplex.org


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)

Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:

> We're trying to encourage the use of a central repository of JARs.
> Having the one repository makes things like automatically downloading
> JARs easier for those who are interested in only developing or fixing
> the single package they are interested in.
>
> I'm only pointing out that we work in a similiar fashion in that we like
> to have everything checked out, that's generally how I work at any rate.

Indeed, I work in the same fashion.  I learn how to build every
Jakarta package I use -- in my own work, and at CollabNet -- from
source.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: property naming (Re: cvs commit: jakarta-commons/digesterbuild.properties.sample)

Posted by Juozas Baliuka <ba...@centras.lt>.
<snip>
> So other than space issues and duplication of JARs everywhere there is
> the issue of using the JAR that was produced by the project itself. So
> if Turbine puts some JARs in the central repository they are guaranteed
> to be the JARs produced by Turbine and not some tweaked JAR that was
> placed in CVS.
>
> It's definitely easier to check everything into CVS but I believe the
> central repository of JARs theory will win out :-)
>
Yes it is good idea.
 I think It is better to have "readme" in lib, or "autodownload" in build
script if some target
need this JAR.
<snip>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)

Posted by Daniel Rall <dl...@finemaltcoding.com>.
Henri Yandell <ba...@generationjava.com> writes:

> I agree fully. Jar repository will be the way to go. Now, my dumb-user
> question is:  Maven or JJAR. What's the url for Maven? (and as an outside
> Turbine person, is it a nice separate component?)

Maven is completely separate from Turbine.  Pete Kazimer has done a
great job producing some very useful initial documentation, which is
all published to the web site (and created by Maven itself):

http://jakarta.apache.org/turbine/maven/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)

Posted by Jason van Zyl <jv...@zenplex.com>.
On Tue, 2002-03-19 at 11:37, Henri Yandell wrote:
> 
> I agree fully. Jar repository will be the way to go. Now, my dumb-user
> question is:  Maven or JJAR. What's the url for Maven? (and as an outside
> Turbine person, is it a nice separate component?)

Maven: http://jakarta.apache.org/turbine/maven/

What JJar does is a small part of what Maven does. JJar basically grabs
JARs based on dependency descriptor. Maven will grab JARs with one of
its tasks based on a project descriptor with the dependencies listed
within. The JAR retrieval supports the use of a proxy and uses
timestamps so that only what is required is brought down.

It has no dependencies on Turbine itself. It has a dependency on an
XML->Bean mapper that is in the jakarta-turbine-stratum repository
but I am tossing that in favour of betwixt in the commons sandbox.

I have built ~20 projects with Maven now and people have tried with
various projects and in the majority of cases it's been a success. Maven
is actually used to build the graph2 component in the sandbox and all
the Turbine projects have project descriptor. David Taylor is going to
try with Jetspeed, Geir is going to try with Velocity and I'm going make
a descriptor for BCEL and XMLRPC. Any project I have contact with I'm
going to try to use Maven.
 

> On 19 Mar 2002, Jason van Zyl wrote:
> 
> > Using something like JJAR or Maven (which has auto JAR downloading
> > feature) allows you to use a single set of JAR files for building all
> > your projects instead of having each project store JARs in CVS.
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
-- 
jvz.

Jason van Zyl
jvanzyl@apache.org

http://tambora.zenplex.org


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)

Posted by Henri Yandell <ba...@generationjava.com>.
I agree fully. Jar repository will be the way to go. Now, my dumb-user
question is:  Maven or JJAR. What's the url for Maven? (and as an outside
Turbine person, is it a nice separate component?)

On 19 Mar 2002, Jason van Zyl wrote:

> Using something like JJAR or Maven (which has auto JAR downloading
> feature) allows you to use a single set of JAR files for building all
> your projects instead of having each project store JARs in CVS.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)

Posted by Jason van Zyl <jv...@zenplex.com>.
On Tue, 2002-03-19 at 10:59, Henri Yandell wrote:
> 
> I've been playing with it to use for work too. Trying to figure out what
> advantages JJAR has over just using cvs and ant-cvs tasks.

Using something like JJAR or Maven (which has auto JAR downloading
feature) allows you to use a single set of JAR files for building all
your projects instead of having each project store JARs in CVS.

Maven will currently see if you have the required JARs for building and
brings them down from a central repository and stores them in your local
repository for use. It's not fool proof yet, in Turbine land we battled
with Maven yesterday to get all the distributions out the door but we
did it and it worked and all of used the same set of JARs.

So other than space issues and duplication of JARs everywhere there is
the issue of using the JAR that was produced by the project itself. So
if Turbine puts some JARs in the central repository they are guaranteed
to be the JARs produced by Turbine and not some tweaked JAR that was
placed in CVS.

It's definitely easier to check everything into CVS but I believe the
central repository of JARs theory will win out :-)
 
> On Tue, 19 Mar 2002, Tomasz Pik wrote:
> 
> > Jason van Zyl wrote:
> >
> > What about Commons-Sandbox JJar Component?
> > I use a little modified version of this tool and I think this is a very
> > good solution for 'continous integration' and managing of differen
> > versions of libraries at all.
> >
> > BTW what is the future of JJar?
> >
> > Tomek Pik
> > pikus@ais.pl
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
-- 
jvz.

Jason van Zyl
jvanzyl@apache.org

http://tambora.zenplex.org


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)

Posted by Henri Yandell <ba...@generationjava.com>.
I've been playing with it to use for work too. Trying to figure out what
advantages JJAR has over just using cvs and ant-cvs tasks.

On Tue, 19 Mar 2002, Tomasz Pik wrote:

> Jason van Zyl wrote:
>
> What about Commons-Sandbox JJar Component?
> I use a little modified version of this tool and I think this is a very
> good solution for 'continous integration' and managing of differen
> versions of libraries at all.
>
> BTW what is the future of JJar?
>
> Tomek Pik
> pikus@ais.pl
>
>
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: property naming (Re: cvs commit: jakarta-commons/digester build.properties.sample)

Posted by Tomasz Pik <pi...@ais.pl>.
Jason van Zyl wrote:


> We're trying to encourage the use of a central repository of JARs.
> Having the one repository makes things like automatically downloading
> JARs easier for those who are interested in only developing or fixing
> the single package they are interested in.
> 
> I'm only pointing out that we work in a similiar fashion in that we like
> to have everything checked out, that's generally how I work at any rate.
> 
> I think that having a central repository of JARs would make a
> generalized continuous integration mechanism a little easier. Where a
> project is working against a known set of binaries and you're building
> every 5 minutes to find errors that have been introduced into a build.
> With a central repository of JARs this would work for any project.


What about Commons-Sandbox JJar Component?
I use a little modified version of this tool and I think this is a very
good solution for 'continous integration' and managing of differen
versions of libraries at all.

BTW what is the future of JJar?

Tomek Pik
pikus@ais.pl




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>