some docu cleanup

Build.md

@@ -1,13 +1,19 @@
 # build jbundler #
 
-the build uses ruby-maven
+the build uses ruby-maven. **note** ruby-maven uses maven and maven is highly modular, i.e. it comes only with the core and the moment you need a plugin he first time its starts downloading it. with that in mind the first usage of (ruby-)maven involves a lot of downloading - so be prepared :)
+
+first get all the development gems in place:
 
 ```jruby -S bundle install```
 
-to build the jar for the lib directory (prepare the jar before packaging the gem)
+to build the (extension) jar for the lib directory (prepare the jar before packaging the gem)
 
 ```rmvn prepare-package```
 
+this also runs all the test over a couple of jruy version each in 1.8 and 1.9 mode. so these tests take some time. in skip the tests when building the gem use:
+
+```rmvn prepare-package --Dmaven.test.skip```
+
 to build the gem in **target/jbundler-0.0.1.gem**
 
 ```rmvn package```
@@ -20,7 +26,7 @@ will do as well.
 
 ## proper maven and IDEs ##
 
-once ```rmvn``` generated the **jbundler.gemspec.pom** you can use proper maven3 by setting a sybolic link **pom.xml** to **jbundler.gemspec.pom**. in the end rmvn is just ruby wrapper around maven3. the **jbundler.gemspec.pom** is generated from the *jbundler.gemspec* and *Mavenfile*.
+once ```rmvn``` generated the **Gemfile.pom** you can use proper maven3 by setting a sybolic link from **pom.xml** to **Gemfile.pom**. in the end rmvn is just ruby wrapper around maven3. the **Gemfile.pom** is generated from the *jbundler.gemspec*, *Gemfile*, *Gemfile.lock* and *Mavenfile*.
 
 your IDE might be able to use the pom.xml to manage the project and its java sources.
 

Readme.md

@@ -33,14 +33,12 @@ execute *example/my_project/info.rb* to see it in action:
 
 ## limitations ##
 
-the current implementation is proof of concept. for example the local maven repository needs to be under $HOME/.m2/repository, etc
-
 update of single artifacts is not possible.
 
-there are no specs in place (yet) so expect a few more bugs ;-)
-
 since the version resolution happens in two steps - first the gems then the jars/poms - it is possible in case of failure of the second one there could be another set of versions for the gems which would then succeed the jars/poms resolution. but there is plenty of possible ways to improve this (maven could resolve the gems as well, etc)
 
+**Mvnfile** is **not** a DSL, i.e. it is not ruby though it could use a ruby DSL to read the data (any contribution welcome).
+
 ## jar/pom dependencies ##
 
 a pom dependency is not associated with a jar file but has dependencies to other poms or jars. 
@@ -83,7 +81,7 @@ the *not* version **!3.4.5** can not be mapped properly to a maven version range
 
 update of a single artifact is not possible (yet). but to update the whole set of artifacts just delete the lockfile *Mvnfile.lock*
 
-if jbundler see that **Gemfile.lock** or **Mvnfile** is newer then the **.jbundler/classpath.rb** file then jbundler tries to gracefully upgrade towards the changes. the is more a maven-like behaviour and once there are command line tools for jbundler this behaviour might be replaced with a more bundler like handling of things.
+if jbundler sees that **Gemfile.lock** or **Mvnfile** is newer then the **.jbundler/classpath.rb** file then jbundler tries to gracefully upgrade towards the changes. the is a maven-like behaviour and once there are command line tools for jbundler they can behave like bundler.
 
 ## meta-fu ##
 

jbundler.gemspec

@@ -8,5 +8,5 @@ END
   s.authors = ['Kristian Meier']
   s.email = ['m.kristian@web.de']
   s.files = Dir['lib/**/*rb'] + ['lib/jbundler.jar', 'MIT-LICENSE'] + Dir['*.md']
-  s.add_runtime_dependency "ruby-maven", "= 3.0.3.0.28.7.pre"
+  s.add_runtime_dependency "ruby-maven", "= 3.0.3.0.29.0.pre"
 end