[source] Folder setup for interactions across multiple SourceForge repositories
Roy Walmsley
roy.walmsley at ntlworld.com
Tue Feb 16 04:03:37 PST 2016
Don,
Great reply below. Thanks for the time taken to explain this. I'm pleased to
note I haven't missed anything obvious, except that I was aware I had done
nothing on the Jenkins front. And no, I don't think you've missed anything
either.
I had examined the template file buildExamplesTemplate.xml and seen that it
is used to generate the build files in the individual example folders. I
learned that the hard way when I changed the build.xml file in the Basic
directory (only minor changes - a few minutes work) only for the changes to
revert when run!!
I'd seen the property "xj3d.dir" and modified it for my setup.
However, I was having another problem, specifically with "resolver.jar". I
noted the comments talked about getting this file from XMLCommons. When I
looked into it, it seemed to be difficult to achieve. And I already had a
resolver file "ant-apache-resolver.jar". I noted you had a property
"resolver.jar" that gave the directory location. I could use that, as I set
up the ANT_HOME environment variable. However, the file was always referred
to by name. So, I added a new property "resolver.jar", and gave it the value
of my "ant-apache-resolver.jar" file. I then modified all instances of
direct use of the file name with the property reference, so that the actual
file name only appears once. I should say, though, that it also occurs in
the comments so these might need to be updated.
With these changes, and no others, the file works for me, at least to the
point of committing to the server, when I cancel out, as usual.
I obviously don't want to commit the changes, as your set up may be
different to mine. But I have attached the file so you can see review my
changes directly. Perhaps, if you are agreeable, we can at least commit the
addition of the property and it's use instances, even if you keep the value
of the property the same as currently committed.
If there are a few things that are system dependent, should we put them in
one place at the top of the file? And should we write a 'SETUP GUIDE' that
explains to new users what they need to do in order to get everything
working? I think on the whole the information is there, it's just scattered
and takes a while to find.
Regards,
Roy
-----Original Message-----
From: Don Brutzman [mailto:brutzman at nps.edu]
Sent: 16 February 2016 00:28
To: Roy Walmsley
Cc: source at web3d.org
Subject: Re: Folder setup for interactions across multiple SourceForge
repositories
Thanks for your thoughtful look Roy. Here are several more pieces of
information.
a. We ported the Xj3D source over to sourceforge so that further work might
resume.
https://savage.nps.edu/Savage/developers.html#Xj3D
http://www.web3d.org/wiki/index.php/Xj3D_Evolution
https://sourceforge.net/projects/xj3d
Because individual programmers have different goals, we kept Xj3D as an
independent open-source project not dependent on the X3D tree at
SourceForge.
We have also kept the same directory structure and architectural design so
that any occasional changes checked into xj3d.org (both for Xj3D and
Aviatrix renderer) can get integrated into the Xj3D SourceForge build with
little difficulty.
b. Of note is that a number of other stylesheets and tools are included in
the X3D SourceForge archive, peer with the "content" directory, visible at
https://sourceforge.net/projects/x3d/
https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets
https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/tools
Also lurking upstairs in the "specifications" directory are DTDs, schemas,
etc. which are often invoked via relative paths as well.
https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/specifications/
c. We allow anyone building the X3D Examples Archives to use a local copy of
Xj3D by setting the property xj3d.dir for local path. Xj3D is used for
binary compression, image snapshot shooting and a few other tasks.
Alternatively we could bundle a .jar file with the archives, but then would
need to make multiple copies (one for each independent examples archive) and
also keep them up to date. Deployment might become troublesome... Xj3D has
many excellent features but it also has a bunch more work needed.
d. Not sure if anyone besides you has made the effort to build everything -
bravo sir - and so it would seem that handling Xj3D can still be fairly ad
hoc.
It would be great if Xj3D development gets busy again... here at NPS we are
able to make the occasional bugfix and improvement.
e. The Savage archives are intentionally separate. Unlike the other primary
X3D Examples Archives, which are now under a BSD-style open-source license
for Web3D Consortium authors, they are under a similar license for NPS.
Similarly the SavageDefense archives are slightly more restricted,
unclassified with For Official Use Only access restrictions, allowing our
team to work well with other government sponsors and partners.
Due to licensing and relevance, they are not appropriate to integrate as
part of Web3D Consortium's SourceForge x3d project archive.
I agree that both Savage and SavageDefense archives can be carefully dropped
in as peers as you suggest below. That is my typical configuration and
subversion seems OK - just be sure you check out the right directory at that
level, rather than "stepping on" the subversion configuration at directories
higher than the "examples" directory.
f. The parent "examples" directory includes a build.xml Ant file that has a
set of tasks that takes advantage of that shared child set of example
archives.
https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/content/examp
les/
It also has a "buildExamplesTemplate.xml" file that is customized for each
of the 7 examples archives. Each build.xml is further checked into version
control.
Incidentally the latest improvements for the X3D JSON encoding have also
rippled into pretty-print HTML, VRML97/ClassicVRML conversions, and X3DOM
wrapper pages. So after uploading JSON improvements I'll be continuing on
after performing a "clean.all" at the top level - always a good test that
everything is performing correctly, tho it can tak a few days to propagate!
g. Yet another build dependency hidden in plain sight: this work also works
on our Jenkins continuous integration server. Some sysadmin cleanup needed
on that box to get a few jars restored (gee there just aren't enough hours
in the week) but everything essentially works when it is setup properly.
TODO for me.
https://savage.nps.edu/Savage/developers.html#Jenkins
https://savage.nps.edu/jenkins/
h.So I think all of the goals you are looking for seem to be handled
already. I don't think Xj3D is yet to the point that warrants further
integration.
I hope it is now clearer that the build files are mostly independent yet all
tightly intertwined... so any changes do need to carefully coordinated.
Sound OK? Did we miss something? Please advise. As ever, questions and
improvements are welcome.
v/r Don
On 2/13/2016 2:04 AM, Roy Walmsley wrote:
> Don,
>
> Currently there are at least four independent repositories that have
interactions spanning multiple repositories.
>
> The x3d repository (https://sourceforge.net/projects/x3d/) is the main X3D
repository. Of relevance here is that it includes the Web3D examples, which
includes a Netbeans project entitled "X3D examples: archive top level".
>
> Detailed examination reveals that this project relies upon three
subprojects in three other repositories.
>
> The first is the Xj3D repository (https://sourceforge.net/projects/xj3d/).
>
> The second is the Savage examples archive
(https://savage.nps.edu/svn/repos/nps/list/Savage).
>
> The third is the Savage defence examples archive. This is, of course, a
restricted archive not available to the general public.
>
> The top level project needs to refer to each of the sub projects. This
needs to be done by specifying relative directories. Therefore, in order for
this to be successful, the relative locations of the cloned repositories
needs to be clearly specified.
>
> I therefore suggest the following.
>
> Assume that the top level folder exists, which for the sake of this
discussion I will simply name "TopLevel". It can be called anything the user
wishes. The x3d repository should be checked out into this folder. There are
two top level folders: "legacy" and "www.web3d.org". In the latter there are
two further folders: "specifications" and "x3d".
>
> The Xj3D repository should be checked out into the "www.web3d.org" folder.
This adds a third folder to "xj3d" to "specifications" and "x3d".
>
> The "x3d" folder contains five folders. The one we are particularly
interested in is "content". "content" has three folders. We are interested
in "examples". "examples" has seven folders. Five of these are of interest,
as they contain the full set of Web3D archive examples. These are "Basic",
"ConformanceNist", "Vrml2.0Sourcebook", "X3dForAdvancedModeling", and
"X3dForWebAuthors". It is into the "examples" folder that the Savage
examples, and, if available, the Savage Defence examples repositories should
be checked into. For the Savage examples archive this adds the folder
"Savage".
>
> In summary, this produces the following folder structure excerpt (only the
relevant folders are shown - there are many more).
>
> TopLevel -+
>
> |
>
> +- legacy
>
> +- www.web3d.org -+
>
> |
>
> +-
specifications
>
> +- xj3d
>
> +- x3d -+
>
>
|
>
>
+- content -+
>
>
|
>
>
+- examples -+
>
>
|
>
>
+- Basic
>
>
+- ConformanceNist
>
>
+- Vrml2.0Sourcebook
>
>
+- X3DForAdvancedModeling
>
>
+- X3DForWebAuthors
>
>
+- Savage
>
>
+- SavageDefence (??)
>
> Note: The nesting of repositories has not caused any problems on my
Windows system.
>
> If this folder structure is agreed then I will amend all paths to conform
to this structure. I will also modify the code so that the paths are
specified as variables at the start of a "build.xml" file so that, if
necessary, any modifications are only required in one place.
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildExamplesTemplate.xml
Type: text/xml
Size: 199070 bytes
Desc: not available
URL: <http://web3d.org/pipermail/source_web3d.org/attachments/20160216/6631d96a/attachment-0001.xml>
More information about the source
mailing list