Joerg Hohwiller wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Trygve, hi everybody,
I have some things to chat about unix-maven-plugin.
After about half a year I finally found the time to
start digging...
Here are some issues to improve or discuss:
* There is no component "unix" in JIRA for MOJO.
Should we create one?
There's a complete JIRA project for it! See [1].
* DebControlParserTest fails to run on windows. I debugged into
and found out that it reads the control-files from the disc with
windows newlines and then compares them with the strings in the
code of the testcase that have \n build in.
My suggestion would be to set property svn:eol-style=LF on the
according control files to fix this.
* Why are you NOT using org.junit.Assert-Methods (at least inside TestUtil)?
You are wasting rich IDE support to evaluate the failures
of JUnit-tests. If you want to I can send you a patch.
Otherwise let me know why your created your on solution.
Where is that? There are a few assert method to support more complicated
assert scenarios, but most should use the standard JUnit. Many of them
dump the information and try to make smart diffs too.
* The code-style is a little bit strage for me but I guess
this origins because I am not familiar with functional-java.
Are you using a specific fj-IDE?
However is it just lazyness that there is hardly any javadoc
or comment? Or is the code partially generated?
It makes it a little difficult to get into especially
because of the compact names you use (If StringF was named,
StringFunctions one would get it easier and I personally
prefer rich IDE such as Eclipse so I do not care about
longer names).
"StringF" made more sense to me as the interface is called "F" and it is
so littered over the FJ code already. I find most of the code to have
quite self-explanatory names, but I see your point.
Otherwise I might add some comments when I digged through
some parts of the code and add it to a potential patch.
The reason for not having too much javadoc is because I try to make the
code as self-explanatory as possible and that they tend to be more out
of date than correct. I can always add more comments to specific areas
if there are specific stuff you're wondering about.
I realize the code style is a bit funky, in particular with so many
inner classes. IntelliJ IDEA make a lot of them easier to read. I've
done it as a learning experience and fully realize that some parts of
the code is quite convoluted.
If you want to I would like to port the whole thing to scala as I know
it would reduce the line count by at least 50% and it would be much
easier to read.
* Do I get it right that several pieces of code are just
fancy ideas but never used in the code (such as chmod and
chmodIf, etc.)? I just ask because it confused me (e.g.
for chmod I expected that you do this on the vfs rather
than native).
That might be true a couple of cases. There are also code that has been
in use but are not used anymore. Chmod in particular should be used, or
was at least implemented because vfs doesn't support those kind of
operations. Chmod is required to get dpkg to include the right
permissions of the file. chown is harder though, which is why I want to
implement the whole Debian support in pure Java.
* A lot more to talk about but not tonight :)
I'm usually on #maven on irc.codehaus.org, feel free to join there for a
chat.
[1]: http://jira.codehaus.org/browse/MUNIX
--
Trygve
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
