+1 on the JMX + gradle properties. Is there any (seamless) way of
including the exact git hash? That would be extremely useful if users
need help debugging and happen to be on an unreleased build (say, off
trunk)

On Wed, Nov 12, 2014 at 09:34:35AM -0800, Gwen Shapira wrote:
> Actually, Jun suggested exposing this via JMX.
> 
> On Wed, Nov 12, 2014 at 9:31 AM, Gwen Shapira <gshap...@cloudera.com> wrote:
> 
> > Good question.
> >
> > The server will need to expose this in the protocol, so Kafka clients will
> > know what they are talking to.
> >
> > We may also want to expose this in the producer and consumer, so people
> > who use Kafka's built-in clients will know which version they have in the
> > environment.
> >
> >
> >
> > On Wed, Nov 12, 2014 at 9:09 AM, Mark Roberts <wiz...@gmail.com> wrote:
> >
> >> Just to be clear: this is going to be exposed via some Api the clients
> >> can call at startup?
> >>
> >>
> >> > On Nov 12, 2014, at 08:59, Guozhang Wang <wangg...@gmail.com> wrote:
> >> >
> >> > Sounds great, +1 on this.
> >> >
> >> >> On Tue, Nov 11, 2014 at 1:36 PM, Gwen Shapira <gshap...@cloudera.com>
> >> wrote:
> >> >>
> >> >> So it looks like we can use Gradle to add properties to manifest file
> >> and
> >> >> then use getResourceAsStream to read the file and parse it.
> >> >>
> >> >> The Gradle part would be something like:
> >> >> jar.manifest {
> >> >>            attributes('Implementation-Title': project.name,
> >> >>            'Implementation-Version': project.version,
> >> >>            'Built-By': System.getProperty('user.name'),
> >> >>            'Built-JDK': System.getProperty('java.version'),
> >> >>            'Built-Host': getHostname(),
> >> >>            'Source-Compatibility': project.sourceCompatibility,
> >> >>            'Target-Compatibility': project.targetCompatibility
> >> >>            )
> >> >>        }
> >> >>
> >> >> The code part would be:
> >> >>
> >> >>
> >> this.getClass().getClassLoader().getResourceAsStream("/META-INF/MANIFEST.MF")
> >> >>
> >> >> Does that look like the right approach?
> >> >>
> >> >> Gwen
> >> >>
> >> >> On Tue, Nov 11, 2014 at 10:43 AM, Bhavesh Mistry <
> >> >> mistry.p.bhav...@gmail.com
> >> >>> wrote:
> >> >>
> >> >>> If is maven artifact then you will get following pre-build property
> >> file
> >> >>> from maven build called pom.properties under
> >> >>> /META-INF/maven/groupid/artifactId/pom.properties folder.
> >> >>>
> >> >>> Here is sample:
> >> >>> #Generated by Maven
> >> >>> #Mon Oct 10 10:44:31 EDT 2011
> >> >>> version=10.0.1
> >> >>> groupId=com.google.guava
> >> >>> artifactId=guava
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> Bhavesh
> >> >>>
> >> >>> On Tue, Nov 11, 2014 at 10:34 AM, Gwen Shapira <gshap...@cloudera.com
> >> >
> >> >>> wrote:
> >> >>>
> >> >>>> In Sqoop we do the following:
> >> >>>>
> >> >>>> Maven runs a shell script, passing the version as a parameter.
> >> >>>> The shell-script generates a small java class, which is then built
> >> >> with a
> >> >>>> Maven plugin.
> >> >>>> Our code references this generated class when we expose
> >> "getVersion()".
> >> >>>>
> >> >>>> Its complex and ugly, so I'm kind of hoping that there's a better way
> >> >> to
> >> >>> do
> >> >>>> it :)
> >> >>>>
> >> >>>> Gwen
> >> >>>>
> >> >>>>> On Tue, Nov 11, 2014 at 9:42 AM, Jun Rao <jun...@gmail.com> wrote:
> >> >>>>>
> >> >>>>> Currently, the version number is only stored in our build config
> >> >> file,
> >> >>>>> gradle.properties. Not sure how we can automatically extract it and
> >> >>>> expose
> >> >>>>> it in an mbean. How do other projects do this?
> >> >>>>>
> >> >>>>> Thanks,
> >> >>>>>
> >> >>>>> Jun
> >> >>>>>
> >> >>>>> On Tue, Nov 11, 2014 at 7:05 AM, Otis Gospodnetic <
> >> >>>>> otis.gospodne...@gmail.com> wrote:
> >> >>>>>
> >> >>>>>> Hi Jun,
> >> >>>>>>
> >> >>>>>> Sounds good.  But is the version number stored anywhere from where
> >> >> it
> >> >>>>> could
> >> >>>>>> be gotten?
> >> >>>>>>
> >> >>>>>> Thanks,
> >> >>>>>> Otis
> >> >>>>>> --
> >> >>>>>> Monitoring * Alerting * Anomaly Detection * Centralized Log
> >> >>> Management
> >> >>>>>> Solr & Elasticsearch Support * http://sematext.com/
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On Tue, Nov 11, 2014 at 12:45 AM, Jun Rao <jun...@gmail.com>
> >> >> wrote:
> >> >>>>>>
> >> >>>>>>> Otis,
> >> >>>>>>>
> >> >>>>>>> We don't have an api for that now. We can probably expose this
> >> >> as a
> >> >>>> JMX
> >> >>>>>> as
> >> >>>>>>> part of kafka-1481.
> >> >>>>>>>
> >> >>>>>>> Thanks,
> >> >>>>>>>
> >> >>>>>>> Jun
> >> >>>>>>>
> >> >>>>>>> On Mon, Nov 10, 2014 at 7:17 PM, Otis Gospodnetic <
> >> >>>>>>> otis.gospodne...@gmail.com> wrote:
> >> >>>>>>>
> >> >>>>>>>> Hi,
> >> >>>>>>>>
> >> >>>>>>>> Is there a way to detect which version of Kafka one is running?
> >> >>>>>>>> Is there an API for that, or a constant with this value, or
> >> >> maybe
> >> >>>> an
> >> >>>>>>> MBean
> >> >>>>>>>> or some other way to get to this info?
> >> >>>>>>>>
> >> >>>>>>>> Thanks,
> >> >>>>>>>> Otis
> >> >>>>>>>> --
> >> >>>>>>>> Monitoring * Alerting * Anomaly Detection * Centralized Log
> >> >>>>> Management
> >> >>>>>>>> Solr & Elasticsearch Support * http://sematext.com/
> >> >
> >> >
> >> >
> >> > --
> >> > -- Guozhang
> >>
> >
> >

Reply via email to