You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <sk...@apache.org> on 2007/01/07 05:59:03 UTC
[all] jarfiles in svn
Hi,
I noticed (due to a recent commit message) that commons-transaction has
jarfiles checked in to svn, eg
http://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/trunk/lib/
What's the general policy on this? Sorry if this has been discussed
before; I don't remember it.
Personally, I really really dislike jarfiles in the version control
system. For a start, if every project were to do this, the impact on the
Apache SVN repository would be huge.
I would instead prefer to see ant builds using "get" to download jars as
needed. The maven repositories can be used as a convenient source for
the jars, eg
http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/build.xml
BTW, note that there is *no* way to remove a file from SVN once it is
committed short of a repo dump/restore (which is a major effort on a
repo the size of Apache). A "svnadmin obliterate" command is about the
oldest outstanding feature request...
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by Matt Benson <gu...@yahoo.com>.
--- Martin Cooper <ma...@apache.org> wrote:
[SNIP]
> This is a red herring. One way or another, you're
> going to have to get the
> jars from the network, whether it's getting them
> from SVN, or having Maven
> or Ant retrieve them. And in all of those three
> cases, once you have them on
> your local machine, you don't need the network to
> build the next time.
>
Fairly recently in Ant we switched our build to
dynamically obtain (if necessary) the maven2 ant tasks
to get our optional dependencies for full builds.
Steve Loughran put it together initially; I later
refined (IMHO) it. ;) I actually extracted it all
into a single Ant buildfile (fetch.xml) with the
intent of using it in commons-openpgp (again, I never
got around to actually doing it), but if/when my
committer status goes through I could adapt jxpath to
use this means of optionally obtaining dependencies
and see how it goes over.
-Matt
> --
> Martin Cooper
>
>
> But with Ant
> > it's at least better than with Maven as the build
> environment itself does
> > not
> > get changed.
> >
> > My concerns are raised after one year mess with
> Maven in Cocoon trunk.
> >
> > Regards
> > Jörg
> >
> > [1]
>
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/lib/
> > [2]
>
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/lib/
> > [3]
> >
>
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=116811395603150&w=4
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> >
> >
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by Joerg Heinicke <jo...@gmx.de>.
David Blevins <da...@...> writes:
> > So I don't forget, some commons projects need JDK 1.3 compiled
> > versions of some of our J2EE 1.4 specs, so at some when I get a
> > spare cycle I plan to build and put those up for a vote.
Hi David,
thanks for your efforts. I couldn't join the votes as I was on vacation for 5
weeks at that time. Now I noticed from the tags in the svn repository that the
jars are actually released. Are they already or will they be available from any
public repository?
Regards
Jörg
Re: [all] jarfiles in svn
Posted by David Blevins <da...@visi.com>.
Going to crank these out now, expect to see some votes for them.
-David
On Jan 11, 2007, at 9:53 PM, David Blevins wrote:
> So I don't forget, some commons projects need JDK 1.3 compiled
> versions of some of our J2EE 1.4 specs, so at some when I get a
> spare cycle I plan to build and put those up for a vote.
>
> -David
>
>
> Begin forwarded message:
>
>> From: David Blevins <da...@visi.com>
>> Date: January 10, 2007 11:27:41 AM PST
>> To: "Jakarta Commons Developers List" <commons-
>> dev@jakarta.apache.org>
>> Subject: Re: [all] jarfiles in svn
>> Reply-To: "Jakarta Commons Developers List" <commons-
>> dev@jakarta.apache.org>
>>
>>
>> On Jan 10, 2007, at 2:39 AM, Joerg Heinicke wrote:
>>
>>> David Blevins <david.blevins <at> visi.com> writes:
>>>
>>>> Only passively reading the thread, but from some of the comments
>>>> and
>>>> your commit message it looks like you just need JDK 1.3 compiled
>>>> versions of those specs.
>>>
>>> Yes, that's it.
>>
>> Cool.
>>
>>>
>>>> I'd be happy to apply your pom changes in the geronimo tree and
>>>> put newly built
>>>> versions up for a vote.
>>>
>>> That would be fine. But please review my pom changes. I'm not a
>>> Maven expert,
>>> but only googled for compiling for target JDK and found different
>>> approaches.
>>> Though this approach works for me there might be cases where it
>>> does not or
>>> simply better ones.
>>
>> It looks good, I'll give it a try.
>>
>> -David
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
Fwd: [all] jarfiles in svn
Posted by David Blevins <da...@visi.com>.
So I don't forget, some commons projects need JDK 1.3 compiled
versions of some of our J2EE 1.4 specs, so at some when I get a spare
cycle I plan to build and put those up for a vote.
-David
Begin forwarded message:
> From: David Blevins <da...@visi.com>
> Date: January 10, 2007 11:27:41 AM PST
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Subject: Re: [all] jarfiles in svn
> Reply-To: "Jakarta Commons Developers List" <commons-
> dev@jakarta.apache.org>
>
>
> On Jan 10, 2007, at 2:39 AM, Joerg Heinicke wrote:
>
>> David Blevins <david.blevins <at> visi.com> writes:
>>
>>> Only passively reading the thread, but from some of the comments and
>>> your commit message it looks like you just need JDK 1.3 compiled
>>> versions of those specs.
>>
>> Yes, that's it.
>
> Cool.
>
>>
>>> I'd be happy to apply your pom changes in the geronimo tree and
>>> put newly built
>>> versions up for a vote.
>>
>> That would be fine. But please review my pom changes. I'm not a
>> Maven expert,
>> but only googled for compiling for target JDK and found different
>> approaches.
>> Though this approach works for me there might be cases where it
>> does not or
>> simply better ones.
>
> It looks good, I'll give it a try.
>
> -David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [all] jarfiles in svn
Posted by David Blevins <da...@visi.com>.
On Jan 10, 2007, at 2:39 AM, Joerg Heinicke wrote:
> David Blevins <david.blevins <at> visi.com> writes:
>
>> Only passively reading the thread, but from some of the comments and
>> your commit message it looks like you just need JDK 1.3 compiled
>> versions of those specs.
>
> Yes, that's it.
Cool.
>
>> I'd be happy to apply your pom changes in the geronimo tree and
>> put newly built
>> versions up for a vote.
>
> That would be fine. But please review my pom changes. I'm not a
> Maven expert,
> but only googled for compiling for target JDK and found different
> approaches.
> Though this approach works for me there might be cases where it
> does not or
> simply better ones.
It looks good, I'll give it a try.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by Joerg Heinicke <jo...@gmx.de>.
David Blevins <david.blevins <at> visi.com> writes:
> Only passively reading the thread, but from some of the comments and
> your commit message it looks like you just need JDK 1.3 compiled
> versions of those specs.
Yes, that's it.
> I'd be happy to apply your pom changes in the geronimo tree and put newly built
> versions up for a vote.
That would be fine. But please review my pom changes. I'm not a Maven expert,
but only googled for compiling for target JDK and found different approaches.
Though this approach works for me there might be cases where it does not or
simply better ones.
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by David Blevins <da...@visi.com>.
On Jan 8, 2007, at 2:21 PM, Joerg Heinicke wrote:
> David Blevins <david.blevins <at> visi.com> writes:
>
>> If someone needs JDK 1.3 versions of any spec jar, I'd be happy to
>> help. OpenJPA had a similar request recently (JDK 1.3 version of JTA
>> 1.1) and I made sure to do the final release of that spec with JDK
>> 1.3.
>
> What exactly do you have in mind with your help offer? Is it
> publicly available
> then, maybe with a different naming?
>
> Please find my commit at http://svn.apache.org/viewvc?
> view=rev&revision=493595.
Only passively reading the thread, but from some of the comments and
your commit message it looks like you just need JDK 1.3 compiled
versions of those specs. I'd be happy to apply your pom changes in
the geronimo tree and put newly built versions up for a vote.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by Joerg Heinicke <jo...@gmx.de>.
David Blevins <david.blevins <at> visi.com> writes:
> If someone needs JDK 1.3 versions of any spec jar, I'd be happy to
> help. OpenJPA had a similar request recently (JDK 1.3 version of JTA
> 1.1) and I made sure to do the final release of that spec with JDK 1.3.
What exactly do you have in mind with your help offer? Is it publicly available
then, maybe with a different naming?
Please find my commit at http://svn.apache.org/viewvc?view=rev&revision=493595.
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by David Blevins <da...@visi.com>.
On Jan 7, 2007, at 6:28 PM, Phil Steitz wrote:
> I see
> the geronimo spec jars were added with the comment that they had been
> recompiled for JDK 1.3. If that is necessary, its probably better
> to first
> ask geronimo to produce *different* artifacts that satisfy this, or
> at least
> to rename these reccompiled artifacts.
/me ears perk up
If someone needs JDK 1.3 versions of any spec jar, I'd be happy to
help. OpenJPA had a similar request recently (JDK 1.3 version of JTA
1.1) and I made sure to do the final release of that spec with JDK 1.3.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by Phil Steitz <ph...@gmail.com>.
On 1/7/07, Joerg Heinicke <jo...@gmx.de> wrote:
>
> Martin Cooper <martinc <at> apache.org> writes:
>
> > > In general I don't like the need for internet access on build time.
> >
> > This is a red herring. One way or another, you're going to have to get
> the
> > jars from the network, whether it's getting them from SVN, or having
> Maven
> > or Ant retrieve them. And in all of those three cases, once you have
> them on
> > your local machine, you don't need the network to build the next time.
>
> There is one big difference: With everything in the src jar or at least in
> the
> svn checkout your requirements are less sophisticated than with the build
> system. For src jar I only need a browser, for svn checkout I need a svn
> client,
> but for Ant and Maven I need additionally Java and the build environment
> itself.
> And this is a big difference if the machine with internet access is not
> your
> local machine.
>
> (I speak from experience. In my company I get access to the internet only
> via a
> terminal server. There is no build environment. For proposed changes in
> the
> build I need to download all dependencies by hand.)
I would be more concerned about funny-versioned or unversioned jars coming
in to my environment or builds via svn checkouts. Most corporate
environments control pretty carefully the external jars used in builds -
both the OSS jars from maven repositories and release distributions. It
makes things easier if when building from source the dependencies are
explicitly versioned release jars, not whatever happens to be come down with
an svn checkout. The good thing about the great work the Ant, Maven and
repository@ people are doing is that it gets us to standardized jar
distribution.
I know that other apache projects have seen fit to put jars into scm and
they have had lots of reasons to do this - almost always to make builds for
users or release management easier. Up to now, we have pretty much avoided
this in commons and I for one would really like to keep things that way. I
had never noticed the /lib directory in [transaction] before, though, which
seems to have been there for a couple of years. Maybe Oliver or someone
else can explain why [transaction] really needs those jars in svn. I see
the geronimo spec jars were added with the comment that they had been
recompiled for JDK 1.3. If that is necessary, its probably better to first
ask geronimo to produce *different* artifacts that satisfy this, or at least
to rename these reccompiled artifacts.
Phil
Re: [all] jarfiles in svn
Posted by Joerg Heinicke <jo...@gmx.de>.
Martin Cooper <martinc <at> apache.org> writes:
> > In general I don't like the need for internet access on build time.
>
> This is a red herring. One way or another, you're going to have to get the
> jars from the network, whether it's getting them from SVN, or having Maven
> or Ant retrieve them. And in all of those three cases, once you have them on
> your local machine, you don't need the network to build the next time.
There is one big difference: With everything in the src jar or at least in the
svn checkout your requirements are less sophisticated than with the build
system. For src jar I only need a browser, for svn checkout I need a svn client,
but for Ant and Maven I need additionally Java and the build environment itself.
And this is a big difference if the machine with internet access is not your
local machine.
(I speak from experience. In my company I get access to the internet only via a
terminal server. There is no build environment. For proposed changes in the
build I need to download all dependencies by hand.)
Regards
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by Joerg Heinicke <jo...@gmx.de>.
Craig McClanahan <craigmcc <at> apache.org> writes:
> Someone had asked earlier about how Commons projects accomplished this goal
> before Maven. The answer was a convention for using Ant build.xml scripts
> that referenced a series of "build.properties" files containing definitions
> for things like what commons-digester.jar should I use. The highest level
> such file consulted was your ${user.home}/build.properties, so it was
> reasonably easy to enforce global usage of common dependencies, as long as
> all the build scripts used the same variable names.
Ah, yes. That's how it works in my company actually.
> In your build script, don't hard code the build to use your particular
> version of the dependency only. If I have my own version, I'm going to want
> to use it universally.
The build of commons transaction still has some remnants of the above method
(build.properties.sample in root dir and <property
file="${basedir}/build.properties"/> in build.xml). I have not tried it and it
might need some adaptions. But I'd like to know if this is still an acceptable
way at all for Jakarta Commons before I invest any effort to fix it.
So what's the outcome of this discussion?
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by Craig McClanahan <cr...@apache.org>.
On 1/8/07, Joerg Heinicke <jo...@gmx.de> wrote:
>
> Craig McClanahan <craigmcc <at> apache.org> writes:
>
> > Storing JAR files in your source repository (or pretty much any other
> > scenario where you check in things that have been generated, instead of
> > rebuilding them) has the following negative impacts:
> >
> > * Bypasses the normal mechanisms people use to verify
> > that the bits they are depending on have not been corrupted
> > (either accidentally or maliciously). A cautious downstream
> > user will go directly to the origin for every package they
> > depend on, and validate checksums and signatures. You
> > are asking your downstream users to trust *you* to not
> > have messed with these jar files.
>
> Good point.
>
> Side notes (not invalidating the point): Maven has switched off enforcing
> checksum match by default. Often projects would also not be buildable due
> to
> checksum mismatches in the dependencies. And: I have to trust Maven that
> it
> really checks every download.
Not necessarily ... people who are sufficiently concerned about this are
also setting up their own internal repositories, containing only the bits
they have vetted themselves, and with their own security settings.
> * Typically leads to a build environment where *only* the
> > copy of the dependent jars in your repository are used.
> > That makes life much harder for downstream users who
> > might have several packages that need the same dependency,
> > and need to be sure that their entire application
> >
> > * Creates redundant copies of shared dependencies in the
> > build environment of your downstream users (if they use
> > lots of packages that follow the same practice). It's one thing
> > to make a mess of redundant copies on our own server.
> > It's quite another thing to make a mess in your user's directory,
> > for every user.
>
> I guess that was the major driver for Maven et al.
Someone had asked earlier about how Commons projects accomplished this goal
before Maven. The answer was a convention for using Ant build.xml scripts
that referenced a series of "build.properties" files containing definitions
for things like what commons-digester.jar should I use. The highest level
such file consulted was your ${user.home}/build.properties, so it was
reasonably easy to enforce global usage of common dependencies, as long as
all the build scripts used the same variable names.
Not perfect by any means, but it was minimally acceptable.
> but please let your user opt out of *only* being allowed to use the
> version
> > you shipped.
>
> What do you have in mind? What's actually enforced? Does it relate to your
> impact 2 which is somewhat shortened?
In your build script, don't hard code the build to use your particular
version of the dependency only. If I have my own version, I'm going to want
to use it universally.
Jörg
Craig
Re: [all] jarfiles in svn
Posted by Joerg Heinicke <jo...@gmx.de>.
Craig McClanahan <craigmcc <at> apache.org> writes:
> Storing JAR files in your source repository (or pretty much any other
> scenario where you check in things that have been generated, instead of
> rebuilding them) has the following negative impacts:
>
> * Bypasses the normal mechanisms people use to verify
> that the bits they are depending on have not been corrupted
> (either accidentally or maliciously). A cautious downstream
> user will go directly to the origin for every package they
> depend on, and validate checksums and signatures. You
> are asking your downstream users to trust *you* to not
> have messed with these jar files.
Good point.
Side notes (not invalidating the point): Maven has switched off enforcing
checksum match by default. Often projects would also not be buildable due to
checksum mismatches in the dependencies. And: I have to trust Maven that it
really checks every download.
> * Typically leads to a build environment where *only* the
> copy of the dependent jars in your repository are used.
> That makes life much harder for downstream users who
> might have several packages that need the same dependency,
> and need to be sure that their entire application
>
> * Creates redundant copies of shared dependencies in the
> build environment of your downstream users (if they use
> lots of packages that follow the same practice). It's one thing
> to make a mess of redundant copies on our own server.
> It's quite another thing to make a mess in your user's directory,
> for every user.
I guess that was the major driver for Maven et al.
> but please let your user opt out of *only* being allowed to use the version
> you shipped.
What do you have in mind? What's actually enforced? Does it relate to your
impact 2 which is somewhat shortened?
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by Craig McClanahan <cr...@apache.org>.
On 1/8/07, Joerg Heinicke <jo...@gmx.de> wrote:
>
> Simon Kitching <skitching <at> apache.org> writes:
>
> > When using maven, only the first run needs to download the jars ... So,
> no need
> > for "internet access at build time".
> >
> > For ant ... This can be run *once* to download the jars, but is not part
> of the
> > main build task, so there is no need for "internet access at build
> time".
>
> Even if only for the first run you need a build environment for
> downloading the
> dependencies. That's the point.
>
> > > (I speak from experience. In my company ...)
> >
> > A poor corporate internet access policy at one company is *NOT* a good
> > justification for misusing the Apache SVN repository.
>
> 1. How can be a misuse what was (inevitably?) custom for years? I don't
> know how
> Jakarta Commons handled this before Maven. Of course SVN might not be
> perfect
> for it. But as long as infrastructure team does not even discourage from
> committing jars I don't see a real problem with it. And for commons
> transaction
> we talk about other magnitudes than for Cocoon (665 KB vs. 40-45 MB).
>
> 2. I don't give justifications for enacting a law or something like that.
> I only
> gave an argument which might be considered as well. Other examples might
> be
> imaginable. If it is common understanding to do it the other way, be it
> for
> unification or other reasons mentioned, I'm ok with it.
The problem here is not disk space or overhead on the SCM server (although
you won't hurt my feelings if you take actions that make the Apache
Subversion server run faster :-). The problem is one of engineering best
practices.
Storing JAR files in your source repository (or pretty much any other
scenario where you check in things that have been generated, instead of
rebuilding them) has the following negative impacts:
* Bypasses the normal mechanisms people use to verify
that the bits they are depending on have not been corrupted
(either accidentally or maliciously). A cautious downstream
user will go directly to the origin for every package they
depend on, and validate checksums and signatures. You
are asking your downstream users to trust *you* to not
have messed with these jar files.
* Typically leads to a build environment where *only* the
copy of the dependent jars in your repository are used.
That makes life much harder for downstream users who
might have several packages that need the same dependency,
and need to be sure that their entire application
* Creates redundant copies of shared dependencies in the
build environment of your downstream users (if they use
lots of packages that follow the same practice). It's one thing
to make a mess of redundant copies on our own server.
It's quite another thing to make a mess in your user's directory,
for every user.
This is not the same as saying "do not distribute such jars in a binary
distribution." That is a convenience that many projects offer ... but
please let your user opt out of *only* being allowed to use the version you
shipped.
Thanks for your understanding.
>
> Jörg
Craig
Re: [all] jarfiles in svn
Posted by Joerg Heinicke <jo...@gmx.de>.
Simon Kitching <skitching <at> apache.org> writes:
> When using maven, only the first run needs to download the jars ... So, no need
> for "internet access at build time".
>
> For ant ... This can be run *once* to download the jars, but is not part of the
> main build task, so there is no need for "internet access at build time".
Even if only for the first run you need a build environment for downloading the
dependencies. That's the point.
> > (I speak from experience. In my company ...)
>
> A poor corporate internet access policy at one company is *NOT* a good
> justification for misusing the Apache SVN repository.
1. How can be a misuse what was (inevitably?) custom for years? I don't know how
Jakarta Commons handled this before Maven. Of course SVN might not be perfect
for it. But as long as infrastructure team does not even discourage from
committing jars I don't see a real problem with it. And for commons transaction
we talk about other magnitudes than for Cocoon (665 KB vs. 40-45 MB).
2. I don't give justifications for enacting a law or something like that. I only
gave an argument which might be considered as well. Other examples might be
imaginable. If it is common understanding to do it the other way, be it for
unification or other reasons mentioned, I'm ok with it.
Thanks for your understanding.
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2007-01-07 at 17:08 +0000, Joerg Heinicke wrote:
> Martin Cooper <martinc <at> apache.org> writes:
>
> > > In general I don't like the need for internet access on build time.
> >
> > This is a red herring. One way or another, you're going to have to get the
> > jars from the network, whether it's getting them from SVN, or having Maven
> > or Ant retrieve them. And in all of those three cases, once you have them on
> > your local machine, you don't need the network to build the next time.
>
> There is one big difference: With everything in the src jar or at least in the
> svn checkout your requirements are less sophisticated than with the build
> system. For src jar I only need a browser, for svn checkout I need a svn client,
> but for Ant and Maven I need additionally Java and the build environment itself.
> And this is a big difference if the machine with internet access is not your
> local machine.
I've got no objection to commons-transaction providing a custom
download, eg "commons-transactions-6.7-src-all.tgz" which contains jars
if you feel this would make users happy. However no other commons
project has done this AFAIK, and I don't see any complaints on the user
lists.
When using maven, only the first run needs to download the jars;
thereafter they are cached locally. So, no need for "internet access at
build time".
For ant, have a look at the build.xml file in logging that I provided a
link to; it defines a separate "getlibs" task to download the jars. This
can be run *once* to download the jars, but is not part of the main
build task, so there is no need for "internet access at build time".
Re your maven issues: it's not mandatory to use maven to create builds;
ant is fine. Providing both is even better. It's only the jars issue
that is being discussed.
> (I speak from experience. In my company I get access to the internet only via a
> terminal server. There is no build environment. For proposed changes in the
> build I need to download all dependencies by hand.)
A poor corporate internet access policy at one company is *NOT* a good
justification for misusing the Apache SVN repository.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by Martin Cooper <ma...@apache.org>.
On 1/7/07, Joerg Heinicke <jo...@gmx.de> wrote:
>
> Simon Kitching <skitching <at> apache.org> writes:
>
> > For a start, if every project were to do this, the impact on the
> > Apache SVN repository would be huge.
>
> Cocoon (maintenance branch 2.1) has currently 111 jars with about 40 MB in
> its
> repository (+ the one for the environment [2]), we are regularly upgrading
> them
> and it has never been seen as a problem from infrastructure team.
>
> > I would instead prefer to see ant builds using "get" to download jars as
> > needed. The maven repositories can be used as a convenient source for
> > the jars, eg
> >
> http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/build.xml
>
> I posted my opinion on this recently [3]:
> In general I don't like the need for internet access on build time.
This is a red herring. One way or another, you're going to have to get the
jars from the network, whether it's getting them from SVN, or having Maven
or Ant retrieve them. And in all of those three cases, once you have them on
your local machine, you don't need the network to build the next time.
--
Martin Cooper
But with Ant
> it's at least better than with Maven as the build environment itself does
> not
> get changed.
>
> My concerns are raised after one year mess with Maven in Cocoon trunk.
>
> Regards
> Jörg
>
> [1] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/lib/
> [2] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/lib/
> [3]
> http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=116811395603150&w=4
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] jarfiles in svn
Posted by Joerg Heinicke <jo...@gmx.de>.
Simon Kitching <skitching <at> apache.org> writes:
> For a start, if every project were to do this, the impact on the
> Apache SVN repository would be huge.
Cocoon (maintenance branch 2.1) has currently 111 jars with about 40 MB in its
repository (+ the one for the environment [2]), we are regularly upgrading them
and it has never been seen as a problem from infrastructure team.
> I would instead prefer to see ant builds using "get" to download jars as
> needed. The maven repositories can be used as a convenient source for
> the jars, eg
> http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/build.xml
I posted my opinion on this recently [3]:
In general I don't like the need for internet access on build time. But with Ant
it's at least better than with Maven as the build environment itself does not
get changed.
My concerns are raised after one year mess with Maven in Cocoon trunk.
Regards
Jörg
[1] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/lib/
[2] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/lib/
[3] http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=116811395603150&w=4
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by Henri Yandell <fl...@gmail.com>.
This is an interesting 'request to developers':
http://www.jpackage.org/jpprequest.php
with some reasons for why putting in the external binaries is a pain
for redistributing.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] jarfiles in svn
Posted by Martin Cooper <ma...@apache.org>.
On 1/6/07, Simon Kitching <sk...@apache.org> wrote:
>
> Hi,
>
> I noticed (due to a recent commit message) that commons-transaction has
> jarfiles checked in to svn, eg
>
> http://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/trunk/lib/
>
> What's the general policy on this? Sorry if this has been discussed
> before; I don't remember it.
It has been discussed before, but it's been a while since it's come up. The
general consensus has been "don't do it". There are lots of reasons to avoid
doing this, and no good reasons to do so, especially since we're using Maven
now.
Personally, I really really dislike jarfiles in the version control
> system. For a start, if every project were to do this, the impact on the
> Apache SVN repository would be huge.
Yep. I'm with you on both points.
I would instead prefer to see ant builds using "get" to download jars as
> needed. The maven repositories can be used as a convenient source for
> the jars, eg
>
> http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/build.xml
Right, and an Ant build generated by Maven will in fact get the dependencies
from the Maven repo, just as Maven does.
--
Martin Cooper
BTW, note that there is *no* way to remove a file from SVN once it is
> committed short of a repo dump/restore (which is a major effort on a
> repo the size of Apache). A "svnadmin obliterate" command is about the
> oldest outstanding feature request...
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>