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
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 wrote:
> 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
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.
--benso
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 se
s/way/idea/
On Mon, Jan 10, 2011 at 1:54 AM, dsh wrote:
> Hi,
>
> I'd suggest to consider dependency management systems such as Apache
> Maven or Apache Ivy as an advantage in the long run. They allow to
> precisely document your dependencies and both support an offline mode.
> Additionally both
Hi,
I'd suggest to consider dependency management systems such as Apache
Maven or Apache Ivy as an advantage in the long run. They allow to
precisely document your dependencies and both support an offline mode.
Additionally both of course provide a very reliable way to define
exactly what version
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 wrote:
> This seems a bit over the top. I
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
>
> http://svn.apache.org/repos/asf/incubator/lcf
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 diffic
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 wrote:
> Please point me at a URL where it says this is Apache policy. I know
> of seve
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 wrote:
> I've just noticed that there are lots of j
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 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
w
On 9 January 2011 08:14, Karl Wright 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 dist dire
On Sat, Jan 8, 2011 at 4:40 PM, Karl Wright 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 have now it all
> 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(
16 matches
Mail list logo