On Jan 22, 2013, at 10:33 AM, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:

> So, I'd like to actually do some work on this over the weekend to ensure we
> can publish it in future, which warrants having the previously mentioned
> discussion :)
Yep.
> 
> I propose to publish the jar and its sources as one set of maven artifacts,
> with the rar published separately as another.
> 
Makes perfect sense as the RAR is nothing more than it's constituent 
jars/descriptors just packaged for JEE compliance.

> For the jar, I would retain the jca module structure as it exists now, but
> changing its jar artifact to actually be called 'jca' instead of hacked to
> become 'ra as it is now', giving qpid-jca-0.XX.jar as the jar output. This
> would allow removing all hackery involved with renaming the jar file in the
> tree and simplify generation of the maven artifacts for it.
> 
Agree in principle. We have internal build processes/testing that may have to 
change as a result so to be a good citizen
I would like to have the discussion with my colleagues but I don't see it as 
being an issue. 

> For the rar, I would add continue to have the standard jca module build
> produce the rar, adding an additional step to output maven artifacts for
> the rar while generating the maven output for the jar. I would propose
> either keeping the existing name of qpid-ra-0.XX.rar for compatibility or
> change it to something like qpid-jca-ra-0.XX.rar to better denote its
> linkaage with the jca module.
> 
Much like the point above, I agree I just need to run it by those involved in 
our internal process. Note, if we do change names the documentation will have 
to change as a result, but that is not that big of a deal either. 


> Thoughts?
> 
Thanks for taking the time to think about this. 

Regards,

Weston
> Robbie
> 
> 
> On 16 January 2013 12:32, Weston M. Price <wpr...@redhat.com> wrote:
> 
>> Hi Robbie,
>>        All great questions.  Wholeheartedly agree on
>> 
>>> Going back to where I started, I think the questions and build process
>>> change required to start doing this on a long term basis warrant a bit of
>>> discussion and thought, to the extent that I would hold fire on pushing
>> the
>>> artifact in this release.
>> 
>> Let's table for this release and discuss further for a long term solution.
>> 
>> Thanks for your response, again, great points/questions all around.
>> 
>> Regards,
>> 
>> -W
>> On Jan 16, 2013, at 6:27 AM, Robbie Gemmell <robbie.gemm...@gmail.com>
>> wrote:
>> 
>>> Hi Weston,
>>> 
>>> I had a think about / quick look at doing this, and cant help but think
>> it
>>> has now missed the boat.
>>> 
>>> In terms of putting up the artifact we have in the 'java release' tar, it
>>> shouldn't be too hard to do on an ad-hoc basis, however doing it properly
>>> on an ongoing basis it isnt so simple and raised several questions and
>>> things to consider that would stop me from jumping on publishing it
>> ad-hoc
>>> for 0.20.
>>> 
>>> Producing the output as part of the normal build would be a good bit more
>>> involved and rather contrived compared to what is there now for the
>> clients
>>> and broker modules, both due to the namaing split (jca vs ra) present in
>>> the jca module, and the fact its the first and only module producing
>>> multiple artifacts (inluding non-jar artifacts, i.e the rar, which
>> require
>>> a very slightly different pom) that happens to have the same name but
>>> different extension as other artifacts in the module (the jar), and also
>>> has artifacts that dont have sources jars to go with it (the rar).
>>> 
>>> Some of the questions I had when thinking about it were:
>>> - Do we publish the jar as well?
>>> It seems at least some other projects do, possibly as the sources are
>> only
>>> for the jar and not the rar.
>>> 
>>> - Should the rar and the jar really have the same name (excluding the
>>> extension) if we do?
>>> It seems at least some projects artifacts dont (e.g the rar is built by a
>>> maven module for the rar that depends on a module for the jar).
>>> 
>>> - What would we call it?
>>> qpid-ra isnt necessarily my first pick for a maven artifact name, but
>> thats
>>> what it would currently be.
>>> 
>>> That last question and the earlier mentioned complications in actually
>>> generating maven artifacts for the jca module lead me on to a related
>> topic
>>> I have been meaning to bring up for some time. The naming split within
>> the
>>> jca module is quite annoying, and over complicates things in general but
>>> far more so in situations such as this. I think it is time we either
>>> renamed the module to ra (if we think the historic file name is the most
>>> important thing), or change the output filenames (if we think the source
>>> tree module name is the most important thing). If we were to change the
>>> filenames in any way (including giving the rar and jar different names)
>>> then that would be another reason I would hold off publishing it with the
>>> current naming.
>>> 
>>> Going back to where I started, I think the questions and build process
>>> change required to start doing this on a long term basis warrant a bit of
>>> discussion and thought, to the extent that I would hold fire on pushing
>> the
>>> artifact in this release.
>>> 
>>> Robbie
>>> 
>>> 
>>> On 15 January 2013 17:09, Weston M. Price <wpr...@redhat.com> wrote:
>>> 
>>>> Hi Robbie,
>>>>       There is a JIRA
>>>> 
>>>> https://issues.apache.org/jira/browse/QPID-4445
>>>> 
>>>> Basically requesting that the JCA binaries also be uploaded to the Maven
>>>> repository. I am more than willing to look at this, but if you have
>>>> familiarity with the process it might go much faster.
>>>> 
>>>> Regards,
>>>> 
>>>> Weston
>>>> On Jan 15, 2013, at 12:05 PM, Robbie Gemmell <robbie.gemm...@gmail.com>
>>>> wrote:
>>>> 
>>>>> The maven binaries for the Java clients and broker are staged at:
>>>>> https://repository.apache.org/content/repositories/orgapacheqpid-133
>>>>> 
>>>>> Robbie
>>>>> 
>>>>> On 10 January 2013 12:48, Justin Ross <jr...@apache.org> wrote:
>>>>> 
>>>>>> Hi, everyone.  The proposed final 0.20 release candidate, RC4, is
>>>>>> available here:
>>>>>> 
>>>>>> http://people.apache.org/~jross/qpid-0.20-rc4/
>>>>>> 
>>>>>> My testing showed everything in good shape, including the proton
>>>>>> integration.
>>>>>> 
>>>>>> RC4 has the following changes versus RC3:
>>>>>> 
>>>>>> r1430909 | kwall | (Wed, 09 Jan 2013) | 5 lines
>>>>>> QPID-4503: Producer transaction timeout detection feature may produce
>>>>>> suprious open/idle alerts and close client connections/sessions
>>>>>> without good cause
>>>>>> 
>>>>>> r1430904 | kwall | (Wed, 09 Jan 2013) | 5 lines
>>>>>> QPID-4503: Producer transaction timeout detection feature may produce
>>>>>> suprious open/idle alerts and close client connections/sessions
>>>>>> without good cause
>>>>>> 
>>>>>> r1430554 | astitcher | (Tue, 08 Jan 2013) | 5 lines
>>>>>> QPID-4095: Move the directory iteration into FileSysDir
>>>>>> 
>>>>>> r1430452 | jross | (Tue, 08 Jan 2013) | 1 line
>>>>>> QPID-4368: Add missing dist file
>>>>>> 
>>>>>> r1430321 | robbie | (Tue, 08 Jan 2013) | 4 lines
>>>>>> QPID-4521: ensure that the routing key is properly passed to the
>>>>>> alternate Topic exchange by the adapter. Add unit tests for the
>>>>>> adapter methods.
>>>>>> 
>>>>>> r1430320 | robbie | (Tue, 08 Jan 2013) | 4 lines
>>>>>> QPID-4519: return true for VirtualHost MBean isStatusEnabled, dont
>>>>>> update stats when doing so, and stop using a synchronized method as a
>>>>>> result
>>>>>> 
>>>>>> r1430319 | robbie | (Tue, 08 Jan 2013) | 4 lines
>>>>>> QPID-4512: stop the delete visitor indicating completion upon the
>>>>>> first matching queue entry, or any for that matter: it needs to check
>>>>>> them all.
>>>>>> 
>>>>>> r1424598 | kgiusti | (Thu, 20 Dec 2012) | 1 line
>>>>>> NO-JIRA: merge compile fix from trunk
>>>>>> 
>>>>>> r1423964 | robbie | (Wed, 19 Dec 2012) | 6 lines
>>>>>> QPID-4511: move the broker-plugins lib dir under build/scratch to
>>>>>> prevent it being included in the binary produced by 'ant release'.
>>>>>> 
>>>>>> The artifacts are signed, and if approved by vote, these bits
>>>>>> precisely would ship as 0.20 GA.  I'll follow this with a separate
>>>>>> [VOTE] mail.
>>>>>> 
>>>>>> Thanks Alex, Keith, Robbie, and Ken for posting your test outcomes on
>>>>>> the list.  It is very much appreciated.  Please try RC4 and prepare to
>>>>>> vote!
>>>>>> 
>>>>>> Thanks,
>>>>>> Justin
>>>>>> 
>>>>>> ---
>>>>>> 0.20 release page: https://cwiki.apache.org/qpid/020-release.html
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>>>>>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>>>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>>> 
>>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: dev-h...@qpid.apache.org
>> 
>> 


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

Reply via email to