geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anthony Baker (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEODE-2743) Adjust gradle build of geode-examples JAR files
Date Fri, 31 Mar 2017 18:09:41 GMT

    [ https://issues.apache.org/jira/browse/GEODE-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15951412#comment-15951412
] 

Anthony Baker commented on GEODE-2743:
--------------------------------------

What geode jar are you referring to above?  If you are suggesting we should remove the version
from {{geode-core-1.1.0.jar}}, I don't think that is a good approach.

> Adjust gradle build of geode-examples JAR files
> -----------------------------------------------
>
>                 Key: GEODE-2743
>                 URL: https://issues.apache.org/jira/browse/GEODE-2743
>             Project: Geode
>          Issue Type: Improvement
>            Reporter: Karen Smoler Miller
>
> With a versioned build of geode-examples, the JAR file created for any specific example
(right now there are 2, replicated and partitioned) has a version number in its file name.
 This makes it difficult or impossible to write a robust shell script that must place that
JAR file on the classpath.  
> One idea floated was to just grab whatever JAR file was in the build/libs directory and
use it on the classpath.  That doesn't work if the developer running the examples has used
2 (or more) distinct version of Geode over time, such that there are 2 (or more) JAR files
in the build/libs directory.
> Another idea was to not use shell scripts to run the example.  Just inform the developer
how to form the correct gfsh commands.  This works, but it makes the examples more effort
for the developer, who can no longer copy/paste any of the commands from the README instructions
that explain how to run the example. I think it also hobbles a developer of further examples.
> Since the examples should be fairly independent of which version of Geode is actually
running, my proposed solution is for the build to not inject a Geode version number into the
name of the JAR file. That is what this ticket is meant to implement.
> Once this is done, both the replicated and partitioned examples will need to be revised,
since both have scripts that reference versioned files.  
> This will also decrease the effort of a release manager, since right now, to have a working
example, the release manager would need to update the geode-examples gradle.properties file
(this will always need to be done) and  the versioned file names that are embedded into an
example's scripts.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message