Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <4486E81B.7010806@pobox.com>
Date: Wed, 07 Jun 2006 10:52:11 -0400
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: Supporting working on a single module?
References: <200606071432.k57EWuju002296@d06av02.portsmouth.uk.ibm.com>
In-Reply-To: <200606071432.k57EWuju002296@d06av02.portsmouth.uk.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Mark Hindess wrote:
> On 7 June 2006 at 9:42, Geir Magnusson Jr <geir@pobox.com> wrote:
>> Oliver Deakin wrote:
>>> Just thought Id give a bit of a heads up on HARMONY-561.
>>> The patch attached to that JIRA moves the header files under the
>>> native-src/<platform>/include directories into
>>> /modules/<luni|archive>/src/main/native. It also updates the build
>>> scripts and
>>> makefiles to move the headers into a shared location (<hdk>/include, as
>>> described at [1])  and compile against their new location.
>> Right, and I really don't like it, have been saying I don't like
>> overwriting the HDK, gave a reason for why I don't like it, and never
>> heard a reason why it must be this way.
> 
> It's no different to how we've been deploying java code for the last
> several months. 

Sure it is, if you think of the HDK as a binary snapshot you can build
against.

> That is, if you build at the top level, you are
> effectively creating the java parts of the jre (which is part of the
> large hdk).  If you then go and build in say modules/luni, you are
> building against the jars in the "hdk/jdk/jre/lib/boot" directory and
> the new luni.jar will be overwrite the existing one.

That's misleading, because there is no 'hdk' now.

There's nothing wrong with having a /deploy or /target directory that we
build into in parallel w/ the hdk, and no one's told me why that's a bad
idea, since *that* is how we've been working for several months now.

Remember, the motivation for this change is to modularize the natives,
not the hdk.  lets not let the tail wag the dog here.


> 
> So if Oliver is breaking anything by these changes, then it is nothing
> that wasn't broken before for the java code building process.  So I
> don't see the harm in proceeding because without this or something like
> it, it is impossible to move forward with (long overdue) the native-src
> restructuring.

I don't think I said he was breaking anything.  I said that I felt that
any alternatives that I suggested that got us to the same place, yet in
what I felt lead to clarity and diversity in use case were ignored.

Isn't anyone else bothered by the build process dropping artifacts into
and overriding what is an SDK?

> 
> No one has felt a pressing need to solve the problem with respect to the
> java code parts of the hdk (jre) being overwritten so I don't see why we
> now need to solve that problem first.

You are mixing two things up here.  No one cares if we overwrite stuff
in the build destination - that's a necessity - and that's not the
issue.  The issue is confusing the hdk, something that we'll distribute
as snapshots or versioned releases, w/ the build target.


> 
>> If you want me to put my money where my mouth is and just patch it,
>> I'm more than able to do that, but I'd rather reach consensus together
>> on how to go forward.
> 
> I'd prefer the consensus approach too.
> 
> Having said that I am interested in how you would patch it.  I've not
> clearly understood how it should be solved/patched.  Ignoring the native
> code for a moment, how do you propose to solve the problem with respect
> to the hdk/jdk/jre/lib/boot jars?  Where should the jars go when we
> build at the top level?


/target/jdk/jre/lib/boot for example

<aside>

...and to be honest, I think that it should be in a peer to /classlib,
not inside of clsaslib.

... and which the word 'target' up for debate, although I prefer it to
'deploy', because I think of deploy as a tree created when you push the
button to do a release or snapshot.... i.e.

  /deploy/harmony-0.5-snapshot/....

</aside>


>  Currently they go in the hdk - just as they
> always have - except we didn't call it that.

I think that's a really deceptive argument, as the hdk is more than just
a simple directory rename.  It's a distributed versioned resource.

>  Where do you think we
> should put the jars created when we build in a module?  

Where they went before

>Should the
> launcher be modified to support looking for the jars in all locations
> (with the hdk/jdk/jre/lib/boot location as last resort)?

Well,  I believe we still have to sort out where we think that the hdk
lives, given classlib is just one part of Harmony.  (I know we've been
very focused on the classlib until now, but our goal is JavaSE, not a
classlib)  But putting that aside, yes, that's sortof what I was
imagining although I didn't quite grok the best way... I don't know if
it's possible, creating classpaths and library paths that are a
combination of the /target stuff in front of the /hdk stuff, so that you
can 'override'...

So let me try to summarize my objections - my main objection is that
while  I agree the hdk is a powerful and useful idea,  we're mixing up
the hdk and the build destination, for reasons that haven't been explained.

geir

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org