Re: [VOTE] Apache ActiveMQ 5.17.1 release
+1 Dan > On Apr 25, 2022, at 10:21 AM, Jean-Baptiste Onofré wrote: > > Hi guys, > > I submit the ActiveMQ 5.17.1 release to your vote. > > This release is an important release on the 5.17.x series, bringing > major changes: > - upgrade to Spring 5.3.19, fixing Spring4shell vulnerability (even if > ActiveMQ is not directly impacted) > - XBean 4.21 (supporting Spring 5.x) and ASM 9.3 for better Java 18+ support > - and much much more > > Please take a look on the Release Notes for details: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12351348 > > Maven Staging Repository: > https://repository.apache.org/content/repositories/orgapacheactivemq-1250/ > > Dist Staging Repository: > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.1/ > > Git tag: activemq-5.17.1 > > Please vote to approve this release: > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks ! > Regards > JB -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> Talend - https://talend.com <https://talend.com/>
Re: [VOTE] Apache ActiveMQ 5.15.15 release (take #3)
+1 I don’t see any real reason to delay the release anymore. Let’s get it out. Dan > On Apr 20, 2021, at 3:00 AM, Jean-Baptiste Onofre wrote: > > Hi everyone, > > I submit Apache ActiveMQ 5.15.15 to your vote (third attempt). We fixed the > issue identified in AMQ-8226 and this is a new take (#3) on 5.15.15 release. > > This release includes important fixes and updates, especially: > - Shiro, Spring, xstream, jetty upgrades > - fixes on WebConsole when destination name contains + > - fixes and improvements on the Karaf features to avoid breaking Karaf http > commands and refresh > - improved serialization security to avoid impact on xstream ack processing > > Please take a look on the Release Notes for details: > > > The Maven staging repository is: > https://repository.apache.org/content/repositories/orgapacheactivemq-1228/ > <https://repository.apache.org/content/repositories/orgapacheactivemq-1228/> > > The dist staging repository is: > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.15/ > <https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.15/> > > Git tag: > activemq-5.15.15 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks ! > Regards > JB -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend - http://talend.com <http://coders.talend.com/>
Re: [VOTE] Apache ActiveMQ 5.15.15 release (take #2)
+1 Lets get is out so we can concentrate on 5.16/5.17. Dan > On Apr 8, 2021, at 7:22 AM, Jean-Baptiste Onofre wrote: > > Hi everyone, > > I submit Apache ActiveMQ 5.15.15 to your vote. We fixed the issue identified > in AMQ-8219 and this is a new take on 5.15.15 release. > > This release includes important fixes and updates, especially: > - Shiro, Spring, xstream, jetty upgrades > - fixes on WebConsole when destination name contains + > - fixes and improvements on the Karaf features to avoid breaking Karaf http > commands and refresh > - improved serialization security to avoid impact on xstream ack processing > > Please take a look on the Release Notes for details: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12349417 > > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12349417> > > The Maven staging repository is: > https://repository.apache.org/content/repositories/orgapacheactivemq-1227/ > <https://repository.apache.org/content/repositories/orgapacheactivemq-1227/> > > The dist staging repository is: > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.15/ > <https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.15/> > > Git tag: > activemq-5.15.15 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks ! > Regards > JB -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend - http://talend.com <http://coders.talend.com/>
Re: [VOTE] Apache ActiveMQ 5.16.1 release
+1 Dan > On Jan 14, 2021, at 9:51 AM, Jean-Baptiste Onofre wrote: > > Hi everyone, > > I submit Apache ActiveMQ 5.16.1 to your vote. > This release includes several fixes (runtime configuration plugin with JDK9+, > Karaf features, harden deserialization, …), improvements (new scheduler > counters on JMX, avoiding several NPE, …), and updates (commons*, Shiro, > jetty, …). > > Please take a look on the Release Notes for details: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12347027 > > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12347027> > > The Maven staging repository is: > https://repository.apache.org/content/repositories/orgapacheactivemq-1222/ > <https://repository.apache.org/content/repositories/orgapacheactivemq-1222/> > > The dist staging repository is: > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.1/ > <https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.1/> > > Git tag: > activemq-5.16.1 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks ! > Regards > JB -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend - http://talend.com <http://coders.talend.com/>
Re: [VOTE] Apache ActiveMQ 5.15.14 release (take #2)
+1 Dan > On Dec 3, 2020, at 12:03 AM, Jean-Baptiste Onofre wrote: > > Hi everyone, > > I submit Apache ActiveMQ 5.15.14 to your vote. This second take includes > fixes on jetty-realm file protocol and new updates. > This release includes CVE related updates and bug fixes. > > Please take a look on the Release Notes for details: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12348294 > > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12348294> > > The Maven staging repository is: > https://repository.apache.org/content/repositories/orgapacheactivemq-1221/ > <https://repository.apache.org/content/repositories/orgapacheactivemq-1221/> > > The dist staging repository is: > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.14/ > <https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.14/> > > Git tag: > activemq-5.15.14 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks ! > Regards > JB -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend - http://talend.com <http://coders.talend.com/>
Re: [VOTE] Apache ActiveMQ 5.15.14 release
+1 Dan > On Nov 24, 2020, at 2:00 AM, Jean-Baptiste Onofre wrote: > > Hi everyone, > > I submit Apache ActiveMQ 5.15.14 to your vote. > This release includes CVE related updates and bug fixes. > > Please take a look on the Release Notes for details: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12348294 > > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12348294> > > The Maven staging repository is: > https://repository.apache.org/content/repositories/orgapacheactivemq-1220/ > <https://repository.apache.org/content/repositories/orgapacheactivemq-1220/> > > The dist staging repository is: > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.14/ > <https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.14/> > > Git tag: > activemq-5.15.14 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks ! > Regards > JB -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend - http://talend.com <http://coders.talend.com/>
Re: [DISCUSS] Draft proposal for terminology change
Huge +1 from me. Major thanks for putting a concrete proposal together. -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend - http://talend.com <http://talend.com/> > On Jul 25, 2020, at 11:39 PM, Matt Pavlovich wrote: > > Clebert— Good catch, updated below > > [Draft rev 2] > > Kicking off draft proposal conversation, we can then convert this to a > ticket. I’ve collected ideas from the recent dev mailing list convo. I’m > sure I’ve missed some key points and am not married to anything here. > Please chime in! > > Description: Support migration of terms such as ‘master’ and ’slave’. > > Proposed steps: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > 6. Other? > > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' > > Thanks, > Matt Pavlovich > > > > >> On Jul 25, 2020, at 6:58 PM, Clebert Suconic >> wrote: >> >> You’re missing blacklist and white list. >> >> >> Should be allow list. And deny list. >> >> On Sat, Jul 25, 2020 at 2:25 PM Matt Pavlovich wrote: >> >>> Kicking off draft proposal conversation, we can then convert this to a >>> ticket. I’ve collected ideas from the recent dev mailing list convo. I’m >>> sure I’ve missed some key points and am not married to anything here. >>> Please chime in! >>> >>> Description: Support migration of terms such as ‘master’ and ’slave’. >>> >>> Proposed steps: >>> 1. Deprecate terms such as ‘master’ and ’slave >>> 2. log.warn any configuration change notifications >>> 3. Provide compatibility under the covers for deprecated terms >>> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis >>> 5. Notify users in an announcement and provide a conversion HOWTO >>> 6. Other? >>> >>> New terms: >>> a. For shared storage: ‘active’ and ’standby’ >>> b. For replication: ‘primary’ and ‘replica' >>> >>> For example: >>> ‘master’ -> ‘active’ >>> ’slave’ -> ’standby' >>> >>> Thanks, >>> Matt Pavlovich >> >> -- >> Clebert Suconic >
Re: [VOTE] Apache ActiveMQ 5.16.0 release (take #2)
+1, simple building and running basic tests looks OK -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend - http://talend.com <http://talend.com/> > On Jun 25, 2020, at 10:23 AM, Jean-Baptiste Onofré wrote: > > Hi everyone, > > Now that we fixed the ASF header issue, I'm submitting ActiveMQ 5.16.0 > release to your vote (take #2). > > This release is an important milestone as the runtime supports JDK 11. > The full build with JDK 11 is planned for 5.17.0. > > It also includes bunch of fixes, improvements and much more. > > For your information, once this vote will pass, I will create > activemq-5.16.x branch and I will move master branch to version 5.17.0. > > Please take a look on the Release Notes for details: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12341032 > > The Maven staging repository is: > https://repository.apache.org/content/repositories/orgapacheactivemq-1213/ > > The dist staging repository is: > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.0/ > > Git tag: > activemq-5.16.0 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks ! > Regards > JB
Re: [VOTE] Apache ActiveMQ 5.15.12 release (take #2)
+1 Dan > On Mar 13, 2020, at 9:43 AM, Jean-Baptiste Onofre wrote: > > Hi everyone, > > I'm submitting ActiveMQ 5.15.12 release to your vote (take #2). In this new > round, we fixed JDBC lock test and STOMP connection error handling. > > As for the previous attempt, this release includes dependency updates > (especially for CVE/Security > fixes), important improvements on JDBC persistence adapter, other > improvements and fixes. > > Please take a look on the Release Notes for details: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12346500 > > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12346500><https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12346500 > > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12346500>> > > The Maven staging repository is: > https://repository.apache.org/content/repositories/orgapacheactivemq-1205 > > The dist staging repository is: > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.12/ > <https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.12/> > <https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.12/ > <https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.12/>> > > Git tag: > activemq-5.15.12 > > Website PR: > https://github.com/apache/activemq-website/pull/28 > <https://github.com/apache/activemq-website/pull/28> > <https://github.com/apache/activemq-website/pull/28 > <https://github.com/apache/activemq-website/pull/28>> > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks ! > Regards > JB -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: [VOTE] Apache ActiveMQ 5.15.12 release
+1 Dan > On Mar 6, 2020, at 2:15 AM, Jean-Baptiste Onofre wrote: > > Hi everyone, > > I'm submitting ActiveMQ 5.15.12 release to your vote. > > This release includes dependency updates (especially for CVE/Security > fixes), important improvements on JDBC persistence adapter, other > improvements and fixes. > > Please take a look on the Release Notes for details: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12346500 > > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12346500> > > The Maven staging repository is: > https://repository.apache.org/content/repositories/orgapacheactivemq-1204 > > The dist staging repository is: > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.12/ > <https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.12/> > > Git tag: > activemq-5.15.12 > > Website PR: > https://github.com/apache/activemq-website/pull/28 > <https://github.com/apache/activemq-website/pull/28> > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks ! > Regards > JB -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: [VOTE] Apache ActiveMQ 5.15.11 release (take #2)
+1 Dan > On Nov 20, 2019, at 1:02 PM, Jean-Baptiste Onofré wrote: > > Hi guys, > > Waiting ActiveMQ 5.16.0 release (that will be submitted to vote shortly, > probably next week), I'm submitting ActiveMQ 5.15.11 release to your vote. > This is take #2 containing a fix on activemq-osgi build. > > This release includes dependency updates (especially for CVE/Security > fixes), minor improvements, and fixes. > > Please take a look on the Release Notes for details: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12345958 > > The Maven staging repository is: > https://repository.apache.org/content/repositories/orgapacheactivemq-1201 > > The dist staging repository is: > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.11/ > > Git tag: > activemq-5.15.11 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks ! > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: [PROPOSAL] Move to gitbox.apache.org
> On Dec 10, 2018, at 2:40 PM, Clebert Suconic > wrote: > > I'm still trying to understand how it will happen before being able to > suggest anything. > > In particular what happens with the github mirror? The only thing that happens is all the GitHub stuff gets enabled. The merge button works. You can close PR’s, etc…. Other than that, it stays the same. Dan > > On Mon, Dec 10, 2018 at 10:31 AM Robbie Gemmell > mailto:robbie.gemm...@gmail.com>> wrote: >> >> I agree a formal vote isnt needed but a documented consensus on the >> mailing list is required in order to be included in the initial >> voluntary moves, which seems to be what Jean-Baptiste is proposing, so >> it does at minimum need this discussion and probably a direct lazy >> consensus statement on the matter. >> >> I'd echo your comment about being fine with it any time so long as >> noone is planning an imminent release. >> >> Robbie >> >> On Fri, 7 Dec 2018 at 17:14, Daniel Kulp > <mailto:dk...@apache.org>> wrote: >>> >>> >>> You don’t need a vote… It’s going to happen one way or another by Feb 7. >>> >>> The only issue is weather to be pro-active and do it now or wait a little >>> bit. If we have releases imminent, I’d say wait till after the >>> release. Otherwise, I’m OK at any time. >>> >>> Dan >>> >>> >>> >>>> On Dec 7, 2018, at 12:03 PM, Jean-Baptiste Onofré >>>> wrote: >>>> >>>> Hi all, >>>> >>>> Our repositories are currently located on git-wip-us.apache.org. >>>> >>>> This service will be decommissioned in the coming month. >>>> >>>> I'm proposing to move our repositories to gitbox.apache.org. >>>> >>>> I'm volunteer to start a vote, and if OK, I will deal with the infra. >>>> >>>> Thoughts ? >>>> >>>> Regards >>>> JB >>>> -- >>>> Jean-Baptiste Onofré >>>> jbono...@apache.org >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>> >>> -- >>> Daniel Kulp >>> dk...@apache.org <mailto:dk...@apache.org> <mailto:dk...@apache.org >>> <mailto:dk...@apache.org>> - http://dankulp.com/blog >>> <http://dankulp.com/blog> <http://dankulp.com/blog >>> <http://dankulp.com/blog>> >>> Talend Community Coder - http://talend.com <http://talend.com/> >>> <http://coders.talend.com/ <http://coders.talend.com/>> > > > > -- > Clebert Suconic -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: [PROPOSAL] Move to gitbox.apache.org
You don’t need a vote… It’s going to happen one way or another by Feb 7. The only issue is weather to be pro-active and do it now or wait a little bit. If we have releases imminent, I’d say wait till after the release. Otherwise, I’m OK at any time. Dan > On Dec 7, 2018, at 12:03 PM, Jean-Baptiste Onofré wrote: > > Hi all, > > Our repositories are currently located on git-wip-us.apache.org. > > This service will be decommissioned in the coming month. > > I'm proposing to move our repositories to gitbox.apache.org. > > I'm volunteer to start a vote, and if OK, I will deal with the infra. > > Thoughts ? > > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: [VOTE] Apache ActiveMQ 5.15.7
+1 Dan > On Oct 24, 2018, at 10:41 AM, Christopher Shannon > wrote: > > Hi Everyone, > > I have created the 5.15.7 release and it is ready for a vote. > > The list of resolved issues is here: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12344049 > > You can get the release artifacts here: > https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.7/ > > Maven repository is at: > https://repository.apache.org/content/repositories/orgapacheactivemq-1173/ > > Source tag: > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=795a2533b1cd4883ca1b17e7cb86d9bbc20994c5 > > Please vote to approve this release. The vote will remain open for 72 > hours. > > [ ] +1 Release the binary as Apache ActiveMQ 5.15.7 > [ ] -1 (provide specific comments) > > Here's my +1 -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: Webconsole deprecation
> Furthermore, there are certain things that require PMC members to > handle so there would still need to be people on the PMC willing to > support the web console as well (which hasn't really been the case > other than a few minor fixes I have committed the past couple years). That’s something that is easily fixed by the PMC if someone steps up to work on the console: vote them into the PMC. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Thoughts on refactoring the ActiveMQ website
I hacked the Confluence exporter a bit to grab the page content in different formats so we can see if one is easier to migrate or similar. I just pushed 3 new branches to this repo: body.only - this is basically the same HTML, but with all the “wrapper” stuff removed. Just the HTML of the body content. So no navigation or header/footer, etc… body.storage - this is the raw storage format of the data from confluence. Things like code snippets are in storage format (), etc. body.view - confluence has a “body.view” mode that is between the “storage” format and not really the exported HTML. The structured macros are expanded a bit (
Re: Thoughts on refactoring the ActiveMQ website
ing
>>>> paragraphs.
>>>>
>>>>
>>>> Bruce
>>>>
>>>> On Tue, Dec 12, 2017 at 11:39 AM, Martyn Taylor
>>>> wrote:
>>>>
>>>>> I was thinking there would be a single css file for all the pages.
>> But
>>> I
>>>>> haven't seen the files yet. Let's have a play around when Bruce pushes
>>> the
>>>>> export.
>>>>>
>>>>> Cheers
>>>>>
>>>>> On 12 Dec 2017 5:30 pm, "Michael André Pearce" <
>>>>> michael.andre.pea...@me.com>
>>>>> wrote:
>>>>>
>>>>>> What’s 1600 pages between friends
>>>>>>
>>>>>> I agree it will be easier to covert to md than to start doing css
>>>>> styles.
>>>>>> It’s all from a wiki anyhow so it’s can’t be that far off.
>>>>>>
>>>>>> It be good to get some samples (eg 50 pages) if not all just to try
>>> and
>>>>>> see what it is like.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12 Dec 2017, at 17:04, Clebert Suconic <
>> clebert.suco...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>> Exporting to MD and creating a gitbook seems like a big task, I
>>>>> suspect
>>>>>> any
>>>>>>>> tool we use will cause a bunch of styling/content issues.
>>>>>>>>
>>>>>>>> At least initially, how about we just create a nice landing page
>>> that
>>>>>>>> brings the ActiveMQ site and Artemis site together, and
>>> refresh/align
>>>>>> the
>>>>>>>> existing content with some CSS?
>>>>>>>
>>>>>>> I was just looking for the minimal effort task. I thought that
>>>>>>> converting these pages into a doc would be easier than converting
>>> them
>>>>>>> to another .css...
>>>>>>>
>>>>>>> if the conversion needed to be done anyways... I thought .md would
>>> be
>>>>>>> easier and having a better final presentation.
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&
>>>> 5R\"F)R=6-E+G-N>61E>>>
>>>> ActiveMQ in Action: http://bit.ly/2je6cQ
>>>> Blog: http://bsnyder.org/ <http://bruceblog.org/>
>>>> Twitter: http://twitter.com/brucesnyder
>>>>
>>>
>>>
>>>
>>> --
>>> perl -e 'print
>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E>>
>>> ActiveMQ in Action: http://bit.ly/2je6cQ
>>> Blog: http://bsnyder.org/ <http://bruceblog.org/>
>>> Twitter: http://twitter.com/brucesnyder
>>>
>>
>
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bsnyder.org/ <http://bruceblog.org/>
> Twitter: http://twitter.com/brucesnyder
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Thoughts on refactoring the ActiveMQ website
There are some things available to convert the confluence xhtml to markdown:
Example:
https://www.npmjs.com/package/confluence-to-github-markdown
I’m not sure how good of a job they do, but it might be better than nothing.
Dan
> On Dec 7, 2017, at 11:50 AM, Bruce Snyder wrote:
>
> That's the big hurdle I have identified, the initial conversion to
> Markdown. Perhaps a manual hackathon is the best way.
>
> Bruce
>
> On Thu, Dec 7, 2017 at 9:48 AM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
>> I agree that Markdown would be a good idea if we can figure out a good way
>> to convert it.
>>
>> On Thu, Dec 7, 2017 at 11:42 AM, Clebert Suconic <
>> clebert.suco...@gmail.com>
>> wrote:
>>
>>> +1
>>>
>>> I like the Markdown (or whatever easy format.. non xml based). We will
>>> need to choose a framework for that. do you have anything in mind?
>>>
>>> I also think we should have a consistent look and feel.
>>>
>>>
>>> I will be supportive on this...
>>>
>>>
>>> First thing will be to have a framework chosen..
>>> Second to have a github we collaborate...
>>> Third.. maybe we could use one of those video calls to talk about how to
>>> do it.
>>>
>>> On Wed, Dec 6, 2017 at 11:20 PM, Bruce Snyder
>>> wrote:
>>>> Several opinions have been expressed recently that the ActiveMQ website
>>>> needs some attention and that Artemis should be made more prominent.
>> I'd
>>>> like to discuss some ideas to see what we could achieve on this topic.
>>>>
>>>> If we are going to make Artemis more prominent, the first concern I
>>>> identified is that the ActiveMQ website and the Artemis website are
>>>> authored differently. The ActiveMQ website is authored in the
>> Confluence
>>>> wiki and exported to HTML automagically whereas the Artemis website is
>>>> authored in raw HTML. As a result, the two sites have a very different
>>> look
>>>> and feel to them. This presents some challenges to using the content
>>>> between the two.
>>>>
>>>> But this presents other questions -- do we want the two sites to look
>>>> similar or different? When someone looks at Artemis content, do we want
>>> the
>>>> user to immediately know that they are looking at ActiveMQ content vs.
>>>> Artemis based content solely due to the look and feel of the site?
>> Should
>>>> there even be two different sites?
>>>>
>>>> I would prefer to have the site authored in a language that is easier
>> to
>>>> write than HTML (such as Markdown). I would also like the files
>>> comprising
>>>> the site to live in a git repo. To give the site a modern look and feel
>>>> means using CSS (e.g., SASS, etc.). All these things can be achieved
>>> using
>>>> Jekyll, but first we would need to convert the raw HTML files to
>> Mardown
>>> to
>>>> put in git. I have experimented with some tools to convert HTML to
>>> Markdown
>>>> and they are less than ideal. Does anyone have any experience with
>> this?
>>>>
>>>> Sorry for the rambling. Anyone else interested to help tackle this
>> thorny
>>>> set of issues?
>>>>
>>>> Bruce
>>>>
>>>> --
>>>> perl -e 'print
>>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E> );'
>>>>
>>>> ActiveMQ in Action: http://bit.ly/2je6cQ
>>>> Blog: http://bsnyder.org/ <http://bruceblog.org/>
>>>> Twitter: http://twitter.com/brucesnyder
>>>
>>>
>>>
>>> --
>>> Clebert Suconic
>>>
>>
>
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bsnyder.org/ <http://bruceblog.org/>
> Twitter: http://twitter.com/brucesnyder
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Move PR discussions to another list...
They are different though… A PR discussion is exactly that… a discussion. If there are things in the PR discussions like code suggestions and back and forth about opinions on how something is done and such, they SHOULD be on the dev list as they are dev discussions. The commit is more “final”. That is also the reason that the “reply-to” field on the commit list is the dev list. If you reply to a commit, it’s starting a discussion which goes to the dev list. Thus, if we wanted to completely mimic the commits, it would be that the “Open PR” and “Close PR" emails would go to a different list, but any discussion/replys would go to the dev list. I’m not sure that buys much. Dan > On Dec 6, 2017, at 5:44 PM, Clebert Suconic wrote: > > You could use the same argument to have committs being fed here... > it's too noisy! > > On Wed, Dec 6, 2017 at 5:35 PM, Timothy Bish wrote: >> -1 >> >> Unless PR discussions can exist on the dev list I'm against moving that to >> another list as that is part of the development process. >> >> >> On 12/06/2017 05:34 PM, Clebert Suconic wrote: >>> >>> in my view... and in my plan... going forward now I plan to make more >>> discussions on the dev list.. especially around this Roadmap idea. >>> >>> >>> What if: >>> >>> - We move github traffic to another list.. (commit perhaps)? >>> - We can still use github to talk about spot on issues.. such as.. the >>> format here sucks... the logic here is not accurate.. etc.. etc... >>> which this is the kind of noise that's feeding this list like crazy. >>> . You could use the same argument to bring JIRA comments to the >>> dev list.. it would be too noise.. I believe that's been the case at >>> some point >>> >>> But if there is a meaningful discussion... then we would refer the >>> dev-list... just like as we do in other places. (JIRA, private list.. >>> etc.. etc) >>> >>> >>> That seems a reasonable thing to me. It would help us to be more >>> active on the dev list.. which is what we need now. >>> >>> >>> On Wed, Dec 6, 2017 at 5:20 PM, jgenender wrote: >>>> >>>> Daniel Kulp wrote >>>>> >>>>> I’m -0.5 on moving them. PR’s (and the conversations in them) are part >>>>> of >>>>> the development process and should be on the dev list. >>>> >>>> But the deluge often loses the discussion which is why some projects have >>>> commit lists. This is the difference between projects that work off PRs >>>> and >>>> projects whose committers mainly just commit directly to the repository. >>>> >>>> Unfortunately as pointed out earlier, the volume of noise created causes >>>> a >>>> certain amount of people to lose conversations. Some use Nabble, some >>>> use >>>> an email client. >>>> >>>> >>>> >>>> -- >>>> Sent from: >>>> http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html >>> >>> >>> >> >> -- >> Tim Bish >> twitter: @tabish121 >> blog: http://timbish.blogspot.com/ >> > > > > -- > Clebert Suconic -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] ActiveMQ Artemis becomes ActiveMQ 6
I’m +1 on starting the process of updating the websites and such to promote Artemis more and working toward getting it ready to become 6. That definitely means getting a roadmap started (nice job Bruce!) and doing some level of gap analysis between it and AMQ5. I personally think the “adoption argument” is bull shit. That’s like saying the Tomcat community cannot release Tomcat 9 until the adoption of "Tomcat 9 (beta)” becomes significant. That’s just dumb. So it really comes down to features and documentation/migration. Again, get a roadmap in place that documents what needs to be done, get docs and such updated, promote it as an alpha/beta/whatever to get those that are willing to test it to do so, and when it’s ready, we release as 6.0. (and, IMO, it doesn’t need to be perfect to be 6.0. We can always spin a 6.0.1 or 6.1 if folks run into issues that haven’t been found) Dan > On Dec 4, 2017, at 3:32 PM, Clebert Suconic wrote: > > Following on from the discussion, "[DISCUSS] Confusion surrounding the > ActiveMQ project roadmap" > > linked here for convenience : > - > http://activemq.2283324.n4.nabble.com/DISCUSS-Confusion-surrounding-the-ActiveMQ-project-roadmap-td4732935.html > - > http://activemq.2283324.n4.nabble.com/Re-DISCUSS-Confusion-surrounding-the-ActiveMQ-project-roadmap-td4733148.html > > > I would like to propose a vote on ActiveMQ Artemis mainline becoming ActiveMQ > 6. > > [+1] - agree > [-1] . - disagree and provide some reason > [0] - neutral but go ahead > > This vote will be open until Thursday, Dec 07 by the end of the day. > > Here is my +1 (PMC) vote. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Move PR discussions to another list...
I’m -0.5 on moving them. PR’s (and the conversations in them) are part of the development process and should be on the dev list. Dan > On Dec 6, 2017, at 10:00 AM, Clebert Suconic > wrote: > > Can we move the github PR discussions away to a different list... > > I suggest we create a list called hack...@activemq.apache.org > > We could use it for all the github PRs notifications.. and eventually > low level discussions. > > We should still keep general discussions on the dev list. > > > > That would probably improve communication style and decrease noise. > > > > > > And.. do I need a VOTE for that? or just consensus here? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Time for another ASF board report
> On Oct 19, 2017, at 11:09 AM, Bruce Snyder wrote: > Thank you for providing this info. The URL to the mailing list discussion > is especially helpful. > > The reason I am asking about this topic is due to the past issues that > arose around the use of the Hawt.io management console without seeking > consensus before making the changes (I cannot recall all the details off > the top of my head). I see that the Hawt.io console is being used for > Artemis, but it appears to have been achieved in a more transparent manner > via mailing list discussions and pull requests. Does all of the source code > for the management console exist in the git repo as part of the ActiveMQ > Artemis project? Yea… the main things that ended up different this time around are: 1) Branding - the old attempt was heavily branded hawt.io and it was difficult (or impossible at the time) to skin it into something that looks like it’s an Apache ActiveMQ console and not hawt.io. The new hawt.io frameworks provides extra hooks and stuff to allow much of it to be skinned. Thus, the only mention of hawt.io is a “powered by” type link. It really “looks” like an ActiveMQ/Artemis console. 2) Functionality - the ActiveMQ “plugins” that provided the functionality in the old console was provided by the hawt.io community and not the ActiveMQ folks. With this new effort, it’s now completely provided by the Artemis folks and built/tested as part of Artemis. If the Artemis users don’t like something or want to add something, they submit ideas to *US*. This was super important. 3) With the skinning in (1), it is also possible to remove much of the stuff that is NOT related to ActiveMQ/Artemis.All the user sees in the console is stuff related to ActiveMQ/Artemis. It isn’t a marketing vehicle for other (external) projects and products. 4) Community involvement - obviously the other part was the fact that it was all pretty much discussed on the dev list, requirements laid out, several reviews by various people during the process, etc… Basically, the old controversial attempt was taking hawt.io “as is” and dropping it in to ActiveMQ AS the console and the hawt.io community was the one completely driving anything related to it. The new effort treats hawt.io as a framework to build a console on top of with the ActiveMQ community driving the final usability and appearance. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Time for another ASF board report
Bruce,
> On Oct 18, 2017, at 2:04 PM, Bruce Snyder wrote:
>
> There was a comment regarding Artemis added to the board report that
> mentioned the following:
>
> 'An embedded web management console was added'
>
> What embedded web management console is this? Was it built from the ground
> up or was it adopted from something else?
It uses hawt.io as a framework, but there were extensive requirements set forth
that we able to be met with the newer setup. See the summary at:
https://lists.apache.org/thread.html/ea23d51f254690a905caf064cbd11610773dc3dc9015c10319b7d826@%3Cdev.activemq.apache.org%3E
And the links in that email. Basically, all the hawt.io branding is removed
and replaced with ActiveMQ branding, all of stuff not related to ActiveMQ is
removed/hidden, and all of the ActiveMQ/Artemis functionally is provided by
plugins created and maintained here at Apache.
Dan
> Bruce
>
>
> On Tue, Oct 10, 2017 at 9:28 AM, Bruce Snyder
> wrote:
>
>> Thank you for taking the time, Robbie.
>>
>> Bruce
>>
>> On Fri, Oct 6, 2017 at 9:18 AM, Robbie Gemmell
>> wrote:
>>
>>> I've added some initial notes.
>>>
>>> Robbie
>>>
>>> On 5 October 2017 at 15:54, Bruce Snyder wrote:
>>>> It is time to create a report for the ASF board for October. Please
>>> take 5
>>>> minutes and contribute to the report available at the following URL:
>>>>
>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?
>>> pageId=74681966
>>>>
>>>> Please contribute any project activity from any of the ActiveMQ
>>> subprojects.
>>>>
>>>> This report will be submitted on 10 Oct.
>>>>
>>>> Bruce
>>>> --
>>>> perl -e 'print
>>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E>> );'
>>>>
>>>> ActiveMQ in Action: http://bit.ly/2je6cQ
>>>> Blog: http://bsnyder.org/ <http://bruceblog.org/>
>>>> Twitter: http://twitter.com/brucesnyder
>>>
>>
>>
>>
>> --
>> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&
>> 5R\"F)R=6-E+G-N>61E>
>> ActiveMQ in Action: http://bit.ly/2je6cQ
>> Blog: http://bsnyder.org/ <http://bruceblog.org/>
>> Twitter: http://twitter.com/brucesnyder
>>
>
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bsnyder.org/ <http://bruceblog.org/>
> Twitter: http://twitter.com/brucesnyder
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] release process improvements
t;>>>>>> svn cp -m "add files for activemq-artemis-2.3.0" >>>>>>>>> >>>>> >>>>> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.3.0-rc1 >>>>> >>>>> https://dist.apache.org/repos/dist/release/activemq/activemq-artemis/2.3.0 >>>>>>>>> >>>>>>>>> Robbie >>>>>>>>> >>>>>>>>> On 13 September 2017 at 17:52, Clebert Suconic >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> I actually see how to make the copy into dev... let me play with it >>>>> >>>>> a >>>>>>>>>> >>>>>>>>>> little bit >>>>>>>>>> >>>>>>>>>> On Wed, Sep 13, 2017 at 12:44 PM, Clebert Suconic >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> what about this: >>>>>>>>>>> >>>>>>>>>>> Currently mvn release and mvn upload will always send the release >>>>> >>>>> to >>>>>>> >>>>>>> nexus, >>>>>>>>>>> >>>>>>>>>>> So what about: >>>>>>>>>>> >>>>>>>>>>> - we provide an script to artemis to download the correct bits of >>>>> >>>>> the >>>>>>>>>>> >>>>>>>>>>> release, the release manager would use that script to perform such >>>>>>>>>>> download. >>>>>>>>>>> - The release manager would place it on the dev repository Robbie >>>>> >>>>> is >>>>>>>>>>> >>>>>>>>>>> mentioning... (that means.. we wouldn't really have an extra step). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On thing I'm not sure how to do is... how to upload it to the dev >>>>> >>>>> dist >>>>>>>>>>> >>>>>>>>>>> at https://dist.apache.org/repos/dist/dev/activemq/ >>>>>>>>>>> >>>>>>>>>>> and how we would make the final move? just a regular copy? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Sep 13, 2017 at 9:49 AM, Robbie Gemmell >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 13 September 2017 at 14:35, Clebert Suconic >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Sep 13, 2017 at 9:21 AM Robbie Gemmell < >>>>>>> >>>>>>> robbie.gemm...@gmail.com> >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> This was less about time, though there is some benefit in that >>>>>>> >>>>>>> regard, >>>>>>>>>>>>>> >>>>>>>>>>>>>> with how much depending on how particular people actually verify >>>>>>> >>>>>>> the >>>>>>>>>>>>>> >>>>>>>>>>>>>> checksums I guess. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Actually this is kind of moot. nexus does that check for you. >>>>> >>>>> You >>>>>>> >>>>>>> cannot >>>>>>>>>>>>> >>>>>>>>>>>>> upload a release with a checksum broken. It won't let you close. >>>>>>>>>>>>> >>>>>>>>>>>>> Like. Last week I had to restart the release once because MVN >>>>>>> >>>>>>> upload broke >>>>>>>>>>>>> >>>>>>>>>>>>> the checksum somewhere. >>>>>>>>>>>>> -- >>>>>>>>>>>>> Clebert Suconic >>>>>>>>>>>> >>>>>>>>>>>> Whether the files in Nexus are ok isn't sufficient. The archives >>>>> >>>>> and >>>>>>>>>>>> >>>>>>>>>>>> checksum files in the dist repo are the mirrorer official release >>>>>>>>>>>> artifacts (and strictly only the source ones at that), and Nexus >>>>> >>>>> cant >>>>>>>>>>>> >>>>>>>>>>>> check those. There could be a problem deploying those bits for a >>>>>>>>>>>> variety of reasons, so we check they are ok. Users downloading the >>>>>>>>>>>> release archives also tend to grab the checksums from the dist >>>>> >>>>> repo >>>>>>>>>>>> >>>>>>>>>>>> because that is their official source, in order to verify >>>>> >>>>> downloads >>>>>>>>>>> >>>>>>>>>>> >>> >>> -- >>> Tim Bish >>> twitter: @tabish121 >>> blog: http://timbish.blogspot.com/ >>> > > > > -- > Clebert Suconic -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] release process improvements
Just to be clear… This proposal creates more work for the release manager prior to starting the vote but in hopes of reducing the work for the reviewers. It’s a bit more than a “mvn release:prepare ; man release:perform”. Some of the extra work can obviously be scripted, but it is still a bit more to do. That said, script provided to the reviewer could accomplish the same things using the current staging location/setup. Anyway, I’m -0 to the idea.Getting folks to actually be a release manager is hard enough, why make it even more work.Since I haven’t been a release manager for an ActiveMQ release in a while, I certainly wouldn’t hold up the idea though. Dan > On Sep 12, 2017, at 9:49 AM, Robbie Gemmell wrote: > > Hi folks, > > I mentioned on the recent Artemis 2.3.0 vote that I had some suggested > changes for the release process improvements, not just for Artemis but > for other components too, and would send a mail later. > > The short version is there are three main things I'd like to suggest > as improvements, both for folks testing+voting, and end users > downloading the release later: > - Using the dist dev repo for publishing bits for folks to test and vote on. > - Providing checksum files in the dist repo which verify more easily > with the related tools. > - Use SHA512 rather than SHA1 for checksums in the dist repo. > > # Dist dev repo for votes > > Currently the ActiveMQ votes for the Java components tend to link to > the artifacts in the nexus staging repo. I think using the dist dev > repo (https://dist.apache.org/repos/dist/dev/activemq/) to publish the > bits under vote would be an improvement. Its easy for folks to grab > all the files at once, helps ensure that what people test is actually > what will end up in the dist release repo later, and it simplifies the > eventual release step to a single svn remote copy command. > > # Provide more easily verifiable checksum files in dist release repo > > Currently, the checksum files provides in the dist release repo are > just the ones from nexus. These lack filename information and so you > cant verify them as easily with tools. Files which contain the > filename detail can be verified quickly and even grouped in a single > shot with the checksum tools, e.g "md5sum -c *.md5". For the MD5 and > SHA1 cases they could be prepared either by manipulating the existing > files taken from nexus to add the names, or simply generating the > checksums again with the tools and manually verifying them the same > way everyone currently needs to. > > # Provide SHA512 checksum files in the dist repo > > The release distribution policy has suggested using SHA512 for some > time now, I think it would be good to make the switch for the files > provided in the dist repo. > http://www.apache.org/dev/release-distribution.html#sigs-and-sums > > Robbie -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSSS] Web Management Console for Artemis.
>>> from a powered by. >>>>>>> Help and about pages should be ActiveMQ Artemis focussed >>>>>>> Provide functionality to manage the broker >>>>>>> This should be able to expand over time >>>>>>> License/Notice files and any legal requirements are updated/met >>>>>>> The war size should be kept to a minimum >>>>>>> Login/Security should be integrated to the broker roles/users >>>>>>> Plugins/customisation specific to AcitveMQ Artemis to reside in >>> ActiveMQ Artemis project. >>>>>>> >>>>>>> Also we had some good early feedback in the community on the missing >>> bits in our early PR, of bits that needed/must be addressed. (thanks to >>> Dan, Clebert, Martyn). >>>>>>> >>>>>>> We believe we have a viable “agreeable" solution to provide a web >>> console admin for Apache ActiveMQ Artemis. >>>>>>> >>>>>>> As such we don’t see any reason to hold off and would like to bring >>> your attention (again) to the PR please make any standard review comments >>> there. >>>>>>> >>>>>>> https://github.com/apache/activemq-artemis/pull/1385 < >>> https://github.com/apache/activemq-artemis/pull/1385> >>>>>>> >>>>>>> Also there has been a small discussion on how to release this, so >>> that we can start to get end user feedback, as users tend to want a built >>> usable distribution, like wise there is concern of bundling this into the >>> next release. >>>>>>> >>>>>>> We propose: >>>>>>> We will release the upcoming next version of Apache ActiveMQ >> Artemis, >>> WITHOUT the new web console. This is due to occur in the coming week. >>>>>>> We will then subsequently look to merge and release another version >>> of Apache ActiveMQ Artemis WITH the console, so it is in a clean release >>> with only the addition of the web console. This should occur almost >>> immediately after. >>>>>>> >>>>>>> I should thank Clebert and Martyn in offering to run the extra >>> release this would require, but de-risk some community concerns. >>>>>>> >>>>>>> This solution is based off a hawtio framework, i would like to >>> iterate i am not a RedHat employee, nor anything to do with Hawtio >> project. >>> I work for a company that uses the project like other end users, and >> simply >>> see it as a framework to enable us in activemq to deliver a usable web >>> management console for artemis with as little cost, effort and >> maintenance >>> as possible, to provide an immediate need in the user community. >>>>>>> >>>>>>> Many thanks >>>>>>> Mike >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Tim Bish >>>>> twitter: @tabish121 >>>>> blog: http://timbish.blogspot.com/ >>>>> >>> >>> >>> >>> -- >>> Clebert Suconic >>> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [GitHub] activemq-artemis issue #1385: ARTEMIS-1270 Management Console - Hawtio Solut...
> On Jul 6, 2017, at 1:00 PM, Michael André Pearce > wrote: > > My view on 2 is that currently there is no capability having anything is > better than none. > > Any extra features can be added over time by those willing to contribute. > > Indeed there are some bits I'd like to add but having something is better > than nothing and certainly can now start the ball rolling. Well, yes and no.Once "released", you kind of have to build off of what’s there and continue to support that way of doing things. If what’s there doesn’t make any sense and needs to be completely re-organized or something, that could be difficult if we have to continue supporting the current layout. Kind of like a backwards compatibility thing.I’d like a few folks to make sure that what’s there makes some sense going forward and adding the stuff that is missing can be done by extending what’s there in a way that makes sense. That said, for the first release, if we kind of release note the console as a “technology preview, subject to change” or similar, I’d be less concerned. Dan > > Sent from my iPhone > >> On 6 Jul 2017, at 17:21, Daniel Kulp wrote: >> >> >>> On Jul 6, 2017, at 10:15 AM, Clebert Suconic >>> wrote: >>> >>> It seems that this is almost ready.. if we fix logging it could be merged... >>> >>> >>> It would be awesome if we could have the next release with this >>> already... even if we delay another week. >>> >>> >>> @Dan: WDYT? >> >> Well, there are basically 4 “types” of things that need to be taken care of: >> >> 1) Branding/skinning/packaging : this is what my lists have been >> concentrating on. Things are certainly looking better there. I just did a >> build and things look much better. I’m “slightly” concerned about the >> downgrade from 1.5.2 to 1.5.0 which I’m assuming is due to the flight >> recorder stuff. Certainly OK for now, but longer term I think we’d like a >> better option so that we can get whatever security fixes are needed in >> future versions.There are some additional options to trim the war even >> further such as an overlay config of: >> >> >> >> io.hawt >> hawtio-web >> >> bower_components/**/* >> app/site/**/* >> app/core/**/* >> >> >> >> >> 2) Actual capabilities : I haven’t looked at this at all. Art had a list >> of things he expected to be able to manage based on the capabilities of the >> 5.x console. I’m not sure if his list is completely covered by the new >> plugin or not as I haven’t looked at this aspect. >> >> >> 3) Integration : there are gaps here related to logging, security, >> user/roles, etc… For testing, we’re currently bypassing all of this. >> >> 4) Legal : There are MAJOR updates needed for the License/Notice files. >> It’s a shame that the hawt.io folks aren’t doing this properly and meeting >> the legal requirements of the licenses of everything they are including. >> Just means we’re going to have to do it. This is the big thing as I have >> no idea how long this will take. For every file in the war (and every file >> within the jars within the war), we need to check it’s license status and >> figure out what needs to be added to the license and notice files. That’s >> not trivial.With the above excludes, large chunks of things go away (the >> bootstrap/docs for example are CC-BY which has notice requirements) so there >> is less work to do, but there are still a bunch of things in there. >> >> >> Because 4 is a big “unknown” and I have no idea on 2, I really wouldn’t hold >> up the current releases for it.In addition, since this is a “big >> change”, I’d certainly want to make sure the rest of the community that >> hasn’t looked at it gets a good chance to do so prior to a release. Gut >> feeling is that this is much more than a “3-4 day delay”. >> >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [GitHub] activemq-artemis issue #1385: ARTEMIS-1270 Management Console - Hawtio Solut...
> On Jul 6, 2017, at 10:15 AM, Clebert Suconic > wrote: > > It seems that this is almost ready.. if we fix logging it could be merged... > > > It would be awesome if we could have the next release with this > already... even if we delay another week. > > > @Dan: WDYT? Well, there are basically 4 “types” of things that need to be taken care of: 1) Branding/skinning/packaging : this is what my lists have been concentrating on. Things are certainly looking better there. I just did a build and things look much better. I’m “slightly” concerned about the downgrade from 1.5.2 to 1.5.0 which I’m assuming is due to the flight recorder stuff. Certainly OK for now, but longer term I think we’d like a better option so that we can get whatever security fixes are needed in future versions.There are some additional options to trim the war even further such as an overlay config of: io.hawt hawtio-web bower_components/**/* app/site/**/* app/core/**/* 2) Actual capabilities : I haven’t looked at this at all. Art had a list of things he expected to be able to manage based on the capabilities of the 5.x console. I’m not sure if his list is completely covered by the new plugin or not as I haven’t looked at this aspect. 3) Integration : there are gaps here related to logging, security, user/roles, etc… For testing, we’re currently bypassing all of this. 4) Legal : There are MAJOR updates needed for the License/Notice files. It’s a shame that the hawt.io folks aren’t doing this properly and meeting the legal requirements of the licenses of everything they are including. Just means we’re going to have to do it. This is the big thing as I have no idea how long this will take. For every file in the war (and every file within the jars within the war), we need to check it’s license status and figure out what needs to be added to the license and notice files. That’s not trivial. With the above excludes, large chunks of things go away (the bootstrap/docs for example are CC-BY which has notice requirements) so there is less work to do, but there are still a bunch of things in there. Because 4 is a big “unknown” and I have no idea on 2, I really wouldn’t hold up the current releases for it.In addition, since this is a “big change”, I’d certainly want to make sure the rest of the community that hasn’t looked at it gets a good chance to do so prior to a release. Gut feeling is that this is much more than a “3-4 day delay”. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Removing the Web Console
> On Jul 5, 2017, at 2:39 PM, Michael André Pearce > wrote: > > Re point 2) license file out of date- I'm reading this as a more general > issue with artemis license not upto date , if this is the case could someone > else pick this one up? The main thing I noticed was the json.org license still in there. Since we haven’t depended on that for almost a year now (ARTEMIS-565) (and Apache projects CANNOT depend on it anymore), that just jumped out at me as something that was obviously wrong. I went ahead and removed those. Not saying that there are things that belong in there that aren’t, but at least the json.org part is now fixed on master. Dan > > Sent from my iPhone > >> On 5 Jul 2017, at 18:45, Clebert Suconic wrote: >> >>> On Wed, Jul 5, 2017 at 1:25 PM, Daniel Kulp wrote: >>> Started doing a quick look through this (really, just a build, run with. >>> help from IRC channel to get past login issue, poke around) and it’s >>> definitely “very early” and still needs quite a bit of work, but for the >>> most part, a good start. >>> >>> From my “5 minute poke around”: >>> >>> 1) URL and page titles need to have hawtio removed and changed. >> >> >> You're trying to hide the fact we used hawtio? >> >> that's different from implying to be made by Apache or not. what's the >> issue on that? >> >> >> The other points seem ok to me.. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Removing the Web Console
o if in the future a better viable option is chaired, then this can be >>>> replaced, but for now at least this provides an out the box solution which >>>> as already stated myself and other users are crying out for. >>>> >>>> >>>> As per the minimum things we needed to address which Dan kindly bulleted >>>> for us, to make this acceptable, i believe I have met all the minimum bar >>>> requirements now. >>>> >>>> = >>>> >>>> I discussed previously, what would NEED to be done for this to be >>>> “acceptable”: >>>> >>>> 1) All branding/links/etc… in the console need to be re-skinned or >>>> whatever to be “ActiveMQ”. All mentions of hawtio and links off to other >>>> sites other than a possible small “powered by” type thing would need to be >>>> removed. >>>> >>>> 2) All “plugins” and functionality that don’t pertain to things related to >>>> ActiveMQ would need to be removed. >>>> >>>> 3) The “plugin" that presents ActiveMQ related stuff to the user MUST live >>>> here at Apache and part of the ActiveMQ community. We cannot use the one >>>> they provide (unless you can convince them to donate it to Apache). >>>> >>>> = >>>> >>>> 1 - Done - See screenshots. (one note as per community feedback is for me >>>> to add a poweredBy logo , i can easily do this) >>>> 2 - Done - See screenshots >>>> 3 - Done - As per mail thread it seems they’re willing to donate this. >>>> >>>> Cheers >>>> Mike >>>> >>>> >>>> >>>>> On 4 Jul 2017, at 18:57, artnaseef wrote: >>>>> >>>>> Please catch me up here - are we saying that the Artemis built-in web >>>>> console will be running HawtIO??? >>>>> >>>>> Art >>>>> >>>>> >>>>> On Tue, Jul 4, 2017 at 7:15 AM, rajdavies [via ActiveMQ] < >>>>> ml+s2283324n4728199...@n4.nabble.com> wrote: >>>>> >>>>>> On the “about” page - it would be polite to reference the hawtio >>>>>> comunity >>>>>> - i.e. “Artemis Management console is powered by hawtio: hawt.io < >>>>>> http://hawt.io/>” etc - as there is no powered by logo. >>>>>> >>>>>>> On 3 Jul 2017, at 23:52, Michael André Pearce <[hidden email] >>>>>> <http:///user/SendEmail.jtp?type=node&node=4728199&i=0>> wrote: >>>>>>> >>>>>>> Ok, >>>>>>> >>>>>>> So i think we can do this. From a local build. >>>>>>> >>>>>>> Please see screenshots. >>>>>>> >>>>>>> https://gist.github.com/michaelandrepearce/ >>>>>> 98b4be98d20f407c2d745a41df9cef03 <https://gist.github.com/ >>>>>> michaelandrepearce/98b4be98d20f407c2d745a41df9cef03> >>>>>>> >>>>>>> For 1) I think we have managed to completely skin it, with all hawtio >>>>>> references removed, even the favicon. >>>>>>> For 2) Only the artemis plugin and base jvm plugins, no extras for any >>>>>> other products. >>>>>>> For 3) Im hoping we can come to agreement on this gets contributed in >>>>>> from the rh-messaging project @clebert @martyn @andy?, if not we can >>>>>> probably code up a simpler version of it for now without bells and >>>>>> whistles, and add in the future features later. >>>>>>> >>>>>>> So if we sort point three, i think we can make this “acceptable” >>>>>>> >>>>>>> Cheers >>>>>>> Mike >>>>>>> >>>>>>>> On 29 Jun 2017, at 19:17, Daniel Kulp <[hidden email] >>>>>> <http:///user/SendEmail.jtp?type=node&node=4728199&i=1>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Jun 29, 2017, at 1:59 PM, Michael André Pearce <[hidden email] >>>>>> <http:///user/SendEmail.jtp?type=node&node=4728199&i=2> <mailto:[hidden >>>>>> email] <http:///user/SendEmail.jtp?type=node&node=4728199&i=3>&
Re: [DISCUSS] Removing the Web Console
> On Jun 29, 2017, at 1:59 PM, Michael André Pearce > wrote: > > I believe we could make a simple activemq branding jar/war with the selected > new logo ;) once decided without too much trouble. > > I'd be happy to step up to try do this if no objectors. I discussed previously, what would NEED to be done for this to be “acceptable”: 1) All branding/links/etc… in the console need to be re-skinned or whatever to be “ActiveMQ”. All mentions of hawtio and links off to other sites other than a possible small “powered by” type thing would need to be removed. 2) All “plugins” and functionality that don’t pertain to things related to ActiveMQ would need to be removed. 3) The “plugin" that presents ActiveMQ related stuff to the user MUST live here at Apache and part of the ActiveMQ community. We cannot use the one they provide (unless you can convince them to donate it to Apache). Unless all three happen, it’s a no-go. Dan > >> On 29 Jun 2017, at 16:51, Clebert Suconic wrote: >> >> Speaking the plain truth... The issue is that the hawtio console that >> was used years ago.. looked like a commercial product outside of >> apache >> >> I think that if we clear that now.. if it looks an apache look & >> feel.. people wouldn't have an issue with it. >> >> >> That would require some cleanup.. move to a newer hawtio plugin maybe? >> that's when we thought about trying new routes if we would need to do >> a lot of work anyways. >> >> On Thu, Jun 29, 2017 at 11:42 AM, Michael André Pearce >> wrote: >>> I don't think this is a blocker, for example artemis uses jboss logging, >>> this doesn't have a notice file >>> >>> I think we just have to preserve them if present and for asf projects >>> themselves eg artemis itself it's policy to provide one for the asf work. >>> >>> Sent from my iPhone >>> >>>> On 29 Jun 2017, at 01:09, W B D wrote: >>>> >>>> I've been using hawtio alongside the classic web console in ActiveMQ 5.x >>>> and have been quite happy with it. I find it easier to use for many common >>>> operations as well as for general monitoring, and it is definitely a gap in >>>> the current Artemis distribution, so I would certainly welcome built-in >>>> hawtio support as a good addition. >>>> >>>> Although the source code already contains the standard license assignment >>>> to ASF, it does not include a NOTICE file. We could ask Redhat for one, or >>>> construct one crediting them with the original work, or add a stanza to the >>>> top-level NOTICE file if that is more appropriate. IMO, the package and >>>> class name org.jboss.plugin.PluginContextListener could probably be changed >>>> in our copy, both to establish custody and to give a clearer name. >>>> >>>> On Wed, Jun 28, 2017 at 9:27 AM, MichaelAndrePearce < >>>> michael.andre.pea...@me.com> wrote: >>>> >>>>> Hi Guys, >>>>> >>>>> It's been some time since this discussion thread without seemingly any >>>>> movement. >>>>> >>>>> Artemis Project is really suffering from having any kind of management >>>>> console. With continued questions and calls from users especially as it's >>>>> picking up traction and deployment. >>>>> >>>>> As such could I propose, that as lack of movement on any other solution >>>>> and >>>>> Hawtio is pretty much in a usable state, with a plugin also out there in >>>>> the >>>>> wild. (It's ASL) >>>>> >>>>> That for the interim on artemis project we build and release with Hawtio >>>>> and >>>>> an artemis plugin (if RH would donate their plugin to artemis project?) >>>>> >>>>> Any objectors? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: http://activemq.2283324.n4. >>>>> nabble.com/DISCUSS-Removing-the-Web-Console-tp4717136p4728020.html >>>>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. >>>>> >> >> >> >> -- >> Clebert Suconic -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache ActiveMQ 5.14.4
+1 Dan > On Feb 27, 2017, at 9:03 AM, Christopher Shannon > wrote: > > Hi Everyone, > > I have created the ActiveMQ 5.14.4 release and it's ready for a vote. > > The list of resolved issues is here: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12338909 > > You can get binary distributions here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1118/org/apache/activemq/apache-activemq/5.14.4/ > > Source archives are here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1118/org/apache/activemq/activemq-parent/5.14.4/ > > Maven repository is at: > https://repository.apache.org/content/repositories/orgapacheactivemq-1118/ > > Source tag: > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=308eab0bb63136871e2c1c8f179a6cd2e458de5f > > Please vote to approve this release. The vote will remain open for 72 > hours. > > [ ] +1 Release the binary as Apache ActiveMQ 5.14.4 > [ ] -1 (provide specific comments) > > Here's my +1 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Move Apache.NMS project to Git
> On Feb 21, 2017, at 9:11 PM, Jim Gomes wrote: > > I guess I didn't explain the requirements clearly. Tagging is not the > solution. This is about automatically injecting the revision of the source > code that was used to build the product. For example, let's say the > Subversion repository is at revision number 18634. I am building > Apache.NMS version 1.7.0. When I run my build, it will automatically > produce an assembly with the embedded version number 1.7.0.18634. That > last number can't be a hash. Why can’t it be a hash? Or at least the git short hash? That’s the exact revision id for git so if that is what the purpose is, then that is what should go there. > If I were to commit any change at all (not > necessarily creating a tag or branch, just a change), then the repository > would increment to 18635. If I build again, it would produce Apache.NMS > 1.7.0.18635. Automatically. This way there is no confusion as to what > exact revisions went into creating that assembly, and I have a reproducible > build. And the has accomplishes the same thing if the goal is a reproducible build. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: What is the current status and plans for the web-console?
> On Feb 17, 2017, at 8:52 AM, Clebert Suconic > wrote: > > On Fri, Feb 17, 2017 at 4:48 AM, Christian Schneider > wrote: >> I have read the old threads about the web console. >> >> If I understood correctly then we would like to get rid of the current >> activemq web console but need a replacement. There is hawt.io which >> functionally would work but which is not compatible from a community >> standpoint. > > My understand was: as long as it looked like an apache console, and > not a commercial product belonging to any company it would be ok. > *AND* all of the ActiveMQ/Artemis related bits are written and maintained here at Apache as part of this community. How the queues and brokers and such are presented to the user is completely under the control of this community. In other words: we don’t take the activemq plugin or whatever they have and use it as is. (Unless they want to donate it to this community) -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache ActiveMQ 5.14.3
+1 Dan > On Dec 19, 2016, at 10:49 AM, Christopher Shannon > wrote: > > Hi Everyone, > > I have created the ActiveMQ 5.14.3 release and it's ready for a vote. > This release contains 7 important fixes that didn't make it into the > last release. > > The list of resolved issues is here: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12338822 > > You can get binary distributions here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1113/org/apache/activemq/apache-activemq/5.14.3/ > > Source archives are here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1113/org/apache/activemq/activemq-parent/5.14.3/ > > Maven repository is at: > https://repository.apache.org/content/repositories/orgapacheactivemq-1113/ > > Source tag: > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=58dddb9181912bee60fec480d90e05be4ca3a044 > > Please vote to approve this release. The vote will remain open for 72 hours. > > [ ] +1 Release the binary as Apache ActiveMQ 5.14.3 > [ ] -1 (provide specific comments) > > Here's my +1 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[RESULT] [VOTE] ActiveMQ 5.13.5
There are 7 +1 votes and not other votes. This vote passes. Dan > On Dec 16, 2016, at 2:23 PM, Daniel Kulp wrote: > > This is a vote to release Apache ActiveMQ 5.13.5, a new patch release that > includes a couple high importance fixes. > > Release notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12337971 > > > Staging repository: > https://repository.apache.org/content/repositories/orgapacheactivemq-1112/ > > Binary Tarballs: > https://repository.apache.org/content/repositories/orgapacheactivemq-1112/org/apache/activemq/apache-activemq/5.13.5/ > > Source Tarballs: > https://repository.apache.org/content/repositories/orgapacheactivemq-1112/org/apache/activemq/activemq-parent/5.13.5/ > > Tag: > https://git1-us-west.apache.org/repos/asf?p=activemq.git;a=tag;h=3867d32f6c4e0afdce609c6659be215edcaa64dd > > Please test this release candidate and cast your vote. > [ ] +1 Release the binary as Apache ActiveMQ 5.13.5 > [ ] -1 Don’t release (provide specific comments) > > The vote is open for at least 72 hours. > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[VOTE] ActiveMQ 5.13.5
This is a vote to release Apache ActiveMQ 5.13.5, a new patch release that includes a couple high importance fixes. Release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12337971 Staging repository: https://repository.apache.org/content/repositories/orgapacheactivemq-1112/ Binary Tarballs: https://repository.apache.org/content/repositories/orgapacheactivemq-1112/org/apache/activemq/apache-activemq/5.13.5/ Source Tarballs: https://repository.apache.org/content/repositories/orgapacheactivemq-1112/org/apache/activemq/activemq-parent/5.13.5/ Tag: https://git1-us-west.apache.org/repos/asf?p=activemq.git;a=tag;h=3867d32f6c4e0afdce609c6659be215edcaa64dd Please test this release candidate and cast your vote. [ ] +1 Release the binary as Apache ActiveMQ 5.13.5 [ ] -1 Don’t release (provide specific comments) The vote is open for at least 72 hours. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Back porting to 5.13.x
I’m going to back port the web-console fix and a couple others to 5.13.x and hopefully do a 5.13.5 release later this week. If there are other fixes that could/should be pulled back, please let me know. Thanks! -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
CachedLDAPAuthorizationMap in blueprint....
While debugging an issue for a client, I discovered that the CachedLDAPAuthorizationMap isn’t working “correctly” with blueprint and would like advice on how to fix it. Basically, in Spring, the CachedLDAPAuthorizationMap implements the InitializingBean and DisposableBean interfaces so Spring will call the afterPropertiesSet method right after creation so it can query the LDAP server and get the ACL’s. In blueprint, however, nothing calls the afterPropertiesSet method so it’s not until the first “update” that the ACL’s are queried so any attempt to create topics or anything before then would be denied. I can think of a few options to fix it: 1) Least potential for impact: add a atomic boolean flag of “queried” that is set to false at creation, set to true on first query, and any attempt to read ACL’s will call the query method if it hasn’t been called before. 2) Add @PostContruct and @PreDestroy annotations to CachedLDAPAuthorizationMap so blueprint will call the methods. Not sure what spring would do if an object implements the interfaces AND has the annotations though. 3) Create a separate blueprint subclass and somehow get blueprint to create the subclass version which has the annotations on it. Not sure how to do this though. Anyway, thoughts? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Removing the Web Console
I guess the first question that needs to be determined is if this will be done in the Artemis git repo or if we should create a new repo for this (so it could be shared for both 5.x and Artemis). If a new repo, then just get the repo created and start committing code. Don’t bother with the pull request, just start working on it and continue discussing it here. From my standpoint, I’m quite OK with a separate repo. Dan > On Oct 7, 2016, at 6:43 PM, Clebert Suconic wrote: > > I think this is pretty straightforward: > > i - it should relay on JMX or jolokia.. A common thing between both > Artemis and ActiveMQ > > ii - it should manage at least a single broker.. with some metrics... > > > iii - anything beyond that will just be a collaboration over the code. > > > The best way to discuss this IMO would be through a Pull Request.. > someone send an initial draft.. we can have some **technical** > discussion over of PR, and commit it as version 1... then > collaboratively this could be increased just as with anything else. > > > > I think we are clear from the previous discussions... and that's a > request I am making here, probably the third time... lets CTRL-Alt-Del > and start fresh... The issues we had are clear... and I see everybody > with a single goal here.. to have an integrated console that looks > like an Apache project, pretty and neat. > > > Once someone put a first version, we can only improve it from there. > > On Fri, Oct 7, 2016 at 12:17 PM, Hadrian Zbarcea wrote: >> I would suggest discussing the goals for such a console first. Is it >> intended to monitory just one broker instance or a whole network of brokers? >> Should it manage just the brokers or other services? Should it rely on JMX >> or something else? >> >> Then one can think about reusing and/or improving something that's available >> or some other solution. >> >> The way this discuss goes, sounds to me like trying to push again for >> something that was rejected in the past and I suspect will not go anywhere. >> >> My $0.02, >> Hadrian >> >> >> On 10/07/2016 06:41 AM, Martyn Taylor wrote: >>> >>> +1 on improving/adding a console. Providing a console out of the box is a >>> massive win for user experience imo and something that I feel Artemis >>> would >>> greatly benefit from. Whether it's HawtIO or something else we should >>> make >>> every effort to standardise across both 5.x and Artemis. >>> >>> On Tue, Oct 4, 2016 at 5:11 PM, Clebert Suconic >>> >>> wrote: >>> >>>> On Tue, Oct 4, 2016 at 11:57 AM, John D. Ament >>>> wrote: >>>>> >>>>> @Hiram >>>>> >>>>> The website branding says otherwise (take a look at the top right >>>> >>>> corner). >>>> >>>> >>>> That symbol on the top is just a link to the following: >>>> >>>> "Like hawtio? It’s part of a community of Red Hat projects. Learn more >>>> about Red Hat and our open source communities:" >>>> >>>> >>>> >>>> No other implications from what I see. >>>> >>> >> > > > > -- > Clebert Suconic -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Removing the Web Console
> On Sep 30, 2016, at 2:31 PM, Clebert Suconic > wrote: > so... IMO, the Web console needs to look an apache product.. > regardless of what components you use. if someone can provide a clean > and nice implementation.. using whatever frameworks or components that > are apache (or compatible) license, I think that's a reasonable > consideration. It’s a bit more than that….It cannot be used to promote other 3rd party things. Thus, other than a small “powered by” logo or similar in a non-prominant place, no other links out. Also, all the non-ActiveMQ-essential things need to be able to be stripped out. Second, all the code related to interfacing and interacting with ActiveMQ/Artemis needs to be part of the ActiveMQ community. This goes beyond branding. Using the current ActiveMQ “plugin" from Hawt io is NOT ok unless all of that can be moved into the Apache community (which the developers did NOT want to do last time this was discussed). Basically, how ActiveMQ is presented to the user MUST be completely under the control of the ActiveMQ community, not some other community. Dan > > And with git / github, we can first propose how it will look like, and > merge when it's pretty and ready. That's also a difference from 2 or 3 > years ago when these discussions were taking place, where even if git > was being used the workflow was pretty much the same svn style. > > I won't be able myself to work on this for a few weeks as I am working > on a few improvements around replication, that I want to do for 1.5.0. > but I think this would open the possibility of someone else looking > into that.. both from AMQ5 and/or Artemis perspective. > > so if you (anyone) start working around this give us a sign here, so > there wouldn't be two people working on the same task. > > > A request I make is.. lets start fresh and do something cool and nice... ;) > > On Fri, Sep 30, 2016 at 11:14 AM, jgenender wrote: >> clebertsuconic wrote >>> I don't want to read that discussion again.. but from what I remember >>> of what I once read, and after I talked to some guys in person, the >>> issue was where the component would live.. like the plugin being >>> outside of AMQ5 code. >>> >>> I believe that if we consumed hawt-io as a component (just like we >>> consume Jetty), and have the plugins, checkstyles, apache branding, >>> activemq5 and Artemis brand on the main repo, it shouldn't be an >>> issue. >> >> I wouldn't speculate. I wouldn't even attempt it unless you have examined >> the issues and do a 5 minute perusal on the thread. I won't argue what it >> was because I, and some other non-Red Hat folks were central to that >> discussion. >> >> My recommendation... don't rehash that. Look at the primary problems were >> (tl;dr; I mentioned them previously). Come up with a reasonable community >> based solution to the issues and present them. >> >> That said, I think branding would help significantly as long as any other >> concerns are resolved. I do know that templating it was certainly one of >> the offered solutions. >> >> >> >> >> -- >> View this message in context: >> http://activemq.2283324.n4.nabble.com/DISCUSS-Removing-the-Web-Console-tp4717136p4717302.html >> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. > > > > -- > Clebert Suconic -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://coders.talend.com <http://coders.talend.com/>
Re: [VOTE] Apache ActiveMQ 5.14.0
+1 Dan > On Aug 2, 2016, at 9:40 AM, Christopher Shannon > wrote: > > Hello everyone, > > ActiveMQ 5.14.0 is ready for a vote. This release has several new features > and improvements including AMQP over WebSockets as well as improved support > for durable subscriptions in a network of brokers. In total this release > contains over 200 resolved Jira issues. > > The list of resolved issues is here: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12334188 > > You can get binary distributions here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1098/org/apache/activemq/apache-activemq/5.14.0/ > > Source archives are here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1098/org/apache/activemq/activemq-parent/5.14.0/ > > Maven2 repository is at: > https://repository.apache.org/content/repositories/orgapacheactivemq-1098/ > > Source tag: > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=71cbc652835e8b6b9d17b7a28fc998fce4840a9b > > Please vote to approve this release. The vote will remain open for 72 > hours. > > [ ] +1 Release the binary as Apache ActiveMQ 5.14.0 > [ ] -1 (provide specific comments) > > Here's my +1 (non-binding) -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://coders.talend.com <http://coders.talend.com/>
[RESULT][VOTE] ActiveMQ 5.11.4/5.12.3
We have 6 +1 votes. I’ll get the artifacts released. Thanks! Dan > On Feb 3, 2016, at 2:52 PM, Daniel Kulp wrote: > > Several high importance fixes were back ported from the 5.13.1 release that > we should get into patch releases. > > > Staging Repositories: > 5.12.3: > https://repository.apache.org/content/repositories/orgapacheactivemq-1087/ > 5.11.4: > https://repository.apache.org/content/repositories/orgapacheactivemq-1088/ > > Tags: > 5.12.3 > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=231698ac73d6bc2b2e356a941e626ea9a2077c5c > 5.11.4 > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=67ddeb28d85d106dc2a8841cf8e2be7d8e33d0c1 > > > The vote will remain open for 72 hours. Here is my +1 > > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[VOTE] ActiveMQ 5.11.4/5.12.3
Several high importance fixes were back ported from the 5.13.1 release that we should get into patch releases. Staging Repositories: 5.12.3: https://repository.apache.org/content/repositories/orgapacheactivemq-1087/ 5.11.4: https://repository.apache.org/content/repositories/orgapacheactivemq-1088/ Tags: 5.12.3 https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=231698ac73d6bc2b2e356a941e626ea9a2077c5c 5.11.4 https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=67ddeb28d85d106dc2a8841cf8e2be7d8e33d0c1 The vote will remain open for 72 hours. Here is my +1 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache ActiveMQ 5.13.1
+1 Dan > On Feb 2, 2016, at 1:34 PM, Christopher Shannon > wrote: > > Hello everyone, > > I have created the ActiveMQ 5.13.1 release and it's ready for a vote. This > release has 43 bug fixes and improvements. > > The list of resolved issues is here: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12334251 > > You can get binary distributions here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1086/org/apache/activemq/apache-activemq/5.13.1/ > > Source archives are here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1086/org/apache/activemq/activemq-parent/5.13.1/ > > Maven2 repository is at: > https://repository.apache.org/content/repositories/orgapacheactivemq-1086/ > > Source tag: > *https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=d60b73402cc11babb53e0a26e4537265f153492b > <https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=d60b73402cc11babb53e0a26e4537265f153492b>* > > Please vote to approve this release. The vote will remain open for 72 > hours. > > [ ] +1 Release the binary as Apache ActiveMQ 5.13.1 > [ ] -1 (provide specific comments) > > Here's my +1 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
> On Dec 23, 2015, at 6:34 PM, Hiram Chirino wrote:
>
> -1 that seems silly. There is no legal reason to do that and it gives our
> users a worse experience out of the box.
Giving our users the information they would need to make it perform better is
giving them a worse experience?
Dan
>
> On Wednesday, December 23, 2015, John D. Ament
> wrote:
>
>> +1 for a prompt on broker creation.
>>
>> It could even include a prompt, say "No libaio detected, to make your
>> Artemis server faster please install libaio and {do necessary step to
>> enable in broker}" but if it is installed, just prompt/given flag.
>>
>> John
>>
>> On Wed, Dec 23, 2015 at 5:07 PM Daniel Kulp > > wrote:
>>
>>>
>>>> On Dec 23, 2015, at 4:55 PM, Andy Taylor > > wrote:
>>>> I Guess it depends on what they mean by enabled. If the user has to
>>>> explicitly install it then to me it's optional. Saying that if it's
>>>> installed by default on the OS you could argue the opposite.
>>>
>>> The issue with the is that the user may not even know if they have it
>>> installed or not.For example, on my two gentoo linux boxes, one has
>> it
>>> installed and one doesn’t. I have no idea why the one that has it
>>> installed has it. With the package management and such, something I
>>> installed there some time in the past must have caused it to install.
>>> (likely mysql)
>>>
>>>> We could change the cli to prompt for a choice at create time.
>>>
>>> That would certainly work.
>>>
>>> Dan
>>>
>>>
>>>
>>>> On Wed, 23 Dec 2015 21:41 Daniel Kulp >
>> wrote:
>>>>
>>>>>
>>>>>> On Dec 23, 2015, at 4:07 PM, John D. Ament > >
>>>>> wrote:
>>>>>>
>>>>>> Are you referring to the bin or src distribution?
>>>>>
>>>>> Kind of both…
>>>>>
>>>>> By removing the binary from the src distribution, that covers that
>> case.
>>>>> The user would have to cd into the appropriate directory and
>> explicitly
>>>>> run the “make” or whatever to build the binary. It’s an explicit
>>> choice
>>>>> they make. Thus, I’m completely OK with that now.
>>>>>
>>>>>
>>>>> The bin distribution is still an issue. If the default was to not
>> use
>>>>> the libaio at all unless the user either edited a config file to
>> enable
>>> it
>>>>> or pass a command line flag or similar to take explicit action, I’d be
>>> OK
>>>>> there as well. The new wording on the legal pages is completely
>>>>> confusing. The original suggested wording in:
>>>>> https://issues.apache.org/jira/browse/LEGAL-54
>>>>> makes so much more sense:
>>>>>
>>>>> "However, projects may use LGPL licensed works in optional features
>> that
>>>>> are not enabled by default.”
>>>>>
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp > > wrote:
>>>>>>
>>>>>>>
>>>>>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
>>>>> “out
>>>>>>> of the box”, does it use libaio or not? If I specifically have to
>>>>>>> configure something (pass a flag, edit a config file, etc…) to
>> enable
>>>>> use
>>>>>>> if the LGPL library, then fine.However, if it’s something that
>>>>> occurs
>>>>>>> completely automatically without the user even knowing that it’s
>>>>> occurring,
>>>>>>> then I have a major problem with it. It needs to be something that
>>> the
>>>>>>> user has to explicitly CHOOSE to use.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
>>>>> clebert.suco...@gmail.com >
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> also, there has also been questions about it during the donation
>
Re: [VOTE] Apache Artemis 1.2.0
> On Dec 23, 2015, at 6:45 PM, Clebert Suconic > wrote: > > > Anyways, Saying you can't depend on anything LGPL is the same as > saying you can't depend on Linux or anything coming from Linux. for > instance Apache HTTP (the very first project that founded this > organization) would be breaking the apache license itself by using > libc. (Open the source code if you don't believe me). > > It's certainly not the case...as libc is a platform API. Except you can build HTTP on Linux and NOT depend on the gnu license libc. I can use clang as the compiler (or the intel compiler or ….) and not end up with a dependency on a LGPL library. If you have a non-LGPL version of libaio, then by all means, let’s use it. > libaio is also a platform API. libaio is NOT installed by default on pretty much any of the linux “platforms" so I would have a hard time considering as a part of the platform. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
> On Dec 23, 2015, at 4:55 PM, Andy Taylor wrote: > I Guess it depends on what they mean by enabled. If the user has to > explicitly install it then to me it's optional. Saying that if it's > installed by default on the OS you could argue the opposite. The issue with the is that the user may not even know if they have it installed or not.For example, on my two gentoo linux boxes, one has it installed and one doesn’t. I have no idea why the one that has it installed has it. With the package management and such, something I installed there some time in the past must have caused it to install.(likely mysql) > We could change the cli to prompt for a choice at create time. That would certainly work. Dan > On Wed, 23 Dec 2015 21:41 Daniel Kulp wrote: > >> >>> On Dec 23, 2015, at 4:07 PM, John D. Ament >> wrote: >>> >>> Are you referring to the bin or src distribution? >> >> Kind of both… >> >> By removing the binary from the src distribution, that covers that case. >> The user would have to cd into the appropriate directory and explicitly >> run the “make” or whatever to build the binary. It’s an explicit choice >> they make. Thus, I’m completely OK with that now. >> >> >> The bin distribution is still an issue. If the default was to not use >> the libaio at all unless the user either edited a config file to enable it >> or pass a command line flag or similar to take explicit action, I’d be OK >> there as well. The new wording on the legal pages is completely >> confusing. The original suggested wording in: >> https://issues.apache.org/jira/browse/LEGAL-54 >> makes so much more sense: >> >> "However, projects may use LGPL licensed works in optional features that >> are not enabled by default.” >> >> >> Dan >> >> >> >>> >>> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp wrote: >>> >>>> >>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker >> “out >>>> of the box”, does it use libaio or not? If I specifically have to >>>> configure something (pass a flag, edit a config file, etc…) to enable >> use >>>> if the LGPL library, then fine.However, if it’s something that >> occurs >>>> completely automatically without the user even knowing that it’s >> occurring, >>>> then I have a major problem with it. It needs to be something that the >>>> user has to explicitly CHOOSE to use. >>>> >>>> Dan >>>> >>>> >>>> >>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic < >> clebert.suco...@gmail.com> >>>> wrote: >>>>> >>>>> also, there has also been questions about it during the donation >>>>> process.. licenses reviewed.. etc.. so I don't think we need to open a >>>>> new discussions over this. the binary inclusion on the source was >>>>> something that was fixed now. >>>>> >>>>> The dependency on libaio on the C code is through through dynamic >>>>> linked library, and is the same as any C code depending on libc or >>>>> gcc. >>>>> >>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic >>>>> wrote: >>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament >> >>>> wrote: >>>>>>> Just wondering, does anyone plan to raise the LGPL question w/ legal >>>>>>> discuss? If we're waiting for the new year to do the next release, >>>> would >>>>>>> be good to at least start the discussion. >>>>>> >>>>>> >>>>>> We had such discussion long ago with legal. I couldn't find that email >>>>>> on my inbox but we specifically asked questions about it. We were ok >>>>>> as I remember. Maybe someone else (Martyn?) will have it on their >>>>>> inboxes. For that reason I don't want to go over the same issue we had >>>>>> asked before. >>>>>> >>>>>> The use of libaio is optional anyways and the system works as >>>>>> expected. what also covers other questions we had here on this thread. >>>>> >>>>> >>>>> >>>>> -- >>>>> Clebert Suconic >>>> >>>> -- >>>> Daniel Kulp >>>> dk...@apache.org - http://dankulp.com/blog >>>> Talend Community Coder - http://coders.talend.com >>>> >>>> >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
> On Dec 23, 2015, at 4:07 PM, John D. Ament wrote: > > Are you referring to the bin or src distribution? Kind of both… By removing the binary from the src distribution, that covers that case. The user would have to cd into the appropriate directory and explicitly run the “make” or whatever to build the binary. It’s an explicit choice they make. Thus, I’m completely OK with that now. The bin distribution is still an issue. If the default was to not use the libaio at all unless the user either edited a config file to enable it or pass a command line flag or similar to take explicit action, I’d be OK there as well. The new wording on the legal pages is completely confusing. The original suggested wording in: https://issues.apache.org/jira/browse/LEGAL-54 makes so much more sense: "However, projects may use LGPL licensed works in optional features that are not enabled by default.” Dan > > On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp wrote: > >> >> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker “out >> of the box”, does it use libaio or not? If I specifically have to >> configure something (pass a flag, edit a config file, etc…) to enable use >> if the LGPL library, then fine.However, if it’s something that occurs >> completely automatically without the user even knowing that it’s occurring, >> then I have a major problem with it. It needs to be something that the >> user has to explicitly CHOOSE to use. >> >> Dan >> >> >> >>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic >> wrote: >>> >>> also, there has also been questions about it during the donation >>> process.. licenses reviewed.. etc.. so I don't think we need to open a >>> new discussions over this. the binary inclusion on the source was >>> something that was fixed now. >>> >>> The dependency on libaio on the C code is through through dynamic >>> linked library, and is the same as any C code depending on libc or >>> gcc. >>> >>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic >>> wrote: >>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament >> wrote: >>>>> Just wondering, does anyone plan to raise the LGPL question w/ legal >>>>> discuss? If we're waiting for the new year to do the next release, >> would >>>>> be good to at least start the discussion. >>>> >>>> >>>> We had such discussion long ago with legal. I couldn't find that email >>>> on my inbox but we specifically asked questions about it. We were ok >>>> as I remember. Maybe someone else (Martyn?) will have it on their >>>> inboxes. For that reason I don't want to go over the same issue we had >>>> asked before. >>>> >>>> The use of libaio is optional anyways and the system works as >>>> expected. what also covers other questions we had here on this thread. >>> >>> >>> >>> -- >>> Clebert Suconic >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker “out of the box”, does it use libaio or not? If I specifically have to configure something (pass a flag, edit a config file, etc…) to enable use if the LGPL library, then fine.However, if it’s something that occurs completely automatically without the user even knowing that it’s occurring, then I have a major problem with it. It needs to be something that the user has to explicitly CHOOSE to use. Dan > On Dec 23, 2015, at 2:02 PM, Clebert Suconic > wrote: > > also, there has also been questions about it during the donation > process.. licenses reviewed.. etc.. so I don't think we need to open a > new discussions over this. the binary inclusion on the source was > something that was fixed now. > > The dependency on libaio on the C code is through through dynamic > linked library, and is the same as any C code depending on libc or > gcc. > > On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic > wrote: >> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament wrote: >>> Just wondering, does anyone plan to raise the LGPL question w/ legal >>> discuss? If we're waiting for the new year to do the next release, would >>> be good to at least start the discussion. >> >> >> We had such discussion long ago with legal. I couldn't find that email >> on my inbox but we specifically asked questions about it. We were ok >> as I remember. Maybe someone else (Martyn?) will have it on their >> inboxes. For that reason I don't want to go over the same issue we had >> asked before. >> >> The use of libaio is optional anyways and the system works as >> expected. what also covers other questions we had here on this thread. > > > > -- > Clebert Suconic -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
> On Dec 21, 2015, at 12:41 PM, John D. Ament wrote: > > On Mon, Dec 21, 2015 at 12:34 PM Clebert Suconic > wrote: > >>> Nothing's stopping you from including them in the binary release. They >>> should be excluded in the source release. >> >> >> It's been easier to keep these .so there. I'm about to give up >> maintaining 32 bits. but right now you would need to log on 32 bits.. >> compile it.. log on 64 bits.. compile it..to make a full binary >> distribution from the source. >> >> removing the .so will only complicate things.. I don't think we should >> be so purist on this matter. >> > > I think you're thinking about removing the .so's from the git repo. I'm > not requesting that. They simply can't be in the source release tar.gz/zip > archives. Back to this part, the DO have to be removed from the source tar.gz. Per Roy Fielding: "Apache releases open source and ONLY open source. Our releases are absolutely forbidden to contain anything other than the open source code that is in our vcs-of-record, meaning code that is in the form most likely to be edited by recipients for the sake of modifying the product, and in some specific cases the generated (and open) source code of build scripts." http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3CC3656B87-A6DC-4D3D-B1EB-29911B7A8070%40gbiv.com%3E So yes, this part MUST be done. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
> On Dec 21, 2015, at 1:08 PM, Clebert Suconic > wrote: > > In particular, in org_apache_activemq_artemis_jlibaio_LibaioContext.c, > I see right at the top: > > #ifndef _GNU_SOURCE > // libaio, O_DIRECT and other things won't be available without this define > #define _GNU_SOURCE > #endif > > > this has nothing to do with LGPL licenses.. or even libaio on this > instance.. That's how you enable O_DIRECT, with O_DIRECT being a Linux > extension non conformant with POSIX. the header is there for any > source code using it. > >> …linked to libraries that are LGPL and only LGPL, which is not allowed per >> ASF policy. >> > > Dynamic linked.. it doesn't not include libaio. But is still REQUIRED for building the library… Thus, the library still has a REQUIRED dependency on a LGPL’d library to work.Thus, it must be optional and the user must take explicit actions to enable it during build and runtime. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
> On Dec 21, 2015, at 12:55 PM, Clebert Suconic > wrote: > >> >> Actually, this is more serious than that. If I’m reading correctly, libaio >> is LGPL. Thus, we cannot use it from an Apache release unless its: >> > We are not redistributing libaio.. libaio is a Kernel functionality > from Linux. We have an implementation that is just using a kernel > functionality available on any Linux Kernel. you need to install the > libaio header but the functiionality is part of the linux kernel. > > Saying so would be the same as saying you can't use any OS that's > LGPL.. which is not the case. But the parts of the “OS” that is used generally has some sort of “classpath exception” or similar or there is another implementation that is completely usable that is not LGPL (example: the stdc++ runtimes). libaio does not. It is specifically LGPL. In particular, in org_apache_activemq_artemis_jlibaio_LibaioContext.c, I see right at the top: #ifndef _GNU_SOURCE // libaio, O_DIRECT and other things won't be available without this define #define _GNU_SOURCE #endif That’s in direct conflict with the license header. >> 2) Not be part of the default build - in our case, we’d need a maven >> profile to build it and that profile would need to not be activeByDefault. >> >> Thus, I think this release cannot be released as is. > > I disagree.. the release should include it... our implementation is > apache licensed. …linked to libraries that are LGPL and only LGPL, which is not allowed per ASF policy. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Artemis 1.2.0
> On Dec 21, 2015, at 12:27 PM, John D. Ament wrote: > > On Mon, Dec 21, 2015 at 12:16 PM Clebert Suconic > wrote: > >> This has been like this since 1.0.0 >> >> > Then I missed them in prior votes. Mea culpa. We all missed them on the prior releases. >> >> I don't want to require users to install cmake and make just to >> compile this small library. it should be an optional step for those >> who want to do it. >> > > Nothing's stopping you from including them in the binary release. They > should be excluded in the source release. Actually, this is more serious than that. If I’m reading correctly, libaio is LGPL. Thus, we cannot use it from an Apache release unless its: 1) completely optional - Artemis would have to “functionally work” without it 2) Not be part of the default build - in our case, we’d need a maven profile to build it and that profile would need to not be activeByDefault. Thus, I think this release cannot be released as is. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [ANNOUNCE] Apache ActiveMQ 5.13.0 Released
e text in the release notes, and ideally AMQ >>>>>>> broker / client should have some kind of INFO logging that openwire >>>>>>> with objects is restricted or not. Otherwise its even harder for end >>>>>>> users to spot what is going on. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Dec 4, 2015 at 3:57 PM, Timothy Bish >>>>> wrote: >>>>>>>> It's probably a good idea to add a new page in the "New Features" >>>>> section >>>>>>>> on the site to cover the additions in 5.13.0. I know you added the >>>>>>> 'auto' >>>>>>>> transport along with some other work for some additional metrics >>>>> etc, all >>>>>>>> good things that would be nice to advertise a bit. >>>>>>>> >>>>>>>> See: http://activemq.apache.org/new-features.html >>>>>>>> >>>>>>>> On Thu, Dec 3, 2015 at 3:51 PM, Christopher Shannon < >>>>>>>> christopher.l.shan...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> Apache ActiveMQ 5.13.0 has now been released. >>>>>>>>> >>>>>>>>> This release contains a number of resolved issues and new features >>>>> since >>>>>>>>> the 5.12.1 release. >>>>>>>>> >>>>>>>>> A list of issues resolved in this release is available here: >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12329848 >>>>>>>>> >>>>>>>>> The Wiki page for the release is here: >>>>>>>>> http://activemq.apache.org/activemq-5130-release.html >>>>>>>>> >>>>>>>>> API documentation for 5.12.1 is located here: >>>>>>>>> http://activemq.apache.org/maven/5.13.0/apidocs/index.html >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> -- >>>>>>>> Tim Bish >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Claus Ibsen >>>>>>> - >>>>>>> http://davsclaus.com @davsclaus >>>>>>> Camel in Action 2: https://www.manning.com/ibsen2 >>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Claus Ibsen >>>>> - >>>>> http://davsclaus.com @davsclaus >>>>> Camel in Action 2: https://www.manning.com/ibsen2 >>>>> >>>> >>>> >> >> >> >> -- >> Claus Ibsen >> - >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] OSGi support for Artemis
I’d much much rather see the split packages resolved than have an uber jar. Can the packages be moved into a “common” jar or something that can be referenced by both? Dan > On Nov 13, 2015, at 10:27 AM, Clebert Suconic > wrote: > > https://issues.apache.org/jira/browse/ARTEMIS-93 > > OSGI still an open task. Fancy contributing? (as the British would say) > > The first thing thing I know we will need is an uber JAR. I think we > talked about this during the last Apache Con with some folks.. and I > also remember talking to some other folks.. that the first thing we > will need is an Uber Jar... > > > ActiveMQ has it being done here: > > https://github.com/apache/activemq/tree/master/activemq-osgi > > > Maybe that's an easy transfer? > > > And that would take care of your issue of multiple split jars.. (We > need the split jars as the clients don't want to have server > objects... and other things that are best to be kept separate... you > don't need the resource adapter on the client for instance). > > > > On Fri, Nov 13, 2015 at 9:21 AM, Guillaume Nodet wrote: >> I was looking at supporting OSGi deployment for Artemis. >> >> The first big problem I hit is the existence of split packages. Split >> packages are java packages shared across multiple jars (which become >> bundles in OSGi). >> Examples of those are org.apache.activemq.artemis.uri (shared between >> artemis-jms-client and artemis-core-client) or >> org.apache.activemq.artemis.api.config (shared between artemis-core-client >> and artemis-commons). >> The reason they are problematic is that in OSGi, each bundle has its own >> class loader, importing classes from other packages based on packages. The >> same package can not be imported from 2 different bundles. >> >> So the question is: would it be possible to get rid of those split packages >> ? It can be done either by moving the classes from a jar to another one, >> keeping the same package name, or by renaming one of the split package so >> that there's no duplicate package names across jars. >> >> Thoughts ? >> Guillaume Nodet > > > > -- > Clebert Suconic -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[RESULT][VOTE] ActiveMQ 5.11.3
Update subject for future searches…. Dan > On Nov 2, 2015, at 12:33 PM, Daniel Kulp wrote: > > We have 8 +1 votes and no other votes. This vote passes. I’ll promote the > release. > > Thanks! > Dan > > > >> On Oct 29, 2015, at 12:22 PM, Daniel Kulp wrote: >> >> >> This is a vote to release Apache ActiveMQ 5.11.3 >> >> Staging area: >> https://repository.apache.org/content/repositories/orgapacheactivemq-1070/ >> >> Tag: >> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=a820bfb4c5489ed842efc6ef5702f0fc21975c41 >> >> Issues resolved: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12333254 >> >> >> This vote will be open till Monday. Here is my +1 >> >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] ActiveMQ 5.11.3
We have 8 +1 votes and no other votes. This vote passes. I’ll promote the release. Thanks! Dan > On Oct 29, 2015, at 12:22 PM, Daniel Kulp wrote: > > > This is a vote to release Apache ActiveMQ 5.11.3 > > Staging area: > https://repository.apache.org/content/repositories/orgapacheactivemq-1070/ > > Tag: > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=a820bfb4c5489ed842efc6ef5702f0fc21975c41 > > Issues resolved: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12333254 > > > This vote will be open till Monday. Here is my +1 > > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[VOTE] ActiveMQ 5.11.3
This is a vote to release Apache ActiveMQ 5.11.3 Staging area: https://repository.apache.org/content/repositories/orgapacheactivemq-1070/ Tag: https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=a820bfb4c5489ed842efc6ef5702f0fc21975c41 Issues resolved: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12333254 This vote will be open till Monday. Here is my +1 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Release ActiveMQ 5.11.3....
I went through the “Critical” and “Blocker” things that have been fixed recently and back ported a couple. Thus, we have: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12333254 I just ran all the tests and everything passes. If there aren’t any objections or additional concerns or things that are needed, I’ll do the build tomorrow. Dan > On Oct 26, 2015, at 12:23 PM, Daniel Kulp wrote: > > I’d like to build a 5.11.3 release later this week to fix the problems with > ActiveMQ in Karaf, particularly the web console. I’ll likely try and review > some of the other bugs and pull some fixes back. If anyone has anything in > particular that they think is important for 5.11.3, please let me know ASAP. > > Thanks! > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Release ActiveMQ 5.11.3....
I’d like to build a 5.11.3 release later this week to fix the problems with ActiveMQ in Karaf, particularly the web console. I’ll likely try and review some of the other bugs and pull some fixes back. If anyone has anything in particular that they think is important for 5.11.3, please let me know ASAP. Thanks! -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache ActiveMQ 5.12.1
+1, ran CXF’s tests with it. Dan > On Oct 12, 2015, at 2:33 PM, Christopher Shannon > wrote: > > Hello everyone, > > I have cut the ActiveMQ 5.12.1 release and it's ready for a vote. This > release has 22 bug fixes and > improvements. > > The list of resolved issues is here: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12333269 > > You can get binary distributions here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1069/org/apache/activemq/apache-activemq/5.12.1/ > > Source archives are here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1069/org/apache/activemq/activemq-parent/5.12.1/ > > Maven2 repository is at: > https://repository.apache.org/content/repositories/orgapacheactivemq-1069/ > > Source tag: > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=21c8b4695f771065192ed7a24c92367ed9f6e564 > > Please vote to approve this release. The vote will remain open for 72 > hours. > > [ ] +1 Release the binary as Apache ActiveMQ 5.12.1 > [ ] -1 (provide specific comments) > > Here's my +1 (non-binding) -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Please contribute to the board report for October 2015
You likely should go to:
https://reporter.apache.org/
and grab the template from there and fill in the information on our wiki into
the right spots in there.In particular, the board WILL ask for things like
date of last committer addition, date of last PMC addition, etc… reporter
tracks some of that. For the most part, the stuff on the wiki page is perfect
for the “Activity” section. For the other two:
Health:
As the number and scope of the recent releases shows, there is a lot of
development occurring throughout all of the ActiveMQ products. Many bugs are
being raised, but they are being looked at fairly promptly. There were a
couple of bugs raised that resulted in good “cross team” discussions as to
whether the bug was, indeed, a bug or a desired change in behavior. While
some of these discussions did hold up the creations of a patch release
(5.12.1), it was important for the team to reach a consensus on the outcome.
That was achieved and plans are starting to finish the release.
Issues: there are no issues requiring board attention at this time
Dan
> On Oct 6, 2015, at 1:55 PM, Bruce Snyder wrote:
>
> Are folks satisfied with the board report? Can I submit it today?
>
> Bruce
>
> On Tue, Sep 29, 2015 at 10:37 PM, Bruce Snyder
> wrote:
>
>> I have created the initial wiki page for the October board report here:
>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61321327
>>
>> Due date: October 7, 2015
>>
>> If you have anything to contribute to the October board report, please add
>> it to the wiki page or reply to this message.
>>
>> I would like for the October board report to be as detailed as the one
>> that was submitted for August which is available here:
>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61309469
>>
>> If you have any questions or would like to discuss, please reply to this
>> message.
>>
>> Bruce
>> --
>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E>
>> ActiveMQ in Action: http://bit.ly/2je6cQ
>> Blog: http://bsnyder.org/ <http://bruceblog.org/>
>> Twitter: http://twitter.com/brucesnyder
>>
>
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bsnyder.org/ <http://bruceblog.org/>
> Twitter: http://twitter.com/brucesnyder
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [HEADSUP] ActiveMQ 5.12.1 Release Preparation
> On Sep 22, 2015, at 4:36 PM, Christopher Shannon > wrote: > > It's been about a month since 5.12.0 was released and there are already a > good number of fixes contributed towards 5.12.1 so I'd like to start > working on a 5.12.1 release in a few days. > > If there is anything major that would be a blocker, let me know. > > Here are the current release notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12333269 Well, I’d like to understand what is going on with https://issues.apache.org/jira/browse/AMQ-5966 a bit first. It’s definitely a behavior change (and thus should have been documented in release notes at the very least).What I’m still struggling with is trying to determine if it’s a bug or not. That said, the commit that introduced the change did not include a unit test. The log points at a fuse JIRA that is obviously completely unrelated. Thus, I have no idea why that change was even put in. I’m tempted to back it out. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Jetty 9.2 OSGi upgrade
Likely needs to move to Karaf 4. Karaf 4 is the first version to support Jetty 9. Dan > On Aug 19, 2015, at 4:57 PM, Christopher Shannon > wrote: > > I've finished all the work for the Jetty 9.2 upgrade, except for the OSGi > piece. The web console and demo work all of the WebSocket support has been > converted to the new APIs. I've also fixed all of the tests in the http > module that were relying on the old Jetty APIs. > > However, the karaf integration tests don't work and it looks like Karaf > might need to be upgraded to make it compatible with Jetty 9, or some work > will need to be done to make Jetty 9 work in the older version of Karaf we > are using (2.4). For example, the pax-web-features which is part of Karaf > appears to be too old. > > My OSGi experience is pretty limited so I was wondering if there was anyone > with more OSGi experience who might volunteer to take a look at this > piece? I was thinking about creating a new Jira subtask for the OSGi piece. > > Thanks, > Chris -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Jetty 9.2 dependency licensing issues
CDDL is category B and can be used: http://apache.org/legal/resolved.html#category-b Dan > On Aug 18, 2015, at 12:33 PM, Christopher Shannon > wrote: > > Actually, re-reading the Apache guidance I'm not sure that CDDL can be > included either if the source is available. So any guidance is appreciated > from anyone who has dealt with the licensing stuff before. > > On Tue, Aug 18, 2015 at 11:57 AM, Christopher Shannon < > christopher.l.shan...@gmail.com> wrote: > >> I'm working on upgrading to Jetty 9.2.x to fix: >> https://issues.apache.org/jira/browse/AMQ-5356 >> >> Part of the upgrade requires updating dependencies for the servlet and jsp >> jars. Jetty has two different versions of jsp implementations it is >> supposed to work. The jetty-jsp works fine but I'm not sure if the >> dependencies are compatible with Apache licensing. Supposedly Jetty also >> works with apache-jsp (which is Tomcat) but I've had lots of issues trying >> to get it to work right. >> >> I know we can't use GPL licensed dependencies but I think the dependencies >> below are both GPL and CDDL. Can we still use the dependencies since they >> are also under CDDL or is that not allowed? >> >> >> javax.servlet >> javax.servlet-api >> 3.1 >> >> >> javax.servlet.jsp >> javax.servlet.jsp-api >> 2.3.1 >> >> >> org.glassfish.web >> javax.servlet.jsp >> 2.3.2 >> >> >> org.glassfish.web >> javax.servlet.jsp.jstl >> 1.2.2 >> >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache ActiveMQ 5.12.0
+1 Dan > On Aug 10, 2015, at 2:11 PM, Timothy Bish wrote: > > Hi folks, > > I've just cut a release candidate for the ActiveMQ 5.12.0 release and > it's ready for a vote. This release has 180+ bug fixes and > improvements. A large amount of work has gone into hardening the AMQP > and MQTT protocol support along with numerous other improvements. > > The list of resolved issues is here: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12329258 > > You can get binary distributions here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1062/org/apache/activemq/apache-activemq/5.12.0/ > > Source archives are here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1062/org/apache/activemq/activemq-parent/5.12.0/ > > Maven2 repository is at: > https://repository.apache.org/content/repositories/orgapacheactivemq-1062/ > > Source tag: > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=a9eeb03520f074d5013239b8d8708a05ba31e176 > > Please vote to approve this release. The vote will remain open for 72 > hours. > > [ ] +1 Release the binary as Apache ActiveMQ 5.12.0 > [ ] -1 (provide specific comments) > > Here's my +1 > > -- > Tim Bish > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [RESULT] [VOTE] ActiveMQ 5.11.2
> On Aug 10, 2015, at 3:00 PM, Paul Gale wrote: > > There appears to be a significant discrepancy between the size of the bug > list for 5.11.2 that of 5.12. > > What is the technical impediment preventing the same number of bug fixes > from being included in the 5.11.2 release as are proposed for inclusion in > the 5.12 release? See my response: http://mail-archives.apache.org/mod_mbox/activemq-dev/201508.mbox/%3C0EEEA788-8D57-4B61-9408-F626ED4AAE4E%40apache.org%3E Basically, it’s a matter of finding someone to review the fixes and pull them back. I’d love to see the original “fixers” pulling them back, but so far that isn’t happing often enough. If someone would like to start going through more of the 5.12.0 bugs and seeing what CAN be pulled back, I have no problem doing a 5.11.3 release. Either send me a list of git hashes or even a github pull request from the 5.11.x branch. Dan > > Thanks, > Paul > > On Mon, Aug 10, 2015 at 9:13 AM, Daniel Kulp wrote: > >> We have 3 binding +1 votes, 3 non-binding +1 votes, 1 +0 vote, and no >> other votes. This vote passes. >> >> Dan >> >> >> >>> On Aug 6, 2015, at 10:57 AM, Daniel Kulp wrote: >>> >>> This is a vote to release Apache ActiveMQ 5.11.2 >>> >>> Staging area: >>> >> https://repository.apache.org/content/repositories/orgapacheactivemq-1061/ >>> >>> Tag: >>> >> https://git1-us-west.apache.org/repos/asf?p=activemq.git;a=tag;h=16e90579044aa4a302164c1a59d5a88db265e81c >>> >>> Issues resolved: >>> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12329669 >>> >>> >>> This vote will be open till Monday. Here is my +1 >>> >>> >>> -- >>> Daniel Kulp >>> dk...@apache.org - http://dankulp.com/blog >>> Talend Community Coder - http://coders.talend.com >>> >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[RESULT] [VOTE] ActiveMQ 5.11.2
We have 3 binding +1 votes, 3 non-binding +1 votes, 1 +0 vote, and no other votes. This vote passes. Dan > On Aug 6, 2015, at 10:57 AM, Daniel Kulp wrote: > > This is a vote to release Apache ActiveMQ 5.11.2 > > Staging area: > https://repository.apache.org/content/repositories/orgapacheactivemq-1061/ > > Tag: > https://git1-us-west.apache.org/repos/asf?p=activemq.git;a=tag;h=16e90579044aa4a302164c1a59d5a88db265e81c > > Issues resolved: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12329669 > > > This vote will be open till Monday. Here is my +1 > > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[VOTE] ActiveMQ 5.11.2
This is a vote to release Apache ActiveMQ 5.11.2 Staging area: https://repository.apache.org/content/repositories/orgapacheactivemq-1061/ Tag: https://git1-us-west.apache.org/repos/asf?p=activemq.git;a=tag;h=16e90579044aa4a302164c1a59d5a88db265e81c Issues resolved: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12329669 This vote will be open till Monday. Here is my +1 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: 5.11.2....
> On Aug 5, 2015, at 9:47 AM, Dejan Bosanac wrote: > > Can you add https://issues.apache.org/jira/browse/AMQ-5754 to the list? Yep. Done. Thanks! Dan > > Regards > -- > Dejan Bosanac > about.me/dejanb > > On Wed, Aug 5, 2015 at 3:28 PM, Daniel Kulp wrote: > >> Thanks for this list. I’ve pulled these back (along with a couple others >> needed to get these to compile). The tests all pass. >> >> I’ll likely do the 5.11.2 builds tomorrow morning. If anyone has anything >> else they need, let me know ASAP! >> >> Thanks! >> Dan >> >> >> >>> On Aug 3, 2015, at 3:50 PM, Christopher Shannon < >> christopher.l.shan...@gmail.com> wrote: >>> >>> A couple of other bug candidates I thing would be good to include if not >>> already on the branch: >>> >>> AMQ-5674: 20832f1f1b5bf028d43256a8b2172f2795b0c02d >>> AMQ-5742: c85fa67e1c65caecb96d3a044fbd5ac835cce3db >>> AMQ-5787 : e99c8148301c6ff6b6ed529a26ba3337ef20d016 >>> AMQ-5813: ea03bb1f8cb2bce97fabdaa8fa287f4c9f977a3a >>> AMQ-5814 : e4af2eb63501251befc33a415abfad2b72d53321 >>> >>> >>> >>> On Mon, Aug 3, 2015 at 2:47 PM, Daniel Kulp wrote: >>> >>>> >>>>> On Jul 30, 2015, at 11:06 AM, Christopher Shannon < >>>> christopher.l.shan...@gmail.com> wrote: >>>>> >>>>> I checked Jira and there are over 100 bug issues against 5.12.0 that >> have >>>>> been resolved. I'm thinking that going forward it might make sense to >>>>> backport fixes when the tickets are resolved if it makes sense to do >> so. >>>> >>>> I’d love to see that, but most of the people that have implemented fixes >>>> don’t seem to want to spend the time pulling them back to any of the >> fixes >>>> branches. :(As long as the people doing the fixes aren’t willing >> to >>>> do it, it becomes really tough as it’s more about asking other folks to >>>> take a look. That’s something even non-committers could do and help >> out >>>> with. In this case, I specifically asked for any fixes or git hashes >> or >>>> something to pull back and got exactly one. Not a good sign. >>>> >>>>> This won't work for all cases but it would cut down the work at release >>>>> time if some of the commits can be merged ahead of time. >>>> >>>> In any case, I do plan on doing the build on Wednesday or Thursday. If >>>> anyone would like something pulled back, please let me know. >>>> >>>> Thanks! >>>> Dan >>>> >>>> >>>> >>>>> >>>>> On Thu, Jul 30, 2015 at 10:56 AM, Daniel Kulp >> wrote: >>>>> >>>>>> >>>>>>> On Jul 30, 2015, at 10:44 AM, Paul Gale >> wrote: >>>>>>> >>>>>>> If possible can AMQ-5903 be included in 5.11.2? It's only on master >> at >>>>>> the >>>>>>> moment, e.g. destined for 5.12.0. >>>>>> >>>>>> Done… can you verify it’s on the branch properly and working? >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> On Thu, Jul 30, 2015 at 9:10 AM, Daniel Kulp >> wrote: >>>>>>> >>>>>>>> It’s been a while since 5.11.1 so I’d like to get a 5.11.2 release >> out >>>>>>>> shortly, probably early/mid next week.There’s not a lot of fixes >>>> on >>>>>> the >>>>>>>> branch right now, just stuff mostly necessary for OSGi to support >>>>>> running >>>>>>>> ActiveMQ in Karaf4. >>>>>>>> >>>>>>>> If there are other fixes that people would like to get in, please >> get >>>>>> them >>>>>>>> cherry-picked to the activemq-5.11.x branch or send me the git >> hashes >>>>>> and I >>>>>>>> can take a look and get them merged. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> -- >>>>>>>> Daniel Kulp >>>>>>>> dk...@apache.org - http://dankulp.com/blog >>>>>>>> Talend Community Coder - http://coders.talend.com >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Daniel Kulp >>>>>> dk...@apache.org - http://dankulp.com/blog >>>>>> Talend Community Coder - http://coders.talend.com >>>>>> >>>>>> >>>> >>>> -- >>>> Daniel Kulp >>>> dk...@apache.org - http://dankulp.com/blog >>>> Talend Community Coder - http://coders.talend.com >>>> >>>> >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: 5.11.2....
Thanks for this list. I’ve pulled these back (along with a couple others needed to get these to compile). The tests all pass. I’ll likely do the 5.11.2 builds tomorrow morning. If anyone has anything else they need, let me know ASAP! Thanks! Dan > On Aug 3, 2015, at 3:50 PM, Christopher Shannon > wrote: > > A couple of other bug candidates I thing would be good to include if not > already on the branch: > > AMQ-5674: 20832f1f1b5bf028d43256a8b2172f2795b0c02d > AMQ-5742: c85fa67e1c65caecb96d3a044fbd5ac835cce3db > AMQ-5787 : e99c8148301c6ff6b6ed529a26ba3337ef20d016 > AMQ-5813: ea03bb1f8cb2bce97fabdaa8fa287f4c9f977a3a > AMQ-5814 : e4af2eb63501251befc33a415abfad2b72d53321 > > > > On Mon, Aug 3, 2015 at 2:47 PM, Daniel Kulp wrote: > >> >>> On Jul 30, 2015, at 11:06 AM, Christopher Shannon < >> christopher.l.shan...@gmail.com> wrote: >>> >>> I checked Jira and there are over 100 bug issues against 5.12.0 that have >>> been resolved. I'm thinking that going forward it might make sense to >>> backport fixes when the tickets are resolved if it makes sense to do so. >> >> I’d love to see that, but most of the people that have implemented fixes >> don’t seem to want to spend the time pulling them back to any of the fixes >> branches. :(As long as the people doing the fixes aren’t willing to >> do it, it becomes really tough as it’s more about asking other folks to >> take a look. That’s something even non-committers could do and help out >> with. In this case, I specifically asked for any fixes or git hashes or >> something to pull back and got exactly one. Not a good sign. >> >>> This won't work for all cases but it would cut down the work at release >>> time if some of the commits can be merged ahead of time. >> >> In any case, I do plan on doing the build on Wednesday or Thursday. If >> anyone would like something pulled back, please let me know. >> >> Thanks! >> Dan >> >> >> >>> >>> On Thu, Jul 30, 2015 at 10:56 AM, Daniel Kulp wrote: >>> >>>> >>>>> On Jul 30, 2015, at 10:44 AM, Paul Gale wrote: >>>>> >>>>> If possible can AMQ-5903 be included in 5.11.2? It's only on master at >>>> the >>>>> moment, e.g. destined for 5.12.0. >>>> >>>> Done… can you verify it’s on the branch properly and working? >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On Thu, Jul 30, 2015 at 9:10 AM, Daniel Kulp wrote: >>>>> >>>>>> It’s been a while since 5.11.1 so I’d like to get a 5.11.2 release out >>>>>> shortly, probably early/mid next week.There’s not a lot of fixes >> on >>>> the >>>>>> branch right now, just stuff mostly necessary for OSGi to support >>>> running >>>>>> ActiveMQ in Karaf4. >>>>>> >>>>>> If there are other fixes that people would like to get in, please get >>>> them >>>>>> cherry-picked to the activemq-5.11.x branch or send me the git hashes >>>> and I >>>>>> can take a look and get them merged. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -- >>>>>> Daniel Kulp >>>>>> dk...@apache.org - http://dankulp.com/blog >>>>>> Talend Community Coder - http://coders.talend.com >>>>>> >>>>>> >>>> >>>> -- >>>> Daniel Kulp >>>> dk...@apache.org - http://dankulp.com/blog >>>> Talend Community Coder - http://coders.talend.com >>>> >>>> >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Artemis Coding Style
Lazy consensus is fine.Wait till tomorrow and if no one objects, just do it. Dan > On Aug 4, 2015, at 11:24 AM, Clebert Suconic > wrote: > > Is this a just do it thing, or we need a vote? > > On Tue, Aug 4, 2015 at 10:07 AM, Timothy Bish wrote: >> On 08/04/2015 07:56 AM, Christopher Shannon wrote: >>> So in general I'm not too picky with coding styles but I just started >>> looking at the Artemis project a few days ago and something that stood out >>> to me right away was the use of opening curly braces on a new line. >>> >>> Virtually ever Java code base I've seen is written in the style using the >>> opening brace on the same line. (See >>> http://google.github.io/styleguide/javaguide.html#s4.1.2-blocks-k-r-style) >>> I think that in general it would be a good idea to match up to a style >>> that most Java developers are used to working with if we want to get more >>> of the community involved. >>> >>> I was wondering if anyone would have an issue with changing the style or >>> what people's thoughts are about this potential change? >>> >> +1 >> >> I think following the javaguide style would make the code much more >> approachable. >> >> -- >> Tim Bish >> Sr Software Engineer | RedHat Inc. >> tim.b...@redhat.com | www.redhat.com >> twitter: @tabish121 >> blog: http://timbish.blogspot.com/ >> > > > > -- > Clebert Suconic -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Artemis Coding Style
I’d probably start with the CXF configs: https://git1-us-west.apache.org/repos/asf?p=cxf-build-utils.git;a=tree;f=buildtools/src/main/resources;h=f0a20e01e53e5915a2a298060688c0cf24bc86bf;hb=HEAD as a base and modify it (likely relax some rules, CXF is pretty strict). The CXF configs are updated for the latest checkstyle plugins for both Maven and the Eclipse checkstyle plugin. I know the Camel configs need some update for the new plugins. Just haven’t gotten around to doing it. Dan > On Aug 4, 2015, at 9:45 AM, Clebert Suconic wrote: > > +0. I have no problem on switching coding styles as long as we stick > to one and bind it with checkstyle. > > Although, If that will help more people to adopt the codebase and > would help the community, then I am +1000 on that. > > The only favor I ask is if anyone is sending a commit to change > codestyles and reconfigure the checkstyle please do it with a pull > request as that will be used also to validate the PR builds. > > > Maybe we could agree in detail with the checkstyle.xml before we send > a commit doing it though. > > On Tue, Aug 4, 2015 at 7:56 AM, Christopher Shannon > wrote: >> So in general I'm not too picky with coding styles but I just started >> looking at the Artemis project a few days ago and something that stood out >> to me right away was the use of opening curly braces on a new line. >> >> Virtually ever Java code base I've seen is written in the style using the >> opening brace on the same line. (See >> http://google.github.io/styleguide/javaguide.html#s4.1.2-blocks-k-r-style) >> I think that in general it would be a good idea to match up to a style >> that most Java developers are used to working with if we want to get more >> of the community involved. >> >> I was wondering if anyone would have an issue with changing the style or >> what people's thoughts are about this potential change? > > > > -- > Clebert Suconic -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Artemis Coding Style
+1 (or more) I honestly thought ActiveMQ had a style guide already, but I didn’t find one while searching through the site or anything like IDE setups in the repo or anything. I guess I always have the stuff from Camel/CXF configured in Eclipse which pretty much uses the javaguide style and never really gave it much thought. Dan > On Aug 4, 2015, at 7:56 AM, Christopher Shannon > wrote: > > So in general I'm not too picky with coding styles but I just started > looking at the Artemis project a few days ago and something that stood out > to me right away was the use of opening curly braces on a new line. > > Virtually ever Java code base I've seen is written in the style using the > opening brace on the same line. (See > http://google.github.io/styleguide/javaguide.html#s4.1.2-blocks-k-r-style) > I think that in general it would be a good idea to match up to a style > that most Java developers are used to working with if we want to get more > of the community involved. > > I was wondering if anyone would have an issue with changing the style or > what people's thoughts are about this potential change? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: 5.11.2....
> On Jul 30, 2015, at 11:06 AM, Christopher Shannon > wrote: > > I checked Jira and there are over 100 bug issues against 5.12.0 that have > been resolved. I'm thinking that going forward it might make sense to > backport fixes when the tickets are resolved if it makes sense to do so. I’d love to see that, but most of the people that have implemented fixes don’t seem to want to spend the time pulling them back to any of the fixes branches. :(As long as the people doing the fixes aren’t willing to do it, it becomes really tough as it’s more about asking other folks to take a look. That’s something even non-committers could do and help out with. In this case, I specifically asked for any fixes or git hashes or something to pull back and got exactly one. Not a good sign. > This won't work for all cases but it would cut down the work at release > time if some of the commits can be merged ahead of time. In any case, I do plan on doing the build on Wednesday or Thursday. If anyone would like something pulled back, please let me know. Thanks! Dan > > On Thu, Jul 30, 2015 at 10:56 AM, Daniel Kulp wrote: > >> >>> On Jul 30, 2015, at 10:44 AM, Paul Gale wrote: >>> >>> If possible can AMQ-5903 be included in 5.11.2? It's only on master at >> the >>> moment, e.g. destined for 5.12.0. >> >> Done… can you verify it’s on the branch properly and working? >> >> Dan >> >> >>> >>> Thanks, >>> Paul >>> >>> On Thu, Jul 30, 2015 at 9:10 AM, Daniel Kulp wrote: >>> >>>> It’s been a while since 5.11.1 so I’d like to get a 5.11.2 release out >>>> shortly, probably early/mid next week.There’s not a lot of fixes on >> the >>>> branch right now, just stuff mostly necessary for OSGi to support >> running >>>> ActiveMQ in Karaf4. >>>> >>>> If there are other fixes that people would like to get in, please get >> them >>>> cherry-picked to the activemq-5.11.x branch or send me the git hashes >> and I >>>> can take a look and get them merged. >>>> >>>> Thanks! >>>> >>>> -- >>>> Daniel Kulp >>>> dk...@apache.org - http://dankulp.com/blog >>>> Talend Community Coder - http://coders.talend.com >>>> >>>> >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: constant updating of the "Unix Shell Script" website page
For some reason (no idea why), the builder was using an old version of the export utilities and not fetching the latest version. I added a -U to the mvn command to force the update and that seems to have fixed it. It SHOULD just be rendering the pages that have changed. Dan > On Aug 3, 2015, at 5:45 AM, Robbie Gemmell wrote: > > I don't know what the current export process used is or where it is > running exactly, other than the commit emails giving away that it is a > Buildbot instance doing it. I know in the past there was an > auto-export plugin used with Confluence that exported the websites, > but it got dropped during some upgrades. Perhaps someone involved in > the switchover at that point can chime in? > > It seems likely to be that conversion where the issue lies rather than > the Buildbot itself, which from the mails is probably just detecting > the diff in the files created and committing them. The issue is the > toc elements getting new style class every run. The suggestion of a > static links rather than toc was really just to stop the immediate > commit spam if noone knew how to stop it otherwise. > > Robbie > > On 3 August 2015 at 06:16, Marc Schöchlin wrote: >> Hi, >> >> i added the TOC to provide a better overview - unbeliveable that i am the >> first user of this feature. >> >> A static TOC does not seem to be a attractive solution - because users will >> not aware to update the TOC and will not aware not to use the confluce TOC. >> >> Probably it would be a better solution to fix the "website buildbot"? >> Where can i find it? >> >> Regards >> Marc >> >> >> Am 29.07.2015 um 18:12 schrieb Robbie Gemmell: >>> Hi folks, >>> >>> The "Unix Shell Script" page >>> (http://activemq.apache.org/unix-shell-script.html) seems to be >>> driving the website Buildbot a bit nuts. It commits an update for this >>> page every hour and mails the commits@ list. >>> >>> It looks like the Table of Contents could be the issue. It seems to be >>> changing class name for some of the elements each time it is built or >>> something. It also looks a bit broken when viewed on the website >>> versus the original on confluence >>> (https://cwiki.apache.org/confluence/display/ACTIVEMQ/Unix+Shell+Script). >>> >>> Anyone know how to fix this? Should we remove the TOC, perhaps replace >>> it with links to some static anchors in the page? >>> >>> Robbie >> >> -- >> GPG encryption available: 0x670DCBEC/pool.sks-keyservers.net >> (https://www.256bit.org/keys/mschoechlin.pub.asc) >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: 5.11.2....
> On Jul 30, 2015, at 10:44 AM, Paul Gale wrote: > > If possible can AMQ-5903 be included in 5.11.2? It's only on master at the > moment, e.g. destined for 5.12.0. Done… can you verify it’s on the branch properly and working? Dan > > Thanks, > Paul > > On Thu, Jul 30, 2015 at 9:10 AM, Daniel Kulp wrote: > >> It’s been a while since 5.11.1 so I’d like to get a 5.11.2 release out >> shortly, probably early/mid next week.There’s not a lot of fixes on the >> branch right now, just stuff mostly necessary for OSGi to support running >> ActiveMQ in Karaf4. >> >> If there are other fixes that people would like to get in, please get them >> cherry-picked to the activemq-5.11.x branch or send me the git hashes and I >> can take a look and get them merged. >> >> Thanks! >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
5.11.2....
It’s been a while since 5.11.1 so I’d like to get a 5.11.2 release out shortly, probably early/mid next week.There’s not a lot of fixes on the branch right now, just stuff mostly necessary for OSGi to support running ActiveMQ in Karaf4. If there are other fixes that people would like to get in, please get them cherry-picked to the activemq-5.11.x branch or send me the git hashes and I can take a look and get them merged. Thanks! -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Git workflow for committers
> On Jun 9, 2015, at 9:56 PM, Clebert wrote: > > +1. Although Only question I have: > > With git it's not really needed to create a branch in the main repo for > temporary branches. Depends on the purpose….. If I was going to work on a relatively large idea/change and want to collaborate with another committer, a branch at Apache makes a lot of sense. For example, I’m thinking about creating one to work on the CXF change. I can keep working on it, all commits would still go to the commits@ list so everyone can see what’s going on. Others could help out, etc… Once “done”, it could be merged to master and the branch removed. > But If someone did it thought. Is it easy to remove a branch with Apache > git? I have the impression that you need Infra guys to delete branches? > If only infra structure guys can delete branches I would not encourage > branches on the main repo. The only branch you cannot remove is master. Anything else is just like normal. Dan > > -- Clebert Suconic typing on the iPhone. > >> On Jun 9, 2015, at 20:22, Daniel Kulp wrote: >> >> I guess if it was up to me to actually write a formal doc describing the >> process it would go something like: >> >> >> ——— >> >> ActiveMQ uses a Commit-Then-Review process for getting changes contributed >> to the development branches. In general, this means the ActiveMQ >> committers are free to directly commit their own work to master and push >> those changes to the canonical repository at Apache. However, the >> expectation is that the developer has made a good effort to test their >> changes and is reasonably confident that the changes that are being >> committed will not “break the build.” >> >> What does it mean to be reasonably confident? That may depend on the >> developer. If the developer has run the same maven commands that the CI >> builds are running, they can likely be reasonably confident. However, if >> the changes are significant, touches a wide area of code, or even if the >> developer just wants a second opinion, they are encouraged to engage other >> members of the community to obtain an additional review prior to commit. >> This can easily be done via a pull request on github, a patch file attached >> to an email or JIRA, committed to a branch in the Apache git repo, etc… >> There are a variety of options open to them.Having additional eyes >> looking at significant changes prior to committing to the main development >> branches is definitely encouraged if it helps obtain the “reasonable >> confidence” that the build is not broken and code quality has not decreased. >> We also have automatic builds setup to test github pull requests in advance >> to help establish a good level of confidence in the build. >> >> However, “things happen”. We’re all human. In the case where the build >> does break, the expectation is that the developer will make a best effort to >> get the builds fixed in a reasonable amount of time.If it cannot be >> fixed in a reasonable amount of time, the commit can be reverted and >> re-reviewed. >> >> ——— >> >> Everyone: does that about cover it?Did I miss anything?The github >> pull requests and gui tools are definitely a good tool chain in certain >> cases and I would still encourage those folks that find value in them to >> continue using them. However, they cannot be “required”. >> >> >> Dan >> >> >> >> >> >> >>>> On Jun 9, 2015, at 7:57 PM, Clebert Suconic >>>> wrote: >>>> >>>> +1 to stay with the existing CTR practice that is well established in the >>>> ActiveMQ community. That's why committership is granted. It's a level of >>>> trust and confidence that you don't make low hanging fruit errors. >>> >>> I actually screw up all the time ;) But I rather make eventual >>> mistakes than not do something :) >>> >>> Anyways... lets keep the pull requests as a tool. For instance I just >>> prevented an issue because of a PR Build >>> >>> https://builds.apache.org/job/ActiveMQ-Artemis-PR-Build/418/ >>> https://github.com/apache/activemq-artemis/pull/22 >>> >>> But I don't want to talk about the issue itself on this Thread... This >>> is a meta discussion.. I will talk about the issue itself on another >>> post I'm about to make >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Git workflow for committers
I guess if it was up to me to actually write a formal doc describing the process it would go something like: ——— ActiveMQ uses a Commit-Then-Review process for getting changes contributed to the development branches. In general, this means the ActiveMQ committers are free to directly commit their own work to master and push those changes to the canonical repository at Apache. However, the expectation is that the developer has made a good effort to test their changes and is reasonably confident that the changes that are being committed will not “break the build.” What does it mean to be reasonably confident? That may depend on the developer. If the developer has run the same maven commands that the CI builds are running, they can likely be reasonably confident. However, if the changes are significant, touches a wide area of code, or even if the developer just wants a second opinion, they are encouraged to engage other members of the community to obtain an additional review prior to commit. This can easily be done via a pull request on github, a patch file attached to an email or JIRA, committed to a branch in the Apache git repo, etc… There are a variety of options open to them.Having additional eyes looking at significant changes prior to committing to the main development branches is definitely encouraged if it helps obtain the “reasonable confidence” that the build is not broken and code quality has not decreased. We also have automatic builds setup to test github pull requests in advance to help establish a good level of confidence in the build. However, “things happen”. We’re all human. In the case where the build does break, the expectation is that the developer will make a best effort to get the builds fixed in a reasonable amount of time.If it cannot be fixed in a reasonable amount of time, the commit can be reverted and re-reviewed. ——— Everyone: does that about cover it?Did I miss anything?The github pull requests and gui tools are definitely a good tool chain in certain cases and I would still encourage those folks that find value in them to continue using them. However, they cannot be “required”. Dan > On Jun 9, 2015, at 7:57 PM, Clebert Suconic wrote: > >> +1 to stay with the existing CTR practice that is well established in the >> ActiveMQ community. That's why committership is granted. It's a level of >> trust and confidence that you don't make low hanging fruit errors. > > I actually screw up all the time ;) But I rather make eventual > mistakes than not do something :) > > Anyways... lets keep the pull requests as a tool. For instance I just > prevented an issue because of a PR Build > > https://builds.apache.org/job/ActiveMQ-Artemis-PR-Build/418/ > https://github.com/apache/activemq-artemis/pull/22 > > But I don't want to talk about the issue itself on this Thread... This > is a meta discussion.. I will talk about the issue itself on another > post I'm about to make -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Artemis and Eclipse...
> On Jun 8, 2015, at 6:47 PM, Clebert Suconic wrote: > > True, > > although I think it makes sense to fix the javadoc stuff anyways to > not require that setting I started looking at this. Definitely a lot more involved than I was expecting. It was definitely the right call to add the setting to get the release out. At this point a “mvn -Pdev install” will now work without that setting. That’s a good start. The javadoc run in artemis-website now will run without an error. (plenty of warnings though) However, javadoc in the individual modules still fails. Since the javadoc in the modules is part of the deploy (and release) process, we still need the switch. One step at a time….. Dan > > On Mon, Jun 8, 2015 at 6:41 PM, Hiram Chirino wrote: >> I would not recommend exerting too much effort in maintaining Java 7 >> support since Java 7 is EOL. The only type of lib I would say should >> keep old Java support for is client libs. There are some platforms >> out there that don't rev that quickly (stuff like GWT, Android, etc). >> Would it makes sense to keep clients libs in builds outside of >> Artemis? >> >> On Mon, Jun 8, 2015 at 5:57 PM, Clebert Suconic >> wrote: >>> The first try was using profiles but it was kind of messy. This was >>> done very closely to the releases and I didn't have time to evaluate >>> any other options back then. >>> >>> If all we need is to fix javadoc, I would say we fix javadoc and >>> remove the java8 dependency (at least for now). I'm not sure yet how >>> difficult that would be though >>> >>> >>> >>> On Mon, Jun 8, 2015 at 5:45 PM, Robbie Gemmell >>> wrote: >>>> Do you mean the -Xdoclint:none option? Javadoc is stricter with Java8 >>>> and will refuse to process things that 'worked' with Java7. You can >>>> make it lenient again using the -Xdoclint config option, but that only >>>> works when using Java8 and so setting it then makes javadoc processing >>>> fail when building on Java7 since it doesnt understand the new config >>>> option. >>>> >>>> When I first hit this elsewhere I just updated all the javadoc to >>>> remove the errors seen using Java8, allowing things to work on 7 or 8 >>>> without disabling doclint. You could possibly use profiles to apply >>>> the config selectively. >>>> >>>> Robbie >>>> >>>> On 8 June 2015 at 22:23, Clebert Suconic wrote: >>>>> The only thing I remember we had to add JDK 1.8 to the equation was >>>>> some option we needed for building javadocs. Perhaps there is a better >>>>> way to solve that. >>>>> >>>>> Right now the codebase is not using anything specific to JDK 1.8. (I >>>>> mean.. at least that's the idea. we could have slipped something.. but >>>>> I don't recall anything specific to java8 in the codebase) >>>>> >>>>> On Mon, Jun 8, 2015 at 2:35 PM, Daniel Kulp wrote: >>>>>> I’ve updated a bunch of things so that Artemis now loads fairly easily >>>>>> into Eclipse without any errors for all the non-example things.I >>>>>> haven’t attempted the examples yet. >>>>>> >>>>>> Just have a couple of questions: >>>>>> >>>>>> 1) In the poms, we specify that Java8 is required to build, but java7 is >>>>>> used for the source/target. Thus, Eclipse will pick up the Java7 >>>>>> runtime. It seems to work OK so I’m kind of wondering why we require >>>>>> Java8 to build. Maybe in the examples someplace? >>>>>> >>>>>> 2) artemis-dto has a profile for jdk-1.5. I assume that is not needed >>>>>> at all as there is no way it would ever be triggered. I think the >>>>>> ibmjdk profile in there is irrelevant as well? (seems to reference >>>>>> things about differences between 1.5 and 1.6) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Daniel Kulp >>>>>> dk...@apache.org - http://dankulp.com/blog >>>>>> Talend Community Coder - http://coders.talend.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Clebert Suconic >>>>> http://community.jboss.org/people/clebert.suco...@jboss.com >>>>> http://clebertsuconic.blogspot.com >>> >>> >>> >>> -- >>> Clebert Suconic >>> http://community.jboss.org/people/clebert.suco...@jboss.com >>> http://clebertsuconic.blogspot.com >> >> >> >> -- >> Hiram Chirino >> Engineering | Red Hat, Inc. >> hchir...@redhat.com | fusesource.com | redhat.com >> skype: hiramchirino | twitter: @hiramchirino > > > > -- > Clebert Suconic > http://community.jboss.org/people/clebert.suco...@jboss.com > http://clebertsuconic.blogspot.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Git workflow for committers
> On Jun 9, 2015, at 12:08 PM, Clebert Suconic > wrote: > On Tue, Jun 9, 2015 at 11:09 AM, Daniel Kulp wrote: >> >> Just to follow up, I have nothing against others using the github tooling or >> whatever if they feel that makes their job easier/faster/better. If other >> members of the community want to keep developing that way, that’s ok. I’m >> NOT ok with mandating the use of github tooling or requiring any other >> "review then commit" workflow. > > You should be responsible for testing your commits before they enter > the build then. Please keep an eye on the build you created. Agreed. > Also: I'm afraid of people pushing directly on git for wrong merge > committs and other things that can easily get broken. > > And BTW: the build you created is sending emails anywhere in case of bad > builds? In theory, yes. According to the configuration, it should be sending to comm...@activemq.apache.org and to the individuals. However, we’d need someone to break the build to test it.Any volunteers? :-) -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Git workflow for committers
Just to follow up, I have nothing against others using the github tooling or whatever if they feel that makes their job easier/faster/better. If other members of the community want to keep developing that way, that’s ok. I’m NOT ok with mandating the use of github tooling or requiring any other "review then commit" workflow. Dan > On Jun 9, 2015, at 11:03 AM, Daniel Kulp wrote: > >> >> On Jun 9, 2015, at 10:47 AM, Andy Taylor wrote: >> >> Dan, >> >> are you implying you are going to bypass the workflow that everyone else is >> using and commit directly? shouldnt we be consistent? > > That IS being consistent with the workflow that the *ACTIVEMQ* community has > been using for the last 10+ years and has been using with the git repo for > the last 2 years.So yes, I will be using the workflow that the community > has agreed on and been using. Thanks for asking. > > Dan > > >> >> On 09/06/15 15:45, Daniel Kulp wrote: >>> >>>> On Jun 9, 2015, at 10:32 AM, Clebert Suconic >>>> wrote: >>>> >>>>> It turns out we didn’t have a build setup for that. We do now. >>>> >>>> The build I sent you before was a PR build from my own PR. Unless you >>>> set it up somewhere. Did you set up a new build for that? >>> >>> Yes: >>> >>> https://builds.apache.org/view/A-D/view/ActiveMQ/job/ActiveMQ-Artemis-Master/ >>> >>> It builds on each commit to the canonical repository. >>> >>> >>> Dan >>> >>> >>> >>>> >>>> On Tue, Jun 9, 2015 at 10:29 AM, Clebert Suconic >>>> wrote: >>>>>> Well, I fixed that situation this morning. I *THOUGHT* we had a CI >>>>>> build that was running on master on all commits. That was the >>>>>> expectation and if something broke I would have gotten a “this is >>>>>> broken” email within 15 minutes or so. It turns out we didn’t have a >>>>>> build setup for that. We do now. >>>>>> >>>>> >>>>> I was not being specific about the situation itself.. just finding it >>>>> as an example on where the CI build would been useful. >>>>> >>>>> We have a CI build that run on every Pull Request, not on every commit. >>>>> >>>>> We have a daily build but they are not as fast on catching issues. >>>>> >>>>> >>>>>>> I'm asking if you could at least send a PR and wait for the build to >>>>>>> finish. >>>>>> >>>>>> How do I do a pull request that doesn’t involve github? I’m not using >>>>>> github for development. >>>>>> >>>>> >>>>> You really need github for that. You would need a github account >>>>> associated with your apache email and send send the PR. >>>>> >>>>> You don't want to use github at all? If you don't want to use github, >>>>> then you certainly won't be able to use these tools. >>>>> >>>>> Do you have any issues on using github? >>>> >>>> >>>> >>>> -- >>>> Clebert Suconic >>>> http://community.jboss.org/people/clebert.suco...@jboss.com >>>> http://clebertsuconic.blogspot.com >>> >> > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Git workflow for committers
> On Jun 9, 2015, at 10:47 AM, Andy Taylor wrote: > > Dan, > > are you implying you are going to bypass the workflow that everyone else is > using and commit directly? shouldnt we be consistent? That IS being consistent with the workflow that the *ACTIVEMQ* community has been using for the last 10+ years and has been using with the git repo for the last 2 years.So yes, I will be using the workflow that the community has agreed on and been using. Thanks for asking. Dan > > On 09/06/15 15:45, Daniel Kulp wrote: >> >>> On Jun 9, 2015, at 10:32 AM, Clebert Suconic >>> wrote: >>> >>>> It turns out we didn’t have a build setup for that. We do now. >>> >>> The build I sent you before was a PR build from my own PR. Unless you >>> set it up somewhere. Did you set up a new build for that? >> >> Yes: >> >> https://builds.apache.org/view/A-D/view/ActiveMQ/job/ActiveMQ-Artemis-Master/ >> >> It builds on each commit to the canonical repository. >> >> >> Dan >> >> >> >>> >>> On Tue, Jun 9, 2015 at 10:29 AM, Clebert Suconic >>> wrote: >>>>> Well, I fixed that situation this morning. I *THOUGHT* we had a CI >>>>> build that was running on master on all commits. That was the >>>>> expectation and if something broke I would have gotten a “this is broken” >>>>> email within 15 minutes or so. It turns out we didn’t have a build >>>>> setup for that. We do now. >>>>> >>>> >>>> I was not being specific about the situation itself.. just finding it >>>> as an example on where the CI build would been useful. >>>> >>>> We have a CI build that run on every Pull Request, not on every commit. >>>> >>>> We have a daily build but they are not as fast on catching issues. >>>> >>>> >>>>>> I'm asking if you could at least send a PR and wait for the build to >>>>>> finish. >>>>> >>>>> How do I do a pull request that doesn’t involve github? I’m not using >>>>> github for development. >>>>> >>>> >>>> You really need github for that. You would need a github account >>>> associated with your apache email and send send the PR. >>>> >>>> You don't want to use github at all? If you don't want to use github, >>>> then you certainly won't be able to use these tools. >>>> >>>> Do you have any issues on using github? >>> >>> >>> >>> -- >>> Clebert Suconic >>> http://community.jboss.org/people/clebert.suco...@jboss.com >>> http://clebertsuconic.blogspot.com >> > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Git workflow for committers
> On Jun 9, 2015, at 10:32 AM, Clebert Suconic > wrote: > >> It turns out we didn’t have a build setup for that. We do now. > > The build I sent you before was a PR build from my own PR. Unless you > set it up somewhere. Did you set up a new build for that? Yes: https://builds.apache.org/view/A-D/view/ActiveMQ/job/ActiveMQ-Artemis-Master/ It builds on each commit to the canonical repository. Dan > > On Tue, Jun 9, 2015 at 10:29 AM, Clebert Suconic > wrote: >>> Well, I fixed that situation this morning. I *THOUGHT* we had a CI build >>> that was running on master on all commits. That was the expectation and >>> if something broke I would have gotten a “this is broken” email within 15 >>> minutes or so. It turns out we didn’t have a build setup for that. We >>> do now. >>> >> >> I was not being specific about the situation itself.. just finding it >> as an example on where the CI build would been useful. >> >> We have a CI build that run on every Pull Request, not on every commit. >> >> We have a daily build but they are not as fast on catching issues. >> >> >>>> I'm asking if you could at least send a PR and wait for the build to >>>> finish. >>> >>> How do I do a pull request that doesn’t involve github? I’m not using >>> github for development. >>> >> >> You really need github for that. You would need a github account >> associated with your apache email and send send the PR. >> >> You don't want to use github at all? If you don't want to use github, >> then you certainly won't be able to use these tools. >> >> Do you have any issues on using github? > > > > -- > Clebert Suconic > http://community.jboss.org/people/clebert.suco...@jboss.com > http://clebertsuconic.blogspot.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Git workflow for committers
> On Jun 9, 2015, at 10:15 AM, Clebert Suconic > wrote: > > The commit-then-review doesn't really scale. If someone breaks stuff > that means someone else will have to review and test it. > > For instance, yesterday I spent one hour of my catching up time with > Game Of Thrones to find what broke the build :) > > the commit-then-review means that *someone like me* will have to go > over and find what broke it. > > On the case it was the m2e change that opened a JDK bug / Whatever > compilation bug. > > There is no way you could have caught that bug without a CI build that > we currently have. Well, I fixed that situation this morning. I *THOUGHT* we had a CI build that was running on master on all commits. That was the expectation and if something broke I would have gotten a “this is broken” email within 15 minutes or so. It turns out we didn’t have a build setup for that. We do now. > I'm asking if you could at least send a PR and wait for the build to finish. How do I do a pull request that doesn’t involve github? I’m not using github for development. Dan > For me the workflow is a tool to avoid mistakes, not an enforced rule. > So, I don't want to get political on the workflow and I don't want to > dictate how you work. > > If you don't want someone else reviewing your commit, please at least > send the PR, wait for a Successful build from the CI, that enhances > your testing. > > If you could wait someone else to merge it do it. If you really don't > want to wait push it yourself but I would appreciate if you could at > least wait the CI build to finish and avoid errors. > > > (notice I'm saying avoiding... we all break stuff from time to time, > so this is just a tool) > > > > > > On Mon, Jun 8, 2015 at 4:02 PM, Daniel Kulp wrote: >> >>> On Jun 8, 2015, at 2:07 PM, Bruce Snyder wrote: >>> >>> In general, there are two approaches to the use of SCM on ASF projects: >>> >>> 1) Commit then review (CTR) >>> 2) Review then commit (RTC) >>> >>> As Dan pointed out above, the ActiveMQ repo has always been CTR and I see >>> no reason to change this. What I asked about is the general workflow used >>> on the ActiveMQ repo, not the Artemis repo. I know that Artemis uses Github >>> as the primary entry point, but to my knowledge ActiveMQ is not using >>> Github in this way. Is this assumption correct? >> >> Correct. For the most part, the committers on all the repos other than >> activemq-artemis push directly to master as they complete development. >> Commits are then cherry-picked as needed back to the various fixes branches. >> >> >> Basically, workflow for committers: >> >> git clone https://git1-us-west.apache.org/repos/asf/activemq.git >> work work work work >> git commit …. >> git pull —rebase >> git push origin master >> >> Obviously there are various “mvn test” things in there. >> >> Github is not involved at all. >> >> For non-committers, we certainly can and should encourage github pull >> requests. In addition, patches attached to JIRA’s are perfectly acceptable. >> >> Dan >> >> >> >>> Now that we are talking about different workflows for different repos, I >>> think we should document the recommended git workflow for both the ActiveMQ >>> repo and the Artemis repo (and any repos that get created in the future). >>> >>> Bruce >>> >>> On Mon, Jun 8, 2015 at 10:19 AM, Andy Taylor wrote: >>> >>>> Daniel, >>>> >>>> Bruce asked about the workflow that committers use today because of some >>>> questions that were raised. I dont think any replies are mandating that >>>> ActiveMQ should follow a different route they are just commenting on the >>>> way they currently work. This is just a discussion about the pros and cons >>>> of different approaches as far as I can see and to document what ActiveMQ >>>> currently does, I'm not sure this is currently documented. >>>> >>>> >>>> On 08/06/15 17:01, Daniel Kulp wrote: >>>> >>>>> Apache ActiveMQ has always been “Commit then Review”.This workflow >>>>> completely changes that and if you want to start the whole argument about >>>>> an external project subsuming the processes that are currently in place >>>>> for >>>>> THIS project, feel free. It likely won’t go well. >>>
Re: Artemis - CXF
> On Jun 9, 2015, at 8:48 AM, John D. Ament wrote: > Is this a big priority to pick up? It would be my #1 priority, followed closely by OSGi support. In the whole “scratch the itch” methodology, it’s what I’m planning on working on. > Resteasy is already Apache V2 licensed, > so it doesn't cause a licensing conflict, though I agree being able to > leverage the rest api in containers that aren't deploying resteasy would be > beneficial. The problem is parts of the JAX-RS APIs end up having problems if there are multiple JAX-RS implementations available. It holds onto the various things in statics based on the first implementation that is found. Thus, those containers that provide JAX-RS based on CXF will have potential issues if Resteasy is brought in as well. Since Resteasy isn’t needed, it might as well be made optional. If Artemis is to provide JMS 2.0 support for TomEE or ServiceMix, we need to get CXF support working. > The bootstrap code is resteasy specific, but it seems to be used mostly > during tests. it seems like some of these changes would put pretty big > overheads on how the rest api works. The current rest api just takes > whatever body came along and converts it to a message, and provides > messages back with the streams directly. I don’t think any of that would necessarily have to change, but we’ll find out more as we refactor this. It’s still JAX-RS, it’s just a matter of whether its CXF or RestEasy handling the mapping and unmarshalling and such. Dan > > On Tue, Jun 9, 2015 at 5:25 AM Daniel Kulp wrote: > >> >> I’m going to start working on replacing RestEASY with CXF for the Artemis >> REST stuff but wanted to start a quick discussion first about how we should >> do this. Looking through the code briefly, I think there are three >> “types” of code: >> >> 1) Pure JAX-RS things and the object models for the mappings to/from the >> rest<->JMS >> >> 2) Some RestEASY things that could be refactored into (1). There are a >> bunch of client things (even using deprecated RestEASY classes) that can be >> refactored into (1) >> >> 3) Pure RestEASY bootstrap things >> >> #2 is likely a “no brainer”, IMO. So the question is what to do about >> 3? Should we split the current artemis-rest into three modules? On that >> would contain all the non-implementation specific things and one specific >> for CXF and one for RestEASY?Would that be >> artemis-rest-common/artemis-rest-cxf/artemis-rest-resteasy? >> >> The other option is to try and put the CXF and RestEASY code both into >> artemis-rest and declare all the deps optional+provided and try to >> determine the impl that is available at runtime and do something smart. >> (might be able to detect jersey as well). That seems a bit convoluted >> though. >> >> I’m not really considering dropping RestEASY entirely for CXF, but I >> suppose that is a path to mention just for completeness. >> >> Thoughts? >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Artemis - CXF
I’m going to start working on replacing RestEASY with CXF for the Artemis REST stuff but wanted to start a quick discussion first about how we should do this. Looking through the code briefly, I think there are three “types” of code: 1) Pure JAX-RS things and the object models for the mappings to/from the rest<->JMS 2) Some RestEASY things that could be refactored into (1). There are a bunch of client things (even using deprecated RestEASY classes) that can be refactored into (1) 3) Pure RestEASY bootstrap things #2 is likely a “no brainer”, IMO. So the question is what to do about 3? Should we split the current artemis-rest into three modules? On that would contain all the non-implementation specific things and one specific for CXF and one for RestEASY?Would that be artemis-rest-common/artemis-rest-cxf/artemis-rest-resteasy? The other option is to try and put the CXF and RestEASY code both into artemis-rest and declare all the deps optional+provided and try to determine the impl that is available at runtime and do something smart. (might be able to detect jersey as well).That seems a bit convoluted though. I’m not really considering dropping RestEASY entirely for CXF, but I suppose that is a path to mention just for completeness. Thoughts? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Artemis and Eclipse...
Seems to be an issue with the maven-compiler-plugin. Backing down to 3.1 makes it go away. I tried 3.3 and 3.2 and both caused the issue. Strange. Need to dig through the compiler plugin to see what might have changed to cause this. Dan > On Jun 8, 2015, at 11:53 PM, Clebert Suconic > wrote: > > Daniel: > > I am sending a revert for your commit on m2e on this PR: > https://github.com/apache/activemq-artemis/pull/20 > > > > The PR check is failing with a JDK bug caused by the commit your sent. > I have no idea on how to fix it now. > This is build failure: > https://builds.apache.org/job/ActiveMQ-Artemis-PR-Build/409/ > > I will have to revert this now as I can't compile on the PR check and > in Linux box I have for my own tests. > > > On Mon, Jun 8, 2015 at 2:35 PM, Daniel Kulp wrote: >> I’ve updated a bunch of things so that Artemis now loads fairly easily into >> Eclipse without any errors for all the non-example things.I haven’t >> attempted the examples yet. >> >> Just have a couple of questions: >> >> 1) In the poms, we specify that Java8 is required to build, but java7 is >> used for the source/target. Thus, Eclipse will pick up the Java7 runtime. >> It seems to work OK so I’m kind of wondering why we require Java8 to build. >> Maybe in the examples someplace? >> >> 2) artemis-dto has a profile for jdk-1.5. I assume that is not needed at >> all as there is no way it would ever be triggered. I think the ibmjdk >> profile in there is irrelevant as well? (seems to reference things about >> differences between 1.5 and 1.6) >> >> >> >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> > > > > -- > Clebert Suconic > http://community.jboss.org/people/clebert.suco...@jboss.com > http://clebertsuconic.blogspot.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Git workflow for committers
> On Jun 8, 2015, at 2:07 PM, Bruce Snyder wrote: > > In general, there are two approaches to the use of SCM on ASF projects: > > 1) Commit then review (CTR) > 2) Review then commit (RTC) > > As Dan pointed out above, the ActiveMQ repo has always been CTR and I see > no reason to change this. What I asked about is the general workflow used > on the ActiveMQ repo, not the Artemis repo. I know that Artemis uses Github > as the primary entry point, but to my knowledge ActiveMQ is not using > Github in this way. Is this assumption correct? Correct. For the most part, the committers on all the repos other than activemq-artemis push directly to master as they complete development. Commits are then cherry-picked as needed back to the various fixes branches. Basically, workflow for committers: git clone https://git1-us-west.apache.org/repos/asf/activemq.git work work work work git commit …. git pull —rebase git push origin master Obviously there are various “mvn test” things in there. Github is not involved at all. For non-committers, we certainly can and should encourage github pull requests. In addition, patches attached to JIRA’s are perfectly acceptable. Dan > Now that we are talking about different workflows for different repos, I > think we should document the recommended git workflow for both the ActiveMQ > repo and the Artemis repo (and any repos that get created in the future). > > Bruce > > On Mon, Jun 8, 2015 at 10:19 AM, Andy Taylor wrote: > >> Daniel, >> >> Bruce asked about the workflow that committers use today because of some >> questions that were raised. I dont think any replies are mandating that >> ActiveMQ should follow a different route they are just commenting on the >> way they currently work. This is just a discussion about the pros and cons >> of different approaches as far as I can see and to document what ActiveMQ >> currently does, I'm not sure this is currently documented. >> >> >> On 08/06/15 17:01, Daniel Kulp wrote: >> >>> Apache ActiveMQ has always been “Commit then Review”.This workflow >>> completely changes that and if you want to start the whole argument about >>> an external project subsuming the processes that are currently in place for >>> THIS project, feel free. It likely won’t go well. >>> >>> Second, a rule at Apache is if it didn’t appear on our lists, it’s not >>> done. Thus, anything NOT pushed to Apache hasn’t happened. There isn’t >>> anything to discuss. Anything you do in your personal github fork is >>> irrelevant until it appears in the Apache repo and the appropriate commit >>> messages sent off to the dev list to be reviewed. That’s exactly why I >>> said feature branches can be done at Apache. >>> >>> And your #3 also completely changes how ActiveMQ has worked in the past. >>> Again, not something to be taken lightly. (and something I would vote >>> against) >>> >>> Dan >>> >>> >>> >>> On Jun 8, 2015, at 9:54 AM, Justin Bertram wrote: >>>> >>>> Daniel, the workflow is essentially what I follow as a committer. I >>>> never push straight to the master on the official Apache repo. GitHub >>>> offers me a few distinct advantages: >>>> >>>> 1. Automated PR builds. I could run the PR build locally but then >>>> that ties up my machine when I could be working on something else. >>>> 2. Chance for discussion *before* the commit is made on the official >>>> Apache repo. If there's something wrong with the PR then you want to catch >>>> it before it's committed, not after. >>>> 3. Allows someone other than the developer who made the changes to >>>> merge the commit. This is a rule we follow pretty closely and it should >>>> probably be specifically outlined in the hackng guide. >>>> >>>> BTW, here's some notes specifically for project maintainers: >>>> https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/en/maintainers.md >>>> >>>> >>>> Justin >>>> >>>> - Original Message - >>>> From: "Daniel Kulp" >>>> To: dev@activemq.apache.org >>>> Sent: Monday, June 8, 2015 8:41:56 AM >>>> Subject: Re: Git workflow for committers >>>> >>>> >>>> On Jun 8, 2015, at 9:35 AM, Justin Bertram wrote: >>>>> >>>>> We recently published a Hacking Guide that outlines the typical &g
Artemis and Eclipse...
I’ve updated a bunch of things so that Artemis now loads fairly easily into Eclipse without any errors for all the non-example things.I haven’t attempted the examples yet. Just have a couple of questions: 1) In the poms, we specify that Java8 is required to build, but java7 is used for the source/target. Thus, Eclipse will pick up the Java7 runtime. It seems to work OK so I’m kind of wondering why we require Java8 to build. Maybe in the examples someplace? 2) artemis-dto has a profile for jdk-1.5. I assume that is not needed at all as there is no way it would ever be triggered. I think the ibmjdk profile in there is irrelevant as well? (seems to reference things about differences between 1.5 and 1.6) -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Git workflow for committers
Apache ActiveMQ has always been “Commit then Review”.This workflow
completely changes that and if you want to start the whole argument about an
external project subsuming the processes that are currently in place for THIS
project, feel free. It likely won’t go well.
Second, a rule at Apache is if it didn’t appear on our lists, it’s not done.
Thus, anything NOT pushed to Apache hasn’t happened. There isn’t anything to
discuss. Anything you do in your personal github fork is irrelevant until it
appears in the Apache repo and the appropriate commit messages sent off to the
dev list to be reviewed. That’s exactly why I said feature branches can be
done at Apache.
And your #3 also completely changes how ActiveMQ has worked in the past.
Again, not something to be taken lightly. (and something I would vote against)
Dan
> On Jun 8, 2015, at 9:54 AM, Justin Bertram wrote:
>
> Daniel, the workflow is essentially what I follow as a committer. I never
> push straight to the master on the official Apache repo. GitHub offers me a
> few distinct advantages:
>
> 1. Automated PR builds. I could run the PR build locally but then that ties
> up my machine when I could be working on something else.
> 2. Chance for discussion *before* the commit is made on the official Apache
> repo. If there's something wrong with the PR then you want to catch it
> before it's committed, not after.
> 3. Allows someone other than the developer who made the changes to merge the
> commit. This is a rule we follow pretty closely and it should probably be
> specifically outlined in the hackng guide.
>
> BTW, here's some notes specifically for project maintainers:
> https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/en/maintainers.md
>
>
> Justin
>
> - Original Message -
> From: "Daniel Kulp"
> To: dev@activemq.apache.org
> Sent: Monday, June 8, 2015 8:41:56 AM
> Subject: Re: Git workflow for committers
>
>
>> On Jun 8, 2015, at 9:35 AM, Justin Bertram wrote:
>>
>> We recently published a Hacking Guide that outlines the typical development
>> cycle:
>> https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/en/code.md#typical-development-cycle
>>
>> Improvements are certainly welcome.
>
> I think this is ok for workflow for non-committers. Nice to have that
> documented. Committers should not have to go through github.
>
> In particular: step 4 can just be push your branch to a new branch at Apache.
> There isn’t a need for github for that
> Step 5: if you push to Apache in step 4, all the commits would be on the
> Apache commits list and would be fine for discussion from there.
> Step 7: if you are a committer, just push it to master. There is no need
> for the pull requests from github.
>
>
> Dan
>
>
>>
>>
>> Justin
>>
>> P.S. I already sent a PR to get the references to the old JIRA repo (i.e.
>> ACTIVEMQ6) updated to the new one (i.e. ARTEMIS).
>>
>> - Original Message -
>> From: "Bruce Snyder"
>> To: dev@activemq.apache.org
>> Sent: Sunday, June 7, 2015 2:10:14 PM
>> Subject: Git workflow for committers
>>
>> New committer Marc Schöchlin has raised some questions about the git
>> workflow to use as he continues to work on the init scripts. This is a
>> perfect opportunity for all committers to discuss the workflow that we
>> recommend be used when working on ActiveMQ projects and I will document the
>> end result on the wiki in association with the 'How To Become a
>> Committer...' page.
>>
>> After many years of experience with git, I am a big fan of git flow (
>> http://nvie.com/posts/a-successful-git-branching-model/) but I don't
>> believe that is being used on ActiveMQ. So what is the general git workflow
>> that committers use today?
>>
>> Bruce
>>
>> --
>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E>
>> ActiveMQ in Action: http://bit.ly/2je6cQ
>> Blog: http://bruceblog.org/
>> Twitter: http://twitter.com/brucesnyder
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Git workflow for committers
> On Jun 8, 2015, at 9:35 AM, Justin Bertram wrote:
>
> We recently published a Hacking Guide that outlines the typical development
> cycle:
> https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/en/code.md#typical-development-cycle
>
> Improvements are certainly welcome.
I think this is ok for workflow for non-committers. Nice to have that
documented. Committers should not have to go through github.
In particular: step 4 can just be push your branch to a new branch at Apache.
There isn’t a need for github for that
Step 5: if you push to Apache in step 4, all the commits would be on the
Apache commits list and would be fine for discussion from there.
Step 7: if you are a committer, just push it to master. There is no need for
the pull requests from github.
Dan
>
>
> Justin
>
> P.S. I already sent a PR to get the references to the old JIRA repo (i.e.
> ACTIVEMQ6) updated to the new one (i.e. ARTEMIS).
>
> - Original Message -
> From: "Bruce Snyder"
> To: dev@activemq.apache.org
> Sent: Sunday, June 7, 2015 2:10:14 PM
> Subject: Git workflow for committers
>
> New committer Marc Schöchlin has raised some questions about the git
> workflow to use as he continues to work on the init scripts. This is a
> perfect opportunity for all committers to discuss the workflow that we
> recommend be used when working on ActiveMQ projects and I will document the
> end result on the wiki in association with the 'How To Become a
> Committer...' page.
>
> After many years of experience with git, I am a big fan of git flow (
> http://nvie.com/posts/a-successful-git-branching-model/) but I don't
> believe that is being used on ActiveMQ. So what is the general git workflow
> that committers use today?
>
> Bruce
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [jira] [Created] (AMQNET-500) Using Ssl transport with certificates failure
I just wanted to point out that this message went to the new iss...@activemq.apache.org address with the reply-to set to the dev list. Thus, it looks like the new issues list is working correctly. Make sure you subscribe if you are interested in the JIRA notifications. Dan > On Apr 29, 2015, at 1:51 PM, Enrique García (JIRA) > wrote: > > Enrique García created AMQNET-500: > - > > Summary: Using Ssl transport with certificates failure > Key: AMQNET-500 > URL: https://issues.apache.org/jira/browse/AMQNET-500 > Project: ActiveMQ .Net > Issue Type: Bug > Components: ActiveMQ >Affects Versions: 1.7.1 > Environment: Mono >Reporter: Enrique García >Assignee: Jim Gomes >Priority: Minor > > > Using the SSL transport and a certificate from the X509Store with mono is not > possible. That is because of a bug in the mono implementation of the > X509Store (I sent a patch yesterday). The X509Store.Certificates returns a > reference to the internal list of certificates which is closed after calling > X509Store.Close(). I implemented a workaround in the code you could use if > you consider it useful. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] ActiveMQ {CodeName} Must-Have Features...
Couple things I think are important:
1) OSGi support - in particular the Karaf features and various commands and
such for starting and configuring the brokers within Karaf.
2) Related to (1) - using the “normal” libraries that we would use within
Karaf. The particular one I’m thinking of is using CXF for the activemq-rest
stuff instead of ActiveMQ. There are issues with having two JAX-RS
implementations within a runtime so I would think it’s important to be able to
use the one more of us are using within Karaf.
I think those would be somewhat required for being able to have a ServiceMix
that uses this.
Dan
> On Apr 15, 2015, at 11:56 AM, James Carman wrote:
>
> In order for ActiveMQ {CodeName} to take over as the next generation
> of ActiveMQ, it obviously must have some level of feature parity with
> the existing ActiveMQ 5.x (or 6.x if it's released before that
> transition) offering. We should come up with some level of a roadmap
> together about which features are required. Thus far, the only
> big-ticket items that have been addressed are:
>
> 1. The OpenWire protocol is supported
> 2. Auto-creation of destinations (mostly complete).
>
> This is obviously not all of what the existing ActiveMQ is all about.
> What other features are folks wanting to see in the next generation
> ActiveMQ?
>
> James
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Legacy support for HornetQ
It’s one thing to “support” the old keys and another thing entirely to make
that the default and only option for developers to use right now. If I
download the new release from Apache (having never been a HornetQ user) and
start writing apps and such, I SHOULD be using AMQ* keys and properties, not
HQ* keys. Thus, I think the patch needs to do something like:
private static final SimpleString AMQ_PROPNAME = new SimpleString("_AMQ_”);
@Deprecated
private static final SimpleString HQ_PROPNAME = new SimpleString("_HQ_");
and update the code to handle both at this point with plans to remove the HQ_
stuff at some point in the future.
Does that make sense?
Dan
> On Apr 14, 2015, at 12:47 PM, Bruce Snyder wrote:
>
> I'm currently at ApacheCon working with Hiram and Clebert and I have
> learned that the HornetQ project is now considered a legacy project -- the
> code is no longer maintained as the open source project HornetQ. The
> expectation is to migrate the HornetQ user base to the ActiveMQ community.
> We (the ActiveMQ community) still need to draft a plan of action for steps
> to take with the HornetQ code donation, and I think that this could be one
> of the things that is identified in that plan to help merge the two
> communities. When combining communities in this manner, the goals of the
> merger cannot be achieved without some level of compromise and I see this
> is as a minor compromise. Therefore, I see no issue with providing backward
> compatibility because it is a minor level of effort and yet it helps to
> provide a migration path for users of HornetQ (the HornetQ community) to
> make use of ActiveMQ .
>
> Bruce
>
>
> On Tue, Apr 14, 2015 at 11:30 AM, Tracy Snell wrote:
>
>> https://issues.apache.org/jira/browse/ACTIVEMQ6-97 <
>> https://issues.apache.org/jira/browse/ACTIVEMQ6-97> in the comments
>> indicates that AMQ6 needs to provide legacy support for HornetQ. This is a
>> surprise to me and I haven’t seen anything where this was mentioned as part
>> of the plan (and it’s entirely possible I just missed it). So I’m just
>> wanting clarification, with the HornetQ donation is ActiveMQ now required
>> to provide legacy support for HornetQ clients?
>>
>>
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [VOTE] Pick a code name for the HornetQ code donation
+1 for Artemis Dan > On Apr 14, 2015, at 11:42 AM, Hiram Chirino wrote: > > Now that we have chosen to give the HornetQ code donation a code name, > it's time to pick what that code name will be. Please select from one > of the following options: > > [a] ActiveMQ Artemis > [b] ActiveMQ Luna > [c] ActiveMQ Reactive > > Vote will be open for 72 hours. The option with the most votes will win. > > Regards, > Hiram > > -- > Hiram Chirino > Engineering | Red Hat, Inc. > hchir...@redhat.com | fusesource.com | redhat.com > skype: hiramchirino | twitter: @hiramchirino -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Fix Sorting of Board Reports
> On Apr 9, 2015, at 1:02 PM, Jim Gomes wrote: > > Thanks for the link, Dan. I didn't know those were there. I think the main > difference here is that link is to the Board Minutes, whereas the ActiveMQ > wiki has the Board Report. They seem to be identical, but will they always > be? Possibly not, but it would NORMALLY be because the board has decided something should be private (like names of people being voted on or something) in which case it should likely not have been in our public version as well. Doesn’t happen too often. Also, they would remove any “wiki formatting” type things that wouldn’t look right in the text form they use. > And even if they are identical, do we still need to have the redundancy > for trace-ability? For instance, if the Board, for whatever reason, claims > they didn't receive the report, we have documentation on the wiki showing > the Report was produced. I don’t really think the board would care if one was produced or not. It’s the chair’s job to make sure the board gets the report. If they don’t get it, they ask the chair to report again next month. If the chair consistently has issues, they’d likely replace the chair.Another thing to keep in mind: it’s the Chairs job to create the report that reflects the state of the community. The chair MAY include the wider community in creating that report, but that’s not a requirement. Thus, saying “the community produced one, the chair didn’t submit it” really wouldn’t matter at all. Dan > > That's me just trying to understand the reason for the Board Report page's > existence. > > -Jim > > > On Thu, Apr 9, 2015 at 9:53 AM, Daniel Kulp wrote: > >> >> No "objection", but why don't we just delete the page and point at the >> official records: >> >> https://whimsy.apache.org/board/minutes/ActiveMQ.html >> >> Dan >> >> >>> On Apr 9, 2015, at 12:35 PM, Jim Gomes wrote: >>> >>> I recently went out to look at previous Board Reports ( >>> http://activemq.apache.org/apache-activemq-board-reports.html) and found >>> the current sorting method difficult to deal with. Unless we are required >>> to use the page naming format, I would like to change it to the following >>> format: >>> >>> Apache ActiveMQ Board Report - 2009.01 January >>> Apache ActiveMQ Board Report - 2009.04 April >>> Apache ActiveMQ Board Report - 2009.07 July >>> . >>> . >>> . >>> >>> I would then set it to sort in reverse order so the most recent report is >>> automatically at the top, and they descend in chronological order. The >>> current sorting puts the most recent board report (2015/02) in the middle >>> of the pack, making it difficult to find. Good luck trying to find the >>> report directly prior to that. >>> >>> I will make the changes, unless anyone has other suggestions. >>> >>> Best, >>> Jim >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Fix Sorting of Board Reports
No “objection”, but why don’t we just delete the page and point at the official records: https://whimsy.apache.org/board/minutes/ActiveMQ.html Dan > On Apr 9, 2015, at 12:35 PM, Jim Gomes wrote: > > I recently went out to look at previous Board Reports ( > http://activemq.apache.org/apache-activemq-board-reports.html) and found > the current sorting method difficult to deal with. Unless we are required > to use the page naming format, I would like to change it to the following > format: > > Apache ActiveMQ Board Report - 2009.01 January > Apache ActiveMQ Board Report - 2009.04 April > Apache ActiveMQ Board Report - 2009.07 July > . > . > . > > I would then set it to sort in reverse order so the most recent report is > automatically at the top, and they descend in chronological order. The > current sorting puts the most recent board report (2015/02) in the middle > of the pack, making it difficult to find. Good luck trying to find the > report directly prior to that. > > I will make the changes, unless anyone has other suggestions. > > Best, > Jim -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
