Re: source directory layout for multirelease jars
That's true, if it is just for the module descriptor, having a MRJAR is
overkill.
https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html
describes how to solve that.
Robert
On 1-5-2020 13:52:15, Hervé BOUTEMY wrote:
when the need is restricted META-INF/versions/9/module-info.class, ie not
really code per Java release, but only module or not module, isn't one
strategy better to use, given there should be less tests to be run?
perhaps the answer is that MR is overkill for that, given JDK 8 will simply
ignore module-info.class?
Regards,
Hervé
Le jeudi 30 avril 2020, 19:40:15 CEST Robert Scholte a écrit :
> Hi Benjamin,
>
> You're confusing me
>
> "Sadly, you cannot just add executions to the maven compiler plugin."
> Why not? The design of the pom contains support of multiple executions
> within the same plugin
>
> "Almost no IDE supports it, ..."
> I think they all do. And even if they don't, they should. I consider an IDE
> as a wrapper around Maven, so it should support this basic feature
>
> "... and when I asked about multiple executions
> in the maven compiler plugin on this list I recevied only one reply
> that this is not an intended way of using this plugin (although I was
> using it for annotation processing with
> useIncrementalCompilation=false)."
>
> I don't recognize this question. And the answer looks incorrect to me.
>
> That said: if you just want a META-INF/versions/9/module-info.class, you can
> already do that (for a long time).
> https://github.com/apache/maven-compiler-plugin/tree/master/src/it/multirel
> ease-patterns However, there is no one ideal pattern, you have to pick one,
>
> Robert
>
>
>
>
> On 30-4-2020 08:49:02, Benjamin Marwell wrote:
> Hi,
>
> to make the story a bit shorter - for most libraries it would be
> sufficient to add a way to include a module descriptor at
> "META-INF/versions/9/module-info.class" while still staying at java 8.
> Most libraries will stick to java 8 or even 7 for quite a time.
>
> Sadly, you cannot just add executions to the maven compiler plugin.
> Almost no IDE supports it, and when I asked about multiple executions
> in the maven compiler plugin on this list I recevied only one reply
> that this is not an intended way of using this plugin (although I was
> using it for annotation processing with
> useIncrementalCompilation=false).
>
> I know there is the moditect plugin for such cases, but it doesn't
> play along nicely with the bundle-plugin and hasn't seen much progress
> lately as far as I can tell.
>
> That said, adding such a module descriptor would be a nice first goal
> without using executions.
>
> Of course this will all become obsolete as soon as everyone uses java 9+.
>
> Am Sa., 25. Apr. 2020 um 21:20 Uhr schrieb Robert Scholte
>
> > I'm afraid this will be long story, but this might be the moment to share
> > the details.
> >
> > https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> > describes already several topics:
> >
> > - why MultiRelease Jars
> > - how to build them? There are several patterns, each with its pro's and
> > con's.
> >
> > But it doesn't explain the technical problems, so I guess we need to
> > explain it a bit better. I will also take the time to describes things
> > that you might already know.
> >
> > So you want to build a jar? You take the minimum pom (modelVersion +
> > groupId + artifactId + version) and you can set the packaging to jar (or
> > omit it, as it is the default value). You will call "package", which
> > matches a phase of the default lifecycle. Maven must first figure out the
> > matching lifecycle, by looping over all the available.[1] It will pick up
> > all mapped Lifecycle components and will search in its phases. The result
> > will be the "default" Lifecycle. Based on this Maven will look for "jar"
> > named LifecycleMapper and the configuration for the "default" lifecycle
> > [2]
> >
> > Now it knows which plugins, versions and goals must be called. (it is
> > possible to call multiple calls within one phase) There is no explicit
> > executionId (I'm actually not sure if you can use it here, I think so),
> > so default- will be used as executionId. You can see this in the console
> > output of Maven. You can use this executionId for explicit configuration.
> > Keep in mind that plugins are very isolated.
> > They have their own classloader during execution.
> > They don't share configuration or instances with other plugins(*), you
> > could treat the pom as the shared configuration.
> >
> > For the creation of a Multirelease jar we have sepatare challenges for the
> > following phases: compile, test and packaging. The simplest of the three
> > is probably packaging: you need to ensure that the manifest has the
> > attribute Multi-Release: true Depending on in which folder/package
> > structure the classes are available you need to build up the right
> > structure, putting classes in their matching
> > META-INF/versions/${release}/
Re: source directory layout for multirelease jars
On Fri, May 1, 2020 at 1:52 PM Hervé BOUTEMY wrote: > when the need is restricted META-INF/versions/9/module-info.class, ie not > really code per Java release, but only module or not module, isn't one > strategy better to use, given there should be less tests to be run? > > perhaps the answer is that MR is overkill for that, given JDK 8 will > simply > ignore module-info.class? > > That's why the JUnit team decided to place module-info.class files in the root of each published artifact [0]. We got zero negative feedback for doing so for over a year now. Yes, that's not a proof, but still a good indication that most tools and runtimes on Java 8 ignore those compiled module descriptors. Cheers, Christian [0]: https://github.com/junit-team/junit5/pull/1857/files#diff-9d20ecc86db63514a52ddb1914e60477R90-R92
Re: source directory layout for multirelease jars
when the need is restricted META-INF/versions/9/module-info.class, ie not
really code per Java release, but only module or not module, isn't one
strategy better to use, given there should be less tests to be run?
perhaps the answer is that MR is overkill for that, given JDK 8 will simply
ignore module-info.class?
Regards,
Hervé
Le jeudi 30 avril 2020, 19:40:15 CEST Robert Scholte a écrit :
> Hi Benjamin,
>
> You're confusing me
>
> "Sadly, you cannot just add executions to the maven compiler plugin."
> Why not? The design of the pom contains support of multiple executions
> within the same plugin
>
> "Almost no IDE supports it, ..."
> I think they all do. And even if they don't, they should. I consider an IDE
> as a wrapper around Maven, so it should support this basic feature
>
> "... and when I asked about multiple executions
> in the maven compiler plugin on this list I recevied only one reply
> that this is not an intended way of using this plugin (although I was
> using it for annotation processing with
> useIncrementalCompilation=false)."
>
> I don't recognize this question. And the answer looks incorrect to me.
>
> That said: if you just want a META-INF/versions/9/module-info.class, you can
> already do that (for a long time).
> https://github.com/apache/maven-compiler-plugin/tree/master/src/it/multirel
> ease-patterns However, there is no one ideal pattern, you have to pick one,
>
> Robert
>
>
>
>
> On 30-4-2020 08:49:02, Benjamin Marwell wrote:
> Hi,
>
> to make the story a bit shorter - for most libraries it would be
> sufficient to add a way to include a module descriptor at
> "META-INF/versions/9/module-info.class" while still staying at java 8.
> Most libraries will stick to java 8 or even 7 for quite a time.
>
> Sadly, you cannot just add executions to the maven compiler plugin.
> Almost no IDE supports it, and when I asked about multiple executions
> in the maven compiler plugin on this list I recevied only one reply
> that this is not an intended way of using this plugin (although I was
> using it for annotation processing with
> useIncrementalCompilation=false).
>
> I know there is the moditect plugin for such cases, but it doesn't
> play along nicely with the bundle-plugin and hasn't seen much progress
> lately as far as I can tell.
>
> That said, adding such a module descriptor would be a nice first goal
> without using executions.
>
> Of course this will all become obsolete as soon as everyone uses java 9+.
>
> Am Sa., 25. Apr. 2020 um 21:20 Uhr schrieb Robert Scholte
>
> > I'm afraid this will be long story, but this might be the moment to share
> > the details.
> >
> > https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> > describes already several topics:
> >
> > - why MultiRelease Jars
> > - how to build them? There are several patterns, each with its pro's and
> > con's.
> >
> > But it doesn't explain the technical problems, so I guess we need to
> > explain it a bit better. I will also take the time to describes things
> > that you might already know.
> >
> > So you want to build a jar? You take the minimum pom (modelVersion +
> > groupId + artifactId + version) and you can set the packaging to jar (or
> > omit it, as it is the default value). You will call "package", which
> > matches a phase of the default lifecycle. Maven must first figure out the
> > matching lifecycle, by looping over all the available.[1] It will pick up
> > all mapped Lifecycle components and will search in its phases. The result
> > will be the "default" Lifecycle. Based on this Maven will look for "jar"
> > named LifecycleMapper and the configuration for the "default" lifecycle
> > [2]
> >
> > Now it knows which plugins, versions and goals must be called. (it is
> > possible to call multiple calls within one phase) There is no explicit
> > executionId (I'm actually not sure if you can use it here, I think so),
> > so default- will be used as executionId. You can see this in the console
> > output of Maven. You can use this executionId for explicit configuration.
> > Keep in mind that plugins are very isolated.
> > They have their own classloader during execution.
> > They don't share configuration or instances with other plugins(*), you
> > could treat the pom as the shared configuration.
> >
> > For the creation of a Multirelease jar we have sepatare challenges for the
> > following phases: compile, test and packaging. The simplest of the three
> > is probably packaging: you need to ensure that the manifest has the
> > attribute Multi-Release: true Depending on in which folder/package
> > structure the classes are available you need to build up the right
> > structure, putting classes in their matching
> > META-INF/versions/${release}/ -folder
> >
> >
> > Now the compiling part:
> > My first approach is close to what everybody wants: no additional
> > configuration in the pom (the minimal pom should be enough), use
> > src/main/java/ as predefined
Re: source directory layout for multirelease jars
Hi Benjamin,
You're confusing me
"Sadly, you cannot just add executions to the maven compiler plugin."
Why not? The design of the pom contains support of multiple executions within
the same plugin
"Almost no IDE supports it, ..."
I think they all do. And even if they don't, they should. I consider an IDE as
a wrapper around Maven, so it should support this basic feature
"... and when I asked about multiple executions
in the maven compiler plugin on this list I recevied only one reply
that this is not an intended way of using this plugin (although I was
using it for annotation processing with
useIncrementalCompilation=false)."
I don't recognize this question. And the answer looks incorrect to me.
That said: if you just want a META-INF/versions/9/module-info.class, you can
already do that (for a long time).
https://github.com/apache/maven-compiler-plugin/tree/master/src/it/multirelease-patterns
However, there is no one ideal pattern, you have to pick one,
Robert
On 30-4-2020 08:49:02, Benjamin Marwell wrote:
Hi,
to make the story a bit shorter - for most libraries it would be
sufficient to add a way to include a module descriptor at
"META-INF/versions/9/module-info.class" while still staying at java 8.
Most libraries will stick to java 8 or even 7 for quite a time.
Sadly, you cannot just add executions to the maven compiler plugin.
Almost no IDE supports it, and when I asked about multiple executions
in the maven compiler plugin on this list I recevied only one reply
that this is not an intended way of using this plugin (although I was
using it for annotation processing with
useIncrementalCompilation=false).
I know there is the moditect plugin for such cases, but it doesn't
play along nicely with the bundle-plugin and hasn't seen much progress
lately as far as I can tell.
That said, adding such a module descriptor would be a nice first goal
without using executions.
Of course this will all become obsolete as soon as everyone uses java 9+.
Am Sa., 25. Apr. 2020 um 21:20 Uhr schrieb Robert Scholte
:
>
> I'm afraid this will be long story, but this might be the moment to share the
> details.
>
> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> describes already several topics:
>
> - why MultiRelease Jars
> - how to build them? There are several patterns, each with its pro's and
> con's.
>
> But it doesn't explain the technical problems, so I guess we need to explain
> it a bit better.
> I will also take the time to describes things that you might already know.
>
> So you want to build a jar? You take the minimum pom (modelVersion + groupId
> + artifactId + version)
> and you can set the packaging to jar (or omit it, as it is the default value).
> You will call "package", which matches a phase of the default lifecycle.
> Maven must first figure out the matching lifecycle, by looping over all the
> available.[1]
> It will pick up all mapped Lifecycle components and will search in its
> phases. The result will be the "default" Lifecycle.
> Based on this Maven will look for "jar" named LifecycleMapper and the
> configuration for the "default" lifecycle [2]
>
> Now it knows which plugins, versions and goals must be called. (it is
> possible to call multiple calls within one phase)
> There is no explicit executionId (I'm actually not sure if you can use it
> here, I think so), so default- will be used as executionId.
> You can see this in the console output of Maven. You can use this executionId
> for explicit configuration.
> Keep in mind that plugins are very isolated.
> They have their own classloader during execution.
> They don't share configuration or instances with other plugins(*), you could
> treat the pom as the shared configuration.
>
> For the creation of a Multirelease jar we have sepatare challenges for the
> following phases: compile, test and packaging.
> The simplest of the three is probably packaging: you need to ensure that the
> manifest has the attribute Multi-Release: true
> Depending on in which folder/package structure the classes are available you
> need to build up the right structure, putting classes in their matching
> META-INF/versions/${release}/ -folder
>
>
> Now the compiling part:
> My first approach is close to what everybody wants: no additional
> configuration in the pom (the minimal pom should be enough), use
> src/main/java/ as predefined folder template.
> I did a POC, and it looks promising: the plugin would loop over the folders,
> extracted the release value and executed javac a couple of times, but the
> classes in the matching directory.
> Well, I was wrong: tests started to fail. I discovered that several
> parameters should only be used for a subset of a javac calls, or just exactly
> for one. Especially the includes/excludes caused trouble.
> I could try to find a configuration for includes/excludes per release value
> within the same execution, but I knew there were other properties needing
>
Re: source directory layout for multirelease jars
Hi,
to make the story a bit shorter - for most libraries it would be
sufficient to add a way to include a module descriptor at
"META-INF/versions/9/module-info.class" while still staying at java 8.
Most libraries will stick to java 8 or even 7 for quite a time.
Sadly, you cannot just add executions to the maven compiler plugin.
Almost no IDE supports it, and when I asked about multiple executions
in the maven compiler plugin on this list I recevied only one reply
that this is not an intended way of using this plugin (although I was
using it for annotation processing with
useIncrementalCompilation=false).
I know there is the moditect plugin for such cases, but it doesn't
play along nicely with the bundle-plugin and hasn't seen much progress
lately as far as I can tell.
That said, adding such a module descriptor would be a nice first goal
without using executions.
Of course this will all become obsolete as soon as everyone uses java 9+.
Am Sa., 25. Apr. 2020 um 21:20 Uhr schrieb Robert Scholte
:
>
> I'm afraid this will be long story, but this might be the moment to share the
> details.
>
> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> describes already several topics:
>
> - why MultiRelease Jars
> - how to build them? There are several patterns, each with its pro's and
> con's.
>
> But it doesn't explain the technical problems, so I guess we need to explain
> it a bit better.
> I will also take the time to describes things that you might already know.
>
> So you want to build a jar? You take the minimum pom (modelVersion + groupId
> + artifactId + version)
> and you can set the packaging to jar (or omit it, as it is the default value).
> You will call "package", which matches a phase of the default lifecycle.
> Maven must first figure out the matching lifecycle, by looping over all the
> available.[1]
> It will pick up all mapped Lifecycle components and will search in its
> phases. The result will be the "default" Lifecycle.
> Based on this Maven will look for "jar" named LifecycleMapper and the
> configuration for the "default" lifecycle [2]
>
> Now it knows which plugins, versions and goals must be called. (it is
> possible to call multiple calls within one phase)
> There is no explicit executionId (I'm actually not sure if you can use it
> here, I think so), so default- will be used as executionId.
> You can see this in the console output of Maven. You can use this executionId
> for explicit configuration.
> Keep in mind that plugins are very isolated.
> They have their own classloader during execution.
> They don't share configuration or instances with other plugins(*), you could
> treat the pom as the shared configuration.
>
> For the creation of a Multirelease jar we have sepatare challenges for the
> following phases: compile, test and packaging.
> The simplest of the three is probably packaging: you need to ensure that the
> manifest has the attribute Multi-Release: true
> Depending on in which folder/package structure the classes are available you
> need to build up the right structure, putting classes in their matching
> META-INF/versions/${release}/ -folder
>
>
> Now the compiling part:
> My first approach is close to what everybody wants: no additional
> configuration in the pom (the minimal pom should be enough), use
> src/main/java/ as predefined folder template.
> I did a POC, and it looks promising: the plugin would loop over the folders,
> extracted the release value and executed javac a couple of times, but the
> classes in the matching directory.
> Well, I was wrong: tests started to fail. I discovered that several
> parameters should only be used for a subset of a javac calls, or just exactly
> for one. Especially the includes/excludes caused trouble.
> I could try to find a configuration for includes/excludes per release value
> within the same execution, but I knew there were other properties needing
> similar features.
> And then I came to the conclusion the an "executionblock" should match
> exactly one javac call, it is already named like that!
> It does mean, that you must define multiple execution-blocks. And because
> execution blocks aren't context aware you need to configure them a little
> bit. Right now that is:
> 11
>
> true
>
> ${project.basedir}/src/main/java11
>
>
>
> Multirelease is quite a specific feature that is only useful for a specific
> kind of libraries, so needing extra configuration for a reliable result was
> acceptable for me.
>
> Testing is by far the hardest part and the most underestimated part: you can
> only test multirelease jar a a jar (so you cannot test it with surefire, you
> must use failsafe) and must test it separately with all targeted JDK release
> versions.
> Or you must make multiple test-jars, stripping of every release layer, but
> that means that you are actually not testing the deliverable.
> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
Re: source directory layout for multirelease jars
I'm afraid this will be long story, but this might be the moment to share the
details.
https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
describes already several topics:
- why MultiRelease Jars
- how to build them? There are several patterns, each with its pro's and con's.
But it doesn't explain the technical problems, so I guess we need to explain it
a bit better.
I will also take the time to describes things that you might already know.
So you want to build a jar? You take the minimum pom (modelVersion + groupId +
artifactId + version)
and you can set the packaging to jar (or omit it, as it is the default value).
You will call "package", which matches a phase of the default lifecycle.
Maven must first figure out the matching lifecycle, by looping over all the
available.[1]
It will pick up all mapped Lifecycle components and will search in its phases.
The result will be the "default" Lifecycle.
Based on this Maven will look for "jar" named LifecycleMapper and the
configuration for the "default" lifecycle [2]
Now it knows which plugins, versions and goals must be called. (it is possible
to call multiple calls within one phase)
There is no explicit executionId (I'm actually not sure if you can use it here,
I think so), so default- will be used as executionId.
You can see this in the console output of Maven. You can use this executionId
for explicit configuration.
Keep in mind that plugins are very isolated.
They have their own classloader during execution.
They don't share configuration or instances with other plugins(*), you could
treat the pom as the shared configuration.
For the creation of a Multirelease jar we have sepatare challenges for the
following phases: compile, test and packaging.
The simplest of the three is probably packaging: you need to ensure that the
manifest has the attribute Multi-Release: true
Depending on in which folder/package structure the classes are available you
need to build up the right structure, putting classes in their matching
META-INF/versions/${release}/ -folder
Now the compiling part:
My first approach is close to what everybody wants: no additional configuration
in the pom (the minimal pom should be enough), use src/main/java/ as
predefined folder template.
I did a POC, and it looks promising: the plugin would loop over the folders,
extracted the release value and executed javac a couple of times, but the
classes in the matching directory.
Well, I was wrong: tests started to fail. I discovered that several parameters
should only be used for a subset of a javac calls, or just exactly for one.
Especially the includes/excludes caused trouble.
I could try to find a configuration for includes/excludes per release value
within the same execution, but I knew there were other properties needing
similar features.
And then I came to the conclusion the an "executionblock" should match exactly
one javac call, it is already named like that!
It does mean, that you must define multiple execution-blocks. And because
execution blocks aren't context aware you need to configure them a little bit.
Right now that is:
11
true
${project.basedir}/src/main/java11
Multirelease is quite a specific feature that is only useful for a specific
kind of libraries, so needing extra configuration for a reliable result was
acceptable for me.
Testing is by far the hardest part and the most underestimated part: you can
only test multirelease jar a a jar (so you cannot test it with surefire, you
must use failsafe) and must test it separately with all targeted JDK release
versions.
Or you must make multiple test-jars, stripping of every release layer, but that
means that you are actually not testing the deliverable.
https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html shows
a matrix with all kind of approaches.
My preferred solution is the test it with a CI server with multiple JDKs and
use profiles to decide which mulitirelease sources should be compiled, but it
all depends on your way of work.
github.com/codehaus-plexus/plexus-languages/blob/master/plexus-java/pom.xml#L105-L151
The way you want to test has effect on how you can compile and vice versa.
I have my doubt there's a solution that covers it all.
Should Maven be changed for this? Well, maybe. The key is that you need to add
executions dynamically, and the first plugin that can inform Maven about that
is the maven-compiler-plugin.
I'm saying dynamically, because you don't want to have a static list like
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile@default-compile,
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile@default-compile_java11,
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile@default-compile_java14,
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile@default-compile_java15
It is possible to create MRJARs for several years, but it requires additional
configuration.
And I don't mind, because
Re: source directory layout for multirelease jars
The structure which I want is; src/main/java src/main/java11 src/main/java14 src/test/java src/test/java11 src/test/java14 I'm wanting to create a java 1.8 jar, with java 11 LTS support and the latest release java version supported. So newer projects can use modules and older projects still have a single jar they can depend upon and choose when to upgrade within having to change and GAV details. Which the maven-compiler-plugin can handled, and produce a MR-JAR, but the issues I've encountered are; 1) surefire doesn't support toolchain yet, believe is out in 3.0.0-M5 2) Bug since Java 9 and still in 14 regarding MR-JAR and JPMS, where the root java version can't be 1.8, it must be 9 or newer. otherwise so if your have java 1.8 and this java 11 /META-INF/versions/11/module-info.class, it would be valid for jar but not for java or javac even if you specify -release 11. 3) IDE's can't handle different project subdirectories being different java versions I do like the new 6 month release cycles but i'm still feeling some projects are yet to move from java 6, or 7 to even 8, so some issues are yet to be found... John On Fri, 24 Apr 2020 at 17:06, Christian Stein wrote: > > Robert (?) wrote this page [0] about supporting MR-JAR files. > > There're several approaches to the topic. It'd be nice, if the compiler- and > the jar-plugin would pick one by default or based on a directory layout > convention. > > [0]: > https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html > > On Fri, Apr 24, 2020 at 5:26 PM Elliotte Rusty Harold > wrote: > > > I've been thinking about multirelease jars. First step is source layout. > > Here's a strawman modeled after the jar layout. > > > > We add a versions directory to the existing src directory. Inside the > > versions directory one can have directories named 9, 10, 11, etc. for each > > major Java version that has custom code. Each numbered directory is a full > > src folder that contains main, test, etc. > > > > > > Can anyone poke holes in this? Is there a reason why this wouldn't suffice? > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: source directory layout for multirelease jars
Robert (?) wrote this page [0] about supporting MR-JAR files. There're several approaches to the topic. It'd be nice, if the compiler- and the jar-plugin would pick one by default or based on a directory layout convention. [0]: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html On Fri, Apr 24, 2020 at 5:26 PM Elliotte Rusty Harold wrote: > I've been thinking about multirelease jars. First step is source layout. > Here's a strawman modeled after the jar layout. > > We add a versions directory to the existing src directory. Inside the > versions directory one can have directories named 9, 10, 11, etc. for each > major Java version that has custom code. Each numbered directory is a full > src folder that contains main, test, etc. > > > Can anyone poke holes in this? Is there a reason why this wouldn't suffice? > > -- > Elliotte Rusty Harold > elh...@ibiblio.org >
source directory layout for multirelease jars
I've been thinking about multirelease jars. First step is source layout. Here's a strawman modeled after the jar layout. We add a versions directory to the existing src directory. Inside the versions directory one can have directories named 9, 10, 11, etc. for each major Java version that has custom code. Each numbered directory is a full src folder that contains main, test, etc. Can anyone poke holes in this? Is there a reason why this wouldn't suffice? -- Elliotte Rusty Harold elh...@ibiblio.org
