Before the next release (the number of issues tagged 0.3 is
slowly dropping), I'd like to reorganize a bit the source files.
In addition to the original source code (the compilation sheets),
we have now the scripts (shell, batch and XProc), some resources
(CSS, schemas, graphics, etc), some build tools (Ant script,
Makefile), all in top-level directory. Plus other sub-directories
for Java code, editors support, tests and the tutorial.
I think it is time to reorganize a bit this "architecture" and
put the top-level files in some sub-directories (like src/ and
build/, at least).
Any objection?
--
Florent Georges
http://fgeorges.org/
-James
Hi,
> Sounds good. No objection here.
Good, thanks James. What do you (I mean, all of you :-p) think
about the following changes? I shall create 3 new directories:
bin/, build/ and src/, with the following content:
bin/
xspec.bat
xspec.sh
build/
build.xml
src/
compiler/
generate-common-tests.xsl
generate-query-helper.xsl
generate-query-tests.xsl
generate-query-utils.xql
generate-tests-helper.xsl
generate-tests-utils.xsl
generate-xspec-tests.xsl
reporter/
coverage-report.xsl
format-utils.xsl
format-xspec-report-folding.xsl
format-xspec-report.xsl
test-report.css
schemas/
find-examples.rnc
xspec.rnc
tools/
xspec.xpl
The files LICENSE and README stay on top. There are also both
files find-examples.xml and find-examples.xsl, but I am not sure
exactly where they belong. Actually I am not sure of their exact
purpose. Any idea?
Regards,
LICENSE is there because the terms of the MIT license state (I think)
that we're technically required to include the license text. I added
the README a while back just because it seemed like good practice,
even if all it does is point people to the website. :)
-James
To me, a 'build' directory implies content that has been built by some
compilation process. It's usually stuff that you can delete when you
cleanup, as opposed to 'src', which you can't.
It might be better to put 'build.xml' into a 'lib' directory?
> src/
> compiler/
> generate-common-tests.xsl
...
These aren't 'sources' in the sense that they need to be compiled into
some other format to be usable. Maybe they're all 'lib' material?
> tools/
> xspec.xpl
>
> The files LICENSE and README stay on top. There are also both
> files find-examples.xml and find-examples.xsl, but I am not sure
> exactly where they belong. Actually I am not sure of their exact
> purpose. Any idea?
Tutorial? Example?
Regards,
Tony.
> That looks good. The only comment I have is that maybe
> build.xml belongs in bin/ with the other two scripts, since it
> doesn't really build xspec so much as run it.
Ok, I thought that was to build the project, but if it is
another "runner", of course, that makes sense... :-)
Hi,
> To me, a 'build' directory implies content that has been built
> by some compilation process.
Yeah, true. I used to use that name for a project's build
process though; not sure that's a good idea. But as James
noticed, this file is not a build file for the project, but one
way to run a test suite, so makes sense to go to bin/ instead.
>> src/
>> compiler/
>> generate-common-tests.xsl
> These aren't 'sources' in the sense that they need to be
> compiled into some other format to be usable. Maybe they're
> all 'lib' material?
I don't understand. Those are the main source files we are
working on. The set of stylesheets that compile a test suite to
either XSLT or XQuery (which in turn is run to provide a report).
Did I miss something?
>> There are also both files find-examples.xml and
>> find-examples.xsl, but I am not sure exactly where they
>> belong. Actually I am not sure of their exact purpose. Any
>> idea?
> Tutorial? Example?
If they are examples, yes. But it seems they are not, and
instead serve a purpose in the project, that I can't find out
(it seems it is really "find examples" and not "an example of
find"). But I can be wrong. Does someone use them?
Thanks for your comments!
Hi,
> Before the next release (the number of issues tagged 0.3 is
> slowly dropping), I'd like to reorganize a bit the source
> files.
I'd like (almost 1 year after, gosh!) to revive this thread.
If there is still no objection to this, I will reorganize the
XSpec directory as following:
bin/
xspec.bat
xspec.sh
src/
compiler/
generate-common-tests.xsl
generate-query-helper.xsl
generate-query-tests.xsl
generate-query-utils.xql
generate-tests-helper.xsl
generate-tests-utils.xsl
generate-xspec-tests.xsl
reporter/
coverage-report.xsl
format-utils.xsl
format-xspec-report-folding.xsl
format-xspec-report.xsl
test-report.css
schemas/
find-examples.rnc
xspec.rnc
harnesses/
exist/
exist-xquery-harness.xproc
marklogic/
ml-xquery-harness.xproc
saxon/
saxon-xslt-harness.xproc
saxon-xquery-harness.xproc
xproject/
cxan.xml
project.xml
This includes remarks from the previous thread, as well as adds
harnesses to run tests on different processors (namely eXist,
MarkLogic and Saxon) and adds xproject/ infos in order to build
automatically an EXPath package for XSpec (using XProject).
Any objection?
Regards,
--
Florent Georges
http://fgeorges.org/
Hi,
>> Before the next release (the number of issues tagged 0.3 is
>> slowly dropping), I'd like to reorganize a bit the source
>> files.
> I'd like (almost 1 year after, gosh!) to revive this thread.
> If there is still no objection to this, I will reorganize the
> XSpec directory as following:
Since I haven't heard any objection, I've finally committed my
changes. Can you please have a look at the new structure, and
confirm that everything's still working fine in your environment,
your specific configuration?
If you are using the XProc pipeline, I am also going to commit
new XProc harnesses in src/harnesses/. Indeed, we need to be
able to run tests on several different processors (Saxon, but
also eXist, BaseX, MarkLogic, and others...) The equivalent of
the old pipeline is src/harnesses/saxon/saxon-xslt-harness.xproc
then.