Maven plugin
Ben
This will do two things:
1) Set the -javaagent and jcarder.outpurDir on the surefire test run.
2) Convert the dot output to pngs, to be reported in the project site
I also hope to make jcarder output be tracked by hudson and/or sonar,
in the same way that other tools are (checkstyle, pmd, and of course
junit test results, etc).
Personally, I prefer svn to hg, but that's just my experience. In any
case, even if jcarder itself stays in hg, can I use the google-code
site for jcarder to host the maven-jcarder-plugin code in svn?
And another random question: why not switch the package name of
jcarder to org.jcarder since the domain is now registered?
And, not that is necessary, but I am making a maven build process,
that does the same thing as the ant build.xml, so that we can submit
jcarder to the central maven repository.
JCarder Rocks! Saved me days of debugging!
Ulrik Svensson
On Mon, Nov 24, 2008 at 5:33 PM, Ben <bent...@gmail.com> wrote:
> I am working on wrapping JCarder into a maven plugin.
A maven-jcarder-plugin would be very cool! And I especially like your
idea about being able to visualize the graphs with a renderer
implemented in java. If we can not find a suitable graphviz java
implementation, but instead finds another renderer that can't parse
dot files, we might consider replacing the dot-output-format with
something else.
> Personally, I prefer svn to hg, but that's just my experience. In any
> case, even if jcarder itself stays in hg, can I use the google-code
> site for jcarder to host the maven-jcarder-plugin code in svn?
Personally I like Mercurial with its distributed repository model. Me
and Joel have our own personal Mercurial jcarder-repositories and are
peer-reviewing and then pushing each others change sets to the
repository at hg.jcarder.org. If you would like to setup a local hg
repository we can push your change sets to hg.jcarder.org in a similar
way. But if you instead prefer Subversion for the maven-jcarder-plugin
I can give you access to the svn repository at google code. Choose
what you think would work best for you?
> And another random question: why not switch the package name of
> jcarder to org.jcarder since the domain is now registered?
The JCarder source code has been released to the open source community
by Enea and we decided to keep the com.enea.jcarder package name to
give some advertising to Enea in return.
> And, not that is necessary, but I am making a maven build process,
> that does the same thing as the ant build.xml, so that we can submit
> jcarder to the central maven repository.
I've been reading a little bit more about Maven now and I like it. I
think that especially the handling of our 3pps would be better and
more standardized with Maven. If you provide a pom.xml file I would be
happy to replace the ant build.xml file.
/Ulrik
Ben
wrote:
...
>> And another random question: why not switch the package name of
>> jcarder to org.jcarder since the domain is now registered?
>
> The JCarder source code has been released to the open source community
> by Enea and we decided to keep the com.enea.jcarder package name to
> give some advertising to Enea in return.
groupId for Maven?
I will create org.jcarder:jcarder and org.jcarder:maven-jcarder-plugin
(syntax is groupId:artifactId) for the two poms.
-Ben
Ulrik Svensson
the java package name is com.enea.jcarder.
My name is listed in the whois database for the jcarder.org domain, so
it would make it easier to provide proof that we are owning the domain
when we are adding bundles to the central maven repository, according
to the instructions at
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
/Ulrik
Ulrik Svensson
rendering the graphs from JCarder. We were looking for such tools last
year and this weekend I gave it a new try, but I still have not find a
java implementation that can replace Graphviz.
Many graph tools such as ZGRViewer, Grappa, Yoix, iDot, TINTFU are
implemented partly in java but depends on a native Graphviz dot
installation, either locally or remote, to perform graph layouts.
There are also some commercial non-open source java libraries (yFiles,
JGraph Layout Pro, ILOG JViews) that I didn't investigate due to their
licenses.
Then there are some open source java libraries, but my first
impression is that none of them can layout directed cyclic graphs,
like ours, as good as Graphviz can. The Graphviz algorithm is
described here: http://www.graphviz.org/Documentation/TSE93.pdf. I'm
also not sure if the libraries can they can handle edge labels with
multiple rows and avoid that edges crosses labels. Here is a list of
what I found if anyone would like to investigate this further:
Giny
- Sugiyama algorithm?
- http://csbi.sourceforge.net
GUESS
- GEM and Sugiyama algorithms?
- http://graphexploration.cond.org
JFLAP
- GEM algorithm
- http://www.jflap.org
Pedvizapi
- Sugiyama algorithm
- www.pedvizapi.org
CharGer
- Sugiyama algorithm?
- http://charger.sourceforge.net
VGJ
- CGD algorithm
- http://www.eng.auburn.edu/department/cse/research/graph_drawing/graph_drawing.html
Jung
- http://jung.sourceforge.net/
Prefuse
- http://prefuse.org/
This weekend I have also been trying a new approach and cross-compiled
the Graphviz dot tool into statically linked MIPS binary together with
the most important of its dependencies. That MIPS binary can be
executed in a JVM after its been converted into java byte code by
NestedVM. Generating a svg-file from a dot-file works fine. The
performance is good enough for typical graph sizes.
One problem is that my MIPS binary has no support for Cairo or
Fontconfig and has no access to any of the fonts that might be used
when the resulting SVG is rasterized later. Therefore Graphviz has to
make a guess about how much place each text label is going to need,
and that guess is not very accurate. However, the SVG standard
specifies the attributes textLength and lengthAdjust to solve this
problem, and I wrote a small patch to make Graphviz fill out those
attributes according to its guess about how much space the labels are
going to need. A SVG renderer that understand those attributes can
adapt the font size to make the label fit inside the space assumed by
Graphwiz.
The SVG attributes textLength and lengthAdjust doesn't seem to be
supported by many tools/libraries, but they are supported by
the Batik SVG library (http://xmlgraphics.apache.org/batik/). And
there is at least one SVG Browser (Squiggle) and a rasterizer (that
can generate PNGs) that are part of the Batik project and can adapt
font sizes according to the attributes. I've been trying them and they
rasterizes the SVGs perfectly fine with anti aliasing and everything.
Another problem with the MIPS binary is that the build procedure is
complicated, but that does not affect the end users of JCarder.
If we can not find a java implementation, this MIPS binary may be a
workaround for those that feel that it is cumbersome to find, install
and configure a native Graphviz installation.
/Ulrik
Ben
the build.xml, with Maven.
I'm not sure this is strictly necessary at all...but this is what I
have done so far:
- Moved source directories to standard locations.
- Used the buildnumber-maven-plugin to do the build numbering for
build.properties.
- I had to change the timestamp to long seconds, and then use the
SimpleDateFormatter in the real code to display it.
- Used the maven-assembly-plugin to create:
- the uber jar itself (jar-with-dependencies)
- examples.jar
- The zip/tar.gz/tar.bz2 of everything (txt files, uber jar, etc).
The pom also, of course, includes all the general project info as well
(ci, issue tracker, licencing), etc.
The maven plugin I have has a prepare-surefire goal that will setup
jcarder to be running during the test code run. The default output is
target/jcarder-output.
Let me know how to proceed...do I submit a patch? Do I push directly
to hg.jcarder.org?
-Ben
Ulrik Svensson
It would be easiest if you can export your change sets with the hg
export commands using the following parameters:
hg export --git --output "file-%n-%R.patch" <revisions>
tar -tzf patches.tar.gz file*.patch
and then please send the resulting patches.tar.gz file to me by email.
<revisions> can be a range of different revisions, for example for all
change sets from revision 103 and newer you can use:
hg export --git --output "file-%n-%R.patch" 103:
Each change set has a meta data field named User that will be included
in the export. As long as you don't tell me otherwise I will use the
User provided in your change sets when I push them to hg.jcarder.org.
Have you decided if you want to put maven-jcarder-plugin at
hg.jcarder.org or in svn at google code? If you would like to put it
at hg.jcarder.org I'm thinking about if it would be best to put also
the plugin in the existing repository http://hg.jcarder.org/jcarder or
if we should create separate repository like
http://hg.jcarder.org/maven-jcarder-plugin. I'm not sure about what
would be best?
/Ulrik
Ulrik Svensson
tar -czf patches.tar.gz file*.patch
/Ulrik
On Dec 6, 1:30 am, "Ulrik Svensson" <ulri...@gmail.com> wrote:
> tar -tzf patches.tar.gz file*.patch
Joel Rosdahl
> It would be easiest if you can export your change sets with the hg
> export commands using the following parameters:
>
> hg export --git --output "file-%n-%R.patch" <revisions>
> tar -tzf patches.tar.gz file*.patch
Other options:
* Create a bundle with the changes:
hg bundle mybundle.hg http://hg.jcarder.org/jcarder/
Then mail mybundle.hg.
* Publish a repository that includes the changes somewhere (for
instance on http://www.bitbucket.org) and let us know the location
so that we can pull from it.
* Use the patchbomb extension (hg email -h) to send the patches as
separate mails.
Regards,
Joel
--
Joel Rosdahl <jo...@rosdahl.net>
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D 8B22 0064 F9FF BB84 5E97