[GSoC] Android Impress Remote: Weekly Report #0

[Michael Meeks]

On Mon, 2013-06-10 at 10:00 +0200, Cedric Bosdonnat wrote:
> On Mon, 2013-06-10 at 02:54 +0300, Artur Dryomov wrote:
> > * Prepare migration to Maven as much as possible.
> 
> Do we really want that for building some Java bits in the LO source
> tree? That would add yet another build dependence... but I'm probably
> not the best one for these kinds of questions.

	Good question :-) so - Artur, we currently have a configure / download
script that downloads all the source we need to src/ - and that
(pristine) source is mirrored on our own servers, and thus is 100%
reliable. Furthermore, it is a known quantity - we download exactly
those packages, and no more, no new dependencies get introduced
unexpectedly without people (particularly packagers knowing) etc.

	So - if we use mavern - and surely it'd be nice not to have a random
checkin of pieces of Java code from elsewhere of uncertain version in
the code like this actionbarsherklock - then it needs to follow these
requirements:

	* anything downloaded must be downloaded from TDF servers
	& => the set of downloaded things must be known at compile time

	* there must be a non-automatic-downloading-path as used by
	  packagers, where they stuff known source archives into src/
	  and the build-system will pick them up and not download other
	  things. ie. ./configure --disable-fetch-external should
	  continue to work.

	* we shouldn't add a new dependency on mavern - I guess we'd
	  want to download, compile and use that only iff we're
	  configured to use external source ie. not
	  --disable-fetch-external

	All in all, if we're only doing this for actionbarsherlock - I suspect
it would be better to make a tar-ball of the Java (with a strong version
in it), and do this as we do other tar-ball downloads rather than
investing lots of time in a rather painful and limited mavern
integration - but of course, it's up to you :-) In general, we're not
encouraging lots of Java use in the source, so - a general mavern
solution may be of increasingly limited usefulness ...

	Are there other Java pieces we want to use from mavern ?

	ATB,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot