In message <[email protected]>,
sebb writes:
>
> On 06/03/2010, Mark Hindess <[email protected]> wrote:
> >
> > In message <[email protected]>,
> > sebb writes:
> > >
> > > On 06/03/2010, Mark Hindess <[email protected]> wrote:
> > > >
> > > > Thanks Sebb.
> > > >
> > > > In message
> > > > <[email protected]>,
> > > >
> > > > sebb writes:
> > > > >
> > > > > The NOTICE file is out of date:
> > > > >
> > > > > Apache Harmony
> > > > > Copyright 2006, 2009 The Apache Software Foundation.
> > > >
> > > >
> > > > Fixed in trunk source trees. Merges should fix the other
> > > > instances.
Merges done so these should be fixed.
> > > > > There's a META-INF directory with N&L files in tools-src.jar
> > > > > but not in tools.jar
> > > >
> > > > Which tools.jar in which artifact is missing
> > > > N&L files? Looking at the jar tasks in
> > > > working_jdktools/modules/{jre,jdk}tools/build.xml both the
> > > > tools.jar and tools-src.jar tasks look to have the manifest
> > > > elements I'd expect and looking at a sample of the artifacts the
> > > > jdk/lib/tools.jar and jre/ lib/tools.jar files seem to have the
> > > > N&L files.
> > >
> > > Sorry, my mistake, they do have META-INF directories and N&L
> > > files.
> > >
> > > However the following Manifest entry is wrong:
> > >
> > > Implementation-URL: http://incubator.apache.org/harmony
> > >
> > > jdtstup*.jar have the same obsolete entries in their Manifests:
> >
> > Fixed in r919839.
> >
> > > Ideally all the META-INF entries should be added together at the
> > > beginning of the archive - at present the Manifest is first, and N&L
> > > are last. Definitely not a blocker.
> >
> > Aside from aesthetics, why?
>
> So they appear first when listing the jar to draw attention to them.
>
> See also:
>
> http://www.apache.org/dev/apply-license.html#new
Fair enough. Fixed.
> > > > > The MANIFEST.MF files should ideally contain details for the
> > > > > following headers:
> > > > >
> > > > > Specification-Title
> > > > > Specification-Version
> > > > > Specification-Vendor
> > > > > Implementation-Title
> > > > > Implementation-Version
> > > > > Implementation-Vendor
> > > > > Implementation-Vendor-Id
> > > > >
> > > > > Not relevant for source jars:
> > > > > X-Compile-Source-JDK
> > > > > X-Compile-Target-JDK
> > > >
> > > >
> > > > These will take a bit more effort; A JIRA should probably be targeted to
> > > > the next release to cover this task.
> > >
> > > Only the Specification-Vendor and X-Compile headers are missing, so
> > > probably quite easy to add these.
> >
> > You'd think it would be quite easy, with only 120 <jar> tasks to
> > correct.
>
> Oh - I'd assumed there was just one common routine to do this.
I've fixed most of these except Specification-Vendor. I'll do this
before the 5.0M14/6.0M2 releases.
> > However, I'm not exactly sure what X-Compile headers would be
> > appropriate for modules like pack200.jar which have some code compiled
> > with 1.4/1.4 and some compiled with 1.5/1.5. I'd welcome your opinion.
>
> Never come across that before.
>
> In a jar, I think the header is most useful for recording the target
> JVM version. So if the jar can only be run using Java 1.5, use that.
> If it can be run on both, then perhaps use both.
>
> The header values are only used for documentation, so you could use:
>
> 1.5 (parts 1.4)
>
> for source and target.
Done. Thanks.
> > > https://issues.apache.org/jira/browse/HARMONY-6462
I'll leave this open until I've fixed the Specification-Vendor entries.
> > > > > There are a lot of source files that don't have AL headers, for
> > > > > example:
> > > > >
> > > > > working_classlib/depends/libs/build/fetch-awt-depends.sh
> > > >
> > > > This one is trivial and can be removed now. I wont do it right away
> > > > because I think the README in the same directory also needs work too.
> >
> > I've removed the script but left the README to be addressed later.
> >
> > > > > working_classlib/doc/harmony.css
> > > > > working_classlib/doc/hydoxygen.css
> > > >
> > > > I'm not sure whether these are generated. Certainly according to
> > > > google, the hydoxygen.css comment "end styling for detailed member
> > > > documentation" appears in non-ALv2 files, though some ALv2 files too.
> >
> > I'm still not sure about these.
>
> Who created it? If it was created at the ASF, then it should have the
> AL header. If not, then it probably needs to be mentioned in the N &
> L files (perhaps it is already) and it would do no harm to add short
> comment in the file itself, not least to avoid questions later.
Sorry, I meant I wasn't sure about them because I'd not looked at the
history rather than because I wasn't sure what to do. I have now and
they are fixed.
> > > > > working_classlib/modules/sql/src/test/java/org/apache/harmony/sql/tests/java/sql/SQLClientInfoExceptionTest.java
> > > > > working_classlib/modules/sql/src/test/java/org/apache/harmony/sql/tests/javax/sql/StatementEventTest.java
> > > > > working_classlib/modules/sql/src/test/java/org/apache/harmony/sql/tests/javax/sql/rowset/MockNClob.java
> > > > > working_classlib/modules/sql/src/test/java/org/apache/harmony/sql/tests/javax/sql/rowset/MockRowId.java
> > > > > working_classlib/modules/sql/src/test/java/org/apache/harmony/sql/tests/javax/sql/rowset/MockSQLXML.java
> >
> > Fixed in r919849.
> >
> > > > > working_vm/vm/tests/ncai/funcs/**
> >
> > Fixed in r919853 subject to merging from trunk.
> >
> > > > Will have to have a closer look at these but I suspect most are
> > > > just missing headers.
> > >
> > > https://issues.apache.org/jira/browse/HARMONY-6463 - JIRA with the
> > > full list attached.
> > Aside: Quite a few of the files RAT complains about are empty except
> > for whitespace. Perhaps RAT should skip these?
>
> Yes, it should. RAT has some false positives.
>
> > I'll get to the rest when I get more time.
I've done most of these now.
Can you take a look at the latest artifacts at:
http://people.apache.org/~hindessm/sebb/
Do these look better?
> > > > > Perhaps some of these are not ASF source, but it looks like
> > > > > many of them are.
> > > >
> > > > I'm assuming most of these shouldn't stop the already-voted-for
> > > > releases.
> > >
> > > IMO having so many missing AL headers is a blocker.
> >
> > Thanks for the clarification. I assumed you thought that or you
> > wouldn't have raised these issues on a [vote] thread. ;-)
> >
> > I was really soliciting the opinions of the others who voted and
> > Harmony PMC members.
> >
> > > > The NOTICE year is rather annoying though. What do other people
> > > > think?
> >
> > ?
I'd still *really* like the opinions of the others who voted and Harmony
PMC members. Do you think this should block the already-voted-for
release?
I think stopping an already-voted-for release sets a bad precedent
Testing should happen before/during the vote and if more time is
required then people should ask (as Tim did). However, also I want to
make a good release.
I will *not* be making this decision one way or another until I get some
indication of the opinions of others who voted.
Regards,
Mark.
