Re: [VOTE] Migrate the NMS Projects from SVN to Git

2017-02-22 Thread Jim Gomes 
+0

It does not work for me. I've detailed my technical issues without
satisfactory solutions. However, I will not stand against the community
zeitgeist. It would be my preference to leave it as is.

On Wed, Feb 22, 2017, 8:52 PM Howard Gao  wrote:

> +1
>
> On Thu, Feb 23, 2017 at 7:25 AM, Timothy Bish  wrote:
>
> >
> > Since the discussion around moving the NMS code to Git has died down now
> > I've decided to just call a vote on the matter.
> >
> > The vote covers moving the following NMS projects SVN trees to their own
> > respective Git repositories and marking the old SVN locations as
> > read-only.  As part of the move to Git we'd request that each repository
> be
> > mirrored on Github so that folks that aren't committers can contribute to
> > the NMS clients via pull requests which would make life simpler for both
> > the contributor and the person merging the contributions.  We'd still
> link
> > the repository up to JIRA using the normal svngit2jira mechanism so all
> > repository work with the JIRA issue specified in it gets logged to the
> > associated JIRA issue.
> >
> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS
> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
> > ache.NMS.ActiveMQ
> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
> > ache.NMS.ActiveMQ.OpenWire.Generator
> >
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.AMQP
> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.EMS
> >
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.MSMQ
> >
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.Stomp
> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.XMS
> > https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ZMQ
> >
> > If the vote passes I can handle to process of requesting all these
> changes
> > and ensure that the migration gets done as we requested.
> >
> > [ ] +1 Migrate the specified NMS projects above to Git repositories.
> > [ ] -1 (provide specific comments)
> >
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> >
>

Re: [VOTE] Migrate the NMS Projects from SVN to Git

2017-02-22 Thread Howard Gao 
+1

On Thu, Feb 23, 2017 at 7:25 AM, Timothy Bish  wrote:

>
> Since the discussion around moving the NMS code to Git has died down now
> I've decided to just call a vote on the matter.
>
> The vote covers moving the following NMS projects SVN trees to their own
> respective Git repositories and marking the old SVN locations as
> read-only.  As part of the move to Git we'd request that each repository be
> mirrored on Github so that folks that aren't committers can contribute to
> the NMS clients via pull requests which would make life simpler for both
> the contributor and the person merging the contributions.  We'd still link
> the repository up to JIRA using the normal svngit2jira mechanism so all
> repository work with the JIRA issue specified in it gets logged to the
> associated JIRA issue.
>
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
> ache.NMS.ActiveMQ
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
> ache.NMS.ActiveMQ.OpenWire.Generator
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.AMQP
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.EMS
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.MSMQ
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.Stomp
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.XMS
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ZMQ
>
> If the vote passes I can handle to process of requesting all these changes
> and ensure that the migration gets done as we requested.
>
> [ ] +1 Migrate the specified NMS projects above to Git repositories.
> [ ] -1 (provide specific comments)
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

[GitHub] activemq-artemis pull request #1038: ARTEMIS-988 Regression: web tmp dir not...

2017-02-22 Thread gaohoward 
GitHub user gaohoward opened a pull request:

https://github.com/apache/activemq-artemis/pull/1038

ARTEMIS-988 Regression: web tmp dir not cleaned up

Due to recent changes, the web component is shutdown by the
server, but the shutdown flag is lost so the web component's
cleanup check method is not get called and the web's tmp
dir is left there after user stopped the broker (control-c).

The fix is add a suitable API to allow passing of the
flag so the web component can make sure its tmp dir gets
cleaned up properly before exiting the VM.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gaohoward/activemq-artemis 
master-tmpdir-regression

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1038.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1038


commit e09be4864aff04db372fb4c72c0d01c2fe91e798
Author: Howard Gao 
Date:   2017-02-23T04:25:02Z

ARTEMIS-988 Regression: web tmp dir not cleaned up

Due to recent changes, the web component is shutdown by the
server, but the shutdown flag is lost so the web component's
cleanup check method is not get called and the web's tmp
dir is left there after user stopped the broker (control-c).

The fix is add a suitable API to allow passing of the
flag so the web component can make sure its tmp dir gets
cleaned up properly before exiting the VM.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [VOTE] Migrate the NMS Projects from SVN to Git

2017-02-22 Thread Hadrian Zbarcea 

+1

Hadrian

On 02/22/2017 06:25 PM, Timothy Bish wrote:


Since the discussion around moving the NMS code to Git has died down now
I've decided to just call a vote on the matter.

The vote covers moving the following NMS projects SVN trees to their own
respective Git repositories and marking the old SVN locations as
read-only.  As part of the move to Git we'd request that each repository
be mirrored on Github so that folks that aren't committers can
contribute to the NMS clients via pull requests which would make life
simpler for both the contributor and the person merging the
contributions.  We'd still link the repository up to JIRA using the
normal svngit2jira mechanism so all repository work with the JIRA issue
specified in it gets logged to the associated JIRA issue.

https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ActiveMQ

https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ActiveMQ.OpenWire.Generator

https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.AMQP
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.EMS
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.MSMQ
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.Stomp
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.XMS
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ZMQ

If the vote passes I can handle to process of requesting all these
changes and ensure that the migration gets done as we requested.

[ ] +1 Migrate the specified NMS projects above to Git repositories.
[ ] -1 (provide specific comments)

Re: [VOTE] Migrate the NMS Projects from SVN to Git

2017-02-22 Thread Clebert Suconic 
+1 (binding)



On Wed, Feb 22, 2017 at 6:25 PM Timothy Bish  wrote:

>
> Since the discussion around moving the NMS code to Git has died down now
> I've decided to just call a vote on the matter.
>
> The vote covers moving the following NMS projects SVN trees to their own
> respective Git repositories and marking the old SVN locations as
> read-only.  As part of the move to Git we'd request that each repository
> be mirrored on Github so that folks that aren't committers can
> contribute to the NMS clients via pull requests which would make life
> simpler for both the contributor and the person merging the
> contributions.  We'd still link the repository up to JIRA using the
> normal svngit2jira mechanism so all repository work with the JIRA issue
> specified in it gets logged to the associated JIRA issue.
>
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS
>
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ActiveMQ
>
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ActiveMQ.OpenWire.Generator
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.AMQP
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.EMS
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.MSMQ
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.Stomp
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.XMS
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ZMQ
>
> If the vote passes I can handle to process of requesting all these
> changes and ensure that the migration gets done as we requested.
>
> [ ] +1 Migrate the specified NMS projects above to Git repositories.
> [ ] -1 (provide specific comments)
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
> --
Clebert Suconic

[VOTE] Migrate the NMS Projects from SVN to Git

2017-02-22 Thread Timothy Bish 


Since the discussion around moving the NMS code to Git has died down now 
I've decided to just call a vote on the matter.


The vote covers moving the following NMS projects SVN trees to their own 
respective Git repositories and marking the old SVN locations as 
read-only.  As part of the move to Git we'd request that each repository 
be mirrored on Github so that folks that aren't committers can 
contribute to the NMS clients via pull requests which would make life 
simpler for both the contributor and the person merging the 
contributions.  We'd still link the repository up to JIRA using the 
normal svngit2jira mechanism so all repository work with the JIRA issue 
specified in it gets logged to the associated JIRA issue.


https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ActiveMQ
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ActiveMQ.OpenWire.Generator
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.AMQP
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.EMS
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.MSMQ
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.Stomp
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.XMS
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ZMQ

If the vote passes I can handle to process of requesting all these 
changes and ensure that the migration gets done as we requested.


[ ] +1 Migrate the specified NMS projects above to Git repositories.
[ ] -1 (provide specific comments)


--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

POST using the REST API - An extra line feed character is appended to the message

2017-02-22 Thread mbrimble 
In our hands when the Apache REST API to POST's a message to a AMQ an extra
line feed character is appended to the message. See
https://connectedpawns.wordpress.com/2017/02/23/integrating-apache-active-message-queueamq-with-biztalk-server-publishing-messages-part-2-extra-linefeed/
for a more detailed  description of what we observe.Does anyone know whether
this is normal behaviour or is there a way to suppress this happening?



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/POST-using-the-REST-API-An-extra-line-feed-character-is-appended-to-the-message-tp4722339.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: What is the current status and plans for the web-console?

2017-02-22 Thread Clebert Suconic 
I liked Martyn's proposal for being a cool thing :)


Just looked at this thing he mentioned (bootstrap).. man.. it's really cool...
http://getbootstrap.com/getting-started/


I'm not writing software just to be cool... but a great console would
definitely improve things...


One thing with a great UI though... our website still sucks :)


> - It provides a framework for plugins. So you can have one console that
> gives you access to ActiveMQ but also to other modules in your system
> - It uses jolokia to access the existing JMX layer over REST. So we do not
> need to create an additional REST layer for the console on the AMQ and
> Artemis side
> - Uses a html/javascript client (Angular). So the client side is easy to
> install on any server
>
> So if we do not write a Hawtio plugin then we should still consider to use
> jolokia to avoid overhead on the server side.
> I also think a framework to hook other plugins in would be great but for
> just the activemq and artemis consoles it is not absolutely necessary.

+1... although I strongly encourage to keep the bits isolated. Not
only for easy switch between AMQ5 and Artemis, but eventually we could
include other technologies available on the console. (examples: AMQP
Management, JMX, some consoles standard that I don't remember now, or
any other thing yet to be invented)..   All I'm asking is for standard
OO encapsulation.

>
> So ideally I would like to have something like Hatwio at apache as a generic
> base for a console where all apache projects can hook in via plugins.
> Unfortunately this is a lot of effort and I am not sure if we find enough
> manpower to do it.  It would also be a project on its own and should not be
> done at activemq.



. if I had the time. :/

Re: What is the current status and plans for the web-console?

2017-02-22 Thread Christian Schneider 
The reason why I thought about a hawtio plugin is that it would be mimal 
effort compared to other solutions.


Some things that I like in Hawtio:

- It provides a framework for plugins. So you can have one console that 
gives you access to ActiveMQ but also to other modules in your system
- It uses jolokia to access the existing JMX layer over REST. So we do 
not need to create an additional REST layer for the console on the AMQ 
and Artemis side
- Uses a html/javascript client (Angular). So the client side is easy to 
install on any server


So if we do not write a Hawtio plugin then we should still consider to 
use jolokia to avoid overhead on the server side.
I also think a framework to hook other plugins in would be great but for 
just the activemq and artemis consoles it is not absolutely necessary.


So ideally I would like to have something like Hatwio at apache as a 
generic base for a console where all apache projects can hook in via 
plugins. Unfortunately this is a lot of effort and I am not sure if we 
find enough manpower to do it.  It would also be a project on its own 
and should not be done at activemq.


Christian


On 22.02.2017 18:05, Martyn Taylor wrote:


So my opinion on this...

I feel quite passionately about creating a really great UX for both
ActiveMQ and Artemis and I'm not sure that a HawtIO plugin is what I'd
hoped for when we started talking about an ActiveMQ console.  I think we
could build something that is more focused and much more UX driven than the
ActiveMQ HawtIO plugins that have been created outside Apache.

I'd much prefer to see a console built specifically for the messaging
space.  With something focused solely on messaging, we can think about the
best way to model/manage messaging concepts and how to expose these things
to the end users.  My view is that we either consider some of the other
frameworks like the ones mentioned in this thread, or (my first preference)
would be to go down the route of building our own, something specific to
messaging, based on technologies like HTML5/JS + Bootstrap with the
back-end being made plugable so we could manage both ActiveMQ 5.x and
Artemis brokers.

if redhat does not donate these? -- which would of course be the best

option.


I'd prefer not to go down this route, but, if the community decide this is
the way forward, then I don't think this would be a problem.


I personally would be fine with the hawtio core not being at apache if the
specific plugins are here. So we have most of the control without trying to
replicate hawtio.
In a chat with Dan he added that hawtio must be skinnable enough to have
an apache look. I agree with that.

Christian


On 17.02.2017 15:39, Clebert Suconic wrote:


*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)


Of course!



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com





--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [DISCUSS] Move Apache.NMS project to Git

2017-02-22 Thread Timothy Bish 

On 02/22/2017 11:47 AM, Clebert Suconic wrote:

I think it would be simpler to have the releases aligned as it creates
a DLL Version Hell (that's an actual term on Windows/ActiveX) when you
update versions dependencies.


I can clearly see this made up scenario in a real life / customer scenario:

"Hypothetical: "NMS.ActiveMQ is dependent on NMS 1.1 as it has a bug
fix  on the NMS, while NMS.Stomp 1.3 still depending on NMS 1.0 as it
didn't need a certain bug fix... etc.. etc..."


Aligning these versions would be easier for users IMHO. But that's a
separate discussion.


It doesn't really work that way in the NMS client library releases and 
it isn't necessary given the way the release artifacts are built and 
versioned.






On Wed, Feb 22, 2017 at 11:37 AM, Christopher Shannon
 wrote:

Thanks for the clarification Tim, I missed your message from yesterday.  So
yeah in that case if we do the migration then it makes sense to me to just
create a separate git repo for each one.

On Wed, Feb 22, 2017 at 11:23 AM, Timothy Bish  wrote:


On 02/22/2017 10:47 AM, Christopher Shannon wrote:


Also, if each NMS sub project has a different version than maybe it would
actually be better to have a separate repo for each one.  That might be a
pain to manage though but would make the releases independent.


They already are in separate repos now.

https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS/
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
ache.NMS.ActiveMQ/
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
ache.NMS.Stomp/

etc.


On Wed, Feb 22, 2017 at 10:16 AM, Daniel Kulp  wrote:

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




--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/








--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: What is the current status and plans for the web-console?

2017-02-22 Thread Martyn Taylor 
On Fri, Feb 17, 2017 at 5:23 PM, Christian Schneider <
ch...@die-schneider.net> wrote:

> How about creating a hawtio plugin for activemq and artemis at apache


So my opinion on this...

I feel quite passionately about creating a really great UX for both
ActiveMQ and Artemis and I'm not sure that a HawtIO plugin is what I'd
hoped for when we started talking about an ActiveMQ console.  I think we
could build something that is more focused and much more UX driven than the
ActiveMQ HawtIO plugins that have been created outside Apache.

I'd much prefer to see a console built specifically for the messaging
space.  With something focused solely on messaging, we can think about the
best way to model/manage messaging concepts and how to expose these things
to the end users.  My view is that we either consider some of the other
frameworks like the ones mentioned in this thread, or (my first preference)
would be to go down the route of building our own, something specific to
messaging, based on technologies like HTML5/JS + Bootstrap with the
back-end being made plugable so we could manage both ActiveMQ 5.x and
Artemis brokers.

if redhat does not donate these? -- which would of course be the best
> option.
>
I'd prefer not to go down this route, but, if the community decide this is
the way forward, then I don't think this would be a problem.

>
> I personally would be fine with the hawtio core not being at apache if the
> specific plugins are here. So we have most of the control without trying to
> replicate hawtio.
> In a chat with Dan he added that hawtio must be skinnable enough to have
> an apache look. I agree with that.
>
> Christian
>
>
> On 17.02.2017 15:39, Clebert Suconic wrote:
>
>> *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)
>>>
>> Of course!
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Re: [DISCUSS] Move Apache.NMS project to Git

2017-02-22 Thread Clebert Suconic 
I think it would be simpler to have the releases aligned as it creates
a DLL Version Hell (that's an actual term on Windows/ActiveX) when you
update versions dependencies.


I can clearly see this made up scenario in a real life / customer scenario:

"Hypothetical: "NMS.ActiveMQ is dependent on NMS 1.1 as it has a bug
fix  on the NMS, while NMS.Stomp 1.3 still depending on NMS 1.0 as it
didn't need a certain bug fix... etc.. etc..."


Aligning these versions would be easier for users IMHO. But that's a
separate discussion.




On Wed, Feb 22, 2017 at 11:37 AM, Christopher Shannon
 wrote:
> Thanks for the clarification Tim, I missed your message from yesterday.  So
> yeah in that case if we do the migration then it makes sense to me to just
> create a separate git repo for each one.
>
> On Wed, Feb 22, 2017 at 11:23 AM, Timothy Bish  wrote:
>
>> On 02/22/2017 10:47 AM, Christopher Shannon wrote:
>>
>>> Also, if each NMS sub project has a different version than maybe it would
>>> actually be better to have a separate repo for each one.  That might be a
>>> pain to manage though but would make the releases independent.
>>>
>>
>> They already are in separate repos now.
>>
>> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS/
>> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
>> ache.NMS.ActiveMQ/
>> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
>> ache.NMS.Stomp/
>>
>> etc.
>>
>>
>> On Wed, Feb 22, 2017 at 10:16 AM, Daniel Kulp  wrote:
>>>
>>> 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



>>
>> --
>> Tim Bish
>> twitter: @tabish121
>> blog: http://timbish.blogspot.com/
>>
>>



-- 
Clebert Suconic

Re: [DISCUSS] Move Apache.NMS project to Git

2017-02-22 Thread Christopher Shannon 
Thanks for the clarification Tim, I missed your message from yesterday.  So
yeah in that case if we do the migration then it makes sense to me to just
create a separate git repo for each one.

On Wed, Feb 22, 2017 at 11:23 AM, Timothy Bish  wrote:

> On 02/22/2017 10:47 AM, Christopher Shannon wrote:
>
>> Also, if each NMS sub project has a different version than maybe it would
>> actually be better to have a separate repo for each one.  That might be a
>> pain to manage though but would make the releases independent.
>>
>
> They already are in separate repos now.
>
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS/
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
> ache.NMS.ActiveMQ/
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
> ache.NMS.Stomp/
>
> etc.
>
>
> On Wed, Feb 22, 2017 at 10:16 AM, Daniel Kulp  wrote:
>>
>> 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
>>>
>>>
>>>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

[GitHub] activemq-artemis pull request #1037: ARTEMIS-970 handle indeterminate JMS de...

2017-02-22 Thread jbertram 
GitHub user jbertram opened a pull request:

https://github.com/apache/activemq-artemis/pull/1037

ARTEMIS-970 handle indeterminate JMS destination



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-970

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1037.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1037


commit 6fdcec264a31c5a9660ea025c5c73ecc33fa69a6
Author: Justin Bertram 
Date:   2017-02-22T14:53:09Z

ARTEMIS-970 handle indeterminate JMS destination




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #1036: ARTEMIS-981 OpenWire can't receive empt...

2017-02-22 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1036


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Move Apache.NMS project to Git

2017-02-22 Thread Timothy Bish 

On 02/22/2017 10:47 AM, Christopher Shannon wrote:

Also, if each NMS sub project has a different version than maybe it would
actually be better to have a separate repo for each one.  That might be a
pain to manage though but would make the releases independent.


They already are in separate repos now.

https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS/
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ActiveMQ/
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.Stomp/

etc.


On Wed, Feb 22, 2017 at 10:16 AM, Daniel Kulp  wrote:


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





--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [DISCUSS] Move Apache.NMS project to Git

2017-02-22 Thread Christopher Shannon 
Also, if each NMS sub project has a different version than maybe it would
actually be better to have a separate repo for each one.  That might be a
pain to manage though but would make the releases independent.

On Wed, Feb 22, 2017 at 10:16 AM, Daniel Kulp  wrote:

>
> > 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: [DISCUSS] Move Apache.NMS project to Git

2017-02-22 Thread Daniel Kulp 

> 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: [DISCUSS] Move Apache.NMS project to Git

2017-02-22 Thread Christopher Shannon 
Jim,

I think you can accomplish both goals you are looking to achieve.

First, correct me if I am wrong but if I understand correctly, are you
saying you just want to be able to check out parts of a repo multiple times
(to have multiple branches checked out at the same time)? If so, Git lets
you do a sparse checkout so you should be able to clone the repo multiple
times but only check out certain subprojects if you want.
https://git-scm.com/docs/git-read-tree .  So if you wanted to just check
out 3 different versions you could clone the repository 3 separate times
but do a sparse checkout to only grab certain subdirectories to save space.

Second, as far as generating unique builds I think you could accomplish
this by using "lightweight tags".  A lightweight tag in git simply is a
pointer to a specifc commit and would conceptually be very similar to
assigning it a unique number based on an SVN commit.  There's almost no
overhead to creating a lightweight tag in git, it just stores the commit
checksum.  https://git-scm.com/book/en/v2/Git-Basics-Tagging  Creating a
lightweight tag for every build could be automated and would allow you to
go back to a unique build for every commit.

Chris

On Tue, Feb 21, 2017 at 9:27 PM, Clebert Suconic 
wrote:

> > So, that's a "Yes, it does duplicate the entire repository (which can be
> > quite sizeable) in order to have multiple branches checked out
> > simultaneously."  Got it. Clearly a disadvantage.
>
> I give up!!!
> We should probably migrate Artemis and AMQ5 to SVN as well.
> Pretty horrible disadvantage to have all the versions available
> without being connected.
>
> You can certainly do tricks to checkout on another directory, but it's
> just easy to copy the directory.
>
> > So, for example, I would be able to have the following structure on my
> > local hard disk?
> >
> > Apache.NMS/
> > /trunk
> > /tags
> > /1.7.0
> > /1.7.1
> > Apache.NMS.ActiveMQ/
> > /trunk
> > /tags
> > /1.7.0
> > /1.7.1
> > /1.7.2
> >
> That's messed up... horrible dependencies between versions. Even as is now.
>
> I wouldn't even bring that build style into the new project. If that's
> the case I would say keep the current SVN the way it is, and start a
> new one on git.
>