I still think the binary archive is unnecessarily bloated, and will
cause wasted load and resources for mirrors and consumers.
If it were straightforward, I would already have done it.
Here's a rundown of the space usage in the dist directory of the -bin object:
doc:
995 File(s)
On Sat, Jan 8, 2011 at 4:40 PM, Karl Wright daddy...@gmail.com wrote:
I've attached a new proposed version of README.txt, NOTICE.TXT, and
LICENSE.txt. Any further comments?
Karl
These look good to me.
Its a long thread so a bit hard to keep track of without a new RC but
i think what you
On 9 January 2011 08:14, Karl Wright daddy...@gmail.com wrote:
I still think the binary archive is unnecessarily bloated, and will
cause wasted load and resources for mirrors and consumers.
If it were straightforward, I would already have done it.
Here's a rundown of the space usage in the
Not sure what you mean by open copy.
Open meaning not bound up in a war.
There are also 2 copies of each of the war files, total 37M for one set.
Yes, that's known to me; so you are also suggesting that not just the
dependent jars be treated this way, but all the built artifacts as
well.
I've just noticed that there are lots of jars stored in SVN under
http://svn.apache.org/repos/asf/incubator/lcf/branches/release-0.1-branch
AIUI, SVN should not be used for storing library jars.
==
The way other projects manage this is to define the jar dependencies
in a build file, and get
Please point me at a URL where it says this is Apache policy. I know
of several Apache projects which work the same way ManifoldCF does.
svn is perfectly capable of storing binary images of all kinds.
Karl
On Sun, Jan 9, 2011 at 5:53 PM, sebb seb...@gmail.com wrote:
I've just noticed that
I'm sure that it isn't a policy. It's a good practice avoiding
Subversion bloat. There are certainly Apache projects who still have a
trunk-load of checked-in jars.
On Sun, Jan 9, 2011 at 6:58 PM, Karl Wright daddy...@gmail.com wrote:
Please point me at a URL where it says this is Apache policy.
We would like to eventually get them out of there, but both Grant and
I agreed early on that it wasn't the highest priority. If it is
Apache policy, then obviously we'd have to change our minds.
When we attack this, we intend to use ant plus ivy, not Maven. We
tried Maven and found it was
This seems a bit over the top. I prefer them in SVN so I can get them all at
once, which is especially nice when one is working offline.
On Jan 9, 2011, at 5:53 PM, sebb wrote:
I've just noticed that there are lots of jars stored in SVN under
The Wave project also has jars in its repository (on its way to Apache SVN).
That seems to be the most reliable way to define exactly what version of
what jars are required and ensure everyone has the same ones.
On 10 January 2011 11:16, Grant Ingersoll gsing...@apache.org wrote:
This seems a
There are additional benefits to dependency management systems like Maven or
Ivy as well. Beyond avoiding checking in jar files, you can reference a
dependency once and not have to proliferate references if you have multi module
builds (with multiple build files). Also, if your project gets
Gang,
Please be clear about when you are offering advice to podlings and
when you are conveying policy. The people in the podlings get
justifiably rattled when they get email that seems to suggest that
they are somehow not following some rule that isn't, apparently,
written down anywhere.
I just offered an advice based on my own experience nothing more :)
Cheers
Daniel
On Mon, Jan 10, 2011 at 3:48 AM, Benson Margulies bimargul...@gmail.com wrote:
Gang,
Please be clear about when you are offering advice to podlings and
when you are conveying policy. The people in the podlings
Karl Wright wrote:
(4) Grant suggested that we simply not include the PDF portion of the
doc build. This has the disadvantage of causing each site page to
have a broken link, but otherwise the PDFs are not of great value,
excepting perhaps the end-user documentation PDF. Savings: about
14 matches
Mail list logo
