On Jan 22, 2013, at 10:58 AM, Robbie Gemmell <[email protected]> wrote:
> Ok, thanks Weston. Though I would tend to prefer changing both, to qpid-jca > for the jar and qpid-jca-ra for the rar, I'm happy enough to keep either > the rar or jar (renaming the source dir to ra) filename the same as it is > now if it is going to be less work for people to pick up afterwards. Having > different names (excluding suffix) for the two will enable having them as > separate modules / groups of artifacts, so at least one of them needs to > change. > Yeah, good point. As per my last email, our internal QE department is ok with whatever scheme we choose so I think your suggestions make the most sense and am all for it. Again, thanks for giving this the amount of thought you have. All looks good. Regards, Weston > Robbie > > > On 22 January 2013 15:39, Weston M. Price <[email protected]> wrote: > >> >> On Jan 22, 2013, at 10:33 AM, Robbie Gemmell <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> 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 < >> [email protected]> >>>>>> 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 <[email protected]> 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: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
