You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by cmorgan <ch...@solace.com> on 2018/01/17 20:50:39 UTC
Re: [DISCUSS] Rework NMS.AMQP
Hi Everyone,
Happy New Year.
I have a progress update about the NMS AMQP API Rework. The work done in the
fork, https://github.com/cjwmorgan-sol-sys/nms-amqp, is close to being
finished. Duane and I have also signed the ICLA. I will follow what Tim
suggested by creating an NMS JIRA under the AMQNET project (if I'm mistaken
about the project please let me know). I will also be creating subtasks for
some task as Tim suggested, eg cleaning out code tree, update building
system, get automated unit tests running, commit new code base, etc.
Although some input or guidance for other subtasks to migrate to an apache
repository would be appreciated.
I will create the JIRA tasks tomorrow unless there is reason not to.
Let me know if there are any questions or concern.
Chris Morgan
-----
Chris Morgan
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
Re: [DISCUSS] Rework NMS.AMQP
Posted by Timothy Bish <ta...@gmail.com>.
On 02/01/2018 03:08 PM, cmorgan wrote:
> I have updated the README.md file in the fork, see
> https://github.com/cjwmorgan-sol-sys/nms-amqp, for the project to show the
> features supported by the amqp provider. Let me know if there are any
> questions.
>
> I have also been working on adding SSL/TLS configuration with client
> certificate authentication (as well as improving/adding transport
> configuration). I plan to make the amqp provider configure transport/SSL
> properties in similar way to ActiveMQ and Stomp providers, using the URI
> Query parameters. I think it would be a good to match the property names
> with ActiveMQ and Stomp property names as they seem to be similar to each
> other as well. Unless there is good reason not to.
>
> I noticed the ActiveMQ and Stomp have provider URI configuration pages, as
> well as build notes. Where and how are those created? I would think I will
> need to update those for the amqp provider pages, perhaps make a Jira Task?
> Although I can update the project README.md in the meantime if that's not
> good place to edit yet.
The NMS project website is generated from the pages that are maintained
in the Confluence Wiki. Since the project is being worked on outside
Apache for now it isn't yet time to add documentation for the project to
the NMS site.
> Chris Morgan
>
>
>
> -----
> Chris Morgan
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
>
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
Re: [DISCUSS] Rework NMS.AMQP
Posted by cmorgan <ch...@solace.com>.
I have updated the README.md file in the fork, see
https://github.com/cjwmorgan-sol-sys/nms-amqp, for the project to show the
features supported by the amqp provider. Let me know if there are any
questions.
I have also been working on adding SSL/TLS configuration with client
certificate authentication (as well as improving/adding transport
configuration). I plan to make the amqp provider configure transport/SSL
properties in similar way to ActiveMQ and Stomp providers, using the URI
Query parameters. I think it would be a good to match the property names
with ActiveMQ and Stomp property names as they seem to be similar to each
other as well. Unless there is good reason not to.
I noticed the ActiveMQ and Stomp have provider URI configuration pages, as
well as build notes. Where and how are those created? I would think I will
need to update those for the amqp provider pages, perhaps make a Jira Task?
Although I can update the project README.md in the meantime if that's not
good place to edit yet.
Chris Morgan
-----
Chris Morgan
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
Re: [DISCUSS] Rework NMS.AMQP
Posted by Timothy Bish <ta...@gmail.com>.
On 01/19/2018 05:23 PM, cmorgan wrote:
> I have created Jira issue AMQNET-575,
> https://issues.apache.org/jira/browse/AMQNET-575, with a few sub tasks. I
> plan to add more when/if needed. Duane and are working on documenting
> features of the API NMS will be implemented. The current repo is not feature
> complete although it is close to feature complete. I plan to add some more
> features like Durable Consumers and SSL configuration soon but not in my
> next commit. Once, Duane and I are finish the feature list I can post it in
> this discussion thread or perhaps it should go into the Root Jira issue? Or
> Both?
>
> Also, Tim the project can be built using the dotnet core sdk command line
> tool so long as you have the Framework Target installed. I was able to build
> it using the dotnet core sdk version 2.1.2, if you wish to build it without
> vs2017.
>
These all sound like good candidates for additions in the client
documentation ;)
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
Re: [DISCUSS] Rework NMS.AMQP
Posted by cmorgan <ch...@solace.com>.
I have created Jira issue AMQNET-575,
https://issues.apache.org/jira/browse/AMQNET-575, with a few sub tasks. I
plan to add more when/if needed. Duane and are working on documenting
features of the API NMS will be implemented. The current repo is not feature
complete although it is close to feature complete. I plan to add some more
features like Durable Consumers and SSL configuration soon but not in my
next commit. Once, Duane and I are finish the feature list I can post it in
this discussion thread or perhaps it should go into the Root Jira issue? Or
Both?
Also, Tim the project can be built using the dotnet core sdk command line
tool so long as you have the Framework Target installed. I was able to build
it using the dotnet core sdk version 2.1.2, if you wish to build it without
vs2017.
Chris Morgan
-----
Chris Morgan
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
Re: [DISCUSS] Rework NMS.AMQP
Posted by Duane Pauls <du...@gmail.com>.
Thanks for the feedback Tim. We're relatively new to the community so it's
very much appreciated.
We had planned to setup the 2017 project files to automatically pull in the
NMS and AmqpNetLite packages via NuGet. So there shouldn't be a need for
those planning to build this project to build the dependencies. I'd expect
this to be the "normal" path most would follow, but of course wouldn't
preclude anyone from building all of the dependencies. My view on this
would be that it is a bit off of the beaten path though, so if there were a
few hoops to jump through, it would be ok.
Does that make sense?
Thanks,
Duane
On Thu, Feb 15, 2018 at 3:54 PM, Timothy Bish <ta...@gmail.com> wrote:
> On 02/15/2018 11:57 AM, Duane Pauls wrote:
>
>> In particular, I think we are wondering whether it would be considered
>> feasible to work towards an initial release with the VS2017 project and
>> solution files. This would require those who want to build it to either
>> use VS2017 to build, or to use the dotnet sdk tool, as is described in the
>> 'Building' section of the README.md.
>>
>> If not considered a gating item for release, we would definitely consider
>> it as a future enhancement if this would be perceived to be of value.
>>
>> Cheers,
>> Duane
>>
>> On Wed, Feb 14, 2018 at 5:28 PM, cmorgan <ch...@solace.com>
>> wrote:
>>
>> Hi everyone,
>>>
>>> Tim's post about not having a platform to run Visual Studio 2017 recently
>>> sparked a discussion between Duane, Ragnar and I about adding project and
>>> solution files for older versions of visual studio to the NMS AMQP
>>> Provider
>>> and were looking for guidance.
>>>
>>> Currently, the project only contains visual studio 2017 project and
>>> solution
>>> files. This was chosen among other things to, 1) reduce the number of of
>>> project files by using the new csproj format multi-target framework
>>> capabilities, and 2) leverage the nuget package integration in the new
>>> csproj format. Other providers seem to contain whatever visual studio
>>> files
>>> they need to build. There were two points of discussion that we are
>>> looking
>>> guidance in.
>>>
>>> 1) Is visual studio 2017 too new to expected a wide variety of developers
>>> to
>>> be able to pickup and look at this project? Does anyone have any insight
>>> into this?
>>>
>>> 2) Is there an automated system that depends on building tools that
>>> predate
>>> visual studio 2017 equivalent build tools? Would it easier for CI builds
>>> if
>>> there were project/solution files that can be built with tools the
>>> predate
>>> vs2017? If this is not the right place to ask this, then where should I
>>> ask
>>> this?
>>>
>>> Based on the feedback from the above two points we'd like to come to a
>>> decision on adding project/solution files for previous Visual Studio
>>> versions for initial release of the new AMQP Provider.
>>>
>>> If anyone has any question about this please let me know.
>>>
>>> Chris Morgan
>>>
>>>
> I don't think there's anything inherently wrong with only including VS2017
> solution files if that' the tool you are using right now for development.
> In the end some things would need to be figured out though like how someone
> builds it and package it from the CLI if possible as that is the current
> workflow for the other NMS libraries although they are using Nant which is
> pretty much dead at this point.
>
> One thing to look at is the baseline build environment set by the
> AmqpNetLite project which your client is leveraging underneath. Does it use
> files from an older VS release, it sort of looks like it to me but I've not
> messed with Windows or .NET in a couple years now so I'm a bit out of the
> loop. If someone needs more tools to build the dependent library than they
> need to build the NMS.AMQP library that could be frustrating to some.
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>
Re: [DISCUSS] Rework NMS.AMQP
Posted by Timothy Bish <ta...@gmail.com>.
On 02/15/2018 11:57 AM, Duane Pauls wrote:
> In particular, I think we are wondering whether it would be considered
> feasible to work towards an initial release with the VS2017 project and
> solution files. This would require those who want to build it to either
> use VS2017 to build, or to use the dotnet sdk tool, as is described in the
> 'Building' section of the README.md.
>
> If not considered a gating item for release, we would definitely consider
> it as a future enhancement if this would be perceived to be of value.
>
> Cheers,
> Duane
>
> On Wed, Feb 14, 2018 at 5:28 PM, cmorgan <ch...@solace.com>
> wrote:
>
>> Hi everyone,
>>
>> Tim's post about not having a platform to run Visual Studio 2017 recently
>> sparked a discussion between Duane, Ragnar and I about adding project and
>> solution files for older versions of visual studio to the NMS AMQP Provider
>> and were looking for guidance.
>>
>> Currently, the project only contains visual studio 2017 project and
>> solution
>> files. This was chosen among other things to, 1) reduce the number of of
>> project files by using the new csproj format multi-target framework
>> capabilities, and 2) leverage the nuget package integration in the new
>> csproj format. Other providers seem to contain whatever visual studio files
>> they need to build. There were two points of discussion that we are
>> looking
>> guidance in.
>>
>> 1) Is visual studio 2017 too new to expected a wide variety of developers
>> to
>> be able to pickup and look at this project? Does anyone have any insight
>> into this?
>>
>> 2) Is there an automated system that depends on building tools that predate
>> visual studio 2017 equivalent build tools? Would it easier for CI builds if
>> there were project/solution files that can be built with tools the predate
>> vs2017? If this is not the right place to ask this, then where should I ask
>> this?
>>
>> Based on the feedback from the above two points we'd like to come to a
>> decision on adding project/solution files for previous Visual Studio
>> versions for initial release of the new AMQP Provider.
>>
>> If anyone has any question about this please let me know.
>>
>> Chris Morgan
>>
I don't think there's anything inherently wrong with only including
VS2017 solution files if that' the tool you are using right now for
development. In the end some things would need to be figured out though
like how someone builds it and package it from the CLI if possible as
that is the current workflow for the other NMS libraries although they
are using Nant which is pretty much dead at this point.
One thing to look at is the baseline build environment set by the
AmqpNetLite project which your client is leveraging underneath. Does it
use files from an older VS release, it sort of looks like it to me but
I've not messed with Windows or .NET in a couple years now so I'm a bit
out of the loop. If someone needs more tools to build the dependent
library than they need to build the NMS.AMQP library that could be
frustrating to some.
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
Re: [DISCUSS] Rework NMS.AMQP
Posted by Duane Pauls <du...@gmail.com>.
In particular, I think we are wondering whether it would be considered
feasible to work towards an initial release with the VS2017 project and
solution files. This would require those who want to build it to either
use VS2017 to build, or to use the dotnet sdk tool, as is described in the
'Building' section of the README.md.
If not considered a gating item for release, we would definitely consider
it as a future enhancement if this would be perceived to be of value.
Cheers,
Duane
On Wed, Feb 14, 2018 at 5:28 PM, cmorgan <ch...@solace.com>
wrote:
> Hi everyone,
>
> Tim's post about not having a platform to run Visual Studio 2017 recently
> sparked a discussion between Duane, Ragnar and I about adding project and
> solution files for older versions of visual studio to the NMS AMQP Provider
> and were looking for guidance.
>
> Currently, the project only contains visual studio 2017 project and
> solution
> files. This was chosen among other things to, 1) reduce the number of of
> project files by using the new csproj format multi-target framework
> capabilities, and 2) leverage the nuget package integration in the new
> csproj format. Other providers seem to contain whatever visual studio files
> they need to build. There were two points of discussion that we are
> looking
> guidance in.
>
> 1) Is visual studio 2017 too new to expected a wide variety of developers
> to
> be able to pickup and look at this project? Does anyone have any insight
> into this?
>
> 2) Is there an automated system that depends on building tools that predate
> visual studio 2017 equivalent build tools? Would it easier for CI builds if
> there were project/solution files that can be built with tools the predate
> vs2017? If this is not the right place to ask this, then where should I ask
> this?
>
> Based on the feedback from the above two points we'd like to come to a
> decision on adding project/solution files for previous Visual Studio
> versions for initial release of the new AMQP Provider.
>
> If anyone has any question about this please let me know.
>
> Chris Morgan
>
>
>
>
> -----
> Chris Morgan
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-
> f2368404.html
>
Re: [DISCUSS] Rework NMS.AMQP
Posted by cmorgan <ch...@solace.com>.
Hi everyone,
Tim's post about not having a platform to run Visual Studio 2017 recently
sparked a discussion between Duane, Ragnar and I about adding project and
solution files for older versions of visual studio to the NMS AMQP Provider
and were looking for guidance.
Currently, the project only contains visual studio 2017 project and solution
files. This was chosen among other things to, 1) reduce the number of of
project files by using the new csproj format multi-target framework
capabilities, and 2) leverage the nuget package integration in the new
csproj format. Other providers seem to contain whatever visual studio files
they need to build. There were two points of discussion that we are looking
guidance in.
1) Is visual studio 2017 too new to expected a wide variety of developers to
be able to pickup and look at this project? Does anyone have any insight
into this?
2) Is there an automated system that depends on building tools that predate
visual studio 2017 equivalent build tools? Would it easier for CI builds if
there were project/solution files that can be built with tools the predate
vs2017? If this is not the right place to ask this, then where should I ask
this?
Based on the feedback from the above two points we'd like to come to a
decision on adding project/solution files for previous Visual Studio
versions for initial release of the new AMQP Provider.
If anyone has any question about this please let me know.
Chris Morgan
-----
Chris Morgan
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
Re: [DISCUSS] Rework NMS.AMQP
Posted by Timothy Bish <ta...@gmail.com>.
On 01/17/2018 03:50 PM, cmorgan wrote:
> Hi Everyone,
>
> Happy New Year.
>
> I have a progress update about the NMS AMQP API Rework. The work done in the
> fork, https://github.com/cjwmorgan-sol-sys/nms-amqp, is close to being
> finished. Duane and I have also signed the ICLA. I will follow what Tim
> suggested by creating an NMS JIRA under the AMQNET project (if I'm mistaken
> about the project please let me know). I will also be creating subtasks for
> some task as Tim suggested, eg cleaning out code tree, update building
> system, get automated unit tests running, commit new code base, etc.
> Although some input or guidance for other subtasks to migrate to an apache
> repository would be appreciated.
>
> I will create the JIRA tasks tomorrow unless there is reason not to.
> Let me know if there are any questions or concern.
>
> Chris Morgan
>
>
>
> -----
> Chris Morgan
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
>
Thanks for letting us know that you've been working on this. You can
create issues on the AMQNET Jira if you'd like.
I've looked through the code a bit and it looks like a nice start, sadly
I can't build it as I don't have a platform to run Visual Studio 2017 so
I can't comment on building it or results of testing etc. Some things
that you might want to do is document what features of the NMS API are
or aren't implemented, I see that it currently doesn't support
transactions for instance. Other tasks would be to provide proper
license files and add Apache license headers to all the source and other
relevant files in the project.
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/