Post J1 catchup. Just minor comments, am trying to read the thread
through...
Mark Hindess wrote:
On 10 May 2006 at 8:07, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
AS a matter of fact, I think that the hdk is simple a tar of the junk
created by a "make the world" build...
I wouldn't have put it quite like that, but yes perhaps that is correct.
I'm saying that deploy/hdk tree should be created/used by a "make the
world" build in such a way that compiling a module would be the same as
if you have just untar'd an hdk snapshot. This is possible/easy if no
module directly references another except via the "junk" in the hdk
(specifically the jre/lib/boot jars for java code).
I'm going to see where this thread winds up, but I'm still convinced
that the HDK shouldn't ever be modified, that the contents should be
copied out to a "working HDK" and then things local to where you are
working (the module) copied in and overlaid.
The following is an example of having the full tree ('full_checkout') at
the same time as a hdk ('binary snapshot aka hdk') with three work areas
(just the prefs checked out from SVN, the RMI contribution from Intel
and the RMI contribution from ITC)
/your_see_drive :)
/full_checkout/
/deploy/
artifacts
/ whatever/
/binary snapshot aka hdk/
/deploy/
artifacts
/checkout_of_pref_only/
build.props (points to /binary snapshot aka hdk/)
/modules/
/pref/
/contribution_1_from_SVN/
build.props (points to /full checkout/)
/modules/
/RMI from Intel/
/contribution_2_from_SVN/
build.props (points to /full checkout/)
/modules/
/RMI_from_ITC/
That way, you can dork w/ the full_checkout, fix something, and then
your other work environments that are pointing at it get that fix w/o
any work.
I hope my crude art makes sense.
Yes. But I'm not sure why I'd need the full_checkout around if I had
the hdk snapshot though. And I'm not sure I'd mind having several hdk's
around; They'd be a more manageable than the code I currently copy
around.
The point is to have options. There should be no requirement to have
the full checkout, but it should be able to co-exist peacefully with
parallel HDKs of various vintages...
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
