Il 29/07/2015 13:52, Steve Amerige ha scritto:
Some issues that large enterprises typically face include that dynamic
tools that resolve dependencies are not permitted. There are many
reasons for this: everything from legal (third-party jars, including
version changes, must be approved), to ha
On 7/29/2015 1:41 AM, Jochen Theodorou wrote:
But Steve, I do have a question...
Normally the things you describe are part of the installation process
as well as making a package for the system installation. That means
normally you want a system package. Installing software packages
manually i
This sounds like an anti-pattern to me to remove version names of the JARs.
In a distant past when we were storing version-less JAR files in CVS, it
was a real hell :-)
That's build tools responsibilities to bring in the right artifacts in the
build deliverables.
On Wed, Jul 29, 2015 at 7:41 AM,
Am 28.07.2015 14:26, schrieb Steve Amerige:
Hi all,
Every time we take a download of the latest Groovy software, we have to
do the same task: remove version numbers from file names. As of the
2.4.4 release, there are 39 files, shown below, that have the version
number as part of the distributio
The embeddable jars are covertly named ;-)
./embeddable/groovy-all-2.4.4-indy.jar
./embeddable/groovy-all-2.4.4.jar
They aren't used (as far as I know) by groovy_home and the intention of
those is to rip them out of the install and copy them around. That sets a
different bar for me for expected us
On 7/28/15 12:08 PM, Steve Amerige wrote:
Hi Henrik,
In most instances, version numbers aren't part of filenames. Consider
executables. For example, OS commands such as 'ls' aren't ls-1.1.
Scripts are written to depend on resources with constant naming. The
same applies to jar files. Cod
On 7/28/15 8:55 AM, Jeff Adamson wrote:
My non-contributor $0.02 would be exactly the opposite Henrik, for
very similar reasons.
I would agree that the embeddable jar should include version number by
default because that is supposed to be dropped around, but the rest of
the lib is already ve
Hi Henrik,
In most instances, version numbers aren't part of filenames. Consider
executables. For example, OS commands such as 'ls' aren't ls-1.1.
Scripts are written to depend on resources with constant naming. The
same applies to jar files. Code can be written to use standardized
filena
My non-contributor $0.02 would be exactly the opposite Henrik, for very
similar reasons.
I would agree that the embeddable jar should include version number by
default because that is supposed to be dropped around, but the rest of the
lib is already version locked to a groovy version. If someone i
The Tomcat example was the first thing that came to my mind. What is your
use case that makes this problematic? If symlinks are the main issue, why
not use your distribution's package manager instead?
-Keegan
On Tue, Jul 28, 2015 at 10:38 AM, Henrik Martin wrote:
> I'm not part of the contri
I'm not part of the contributor team, so I can't speak for the Groovy
team, but I would strongly disagree with you. If you use Maven or
Gradle, it's easy to maintain dependencies on particular versions of jar
files, and have your IDE immediately pick up the new version. In fact,
the default beh
Hi all,
Every time we take a download of the latest Groovy software, we have to
do the same task: remove version numbers from file names. As of the
2.4.4 release, there are 39 files, shown below, that have the version
number as part of the distribution. So, why is this a problem?
* IDEs c
12 matches
Mail list logo
