Re: [DISCUSS] Tweets from ApacheApex handle

[Amol Kekre]

Thomas,
The proposal is for credentials to remain in PMC, and in-effect committers
sending a request to tweet. Here some relevant advice on do's and don'ts
from ASF for social media. I have pasted it as is.

   - Feel free to share stories about your project, whether they come from
   the community, tech press, or folks outside of the press and community.
   Avoid sharing negative stories about "competing" projects.
   - Keep posts/reposts relevant to your project community and technology.
   Most people love LOLCats, but it's probably best not to share them from
   your project's social media accounts.
   - Please share event information so long as it's related directly to
   your project. Promoting an event where there are talks about CloudStack
   (for example) is spot-on. Promoting an event only because a vendor that has
   an interest in CloudStack is participating would be outside the scope of
   CloudStack social media accoun

So lets say we find a vendor/customer/someone saying "I used Apex for ...;
here is my use case; .. Apex worked for me"; Or a blog on some nuances of
Apex. These are stories about Apex, why would we not want to tweet/retweet
these? For adoption of Apex, it is good for everyone to know about such
stories. Moreover it is enpowering for committers to know that they can be
eyes-ears of Apex stories.

Thks,
Amol


*Join us at Apex Big Data World-San Jose
, April 4, 2017!*
[image: http://www.apexbigdata.com/san-jose-register.html]


On Sun, Feb 5, 2017 at 12:11 PM, Thomas Weise  wrote:

> The link that I provided gives context about how projects overall work. I
> find that useful to understand before embarking into further discussion.
> And I also found some more guidance regarding social media activity:
>
> http://www.apache.org/foundation/marks/socialmedia
>
> My preference is that the handle will only tweet official communication
> from the PMC. I looked at a number of other projects that may serve as good
> role models and found that to be the case also.
>
> For retweets, we should probably come up with similar guidelines as for
> listing events, including clean representation of Apache Apex as project,
> vendor neutrality, unrelated to commercial interests.
>
> Thomas
>
>
> On Thu, Feb 2, 2017 at 12:22 PM, Pramod Immaneni 
> wrote:
>
> > I prefer option 2 at least till there is a critical mass of social
> activity
> > and awareness happening outside around apex that we don't need to tweet
> > actively on the community page.
> >
> > Thanks
> >
> > On Thu, Feb 2, 2017 at 10:31 AM, Amol Kekre 
> wrote:
> >
> > > Thomas,
> > > The discussion is not about handle being operated outside PMC. It is
> > > perfectly fine to have handle credentials accessible to only PMC
> > members. I
> > > started this discussion to get Apex community opinion on guidelines on
> > what
> > > gets tweeted. The ASF does not have a formal guideline on twitter. So
> far
> > > there are two proposals
> > >
> > > 1. Only do release tweets, and do retweet of tweets on individual
> handle
> > by
> > > requesting PMC on dev@; no special consideration to committers
> > > 2. Have a more open policy on original tweets, and in addition retweet
> of
> > > tweets on individual handle by request PMC on dev@; take up
> committer's
> > > request as semi-binding.
> > >
> > > In #1, the release-tweets are clear, so nothing else go through. In #2
> > PMC
> > > member can do a trust-but-verify that the tweet is relevant to Apex;
> > which
> > > makes is semi-binding, not binding.
> > >
> > > Thks,
> > > Amol
> > >
> > >
> > > On Wed, Feb 1, 2017 at 7:34 PM, Thomas Weise  wrote:
> > >
> > > > Note this is follow-up from a previous discussion on the PMC list.
> > > >
> > > > I think the decision on activity for the ApacheApex handle should be
> > with
> > > > the PMC and the handle should be operated by PMC members.
> > > >
> > > > See http://apache.org/foundation/how-it-works.html for more context
> > > about
> > > > roles and responsibilities.
> > > >
> > > > What gets posted on the handle should be evaluated with ASF hat on.
> > > >
> > > > I also think that direct tweets (read on for retweets) should be
> > > restricted
> > > > to official PMC communication (releases etc.). All other tweets
> should
> > > come
> > > > from individual handles. I like the idea of retweet suggestions on
> the
> > > dev@
> > > > list.
> > > >
> > > > Thomas
> > > >
> > > >
> > > > On Wed, Feb 1, 2017 at 4:43 PM, Amol Kekre 
> > wrote:
> > > >
> > > > > I want to see what the community feels about posting tweets on
> > > ApacheApex
> > > > > handle. My thoughts are that the committers should have the right
> to
> > > > post a
> > > > > tweek on ApacheApex. For contributors and anyone else, we could
> have
> > a
> > > > > mechanism where they request it 

[jira] [Commented] (APEXCORE-592) Returning description field in defaultProperties during apex cli call get-app-package-info

[Ajay Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/APEXCORE-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853604#comment-15853604
 ] 

Ajay Gupta commented on APEXCORE-592:
-

Hi [~ashwinchandrap], considering the sope of this JIRA,  I have made changes 
to retrieve description only for the properties (omitting attributes) specified 
in properties.xml. Below is an example output. Let me know if this is fine.

properties.xml

dt.application.FraudDetectDemo.operator.smaPerMerchant.windowSize

30
Window size



dt.application.FraudDetectDemo.operator.movingSum.attr.APPLICATION_WINDOW_COUNT

10
Window count for application


Output : get-app-package-info package-name
 
"dt.application.FraudDetectDemo.operator.smaPerMerchant.windowSize": {
  "value": "30",
  "description": "Window size"
},

"dt.application.FraudDetectDemo.operator.movingSum.attr.APPLICATION_WINDOW_COUNT":
 {
  "value": "10",
  "description": null
},

> Returning description field in defaultProperties during apex cli call 
> get-app-package-info
> --
>
> Key: APEXCORE-592
> URL: https://issues.apache.org/jira/browse/APEXCORE-592
> Project: Apache Apex Core
>  Issue Type: Improvement
>Reporter: Ajay Gupta
>Priority: Minor
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Currently for an operator property, only the value field is returned. The 
> operator property can have a description describing the property. This task 
> is created to return this filed for that operator property.



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

[jira] [Updated] (APEXMALHAR-2399) In PojoInnerJoin accumulation default constructor is directly throwing an exception which messes up in default serialization.

[Hitesh Kapoor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/APEXMALHAR-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hitesh Kapoor updated APEXMALHAR-2399:
--
Description: In PojoInnerJoin accumulation default constructor is directly 
throwing an exception which messes up in default serialization. The exception 
is thrown saying to specify the number of streams. Currently we only merge 2 
streams so there is no need to throw this exception also it messes up the 
serialization and the applicaion can't be loaded.  (was: In PojoInnerJoin 
accumulation default constructor is directly throwing an exception which messes 
up in default serialization. The exception is thrown because saying to specify 
the number of streams. Currently we only merge 2 streams so there is no need to 
throw this exception also it messes up the serialization and the applicaion 
can't be loaded.)

> In PojoInnerJoin accumulation default constructor is directly throwing an 
> exception which messes up in default serialization.
> -
>
> Key: APEXMALHAR-2399
> URL: https://issues.apache.org/jira/browse/APEXMALHAR-2399
> Project: Apache Apex Malhar
>  Issue Type: Bug
>Reporter: Hitesh Kapoor
>Assignee: Hitesh Kapoor
>
> In PojoInnerJoin accumulation default constructor is directly throwing an 
> exception which messes up in default serialization. The exception is thrown 
> saying to specify the number of streams. Currently we only merge 2 streams so 
> there is no need to throw this exception also it messes up the serialization 
> and the applicaion can't be loaded.



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

[jira] [Created] (APEXMALHAR-2399) In PojoInnerJoin accumulation default constructor is directly throwing an exception which messes up in default serialization.

[Hitesh Kapoor (JIRA)]

Hitesh Kapoor created APEXMALHAR-2399:
-

 Summary: In PojoInnerJoin accumulation default constructor is 
directly throwing an exception which messes up in default serialization.
 Key: APEXMALHAR-2399
 URL: https://issues.apache.org/jira/browse/APEXMALHAR-2399
 Project: Apache Apex Malhar
  Issue Type: Bug
Reporter: Hitesh Kapoor
Assignee: Hitesh Kapoor


In PojoInnerJoin accumulation default constructor is directly throwing an 
exception which messes up in default serialization. The exception is thrown 
because saying to specify the number of streams. Currently we only merge 2 
streams so there is no need to throw this exception also it messes up the 
serialization and the applicaion can't be loaded.



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

Re: Setting JAVA Serializer to be used at App Level.

[Ambarish Pande]

This is exactly what i wanted.
Thank You.

On Mon, Feb 6, 2017 at 11:35 AM, Hitesh Kapoor 
wrote:

> Hi Ambarish,
>
> Yes you can plug in your own serializer. You will have to set the
> "STREAM_CODEC" port attribute to achieve the same.
> You can refer xmlParserApplication from examples repo (
> https://github.com/DataTorrent/examples).
>
> Regards,
> Hitesh
>
>
> On Mon, Feb 6, 2017 at 11:07 AM, Ambarish Pande <
> ambarish.pande2...@gmail.com> wrote:
>
> > Hello,
> >
> > Is there a way to set up JAVA Serializer as the default serializer to be
> > used for a particular application. Currently, Kryo is the default
> > serializer and the library that I am using has compatibility issues with
> > Kryo.
> >
> > Thank You.
> >
>

Re: Setting JAVA Serializer to be used at App Level.

[Sandesh Hegde]

Java serializer comes with a big performance cost, so it is better to
reduce it's usage.
Can you please give more detail about your use case?

On Sun, Feb 5, 2017 at 10:05 PM Hitesh Kapoor 
wrote:

Hi Ambarish,

Yes you can plug in your own serializer. You will have to set the
"STREAM_CODEC" port attribute to achieve the same.
You can refer xmlParserApplication from examples repo (
https://github.com/DataTorrent/examples).

Regards,
Hitesh


On Mon, Feb 6, 2017 at 11:07 AM, Ambarish Pande <
ambarish.pande2...@gmail.com> wrote:

> Hello,
>
> Is there a way to set up JAVA Serializer as the default serializer to be
> used for a particular application. Currently, Kryo is the default
> serializer and the library that I am using has compatibility issues with
> Kryo.
>
> Thank You.
>

Re: Setting JAVA Serializer to be used at App Level.

[Hitesh Kapoor]

Hi Ambarish,

Yes you can plug in your own serializer. You will have to set the
"STREAM_CODEC" port attribute to achieve the same.
You can refer xmlParserApplication from examples repo (
https://github.com/DataTorrent/examples).

Regards,
Hitesh


On Mon, Feb 6, 2017 at 11:07 AM, Ambarish Pande <
ambarish.pande2...@gmail.com> wrote:

> Hello,
>
> Is there a way to set up JAVA Serializer as the default serializer to be
> used for a particular application. Currently, Kryo is the default
> serializer and the library that I am using has compatibility issues with
> Kryo.
>
> Thank You.
>

Setting JAVA Serializer to be used at App Level.

[Ambarish Pande]

Hello,

Is there a way to set up JAVA Serializer as the default serializer to be
used for a particular application. Currently, Kryo is the default
serializer and the library that I am using has compatibility issues with
Kryo.

Thank You.

Re: [DISCUSS] Tweets from ApacheApex handle

[Thomas Weise]

The link that I provided gives context about how projects overall work. I
find that useful to understand before embarking into further discussion.
And I also found some more guidance regarding social media activity:

http://www.apache.org/foundation/marks/socialmedia

My preference is that the handle will only tweet official communication
from the PMC. I looked at a number of other projects that may serve as good
role models and found that to be the case also.

For retweets, we should probably come up with similar guidelines as for
listing events, including clean representation of Apache Apex as project,
vendor neutrality, unrelated to commercial interests.

Thomas


On Thu, Feb 2, 2017 at 12:22 PM, Pramod Immaneni 
wrote:

> I prefer option 2 at least till there is a critical mass of social activity
> and awareness happening outside around apex that we don't need to tweet
> actively on the community page.
>
> Thanks
>
> On Thu, Feb 2, 2017 at 10:31 AM, Amol Kekre  wrote:
>
> > Thomas,
> > The discussion is not about handle being operated outside PMC. It is
> > perfectly fine to have handle credentials accessible to only PMC
> members. I
> > started this discussion to get Apex community opinion on guidelines on
> what
> > gets tweeted. The ASF does not have a formal guideline on twitter. So far
> > there are two proposals
> >
> > 1. Only do release tweets, and do retweet of tweets on individual handle
> by
> > requesting PMC on dev@; no special consideration to committers
> > 2. Have a more open policy on original tweets, and in addition retweet of
> > tweets on individual handle by request PMC on dev@; take up committer's
> > request as semi-binding.
> >
> > In #1, the release-tweets are clear, so nothing else go through. In #2
> PMC
> > member can do a trust-but-verify that the tweet is relevant to Apex;
> which
> > makes is semi-binding, not binding.
> >
> > Thks,
> > Amol
> >
> >
> > On Wed, Feb 1, 2017 at 7:34 PM, Thomas Weise  wrote:
> >
> > > Note this is follow-up from a previous discussion on the PMC list.
> > >
> > > I think the decision on activity for the ApacheApex handle should be
> with
> > > the PMC and the handle should be operated by PMC members.
> > >
> > > See http://apache.org/foundation/how-it-works.html for more context
> > about
> > > roles and responsibilities.
> > >
> > > What gets posted on the handle should be evaluated with ASF hat on.
> > >
> > > I also think that direct tweets (read on for retweets) should be
> > restricted
> > > to official PMC communication (releases etc.). All other tweets should
> > come
> > > from individual handles. I like the idea of retweet suggestions on the
> > dev@
> > > list.
> > >
> > > Thomas
> > >
> > >
> > > On Wed, Feb 1, 2017 at 4:43 PM, Amol Kekre 
> wrote:
> > >
> > > > I want to see what the community feels about posting tweets on
> > ApacheApex
> > > > handle. My thoughts are that the committers should have the right to
> > > post a
> > > > tweek on ApacheApex. For contributors and anyone else, we could have
> a
> > > > mechanism where they request it on dev@apex.apache.org and a
> committer
> > > can
> > > > help out. In essence we treat tweet same as code. I would expect
> > > committers
> > > > to ensure that the tweet is related to Apex, I believe that will more
> > or
> > > > less remain true.
> > > >
> > > > Aside from this, I think the release-manager should be expected to
> post
> > > > release tweets on ApacheApex handle.
> > > >
> > > > Thoughts?
> > > >
> > > > Thks
> > > > Amol
> > > >
> > >
> >
>

[jira] [Updated] (APEXCORE-632) Fix the existing unit test and move them to JUnit from testNg

[Sandesh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/APEXCORE-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandesh updated APEXCORE-632:
-
Summary: Fix the existing unit test and move them to JUnit from testNg  
(was: Fix the existing unit test and possibly move them to JUnit from testNg)

> Fix the existing unit test and move them to JUnit from testNg
> -
>
> Key: APEXCORE-632
> URL: https://issues.apache.org/jira/browse/APEXCORE-632
> Project: Apache Apex Core
>  Issue Type: Sub-task
>Reporter: Sandesh
>Assignee: Sandesh
>




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