I was thinking the same. Without being all for changing the name, 
maybe:groovy-single.jargroovy-fat.jargroovy-the-one.jar(or more fluent: 
the-one-groovy.jar ;-) )?
-------- Ursprüngliche Nachricht --------Von: Paul King <pa...@asert.com.au> 
Datum: 23.11.17  02:43  (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: 
Building Groovy 
The issue we sometimes get with names like "standalone" (and even "all") is 
that sometimes folks assume that means with all optional dependencies embedded 
like ivy, commons-cli, junit etc. I am not saying that "standalone" is any 
worse than "all", just a point to keep in mind when picking names ...
Cheers, Paul.

On Thu, Nov 23, 2017 at 8:53 AM, MG <mg...@arscreat.com> wrote:

  
    
  
  
    I like groovy-standalone.jar as a name (clearer than "all"). 

    Alas changing names breaks all internet guides/posts/etc preceeding
    the name change, so one has to be careful with things like this...

    

    On 22.11.2017 23:33, Leonard Brünings
      wrote:

    
    
      
      If you are doing that then most likely you won't be using the
        module path either, so we could have groovy-standalone.jar,

        with a Automatic-Module-Name of
        "dont.use.this.jar.for.module.path" to make it really obvious on
        what the proper usage is.

      
      

      Am 22.11.2017 um 21:58 schrieb Paul
        King:

      
      
        The advantage with the fat jar is the convenience
          of being able to run Groovy without a dependency management
          system (Gradle/Maven). Java -jar with just the groovy-all jar
          is going to get you a long way. Then again, I bet most people
          who aren't using Gradle/Maven probably just download the
          distribution. So I see the groovy-all jar as a nice to have
          but not necessarily essential.
          

          
          Cheers, Paul.
        
        

          On Thu, Nov 23, 2017 at 5:22 AM,
            Leonard Brünings <groovy-...@bruenings-it.net>
            wrote:

            I agree
              with Cédric, that is also what I suggested before.

              

              With maven/gradle the usage of groovy-all is currently
              done out of convenience.

              

              I think most projects would work just as well, if
              groovy-all would be turned into an

              empty jar that just depends on the other jars.
              
                

                  

                  Am 22.11.2017 um 19:41 schrieb Jochen Theodorou:

                  
                    Of course you arr right, I am more worried about the
                    migration path in combination with the final result.

                    

                    On 22.11.2017 14:30, Cédric Champeau wrote:

                    
                      Said differently, if you depend on `groovy-all`,
                      it will _effectively_ bring groovy, groovy-json,
                      groovy-xml, groovy-...

                      

                      All of those can be proper modules (as long as we
                      fix the split packages). Then if someone else only
                      brings in `groovy` + `groovy-json`, there's no
                      conflict.

                      

                      2017-11-22 14:29 GMT+01:00 Cédric Champeau 
<cedric.champ...@gmail.com
                      <mailto:cedric.champ...@gmail.com>>:

                      

                          That's precisely what I'm saying: we don't
                      need a fat jar. We need a

                          _module_ (Maven/Gradle sense of a module),
                      which brings in the jars

                          of the individual modules (JPMS sense). So
                      there's no such think as

                          a fat jar anymore, we don't need it.

                      

                          2017-11-22 14:26 GMT+01:00 Jochen Theodorou
                      <blackd...@gmx.org

                          <mailto:blackd...@gmx.org>>:

                      

                      

                      

                              Am 22.11.2017 um 11:47 schrieb Cédric
                      Champeau:

                      

                                  What is the advantage of providing a
                      fat jar, if you can

                                  have a "virtual" dependency,
                      groovy-all, which brings all

                                  the others in? There used to be a
                      difference, but now it's

                                  not that clear.

                      

                      

                              How are you going to express dependencies
                      with automatic

                              modules? They are automatic, because they
                      lack the information a

                              proper module provides and part of that
                      information is the

                              dependencies afaik. JPMS != maven.

                      

                              If you want groovy-all to bring in all the
                      dependencies, then

                              basically it is an almost empty jar with
                      dependencies and the

                              dependencies are the real modules. the
                      fat-jar itself cannot

                              provide any packages those dependencies to
                      provide, otherwise

                              you have conflicts. The empty
                      groovy-all-approach is something

                              we could go for in maven too of course.
                      But its is not a fatjar

                              then ;)

                      

                              bye Jochen

                      

                      

                      

                    
                    

                  
                  

                
              
            
          
          

        
      
      

    
    

  



Reply via email to