From: Emmanuel P. <emm...@in...> - 2007-10-19 06:35:22
|
> Hi, > > Regarding SVN > There is nothing magical about the folders named /tags, /trunk etc. =20= > they are > just conventions that many/most follow, so you are correct - all =20 > you need to > do is to create these folders and move the current folders into /=20 > trunk. At > the same time you may want to move the source folders into "/trunk/=20 > src" to > make the root under trunk look like the layout for the distribution =20= > (and > match the instructions in build.xml). > > If you want to do more, it would be beneficial to break things up into > projects (like the optional gnb, and mdb). If you decide to do that =20= > I would > suggest a structure that looks like this: > > /projectname1 > /trunk > /projectname1 > /src > /com > / ..... > build.xml > /tags > /projectname1-7.0.2a > /projectname1 > (as under trunk) > /projectname1-7.0.2b > ...etc...etc > /branches > /projectname2 > /trunk > /tags > /branches > > This is the structure we are using, and it makes it very easy to =20 > get each > thing as a project, all names are compatible (i.e. you are working on > "projectname1" irrespective of if it is under a tag, the trunk or a =20= > branch. I'll probably go this way. I started doing this in the process of =20 "maven-izing" another completely unrelated project of mine. For ZVTM/=20 ZGRViewer, I'll keep working with Ant for the time being, but =20 eventually I will probably switch to Maven to (once I get enough time =20= to learn more about it). > Statemachine.jar > Yes you are right - my mistake. I do have statemachine.jar. > > Regarding reproducers etc. I will attach either SVG or dot files to =20= > issues > when appropriate. dot files are usually more convenient (I can get the SVG from it, =20 theopposite is not true). > If you are interested, here is some information about what I am =20 > working on: > > My plan is to use the applet (or a modified version) to view graphs =20= > that I > generate on the fly. These graphs describe software components and =20 > their > dependencies on other components and some graphs will be quite =20 > large (my > first attempts produced PNGs that were > 64000 pixels high ! =20 > Needless to > say, the size of these PNGs are also quite large. Unfortunately the > uncompressed SVG output is just as large (or even larger) and hence my > interest in the applet viewer with support for svgz. I also need =20 > the viewer > since FF SVG does not render the dot SVG output correctly (fontsize =20= > is off), > and IE does not have native support for SVG so users would have to =20 > install a > SVG viewer (and Adobe has discontinued the SVG plugin in favour of =20 > Flash - > sigh). FF SVG croaks on very large SVG files. So ZGRViewer has many =20= > benefits > even without using the search, lenses etc. > > I looked at the Yoix project as well as it renders the dot output =20 > directly > (and the dot output is much smaller than PNG and SVG), but I did =20 > not like > their approach with yet another language and environment on top of =20 > java. (I > would really like to have a java implementation of dot as that =20 > would reduce > the size of the data that needs to be transferred to perhaps 50-100k > (compressed) as opposed to the several megabytes of PNG or SVG output > (uncompressed)). I have looked into dot algorithms, and also dot =20 > source and > that seems like a major undertaking to learn and recreate in java. > > Anyway, the dependency graphs will be generated on the fly from our =20= > database > of dependencies, and we will graph the resolved configurations as =20 > well. > We are now just about to release our second alpha at > http://www.cloudsmith.com (alpha 1 is live there now and alpha 2 =20 > will be > released in a week or so). My plan is to add the graph viewing in =20 > the next > cycle - due in about a month. (The functionality to view graphs as =20 > PNGs and > raw DOT is available in the alpha 1, but there is no visible =20 > navigation to > it, in alpha 2 it will be possible to also obtain the SVG output. =20 > This is > what I am using when experimenting with the ZGRviewer applet. > > I guess that was a very long way of saying that there will be =20 > plenty of > samples to try out for anyone :) all I need to do is to give you a =20 > URL. Good. That sounds definitely interesting. > I hope to get enough time to complete the things I want to do =20 > (compression), > and other small things for our next cycle. I may have time to fix =20 > other > ZGRViewer issues as well, and I will then submit patches. =20 > (Sometimes that is > quicker than writing a bug report :)). Excellent. If you end up contributing more than support for SVGZ, it =20 might actually be more convenient to grant you write access to the =20 repository. We'll deal with that when the times come. cheers, Emmanuel -- Emmanuel Pietriga INRIA Futurs - Projet In Situ tel : +33 1 69 15 34 66 Bat 490, Universit=E9 Paris-Sud fax : +33 1 69 15 65 86 91405 ORSAY Cedex FRANCE http://www.lri.fr/~pietriga |