On 02/04/2016 03:48 PM, Dennis E. Hamilton wrote:
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
Hi Dennis,
I understand how the recently released Java UNO jar to Maven needed to
coincide with a AOO release due to the source being in AOO source.
For devtools like this bootstrap connector and the netbeans-integration
plugin, their source is under the devtools dir which is beside AOO trunk
and therefore not branched and tagged with AOO I don't believe.
For the netbeans plugin submitted to NetBeans.org, past releases by my
were discussed on dev@ and then by lazy-concensus proposal. with it's
own trunk, branches, and tags directory structure.
Could this not be similar?
Thanks,
Carl
-----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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
