Change the behavior of PropertySetter?

[Kristian Waagan <Kr...@Sun.COM>]

Hi,

The PropertySetter, whose responsibility it is to configure the compile 
classpath(s) if the user hasn't, now has two algorithms to detect JDK 
installations:
  (1) JAR inspection (newer)
  (2) directory name filter (old)

Currently (1) is run first, followed by (2).
Lately, I have stumbled across a few environments where (2) causes the 
Derby build to fail. The typical pattern is that (1) detects a valid 
Java SE 6 installation, and then (2) picks up an invalid installation of 
Java SE 5.0 or J2SE 1.4.

Would it make sense to run (2) only if (1) can't find the required JDK(s)?

In my opinion, 'ant all buildjars' should just work (to build everything 
you still have to add JUnit).
Regular Derby developers with special build requirements can configure 
the build process manually (they are probably doing this already).

What do people think?


As a side note, as people start building Derby with other JDKs, like 
Harmony, OpenJDK or the FSF-one, I do expect some issues.
Also, I think Derby simply doesn't build with all of these...


Regards,
-- 
Kristian

Re: Change the behavior of PropertySetter?

[Rick Hillegas <ri...@oracle.com>]

Kristian Waagan wrote:
> On 04.05.10 04:15, Bryan Pendleton wrote:
>>> Derby build to fail. The typical pattern is that (1) detects a valid
>>> Java SE 6 installation, and then (2) picks up an invalid 
>>> installation of
>>> Java SE 5.0 or J2SE 1.4.
>>
>> What is an "invalid installation" in this description?
>>
>> In general, your proposal sounds fine to me, I'm just trying to 
>> understand
>> what sort of invalid installations the build tool is uncovering and why.
>
> Hi Byran,
>
> The two problematic installations I have stumbled across lately, where 
> I tried to build Derby and it failed due to incorrect compilation 
> classpaths, were:
>  a) A JDK 1.4 was uninstalled, but because a custom jar had been 
> placed into the jre/lib/ext directory, the directory structure wasn't 
> removed. This caused an empty classpath.
>
>  b) A gcj-installation on a Linux distro was picked up as the 1.5 JDK, 
> but even though it contained a jre/lib (with rt.jar), it didn't have 
> any executables (java or javac). As far as I can see, the directory 
> was a valid part of an installed package (maybe even installed by 
> default on a fresh install).
>
> These were picked up because they met the following requirements:
>  1) The base directory contained the target JDK version (i.e. 1.5).
>  2) The base directory contained the directories jre/lib.
>
> My point is that the new algorithm has a few more requirements, and it 
> didn't pick up these installations for a reason. Therefore, if the new 
> algorithm does the job by fulfilling the minimal JDK requirement, I 
> suggest to skip the old algorithm.
> However, if the new algorithm fails to locate a JDK, we can run the 
> old one - it may manage to pick up one that can be used.
>
>
> More along the lines of what Rick wrote in his reply, both of these 
> algorithms will fail for some JDKs. This means that if we want almost 
> all of our casual developers / hackers to be able to successfully run 
> 'ant all buildjars', we will have to extend PropertySetter.
Hi Kristian,

I think that the following goal is more or less well defined and 
testable, although even it evolves more rapidly than I like. I think we 
can attain it:

a) A Derby build that works without tweaking on out-of-the-box 
installations of some set of ( operatingSystem, jdkVendor ) combinations.

In contrast, I would put limited effort into the following goal. I feel 
that this second goal is poorly defined, hard to test, and evolves too 
rapidly:

b) A Derby build that works without tweaking for all of our casual 
developers/hackers.

My $0.02,
-Rick
>
>
> Regards,

Re: Change the behavior of PropertySetter?

[Kristian Waagan <Kr...@Sun.COM>]

On 04.05.10 04:15, Bryan Pendleton wrote:
>> Derby build to fail. The typical pattern is that (1) detects a valid
>> Java SE 6 installation, and then (2) picks up an invalid installation of
>> Java SE 5.0 or J2SE 1.4.
>
> What is an "invalid installation" in this description?
>
> In general, your proposal sounds fine to me, I'm just trying to 
> understand
> what sort of invalid installations the build tool is uncovering and why.

Hi Byran,

The two problematic installations I have stumbled across lately, where I 
tried to build Derby and it failed due to incorrect compilation 
classpaths, were:
  a) A JDK 1.4 was uninstalled, but because a custom jar had been placed 
into the jre/lib/ext directory, the directory structure wasn't removed. 
This caused an empty classpath.

  b) A gcj-installation on a Linux distro was picked up as the 1.5 JDK, 
but even though it contained a jre/lib (with rt.jar), it didn't have any 
executables (java or javac). As far as I can see, the directory was a 
valid part of an installed package (maybe even installed by default on a 
fresh install).

These were picked up because they met the following requirements:
  1) The base directory contained the target JDK version (i.e. 1.5).
  2) The base directory contained the directories jre/lib.

My point is that the new algorithm has a few more requirements, and it 
didn't pick up these installations for a reason. Therefore, if the new 
algorithm does the job by fulfilling the minimal JDK requirement, I 
suggest to skip the old algorithm.
However, if the new algorithm fails to locate a JDK, we can run the old 
one - it may manage to pick up one that can be used.


More along the lines of what Rick wrote in his reply, both of these 
algorithms will fail for some JDKs. This means that if we want almost 
all of our casual developers / hackers to be able to successfully run 
'ant all buildjars', we will have to extend PropertySetter.


Regards,
-- 
Kristian

>
> thanks,
>
> bryan

Re: Change the behavior of PropertySetter?

[Bryan Pendleton <bp...@gmail.com>]

> Derby build to fail. The typical pattern is that (1) detects a valid
> Java SE 6 installation, and then (2) picks up an invalid installation of
> Java SE 5.0 or J2SE 1.4.

What is an "invalid installation" in this description?

In general, your proposal sounds fine to me, I'm just trying to understand
what sort of invalid installations the build tool is uncovering and why.

thanks,

bryan

Re: Change the behavior of PropertySetter?

[Rick Hillegas <ri...@oracle.com>]

Hi Kristian,

Some comments inline...

Kristian Waagan wrote:
> Hi,
>
> The PropertySetter, whose responsibility it is to configure the 
> compile classpath(s) if the user hasn't, now has two algorithms to 
> detect JDK installations:
>  (1) JAR inspection (newer)
>  (2) directory name filter (old)
>
> Currently (1) is run first, followed by (2).
> Lately, I have stumbled across a few environments where (2) causes the 
> Derby build to fail. The typical pattern is that (1) detects a valid 
> Java SE 6 installation, and then (2) picks up an invalid installation 
> of Java SE 5.0 or J2SE 1.4.
>
> Would it make sense to run (2) only if (1) can't find the required 
> JDK(s)?
PropertySetter is a custom ant task. When it was first written, 
PropertySetter tried to follow the ant model for setting properties: a 
request to set a property was honored only if the property was not 
already set. If the property was already set, then the attempt to 
override it was silently ignored. I assume that PropertySetter continues 
to behave this way but it's been a while since I was in there.

A) This behavior can be a little confusing to people who are not 
familiar with ant's way of thinking. However, it continues to make sense 
to me that an ant task should follow the ant conventions. I feel that 
breaking the ant conventions would be even more confusing. What would be 
even worse would be to follow the conventions sometimes, break them 
sometimes, and not have a simple rule for figuring out when the 
conventions apply.

B) PropertySetter is an attempt to gather up a set of heuristics, which 
have been discovered by trial and error. It is an attempt to code these 
heuristics in a language which

i) we all know and

ii) is more expressive and readable than ant's xml dialect.

I continue to think that it is easier to code the heuristics in Java 
than in xml. However, PropertySetter is still too complicated. That is 
largely because I had never solved a problem like this before I just 
hacked the first increment together. Sorry. Since then several people, 
yourself included, have made important contributions to this program. It 
is now both more capable and more complicated. PropertySetter may have 
reached the point where it needs a good re-write. A table-driven 
approach might be attractive. It would be nice to see at a glance what 
the outcome is for a given ( operatingSystem, jdkLevel ) coordinate.

I am happy with the changes you are suggesting, or even with a complete 
re-write, provided that (A) and (B) are still satisfied.
>
> In my opinion, 'ant all buildjars' should just work (to build 
> everything you still have to add JUnit).
> Regular Derby developers with special build requirements can configure 
> the build process manually (they are probably doing this already).
>
> What do people think?
Two caveats:

I) As with all changes to PropertySetter, it is best to get broad 
developer feedback on your patches before committing them. It's easy to 
break other people's build environments. I know. I've done it a lot.

II) I would appreciate it if you could hold off changing the Derby build 
until after 10.6.1 is released.
>
>
> As a side note, as people start building Derby with other JDKs, like 
> Harmony, OpenJDK or the FSF-one, I do expect some issues.
> Also, I think Derby simply doesn't build with all of these...
A table-driven structure might make it easier to plug in more variants 
like these.

Thanks,
-Rick
>
>
> Regards,