Re: [VOTE] Accept Apex into the Apache Incubator

[Amareshwari Sriramdasu]

+1 binding

On Thu, Aug 13, 2015 at 8:18 PM, P. Taylor Goetz  wrote:

> Following the discussion thread [1], I would like to call a VOTE for
> Accepting Apex as a new Apache Incubator project.
>
> The proposal is available on the wiki [2] and is also attached below.
>
> The VOTE will be open for at least 72 hours.
>
> [ ] +1 Accept Apex into the Incubator
> [ ] ±0 No opinion
> [ ] -1 Do not accept Apex into the Incubator because…
>
> Thanks,
>
> -Taylor
>
> [1] http://s.apache.org/apex_discuss
> [2] https://wiki.apache.org/incubator/ApexProposal
>
>
> == Abstract ==
> Apex is an enterprise grade native YARN big data-in-motion platform that
> unifies stream processing as well as batch processing. Apex processes big
> data in-motion in a highly scalable, highly performant, fault tolerant,
> stateful, secure, distributed, and an easily operable way. It provides a
> simple API that enables users to write or re-use generic Java code, thereby
> lowering the expertise needed to write big data applications.
>
> Functional and operational specifications are separated. Apex is designed
> in a way to enable users to write their own code (aka user defined
> functions) as is and leave all operability to the platform. The API is very
> simple and is designed to allow users to drop in their code as is. The
> platform mainly deals with operability and treats functional code as a
> black box. Operability includes fault tolerance, scalability, security,
> ease of use, metrics api, webservices, etc. In other words there is no
> separation of UDF (user defined functions), as all functional code is UDF.
> This frees users to focus on functional development, and lets platform
> provide operability support. The same code runs as is with different
> operability attributes. The data-in-motion architecture of Apex unifies
> stream as well as batch processing in a single platform. Since Apex is a
> native YARN application, it leverages all the components of YARN without
> duplication. Apex was developed with YARN in mind and has no overlapping
> components/functionality with YARN.
>
> The Apex platform is supplemented by project Malhar, which is a library of
> operators that implement common business logic functions needed by
> customers who want to quickly develop applications. These operators provide
> access to HDFS, S3, NFS, FTP, and other file systems;  Kafka, ActiveMQ,
> RabbitMQ, JMS, and other message systems; MySql, Cassandra, MongoDB, Redis,
> HBase, CouchDB and other databases along with JDBC connectors. The Malhar
> library also includes a host of other common business logic patterns that
> help users to significantly reduce the time it takes to go into production.
> Ease of integration with all other big data technologies is one of the
> primary missions of Malhar.
>
> == Proposal ==
> The goal of this proposal is to establish the core engine of DataTorrent
> RTS product as an Apache Software Foundation (ASF) project in order to
> build a vibrant, diverse, and self-governed open source community around
> the technology. DataTorrent will continue to sell management tools,
> application building tools, easy to use big data applications, and custom
> high end business logic operators. This proposal covers the Apex source
> code (written in Java), Apex documentation and other materials currently
> available on https://github.com/DataTorrent/Apex. This proposal also
> covers the Malhar source code (written in Java), Malhar documentation, and
> other materials currently available on
> https://github.com/DataTorrent/Malhar. We have done a trademark check on
> the name Apex, and have concluded that the Apex name is likely to be a
> suitable project name.
>
> == Background ==
> DataTorrent RTS is a mature and robust product developed as a native YARN
> application. RTS 1.0 was launched in summer of 2014; RTS 2.0 was launched
> in Jan 2015. Both were well received by customers. RTS 3.0 was launched at
> end of July 2015. RTS is among the first enterprise grade platform that was
> developed from the ground up as native YARN application. DataTorrent RTS is
> currently maintained by engineers as a closed source project. Even though
> the engineers behind RTS are experienced software engineers and are
> knowledge leaders in data-in-motion platforms, they have had little
> exposure to the open source governance process. Customers are currently
> running applications based on DataTorrent RTS in production.
>
> == Rationale ==
> Big data applications written for non-Hadoop platforms typically require
> major rewrites  to get them to work with Hadoop. This rewriting creates a
> significant bottleneck in terms of resources (expertise) which in turn
> jeopardizes the viability of such an endeavour. It is hard enough to
> acquire big data expertise, demanding additional expertise to do a major
> code conversion makes it a very hard problem for projects to successfully
> migrate to Hadoop. Also, due to the batch processing nature of Hadoop’s

Клuенmскuе базы Тeл +79IзЗ9IЗ8З7 Email: nonen2...@gmail.com Узнайmе поgробнeе!!!

[general]

Соберем gля Вас по uнmeрнеm базу qaнных 
пoтeнцuальных клиенmов qля Вaшero Бuзнеса!
По бaзe мoжно звoнить пucаmь слaть факcы и email, 
весmu любыe пpямыe akтивные проqaжu Bашиx moвapoв и уcлyr!
Узнaйтe подрoбнeе пo 
Тeл +79IзЗ9IЗ8З7
Email: nonen2...@gmail.com

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Apex into the Apache Incubator

[Roman Shaposhnik]

On Thu, Aug 13, 2015 at 7:48 AM, P. Taylor Goetz  wrote:
> Following the discussion thread [1], I would like to call a VOTE for
> Accepting Apex as a new Apache Incubator project.
>
> The proposal is available on the wiki [2] and is also attached below.
>
> The VOTE will be open for at least 72 hours.
>
> [ ] +1 Accept Apex into the Incubator
> [ ] ±0 No opinion
> [ ] -1 Do not accept Apex into the Incubator because…

+1 (binding)

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apex Incubation Proposal

[Niall Pemberton]

On Wed, Aug 12, 2015 at 3:55 AM, Amol Kekre  wrote:

> Niall,
> Thanks for catching. I replaced '-' with '_' as per atlassian policy. I am
> suspecting that ASF does not allow '_' as none of the project keys have
> '_'. I have added a comment that '_' can be removed if that is the policy.
> Wiki updated.
>

I asked on the infra list what the JIRA key format was and whether it could
be changed to include underscore and got the following response:

"They are all uppercase alpha characters. Sadly it cannot be changed."

Niall



>
> Thks,
> Amol
>
>
> On Tue, Aug 11, 2015 at 7:46 PM, Niall Pemberton <
> niall.pember...@gmail.com>
> wrote:
>
> > On Wed, Aug 12, 2015 at 2:08 AM, Amol Kekre 
> wrote:
> >
> > > oh! We preferred that during our discussion. Somehow we thought there
> > was a
> > > limit. I have changed it to full names (APEX-CORE, APEX-MALHAR). If
> there
> > > is a limit we can reduce the number of chars later. wiki is updated.
> > >
> > > https://wiki.apache.org/incubator/ApexProposal
> > >
> >
> > Hyphens are not allowed as project keys, but underscore is a possibility.
> > The default format is only upper case letters - but you'll need to check
> > what ASF has configured.
> >
> >
> >
> https://confluence.atlassian.com/display/JIRA/Changing+the+Project+Key+Format
> >
> > Niall
> >
> >
> > Thks,
> > > Amol
> > >
> > >
> > > On Tue, Aug 11, 2015 at 1:44 PM, Hitesh Shah 
> wrote:
> > >
> > > > If there isn’t a char limit on project names in JIRA, wouldn’t it
> just
> > be
> > > > better to use “APEX-CORE” and “APEX-MALHAR” to match the actual
> project
> > > > names, repos, etc?
> > > >
> > > > thanks
> > > > — Hitesh
> > > >
> > > > On Aug 11, 2015, at 1:25 PM, Amol Kekre 
> wrote:
> > > >
> > > > > Chris,
> > > > > Thanks for articulating what I was going to respond with after
> > talking
> > > to
> > > > > folks here. We indeed see versions for Malhar and Apex differing.
> We
> > > > expect
> > > > > Malhar versions to change much more rapidly than Apex.
> > > > >
> > > > > Ted,
> > > > > We discussed the impact of single jira on versioning.  For example
> we
> > > > > expect Malhar X.0.0 to happen much earlier than Apex X.0.0. There
> was
> > > > > discomfort in naming versions with prefix. The consensus was to
> have
> > > > > version numbers convey stuff. If folks don't have strong opinion on
> > two
> > > > > jiras, we would prefer to use two jiras. We have taken up
> Bertrand's
> > > > scope
> > > > > naming and changed the names of jira projects as follows
> > > > >
> > > > > APX-CORE
> > > > > APX-MLHR
> > > > >
> > > > > I have changed the wiki to reflect the above as jira project names.
> > > > >
> > > > > Thks,
> > > > > Amol
> > > > >
> > > > >
> > > > > On Tue, Aug 11, 2015 at 10:03 AM, Chris Nauroth <
> > > > cnaur...@hortonworks.com>
> > > > > wrote:
> > > > >
> > > > >> One thing to consider is that release version numbers are tied to
> > > > specific
> > > > >> JIRA projects.  If the intention is for Apex and Malhar version
> > > numbers
> > > > to
> > > > >> be independent, then using a single JIRA project could introduce
> > some
> > > > risk
> > > > >> of confusion if an Apex version number accidentally gets applied
> to
> > a
> > > > >> Malhar issue.  It might necessitate prefixing the version numbers
> > with
> > > > >> "apex-" and "malhar-" to differentiate.
> > > > >>
> > > > >> Based on that, I have a slight preference for separate JIRA
> > projects.
> > > > >> However, I don't object to using a single unified JIRA project if
> > > others
> > > > >> feel strongly about it.
> > > > >>
> > > > >> --Chris Nauroth
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On 8/11/15, 8:23 AM, "Amol Kekre"  wrote:
> > > > >>
> > > > >>> Ted,
> > > > >>> I agree that repo is more critical than jira instance. I am
> taking
> > up
> > > > your
> > > > >>> suggesstion with folks and should get back soon.
> > > > >>>
> > > > >>> Thks
> > > > >>> Amol
> > > > >>>
> > > > >>> On Tue, Aug 11, 2015 at 3:48 AM, Ted Dunning <
> > ted.dunn...@gmail.com>
> > > > >>> wrote:
> > > > >>>
> > > > 
> > > >  I personally see far less reason for separate JIRA instances
> than
> > > git
> > > >  repos. Having all jiras under APEX seems a good choice.
> > > > 
> > > >  Sent from my iPhone
> > > > 
> > > > > On Aug 11, 2015, at 2:32, Bertrand Delacretaz <
> > > > bdelacre...@apache.org
> > > > >>>
> > > >  wrote:
> > > > >
> > > > > As for JIRA, I would apply the same rule, so APX-CORE and
> > APX-MHAR
> > > >  maybe.
> > > > 
> > > > 
> > > -
> > > >  To unsubscribe, e-mail:
> general-unsubscr...@incubator.apache.org
> > > >  For additional commands, e-mail:
> > general-h...@incubator.apache.org
> > > > 
> > > > 
> > > > >>
> > > > >>
> > > > >>
> > -
> > > > >> To unsubscribe, e-mail: general-unsubsc

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

Niall,
Thanks for following up and resolving the ask. We will remove '_' from the
keys.

Thks,
Amol


On Fri, Aug 14, 2015 at 1:03 PM, Niall Pemberton 
wrote:

> On Wed, Aug 12, 2015 at 3:55 AM, Amol Kekre  wrote:
>
> > Niall,
> > Thanks for catching. I replaced '-' with '_' as per atlassian policy. I
> am
> > suspecting that ASF does not allow '_' as none of the project keys have
> > '_'. I have added a comment that '_' can be removed if that is the
> policy.
> > Wiki updated.
> >
>
> I asked on the infra list what the JIRA key format was and whether it could
> be changed to include underscore and got the following response:
>
> "They are all uppercase alpha characters. Sadly it cannot be changed."
>
> Niall
>
>
>
> >
> > Thks,
> > Amol
> >
> >
> > On Tue, Aug 11, 2015 at 7:46 PM, Niall Pemberton <
> > niall.pember...@gmail.com>
> > wrote:
> >
> > > On Wed, Aug 12, 2015 at 2:08 AM, Amol Kekre 
> > wrote:
> > >
> > > > oh! We preferred that during our discussion. Somehow we thought there
> > > was a
> > > > limit. I have changed it to full names (APEX-CORE, APEX-MALHAR). If
> > there
> > > > is a limit we can reduce the number of chars later. wiki is updated.
> > > >
> > > > https://wiki.apache.org/incubator/ApexProposal
> > > >
> > >
> > > Hyphens are not allowed as project keys, but underscore is a
> possibility.
> > > The default format is only upper case letters - but you'll need to
> check
> > > what ASF has configured.
> > >
> > >
> > >
> >
> https://confluence.atlassian.com/display/JIRA/Changing+the+Project+Key+Format
> > >
> > > Niall
> > >
> > >
> > > Thks,
> > > > Amol
> > > >
> > > >
> > > > On Tue, Aug 11, 2015 at 1:44 PM, Hitesh Shah 
> > wrote:
> > > >
> > > > > If there isn’t a char limit on project names in JIRA, wouldn’t it
> > just
> > > be
> > > > > better to use “APEX-CORE” and “APEX-MALHAR” to match the actual
> > project
> > > > > names, repos, etc?
> > > > >
> > > > > thanks
> > > > > — Hitesh
> > > > >
> > > > > On Aug 11, 2015, at 1:25 PM, Amol Kekre 
> > wrote:
> > > > >
> > > > > > Chris,
> > > > > > Thanks for articulating what I was going to respond with after
> > > talking
> > > > to
> > > > > > folks here. We indeed see versions for Malhar and Apex differing.
> > We
> > > > > expect
> > > > > > Malhar versions to change much more rapidly than Apex.
> > > > > >
> > > > > > Ted,
> > > > > > We discussed the impact of single jira on versioning.  For
> example
> > we
> > > > > > expect Malhar X.0.0 to happen much earlier than Apex X.0.0. There
> > was
> > > > > > discomfort in naming versions with prefix. The consensus was to
> > have
> > > > > > version numbers convey stuff. If folks don't have strong opinion
> on
> > > two
> > > > > > jiras, we would prefer to use two jiras. We have taken up
> > Bertrand's
> > > > > scope
> > > > > > naming and changed the names of jira projects as follows
> > > > > >
> > > > > > APX-CORE
> > > > > > APX-MLHR
> > > > > >
> > > > > > I have changed the wiki to reflect the above as jira project
> names.
> > > > > >
> > > > > > Thks,
> > > > > > Amol
> > > > > >
> > > > > >
> > > > > > On Tue, Aug 11, 2015 at 10:03 AM, Chris Nauroth <
> > > > > cnaur...@hortonworks.com>
> > > > > > wrote:
> > > > > >
> > > > > >> One thing to consider is that release version numbers are tied
> to
> > > > > specific
> > > > > >> JIRA projects.  If the intention is for Apex and Malhar version
> > > > numbers
> > > > > to
> > > > > >> be independent, then using a single JIRA project could introduce
> > > some
> > > > > risk
> > > > > >> of confusion if an Apex version number accidentally gets applied
> > to
> > > a
> > > > > >> Malhar issue.  It might necessitate prefixing the version
> numbers
> > > with
> > > > > >> "apex-" and "malhar-" to differentiate.
> > > > > >>
> > > > > >> Based on that, I have a slight preference for separate JIRA
> > > projects.
> > > > > >> However, I don't object to using a single unified JIRA project
> if
> > > > others
> > > > > >> feel strongly about it.
> > > > > >>
> > > > > >> --Chris Nauroth
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On 8/11/15, 8:23 AM, "Amol Kekre"  wrote:
> > > > > >>
> > > > > >>> Ted,
> > > > > >>> I agree that repo is more critical than jira instance. I am
> > taking
> > > up
> > > > > your
> > > > > >>> suggesstion with folks and should get back soon.
> > > > > >>>
> > > > > >>> Thks
> > > > > >>> Amol
> > > > > >>>
> > > > > >>> On Tue, Aug 11, 2015 at 3:48 AM, Ted Dunning <
> > > ted.dunn...@gmail.com>
> > > > > >>> wrote:
> > > > > >>>
> > > > > 
> > > > >  I personally see far less reason for separate JIRA instances
> > than
> > > > git
> > > > >  repos. Having all jiras under APEX seems a good choice.
> > > > > 
> > > > >  Sent from my iPhone
> > > > > 
> > > > > > On Aug 11, 2015, at 2:32, Bertrand Delacretaz <
> > > > > bdelacre...@apache.org
> > > > > >>>
> > > > >  wrote:
> > > > > >
> > > > > > As for JIRA, I would apply the same rule,

Re: [VOTE] Accept Apex into the Apache Incubator

[Niall Pemberton]

+1

Niall

On Thu, Aug 13, 2015 at 3:48 PM, P. Taylor Goetz  wrote:

> Following the discussion thread [1], I would like to call a VOTE for
> Accepting Apex as a new Apache Incubator project.
>
> The proposal is available on the wiki [2] and is also attached below.
>
> The VOTE will be open for at least 72 hours.
>
> [ ] +1 Accept Apex into the Incubator
> [ ] ±0 No opinion
> [ ] -1 Do not accept Apex into the Incubator because…
>
> Thanks,
>
> -Taylor
>
> [1] http://s.apache.org/apex_discuss
> [2] https://wiki.apache.org/incubator/ApexProposal
>
>
> == Abstract ==
> Apex is an enterprise grade native YARN big data-in-motion platform that
> unifies stream processing as well as batch processing. Apex processes big
> data in-motion in a highly scalable, highly performant, fault tolerant,
> stateful, secure, distributed, and an easily operable way. It provides a
> simple API that enables users to write or re-use generic Java code, thereby
> lowering the expertise needed to write big data applications.
>
> Functional and operational specifications are separated. Apex is designed
> in a way to enable users to write their own code (aka user defined
> functions) as is and leave all operability to the platform. The API is very
> simple and is designed to allow users to drop in their code as is. The
> platform mainly deals with operability and treats functional code as a
> black box. Operability includes fault tolerance, scalability, security,
> ease of use, metrics api, webservices, etc. In other words there is no
> separation of UDF (user defined functions), as all functional code is UDF.
> This frees users to focus on functional development, and lets platform
> provide operability support. The same code runs as is with different
> operability attributes. The data-in-motion architecture of Apex unifies
> stream as well as batch processing in a single platform. Since Apex is a
> native YARN application, it leverages all the components of YARN without
> duplication. Apex was developed with YARN in mind and has no overlapping
> components/functionality with YARN.
>
> The Apex platform is supplemented by project Malhar, which is a library of
> operators that implement common business logic functions needed by
> customers who want to quickly develop applications. These operators provide
> access to HDFS, S3, NFS, FTP, and other file systems;  Kafka, ActiveMQ,
> RabbitMQ, JMS, and other message systems; MySql, Cassandra, MongoDB, Redis,
> HBase, CouchDB and other databases along with JDBC connectors. The Malhar
> library also includes a host of other common business logic patterns that
> help users to significantly reduce the time it takes to go into production.
> Ease of integration with all other big data technologies is one of the
> primary missions of Malhar.
>
> == Proposal ==
> The goal of this proposal is to establish the core engine of DataTorrent
> RTS product as an Apache Software Foundation (ASF) project in order to
> build a vibrant, diverse, and self-governed open source community around
> the technology. DataTorrent will continue to sell management tools,
> application building tools, easy to use big data applications, and custom
> high end business logic operators. This proposal covers the Apex source
> code (written in Java), Apex documentation and other materials currently
> available on https://github.com/DataTorrent/Apex. This proposal also
> covers the Malhar source code (written in Java), Malhar documentation, and
> other materials currently available on
> https://github.com/DataTorrent/Malhar. We have done a trademark check on
> the name Apex, and have concluded that the Apex name is likely to be a
> suitable project name.
>
> == Background ==
> DataTorrent RTS is a mature and robust product developed as a native YARN
> application. RTS 1.0 was launched in summer of 2014; RTS 2.0 was launched
> in Jan 2015. Both were well received by customers. RTS 3.0 was launched at
> end of July 2015. RTS is among the first enterprise grade platform that was
> developed from the ground up as native YARN application. DataTorrent RTS is
> currently maintained by engineers as a closed source project. Even though
> the engineers behind RTS are experienced software engineers and are
> knowledge leaders in data-in-motion platforms, they have had little
> exposure to the open source governance process. Customers are currently
> running applications based on DataTorrent RTS in production.
>
> == Rationale ==
> Big data applications written for non-Hadoop platforms typically require
> major rewrites  to get them to work with Hadoop. This rewriting creates a
> significant bottleneck in terms of resources (expertise) which in turn
> jeopardizes the viability of such an endeavour. It is hard enough to
> acquire big data expertise, demanding additional expertise to do a major
> code conversion makes it a very hard problem for projects to successfully
> migrate to Hadoop. Also, due to the batch processing nature of Hadoop’s

Re: [DISCUSS] Apex Incubation Proposal

[P. Taylor Goetz]

Amol,

I don't think there's a need to update the proposal for this, it's an 
implementation detail that can be dealt with upon entry. The proposal should be 
treated as immutable while the vote is underway (which is why proposals are 
always attached to the VOTE -- so people know exactly what they are voting on).

In the (seemingly unlikely) event that the vote doesn't pass, the proposal can 
be revisited.

Just an FYI...

-Taylor

> On Aug 14, 2015, at 4:49 PM, Amol Kekre  wrote:
> 
> Niall,
> Thanks for following up and resolving the ask. We will remove '_' from the
> keys.
> 
> Thks,
> Amol
> 
> 
> On Fri, Aug 14, 2015 at 1:03 PM, Niall Pemberton 
> wrote:
> 
>>> On Wed, Aug 12, 2015 at 3:55 AM, Amol Kekre  wrote:
>>> 
>>> Niall,
>>> Thanks for catching. I replaced '-' with '_' as per atlassian policy. I
>> am
>>> suspecting that ASF does not allow '_' as none of the project keys have
>>> '_'. I have added a comment that '_' can be removed if that is the
>> policy.
>>> Wiki updated.
>>> 
>> 
>> I asked on the infra list what the JIRA key format was and whether it could
>> be changed to include underscore and got the following response:
>> 
>> "They are all uppercase alpha characters. Sadly it cannot be changed."
>> 
>> Niall
>> 
>> 
>> 
>>> 
>>> Thks,
>>> Amol
>>> 
>>> 
>>> On Tue, Aug 11, 2015 at 7:46 PM, Niall Pemberton <
>>> niall.pember...@gmail.com>
>>> wrote:
>>> 
 On Wed, Aug 12, 2015 at 2:08 AM, Amol Kekre 
>>> wrote:
 
> oh! We preferred that during our discussion. Somehow we thought there
 was a
> limit. I have changed it to full names (APEX-CORE, APEX-MALHAR). If
>>> there
> is a limit we can reduce the number of chars later. wiki is updated.
> 
> https://wiki.apache.org/incubator/ApexProposal
> 
 
 Hyphens are not allowed as project keys, but underscore is a
>> possibility.
 The default format is only upper case letters - but you'll need to
>> check
 what ASF has configured.
 
 
 
>>> 
>> https://confluence.atlassian.com/display/JIRA/Changing+the+Project+Key+Format
 
 Niall
 
 
 Thks,
> Amol
> 
> 
> On Tue, Aug 11, 2015 at 1:44 PM, Hitesh Shah 
>>> wrote:
> 
>> If there isn’t a char limit on project names in JIRA, wouldn’t it
>>> just
 be
>> better to use “APEX-CORE” and “APEX-MALHAR” to match the actual
>>> project
>> names, repos, etc?
>> 
>> thanks
>> — Hitesh
>> 
>> On Aug 11, 2015, at 1:25 PM, Amol Kekre 
>>> wrote:
>> 
>>> Chris,
>>> Thanks for articulating what I was going to respond with after
 talking
> to
>>> folks here. We indeed see versions for Malhar and Apex differing.
>>> We
>> expect
>>> Malhar versions to change much more rapidly than Apex.
>>> 
>>> Ted,
>>> We discussed the impact of single jira on versioning.  For
>> example
>>> we
>>> expect Malhar X.0.0 to happen much earlier than Apex X.0.0. There
>>> was
>>> discomfort in naming versions with prefix. The consensus was to
>>> have
>>> version numbers convey stuff. If folks don't have strong opinion
>> on
 two
>>> jiras, we would prefer to use two jiras. We have taken up
>>> Bertrand's
>> scope
>>> naming and changed the names of jira projects as follows
>>> 
>>> APX-CORE
>>> APX-MLHR
>>> 
>>> I have changed the wiki to reflect the above as jira project
>> names.
>>> 
>>> Thks,
>>> Amol
>>> 
>>> 
>>> On Tue, Aug 11, 2015 at 10:03 AM, Chris Nauroth <
>> cnaur...@hortonworks.com>
>>> wrote:
>>> 
 One thing to consider is that release version numbers are tied
>> to
>> specific
 JIRA projects.  If the intention is for Apex and Malhar version
> numbers
>> to
 be independent, then using a single JIRA project could introduce
 some
>> risk
 of confusion if an Apex version number accidentally gets applied
>>> to
 a
 Malhar issue.  It might necessitate prefixing the version
>> numbers
 with
 "apex-" and "malhar-" to differentiate.
 
 Based on that, I have a slight preference for separate JIRA
 projects.
 However, I don't object to using a single unified JIRA project
>> if
> others
 feel strongly about it.
 
 --Chris Nauroth
 
 
 
 
> On 8/11/15, 8:23 AM, "Amol Kekre"  wrote:
> 
> Ted,
> I agree that repo is more critical than jira instance. I am
>>> taking
 up
>> your
> suggesstion with folks and should get back soon.
> 
> Thks
> Amol
> 
> On Tue, Aug 11, 2015 at 3:48 AM, Ted Dunning <
 ted.dunn...@gmail.com>
> wrote:
> 
>> 
>> I personally see far less reason for separate JIRA instances
>>> than
> git
>> repos. Having all jiras under APEX seems a good choice.
>> 

Re: What is the legal basis for enforcing release policies at ASF?

[Shane Curcuru]

On 8/7/15 7:53 AM, Niclas Hedhman wrote:
> Bill,
> So I can release "Niclas Hadoop platform, based on Apache Hadoop" ?? I
> thought the discussion a few years ago was that this was misleading...

No, you cannot.  See our actual trademark policy:

  https://www.apache.org/foundation/marks/faq/#products

Our release policy, as Roman originally asked about, applies only to ASF
projects, and has no bearing on third parties.  However our trademark
policy, and trademark law, prevents third parties from publicly
providing software using our trademarks.

Our operational policies only apply to our projects, just like any other
corporation.  Some policies, like our license itself and our formal
trademark policy, inform the rest of the world how they are allowed to
use our websites, software code, and brands.

Make sense?

- Shane


> 
> 
> 
> On Fri, Aug 7, 2015 at 12:30 PM, William A Rowe Jr 
> wrote:
> 
>> On Thu, Aug 6, 2015 at 7:50 PM, Roman Shaposhnik 
>> wrote:
>>
>>> Hi!
>>>
>>> while answering a question on release policies and ALv2
>>> I've suddenly realized that I really don't know what is the
>>> legal basis for enforcing release policies we've got
>>> documented over here:
>>>http://www.apache.org/dev/release.html
>>>
>>> For example, what would be the legal basis for stopping
>>> a 3d party from releasing a snapshot of ASF's project
>>> source tree and claim it to be a release X.Y.Z of said
>>> project?
>>>
>>
>> Nothing other than the Trademarks.
>>
>> If someone wants to call httpd trunk 3.0.1-GA, they cannot do this as
>> "Apache httpd 3.0.1-GA" or "Apache HTTP Server 3.0.1-GA".
>>
>> They can certainly release trunk under the AL license and call it "Kindred
>> Http Server 3.0.1-GA, based on Apache HTTP Server". That is a statement of
>> fact and not an abuse of the mark, IMHO. (If it was not actually based on
>> Apache HTTP Server, then that would similarly be a Trademark infringement
>> as it is a false use of the mark.)
>>
>> There are no less than two marks, one is the name of the foundation itself
>> in conjunction with Open Source Software, and the other is the specific
>> project name.
>>
> 
> 
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

Taylor,
Got it. I am learning incubation nuances :)

Thks,
Amol


On Fri, Aug 14, 2015 at 2:11 PM, P. Taylor Goetz  wrote:

> Amol,
>
> I don't think there's a need to update the proposal for this, it's an
> implementation detail that can be dealt with upon entry. The proposal
> should be treated as immutable while the vote is underway (which is why
> proposals are always attached to the VOTE -- so people know exactly what
> they are voting on).
>
> In the (seemingly unlikely) event that the vote doesn't pass, the proposal
> can be revisited.
>
> Just an FYI...
>
> -Taylor
>
> > On Aug 14, 2015, at 4:49 PM, Amol Kekre  wrote:
> >
> > Niall,
> > Thanks for following up and resolving the ask. We will remove '_' from
> the
> > keys.
> >
> > Thks,
> > Amol
> >
> >
> > On Fri, Aug 14, 2015 at 1:03 PM, Niall Pemberton <
> niall.pember...@gmail.com>
> > wrote:
> >
> >>> On Wed, Aug 12, 2015 at 3:55 AM, Amol Kekre 
> wrote:
> >>>
> >>> Niall,
> >>> Thanks for catching. I replaced '-' with '_' as per atlassian policy. I
> >> am
> >>> suspecting that ASF does not allow '_' as none of the project keys have
> >>> '_'. I have added a comment that '_' can be removed if that is the
> >> policy.
> >>> Wiki updated.
> >>>
> >>
> >> I asked on the infra list what the JIRA key format was and whether it
> could
> >> be changed to include underscore and got the following response:
> >>
> >> "They are all uppercase alpha characters. Sadly it cannot be changed."
> >>
> >> Niall
> >>
> >>
> >>
> >>>
> >>> Thks,
> >>> Amol
> >>>
> >>>
> >>> On Tue, Aug 11, 2015 at 7:46 PM, Niall Pemberton <
> >>> niall.pember...@gmail.com>
> >>> wrote:
> >>>
>  On Wed, Aug 12, 2015 at 2:08 AM, Amol Kekre 
> >>> wrote:
> 
> > oh! We preferred that during our discussion. Somehow we thought there
>  was a
> > limit. I have changed it to full names (APEX-CORE, APEX-MALHAR). If
> >>> there
> > is a limit we can reduce the number of chars later. wiki is updated.
> >
> > https://wiki.apache.org/incubator/ApexProposal
> >
> 
>  Hyphens are not allowed as project keys, but underscore is a
> >> possibility.
>  The default format is only upper case letters - but you'll need to
> >> check
>  what ASF has configured.
> 
> 
> 
> >>>
> >>
> https://confluence.atlassian.com/display/JIRA/Changing+the+Project+Key+Format
> 
>  Niall
> 
> 
>  Thks,
> > Amol
> >
> >
> > On Tue, Aug 11, 2015 at 1:44 PM, Hitesh Shah 
> >>> wrote:
> >
> >> If there isn’t a char limit on project names in JIRA, wouldn’t it
> >>> just
>  be
> >> better to use “APEX-CORE” and “APEX-MALHAR” to match the actual
> >>> project
> >> names, repos, etc?
> >>
> >> thanks
> >> — Hitesh
> >>
> >> On Aug 11, 2015, at 1:25 PM, Amol Kekre 
> >>> wrote:
> >>
> >>> Chris,
> >>> Thanks for articulating what I was going to respond with after
>  talking
> > to
> >>> folks here. We indeed see versions for Malhar and Apex differing.
> >>> We
> >> expect
> >>> Malhar versions to change much more rapidly than Apex.
> >>>
> >>> Ted,
> >>> We discussed the impact of single jira on versioning.  For
> >> example
> >>> we
> >>> expect Malhar X.0.0 to happen much earlier than Apex X.0.0. There
> >>> was
> >>> discomfort in naming versions with prefix. The consensus was to
> >>> have
> >>> version numbers convey stuff. If folks don't have strong opinion
> >> on
>  two
> >>> jiras, we would prefer to use two jiras. We have taken up
> >>> Bertrand's
> >> scope
> >>> naming and changed the names of jira projects as follows
> >>>
> >>> APX-CORE
> >>> APX-MLHR
> >>>
> >>> I have changed the wiki to reflect the above as jira project
> >> names.
> >>>
> >>> Thks,
> >>> Amol
> >>>
> >>>
> >>> On Tue, Aug 11, 2015 at 10:03 AM, Chris Nauroth <
> >> cnaur...@hortonworks.com>
> >>> wrote:
> >>>
>  One thing to consider is that release version numbers are tied
> >> to
> >> specific
>  JIRA projects.  If the intention is for Apex and Malhar version
> > numbers
> >> to
>  be independent, then using a single JIRA project could introduce
>  some
> >> risk
>  of confusion if an Apex version number accidentally gets applied
> >>> to
>  a
>  Malhar issue.  It might necessitate prefixing the version
> >> numbers
>  with
>  "apex-" and "malhar-" to differentiate.
> 
>  Based on that, I have a slight preference for separate JIRA
>  projects.
>  However, I don't object to using a single unified JIRA project
> >> if
> > others
>  feel strongly about it.
> 
>  --Chris Nauroth
> 
> 
> 
> 
> > On 8/11/15, 8:23 AM, "Amol Kekre"  wrote:
> >
> > Ted,
> > I agree that repo is more critical than j

Re: apache binary distributions

[Shane Curcuru]

On 8/6/15 4:29 AM, Jochen Theodorou wrote:
> Am 06.08.2015 08:22, schrieb Niclas Hedhman:
>> On Thu, Aug 6, 2015 at 8:43 AM, Roman Shaposhnik 
>> wrote:
>>
>>> I honestly see no problem with that, again provided that the artifact
>>> can
>> NOT
>>> be confused with the one coming from Apache project.
>>
>> I think the "problem" lies in Trademarks. Debian's Tomcat7 is labeled
>> "Servlet and JSP engine" and its Tomcat8 is labeled "Apache Tomcat 8 -
>> Servlet and JSP engine", yet I don't see Apache Tomcat project
>> creating/maintaining a Debian dist.
>>
>> Now, is Debian allowed to call it "Tomcat"? Is it allowed to call Tomcat8
>> to BE "Apache Tomcat8", when in fact(!) there are changes to the source,
>> such as the start script in Debian Tomcat is not original of Apache
>> Tomcat,
>> but instead follows a Debian template for how those scripts should be
>> written. I am not sure what all the changes are, feel free to check;
>> http://anonscm.debian.org/cgit/pkg-java/tomcat8.git/tree/debian/patches
>>
>> IF (like Mozilla) Apache decides to strike down on Debian and not
>> allowing
>> it to use the same names, _I_ think it is a disservice to the users
>> (IceWeasel browser), but as it stands, Apache trademark licensing
>> seems to
>> not really be followed (Perhaps Debian has some permission that was
>> granted
>> long in the past... I may have missed that).
> 
> I think there is nothing in the apache license 2 forbidding the usage of
> the project name or even apache (version 1.1 and 1 have been different
> and did indeed require a permission). The trademark weapon is more one
> of last resort. For example to go against false releases with malicious
> code added and the distributor not willing to take it of the web.

Have folks here read the license recently?

"6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file."

  https://www.apache.org/licenses/LICENSE-2.0.html#trademarks

So our license explicitly excludes any Apache trademarks (i.e. APACHE
and the names of all of our projects, among other things) from any of
the other grants the license makes.  Beyond that, trademark law (which
varies in different countries) applies when anyone is using one of our
trademarks in association with a software product or other related
product or service that they provide *publicly*.

Employees in a $BigCo could call an internal release "Best Apache Foo",
and we likely couldn't legally do anything about it (although we'd
certainly not be happy about it, and if we found out should ask them to
change it).  But when some other company or individual releases
"Something Apache Foo" publicly that we can - and should! - complain and
ensure that they're following our published trademark policy:

  https://www.apache.org/foundation/marks/faq/#products

Having specific examples to discuss is a much better idea.  It's very
important both 1) what, specifically, the thing is that's being provided
(download, maven repo, whatever), 2) what an end user would perceive the
branding of that thing to be, and 3) who - what specific person or
organization - is providing that thing.

- Shane





> 
> At least I hope no-one has some crazy idea as that ;)
> 
> bye blackdrag
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Apache Tamaya Release 0.1-incubating

[Anatole Tresch]

Dear Incubator

after the Apache Tamaya PPMC vote passed successfully with 5+ votes for the
first release "0.1-incubating" of Apache Tamaya, it's now the incubator's
task to vote ;)

Please see original [VOTE] thread:
*http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62750...@chw20013593.ch.ad.hedani.net%3E
*

*and vote result: *

*http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62766...@chw20013593.ch.ad.hedani.net%3E
*

Please take a look at the artifacts and vote!

[ ] +1 Release this package
[ ] 0 I don't feel strongly about it, but
don't object
[ ] -1 Do not release this package because...

The vote will be open for 72 hours at least.



References
=

The tag/commit is available here:
https://github.com/apache/incubator-tamaya/tree/0.1-incubating
*https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=c07976ae65db58f02985307b79d317e1ffc4f036
*

The release notes can be found here:
https://raw.githubusercontent.com/apache/incubator-tamaya/0.1-incubating/readme/ReleaseNotes-0.1-incubating.html
and here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315925&version=12329050

Release candidates are signed with a GPG key available at:
*https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=blob_plain;f=keys/KEYS;hb=c07976ae65db58f02985307b79d317e1ffc4f036
*


The release candidate artifacts are here:

https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-bin.zip

SHA-1 checksums: 3eb09278b914b96fb5c6059523b1bb3e69a09334
MD5 checksums: 24a10473841be94bdfef029e45d901741afc4ea0

https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-bin.tar.gz
SHA-1 checksums: 122997a3bacabd4d1589784a9110d0b38133785b
MD5 checksums: 7e69859a07a1c84935e6cce360f4164b

and

https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-src.zip
SHA-1 checksums: 3eb09278b914b96fb5c6059523b1bb3e69a09334
MD5 checksums: 1dfb81f25b88de37976ee2d83ec64bf2

https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-src.tar.gz
SHA-1 checksums: f0aeffb3304f300e6071019d31a73a812556b8c3
MD5 checksums: 801cec5b3fa434a786f8ee82c692c3a0

Obviously the whole closed staging repo is here:
https://repository.apache.org/content/repositories/orgapachetamaya-1003



What's in this release


This is our first release. It contains:

- API and Implementation (core) compatible with Java 7 and later
- API with additional default methods and implementation (core) based on
Java 8
- Out of the box properties and xml-properties are supported configuration
formats
- Extension Modules for
  - resource location and path lookup of configuration resources
  - placeholders and cross references
  - a configuration builder implementation
  - modeling formats, that read configuration data into a normalized data
structure.
  - additional configuration formats support for
- json
  - dynamic configuration events API, including an example how a folder on
disk can be observed for
dynamically updating configuration
  - an purely SE based injection module supporting injection, templates and
dynamic, updateable configuration values.
- All extension modules despite the builder modules are compatible with
Java 7 and later
- A bunch of documentation for
  - Use Cases
  - High Level Design
  - The current draft extension modules
- Also tagged, but not part of the distribution are the experimental
modules for
  - supporting yaml formats
  - configuring JodaTime library types
  - JMX support
  - configuration metamodels
  - configuration model and validation support


Building the project/distribution
===

The project can built using using standard maven commands:

1. Ensure your workspace is setup for using with different tool chains:
- Ensure you have JDK7 AND JDK8 are both installed on your disk.
- copy toolchain.xml from the project's root folder to
$USER_HOME/.m2/t

Re: apache binary distributions - Apache policies

[Shane Curcuru]

On 8/9/15 9:37 PM, Roman Shaposhnik wrote:
> On Fri, Aug 7, 2015 at 1:52 PM, Ted Dunning  wrote:

> The question is: do we have ASF-wide trademark guidelines or do
> we allow each PMC to make those as they go.

Um, yes, we do:

  https://www.apache.org/foundation/marks/

Question: raise your hand here (or in a private email to me) if you are
on the IPMC and have never read that page before.  If so, please go read
it.  I'll wait.

.
.
.

Thanks.

Separately: the ASF is a corporation, which has a board and a number of
corporate officers who are empowered by the board to set specific kinds
of ASF-wide policies, which are *required* (if so marked; many are best
practices) of all Apache projects.  If you haven't read the minimal list
of these requirements, I highly recommend it - it's a much simpler read
than the trademark policy [1]:

  https://www.apache.org/dev/project-requirements

These ASF policies are required for our projects (and podlings, so they
can graduate), but obviously we don't have the authority to require
third parties (other companies or people) to follow them.  We can,
however, insist legally that third parties follow our Apache license and
our trademark policy.

- Shane

[1] Apologies for the long-windedness of the trademark policies.  It's
on my "I'd really love to" list to break it up into simpler chunks.



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Tamaya Release 0.1-incubating

[John D. Ament]

Copying my +1 (binding) from the dev list.

John

On Fri, Aug 14, 2015 at 9:02 PM Anatole Tresch  wrote:

> Dear Incubator
>
> after the Apache Tamaya PPMC vote passed successfully with 5+ votes for the
> first release "0.1-incubating" of Apache Tamaya, it's now the incubator's
> task to vote ;)
>
> Please see original [VOTE] thread:
> *
> http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62750...@chw20013593.ch.ad.hedani.net%3E
> <
> http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62750...@chw20013593.ch.ad.hedani.net%3E
> >*
>
> *and vote result: *
>
> *
> http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62766...@chw20013593.ch.ad.hedani.net%3E
> <
> http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62766...@chw20013593.ch.ad.hedani.net%3E
> >*
>
> Please take a look at the artifacts and vote!
>
> [ ] +1 Release this package
> [ ] 0 I don't feel strongly about it, but
> don't object
> [ ] -1 Do not release this package because...
>
> The vote will be open for 72 hours at least.
>
>
>
> References
> =
>
> The tag/commit is available here:
> https://github.com/apache/incubator-tamaya/tree/0.1-incubating
> *
> https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=c07976ae65db58f02985307b79d317e1ffc4f036
> <
> https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=c07976ae65db58f02985307b79d317e1ffc4f036
> >*
>
> The release notes can be found here:
>
> https://raw.githubusercontent.com/apache/incubator-tamaya/0.1-incubating/readme/ReleaseNotes-0.1-incubating.html
> and here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315925&version=12329050
>
> Release candidates are signed with a GPG key available at:
> *
> https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=blob_plain;f=keys/KEYS;hb=c07976ae65db58f02985307b79d317e1ffc4f036
> <
> https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=blob_plain;f=keys/KEYS;hb=c07976ae65db58f02985307b79d317e1ffc4f036
> >*
>
>
> The release candidate artifacts are here:
>
>
> https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-bin.zip
>
> SHA-1 checksums: 3eb09278b914b96fb5c6059523b1bb3e69a09334
> MD5 checksums: 24a10473841be94bdfef029e45d901741afc4ea0
>
>
> https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-bin.tar.gz
> SHA-1
> 
> checksums: 122997a3bacabd4d1589784a9110d0b38133785b
> MD5 checksums: 7e69859a07a1c84935e6cce360f4164b
>
> and
>
>
> https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-src.zip
> SHA-1 checksums: 3eb09278b914b96fb5c6059523b1bb3e69a09334
> MD5 checksums: 1dfb81f25b88de37976ee2d83ec64bf2
>
>
> https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-src.tar.gz
> SHA-1
> 
> checksums: f0aeffb3304f300e6071019d31a73a812556b8c3
> MD5 checksums: 801cec5b3fa434a786f8ee82c692c3a0
>
> Obviously the whole closed staging repo is here:
> https://repository.apache.org/content/repositories/orgapachetamaya-1003
>
>
>
> What's in this release
> 
>
> This is our first release. It contains:
>
> - API and Implementation (core) compatible with Java 7 and later
> - API with additional default methods and implementation (core) based on
> Java 8
> - Out of the box properties and xml-properties are supported configuration
> formats
> - Extension Modules for
>   - resource location and path lookup of configuration resources
>   - placeholders and cross references
>   - a configuration builder implementation
>   - modeling formats, that read configuration data into a normalized data
> structure.
>   - additional configuration formats support for
> - json
>   - dynamic configuration events API, including an example how a folder on
> disk can be observed for
> dynamically updating configuration
>   - an purely SE based injection module supporting injection, templates and
> dynamic, updateable configuration values.
> - All extension modules despite the builder modules are compatible w

Re: [VOTE] Apache Tamaya Release 0.1-incubating

[Romain Manni-Bucau]

+1
Le 14 août 2015 18:02, "Anatole Tresch"  a écrit :

> Dear Incubator
>
> after the Apache Tamaya PPMC vote passed successfully with 5+ votes for the
> first release "0.1-incubating" of Apache Tamaya, it's now the incubator's
> task to vote ;)
>
> Please see original [VOTE] thread:
> *
> http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62750...@chw20013593.ch.ad.hedani.net%3E
> <
> http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62750...@chw20013593.ch.ad.hedani.net%3E
> >*
>
> *and vote result: *
>
> *
> http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62766...@chw20013593.ch.ad.hedani.net%3E
> <
> http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62766...@chw20013593.ch.ad.hedani.net%3E
> >*
>
> Please take a look at the artifacts and vote!
>
> [ ] +1 Release this package
> [ ] 0 I don't feel strongly about it, but
> don't object
> [ ] -1 Do not release this package because...
>
> The vote will be open for 72 hours at least.
>
>
>
> References
> =
>
> The tag/commit is available here:
> https://github.com/apache/incubator-tamaya/tree/0.1-incubating
> *
> https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=c07976ae65db58f02985307b79d317e1ffc4f036
> <
> https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=c07976ae65db58f02985307b79d317e1ffc4f036
> >*
>
> The release notes can be found here:
>
> https://raw.githubusercontent.com/apache/incubator-tamaya/0.1-incubating/readme/ReleaseNotes-0.1-incubating.html
> and here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315925&version=12329050
>
> Release candidates are signed with a GPG key available at:
> *
> https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=blob_plain;f=keys/KEYS;hb=c07976ae65db58f02985307b79d317e1ffc4f036
> <
> https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=blob_plain;f=keys/KEYS;hb=c07976ae65db58f02985307b79d317e1ffc4f036
> >*
>
>
> The release candidate artifacts are here:
>
>
> https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-bin.zip
>
> SHA-1 checksums: 3eb09278b914b96fb5c6059523b1bb3e69a09334
> MD5 checksums: 24a10473841be94bdfef029e45d901741afc4ea0
>
>
> https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-bin.tar.gz
> SHA-1
> 
> checksums: 122997a3bacabd4d1589784a9110d0b38133785b
> MD5 checksums: 7e69859a07a1c84935e6cce360f4164b
>
> and
>
>
> https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-src.zip
> SHA-1 checksums: 3eb09278b914b96fb5c6059523b1bb3e69a09334
> MD5 checksums: 1dfb81f25b88de37976ee2d83ec64bf2
>
>
> https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-src.tar.gz
> SHA-1
> 
> checksums: f0aeffb3304f300e6071019d31a73a812556b8c3
> MD5 checksums: 801cec5b3fa434a786f8ee82c692c3a0
>
> Obviously the whole closed staging repo is here:
> https://repository.apache.org/content/repositories/orgapachetamaya-1003
>
>
>
> What's in this release
> 
>
> This is our first release. It contains:
>
> - API and Implementation (core) compatible with Java 7 and later
> - API with additional default methods and implementation (core) based on
> Java 8
> - Out of the box properties and xml-properties are supported configuration
> formats
> - Extension Modules for
>   - resource location and path lookup of configuration resources
>   - placeholders and cross references
>   - a configuration builder implementation
>   - modeling formats, that read configuration data into a normalized data
> structure.
>   - additional configuration formats support for
> - json
>   - dynamic configuration events API, including an example how a folder on
> disk can be observed for
> dynamically updating configuration
>   - an purely SE based injection module supporting injection, templates and
> dynamic, updateable configuration values.
> - All extension modules despite the builder modules are compatible with
> Java 7 and later
> - A bunch of documentation

Re: [VOTE] Apache Tamaya Release 0.1-incubating

[Justin Mclean]

Hi,

+1 binding 

I checked:
- incubating in release artefact name
- signatures and hashes correct
- DISCLAIMER exists
- LICENSE and NOTICE good
- no unexpected binaries in source release
- all source files have apache headers
- can compile from source

May be my set up but all steps pass except the very last step of the build 
process failing when doing a "mvn install", a "mvn compile” works however.
[INFO] Apache Tamaya Distribution  FAILURE
[ERROR] Failed to execute goal on project tamaya-distribution: Could not 
resolve dependencies for project 
org.apache.tamaya:tamaya-distribution:jar:0.1-incubating: The following 
artifacts could not be resolved: 
org.apache.tamaya:tamaya-java7-api:jar:javadoc:0.1-incubating, 
org.apache.tamaya:tamaya-java7-core:jar:javadoc:0.1-incubating: Failure to find 
org.apache.tamaya:tamaya-java7-api:jar:javadoc:0.1-incubating in 
http://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central has 
elapsed or updates are forced -> [Help 1]
[ERROR] 

I’m running Java1.8 but do java 1.7 installed and did set up the toolchains.xml 
file.

A couple of minor things:
- Could you place the release candidate here next time? [1]
- Both the src and the bin untag to the same directory
- The binary connivence distribution is missing top level NOTICE, LICENSE and 
DISCLAIMER files (LICENSE and NOTICE are inside respective jars)
- The top level binary NOTICE should include information from the Jackson JSON 
processor NOTICE file [2][3]

Thanks,
Justin

1. https://dist.apache.org/repos/dist/dev/incubator/
2. http://www.apache.org/dev/licensing-howto.html#alv2-dep
3. http://www.apache.org/dev/licensing-howto.html#binary
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache REEF 0.12.0-incubating (rc2)

[Brian Cho]

Thank you Chris and Justin for your thorough checks.

We could really use a third IPMC vote :)

-Brian

On Fri, Aug 14, 2015 at 3:06 PM, Justin Mclean  wrote:

> Hi,
>
> +1 binding
>
> I checked:
> - signatures and hashes good
> - DISCLAIMER exits
> - LICENSE and NOTICE good
> - No unexpected binary files
> - All source files have headers
> - Can compile from source
>
> Thanks,
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Tamaya Release 0.1-incubating

[Anatole Tresch]

Hi Justin

Thank you for your input. We will check the issues found. The failing build
I will try to see if I can reproduce the result, when I clean my local repo
first.

Anatole
Am 15.08.2015 07:09 schrieb "Justin Mclean" :

> Hi,
>
> +1 binding
>
> I checked:
> - incubating in release artefact name
> - signatures and hashes correct
> - DISCLAIMER exists
> - LICENSE and NOTICE good
> - no unexpected binaries in source release
> - all source files have apache headers
> - can compile from source
>
> May be my set up but all steps pass except the very last step of the build
> process failing when doing a "mvn install", a "mvn compile” works however.
> [INFO] Apache Tamaya Distribution  FAILURE
> [ERROR] Failed to execute goal on project tamaya-distribution: Could not
> resolve dependencies for project
> org.apache.tamaya:tamaya-distribution:jar:0.1-incubating: The following
> artifacts could not be resolved:
> org.apache.tamaya:tamaya-java7-api:jar:javadoc:0.1-incubating,
> org.apache.tamaya:tamaya-java7-core:jar:javadoc:0.1-incubating: Failure to
> find org.apache.tamaya:tamaya-java7-api:jar:javadoc:0.1-incubating in
> http://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of central has
> elapsed or updates are forced -> [Help 1]
> [ERROR]
>
> I’m running Java1.8 but do java 1.7 installed and did set up the
> toolchains.xml file.
>
> A couple of minor things:
> - Could you place the release candidate here next time? [1]
> - Both the src and the bin untag to the same directory
> - The binary connivence distribution is missing top level NOTICE, LICENSE
> and DISCLAIMER files (LICENSE and NOTICE are inside respective jars)
> - The top level binary NOTICE should include information from the Jackson
> JSON processor NOTICE file [2][3]
>
> Thanks,
> Justin
>
> 1. https://dist.apache.org/repos/dist/dev/incubator/
> 2. http://www.apache.org/dev/licensing-howto.html#alv2-dep
> 3. http://www.apache.org/dev/licensing-howto.html#binary
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>