Summary: 1. I think the use of the openoffice "class path" and packaging that is already accepted for use be continued, rather than disturb the Java and maven identifiers that people are already using and expect.
2. Creating a distribution is complicated by the absence of a new Apache OpenOffice release that would include the code and other materials that go with this. This would tend to require a special release for just this. So, for (2), there is more to consider. Notes below. - Dennis > -----Original Message----- > From: Dennis E. Hamilton [mailto:orc...@apache.org] > Sent: Saturday, January 30, 2016 13:39 > To: dev@openoffice.apache.org > Subject: RE: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to Maven > Repository > > > -----Original Message----- > > From: Carl Marcum [mailto:cmar...@apache.org] > > Sent: Saturday, January 30, 2016 12:09 > > To: dev@openoffice.apache.org > > Subject: Re: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to > Maven > > Repository > > > > Hi Dennis, > > > > comments below.. > > > > On 01/30/2016 12:17 PM, Dennis E. Hamilton wrote: > [ ... ] > > > I am copying the PMC on this and requesting that all discussion be > > here, and not there, so all committers and interested parties can > > contribute to the discussion. We would also need to know that at > least > > 3 PMC members are prepared to carry out what is required for casting a > > binding release vote. > > > > > > While we wrestle with this, I request that you suspend the Groovy > UNO > > Extension discussion for now and we continue this for the simple case > of > > the Java Bootstrap Connector. I am assuming that this is the simpler > > case to work through a release process if we determine that we need to > > do so. > > > > > > - Dennis > > > > [cmarcum] > > > > No problem. > > I suspended the Groovy UNO extension proposal. > > > > My hope was to do this through the project but I understand the > > procedures and how this could cause more work for others than > necessary > > since it's only a small developer tool and not a primary project > > artifact. > > > > I am more than willing to submit this individually if it makes more > > sense. > > > > In a larger sense this conversation could also apply to the future > > builds of the AOO-Netbeans plugin that is made available through > > NetBeans.org. > > > > Best regards, > > Carl > [orcmid] > > Thanks Carl. Let's wait a few days for others to chime in. > > I would like to see this as a project release rather than a personal one > based on AOO code, especially since I think everything needed is in the > AOO code base. > > The bigger issue is the kind of review that is required, and the extra > effort in preparing a release candidate, etc. > > I also think that you are creating a good model and process for spin- > outs of useful components from the AOO code base. So this is worth > digging into for that reason alone. > > - Dennis [orcmid] Carl, First, we do make distributions that are based on an AOO source release and that use the source in selective ways. The making of language packs is an example of one special distribution. The one you made for Java uno tools is another. Secondly, there are downstream distributions that are also made. In notable cases, we are aware of them because they contribute patches to our source base and then make their distribution from our source release. I think FreeBSD is such a case, and the Solaris and OS2 distributions are as well. I suspect that there may still be downstream build variants in France. I don't know how or whether those use non-released source and how they tie to AOO release versions, or not. So we are left with the situation of there being no simple mechanism, such as regular maintenance releases that have your additions incorporated so the Maven distributions can be tied to the released AOO version. Here's the conundrum: 1. You could put together a release, using a tagged/branched piece of the AOO SVN sufficient to what you want to do. So there's a persistent source-tree location and r-number that nails it down. 2. Then you could take that much through the release process, being the release manager yourself. It might be awkward the first time, making it beneficial that this is a pretty simple addition. After that effort, and presumably without more than 2 release candidates, the issue will be having a binding +1 majority of at least three to accomplish the release. 3. Being able to obtain a release vote that includes binding voters successfully building from the released source is a little worrisome. My suggestion is to go through (2) regardless, but I am not doing the work [;<). If all technical objections are satisfied, and it is simply a lack of votes, my personal recommendation would be to do a downstream release relying on the release bundle, but having it be dependent on AOO code, as identified, but not being an AOO release. The problem is then how that is that to be identified so there is no confusion with an AOO release. That's a lot of armchair quarter-backing. What are your further thoughts on this, Carl? Bueller? - Dennis > > > > > > >> -----Original Message----- > > >> From: Carl Marcum [mailto:cmar...@apache.org] > > >> Sent: Saturday, January 30, 2016 06:42 > > >> To: dev@openoffice.apache.org > > >> Subject: [PROPOSAL][DEVTOOLS] Stage Java BootstrapConnector to > Maven > > >> Repository > > >> > > >> Hi All, > > >> > > >> I would like to create Maven bundles of the source, classes, and > > javadoc > > >> of the recently added BootstrapConnector [1] and stage them on the > > >> Apache Nexus Maven Repository using groupId "org.openoffice" so > this > > >> would be from the project. > > >> > > >> If the project consensus is that a VOTE is necessary I will call > for > > one > > >> after staging and prior to publishing, or if not, I will do another > > >> PROPOSAL for release. > > >> > > >> This jar allows bootstrapping the office by passing a string > > >> representing the path to the office executable to the bootstrap > > method. > > >> > > >> This code has been available for download from the Forum since 2008 > > [2]. > > >> > > >> I have obtained permission from the author to use the code by our > > >> project and under the AL 2.0 license and documented it with the AOO > > PMC. > > >> > > >> If there are no objections to the above proposal by midnight GMT > > >> Wednesday February 3rd, then I will invoke Lazy Consensus and > > proceed > > >> to implement the above proposal. > > >> > > >> Another option to this is that I publish them as an individual with > a > > >> different groupId if this is preferred. > > >> > > >> [1] > > >> https://svn.apache.org/repos/asf/openoffice/devtools/bootstrap- > > >> connector/trunk/ > > >> > > >> [2] https://forum.openoffice.org/en/forum/viewtopic.php?t=2520 > > >> > > >> Thanks, > > >> Carl > > >> > > >> > > >> ------------------------------------------------------------------- > -- > > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > -------------------------------------------------------------------- > - > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
