I should fill in that the background for this change is that there are a
bunch of directories named "doc-files" in the classes source dir. They
have been there a long time. These contain html and gif files (mainly)
that shouldn't get copied into the output classes directory.
In a recent cleanup of the copy mechanism, I changed the copy rules to
by default include html and gif files and explicitly exclude those that
shouldn't be included, rather than explicitly listing what should be
copied. Because of this, we now have the following exclude rules:
# These directories should not be copied at all
EXCLUDES += \
com/sun/org/apache/xml/internal/security/resource/schema \
java/awt/doc-files \
java/lang/doc-files \
javax/swing/doc-files \
javax/swing/text/doc-files \
javax/swing/plaf/synth/doc-files \
javax/swing/undo/doc-files \
sun/awt/X11/doc-files \
sun/util/cldr/resources \
#
When building with sjavac, these get translated to "-e
java.awt.doc-files.*" which sjavac does not accept, because doc-files
are not proper package names. Another possible fix would be to filter
out non valid package names from the excludes sent to sjavac.
/Erik
On 2014-03-19 14:32, Andreas Lundblad wrote:
On Wed, Mar 19, 2014 at 01:58:21PM +0100, Fredrik Öhrström wrote:
The code by itself looks good. However I think that changing from . to / is
a really bad idea.
If someone committed a package directory that does not map correctly to the
package name, then that is a major problem. You will not find that source
through -sourcepath, which means that you just broke sjavac ability to
compile using multiple threads. This is just as bad as when Nashorn tried
to insert $ into java source file names! The horror, the horror.
I.e. do not replace . with /. Fix the problem in the jdk.
In this case, the directory did not contain any source files, just a bunch of
resources for documentation, such as .gif-files. (How could it contain source
files? A package may not contain a '-'.) So unless I misunderstood you, there
should therefore be no problem in this case.
I would prefer to see -i and -x as filters on what directories (not packages)
exists in the subsequent source root: This is more in line with other options
(-if, -xf, -src, ...) which all talk about paths and more general since each
package corresponds to a directory, but only some directories correspond to
packages.
- Andreas
