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 :)
I propose to publish the jar and its sources as one set of maven artifacts, with the rar published separately as another. 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. 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. Thoughts? 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] > >
