Re: [RESULT] [VOTE] Release Felix shell.remote version 1.2.0
This vote passed with three binding +1 and no -1 votes. On Mon, Dec 19, 2016 at 10:29 AM, Carsten Ziegeler wrote: > +1 > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > >
Thanks, more or less goodbye, and what about this dangling release?
Dear Felix community, I have started a new job where I will not be using any OSGi technology for the foreseeable future. I am very aware that I used sharp elbows to get commit privilege here, and that I've received more help than I've been able to pay back in development. I am very grateful for all of your tolerance. Meanwhile, there's this release I started ?2? weeks ago for the remote shell component. Do two more of you PMC members want to give it a plus 1, or do you want me to remove the tag and back out the version in the pom? Regards, benson margulies
[jira] [Commented] (FELIX-5415) HTTP leaves extra service registrations when configured with config admin
[ https://issues.apache.org/jira/browse/FELIX-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15741954#comment-15741954 ] Benson Margulies commented on FELIX-5415: - No, you wind up with two services either way. The service derived from the config-admin port will 'win' and be listening in Jetty. I have left the job where I hit this, so I can't go try it out and report back any longer. > HTTP leaves extra service registrations when configured with config admin > - > > Key: FELIX-5415 > URL: https://issues.apache.org/jira/browse/FELIX-5415 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http.jetty-3.4.0 >Reporter: Benson Margulies > > If you set org.osgi.service.http.port to a port with configuration admin, you > will end up with multiple registrations of the service. One is created for > the port number that is visible from framework properties, the second from > the configuration admin information. If those ports are different, only the > second will be actually listening in jetty. The evidence is visible from the > gogo inspect command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Marking releases released
A look at https://issues.apache.org/jira/plugins/servlet/project-config/FELIX/versions suggests that some folks have forgotten to mark some recent releases as released, such as the 1.0.0 of gogo, unless the UI is fooling me.
One release down, one to go...
The remote shell release still needs two votes.
Copying httplite 0.1.5 to dist
I would be grateful if a PMC member would do this, since I can't edit the download page until its over there to download.
Re: [RESULT] [VOTE] Release Felix httplite version 0.1.5
+1 binding: JB Onofré, David Bosschaert, Guillaume Nodet, Clement Escoffier +1 not binding: Ken Gilmer. The vote passes. Promote it, I will, and a PMC member will need to add it to the dist area. Thanks. On Wed, Nov 30, 2016 at 5:11 AM, Clement Escoffier wrote: > +1, > > Regards, > > Clement > >> On 30 Nov 2016, at 11:02, Jean-Baptiste Onofré wrote: >> >> +1 (binding) >> >> Regards >> JB >> >> On 11/30/2016 09:58 AM, Guillaume Nodet wrote: >>> +1 >>> >>> 2016-11-25 21:59 GMT+01:00 Benson Margulies : >>> >>>> Hi, >>>> >>>> We solved 3 issues in this release: >>>> >>>> ** Bug >>>>* [FELIX-5422] - httplite should accept more date formats. >>>>* [FELIX-5423] - httplite does not urldecode parameter values >>>>* [FELIX-5427] - httplite javadoc fails java8 javadoc lint >>>> >>>> There are still some outstanding issues: >>>> >>>> https://issues.apache.org/jira/browse/FELIX-4992?jql= >>>> project%20%3D%20FELIX%20AND%20resolution%20%3D%20Unresolved%20AND% >>>> 20component%20%3D%20%22Lightweight%20HTTP%20Service%22%20ORDER%20BY% >>>> 20priority%20DESC >>>> >>>> Staging repository: >>>> https://repository.apache.org/content/repositories/orgapachefelix-1153 >>>> >>>> You can use this UNIX script to download the release and verify the >>>> signatures: >>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh >>>> >>>> Usage: >>>> sh check_staged_release.sh [YOUR REPOSITORY ID] /tmp/felix-staging >>>> >>>> Please vote to approve this release: >>>> >>>> [ ] +1 Approve the release >>>> [ ] -1 Veto the release (please provide specific comments) >>>> >>>> This vote will be open for 72 hours. >>>> >>> >>> >>> >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org <mailto:jbono...@apache.org> >> http://blog.nanthrax.net <http://blog.nanthrax.net/> >> Talend - http://www.talend.com <http://www.talend.com/>
Release votes?
Any chance of a few more voters? I'm in the middle of a job change; it would be nice to finish this off during my week in between.
Re: [VOTE] Release Felix httplite version 0.1.5
Hmm. I am inclined to write a JIRA to clean that up later; for the typical trivial use case of the 'lite' package, I don't think it's a big risk. We'll see if we get any votes. On Sun, Nov 27, 2016 at 10:50 PM, Chetan Mehrotra wrote: > Hi Benson, > > On Sat, Nov 26, 2016 at 2:29 AM, Benson Margulies > wrote: >> * [FELIX-5422] - httplite should accept more date formats. > > I think the commit done [0] for this issue has some issue. See the > mail sent on that at [1]. > > Chetan Mehrotra > [0] > https://github.com/apache/felix/commit/3812f7eaa6168ebedb520c871d94ccab9958b68c > [1] > https://lists.apache.org/thread.html/d1ffe9ccb0d577c697974c8781fa2204ae99e02011fe619f335efa8c@%3Cdev.felix.apache.org%3E
[jira] [Resolved] (FELIX-5353) ConfigurationAdmin does not log or diagnose invalid contents of files
[
https://issues.apache.org/jira/browse/FELIX-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies resolved FELIX-5353.
-
Resolution: Invalid
> ConfigurationAdmin does not log or diagnose invalid contents of files
> -
>
> Key: FELIX-5353
> URL: https://issues.apache.org/jira/browse/FELIX-5353
> Project: Felix
> Issue Type: Wish
> Components: Configuration Admin
> Reporter: Benson Margulies
>
> If you have a .cfg file with a line like:
> {noformat}
> prop=${something}/something
> {noformat}
> The contents of the file disappear, without an exception, a log message, or a
> trace. It should at least, I think be logged.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-5413) incorrect log messages about port in felix http
[ https://issues.apache.org/jira/browse/FELIX-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved FELIX-5413. - Resolution: Invalid > incorrect log messages about port in felix http > --- > > Key: FELIX-5413 > URL: https://issues.apache.org/jira/browse/FELIX-5413 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http.base-3.0.18 >Reporter: Benson Margulies > > Log message: > [INFO ] 2016-11-15 09:37:45.176 [FelixStartLevel] > org.apache.felix.http.jetty.3.4.0 - [Unknown]Started Jetty 9.3.12.v20160915 > at port(s) HTTP:8080 on context path / > [minThreads=8,maxThreads=200,acceptors=1,selectors=4] > In config admin, I have: > org.osgi.service.http.port=[8182,) > and, indeed, there is nothing listening on 8080 but something listening on > 8082. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[VOTE] Release Felix httplite version 0.1.5
Hi, We solved 3 issues in this release: ** Bug * [FELIX-5422] - httplite should accept more date formats. * [FELIX-5423] - httplite does not urldecode parameter values * [FELIX-5427] - httplite javadoc fails java8 javadoc lint There are still some outstanding issues: https://issues.apache.org/jira/browse/FELIX-4992?jql=project%20%3D%20FELIX%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20%22Lightweight%20HTTP%20Service%22%20ORDER%20BY%20priority%20DESC Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1153 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh [YOUR REPOSITORY ID] /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours.
[jira] [Resolved] (FELIX-5427) httplite javadoc fails java8 javadoc lint
[ https://issues.apache.org/jira/browse/FELIX-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved FELIX-5427. - Resolution: Fixed 1771382. > httplite javadoc fails java8 javadoc lint > - > > Key: FELIX-5427 > URL: https://issues.apache.org/jira/browse/FELIX-5427 > Project: Felix > Issue Type: Bug > Components: Lightweight HTTP Service > Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: httplite-0.1.5 > > > It's not possible to release httplite using a Java 8 JDK because the javadoc > fails lint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5427) httplite javadoc fails java8 javadoc lint
Benson Margulies created FELIX-5427: --- Summary: httplite javadoc fails java8 javadoc lint Key: FELIX-5427 URL: https://issues.apache.org/jira/browse/FELIX-5427 Project: Felix Issue Type: Bug Components: Lightweight HTTP Service Reporter: Benson Margulies Assignee: Benson Margulies Fix For: httplite-0.1.5 It's not possible to release httplite using a Java 8 JDK because the javadoc fails lint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FELIX-5073) Option to create dependency-reduced-pom exists
[ https://issues.apache.org/jira/browse/FELIX-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed FELIX-5073. --- > Option to create dependency-reduced-pom exists > -- > > Key: FELIX-5073 > URL: https://issues.apache.org/jira/browse/FELIX-5073 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-3.0.0 >Reporter: Benson Margulies > Assignee: Benson Margulies > Fix For: maven-bundle-plugin-3.0.1 > > > It would be convenient to have an option, like the dependency-reduced-pom > option of the maven-shade-plugin, that removes any inlined/embedded > dependencies from the pom of a bundle. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FELIX-5070) Simple syntax for specifying embedded dependencies has broken
[
https://issues.apache.org/jira/browse/FELIX-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed FELIX-5070.
---
> Simple syntax for specifying embedded dependencies has broken
> -
>
> Key: FELIX-5070
> URL: https://issues.apache.org/jira/browse/FELIX-5070
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.0.0
>Reporter: Benson Margulies
> Assignee: Benson Margulies
> Fix For: maven-bundle-plugin-3.0.1
>
>
> In 2.5.3, I could say:
> {code}
> res-core;rni-rnt
> {code}
> or
> {code}
> res-core,rni-rnt
> {code}
> Not any more. I need to say:
> {code}
> *;artifactId=res-core|rni-rnt
> {code}
> which is a whole lot more verbose. This seems undesirable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (FELIX-5069) Spurious split package messages when embedding dependencies
[
https://issues.apache.org/jira/browse/FELIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed FELIX-5069.
---
> Spurious split package messages when embedding dependencies
> ---
>
> Key: FELIX-5069
> URL: https://issues.apache.org/jira/browse/FELIX-5069
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.0.0
>Reporter: Benson Margulies
> Assignee: Benson Margulies
>
> https://github.com/bimargulies/felix-unwanted-split-package-messages-tc:
> run mvn install, see:
> {noformat}
> Use Import/Export Package directive
> -split-package:=(merge-first|merge-last|error|first) to get rid of this
> warning
> Package found in [Jar:sp-tc-jar1, Jar:sp-tc-jar2]
> Class path [Jar:., Jar:sp-tc-jar1, Jar:sp-tc-jar2]
> {noformat}
> I claim that you can't have a 'split package' amongst jars that are embedded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5422) httplite should accept more date formats.
[ https://issues.apache.org/jira/browse/FELIX-5422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated FELIX-5422: Fix Version/s: httplite-0.1.5 > httplite should accept more date formats. > - > > Key: FELIX-5422 > URL: https://issues.apache.org/jira/browse/FELIX-5422 > Project: Felix > Issue Type: Bug > Components: Lightweight HTTP Service > Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: httplite-0.1.5 > > > Full http, via tomcat, accepts some additional date header formats -- > including one that the webconsole uses. Lite could do likewise. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5069) Spurious split package messages when embedding dependencies
[
https://issues.apache.org/jira/browse/FELIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies resolved FELIX-5069.
-
Resolution: Invalid
> Spurious split package messages when embedding dependencies
> ---
>
> Key: FELIX-5069
> URL: https://issues.apache.org/jira/browse/FELIX-5069
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.0.0
>Reporter: Benson Margulies
> Assignee: Benson Margulies
>
> https://github.com/bimargulies/felix-unwanted-split-package-messages-tc:
> run mvn install, see:
> {noformat}
> Use Import/Export Package directive
> -split-package:=(merge-first|merge-last|error|first) to get rid of this
> warning
> Package found in [Jar:sp-tc-jar1, Jar:sp-tc-jar2]
> Class path [Jar:., Jar:sp-tc-jar1, Jar:sp-tc-jar2]
> {noformat}
> I claim that you can't have a 'split package' amongst jars that are embedded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-5423) httplite does not urldecode parameter values
[ https://issues.apache.org/jira/browse/FELIX-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved FELIX-5423. - Resolution: Fixed Fix Version/s: httplite-0.1.5 1771365 > httplite does not urldecode parameter values > > > Key: FELIX-5423 > URL: https://issues.apache.org/jira/browse/FELIX-5423 > Project: Felix > Issue Type: Bug > Components: Lightweight HTTP Service > Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: httplite-0.1.5 > > > Other servlet implementations, when you call getParameter, apply the URL > decoder if the value has any instances of '+' or '%'. httplite does not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[VOTE] Release Felix shell.remote version 1.2.0
Hi, We solved 1 issues in this release: ** Improvement * [FELIX-5418] - Remote shell to support 1.0.0 of gogo instead of 0.6.2... There are still some outstanding issues: https://issues.apache.org/jira/browse/FELIX/component/12312457/?selectedTab=com.atlassian.jira.jira-projects-plugin:component-summary-panel Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1152 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh [YOUR REPOSITORY ID] /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours.
[jira] [Updated] (FELIX-5418) Remote shell to support 1.0.0 of gogo instead of 0.6.2...
[ https://issues.apache.org/jira/browse/FELIX-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated FELIX-5418: Fix Version/s: shell.remote-1.2.0 > Remote shell to support 1.0.0 of gogo instead of 0.6.2... > - > > Key: FELIX-5418 > URL: https://issues.apache.org/jira/browse/FELIX-5418 > Project: Felix > Issue Type: Improvement > Reporter: Benson Margulies > Assignee: Benson Margulies > Fix For: shell.remote-1.2.0 > > > See subject. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
GPG key
I'm about to start some release votes. I've got a new GPG key, could a PMC member please add this to KEYS? pub 4096R/45201BEB 2016-11-25 uid [ultimate] Benson Margulies (CODE SIGNING KEY) sig 345201BEB 2016-11-25 Benson Margulies (CODE SIGNING KEY) sub 4096R/ADAB377C 2016-11-25 sig 45201BEB 2016-11-25 Benson Margulies (CODE SIGNING KEY) -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v2 mQINBFg4cYABEACn8khNpMLzVAbEvfwZsLQdgrJhIB/Clrxn36Zw47/LVBEnaM9q PnYMTSM1tTBDptRlvsSRrqPDQ7TonFBtMj47zk2OzeiGz/xDWPSiEJh8CcgsEI/w iGvvcJUCk6opBeLuq0vLyc/q+kt+P0Sozuv8XgDLGkqEDN0rFW6ODpod6btSaDbL tzoUeJQpl49V4fhJO5CIsknDC8W0fC91Ij26sC/97fvJyHoguIKMzZL2XHYuHPZR Wy3i9AZzjO4dOtIbSV+U+Y0R1H82L1+puLsg4hk/2G30sqbIhQyjd2uhl+lf3HCR tCIZGymILSjr0UlgvlNMwd7DmqEFhTDutoFb3byBN156GR1mgF010o01EwxMHBxc KDUA2JvEvXre4ju+cU/AvwFWiKWG5RTePxHx6iyxP8C76QD09OSBkuFFykD8RGz+ 01SqsBITyFN4doNMAezwYdRCM06TzbSVlEOoWofGrTnhzchREqTyFPOqh/7+S5Hz 6A3nNFuVaIzJ8J+YhS7Jn2nBvlGUev8r6EXHDwSFH69SB4qgEvrvW19aDRyTmBeA YymWSrHFTIJF2Ek8DbEh5dKk1/S8DIZDEpx3m+IZDkqAqYHIhmg7w+g5WlTGE4s7 mDsAdEPktEa9DfOKLN269NpSTQvgaTiR9ZlcVbjct48dIGtsYWuLJXX68QARAQAB tDxCZW5zb24gTWFyZ3VsaWVzIChDT0RFIFNJR05JTkcgS0VZKSA8YmltYXJndWxp ZXNAYXBhY2hlLm9yZz6JAjcEEwEKACEFAlg4cYACGwMFCwkIBwMFFQoJCAsFFgID AQACHgECF4AACgkQ2VHfIEUgG+tf7Q//RU1TmHaucTbYDe3XqBLF4/o6kQFPewEi ihcyky3302LiYVuS3KI2CVaTwjhtecT1DHInF5Ullr+GxdRzcefahobFHAYJBdms Z+C7PSS6SPJWYSOKh3XgBRITaCOKE8AtQGHSjfQcWLqRyq0TopSJxWWBkKQZMRKD L7O6FAmqcDwepXFjmaihY8fN4kDeaK+H5XVFccCMj/lmxBeIrYlqdoT6rOygYeDa Q/2hIEJ5hKLrgR1xWHFkaaN8mEonCSGk3AAGuPz+I+x3uJH2wBouQmdSwGy3Q4eI hCgNTdMEplmJJW7iyy8VIK0BCfplfDpsmqY9/S+IMsGdX6KHvsxgLvH5t2pjqUC0 dlYmTRm5I+S09QXI/TYmvLaqDhH3cvJ54fH1zx77HD12eq2qx5AzRxU/lQnrkMSa usBhIXIdAfQ19X1qL8sLyuu1eawiAG10dGUfRS7ayQlEmK54KUWR/PZI/aHrlrEF +JsyBL8WHfgAWny4kZM0u2ySOdzN0fW5Qa/ULCe7mRIpRqS3+1PXahiMIWDmqqTC NSQCDFOuWduDf4rk+DD3Jru3QJwW/43cmMUvhrlweK3jw011B4X1mcfCupbv+Fiv okuLuSgiXbCW5rNiOvfJ4SfDS5hFJ6oV/FAYs4PoHszDtX84MuvpZuTi8/+wOVKm gZ2mTbTcXM+5Ag0EWDhxgAEQAN+t9UGKKacZk+RgRcObUSwQeDdk40klEg2UlDrV dorKtilN634QZZ1PbgGdb25XvIozCafXmvvVhBm21ho9r5tbLV6vqmgB/OAXKcOy j+CVHkyYCeOYbTCg0GFXxLDgphIv1KSTD0i7ARtnWIietm3IAimVZ8eJnH5R4wBZ w+MFeRv5CSlmA9pfkR1lOFI0zW4jh0HJ7DNztlDNSSr5kBbTm1mej8xO/WmKWr4I VDvHxgzaMZzV56IO/ki/G/ilrQ5hrmqbqtsHVwRPPJWLVumb3EIlY1lHqjs1l85Q ShwsP+aW9gFsTMS8Bjc+KzS+IPzaYCDZEVnsmRFJBZ0NZ/1R/HXr04c8OffFv1bv IPrJIoFSuXTos0eQTZbmyGT1/nMnLSA+6PBJyZhx6nbTYudHMqPPhK2OxDuJ9ITQ kLA0DKCvV+/u8FSsIKRJWMcLFy2XBWwx9KMSJFEV0Hdgy3z3MR2uMaZ0dJ5c87b/ 7UO+1tKyV7IBeYiQ4+kop8IJmgSTD8NhMYXa+i92vLBjhnXuwca8zebHStRXPPE5 68gIJc492FphQTo2/HMkym89DnxPg9aJL/oG6AhkzVXjOzGPJaRI91D4bxjRhJD+ 5ZCmE+mNUdDuvm/0wnA/K6sFNzAOT67OPE7StrsWD/iygbs4L41I41iV3wNH9yTB b7kNABEBAAGJAh8EGAEKAAkFAlg4cYACGwwACgkQ2VHfIEUgG+ugig/+KS1K3BSU /AhcB49QAte8iof+kMtRK9Kyi+hHgkbP3LbVFA72kbvvDNKcJqiPDOUwLAHdmx+p JRBJnrPiECVb0q3X4jK+pZ/YNq/oJGGxef3mjUDn+TqwR7SAwHqHKgk9VFuHOPQG 3JgmqvjOQItuGVG1A5H4cEUyGTVIMoRWGDp+LEa7PmxHJ/hLSFcS5hGNYCpUxpjk yHay5A4Aw806bpvF0vPBb9fl5gBs6mzr5/RgGz1ao1aJiXsi82IoisboT4vzb+SF dfMm0fi0lztc9CxPeZ30T4cA4taYAvaqmryWxblNf4qVJmHGZKByKYhw5bfpTUeI 0q4Jpfm12FfOQK1wcrOvs0+rS+M0gzCXtpxXiaJAulUoORRtYC3pTtngXgrKG/pE DHh8v6RW9K0/P5jl14aiRwg9/pthGndEPlwXPBcMSwY+BBcqJ3VFIU2C64zacJ7u YHpy9c69M+/mbEGg1gAcvH9BteKVANGe1yKprralYJ1t6fWUJlK7iGe+knRQOGYA P6yehcHLlrIhHEQfXXMh9QYeLiKRmEFmjCxGs17eq3muWU83KXdvDMUBdC4JQOxO lKKsSqULsyt2bI+kHx9dSmk116nBsn2TLx1gppE1U+j20l7mAKXazpgMMhdp0L0k lQuOzwJYVATB5K7vXBLPaOsVjErSKPqzYsI= =oeYb -END PGP PUBLIC KEY BLOCK-
[jira] [Created] (FELIX-5423) httplite does not urldecode parameter values
Benson Margulies created FELIX-5423: --- Summary: httplite does not urldecode parameter values Key: FELIX-5423 URL: https://issues.apache.org/jira/browse/FELIX-5423 Project: Felix Issue Type: Bug Components: Lightweight HTTP Service Reporter: Benson Margulies Assignee: Benson Margulies Other servlet implementations, when you call getParameter, apply the URL decoder if the value has any instances of '+' or '%'. httplite does not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5422) httplite should accept more date formats.
[ https://issues.apache.org/jira/browse/FELIX-5422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved FELIX-5422. - Resolution: Fixed Fixed in 1770706. > httplite should accept more date formats. > - > > Key: FELIX-5422 > URL: https://issues.apache.org/jira/browse/FELIX-5422 > Project: Felix > Issue Type: Bug > Components: Lightweight HTTP Service > Reporter: Benson Margulies >Assignee: Benson Margulies > > Full http, via tomcat, accepts some additional date header formats -- > including one that the webconsole uses. Lite could do likewise. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5422) httplite should accept more date formats.
Benson Margulies created FELIX-5422: --- Summary: httplite should accept more date formats. Key: FELIX-5422 URL: https://issues.apache.org/jira/browse/FELIX-5422 Project: Felix Issue Type: Bug Components: Lightweight HTTP Service Reporter: Benson Margulies Assignee: Benson Margulies Full http, via tomcat, accepts some additional date header formats -- including one that the webconsole uses. Lite could do likewise. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Releasing the remote shell
I committed the changes needed to work with gogo 1.0.0 (at least if one avoids JLine). I bumped the version to 1.2.0-SNAPSHOT. Can I stage a release? Would someone else prefer to do so?
[jira] [Resolved] (FELIX-5418) Remote shell to support 1.0.0 of gogo instead of 0.6.2...
[ https://issues.apache.org/jira/browse/FELIX-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved FELIX-5418. - Resolution: Fixed Assignee: Benson Margulies Commit 1770124: update pom so that this works with 1.0.0 of gogo. > Remote shell to support 1.0.0 of gogo instead of 0.6.2... > - > > Key: FELIX-5418 > URL: https://issues.apache.org/jira/browse/FELIX-5418 > Project: Felix > Issue Type: Improvement > Reporter: Benson Margulies > Assignee: Benson Margulies > > See subject. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5418) Remote shell to support 1.0.0 of gogo instead of 0.6.2...
Benson Margulies created FELIX-5418: --- Summary: Remote shell to support 1.0.0 of gogo instead of 0.6.2... Key: FELIX-5418 URL: https://issues.apache.org/jira/browse/FELIX-5418 Project: Felix Issue Type: Improvement Reporter: Benson Margulies See subject. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5415) HTTP leaves extra service registrations when configured with config admin
Benson Margulies created FELIX-5415: --- Summary: HTTP leaves extra service registrations when configured with config admin Key: FELIX-5415 URL: https://issues.apache.org/jira/browse/FELIX-5415 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http.jetty-3.4.0 Reporter: Benson Margulies If you set org.osgi.service.http.port to a port with configuration admin, you will end up with multiple registrations of the service. One is created for the port number that is visible from framework properties, the second from the configuration admin information. If those ports are different, only the second will be actually listening in jetty. The evidence is visible from the gogo inspect command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5413) incorrect log messages about port in felix http
Benson Margulies created FELIX-5413: --- Summary: incorrect log messages about port in felix http Key: FELIX-5413 URL: https://issues.apache.org/jira/browse/FELIX-5413 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http.base-3.0.18 Reporter: Benson Margulies Log message: [INFO ] 2016-11-15 09:37:45.176 [FelixStartLevel] org.apache.felix.http.jetty.3.4.0 - [Unknown]Started Jetty 9.3.12.v20160915 at port(s) HTTP:8080 on context path / [minThreads=8,maxThreads=200,acceptors=1,selectors=4] In config admin, I have: org.osgi.service.http.port=[8182,) and, indeed, there is nothing listening on 8080 but something listening on 8082. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5374) Reduce severity of log message from SCR when there is no metatype
[ https://issues.apache.org/jira/browse/FELIX-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved FELIX-5374. - Resolution: Fixed Fix Version/s: scr-2.1.0 1764148 fixes this by setting the level to INFO. > Reduce severity of log message from SCR when there is no metatype > - > > Key: FELIX-5374 > URL: https://issues.apache.org/jira/browse/FELIX-5374 > Project: Felix > Issue Type: Improvement > Reporter: Benson Margulies > Assignee: Benson Margulies > Fix For: scr-2.1.0 > > > SCR logs at 'error' when there is no metatype. This seems excessive; metatype > is not required, indeed the log message says so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-5374) Reduce severity of log message from SCR when there is no metatype
[ https://issues.apache.org/jira/browse/FELIX-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned FELIX-5374: --- Assignee: Benson Margulies > Reduce severity of log message from SCR when there is no metatype > - > > Key: FELIX-5374 > URL: https://issues.apache.org/jira/browse/FELIX-5374 > Project: Felix > Issue Type: Improvement > Reporter: Benson Margulies > Assignee: Benson Margulies > > SCR logs at 'error' when there is no metatype. This seems excessive; metatype > is not required, indeed the log message says so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5374) Reduce severity of log message from SCR when there is no metatype
Benson Margulies created FELIX-5374: --- Summary: Reduce severity of log message from SCR when there is no metatype Key: FELIX-5374 URL: https://issues.apache.org/jira/browse/FELIX-5374 Project: Felix Issue Type: Improvement Reporter: Benson Margulies SCR logs at 'error' when there is no metatype. This seems excessive; metatype is not required, indeed the log message says so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: svn commit: r1764148 - /felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/config/ScrManagedServiceServiceFactory.java
OK, I'll do it posthumously. On Mon, Oct 10, 2016 at 12:52 PM, David Jencks wrote: > Hi, > > I prefer to open jira issues even for such simple changes as this so there’s > a complete record in jira of everything that happened. > > thanks > david jencks > >> On Oct 10, 2016, at 9:17 AM, bimargul...@apache.org wrote: >> >> Author: bimargulies >> Date: Mon Oct 10 16:17:11 2016 >> New Revision: 1764148 >> >> URL: http://svn.apache.org/viewvc?rev=1764148&view=rev >> Log: >> No jira: reduce log level for SCR noting the absence of MetaType to info, as >> it works just fine without it. >> >> Modified: >> >> felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/config/ScrManagedServiceServiceFactory.java >> >> Modified: >> felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/config/ScrManagedServiceServiceFactory.java >> URL: >> http://svn.apache.org/viewvc/felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/config/ScrManagedServiceServiceFactory.java?rev=1764148&r1=1764147&r2=1764148&view=diff >> == >> --- >> felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/config/ScrManagedServiceServiceFactory.java >> (original) >> +++ >> felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/config/ScrManagedServiceServiceFactory.java >> Mon Oct 10 16:17:11 2016 >> @@ -58,7 +58,7 @@ public class ScrManagedServiceServiceFac >> // assume MetaType Service API not available >> logger >> .log( >> -LogService.LOG_ERROR, >> +LogService.LOG_INFO, >> "Cannot create MetaType providing ManagedService; not >> providing Metatype information but just accepting configuration", >> null ); >> } >> >> >
[jira] [Created] (FELIX-5353) ConfigurationAdmin does not log or diagnose invalid contents of files
Benson Margulies created FELIX-5353:
---
Summary: ConfigurationAdmin does not log or diagnose invalid
contents of files
Key: FELIX-5353
URL: https://issues.apache.org/jira/browse/FELIX-5353
Project: Felix
Issue Type: Wish
Components: Configuration Admin
Reporter: Benson Margulies
If you have a .cfg file with a line like:
{noformat}
prop=${something}/something
{noformat}
The contents of the file disappear, without an exception, a log message, or a
trace. It should at least, I think be logged.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5346) Start annotation not propagated to sub classes
[
https://issues.apache.org/jira/browse/FELIX-5346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491558#comment-15491558
]
Benson Margulies commented on FELIX-5346:
-
Also note that bnd supports
-dsannotations-options: inherit
to make this work, FWIW.
> Start annotation not propagated to sub classes
> --
>
> Key: FELIX-5346
> URL: https://issues.apache.org/jira/browse/FELIX-5346
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager Annotations
>Reporter: Jago de Vreede
>Assignee: Pierre De Rop
>
> Following case in pseudocode:
> {code}Class A {
> @Start
> public void start() {
> System.out.println("start");
> }
> }
> @Component
> Class B extends A {
> }{code}
> When you run this nothing is printed but the start method in A should be
> called as B extends A.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [Converter] Change in API for obtaining a Converter
And then you need 'new' for the Factory, or a static method? Somewhere, the chain of abstraction has to stop. If you don't have any parameters that modify the creation, 'new' is just as good as any sort of Factory or Builder. On Thu, Sep 8, 2016 at 10:21 PM, David Leangen wrote: > > Hi David B., > > Thank for your this explanation. Much of this makes sense, but again, just > out of curiosity… > > I do understand the benefit of having this type of functionality outside > of an OSGi environment. Perhaps the same could even be said for many other > services, too, I’m not sure. > > To do that, instead of using “new” (which for me is a bit of a shock; I > don’t recall even having used “new” to obtain a “service” from a different > bundle), why not use a factory? Actually, the previous way that you wrote > the util package with the publicly available Factory seems like a good > approach to me. > > I’m not married to it, I’m just trying to understand why… Why is “new” > better than a factory, if both achieve the same objective? > > > Cheers, > =David > > > > > On Sep 9, 2016, at 9:53 AM, David Bosschaert > wrote: > > > > Hi David L, > > > > Well, I have to say that I've always thought that the Converter should > be a > > service as well, but where services really come to shine is where you > > potentially have different implementations that might provide different > > features. For the Converter there is very little room for difference in > > implementations. The converters should behave exactly like the spec will > > describe. Any variation on that can be added via the adapters. There is > > still the possibility of distinguishing between implementations from a > > performance point of view, but from a behavioural point of view all > > converters should behave the same to that they are entirely predictable. > Of > > course, this is still possible to do with services, and there are many > > services already of which you would only typically have one at runtime. > > > > The difference here is that the converter is such a generally useful > thing, > > that it can also be really useful outside of an OSGi framework. The API > > itself has no dependency on any other OSGi classes. The thinking is that > > with a simple constructor this makes the converter really easy to use in > > any environment Java environment. > > > > Services are still one of the best features of OSGi IMHO, and for the > > Serializers (what used to be called Codecs) we'll still use services. > This > > especially makes sense since there can be more than one Serializer, there > > is a lot of implementation freedom there (can support any kind of format > > you like) and they are selected based on service properties. > > > > So I agree, services are generally the best choice, however in some > > specific cases, using a simple constructor (or factory method) can make > > sense, especially if there is little room for variation. > > > > Cheers, > > > > David > > > > On 8 September 2016 at 16:42, David Leangen wrote: > > > >> > >> Hi, > >> > >> Just out of pure curiosity… what is the reason for moving away from > >> services like this? This seems like quite a departure from the way > things > >> used to be done… > >> > >> Cheers, > >> =David > >> > >> > >> > >>> On Sep 9, 2016, at 8:14 AM, David Daniel > >> wrote: > >>> > >>> Yes I understand. Thank you > >>> > >>> On Sep 8, 2016 7:10 PM, "David Bosschaert" > > >>> wrote: > >>> > Hi David D, > > The pattern that is being followed here is similar to what is done for > >> OSGi > Promises of which an implementation exists in Apache Aries [1]. There > >> the > Deferred, a class in the org.osgi.service... namespace instantiates > the > Aries implementation. Other implementations can replace the Deferred > >> class > to instantiate their own implementations. > Similarly here constructing a new > org.osgi.service.converter.StandardConverter will instantiate the > Felix > implementation. The org.osgi.service.converter package is embedded in > >> the > bundle. Other implementations will also embed the > org.osgi.service.converter package but provide a different > StandardConverter class, which instantiates a different > implementation. > > Changed in the recent refactoring is that the Converter is not a > service > any more. The StandardConverter is a converter instance that is > exactly > doing what it says in the spec. Anyone who wants a converter simply > >> creates > one by calling new StandardConverter(). > If you want to add customization rules, you simply obtain an Adapter > by > calling > Adapter a = new StandardConverter().newAdapter(); > Then you can add your rules to a. The Adapter a is also a Converter - > it > implements the Converter interface just like the StandardConverter. So > >> you > can call a.convert(something).to(SomethingElse.class) which triggers > >> your >
[jira] [Created] (FELIX-5197) non-fatal circularities in SCR should be info, not error, in log
Benson Margulies created FELIX-5197:
---
Summary: non-fatal circularities in SCR should be info, not error,
in log
Key: FELIX-5197
URL: https://issues.apache.org/jira/browse/FELIX-5197
Project: Felix
Issue Type: Improvement
Components: Declarative Services (SCR)
Affects Versions: scr-2.0.2
Reporter: Benson Margulies
I have two components that have a pseudo-circular dependency.
Component 'WorkerInterface' has a reference like:
{code}
@Reference(cardinality = ReferenceCardinality.MULTIPLE, policy =
ReferencePolicy.DYNAMIC, policyOption = ReferencePolicyOption.GREEDY)
public void setWorkerComponentService(WorkerComponentService
workerComponentService) { ... }
{code}
one of the components that provides 'WorkerComponentService' has:
{code}
@Reference(cardinality = ReferenceCardinality.OPTIONAL, policy =
ReferencePolicy.DYNAMIC, unbind = "unbindWorkerInterface")
public void setWorkerInterface(WorkerInterface workerInterface) { .. }
{code}
This all works: The second activates, the first activates, and then
the second gets called with the reference to the first. However, along
the way, an alarming ERROR-level log message is delivered, as below.
I submit that this should be no louder than INFO.
{noformat}
2016-02-24 10:25:30,963 | ERROR | lixDispatchQueue |
rosapi-worker-rni-rnt-sdk| 51 -
com.basistech.ws.rosapi-worker-rni-rnt-sdk - 0.8.101.v20160224031931 |
FrameworkEvent ERROR - com.basistech.ws.rosapi-worker-rni-rnt-sdk
org.osgi.framework.ServiceException: ServiceFactory.getService()
resulted in a cycle.
at
org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:301)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.Felix.getService(Felix.java:3699)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72)[129:org.apache.felix.scr:2.0.2]
at
org.apache.felix.scr.impl.helper.BindMethod.getServiceObject(BindMethod.java:646)[129:org.apache.felix.scr:2.0.2]
at
org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2137)[129:org.apache.felix.scr:2.0.2]
at
org.apache.felix.scr.impl.manager.DependencyManager$SingleDynamicCustomizer.prebind(DependencyManager.java:872)[129:org.apache.felix.scr:2.0.2]
at
org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1457)[129:org.apache.felix.scr:2.0.2]
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:983)[129:org.apache.felix.scr:2.0.2]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Anyone interested in 'fileinstall' for config via flattening YAML or Json?
On Fri, Dec 25, 2015 at 7:51 PM, David Jencks wrote:
> Benson,
>
> What you did is pretty similar in many ways to what I did although I don’t
> have the json/yaml support.
I'm hardly attached to 4 hours of hacking. If you're willing to take
Jackson deps, I'd be game to collaborate and add json/yaml(/xml) to
what you have.
>
> I’m not sure the [] characters are appropriate for key tokens. Anyway my
> encoding uses key1..key2.….. instead of
> key1[].key2[]…..
I think I could switch to that. On the other hand, can you elaborate
on what's wrong with []? I picked them because it was a less tricky
parse (no "oh, a _number_, that must mean it's a sequence") but I
don't feel very strongly about it.
>
> Since I’m interested in using DS spec features as much as possible, the
> object model is annotations or interfaces rather than concrete classes. So
> if your DS component has
>
> @Activate
> void activate(MyNestedConfigAnnotation config) {…}
>
> DS will generate implementations of the config annotation backed by the CA
> properties map.
I'd be interested to see a fully-worked-out example of this. I often
end up using a fair amount of Jackson @nnotation to tune the
representation. It seems possible that they could coexist; Jackson has
support deserializing to concrete classes as informed by annotations.
>
> I just realized that I haven’t yet made it easy to turn this on by committing
> the meta-annotation to generate the felix specific flag to allow nested
> annotations….. maybe this weekend.
>
> While both you and I picked complex keys, Peter Kriens seems to be strongly
> in favor of complex values encoded in json. I believe one of his reasons is
> that such configurations are less likely to completely break existing
> metatype-aware config viewers.
I waffled back and forth between 'CA is fundamentally a key-value
store, and I need fancy values' and 'I don't want to have a key-value
store at all'. I landed where I did because I wanted to be able to
design a configuration file however it made sense to me -- even with
an sequence rather than a map at the top. But I'm not surprised to
learn that my 'elders' in this design space feel that more
compatibility is more important than this ultimate flexibility, and I
could live with that. As to the contents of the config when in memory,
I don't see anything too horrible about strings of json; it would make
my deflattening scheme a bit slower, but who cares? How big could one
of these sensibly get?
>
> At work I have a proprietary system that relates metatype to these nested
> configurations, but so far there is no hint of spec support. Do you have a
> plan for using metatype?
The first three hits on google for metatype weren't informative enough
to get me off the ground here, so I deferred thinking about it. When
reading via Jackson, I know the type of each value, so I could, I
suppose, generate metatype data on the fly; I'd need to find my way
to/through the documentation about how to do that instead of having
XML sitting in OSGI-INF. Assuming that there is such a way.
>
> While I’m sure OSGI would like your employer to join and help pay $$, I think
> you personally can join as a non-voting person for free or a trivial amount
> of $$. I’d encourage you to consider this to help out with the spec
> development.
I'll have a look. To be honest, I've posted enough stupid stuff here
as I've been learning my way around that I don't think of myself much
of a candidate member of a spec team; I can certainly represent my use
case.
>
> thanks
> david jencks
>
>> On Dec 25, 2015, at 3:00 PM, Benson Margulies wrote:
>>
>> David,
>>
>> Warning, this is going to be a long message.
>>
>> Background:
>>
>> I created an OSGi DS component which is initialized from a complex
>> configuration. I defined this configuration in terms of a Java object
>> model. I implemented it by having a single configuration admin
>> property that pointed to a file of YAML, and then I use Jackson to
>> read that file into the Java objects of the model. I've typed a subset
>> of it below.
>>
>> It all is quite readable and maintainable as a YAML file. That's the
>> driver here: I want a component with relatively complex configuration,
>> and I want that configuration to be maintainable and readable in a
>> natural way. I don't want the devops people to have to deal with the
>> consequences of force-fitting the complex configuration into a simple
>> key-value model, particularly because there are sequences of objects
>> in the natural model. This all works.
>>
>> How this (new) code
Re: Anyone interested in 'fileinstall' for config via flattening YAML or Json?
David,
Warning, this is going to be a long message.
Background:
I created an OSGi DS component which is initialized from a complex
configuration. I defined this configuration in terms of a Java object
model. I implemented it by having a single configuration admin
property that pointed to a file of YAML, and then I use Jackson to
read that file into the Java objects of the model. I've typed a subset
of it below.
It all is quite readable and maintainable as a YAML file. That's the
driver here: I want a component with relatively complex configuration,
and I want that configuration to be maintainable and readable in a
natural way. I don't want the devops people to have to deal with the
consequences of force-fitting the complex configuration into a simple
key-value model, particularly because there are sequences of objects
in the natural model. This all works.
How this (new) code came to be:
It occurred to us that it would be desirable to be able to manipulate
this, to some extent, through ConfigurationAdmin -- to be able to drop
in a new config and have the service reconfigure, to see and edit some
details in the existing tools.
After some discussion with other people who had done similar things on
the Karaf list, I decided to adopt 'flatten tree-shaped configurations
into a single CA configuration', because I was able to think my way
around it. The implementation uses complex keys to avoid complex
values; I didn't know that Felix had existing support; I invented my
own (rather obvious) mapping between the Jackson generic tree
structure and complex keys. (I suspected that something awful would
happen if I put complex values into the Dictionary and fed that to
ConfigurationAdmin.) Certainly the web console and the Karaf shell
would be unable to help edit such things.
To illustrate:
Consider a configuration file in YAML like:
factories:
- id: factory1
componentId: tokenization
- id: factory2
componentId: ner
pipelines:
- endpoint: ner
stages:
- factoryId: factory1
languages: ['*']
- factoryId: factory2
languages: ['*']
This corresponds to an overall Java class (Configuration), plus
Factory and Stage.
class Configuration {
List factories;
List pipelines;
}; // etc, etc.
The service component in that git repo reads a file like this as a
generic tree structure that can represent Json, Yaml (or even XML),
and then 'flattens' it using complex keys:
factories[0].id = factory2
factories[0].componentId = tokenization
...
pipelines[0].endpoint = ner
pipelines[0].stages[0].factoryId = factory1
...
Given all of this, my device reads the file, makes the Dictionary with
the complex 'flattened' keys, and pushed it into ConfigurationAdmin.
The service that does the work now receives the Dictionary with those
keys and their values. However, it does not have to work with them as
such. It can call a method I've supplied to 'deflatten' -- to convert
the key-value dictionary back into the tree structure of the Jackson
'JsonNode' classes. But that's not all: once it has that tree, it can
ask Jackson to convert to the original nice object model. And now
we've got cake and and eating it too; the code of my service works
with the nice Java object model, the config in source control is
readable YAML, and you can at least look around and make simple
changes in the standard tools.
The code I wrote today is not all that complex: one class maps back
and forth between JsonNode trees and Dictionary objects, and another
uses the NIO2 watcher to implement the 'watch the file system and poke
ConfigurationAdmin'.
to answer your first question: I don't know if I have access to R7
docs. Neither I nor my employer has any particular relationship to the
OSGi consortium.
--benson
On Fri, Dec 25, 2015 at 5:15 PM, David Jencks wrote:
> Hi Benson,
>
> Can you get to the OSGI RFCs under development for R7? There’s the
> Configurer one abstracted from the enRoute configurer that David mentioned
> and an object conversion service abstracting the config-by-annotations from
> DS 1.3/R6.
>
> I don’t quite understand what you mean by “Object model” and “flattening”.
> Does your project deal with converting nested configurations into e.g. DS
> references somehow? Or does it flatten tree-shaped configurations into a
> single CA configuration? I’m in favor of both of these ideas making it into
> the specs in some form; felix DS already has some support for tree-shaped
> configurations using complex keys rather than complex values.
>
> I’d appreciate some more description of what your code does….
>
> thanks
> david jencks
>> On Dec 25, 2015, at 1:56 PM, David Daniel
>> wrote:
>>
>> Thank you for the explanation
>>
>> On Friday, December 25, 2015, Benso
Re: Anyone interested in 'fileinstall' for config via flattening YAML or Json?
On Fri, Dec 25, 2015 at 4:45 PM, David Daniel wrote: > What are the differences other than yaml with enroutes configuration > provider. > https://github.com/osgi/osgi.enroute.bundles/tree/master/osgi.enroute.configurer.simple.provider It does not look to me as if that does a full object model; it looks as if it just replaces property file syntax for a single-level map with json syntax. I may not be doing it justice in a fast read. Also, mine allows the receiving component to convert the Dictionary (back) to a Jackson JsonNode, and thence to a real class model. So, you can define a configuration in terms of full data model, but still push it through config admin and allow the use of the webconsole or karaf shell to examine or make minor changes on the fly. I am not educated in enroute, so I would not be surprised to learn that I've reinvented a wheel. > > On Fri, Dec 25, 2015 at 4:39 PM, Benson Margulies > wrote: > >> After some hints from folks on the Karaf list, I implemented a mutant >> cousin of fileinstall. It only does config admin, and it's role in >> life is to read yaml or json files, 'flatten' them, and push the >> results into config admin. My plan is for the things that use it to >> reconstruct the original object model by reversing the flattening, not >> to actually use keys like "foo.bar[3].baz' -- it includes an API that >> maps a CA Dictionary back to a JsonTree. >> >> For expediency, I made it depend on NIO2 (not to mention Jackson) and DS. >> >> I doubt that folks will see this as generally applicable, but I >> carefully set it up with AL so that I could contribute it if there is >> a surprising (to me) groundswell of interest. I know that some >> karafers read this list, so I'm not going to bother to crosspost. >> >> I haven't written any automated tests yet. >> >> https://github.com/benson-basis/yaml-configuration-admin >>
Anyone interested in 'fileinstall' for config via flattening YAML or Json?
After some hints from folks on the Karaf list, I implemented a mutant cousin of fileinstall. It only does config admin, and it's role in life is to read yaml or json files, 'flatten' them, and push the results into config admin. My plan is for the things that use it to reconstruct the original object model by reversing the flattening, not to actually use keys like "foo.bar[3].baz' -- it includes an API that maps a CA Dictionary back to a JsonTree. For expediency, I made it depend on NIO2 (not to mention Jackson) and DS. I doubt that folks will see this as generally applicable, but I carefully set it up with AL so that I could contribute it if there is a surprising (to me) groundswell of interest. I know that some karafers read this list, so I'm not going to bother to crosspost. I haven't written any automated tests yet. https://github.com/benson-basis/yaml-configuration-admin
Re: Git dies of lack of interest?
I believe that everyone in the felix-users confluence group now has access to edit pages in my 'personal space'. On Tue, Dec 1, 2015 at 9:49 PM, Benson Margulies wrote: > On Tue, Dec 1, 2015 at 7:50 PM, David Jencks wrote: >> I also see no way to edit your page, and I have no idea who might be a >> confluence space administrator who could change permissions. >> >> I was going to add to the pro-single-git-repo the point that you can check >> out exactly the parts you want using git sparse-checkout. >> >> I don’t think the decision to move to git can be made independent of choice >> of a git workflow. I’m strongly in favor of triangular workflow. > > Presumably, when it's morning in Europe, someone will turn up who > knows how to admin bimargul...@gmail.com into the Felix space. If not, > I'll open an Infra ticket. > > meanwhile, can't you all at least put things into comments on the bottom? > > (I can't see a way to give other people edit permission to my 'personal > space'). > > > >> >> thanks >> david jencks >> >>> On Dec 1, 2015, at 4:14 PM, Benson Margulies wrote: >>> >>> On Dec 1, 2015 6:43 PM, "Richard S. Hall" wrote: >>>> >>>> >>>>> On Dec 1, 2015, at 17:50, Benson Margulies >>> wrote: >>>>> >>>>> >>> https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git >>>>> >>>>> ? >>>> >>>> Seems like a good start, although is that editable by others? >>> >>> I don't know. Try? I don't have perms to make a page on the Felix wiki , if >>> I get some I will move it. >>> >>>> >>>> It seems like other technical issues were raised about the approaches, so >>> it would be nice to see those added in there by people who have experience. >>>> >>>> I admit, for me, SCM is a necessary evil and not something I get too >>> exited about. I haven’t seen anything to prefer git over svn or vice versa. >>> They’re just different hammers for the same nail. >>>> >>>> Still, thinking about the options, it seems like multiple repos creates a >>> maintenance headache to some degree. For example, line-ending handling is >>> fairly difficult to get configured correctly in git. By having multiple >>> repositories, then every repository would have to have this configured >>> individually, since stuff like that is good to have configured uniformly. >>> Any changes to how we want things uniformly handled would require manual >>> propagation of configuration. Of course, this seems like it would be an >>> issue in any proliferation of repositories (svn or git). >>>> >>>> Or perhaps there is a better way to handle such issues? >>>> >>>> -> richard >>>> >>>>> >>>>> >>>>> On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall >>> wrote: >>>>>> On 12/1/15 13:40 , Carsten Ziegeler wrote: >>>>>>> >>>>>>> Richard S. Hall wrote >>>>>>>> >>>>>>>> Well, the argument to the contrary is perhaps that is makes it more >>>>>>>> difficult for us as a community to have oversight into releases. It >>>>>>>> almost assures us that some/many community members will never >>> checkout >>>>>>>> subprojects that aren't in the repository they normally work. >>> Granted, >>>>>>>> there is no guarantee of this now, since I can just check out what I >>>>>>>> want anyway...but at least it is fairly easy for me to do so now and >>> it >>>>>>>> becomes more difficult if everyone spreads to their own repos. >>>>>>>> >>>>>>>> So, in that regard, I'm more aligned with Marcel...all or nothing >>> makes >>>>>>>> more sense. >>>>>>> >>>>>>> Hmm, ok fair point - however, the *all* is the problematic part where >>> we >>>>>>> couldn't agree on last time (one git repo vs many git repos). >>>>>> >>>>>> >>>>>> But isn't it then incumbent on those wanting such changes to convince >>> us one >>>>>> way or the other? >>>>>> >>>>>> Personally, I'd rather just have one big git repo if we are going to >>> switch, >>>>>> if for no other reason than it seems like less overhead. However, I >>> admit to >>>>>> not really knowing the advantages/disadvantages. >>>>>> >>>>>> Regardless, at a minimum, perhaps someone should create a documented >>>>>> pros/cons list for the approaches. This would at least give us a way >>> to call >>>>>> a vote where we can feel somewhat informed about the choices (i.e., >>> stay >>>>>> with svn, move to one git repo, move to many git repos). >>>>>> >>>>>> Better than saying, "there is no consensus, so let's just go our >>> separate >>>>>> ways"... >>>>>> >>>>>> -> richard >>>>>> >>>>>> >>>>>>> >>>>>>> We could still provide a script in the root of svn which checks out >>> the >>>>>>> moved projects from git and gives the same experience :) >>>>>>> >>>>>>> Carsten >>>>>> >>>>>> >>>> >>
Re: Git dies of lack of interest?
On Tue, Dec 1, 2015 at 7:50 PM, David Jencks wrote: > I also see no way to edit your page, and I have no idea who might be a > confluence space administrator who could change permissions. > > I was going to add to the pro-single-git-repo the point that you can check > out exactly the parts you want using git sparse-checkout. > > I don’t think the decision to move to git can be made independent of choice > of a git workflow. I’m strongly in favor of triangular workflow. Presumably, when it's morning in Europe, someone will turn up who knows how to admin bimargul...@gmail.com into the Felix space. If not, I'll open an Infra ticket. meanwhile, can't you all at least put things into comments on the bottom? (I can't see a way to give other people edit permission to my 'personal space'). > > thanks > david jencks > >> On Dec 1, 2015, at 4:14 PM, Benson Margulies wrote: >> >> On Dec 1, 2015 6:43 PM, "Richard S. Hall" wrote: >>> >>> >>>> On Dec 1, 2015, at 17:50, Benson Margulies >> wrote: >>>> >>>> >> https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git >>>> >>>> ? >>> >>> Seems like a good start, although is that editable by others? >> >> I don't know. Try? I don't have perms to make a page on the Felix wiki , if >> I get some I will move it. >> >>> >>> It seems like other technical issues were raised about the approaches, so >> it would be nice to see those added in there by people who have experience. >>> >>> I admit, for me, SCM is a necessary evil and not something I get too >> exited about. I haven’t seen anything to prefer git over svn or vice versa. >> They’re just different hammers for the same nail. >>> >>> Still, thinking about the options, it seems like multiple repos creates a >> maintenance headache to some degree. For example, line-ending handling is >> fairly difficult to get configured correctly in git. By having multiple >> repositories, then every repository would have to have this configured >> individually, since stuff like that is good to have configured uniformly. >> Any changes to how we want things uniformly handled would require manual >> propagation of configuration. Of course, this seems like it would be an >> issue in any proliferation of repositories (svn or git). >>> >>> Or perhaps there is a better way to handle such issues? >>> >>> -> richard >>> >>>> >>>> >>>> On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall >> wrote: >>>>> On 12/1/15 13:40 , Carsten Ziegeler wrote: >>>>>> >>>>>> Richard S. Hall wrote >>>>>>> >>>>>>> Well, the argument to the contrary is perhaps that is makes it more >>>>>>> difficult for us as a community to have oversight into releases. It >>>>>>> almost assures us that some/many community members will never >> checkout >>>>>>> subprojects that aren't in the repository they normally work. >> Granted, >>>>>>> there is no guarantee of this now, since I can just check out what I >>>>>>> want anyway...but at least it is fairly easy for me to do so now and >> it >>>>>>> becomes more difficult if everyone spreads to their own repos. >>>>>>> >>>>>>> So, in that regard, I'm more aligned with Marcel...all or nothing >> makes >>>>>>> more sense. >>>>>> >>>>>> Hmm, ok fair point - however, the *all* is the problematic part where >> we >>>>>> couldn't agree on last time (one git repo vs many git repos). >>>>> >>>>> >>>>> But isn't it then incumbent on those wanting such changes to convince >> us one >>>>> way or the other? >>>>> >>>>> Personally, I'd rather just have one big git repo if we are going to >> switch, >>>>> if for no other reason than it seems like less overhead. However, I >> admit to >>>>> not really knowing the advantages/disadvantages. >>>>> >>>>> Regardless, at a minimum, perhaps someone should create a documented >>>>> pros/cons list for the approaches. This would at least give us a way >> to call >>>>> a vote where we can feel somewhat informed about the choices (i.e., >> stay >>>>> with svn, move to one git repo, move to many git repos). >>>>> >>>>> Better than saying, "there is no consensus, so let's just go our >> separate >>>>> ways"... >>>>> >>>>> -> richard >>>>> >>>>> >>>>>> >>>>>> We could still provide a script in the root of svn which checks out >> the >>>>>> moved projects from git and gives the same experience :) >>>>>> >>>>>> Carsten >>>>> >>>>> >>> >
Re: Git dies of lack of interest?
On Dec 1, 2015 6:43 PM, "Richard S. Hall" wrote: > > > > On Dec 1, 2015, at 17:50, Benson Margulies wrote: > > > > https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git > > > > ? > > Seems like a good start, although is that editable by others? I don't know. Try? I don't have perms to make a page on the Felix wiki , if I get some I will move it. > > It seems like other technical issues were raised about the approaches, so it would be nice to see those added in there by people who have experience. > > I admit, for me, SCM is a necessary evil and not something I get too exited about. I haven’t seen anything to prefer git over svn or vice versa. They’re just different hammers for the same nail. > > Still, thinking about the options, it seems like multiple repos creates a maintenance headache to some degree. For example, line-ending handling is fairly difficult to get configured correctly in git. By having multiple repositories, then every repository would have to have this configured individually, since stuff like that is good to have configured uniformly. Any changes to how we want things uniformly handled would require manual propagation of configuration. Of course, this seems like it would be an issue in any proliferation of repositories (svn or git). > > Or perhaps there is a better way to handle such issues? > > -> richard > > > > > > > On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall wrote: > >> On 12/1/15 13:40 , Carsten Ziegeler wrote: > >>> > >>> Richard S. Hall wrote > >>>> > >>>> Well, the argument to the contrary is perhaps that is makes it more > >>>> difficult for us as a community to have oversight into releases. It > >>>> almost assures us that some/many community members will never checkout > >>>> subprojects that aren't in the repository they normally work. Granted, > >>>> there is no guarantee of this now, since I can just check out what I > >>>> want anyway...but at least it is fairly easy for me to do so now and it > >>>> becomes more difficult if everyone spreads to their own repos. > >>>> > >>>> So, in that regard, I'm more aligned with Marcel...all or nothing makes > >>>> more sense. > >>> > >>> Hmm, ok fair point - however, the *all* is the problematic part where we > >>> couldn't agree on last time (one git repo vs many git repos). > >> > >> > >> But isn't it then incumbent on those wanting such changes to convince us one > >> way or the other? > >> > >> Personally, I'd rather just have one big git repo if we are going to switch, > >> if for no other reason than it seems like less overhead. However, I admit to > >> not really knowing the advantages/disadvantages. > >> > >> Regardless, at a minimum, perhaps someone should create a documented > >> pros/cons list for the approaches. This would at least give us a way to call > >> a vote where we can feel somewhat informed about the choices (i.e., stay > >> with svn, move to one git repo, move to many git repos). > >> > >> Better than saying, "there is no consensus, so let's just go our separate > >> ways"... > >> > >> -> richard > >> > >> > >>> > >>> We could still provide a script in the root of svn which checks out the > >>> moved projects from git and gives the same experience :) > >>> > >>> Carsten > >> > >> >
Re: Git dies of lack of interest?
https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git ? On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall wrote: > On 12/1/15 13:40 , Carsten Ziegeler wrote: >> >> Richard S. Hall wrote >>> >>> Well, the argument to the contrary is perhaps that is makes it more >>> difficult for us as a community to have oversight into releases. It >>> almost assures us that some/many community members will never checkout >>> subprojects that aren't in the repository they normally work. Granted, >>> there is no guarantee of this now, since I can just check out what I >>> want anyway...but at least it is fairly easy for me to do so now and it >>> becomes more difficult if everyone spreads to their own repos. >>> >>> So, in that regard, I'm more aligned with Marcel...all or nothing makes >>> more sense. >> >> Hmm, ok fair point - however, the *all* is the problematic part where we >> couldn't agree on last time (one git repo vs many git repos). > > > But isn't it then incumbent on those wanting such changes to convince us one > way or the other? > > Personally, I'd rather just have one big git repo if we are going to switch, > if for no other reason than it seems like less overhead. However, I admit to > not really knowing the advantages/disadvantages. > > Regardless, at a minimum, perhaps someone should create a documented > pros/cons list for the approaches. This would at least give us a way to call > a vote where we can feel somewhat informed about the choices (i.e., stay > with svn, move to one git repo, move to many git repos). > > Better than saying, "there is no consensus, so let's just go our separate > ways"... > > -> richard > > >> >> We could still provide a script in the root of svn which checks out the >> moved projects from git and gives the same experience :) >> >> Carsten > >
Fwd: Git dies of lack of interest?
On Tue, Dec 1, 2015 at 11:43 AM, Marcel Offermans wrote: > Hello Benson, > > There is, at least, substantial apathy about git on the part of the > sub-communities that work on some of the sub-projects. In my view, > this apathy, including perhaps a bit of antipathy, sunk the discussion > of just converting as one big repo. As I see it, Felix is a bit of a > loose confederation, and Ray's suggestion is consistent with letting > each of the tribes make up its own mind. > > I am not sure if the apathy is related to converting as one big repository. That's not what I was trying to express. There are some people who, like you, are not enthusiasts. (I'm not interested in trying to convince anyone else that git is 'better'. I will only write that git is becoming very popular, and, as a result, it can facilitate community growth to use it.) Thus, if you ask the question, 'should we move the whole Felix tree to git?', it could be that there are enough non-enthusiasts to block consensus. That is my proposed explanation for the death of the previous thread. And maybe it should just stay dead. If the community has no consensus to move to git, it stays in svn. Ray's proposal looks at another perspective, which is that Felix is composed of a set of rather loosely-coupled pieces. If the predominant contributors to some of those pieces want them in git, why not? (I appreciate that Marcel's view is an answer to the question 'why not!') I offer as an analogy, 'some things build with Maven, some with Gradle.' Since we don't release the entire tree at once, I don't why the choice of VCS needs to be any more uniform than the choice of build tool. However, I didn't reopen this question today to fill everyone's mailbox. I'd like to maintain the bundle plugin in git. But I'm not going to stomp off in a huff if doesn't happen. I'd be happy to see a vote to move just the bundle plugin, and I'll live with the outcome either way. Same for a vote to proceed with the whole project. But if the right thing to do is ... nothing ... then nothing it is. > > Let me speak for myself here, I don’t see compelling arguments for moving to > Git. What problem are we solving here? Why is moving to Git the right > solution? That’s where my lack of enthusiasm comes from. Nobody has yet > explained that to me. And splitting the project so each subproject ends up > in a different repository sounds even less appealing to me (which I am > afraid will happen if we just start moving one, or a few, subprojects). I > would be in favour of a plan where we either move every subproject, or none > at all. And before we start the move, please come up with a plan that > outlines the steps that need to be taken. Maybe even physically do the > migration and demonstrate that things like our release processes are still > working. And yes, that is a lot of work, and enough people need to step up > and offer their help. > > Greetings, Marcel > >
Re: Git dies of lack of interest?
On Tue, Dec 1, 2015 at 11:16 AM, Carsten Ziegeler wrote: > Benson Margulies wrote >> Here's how I'd call the vote: >> >> This is a vote to move the reference source of the maven-bundle-plugin to >> git. >> >> To be specific, >> >> - http://git.apache.org/ will list the repository as >> 'felix-maven-bundle-plugin.git' (because all repo names start with >> their project name). >> - all existing history will be migrated using svn2git. >> - the 'top' of the repo will correspond to >> https://svn.apache.org/repos/asf/felix/trunk/tools/maven-bundle-plugin. >> - The code will be removed and replaced with a readme.txt in svn on trunk. >> > Sounds good to me, assuming that commit mails are still send out to the > same list as before? Yes, that's the behavior of the Foundation's git infrastructure. > > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: Git dies of lack of interest?
David, There is, at least, substantial apathy about git on the part of the sub-communities that work on some of the sub-projects. In my view, this apathy, including perhaps a bit of antipathy, sunk the discussion of just converting as one big repo. As I see it, Felix is a bit of a loose confederation, and Ray's suggestion is consistent with letting each of the tribes make up its own mind. At least, that's how I read the recent email messages (and lacks of email messages). --benson On Tue, Dec 1, 2015 at 10:20 AM, David Jencks wrote: > I apologize for losing track of this whole discussion. I don’t recall seeing > a convincing to me reason to have, at least initially, more than one git > repo. Wasn’t there even a new git feature that let you check out only part > of a project? > > However many repos we decide on, I’m in favor of git :-) With my chronic > distraction I will wait a bit to see if someone else organizes the vote > (thanks Carsten). > > david jencks > >> On Dec 1, 2015, at 7:12 AM, Carsten Ziegeler wrote: >> >> Benson Margulies wrote >>> I would like to peel the bundle plugin. Does any pmc member sympathize >>> sufficiently to start a vote to test consensus to do that? >> >> I don't want to be a PITA, but would you care about writing a more >> detailed description of what that would mean? (git repo name, how it is >> set up) I'm actually not sure what it would need as a description but >> definitely a little bit more than just saying "move to git" :) >> >> I wouldn't mind starting a vote based on that - unless someone signals >> that this is a stupid idea :) >> >> Carsten >> >>> >>> On Dec 1, 2015 9:38 AM, "Raymond Auge" >> <mailto:raymond.a...@liferay.com>> wrote: >>> >>>U ok.. let me see if I can belatedly recapture the brilliance.. >>> >>>I think it was simply the observation that if the end result was to have >>>many repos, couldn't each subproject just start pealing itself off >>>into a >>>git repo as it sees fit? >>> >>>Call it lazy migration if you will. >>> >>>The side effects are going to be limited to those sub projects as >>>they are >>>in transition. But the bulk of main project can safely continue to >>>work in >>>the meantime. >>> >>>That's the entire anti-climactic idea. >>> >>>- Ray >>>On Dec 1, 2015 9:02 AM, "Carsten Ziegeler" >><mailto:cziege...@apache.org>> wrote: >>> >>>> Benson Margulies wrote >>>>> It sure seems as if there are no PMC members fond enough of the git >>>>> idea to call a vote. I'm treating this as a dead topic for now. >>>>> >>>> Looks like :( >>>> >>>> I had a brief discussion two weeks ago with Ray, and he had an >>>> interesting idea. @Ray do you want to bring it up? >>>> >>>> Regards >>>> Carsten >>>> -- >>>> Carsten Ziegeler >>>> Adobe Research Switzerland >>>> cziege...@apache.org <mailto:cziege...@apache.org> >>>> >>> >> >> >> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org >
Re: Git dies of lack of interest?
Here's how I'd call the vote: This is a vote to move the reference source of the maven-bundle-plugin to git. To be specific, - http://git.apache.org/ will list the repository as 'felix-maven-bundle-plugin.git' (because all repo names start with their project name). - all existing history will be migrated using svn2git. - the 'top' of the repo will correspond to https://svn.apache.org/repos/asf/felix/trunk/tools/maven-bundle-plugin. - The code will be removed and replaced with a readme.txt in svn on trunk. On Tue, Dec 1, 2015 at 10:25 AM, Benson Margulies wrote: > I will write a VOTE thread with a description. > > > > On Tue, Dec 1, 2015 at 10:12 AM, Carsten Ziegeler > wrote: >> Benson Margulies wrote >>> I would like to peel the bundle plugin. Does any pmc member sympathize >>> sufficiently to start a vote to test consensus to do that? >> >> I don't want to be a PITA, but would you care about writing a more >> detailed description of what that would mean? (git repo name, how it is >> set up) I'm actually not sure what it would need as a description but >> definitely a little bit more than just saying "move to git" :) >> >> I wouldn't mind starting a vote based on that - unless someone signals >> that this is a stupid idea :) >> >> Carsten >> >>> >>> On Dec 1, 2015 9:38 AM, "Raymond Auge" >> <mailto:raymond.a...@liferay.com>> wrote: >>> >>> U ok.. let me see if I can belatedly recapture the brilliance.. >>> >>> I think it was simply the observation that if the end result was to have >>> many repos, couldn't each subproject just start pealing itself off >>> into a >>> git repo as it sees fit? >>> >>> Call it lazy migration if you will. >>> >>> The side effects are going to be limited to those sub projects as >>> they are >>> in transition. But the bulk of main project can safely continue to >>> work in >>> the meantime. >>> >>> That's the entire anti-climactic idea. >>> >>> - Ray >>> On Dec 1, 2015 9:02 AM, "Carsten Ziegeler" >> <mailto:cziege...@apache.org>> wrote: >>> >>> > Benson Margulies wrote >>> > > It sure seems as if there are no PMC members fond enough of the git >>> > > idea to call a vote. I'm treating this as a dead topic for now. >>> > > >>> > Looks like :( >>> > >>> > I had a brief discussion two weeks ago with Ray, and he had an >>> > interesting idea. @Ray do you want to bring it up? >>> > >>> > Regards >>> > Carsten >>> > -- >>> > Carsten Ziegeler >>> > Adobe Research Switzerland >>> > cziege...@apache.org <mailto:cziege...@apache.org> >>> > >>> >> >> >> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org
Re: Git dies of lack of interest?
I will write a VOTE thread with a description. On Tue, Dec 1, 2015 at 10:12 AM, Carsten Ziegeler wrote: > Benson Margulies wrote >> I would like to peel the bundle plugin. Does any pmc member sympathize >> sufficiently to start a vote to test consensus to do that? > > I don't want to be a PITA, but would you care about writing a more > detailed description of what that would mean? (git repo name, how it is > set up) I'm actually not sure what it would need as a description but > definitely a little bit more than just saying "move to git" :) > > I wouldn't mind starting a vote based on that - unless someone signals > that this is a stupid idea :) > > Carsten > >> >> On Dec 1, 2015 9:38 AM, "Raymond Auge" > <mailto:raymond.a...@liferay.com>> wrote: >> >> U ok.. let me see if I can belatedly recapture the brilliance.. >> >> I think it was simply the observation that if the end result was to have >> many repos, couldn't each subproject just start pealing itself off >> into a >> git repo as it sees fit? >> >> Call it lazy migration if you will. >> >> The side effects are going to be limited to those sub projects as >> they are >> in transition. But the bulk of main project can safely continue to >> work in >> the meantime. >> >> That's the entire anti-climactic idea. >> >> - Ray >> On Dec 1, 2015 9:02 AM, "Carsten Ziegeler" > <mailto:cziege...@apache.org>> wrote: >> >> > Benson Margulies wrote >> > > It sure seems as if there are no PMC members fond enough of the git >> > > idea to call a vote. I'm treating this as a dead topic for now. >> > > >> > Looks like :( >> > >> > I had a brief discussion two weeks ago with Ray, and he had an >> > interesting idea. @Ray do you want to bring it up? >> > >> > Regards >> > Carsten >> > -- >> > Carsten Ziegeler >> > Adobe Research Switzerland >> > cziege...@apache.org <mailto:cziege...@apache.org> >> > >> > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: Git dies of lack of interest?
I would like to peel the bundle plugin. Does any pmc member sympathize sufficiently to start a vote to test consensus to do that? On Dec 1, 2015 9:38 AM, "Raymond Auge" wrote: > U ok.. let me see if I can belatedly recapture the brilliance.. > > I think it was simply the observation that if the end result was to have > many repos, couldn't each subproject just start pealing itself off into a > git repo as it sees fit? > > Call it lazy migration if you will. > > The side effects are going to be limited to those sub projects as they are > in transition. But the bulk of main project can safely continue to work in > the meantime. > > That's the entire anti-climactic idea. > > - Ray > On Dec 1, 2015 9:02 AM, "Carsten Ziegeler" wrote: > > > Benson Margulies wrote > > > It sure seems as if there are no PMC members fond enough of the git > > > idea to call a vote. I'm treating this as a dead topic for now. > > > > > Looks like :( > > > > I had a brief discussion two weeks ago with Ray, and he had an > > interesting idea. @Ray do you want to bring it up? > > > > Regards > > Carsten > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > > >
Git dies of lack of interest?
It sure seems as if there are no PMC members fond enough of the git idea to call a vote. I'm treating this as a dead topic for now.
Re: [VOTE] Release Apache Felix http.base 3.0.4, http.bridge 3.0.4, and http.jetty 3.1.4
Yes, I was surprised to get three links to the same list. On Nov 26, 2015 9:00 AM, "Jean-Baptiste Onofré" wrote: > +1 (non binding) > > Regards > JB > > On 11/26/2015 02:46 PM, David Bosschaert wrote: > >> +1 >> >> David >> >> On 26 November 2015 at 13:09, Carsten Ziegeler >> wrote: >> >>> Hi, >>> >>> We solved some issues for this release: >>> >>> http.base 3.0.4 (4 issues) >>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12333777 >>> >>> http.bridge 3.0.4 (4 issues) >>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12333779 >>> >>> http.jetty 3.1.4 (6 issues) >>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12333778 >>> >>> Staging repository: >>> https://repository.apache.org/content/repositories/orgapachefelix-1105/ >>> >>> You can use this UNIX script to download the release and verify the >>> signatures: >>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh >>> >>> Usage: >>> sh check_staged_release.sh 1105 /tmp/felix-staging >>> >>> Please vote to approve this release: >>> >>> [ ] +1 Approve the release >>> [ ] -1 Veto the release (please provide specific comments) >>> >>> This vote will be open for at least 72 hours. >>> Regards >>> Carsten >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> cziege...@apache.org >>> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: [VOTE] Release Apache Felix http.base 3.0.4, http.bridge 3.0.4, and http.jetty 3.1.4
The release notes are identical? On Nov 26, 2015 8:09 AM, "Carsten Ziegeler" wrote: > Hi, > > We solved some issues for this release: > > http.base 3.0.4 (4 issues) > https://issues.apache.org/jira/browse/FELIX/fixforversion/12333777 > > http.bridge 3.0.4 (4 issues) > https://issues.apache.org/jira/browse/FELIX/fixforversion/12333779 > > http.jetty 3.1.4 (6 issues) > https://issues.apache.org/jira/browse/FELIX/fixforversion/12333778 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-1105/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1105 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for at least 72 hours. > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
Re: Reducing the number of manual steps in peforming a release at Felix?
On Mon, Nov 16, 2015 at 7:14 AM, David Bosschaert wrote: > Hi all, > > Every time I do a release in the Felix community I am thinking: > there's too many manual steps involved here, some of which seem to be > unnecessary as they seem duplicative. I'm wondering whether all these > steps are necessary? Especially since other Apache communities are not > performing all of them... > > Here's what I always do (I hope I didn't forget anything...) > > Preparing the release: > 1. Some components have a changelog.txt that needs to be updated. This > information generally is directly copied&pasted from JIRA. > 2. Release is prepared, tagged and staged in Apache Nexus. > 3. Release vote email is sent out. > > After the vote has succeeded: > 4. Vote conclusion email is sent out > 5. Release is published in Maven Nexus > 6. Release artifacts are copied into dist SVN > 7. Jira is updated, component version marked as released > 8. Website News section is updated > 9. Website Download section is updated (I still find this very awkward > to do as I still haven't found out how to do this from the CMS browser > editor) > 10. Release is registered at https://reporter.apache.org/addrelease.html?felix > > While some steps are obviously required some of them don't seem to add > a lot of value. > * Step 1 - changelog.txt. This info is direcly from JIRA, so whats the > extra value? People can just look it up in JIRA! Some projects use the maven-changes-plugin to read the data from JIRA and incorporate it automatically. > * Step 6 - the artifacts are already in Apache Maven > (https://repository.apache.org/content/repositories/releases/org/apache/felix/), > so why do they need to be copied to another location (dist) too? The source-release.zip file must be in dist by Foundation policy. > * Step 8 - while it seems useful to have some sort of a news section > on the website, the current one simply lists released versions without > any interesting details so I don't think it provides any value to > users. > * Step 9 - the downloads page can be made to point to the Maven Repo > which will mean that it does not need to be manually updated any > more... See above. The board decided that 'the official releases' have to come from the dist area where only PMC members have access to put them. Whether we could set up some scripting or automation to make that easier ... > * Step 10 - this info is available in JIRA, it should not be necessary > to describe the component release again... The reporter is part of the board's tracking of the project. We could write a maven plugin to poke it REST-fully, I guess. > > Not sure what others think and maybe some of these steps are required > from an ASF point of view, but in my opinion it would be nice if we > could get rid of the manual and duplicative tasks as much as > possible... > > Cheers, > > David
bundle plugin doc
It's missing, because I apparently have failed twice to decode the CMS doc as to how to create the extpaths.txt file that should stop it from disappearing. As soon as I find out what I'm going wrong I'll put it back into place.
Re: [RESULT] [VOTE] Release Apache Maven Bundle Plugin version 3.0.1
There is no requirement to publish 'convenience binaries' in the dist areas. For a maven plugin, they are not even convenient. They are not forbidden, just not required. On Fri, Nov 13, 2015 at 7:31 AM, David Bosschaert wrote: > Really? I think the downloads http://felix.apache.org/downloads.cgi > points to the dist area so for that it also has to contain the > binaries? > > David > > On 13 November 2015 at 12:07, Benson Margulies wrote: >> The only things in the dist area should be the source release zip, >> it's detached signature file, and its md5 and sha1 files. >> >> On Fri, Nov 13, 2015 at 6:35 AM, Stuart McCulloch wrote: >>> Those files are extraneous artifacts from old Maven releases (where >>> everything got a checksum, even signature files) - this was fixed in >>> https://issues.apache.org/jira/browse/MNG-5504 >>> >>> They aren’t exposed from the site download page, and don’t provide any >>> extra security over the existing checksums/signatures of the primary files >>> - so can be cleaned up for consistency >>> >>> On Friday, 13 November 2015 at 11:19, Pierre De Rop wrote: >>> >>>> I will try to do it, but before I have a question: >>>> >>>> it seems that there is a diff between the files currently committed in the >>>> Felix release repository and this new release candidate: Indeed, in the >>>> release repository, we currently have the following signatures files that >>>> are not present in this new release candidate: >>>> >>>> from https://dist.apache.org/repos/dist/release/felix/: >>>> >>>> maven-bundle-plugin-3.0.0.jar.asc.md5 >>>> maven-bundle-plugin-3.0.0.jar.asc.sha1 >>>> maven-bundle-plugin-3.0.0-javadoc.jar.asc.md5 >>>> maven-bundle-plugin-3.0.0-javadoc.jar.asc.sha1 >>>> maven-bundle-plugin-3.0.0.pom.asc.md5 >>>> maven-bundle-plugin-3.0.0.pom.asc.sha1 >>>> maven-bundle-plugin-3.0.0-source-release.tar.gz.asc.md5 >>>> maven-bundle-plugin-3.0.0-source-release.tar.gz.asc.sha1 >>>> maven-bundle-plugin-3.0.0-source-release.zip.asc.md5 >>>> maven-bundle-plugin-3.0.0-source-release.zip.asc.sha1 >>>> maven-bundle-plugin-3.0.0-sources.jar.asc.md5 >>>> maven-bundle-plugin-3.0.0-sources.jar.asc.sha1 >>>> >>>> I guess that in the previous release (currently in the felix release repo), >>>> the above files were not necessary. >>>> I just would like that someone confirms this ? >>>> >>>> thanks; >>>> >>>> -> Pierre >>>> >>>> >>>> >>>> On Wed, Nov 11, 2015 at 7:41 PM, Benson Margulies >>> (mailto:bimargul...@gmail.com)> >>>> wrote: >>>> >>>> > I'll send the announcement when I get word that someone has committed >>>> > the release package to the dist area. >>>> > >>>> > >>>> > On Wed, Nov 11, 2015 at 1:22 PM, Benson Margulies >>> > (mailto:bimargul...@gmail.com)> >>>> > wrote: >>>> > > Hi, the vote has passed with the following result: >>>> > > >>>> > > +1 (binding): >>>> > > >>>> > > Pierre De Rop >>>> > > David Bosschaert >>>> > > Stuart McCulloch >>>> > > >>>> > > +1 (not binding): >>>> > > >>>> > > Stefan Seifart, Jean-Baptiste Onofré, Jamie Goodyear. >>>> > > >>>> > > I will promote. PMC members, one of you has to put the source into the >>>> > > distro area, I cannot. >>>> > > >>>> > > >>>> > > >>>> > > On Wed, Nov 11, 2015 at 1:14 PM, Pierre De Rop >>> > > (mailto:pierre.de...@gmail.com)> >>>> > wrote: >>>> > > > Hello Benson, >>>> > > > >>>> > > > I was about to vote: +1 >>>> > > > >>>> > > > regards; >>>> > > > /Pierre >>>> > > > >>>> > > > On Wed, Nov 11, 2015 at 7:12 PM, Benson Margulies < >>>> > bimargul...@gmail.com (mailto:bimargul...@gmail.com)> >>>> > > > wrote: >>>> > > > >>>> > > > > We are still one PMC vote short here. >>>> > > > > >>>> > > >
Re: [RESULT] [VOTE] Release Apache Maven Bundle Plugin version 3.0.1
The only things in the dist area should be the source release zip, it's detached signature file, and its md5 and sha1 files. On Fri, Nov 13, 2015 at 6:35 AM, Stuart McCulloch wrote: > Those files are extraneous artifacts from old Maven releases (where > everything got a checksum, even signature files) - this was fixed in > https://issues.apache.org/jira/browse/MNG-5504 > > They aren’t exposed from the site download page, and don’t provide any extra > security over the existing checksums/signatures of the primary files - so can > be cleaned up for consistency > > On Friday, 13 November 2015 at 11:19, Pierre De Rop wrote: > >> I will try to do it, but before I have a question: >> >> it seems that there is a diff between the files currently committed in the >> Felix release repository and this new release candidate: Indeed, in the >> release repository, we currently have the following signatures files that >> are not present in this new release candidate: >> >> from https://dist.apache.org/repos/dist/release/felix/: >> >> maven-bundle-plugin-3.0.0.jar.asc.md5 >> maven-bundle-plugin-3.0.0.jar.asc.sha1 >> maven-bundle-plugin-3.0.0-javadoc.jar.asc.md5 >> maven-bundle-plugin-3.0.0-javadoc.jar.asc.sha1 >> maven-bundle-plugin-3.0.0.pom.asc.md5 >> maven-bundle-plugin-3.0.0.pom.asc.sha1 >> maven-bundle-plugin-3.0.0-source-release.tar.gz.asc.md5 >> maven-bundle-plugin-3.0.0-source-release.tar.gz.asc.sha1 >> maven-bundle-plugin-3.0.0-source-release.zip.asc.md5 >> maven-bundle-plugin-3.0.0-source-release.zip.asc.sha1 >> maven-bundle-plugin-3.0.0-sources.jar.asc.md5 >> maven-bundle-plugin-3.0.0-sources.jar.asc.sha1 >> >> I guess that in the previous release (currently in the felix release repo), >> the above files were not necessary. >> I just would like that someone confirms this ? >> >> thanks; >> >> -> Pierre >> >> >> >> On Wed, Nov 11, 2015 at 7:41 PM, Benson Margulies > (mailto:bimargul...@gmail.com)> >> wrote: >> >> > I'll send the announcement when I get word that someone has committed >> > the release package to the dist area. >> > >> > >> > On Wed, Nov 11, 2015 at 1:22 PM, Benson Margulies > > (mailto:bimargul...@gmail.com)> >> > wrote: >> > > Hi, the vote has passed with the following result: >> > > >> > > +1 (binding): >> > > >> > > Pierre De Rop >> > > David Bosschaert >> > > Stuart McCulloch >> > > >> > > +1 (not binding): >> > > >> > > Stefan Seifart, Jean-Baptiste Onofré, Jamie Goodyear. >> > > >> > > I will promote. PMC members, one of you has to put the source into the >> > > distro area, I cannot. >> > > >> > > >> > > >> > > On Wed, Nov 11, 2015 at 1:14 PM, Pierre De Rop > > > (mailto:pierre.de...@gmail.com)> >> > wrote: >> > > > Hello Benson, >> > > > >> > > > I was about to vote: +1 >> > > > >> > > > regards; >> > > > /Pierre >> > > > >> > > > On Wed, Nov 11, 2015 at 7:12 PM, Benson Margulies < >> > bimargul...@gmail.com (mailto:bimargul...@gmail.com)> >> > > > wrote: >> > > > >> > > > > We are still one PMC vote short here. >> > > > > >> > > > > On Tue, Nov 10, 2015 at 7:13 PM, Jamie G. > > > > > (mailto:jamie.goody...@gmail.com)> >> > > > > wrote: >> > > > > > +1 (non-binding) >> > > > > > >> > > > > > On Tue, Nov 10, 2015 at 11:50 AM, Benson Margulies >> > > > > > mailto:bimargul...@gmail.com)> wrote: >> > > > > > > Thank You. Perhaps I will change that doc page to mention that a >> > > > > > > PMC >> > > > > > > member might be required. >> > > > > > > >> > > > > > > On Tue, Nov 10, 2015 at 7:30 AM, Stuart McCulloch < >> > mccu...@gmail.com (mailto:mccu...@gmail.com)> >> > > > > wrote: >> > > > > > > > No worries, I’ve just added your key and confirmed it matches >> > > > > > > > the >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > >> > > >> > >> > one >>
Re: [RESULT] [VOTE] Release Apache Maven Bundle Plugin version 3.0.1
I'll send the announcement when I get word that someone has committed the release package to the dist area. On Wed, Nov 11, 2015 at 1:22 PM, Benson Margulies wrote: > Hi, the vote has passed with the following result: > > +1 (binding): > > Pierre De Rop > David Bosschaert > Stuart McCulloch > > +1 (not binding): > > Stefan Seifart, Jean-Baptiste Onofré, Jamie Goodyear. > > I will promote. PMC members, one of you has to put the source into the > distro area, I cannot. > > > > On Wed, Nov 11, 2015 at 1:14 PM, Pierre De Rop wrote: >> Hello Benson, >> >> I was about to vote: +1 >> >> regards; >> /Pierre >> >> On Wed, Nov 11, 2015 at 7:12 PM, Benson Margulies >> wrote: >> >>> We are still one PMC vote short here. >>> >>> On Tue, Nov 10, 2015 at 7:13 PM, Jamie G. >>> wrote: >>> > +1 (non-binding) >>> > >>> > On Tue, Nov 10, 2015 at 11:50 AM, Benson Margulies >>> > wrote: >>> >> Thank You. Perhaps I will change that doc page to mention that a PMC >>> >> member might be required. >>> >> >>> >> On Tue, Nov 10, 2015 at 7:30 AM, Stuart McCulloch >>> wrote: >>> >>> No worries, I’ve just added your key and confirmed it matches the one >>> used to sign the artifacts >>> >>> >>> >>> On Tuesday, 10 November 2015 at 12:15, Benson Margulies wrote: >>> >>> >>> >>>> No can do with the signature. As a mere committer, I can't commit to >>> >>>> the dist area. Only PMC members can do that. >>> >>>> >>> >>>> -BEGIN PGP PUBLIC KEY BLOCK- >>> >>>> Version: GnuPG v1 >>> >>>> >>> >>>> mQINBEzDDl0BEADHvJW2uff8vfxbfy0IvNOK4aytU+HVEvKEmuSqYEzC8i3BF6RT >>> >>>> LOxTeRFlu92rYz5ypD0mdNCzQaH0xbkcjialP6FpPCByrM9fFv6hmxZFSY71rvqz >>> >>>> Aw606I0t9rt94wc6p5Rl8NIso4rbFp2VQeu9hiydtyc5b6xh5mcCb2tYuihfByuL >>> >>>> ozt0ZWHDk1tZJk/XhSDVZ84jHrWRY2zSa2laIxH+KnJFto8BkTxQgrwEL1ipzoJr >>> >>>> n3DMIWOtWQR7hdSGWA/V+FgA4I7HXMXVrxolt5FesiWUXkZ7mVjglExv6Mwmf48V >>> >>>> TFfx46fz8vO6q93XQV705p2Csam78tvAMNYkJs2xZ9iaFIE8ET2cMgPie9yXlqTL >>> >>>> JGFRoFnTDM4HVW2hU6DsS7OAv0TjxZ94VPElrIrp7sK8MMe9+3qkTQkvUvLmbDOH >>> >>>> +i0LBw3ULKrod1oNe9VU8wyBBOaB5WqCfdjMWQoNb0IbgTXOyRRfO7YgA+KTtta1 >>> >>>> H91I8x15aW1ofnEjYDvrXmaScCVMJcaas/62XjlKlmwGJMcS69pVRlxdKGLjBDA4 >>> >>>> dg5gnZ+O/L792UwHOjuuqU3ix65xQ1t9Xrw5QsvTEhHLmbaJIrK9cT0UYvtUR/em >>> >>>> LJ7uVQOjL0PLnFGwntc0B0JldWT11oAtOV1rHgTrRn+HQzC6bTxx6eQlYQARAQAB >>> >>>> tClCZW5zb24gTWFyZ3VsaWVzIDxiaW1hcmd1bGllc0BhcGFjaGUub3JnPokCNwQT >>> >>>> AQoAIQUCTMMOXQIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRCcT36dmLHM >>> >>>> U2/KEACGKZVYVaSarUBdnZGpkgBEcdVxQulcPuAO6cK8omLesMJ365XFsFsWkDQY >>> >>>> TaOMsmoeuuhZw4IHf5M99BT0hPctdRAlrR5x2amWyOWrYUvutPVUrVFtC9W1tPn4 >>> >>>> VVf50r3hxrwIkNY5Ib7ynyCZL4N/4ExazvsRmKnu6KALvqcmyBZPal1MLaICo1k3 >>> >>>> wVJ8KCE84oja4BPgF4hDMrOh1JKEYtjaowCIJRZEZ29sBbkX1fEDl9c6Z78U37KT >>> >>>> 3asaPqS13CGsapQ99b9LrBVqXpbmZ+y3SwU+G8TU5RnitRUF9T9+JYD6jHgUM344 >>> >>>> qeAE8TMsd4C2n5cfEaAiwVuQ0u2ulxlw1VjUC3NaycSHcoPOehYdlD3IFE1QmwwA >>> >>>> XLbLVeCd27RxJ9+kLHsijdHUtwIaqmyC+qBXGof+NikpA+UHA1kgbW8MFgb1QRYN >>> >>>> DJWFQdIgB6H43pW7KxKT2fULYCUeOvt8nST+4X/YZwclAw5Cets2vtVcLvS5BdGz >>> >>>> +ANOyppjKH7DzWzYtnamMdS24i50zQu97vtaoijT3f4wW+dMP+mlusQ651+9rCcz >>> >>>> TXHYkHg9lKw9hy+jdphJPVTMH+QDkcJSsDFpi7k53iLHFcf2YwqK1BiYKoJXd6GH >>> >>>> FbjybE6c8nNfPywzhSKpM34UNY8EV/14sDonjBLQLnr4Z3NrWLkCDQRMww5dARAA >>> >>>> 9qZSA8fGWEppVjhJcJ7oFPzSeAEFeU0z/lASN6E6AaV75n63eQgx00s//2s+ty99 >>> >>>> tqp7a5giIhbSaH1EHQ71xBGalXBirWJnCf5/OkYIgoZUWovveNQHGANXjh6qKfwy >>> >>>> qe9SmWnMn28146LNXKxU/YO+UyYy1AC+0R/Woe5funUmv7db6q/y/+KC9Wbmue+M >>> >>>> HtAbFqDf07Gvp4rSNeSY97jki6dl9bfS5d/ofcvziBM4KCgalGaxTvYT6UI11i03 >>> >>>> YnW57WjtOstIZuJ1q1f8CC3OzTHRMwzoxLKmkfKXzEBxz9eM3fk3zYA6OTdSTOWl >>> >>>> 0akvAiPr2CW4pr3MvwHYw9wEAqWJwadQmBDCCLhRlOzqD4WIJA1C3y7vYtxI2OWf >>> >>>> wiUqtIantAr296vsamuhoiNXAG+GlpYaKasKLr/s7kHcdpH5oD2DkdVUiZHB2xs1 >>> >>>> ZjlgpafG71wHDiNKlJokJ4nZpQOoyDCXEdzr5uOz4fJ5Du4PUg
Re: [RESULT] [VOTE] Release Apache Maven Bundle Plugin version 3.0.1
Hi, the vote has passed with the following result: +1 (binding): Pierre De Rop David Bosschaert Stuart McCulloch +1 (not binding): Stefan Seifart, Jean-Baptiste Onofré, Jamie Goodyear. I will promote. PMC members, one of you has to put the source into the distro area, I cannot. On Wed, Nov 11, 2015 at 1:14 PM, Pierre De Rop wrote: > Hello Benson, > > I was about to vote: +1 > > regards; > /Pierre > > On Wed, Nov 11, 2015 at 7:12 PM, Benson Margulies > wrote: > >> We are still one PMC vote short here. >> >> On Tue, Nov 10, 2015 at 7:13 PM, Jamie G. >> wrote: >> > +1 (non-binding) >> > >> > On Tue, Nov 10, 2015 at 11:50 AM, Benson Margulies >> > wrote: >> >> Thank You. Perhaps I will change that doc page to mention that a PMC >> >> member might be required. >> >> >> >> On Tue, Nov 10, 2015 at 7:30 AM, Stuart McCulloch >> wrote: >> >>> No worries, I’ve just added your key and confirmed it matches the one >> used to sign the artifacts >> >>> >> >>> On Tuesday, 10 November 2015 at 12:15, Benson Margulies wrote: >> >>> >> >>>> No can do with the signature. As a mere committer, I can't commit to >> >>>> the dist area. Only PMC members can do that. >> >>>> >> >>>> -BEGIN PGP PUBLIC KEY BLOCK- >> >>>> Version: GnuPG v1 >> >>>> >> >>>> mQINBEzDDl0BEADHvJW2uff8vfxbfy0IvNOK4aytU+HVEvKEmuSqYEzC8i3BF6RT >> >>>> LOxTeRFlu92rYz5ypD0mdNCzQaH0xbkcjialP6FpPCByrM9fFv6hmxZFSY71rvqz >> >>>> Aw606I0t9rt94wc6p5Rl8NIso4rbFp2VQeu9hiydtyc5b6xh5mcCb2tYuihfByuL >> >>>> ozt0ZWHDk1tZJk/XhSDVZ84jHrWRY2zSa2laIxH+KnJFto8BkTxQgrwEL1ipzoJr >> >>>> n3DMIWOtWQR7hdSGWA/V+FgA4I7HXMXVrxolt5FesiWUXkZ7mVjglExv6Mwmf48V >> >>>> TFfx46fz8vO6q93XQV705p2Csam78tvAMNYkJs2xZ9iaFIE8ET2cMgPie9yXlqTL >> >>>> JGFRoFnTDM4HVW2hU6DsS7OAv0TjxZ94VPElrIrp7sK8MMe9+3qkTQkvUvLmbDOH >> >>>> +i0LBw3ULKrod1oNe9VU8wyBBOaB5WqCfdjMWQoNb0IbgTXOyRRfO7YgA+KTtta1 >> >>>> H91I8x15aW1ofnEjYDvrXmaScCVMJcaas/62XjlKlmwGJMcS69pVRlxdKGLjBDA4 >> >>>> dg5gnZ+O/L792UwHOjuuqU3ix65xQ1t9Xrw5QsvTEhHLmbaJIrK9cT0UYvtUR/em >> >>>> LJ7uVQOjL0PLnFGwntc0B0JldWT11oAtOV1rHgTrRn+HQzC6bTxx6eQlYQARAQAB >> >>>> tClCZW5zb24gTWFyZ3VsaWVzIDxiaW1hcmd1bGllc0BhcGFjaGUub3JnPokCNwQT >> >>>> AQoAIQUCTMMOXQIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRCcT36dmLHM >> >>>> U2/KEACGKZVYVaSarUBdnZGpkgBEcdVxQulcPuAO6cK8omLesMJ365XFsFsWkDQY >> >>>> TaOMsmoeuuhZw4IHf5M99BT0hPctdRAlrR5x2amWyOWrYUvutPVUrVFtC9W1tPn4 >> >>>> VVf50r3hxrwIkNY5Ib7ynyCZL4N/4ExazvsRmKnu6KALvqcmyBZPal1MLaICo1k3 >> >>>> wVJ8KCE84oja4BPgF4hDMrOh1JKEYtjaowCIJRZEZ29sBbkX1fEDl9c6Z78U37KT >> >>>> 3asaPqS13CGsapQ99b9LrBVqXpbmZ+y3SwU+G8TU5RnitRUF9T9+JYD6jHgUM344 >> >>>> qeAE8TMsd4C2n5cfEaAiwVuQ0u2ulxlw1VjUC3NaycSHcoPOehYdlD3IFE1QmwwA >> >>>> XLbLVeCd27RxJ9+kLHsijdHUtwIaqmyC+qBXGof+NikpA+UHA1kgbW8MFgb1QRYN >> >>>> DJWFQdIgB6H43pW7KxKT2fULYCUeOvt8nST+4X/YZwclAw5Cets2vtVcLvS5BdGz >> >>>> +ANOyppjKH7DzWzYtnamMdS24i50zQu97vtaoijT3f4wW+dMP+mlusQ651+9rCcz >> >>>> TXHYkHg9lKw9hy+jdphJPVTMH+QDkcJSsDFpi7k53iLHFcf2YwqK1BiYKoJXd6GH >> >>>> FbjybE6c8nNfPywzhSKpM34UNY8EV/14sDonjBLQLnr4Z3NrWLkCDQRMww5dARAA >> >>>> 9qZSA8fGWEppVjhJcJ7oFPzSeAEFeU0z/lASN6E6AaV75n63eQgx00s//2s+ty99 >> >>>> tqp7a5giIhbSaH1EHQ71xBGalXBirWJnCf5/OkYIgoZUWovveNQHGANXjh6qKfwy >> >>>> qe9SmWnMn28146LNXKxU/YO+UyYy1AC+0R/Woe5funUmv7db6q/y/+KC9Wbmue+M >> >>>> HtAbFqDf07Gvp4rSNeSY97jki6dl9bfS5d/ofcvziBM4KCgalGaxTvYT6UI11i03 >> >>>> YnW57WjtOstIZuJ1q1f8CC3OzTHRMwzoxLKmkfKXzEBxz9eM3fk3zYA6OTdSTOWl >> >>>> 0akvAiPr2CW4pr3MvwHYw9wEAqWJwadQmBDCCLhRlOzqD4WIJA1C3y7vYtxI2OWf >> >>>> wiUqtIantAr296vsamuhoiNXAG+GlpYaKasKLr/s7kHcdpH5oD2DkdVUiZHB2xs1 >> >>>> ZjlgpafG71wHDiNKlJokJ4nZpQOoyDCXEdzr5uOz4fJ5Du4PUgG5y74Cu1JHZ0uJ >> >>>> Le65D+MT2TmmiFeQHhT9Txdk2AVgf5uQjHDcIAvMI0niehT+l3zZ4YtRBviRksG4 >> >>>> 349OecTu+33JoJGqtYnOcuPUR8HBB2dQrPK/l47SUg6esF5duznU4XkNskvbBWu3 >> >>>> 2aiakTz7XiDm0TEzWtBS/hMRIeH4IyjNux8CwEJfV/MAEQEAAYkCHwQYAQoACQUC >> >>>> TMMOXQIbDAAKCRCcT36dmLHMU2u/D/4umQeJcH06a2aM2ETXNVqDK29yti1tCSqs >> >>>> 0jsZivZrK+O+oxqvTzcocYtQ2Fb8WjexGpQ41wN5zocH85cCPD+UisziV4r0NQYK >> >>>> p1
Re: [VOTE] Release Apache Maven Bundle Plugin version 3.0.1
We are still one PMC vote short here. On Tue, Nov 10, 2015 at 7:13 PM, Jamie G. wrote: > +1 (non-binding) > > On Tue, Nov 10, 2015 at 11:50 AM, Benson Margulies > wrote: >> Thank You. Perhaps I will change that doc page to mention that a PMC >> member might be required. >> >> On Tue, Nov 10, 2015 at 7:30 AM, Stuart McCulloch wrote: >>> No worries, I’ve just added your key and confirmed it matches the one used >>> to sign the artifacts >>> >>> On Tuesday, 10 November 2015 at 12:15, Benson Margulies wrote: >>> >>>> No can do with the signature. As a mere committer, I can't commit to >>>> the dist area. Only PMC members can do that. >>>> >>>> -BEGIN PGP PUBLIC KEY BLOCK- >>>> Version: GnuPG v1 >>>> >>>> mQINBEzDDl0BEADHvJW2uff8vfxbfy0IvNOK4aytU+HVEvKEmuSqYEzC8i3BF6RT >>>> LOxTeRFlu92rYz5ypD0mdNCzQaH0xbkcjialP6FpPCByrM9fFv6hmxZFSY71rvqz >>>> Aw606I0t9rt94wc6p5Rl8NIso4rbFp2VQeu9hiydtyc5b6xh5mcCb2tYuihfByuL >>>> ozt0ZWHDk1tZJk/XhSDVZ84jHrWRY2zSa2laIxH+KnJFto8BkTxQgrwEL1ipzoJr >>>> n3DMIWOtWQR7hdSGWA/V+FgA4I7HXMXVrxolt5FesiWUXkZ7mVjglExv6Mwmf48V >>>> TFfx46fz8vO6q93XQV705p2Csam78tvAMNYkJs2xZ9iaFIE8ET2cMgPie9yXlqTL >>>> JGFRoFnTDM4HVW2hU6DsS7OAv0TjxZ94VPElrIrp7sK8MMe9+3qkTQkvUvLmbDOH >>>> +i0LBw3ULKrod1oNe9VU8wyBBOaB5WqCfdjMWQoNb0IbgTXOyRRfO7YgA+KTtta1 >>>> H91I8x15aW1ofnEjYDvrXmaScCVMJcaas/62XjlKlmwGJMcS69pVRlxdKGLjBDA4 >>>> dg5gnZ+O/L792UwHOjuuqU3ix65xQ1t9Xrw5QsvTEhHLmbaJIrK9cT0UYvtUR/em >>>> LJ7uVQOjL0PLnFGwntc0B0JldWT11oAtOV1rHgTrRn+HQzC6bTxx6eQlYQARAQAB >>>> tClCZW5zb24gTWFyZ3VsaWVzIDxiaW1hcmd1bGllc0BhcGFjaGUub3JnPokCNwQT >>>> AQoAIQUCTMMOXQIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRCcT36dmLHM >>>> U2/KEACGKZVYVaSarUBdnZGpkgBEcdVxQulcPuAO6cK8omLesMJ365XFsFsWkDQY >>>> TaOMsmoeuuhZw4IHf5M99BT0hPctdRAlrR5x2amWyOWrYUvutPVUrVFtC9W1tPn4 >>>> VVf50r3hxrwIkNY5Ib7ynyCZL4N/4ExazvsRmKnu6KALvqcmyBZPal1MLaICo1k3 >>>> wVJ8KCE84oja4BPgF4hDMrOh1JKEYtjaowCIJRZEZ29sBbkX1fEDl9c6Z78U37KT >>>> 3asaPqS13CGsapQ99b9LrBVqXpbmZ+y3SwU+G8TU5RnitRUF9T9+JYD6jHgUM344 >>>> qeAE8TMsd4C2n5cfEaAiwVuQ0u2ulxlw1VjUC3NaycSHcoPOehYdlD3IFE1QmwwA >>>> XLbLVeCd27RxJ9+kLHsijdHUtwIaqmyC+qBXGof+NikpA+UHA1kgbW8MFgb1QRYN >>>> DJWFQdIgB6H43pW7KxKT2fULYCUeOvt8nST+4X/YZwclAw5Cets2vtVcLvS5BdGz >>>> +ANOyppjKH7DzWzYtnamMdS24i50zQu97vtaoijT3f4wW+dMP+mlusQ651+9rCcz >>>> TXHYkHg9lKw9hy+jdphJPVTMH+QDkcJSsDFpi7k53iLHFcf2YwqK1BiYKoJXd6GH >>>> FbjybE6c8nNfPywzhSKpM34UNY8EV/14sDonjBLQLnr4Z3NrWLkCDQRMww5dARAA >>>> 9qZSA8fGWEppVjhJcJ7oFPzSeAEFeU0z/lASN6E6AaV75n63eQgx00s//2s+ty99 >>>> tqp7a5giIhbSaH1EHQ71xBGalXBirWJnCf5/OkYIgoZUWovveNQHGANXjh6qKfwy >>>> qe9SmWnMn28146LNXKxU/YO+UyYy1AC+0R/Woe5funUmv7db6q/y/+KC9Wbmue+M >>>> HtAbFqDf07Gvp4rSNeSY97jki6dl9bfS5d/ofcvziBM4KCgalGaxTvYT6UI11i03 >>>> YnW57WjtOstIZuJ1q1f8CC3OzTHRMwzoxLKmkfKXzEBxz9eM3fk3zYA6OTdSTOWl >>>> 0akvAiPr2CW4pr3MvwHYw9wEAqWJwadQmBDCCLhRlOzqD4WIJA1C3y7vYtxI2OWf >>>> wiUqtIantAr296vsamuhoiNXAG+GlpYaKasKLr/s7kHcdpH5oD2DkdVUiZHB2xs1 >>>> ZjlgpafG71wHDiNKlJokJ4nZpQOoyDCXEdzr5uOz4fJ5Du4PUgG5y74Cu1JHZ0uJ >>>> Le65D+MT2TmmiFeQHhT9Txdk2AVgf5uQjHDcIAvMI0niehT+l3zZ4YtRBviRksG4 >>>> 349OecTu+33JoJGqtYnOcuPUR8HBB2dQrPK/l47SUg6esF5duznU4XkNskvbBWu3 >>>> 2aiakTz7XiDm0TEzWtBS/hMRIeH4IyjNux8CwEJfV/MAEQEAAYkCHwQYAQoACQUC >>>> TMMOXQIbDAAKCRCcT36dmLHMU2u/D/4umQeJcH06a2aM2ETXNVqDK29yti1tCSqs >>>> 0jsZivZrK+O+oxqvTzcocYtQ2Fb8WjexGpQ41wN5zocH85cCPD+UisziV4r0NQYK >>>> p1FhAJfkacIR4EtuEQrH2J7m4IDUXSqTW1jv36lXrAO/5ON07Wy3AROoJdFwrtO8 >>>> ja0jX7Z+pe6OaLmptGSFeANSXN6r4CdGYtLh3s5Srf9++WTl+llMLEMfwbAHPSXt >>>> NV7zoq8j1UwI444W9C4DnVNBiku1e42pQUFt3BtEg22mW/1RdhOHUsisxE3hyUtN >>>> E2zCpu7Un5aedt5W72WozbAb0LPlUx/0fXyPLFNQmBMHeMVnxZb7CvraBo6BGHL4 >>>> karbJBX2p+5s05/g8t5ljPbfakGNcUZRqbCk1neOQZYOiW8vI1FBbwGWiFWTISHQ >>>> d+uj/eQTWiQsz4+e3PAVZ4ekDYAMS1HLLXaBwxr7MHRIHRVVKJI8mFbI9HfGKpPt >>>> HDx+C47QkbQgPu1YL85g5mHkoP621r79zyGjW35HS2l4TCnUZ3q+WLvLMLpIsYcW >>>> YNBshwOavdSYmk9lCSSCtilTjl1e0E4WOGtusJKpmkAphOkjFKttCE6Z0mSHenLP >>>> numenORuE0/O7DgoihMrYzTTaRBkHLssIzfaPu96jcWjU9dhuxFW5AktUshr2RLw >>>> EaWfWeQZ4Q== >>>> =b8+3 >>>> -END PGP PUBLIC KEY BLOCK- >>>> >>>> On Tue, Nov 10, 2015 at 6:37 AM, Stuart McCulloch >>> (mailto:mccu...@gmail.com)> wrote: >>>> > +1 verified with a couple of local projects, source release looks good >>>>
Re: [VOTE] Release Apache Maven Bundle Plugin version 3.0.1
Thank You. Perhaps I will change that doc page to mention that a PMC member might be required. On Tue, Nov 10, 2015 at 7:30 AM, Stuart McCulloch wrote: > No worries, I’ve just added your key and confirmed it matches the one used to > sign the artifacts > > On Tuesday, 10 November 2015 at 12:15, Benson Margulies wrote: > >> No can do with the signature. As a mere committer, I can't commit to >> the dist area. Only PMC members can do that. >> >> -BEGIN PGP PUBLIC KEY BLOCK- >> Version: GnuPG v1 >> >> mQINBEzDDl0BEADHvJW2uff8vfxbfy0IvNOK4aytU+HVEvKEmuSqYEzC8i3BF6RT >> LOxTeRFlu92rYz5ypD0mdNCzQaH0xbkcjialP6FpPCByrM9fFv6hmxZFSY71rvqz >> Aw606I0t9rt94wc6p5Rl8NIso4rbFp2VQeu9hiydtyc5b6xh5mcCb2tYuihfByuL >> ozt0ZWHDk1tZJk/XhSDVZ84jHrWRY2zSa2laIxH+KnJFto8BkTxQgrwEL1ipzoJr >> n3DMIWOtWQR7hdSGWA/V+FgA4I7HXMXVrxolt5FesiWUXkZ7mVjglExv6Mwmf48V >> TFfx46fz8vO6q93XQV705p2Csam78tvAMNYkJs2xZ9iaFIE8ET2cMgPie9yXlqTL >> JGFRoFnTDM4HVW2hU6DsS7OAv0TjxZ94VPElrIrp7sK8MMe9+3qkTQkvUvLmbDOH >> +i0LBw3ULKrod1oNe9VU8wyBBOaB5WqCfdjMWQoNb0IbgTXOyRRfO7YgA+KTtta1 >> H91I8x15aW1ofnEjYDvrXmaScCVMJcaas/62XjlKlmwGJMcS69pVRlxdKGLjBDA4 >> dg5gnZ+O/L792UwHOjuuqU3ix65xQ1t9Xrw5QsvTEhHLmbaJIrK9cT0UYvtUR/em >> LJ7uVQOjL0PLnFGwntc0B0JldWT11oAtOV1rHgTrRn+HQzC6bTxx6eQlYQARAQAB >> tClCZW5zb24gTWFyZ3VsaWVzIDxiaW1hcmd1bGllc0BhcGFjaGUub3JnPokCNwQT >> AQoAIQUCTMMOXQIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRCcT36dmLHM >> U2/KEACGKZVYVaSarUBdnZGpkgBEcdVxQulcPuAO6cK8omLesMJ365XFsFsWkDQY >> TaOMsmoeuuhZw4IHf5M99BT0hPctdRAlrR5x2amWyOWrYUvutPVUrVFtC9W1tPn4 >> VVf50r3hxrwIkNY5Ib7ynyCZL4N/4ExazvsRmKnu6KALvqcmyBZPal1MLaICo1k3 >> wVJ8KCE84oja4BPgF4hDMrOh1JKEYtjaowCIJRZEZ29sBbkX1fEDl9c6Z78U37KT >> 3asaPqS13CGsapQ99b9LrBVqXpbmZ+y3SwU+G8TU5RnitRUF9T9+JYD6jHgUM344 >> qeAE8TMsd4C2n5cfEaAiwVuQ0u2ulxlw1VjUC3NaycSHcoPOehYdlD3IFE1QmwwA >> XLbLVeCd27RxJ9+kLHsijdHUtwIaqmyC+qBXGof+NikpA+UHA1kgbW8MFgb1QRYN >> DJWFQdIgB6H43pW7KxKT2fULYCUeOvt8nST+4X/YZwclAw5Cets2vtVcLvS5BdGz >> +ANOyppjKH7DzWzYtnamMdS24i50zQu97vtaoijT3f4wW+dMP+mlusQ651+9rCcz >> TXHYkHg9lKw9hy+jdphJPVTMH+QDkcJSsDFpi7k53iLHFcf2YwqK1BiYKoJXd6GH >> FbjybE6c8nNfPywzhSKpM34UNY8EV/14sDonjBLQLnr4Z3NrWLkCDQRMww5dARAA >> 9qZSA8fGWEppVjhJcJ7oFPzSeAEFeU0z/lASN6E6AaV75n63eQgx00s//2s+ty99 >> tqp7a5giIhbSaH1EHQ71xBGalXBirWJnCf5/OkYIgoZUWovveNQHGANXjh6qKfwy >> qe9SmWnMn28146LNXKxU/YO+UyYy1AC+0R/Woe5funUmv7db6q/y/+KC9Wbmue+M >> HtAbFqDf07Gvp4rSNeSY97jki6dl9bfS5d/ofcvziBM4KCgalGaxTvYT6UI11i03 >> YnW57WjtOstIZuJ1q1f8CC3OzTHRMwzoxLKmkfKXzEBxz9eM3fk3zYA6OTdSTOWl >> 0akvAiPr2CW4pr3MvwHYw9wEAqWJwadQmBDCCLhRlOzqD4WIJA1C3y7vYtxI2OWf >> wiUqtIantAr296vsamuhoiNXAG+GlpYaKasKLr/s7kHcdpH5oD2DkdVUiZHB2xs1 >> ZjlgpafG71wHDiNKlJokJ4nZpQOoyDCXEdzr5uOz4fJ5Du4PUgG5y74Cu1JHZ0uJ >> Le65D+MT2TmmiFeQHhT9Txdk2AVgf5uQjHDcIAvMI0niehT+l3zZ4YtRBviRksG4 >> 349OecTu+33JoJGqtYnOcuPUR8HBB2dQrPK/l47SUg6esF5duznU4XkNskvbBWu3 >> 2aiakTz7XiDm0TEzWtBS/hMRIeH4IyjNux8CwEJfV/MAEQEAAYkCHwQYAQoACQUC >> TMMOXQIbDAAKCRCcT36dmLHMU2u/D/4umQeJcH06a2aM2ETXNVqDK29yti1tCSqs >> 0jsZivZrK+O+oxqvTzcocYtQ2Fb8WjexGpQ41wN5zocH85cCPD+UisziV4r0NQYK >> p1FhAJfkacIR4EtuEQrH2J7m4IDUXSqTW1jv36lXrAO/5ON07Wy3AROoJdFwrtO8 >> ja0jX7Z+pe6OaLmptGSFeANSXN6r4CdGYtLh3s5Srf9++WTl+llMLEMfwbAHPSXt >> NV7zoq8j1UwI444W9C4DnVNBiku1e42pQUFt3BtEg22mW/1RdhOHUsisxE3hyUtN >> E2zCpu7Un5aedt5W72WozbAb0LPlUx/0fXyPLFNQmBMHeMVnxZb7CvraBo6BGHL4 >> karbJBX2p+5s05/g8t5ljPbfakGNcUZRqbCk1neOQZYOiW8vI1FBbwGWiFWTISHQ >> d+uj/eQTWiQsz4+e3PAVZ4ekDYAMS1HLLXaBwxr7MHRIHRVVKJI8mFbI9HfGKpPt >> HDx+C47QkbQgPu1YL85g5mHkoP621r79zyGjW35HS2l4TCnUZ3q+WLvLMLpIsYcW >> YNBshwOavdSYmk9lCSSCtilTjl1e0E4WOGtusJKpmkAphOkjFKttCE6Z0mSHenLP >> numenORuE0/O7DgoihMrYzTTaRBkHLssIzfaPu96jcWjU9dhuxFW5AktUshr2RLw >> EaWfWeQZ4Q== >> =b8+3 >> -END PGP PUBLIC KEY BLOCK- >> >> On Tue, Nov 10, 2015 at 6:37 AM, Stuart McCulloch > (mailto:mccu...@gmail.com)> wrote: >> > +1 verified with a couple of local projects, source release looks good >> > >> > Remember to add your public key to http://www.apache.org/dist/felix/KEYS: >> > >> > http://felix.apache.org/documentation/development/release-management-nexus.html#appendix-a-create-and-add-your-key-to-httpwwwapacheorgdistfelixkeys >> > >> > -- >> > Cheers, Stuart >> > >> > >> > On Monday, 9 November 2015 at 11:44, Benson Margulies wrote: >> > >> > > Hi, >> > > >> > > We solved 3 issues: >> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12333631&styleName=Text&projectId=12310100&Create=Create&atl_token=A5KQ-2QAV-T4JA-FDED%7C0a2bd62f03263e903089dc8
Re: Need access to manage versions in svn
PING! Please? I really want to fix this before I publish the bundle plugin release. On Mon, Nov 9, 2015 at 6:37 AM, Benson Margulies wrote: > I don't seem to have access to manage versions, and people have been > marking JIRAs as fixed for 3.0.2 instead of 3.0.1. I am going to cheat > to send out a vote, but I will fix up JIRA as soon as I have access.
Re: [VOTE] Release Apache Maven Bundle Plugin version 3.0.1
No can do with the signature. As a mere committer, I can't commit to the dist area. Only PMC members can do that. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQINBEzDDl0BEADHvJW2uff8vfxbfy0IvNOK4aytU+HVEvKEmuSqYEzC8i3BF6RT LOxTeRFlu92rYz5ypD0mdNCzQaH0xbkcjialP6FpPCByrM9fFv6hmxZFSY71rvqz Aw606I0t9rt94wc6p5Rl8NIso4rbFp2VQeu9hiydtyc5b6xh5mcCb2tYuihfByuL ozt0ZWHDk1tZJk/XhSDVZ84jHrWRY2zSa2laIxH+KnJFto8BkTxQgrwEL1ipzoJr n3DMIWOtWQR7hdSGWA/V+FgA4I7HXMXVrxolt5FesiWUXkZ7mVjglExv6Mwmf48V TFfx46fz8vO6q93XQV705p2Csam78tvAMNYkJs2xZ9iaFIE8ET2cMgPie9yXlqTL JGFRoFnTDM4HVW2hU6DsS7OAv0TjxZ94VPElrIrp7sK8MMe9+3qkTQkvUvLmbDOH +i0LBw3ULKrod1oNe9VU8wyBBOaB5WqCfdjMWQoNb0IbgTXOyRRfO7YgA+KTtta1 H91I8x15aW1ofnEjYDvrXmaScCVMJcaas/62XjlKlmwGJMcS69pVRlxdKGLjBDA4 dg5gnZ+O/L792UwHOjuuqU3ix65xQ1t9Xrw5QsvTEhHLmbaJIrK9cT0UYvtUR/em LJ7uVQOjL0PLnFGwntc0B0JldWT11oAtOV1rHgTrRn+HQzC6bTxx6eQlYQARAQAB tClCZW5zb24gTWFyZ3VsaWVzIDxiaW1hcmd1bGllc0BhcGFjaGUub3JnPokCNwQT AQoAIQUCTMMOXQIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRCcT36dmLHM U2/KEACGKZVYVaSarUBdnZGpkgBEcdVxQulcPuAO6cK8omLesMJ365XFsFsWkDQY TaOMsmoeuuhZw4IHf5M99BT0hPctdRAlrR5x2amWyOWrYUvutPVUrVFtC9W1tPn4 VVf50r3hxrwIkNY5Ib7ynyCZL4N/4ExazvsRmKnu6KALvqcmyBZPal1MLaICo1k3 wVJ8KCE84oja4BPgF4hDMrOh1JKEYtjaowCIJRZEZ29sBbkX1fEDl9c6Z78U37KT 3asaPqS13CGsapQ99b9LrBVqXpbmZ+y3SwU+G8TU5RnitRUF9T9+JYD6jHgUM344 qeAE8TMsd4C2n5cfEaAiwVuQ0u2ulxlw1VjUC3NaycSHcoPOehYdlD3IFE1QmwwA XLbLVeCd27RxJ9+kLHsijdHUtwIaqmyC+qBXGof+NikpA+UHA1kgbW8MFgb1QRYN DJWFQdIgB6H43pW7KxKT2fULYCUeOvt8nST+4X/YZwclAw5Cets2vtVcLvS5BdGz +ANOyppjKH7DzWzYtnamMdS24i50zQu97vtaoijT3f4wW+dMP+mlusQ651+9rCcz TXHYkHg9lKw9hy+jdphJPVTMH+QDkcJSsDFpi7k53iLHFcf2YwqK1BiYKoJXd6GH FbjybE6c8nNfPywzhSKpM34UNY8EV/14sDonjBLQLnr4Z3NrWLkCDQRMww5dARAA 9qZSA8fGWEppVjhJcJ7oFPzSeAEFeU0z/lASN6E6AaV75n63eQgx00s//2s+ty99 tqp7a5giIhbSaH1EHQ71xBGalXBirWJnCf5/OkYIgoZUWovveNQHGANXjh6qKfwy qe9SmWnMn28146LNXKxU/YO+UyYy1AC+0R/Woe5funUmv7db6q/y/+KC9Wbmue+M HtAbFqDf07Gvp4rSNeSY97jki6dl9bfS5d/ofcvziBM4KCgalGaxTvYT6UI11i03 YnW57WjtOstIZuJ1q1f8CC3OzTHRMwzoxLKmkfKXzEBxz9eM3fk3zYA6OTdSTOWl 0akvAiPr2CW4pr3MvwHYw9wEAqWJwadQmBDCCLhRlOzqD4WIJA1C3y7vYtxI2OWf wiUqtIantAr296vsamuhoiNXAG+GlpYaKasKLr/s7kHcdpH5oD2DkdVUiZHB2xs1 ZjlgpafG71wHDiNKlJokJ4nZpQOoyDCXEdzr5uOz4fJ5Du4PUgG5y74Cu1JHZ0uJ Le65D+MT2TmmiFeQHhT9Txdk2AVgf5uQjHDcIAvMI0niehT+l3zZ4YtRBviRksG4 349OecTu+33JoJGqtYnOcuPUR8HBB2dQrPK/l47SUg6esF5duznU4XkNskvbBWu3 2aiakTz7XiDm0TEzWtBS/hMRIeH4IyjNux8CwEJfV/MAEQEAAYkCHwQYAQoACQUC TMMOXQIbDAAKCRCcT36dmLHMU2u/D/4umQeJcH06a2aM2ETXNVqDK29yti1tCSqs 0jsZivZrK+O+oxqvTzcocYtQ2Fb8WjexGpQ41wN5zocH85cCPD+UisziV4r0NQYK p1FhAJfkacIR4EtuEQrH2J7m4IDUXSqTW1jv36lXrAO/5ON07Wy3AROoJdFwrtO8 ja0jX7Z+pe6OaLmptGSFeANSXN6r4CdGYtLh3s5Srf9++WTl+llMLEMfwbAHPSXt NV7zoq8j1UwI444W9C4DnVNBiku1e42pQUFt3BtEg22mW/1RdhOHUsisxE3hyUtN E2zCpu7Un5aedt5W72WozbAb0LPlUx/0fXyPLFNQmBMHeMVnxZb7CvraBo6BGHL4 karbJBX2p+5s05/g8t5ljPbfakGNcUZRqbCk1neOQZYOiW8vI1FBbwGWiFWTISHQ d+uj/eQTWiQsz4+e3PAVZ4ekDYAMS1HLLXaBwxr7MHRIHRVVKJI8mFbI9HfGKpPt HDx+C47QkbQgPu1YL85g5mHkoP621r79zyGjW35HS2l4TCnUZ3q+WLvLMLpIsYcW YNBshwOavdSYmk9lCSSCtilTjl1e0E4WOGtusJKpmkAphOkjFKttCE6Z0mSHenLP numenORuE0/O7DgoihMrYzTTaRBkHLssIzfaPu96jcWjU9dhuxFW5AktUshr2RLw EaWfWeQZ4Q== =b8+3 -END PGP PUBLIC KEY BLOCK- On Tue, Nov 10, 2015 at 6:37 AM, Stuart McCulloch wrote: > +1 verified with a couple of local projects, source release looks good > > Remember to add your public key to http://www.apache.org/dist/felix/KEYS: > > http://felix.apache.org/documentation/development/release-management-nexus.html#appendix-a-create-and-add-your-key-to-httpwwwapacheorgdistfelixkeys > > -- > Cheers, Stuart > > > On Monday, 9 November 2015 at 11:44, Benson Margulies wrote: > >> Hi, >> >> We solved 3 issues: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12333631&styleName=Text&projectId=12310100&Create=Create&atl_token=A5KQ-2QAV-T4JA-FDED%7C0a2bd62f03263e903089dc8019574717effb605c%7Clin >> >> There are still a couple of issues left in JIRA: >> https://issues.apache.org/jira/browse/FELIX-2322?jql=project%20%3D%20FELIX%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20%22Maven%20Bundle%20Plugin%22%20ORDER%20BY%20priority%20DESC >> >> Staging repo: >> https://repository.apache.org/content/repositories/orgapachefelix-1104 >> https://repository.apache.org/service/local/repositories/orgapachefelix-1104/content/org/apache/felix/maven-bundle-plugin/3.0.1/maven-bundle-plugin-3.0.1-source-release.tar.gz >> >> Source release checksum(s): >> [NAME-OF]-source-release.zip 08bac4ef6329c776b039a4cd28e7b6f4318aa3a3 >> >> Staging site: >> http://felix.apache.org/components/bundle-plugin-archives/bundle-plugin-LATEST/ >> >> Guide to testing staged releases: >> http://maven.apache.org/guides/development/guide-testing-releases.html >> >> Vote open for 72 hours. >> >> [ ] +1 >> [ ] +0 >> [ ] -1 >> >> > >
The name and version of the maven-bundle-plugin
I am preparing, at least mentally, to do to [1] to the maven-bundle-plugin -- to make it require Maven 3.x. So, you might think that I need to change the major version number. This, of course, would have the effect of de-syncing the versions from bnd versions. Maybe this doesn't bother anyone. On the other hand, there's this issue: in theory, names of the form maven-X-bundle are supposed to be reserved for the actual Apache Maven Project. I can't really imagine my Maven PMC fellow-members deciding to hassle another Apache project, but it _could_ be that a better name would be the felix-bundle-plugin. 'maven' in the artifact-id of a maven plugin hardly carries a ton of information. And we could set the version back to 1.0.0. Personally, I'd be happy to just bump the version to 4.0.0 and give up on mirroring bnd version numbers, but I felt compelled for some reason to offer the community the other idea. [1] https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies
Re: Roadmap for maven bundle plugin?
Is there an Embed-Dependency analog? On Nov 9, 2015 12:07 PM, "Konrad Windszus" wrote: > The biggest difference is that currently the bnd-maven-plugin does not > support instructions within pom files ( > https://github.com/bndtools/bnd/issues/952) but rather only in dedicated > bnd files. > Therefore for existing users of maven-bundle-plugin it is not so easy to > migrate. > Konrad > > > > On 09 Nov 2015, at 16:48, Jean-Baptiste Onofré wrote: > > > > Hi Christian, > > > > it sounds promising, but maybe a bit early to have a strong opinion. > > > > From a technology standpoint, it's good to converge. > > > > However, we talk about two different community there, and maybe license. > > As a tooling, it's not a big deal. > > > > Regards > > JB > > > > On 11/09/2015 11:02 AM, Christian Schneider wrote: > >> I recently looked into the bnd-maven-plugin from paremus. It features a > >> better maven lifecycle integration than the felix one. > >> So for example you do not need the packaging "bundle" anymore which is a > >> big obstacle for some projects. > >> It also will probably be part of the maven support for bdntools. > >> > >> So I wonder what the plans for the felix maven plugin are. Will we > >> follow that path and also provide a similar version? > >> Should we at some point recommend to users to switch? > >> > >> Christian > >> > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > >
Re: Roadmap for maven bundle plugin?
Is this the one that is 'owned' by the bndlib people, or are there more than one? The 'bnd' mailing list told me that it had less capability than the maven-bundle-plugin, so that would be a reason not to retire. I'll take on the lifecycle, but I'll make it a plugin that requires maven 3, first. That would raise an interesting version # question. On Mon, Nov 9, 2015 at 5:02 AM, Christian Schneider wrote: > I recently looked into the bnd-maven-plugin from paremus. It features a > better maven lifecycle integration than the felix one. > So for example you do not need the packaging "bundle" anymore which is a big > obstacle for some projects. > It also will probably be part of the maven support for bdntools. > > So I wonder what the plans for the felix maven plugin are. Will we follow > that path and also provide a similar version? > Should we at some point recommend to users to switch? > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
Re: git?
This thread has again quiesced. I respectfully submit that it's time for a PMC member to start a [VOTE] thread to see whether there is a decision to proceed. On Sat, Oct 24, 2015 at 2:51 PM, Benson Margulies wrote: > Greeting, Marcel, > > It's not my intention to try to talk anyone into changing how they > release anything. For the things that are built with Maven, it's my > preference to avoid exercising the maven-release-plugin's feature of > handling multiple released items in a repo, but it's just a > preference. If the acceptable compromise is to have less repos than > releasable items (possibly as few as one repo), I'd personally rather > do that than not move to git at all. > > regards, > > benson > > > On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans > wrote: >> On 24 October 2015 at 11:36:03, Benson Margulies >> (ben...@basistech.com(mailto:ben...@basistech.com)) wrote: >> >>> > So I would definitely argue against getting a Git repository per bundle. >>> > Per subproject sounds like the right granularity to me. >>> >>> If a subproject is released all at once, then we're completely >>> agreeing. If not, then your preference means exercising the >>> occasionally squishy part of the release plugin; maybe it will get >>> fixed once and for all. >> >> So for the dependency manager we reasoned as follows: >> >> 1) When talking about releases within Apache, we are talking about source >> code. Releasing that a subproject at a time makes sense to me as the code, >> even if it ends up in different bundles, clearly belongs together. >> >> 2) Binary releases are a matter of convenience and “what is convenient” >> depends a lot on where you’re coming from. A lot of people would argue that >> putting a binary in Maven is convenient, but there are definitely other >> options. The binary releases also don’t have to have a 1:1 mapping with the >> source, so we can have N bundles being put in Maven and other repositories >> all from the same source release. >> >> Greetings, Marcel >> >>
[VOTE] Release Apache Maven Bundle Plugin version 3.0.1
Hi, We solved 3 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12333631&styleName=Text&projectId=12310100&Create=Create&atl_token=A5KQ-2QAV-T4JA-FDED%7C0a2bd62f03263e903089dc8019574717effb605c%7Clin There are still a couple of issues left in JIRA: https://issues.apache.org/jira/browse/FELIX-2322?jql=project%20%3D%20FELIX%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20%22Maven%20Bundle%20Plugin%22%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/orgapachefelix-1104 https://repository.apache.org/service/local/repositories/orgapachefelix-1104/content/org/apache/felix/maven-bundle-plugin/3.0.1/maven-bundle-plugin-3.0.1-source-release.tar.gz Source release checksum(s): [NAME-OF]-source-release.zip 08bac4ef6329c776b039a4cd28e7b6f4318aa3a3 Staging site: http://felix.apache.org/components/bundle-plugin-archives/bundle-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1
Need access to manage versions in svn
I don't seem to have access to manage versions, and people have been marking JIRAs as fixed for 3.0.2 instead of 3.0.1. I am going to cheat to send out a vote, but I will fix up JIRA as soon as I have access.
bundle plugin doc pub
http://felix.apache.org/components/bundle-plugin-archives/bundle-plugin-LATEST/ is the result of my labors so far.
Re: release of maven-bundle-plugin?
I am willing. I'll tee it up this weekend. On Fri, Nov 6, 2015 at 6:12 AM, Stefan Seifert wrote: > is it planned to make a release of maven-bundle-plugin 3.0.2 soon? > > i think the fix for FELIX-5062 is quite important. > > stefan
Re: git?
On Mon, Nov 2, 2015 at 9:55 AM, Pierre De Rop wrote: > Hello Benson; > > Currently only DependencyManager is using bndtools and gradle (and IIUC, > SCR will jump to bndtools soon). > > So, I propose that you first do a prototype with only all maven based sub > project and make also a jira issue that describes all the impacts, > including any impacts regarding the release process. Then I will look into > it and will help to see how to adapt DM. OK. I am to some extent inclined to ask the PMC to reach a consensus, formally, on whether to do this at all. If the decision is to do it, then the prototype would be the first task. > > However, I think it would be worth to first read the new release process > used by DM in [1] (we are not using maven or the nexus staging repository > anymore, we are only simply using svn from the gradle script). > > FYI, the gradle script used to generate DM binaries is the one that is > generated by bndtools. The only specific gradle script we have done is: [2] > and is only used to make releases. The readme from [3] describes how to > make DM releases and how to use the script. > > [1] https://issues.apache.org/jira/browse/FELIX-4818 > [2] > http://svn.apache.org/viewvc/felix/trunk/dependencymanager/release/build.gradle > [3] > http://svn.apache.org/viewvc/felix/trunk/dependencymanager/release/README.release?view=log > > > cheers; > /Pierre > > On Mon, Nov 2, 2015 at 1:41 PM, Benson Margulies > wrote: > >> I am a gradle idiot. Is someone else willing to help or at least give me >> some pointers? >> On Nov 2, 2015 7:24 AM, "Marcel Offermans" >> wrote: >> >> > I would be more comfortable if we first had someone volunteer to adapt >> all >> > (Maven and Ant/Gradle based builds) to work with Git and otherwise ensure >> > that all projects keep working. Then demonstrate all of that (with a copy >> > of our repository), and update our documentation to reflect the new >> > processes before we decide on making such a move. I have a feeling this >> is >> > going to be a lot of work and it could break quite a few processes that >> we >> > currently have which is why I don’t think we should “just switch” and >> then >> > try to pick up the broken pieces. >> > >> > Greetings, Marcel >> > >> > On 31 October 2015 at 22:01:01 , Oliver Lietz (apa...@oliverlietz.de) >> > wrote: >> > >> > On Friday 30 October 2015 06:41:09 Benson Margulies wrote: >> > > On Fri, Oct 30, 2015 at 2:36 AM, Carsten Ziegeler < >> cziege...@apache.org> >> > wrote: >> > > > Am 30.10.15 um 01:48 schrieb Benson Margulies: >> > > >> Is this a consensus to proceed yet? It's been a few days since the >> > > >> last contribution. >> > > > >> > > > We clearly have different opinions, they range from "why change?", >> > > > "let's get moving" to "let's do more than a simple conversion". >> > > > I don't see a clear consensus/agreement on any of the three. For each >> > > > opinion there are imho good/valid arguments. I have the feeling that >> a >> > > > formal vote does not lead us anywhere. >> > > > >> > > > Maybe someone can clearly identify/list the benefits for everyone if >> we >> > > > move from svn to a single git repo - compared to using the already >> > > > existing git proxy. I think this should give everyone a clear view of >> > > > why the migration makes sense. And if there are no compelling reasons >> > > > then we have a decision as well. >> > > >> > > I think I can state some advantages: >> > > >> > > >> > > 1: Make it significantly easier to apply patches from people who >> > > provide them via github. >> > > >> > > 2: Make it significantly easier to create branches in the main repo >> > > for collaborative changes. >> > > >> > > 3: Take a first step towards subdividing into multiple repos where >> > > that makes sense. >> > >> > some more: >> > >> > https://issues.apache.org/jira/browse/SLING-3987 >> > >> > >> https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git >> > >> > Is there already a project at Apache which moved from Subversion to Git >> > setting up multiple repos or even a repo per release artifact? >> > >> > Regards, >> > O. >> > >> > > My sense of the email thread is that we have some enthusiastic >> > > supporters of moving to git, and some '+0' weak objectors. So, in some >> > > models of consensus process, that would be a reason to go ahead. Do >> > > you want to recast this as a VOTE as a way of clarifying views? >> > > >> > > > Carsten >> > > > -- >> > > > Carsten Ziegeler >> > > > Adobe Research Switzerland >> > > > cziege...@apache.org >> > >> > >>
Re: git?
I am a gradle idiot. Is someone else willing to help or at least give me some pointers? On Nov 2, 2015 7:24 AM, "Marcel Offermans" wrote: > I would be more comfortable if we first had someone volunteer to adapt all > (Maven and Ant/Gradle based builds) to work with Git and otherwise ensure > that all projects keep working. Then demonstrate all of that (with a copy > of our repository), and update our documentation to reflect the new > processes before we decide on making such a move. I have a feeling this is > going to be a lot of work and it could break quite a few processes that we > currently have which is why I don’t think we should “just switch” and then > try to pick up the broken pieces. > > Greetings, Marcel > > On 31 October 2015 at 22:01:01 , Oliver Lietz (apa...@oliverlietz.de) > wrote: > > On Friday 30 October 2015 06:41:09 Benson Margulies wrote: > > On Fri, Oct 30, 2015 at 2:36 AM, Carsten Ziegeler > wrote: > > > Am 30.10.15 um 01:48 schrieb Benson Margulies: > > >> Is this a consensus to proceed yet? It's been a few days since the > > >> last contribution. > > > > > > We clearly have different opinions, they range from "why change?", > > > "let's get moving" to "let's do more than a simple conversion". > > > I don't see a clear consensus/agreement on any of the three. For each > > > opinion there are imho good/valid arguments. I have the feeling that a > > > formal vote does not lead us anywhere. > > > > > > Maybe someone can clearly identify/list the benefits for everyone if we > > > move from svn to a single git repo - compared to using the already > > > existing git proxy. I think this should give everyone a clear view of > > > why the migration makes sense. And if there are no compelling reasons > > > then we have a decision as well. > > > > I think I can state some advantages: > > > > > > 1: Make it significantly easier to apply patches from people who > > provide them via github. > > > > 2: Make it significantly easier to create branches in the main repo > > for collaborative changes. > > > > 3: Take a first step towards subdividing into multiple repos where > > that makes sense. > > some more: > > https://issues.apache.org/jira/browse/SLING-3987 > > https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git > > Is there already a project at Apache which moved from Subversion to Git > setting up multiple repos or even a repo per release artifact? > > Regards, > O. > > > My sense of the email thread is that we have some enthusiastic > > supporters of moving to git, and some '+0' weak objectors. So, in some > > models of consensus process, that would be a reason to go ahead. Do > > you want to recast this as a VOTE as a way of clarifying views? > > > > > Carsten > > > -- > > > Carsten Ziegeler > > > Adobe Research Switzerland > > > cziege...@apache.org > >
Re: Getting the full maven site docs into the site
Folks,
Here is the content I propose to add to the top-level .htaccess file
to merge in generated doc that is not passing through the CMS.
If anyone hates this idea, please speak up. Otherwise, in a day or
two, this will appear (and disappear if it doesn't work, of course).
RewriteEngine on
# if file is not found in CMS content, look into components
RewriteCond %{REQUEST_URI} !^/components/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /components/$1 [C]
# in case of directory without trailing /, do the redirect or httpd
will do a redirect from /foo to /components/foo/
RewriteCond %{REQUEST_FILENAME} -d
RewriteCond %{REQUEST_URI} !/$
RewriteRule components/(.*) /$1/ [R]
On Thu, Oct 29, 2015 at 8:52 PM, Benson Margulies wrote:
> I set up the pom for the maven-bundle-plugin to use the
> maven-scm-publish-plugin to push the generated doc to svn. However,
> it's not visible yet, because there's some trickery needed to combine
> the CMS content with this content.
>
> https://issues.apache.org/jira/browse/INFRA-10688
>
> describes how this is currently done for the Maven project.
>
> Does anyone object to applying the same glue to Felix? Obviously, if
> infra@ comes up with a clean 'unionfs' solution for Maven, it could
> also be applied to Felix.
Re: git?
On Fri, Oct 30, 2015 at 2:36 AM, Carsten Ziegeler wrote: > Am 30.10.15 um 01:48 schrieb Benson Margulies: >> Is this a consensus to proceed yet? It's been a few days since the >> last contribution. >> > We clearly have different opinions, they range from "why change?", > "let's get moving" to "let's do more than a simple conversion". > I don't see a clear consensus/agreement on any of the three. For each > opinion there are imho good/valid arguments. I have the feeling that a > formal vote does not lead us anywhere. > > Maybe someone can clearly identify/list the benefits for everyone if we > move from svn to a single git repo - compared to using the already > existing git proxy. I think this should give everyone a clear view of > why the migration makes sense. And if there are no compelling reasons > then we have a decision as well. I think I can state some advantages: 1: Make it significantly easier to apply patches from people who provide them via github. 2: Make it significantly easier to create branches in the main repo for collaborative changes. 3: Take a first step towards subdividing into multiple repos where that makes sense. My sense of the email thread is that we have some enthusiastic supporters of moving to git, and some '+0' weak objectors. So, in some models of consensus process, that would be a reason to go ahead. Do you want to recast this as a VOTE as a way of clarifying views? > > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Getting the full maven site docs into the site
I set up the pom for the maven-bundle-plugin to use the maven-scm-publish-plugin to push the generated doc to svn. However, it's not visible yet, because there's some trickery needed to combine the CMS content with this content. https://issues.apache.org/jira/browse/INFRA-10688 describes how this is currently done for the Maven project. Does anyone object to applying the same glue to Felix? Obviously, if infra@ comes up with a clean 'unionfs' solution for Maven, it could also be applied to Felix.
Re: git?
Is this a consensus to proceed yet? It's been a few days since the last contribution. On Wed, Oct 28, 2015 at 3:30 AM, Chetan Mehrotra wrote: > On Sat, Oct 24, 2015 at 11:50 PM, Marcel Offermans > wrote: >> I’m +0 on making a switch because it’s also a lot of work and I don’t think >> the benefits are huge. If it works, don’t fix it. :) > > +1 to that. Side-line for me too. > > SVN isn't that bad after all, and along with 'git svn' most of the > benefits of git (quick local branching/fast commit history etc) can be > realized locally by developers. > > Not that imp but for me at times the linear progressing svn revision > feels more useful to determine if a particular CL made it to a > particular released.
Re: git?
On Tue, Oct 27, 2015 at 3:00 PM, David Jencks wrote: > I suspect it’s obvious already, but I’m in favor of moving to a single git > repo and stopping there unless and until we find it quite inconvenient. > > A million thanks Benson for doing the work. I won't say 'you're welcome' until I've done some work, and I don't perceive a consensus to get started quite just yet :-) > > thanks > david jencks > >> On Oct 27, 2015, at 10:07 AM, Benson Margulies wrote: >> >> On Tue, Oct 27, 2015 at 10:02 AM, Carsten Ziegeler >> wrote: >>> Am 27.10.15 um 14:52 schrieb Benson Margulies: >>>> On Tue, Oct 27, 2015 at 9:51 AM, Carsten Ziegeler >>>> wrote: >>>>> Am 27.10.15 um 14:28 schrieb Benson Margulies: >>>>>> As a volunteer of record, I have a preference at this point for >>>>>> flipping the entire repo. It's not zero work; all the elements >>>>>> have to be edited, and release plugin config adjusted, for the maven >>>>>> plugins. But that's very straightforward. Once we get this much done, >>>>>> we can then start to move things to their own repo. >>>>> >>>>> What does it take to get a new git repo setup? Just in INFRA jira issue? >>>> >>>> Yes. There's a particular form of that JIRA that says, >>>> >>>> 'please convert our mirror to a writable repo and set SVN readonly' >>>> >>>> as opposed to >>>> >>>> 'please create a new, empty', repo. >>>> >>>> The 'all-at-once' plan uses the first option. >>>> >>> >>> Right, understood and sorry to ask again, but if we do the all at once >>> plan and want to split something into another new git repo, what does it >>> take then? >> >> For each new repo, a JIRA asking for a new repo, and we move the >> content ourselves. >> >> >>> >>> Carsten >>> >>>>> >>>>> Regards >>>>> Carsten >>>>> >>>>>> >>>>>> ___However___, I'm willing to take up any other work plan that the >>>>>> group agrees upon. >>>>>> >>>>>> On Tue, Oct 27, 2015 at 9:11 AM, Ferry Huberts >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> On 27/10/15 13:45, Carsten Ziegeler wrote: >>>>>>>> >>>>>>>> Looking at this thread, there seems to be no one really against moving >>>>>>>> to git. >>>>>>>> >>>>>>>> When it comes to moving, we have three options: >>>>>>>> >>>>>>>> a) create a single git repo >>>>>>> >>>>>>> >>>>>>> I'd start here. >>>>>>> It's the simplest and lowest risk thing to do, doesn't break your >>>>>>> parent-pom >>>>>>> hierarchy, etc. >>>>>>> >>>>>>> It merely switches the VCS. >>>>>>> >>>>>>> And then work from there, try out different solutions for your >>>>>>> parent-pom >>>>>>> hierarchy, releasing, etc >>>>>>> >>>>>>> You can always split out parts of the tree later while preserving >>>>>>> history. >>>>>>> Git doesn't mind and has great tooling to do that. >>>>>>> >>>>>>> >>>>>>>> b) create git repos by functional modules >>>>>>>> c) create a git repo for every artifact >>>>>>>> >>>>>>>> Depending on which variant we pick, the more work it is to get >>>>>>>> everything moved. Therefore apart from deciding for the option it >>>>>>>> depends on a volunteer to drive this thing. >>>>>>>> >>>>>>>> I'm unsure on how we come to a decision on the option. I think all >>>>>>>> arguments are on the plate and there is little use in reiterating these >>>>>>>> in slightly different fashions. >>>>>>>> >>>>>>>> The thing I don't know is, how much effort it requires to >>>>>>>> request/create/setup another git repo, e.g. if we start with a) and >>>>>>>> there is a desire to create a separate repo for something. (I know the >>>>>>>> git commands to move a subtree to a different repo, therefore I'm just >>>>>>>> asking about the effort on the infra side) >>>>>>>> >>>>>>>> Regards >>>>>>>> Carsten >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ferry Huberts >>>>>> >>>>> >>>>> >>>>> -- >>>>> Carsten Ziegeler >>>>> Adobe Research Switzerland >>>>> cziege...@apache.org >>>> >>> >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> cziege...@apache.org >
[jira] [Commented] (FELIX-5069) Spurious split package messages when embedding dependencies
[
https://issues.apache.org/jira/browse/FELIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14976860#comment-14976860
]
Benson Margulies commented on FELIX-5069:
-
https://github.com/bndtools/bnd/issues/1172
> Spurious split package messages when embedding dependencies
> ---
>
> Key: FELIX-5069
> URL: https://issues.apache.org/jira/browse/FELIX-5069
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.0.0
>Reporter: Benson Margulies
> Assignee: Benson Margulies
>
> https://github.com/bimargulies/felix-unwanted-split-package-messages-tc:
> run mvn install, see:
> {noformat}
> Use Import/Export Package directive
> -split-package:=(merge-first|merge-last|error|first) to get rid of this
> warning
> Package found in [Jar:sp-tc-jar1, Jar:sp-tc-jar2]
> Class path [Jar:., Jar:sp-tc-jar1, Jar:sp-tc-jar2]
> {noformat}
> I claim that you can't have a 'split package' amongst jars that are embedded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: git?
On Tue, Oct 27, 2015 at 10:02 AM, Carsten Ziegeler wrote: > Am 27.10.15 um 14:52 schrieb Benson Margulies: >> On Tue, Oct 27, 2015 at 9:51 AM, Carsten Ziegeler >> wrote: >>> Am 27.10.15 um 14:28 schrieb Benson Margulies: >>>> As a volunteer of record, I have a preference at this point for >>>> flipping the entire repo. It's not zero work; all the elements >>>> have to be edited, and release plugin config adjusted, for the maven >>>> plugins. But that's very straightforward. Once we get this much done, >>>> we can then start to move things to their own repo. >>> >>> What does it take to get a new git repo setup? Just in INFRA jira issue? >> >> Yes. There's a particular form of that JIRA that says, >> >>'please convert our mirror to a writable repo and set SVN readonly' >> >> as opposed to >> >> 'please create a new, empty', repo. >> >> The 'all-at-once' plan uses the first option. >> > > Right, understood and sorry to ask again, but if we do the all at once > plan and want to split something into another new git repo, what does it > take then? For each new repo, a JIRA asking for a new repo, and we move the content ourselves. > > Carsten > >>> >>> Regards >>> Carsten >>> >>>> >>>> ___However___, I'm willing to take up any other work plan that the >>>> group agrees upon. >>>> >>>> On Tue, Oct 27, 2015 at 9:11 AM, Ferry Huberts wrote: >>>>> >>>>> >>>>> On 27/10/15 13:45, Carsten Ziegeler wrote: >>>>>> >>>>>> Looking at this thread, there seems to be no one really against moving >>>>>> to git. >>>>>> >>>>>> When it comes to moving, we have three options: >>>>>> >>>>>> a) create a single git repo >>>>> >>>>> >>>>> I'd start here. >>>>> It's the simplest and lowest risk thing to do, doesn't break your >>>>> parent-pom >>>>> hierarchy, etc. >>>>> >>>>> It merely switches the VCS. >>>>> >>>>> And then work from there, try out different solutions for your parent-pom >>>>> hierarchy, releasing, etc >>>>> >>>>> You can always split out parts of the tree later while preserving history. >>>>> Git doesn't mind and has great tooling to do that. >>>>> >>>>> >>>>>> b) create git repos by functional modules >>>>>> c) create a git repo for every artifact >>>>>> >>>>>> Depending on which variant we pick, the more work it is to get >>>>>> everything moved. Therefore apart from deciding for the option it >>>>>> depends on a volunteer to drive this thing. >>>>>> >>>>>> I'm unsure on how we come to a decision on the option. I think all >>>>>> arguments are on the plate and there is little use in reiterating these >>>>>> in slightly different fashions. >>>>>> >>>>>> The thing I don't know is, how much effort it requires to >>>>>> request/create/setup another git repo, e.g. if we start with a) and >>>>>> there is a desire to create a separate repo for something. (I know the >>>>>> git commands to move a subtree to a different repo, therefore I'm just >>>>>> asking about the effort on the infra side) >>>>>> >>>>>> Regards >>>>>> Carsten >>>>>> >>>>> >>>>> -- >>>>> Ferry Huberts >>>> >>> >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> cziege...@apache.org >> > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: git?
On Tue, Oct 27, 2015 at 9:51 AM, Carsten Ziegeler wrote: > Am 27.10.15 um 14:28 schrieb Benson Margulies: >> As a volunteer of record, I have a preference at this point for >> flipping the entire repo. It's not zero work; all the elements >> have to be edited, and release plugin config adjusted, for the maven >> plugins. But that's very straightforward. Once we get this much done, >> we can then start to move things to their own repo. > > What does it take to get a new git repo setup? Just in INFRA jira issue? Yes. There's a particular form of that JIRA that says, 'please convert our mirror to a writable repo and set SVN readonly' as opposed to 'please create a new, empty', repo. The 'all-at-once' plan uses the first option. > > Regards > Carsten > >> >> ___However___, I'm willing to take up any other work plan that the >> group agrees upon. >> >> On Tue, Oct 27, 2015 at 9:11 AM, Ferry Huberts wrote: >>> >>> >>> On 27/10/15 13:45, Carsten Ziegeler wrote: >>>> >>>> Looking at this thread, there seems to be no one really against moving >>>> to git. >>>> >>>> When it comes to moving, we have three options: >>>> >>>> a) create a single git repo >>> >>> >>> I'd start here. >>> It's the simplest and lowest risk thing to do, doesn't break your parent-pom >>> hierarchy, etc. >>> >>> It merely switches the VCS. >>> >>> And then work from there, try out different solutions for your parent-pom >>> hierarchy, releasing, etc >>> >>> You can always split out parts of the tree later while preserving history. >>> Git doesn't mind and has great tooling to do that. >>> >>> >>>> b) create git repos by functional modules >>>> c) create a git repo for every artifact >>>> >>>> Depending on which variant we pick, the more work it is to get >>>> everything moved. Therefore apart from deciding for the option it >>>> depends on a volunteer to drive this thing. >>>> >>>> I'm unsure on how we come to a decision on the option. I think all >>>> arguments are on the plate and there is little use in reiterating these >>>> in slightly different fashions. >>>> >>>> The thing I don't know is, how much effort it requires to >>>> request/create/setup another git repo, e.g. if we start with a) and >>>> there is a desire to create a separate repo for something. (I know the >>>> git commands to move a subtree to a different repo, therefore I'm just >>>> asking about the effort on the infra side) >>>> >>>> Regards >>>> Carsten >>>> >>> >>> -- >>> Ferry Huberts >> > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: git?
As a volunteer of record, I have a preference at this point for flipping the entire repo. It's not zero work; all the elements have to be edited, and release plugin config adjusted, for the maven plugins. But that's very straightforward. Once we get this much done, we can then start to move things to their own repo. ___However___, I'm willing to take up any other work plan that the group agrees upon. On Tue, Oct 27, 2015 at 9:11 AM, Ferry Huberts wrote: > > > On 27/10/15 13:45, Carsten Ziegeler wrote: >> >> Looking at this thread, there seems to be no one really against moving >> to git. >> >> When it comes to moving, we have three options: >> >> a) create a single git repo > > > I'd start here. > It's the simplest and lowest risk thing to do, doesn't break your parent-pom > hierarchy, etc. > > It merely switches the VCS. > > And then work from there, try out different solutions for your parent-pom > hierarchy, releasing, etc > > You can always split out parts of the tree later while preserving history. > Git doesn't mind and has great tooling to do that. > > >> b) create git repos by functional modules >> c) create a git repo for every artifact >> >> Depending on which variant we pick, the more work it is to get >> everything moved. Therefore apart from deciding for the option it >> depends on a volunteer to drive this thing. >> >> I'm unsure on how we come to a decision on the option. I think all >> arguments are on the plate and there is little use in reiterating these >> in slightly different fashions. >> >> The thing I don't know is, how much effort it requires to >> request/create/setup another git repo, e.g. if we start with a) and >> there is a desire to create a separate repo for something. (I know the >> git commands to move a subtree to a different repo, therefore I'm just >> asking about the effort on the infra side) >> >> Regards >> Carsten >> > > -- > Ferry Huberts
Re: git?
For Ferry, The workflow to apply github pull requests with git svn is complex and error prone. More and more, contributions from the outside come in as pull requests. What's 'broken', and I choose that term with some trepidation, is that some of us really prefer some git workflow (task branches, whatever), and use git at our day jobs, and would rather not switch our brains to svn or the combination. The premise of this discussion is that if we're willing to do the work, others are willing to see us do it. It could be that there isn't a consensus for that. On Tue, Oct 27, 2015 at 6:22 AM, Ferry Huberts wrote: > Side-line for me too. > > How about just using 'git svn ...' > > Work locally in git, store in svn. > What's the big deal? > > If there are blocking process issues _then_ you switch, right? > > > > > On 27/10/15 11:16, Achim Nierbeck wrote: >> >> Just looking from the side-line of this ... >> ... but all of this sounds more like a lot of pain compared to the gain. >> >> SVN isn't that bad after all, so why fix something that isn't really >> broken? >> Right now I don't see much of a benefit to this, but as I'm not part of >> any >> decision makers here, >> take this just as a little hint :-) >> >> regards, Achim >> >> >> 2015-10-27 11:12 GMT+01:00 Benson Margulies : >> >>> My recommendation at this point in the discussion is to convert the >>> repo _en bloc_, then split out very independent things (if any), and >>> only then contemplate add-ons. >>> >> >> >> > > -- > Ferry Huberts
[jira] [Commented] (FELIX-5069) Spurious split package messages when embedding dependencies
[
https://issues.apache.org/jira/browse/FELIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14976195#comment-14976195
]
Benson Margulies commented on FELIX-5069:
-
There is no test dependency involved in my test case, so I don't think so. I'm
hoping to poke at this late today EDT; I'm stuck in a meeting where I'm not
allowed to tune out and work for the bulk of the day.
> Spurious split package messages when embedding dependencies
> ---
>
> Key: FELIX-5069
> URL: https://issues.apache.org/jira/browse/FELIX-5069
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.0.0
>Reporter: Benson Margulies
>Assignee: Benson Margulies
>
> https://github.com/bimargulies/felix-unwanted-split-package-messages-tc:
> run mvn install, see:
> {noformat}
> Use Import/Export Package directive
> -split-package:=(merge-first|merge-last|error|first) to get rid of this
> warning
> Package found in [Jar:sp-tc-jar1, Jar:sp-tc-jar2]
> Class path [Jar:., Jar:sp-tc-jar1, Jar:sp-tc-jar2]
> {noformat}
> I claim that you can't have a 'split package' amongst jars that are embedded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: git?
My recommendation at this point in the discussion is to convert the repo _en bloc_, then split out very independent things (if any), and only then contemplate add-ons.
[jira] [Assigned] (FELIX-5069) Spurious split package messages when embedding dependencies
[
https://issues.apache.org/jira/browse/FELIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies reassigned FELIX-5069:
---
Assignee: Benson Margulies
> Spurious split package messages when embedding dependencies
> ---
>
> Key: FELIX-5069
> URL: https://issues.apache.org/jira/browse/FELIX-5069
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.0.0
>Reporter: Benson Margulies
> Assignee: Benson Margulies
>
> https://github.com/bimargulies/felix-unwanted-split-package-messages-tc:
> run mvn install, see:
> {noformat}
> Use Import/Export Package directive
> -split-package:=(merge-first|merge-last|error|first) to get rid of this
> warning
> Package found in [Jar:sp-tc-jar1, Jar:sp-tc-jar2]
> Class path [Jar:., Jar:sp-tc-jar1, Jar:sp-tc-jar2]
> {noformat}
> I claim that you can't have a 'split package' amongst jars that are embedded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: git?
There is a relatively standard Apache workflow that handles GH PR's. The committer merges the PR and pushes it, editing a comment to say 'closes #nnn" and the PR gets closed. On Sun, Oct 25, 2015 at 12:51 PM, David Jencks wrote: > While working on bnd and OSGI at github I’ve become quite attached to the > triangular workflow model. (cf > https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows > > <https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows>) > I probably should know already, but does anyone know how practical it is to > do this with apache git and developer branches at github? > > I don’t know if apache git is at version 2.5 yet, but from the above link it > looks like the new worktree feature may provide an alternate solution to the > multiple-branches problem. > > david jencks > >> On Oct 25, 2015, at 12:12 PM, David Jencks wrote: >> >> Hi, >> >> In the 12+ years I’ve been working on apache projects I can’t recall any >> time when I’ve wanted to simultaneously check out different branches of >> modules of the same top level project. Therefore, unless anyone has actual >> contrary experience, I’d be in favor of trying a single git repo and >> refining it into multiple repos if we discover problems in real life use. >> (I have wanted to check out different branches of the same project >> simultaneously, but with git this is not helped by more repos). >> >> thanks >> david jencks >> >>> On Oct 25, 2015, at 2:47 AM, Christian Schneider >>> wrote: >>> >>> I am not sure if one git repo for everything would be a good idea. The main >>> reason is that in git (unlike in subversion) each branch and tag you do >>> contains all the other unrelated projects too. >>> I think it would also be quite difficult to checkout a state of the repo >>> where you need bundle A in branch A1 and bundle B in branch B2. Probably >>> this would mean that you need to checkout two instances of the repo >>> to have both branches visisble at the same time. You would then also have >>> to be really careful to not pick a project from the wrong checkout as it >>> would be in kind of an undefined state there. >>> >>> The other solution of having one git repo per bundle also seems to be quite >>> difficult to manage as you need to checkout and sync every such checkout in >>> the correct way. I have seen a project that does this at a customer and it >>> is not very easy to work in this structure. >>> >>> In the Aries project we went for kind of a compromise. >>> >>> We aim for releases by subproject. So each subproject can go into one git >>> repo. >>> The advantage is that each tag in git really covers the whole subproject. >>> So from the git side this is natural. >>> >>> The downside is of course that in many cases bundles are released that did >>> not change at all. >>> We make sure the package versions are done with semantic versioning. So >>> from the OSGi point of view the versioning >>> is still working as before. >>> >>> At the moment we have not yet done the migration to git but it is planned. >>> We are currently moving each subproject to the release by subproject model >>> gradually. >>> Theoretically we can then move each subproject to git independently. I am >>> not sure though how to move the change history over in that case. >>> In any case the Aries JPA project is the first one that is fully converted >>> to the release by subproject model if you want to take a look. >>> https://github.com/apache/aries/tree/trunk/jpa >>> >>> Christian >>> >>> Am 24.10.2015 um 23:32 schrieb Benson Margulies: >>>> On Sat, Oct 24, 2015 at 4:21 PM, David Jencks >>>> wrote: >>>>> I like having several felix subprojects open in one eclipse instance at >>>>> once, which the current svn structure facilitates. Having just one git >>>>> svn rebase to run is nice. Is there a way to stitch together several >>>>> smaller git repos that would work similarly? Not knowing how to do this, >>>>> I am starting to lean towards one big repo. >>>> Well, there are git submodules. But I hate to take everyone into that >>>> rabbit hole. I think we should aim to start with one big repo and >>>> assume we can tame the maven-release-plugin to start with. >>>> >
Re: git?
On Sat, Oct 24, 2015 at 4:21 PM, David Jencks wrote: > I like having several felix subprojects open in one eclipse instance at once, > which the current svn structure facilitates. Having just one git svn rebase > to run is nice. Is there a way to stitch together several smaller git repos > that would work similarly? Not knowing how to do this, I am starting to lean > towards one big repo. Well, there are git submodules. But I hate to take everyone into that rabbit hole. I think we should aim to start with one big repo and assume we can tame the maven-release-plugin to start with. > > FWIW, I’m hoping to move DS onto a gradle based build soon. > > thanks > david jencks > >> On Oct 24, 2015, at 2:51 PM, Benson Margulies wrote: >> >> Greeting, Marcel, >> >> It's not my intention to try to talk anyone into changing how they >> release anything. For the things that are built with Maven, it's my >> preference to avoid exercising the maven-release-plugin's feature of >> handling multiple released items in a repo, but it's just a >> preference. If the acceptable compromise is to have less repos than >> releasable items (possibly as few as one repo), I'd personally rather >> do that than not move to git at all. >> >> regards, >> >> benson >> >> >> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans >> wrote: >>> On 24 October 2015 at 11:36:03, Benson Margulies >>> (ben...@basistech.com(mailto:ben...@basistech.com)) wrote: >>> >>>>> So I would definitely argue against getting a Git repository per bundle. >>>>> Per subproject sounds like the right granularity to me. >>>> >>>> If a subproject is released all at once, then we're completely >>>> agreeing. If not, then your preference means exercising the >>>> occasionally squishy part of the release plugin; maybe it will get >>>> fixed once and for all. >>> >>> So for the dependency manager we reasoned as follows: >>> >>> 1) When talking about releases within Apache, we are talking about source >>> code. Releasing that a subproject at a time makes sense to me as the code, >>> even if it ends up in different bundles, clearly belongs together. >>> >>> 2) Binary releases are a matter of convenience and “what is convenient” >>> depends a lot on where you’re coming from. A lot of people would argue that >>> putting a binary in Maven is convenient, but there are definitely other >>> options. The binary releases also don’t have to have a 1:1 mapping with the >>> source, so we can have N bundles being put in Maven and other repositories >>> all from the same source release. >>> >>> Greetings, Marcel >>> >>> >
Looking for a bit of help with a CMS / site publication issue
At Felix, I'd like to add publication of a maven-generated site to the existing CMS content, following the trail of what's done at Maven. I see that the main site for Felix is at https://svn.apache.org/repos/infra/websites/production/felix/content, that's http://felix.apache.org I created https://svn.apache.org/repos/infra/websites/production/felix/components what does it take to make that work content be reachable at some URL inside of http://felix.apache.org? If I've started down the wrong path here, svn rm is not very hard; I set up to use the scm-publish-plugin analogously to the way it's used at Maven.
Re: git?
Greeting, Marcel, It's not my intention to try to talk anyone into changing how they release anything. For the things that are built with Maven, it's my preference to avoid exercising the maven-release-plugin's feature of handling multiple released items in a repo, but it's just a preference. If the acceptable compromise is to have less repos than releasable items (possibly as few as one repo), I'd personally rather do that than not move to git at all. regards, benson On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans wrote: > On 24 October 2015 at 11:36:03, Benson Margulies > (ben...@basistech.com(mailto:ben...@basistech.com)) wrote: > >> > So I would definitely argue against getting a Git repository per bundle. >> > Per subproject sounds like the right granularity to me. >> >> If a subproject is released all at once, then we're completely >> agreeing. If not, then your preference means exercising the >> occasionally squishy part of the release plugin; maybe it will get >> fixed once and for all. > > So for the dependency manager we reasoned as follows: > > 1) When talking about releases within Apache, we are talking about source > code. Releasing that a subproject at a time makes sense to me as the code, > even if it ends up in different bundles, clearly belongs together. > > 2) Binary releases are a matter of convenience and “what is convenient” > depends a lot on where you’re coming from. A lot of people would argue that > putting a binary in Maven is convenient, but there are definitely other > options. The binary releases also don’t have to have a 1:1 mapping with the > source, so we can have N bundles being put in Maven and other repositories > all from the same source release. > > Greetings, Marcel > >
Re: git?
On Sat, Oct 24, 2015 at 2:27 PM, Richard Hall wrote: > On Oct 24, 2015 2:21 PM, "Marcel Offermans" > wrote: >> >> Within Felix we have “subprojects” that consist of one or more bundles > and I would argue that they are always released together. This does not > mean that for every release, every bundle needs to change, sometimes only a > subset of the released bundles change. >> >> So I would definitely argue against getting a Git repository per bundle. > Per subproject sounds like the right granularity to me. If a subproject is released all at once, then we're completely agreeing. If not, then your preference means exercising the occasionally squishy part of the release plugin; maybe it will get fixed once and for all. >> >> Regarding Maven I don’t have much experience on how to set that up with > Git. Note that not all subprojects use Maven. Specifically the “dependency > manager” uses a gradle/bndtools based setup. We could easily move that to > its own Git repository. It is already setup for that. >> >> In general I like Git, and outside of the Apache projects I’m involved in > I almost exclusively use it, but I’m +0 on making a switch because it’s > also a lot of work and I don’t think the benefits are huge. If it works, > don’t fix it. :) > > +1 > > I don't care, but I agree the benefits aren't super compelling other than > buzzword compliance. > >> >> Greetings, Marcel >> >> On 24 October 2015 at 11:06:02, Benson Margulies (ben...@basistech.com) > wrote: >> >> Here's the basic issue. The maven-release-plugin doesn't always work >> with git when the pom you are releasing is not the top of the >> repository. I put a great deal of work into fixing it, and yet others >> continue to report problems. (It works for my favorite test case.) >> >> So, the conservative strategy is to put each group that are released >> together into a repo. >> >> As far as migration, INFRA only understands 'one big flip.' That >> offers us two choices if our goal is to subdivide: >> >> 1: Let infra do the flip, and then gradually get new repos and move >> some things into them. >> >> 2: Do our own migration: one by one, get infra to make new, empty, >> repos, and use the existing mirror repo as a source to push the pieces >> into them. >> >> I don't see much value in item #1 over item #2. So I'd propose to >> start by asking infra for a repo for the overall parent pom, which I >> think needs to live in a repo by itself (that's how we do it at >> Maven). Once we have released the pom from there, we can migrate >> others in whatever grouping we prefer. >> >> As the new committer here, I have to ask: what decision-making process >> would be good? >> >> >> >> >> On Sat, Oct 24, 2015 at 1:00 AM, David Jencks > wrote: >> > YAY!! >> > >> > as you can tell, I’m in favor of it. >> > >> > I think that 1 repo per project may be too small. For instance I think > it makes sense to have one repo for the 3 gogo projects, even though they > are released separately. I think soon there will be at least 4 scr projects > and I’d like them to be in 1 repo. >> > >> > Do you know how infra feels about gradual migration? Are they fine with > it or do they prefer all-at-once? >> > >> > thanks >> > david jencks >> > >> >> On Oct 23, 2015, at 10:36 PM, Benson Margulies > wrote: >> >> >> >> There was some discussion a while back about git, which I recall >> >> (perhaps inaccurately) as vaguely positive. It's a lot easier if each >> >> releasable thing gets its own git repo. >> >> >> >> How do folks feel about starting with a migration of the bundle plugin? >> >> >> >> --benson >> >
[jira] [Resolved] (FELIX-5070) Simple syntax for specifying embedded dependencies has broken
[
https://issues.apache.org/jira/browse/FELIX-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies resolved FELIX-5070.
-
Resolution: Fixed
Fix Version/s: maven-bundle-plugin-3.0.2
r1710372 adds a unit test that proves that there's no problem here.
I *think* that resulted from a behavior of the old version in which , and ;
were interchangeable.
> Simple syntax for specifying embedded dependencies has broken
> -
>
> Key: FELIX-5070
> URL: https://issues.apache.org/jira/browse/FELIX-5070
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.0.0
> Reporter: Benson Margulies
> Fix For: maven-bundle-plugin-3.0.2
>
>
> In 2.5.3, I could say:
> {code}
> res-core;rni-rnt
> {code}
> or
> {code}
> res-core,rni-rnt
> {code}
> Not any more. I need to say:
> {code}
> *;artifactId=res-core|rni-rnt
> {code}
> which is a whole lot more verbose. This seems undesirable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: git?
Here's the basic issue. The maven-release-plugin doesn't always work with git when the pom you are releasing is not the top of the repository. I put a great deal of work into fixing it, and yet others continue to report problems. (It works for my favorite test case.) So, the conservative strategy is to put each group that are released together into a repo. As far as migration, INFRA only understands 'one big flip.' That offers us two choices if our goal is to subdivide: 1: Let infra do the flip, and then gradually get new repos and move some things into them. 2: Do our own migration: one by one, get infra to make new, empty, repos, and use the existing mirror repo as a source to push the pieces into them. I don't see much value in item #1 over item #2. So I'd propose to start by asking infra for a repo for the overall parent pom, which I think needs to live in a repo by itself (that's how we do it at Maven). Once we have released the pom from there, we can migrate others in whatever grouping we prefer. As the new committer here, I have to ask: what decision-making process would be good? On Sat, Oct 24, 2015 at 1:00 AM, David Jencks wrote: > YAY!! > > as you can tell, I’m in favor of it. > > I think that 1 repo per project may be too small. For instance I think it > makes sense to have one repo for the 3 gogo projects, even though they are > released separately. I think soon there will be at least 4 scr projects and > I’d like them to be in 1 repo. > > Do you know how infra feels about gradual migration? Are they fine with it > or do they prefer all-at-once? > > thanks > david jencks > >> On Oct 23, 2015, at 10:36 PM, Benson Margulies wrote: >> >> There was some discussion a while back about git, which I recall >> (perhaps inaccurately) as vaguely positive. It's a lot easier if each >> releasable thing gets its own git repo. >> >> How do folks feel about starting with a migration of the bundle plugin? >> >> --benson >
Re: Could I please have permission to assign jiras?
Still no luck. I even logged out and into jira. On Sat, Oct 24, 2015 at 10:21 AM, Carsten Ziegeler wrote: > Am 24.10.15 um 14:14 schrieb Benson Margulies: >> I can close them, but I can't assign them to myself. >> > Should work now > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Could I please have permission to assign jiras?
I can close them, but I can't assign them to myself.
[jira] [Resolved] (FELIX-5073) Option to create dependency-reduced-pom exists
[ https://issues.apache.org/jira/browse/FELIX-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved FELIX-5073. - Resolution: Fixed Fix Version/s: maven-bundle-plugin-3.0.2 r1710332 | bimargulies | 2015-10-24 07:38:15 -0400 (Sat, 24 Oct 2015) | 1 line FELIX-5073: fill in integration test. r1710331 | bimargulies | 2015-10-24 07:38:12 -0400 (Sat, 24 Oct 2015) | 1 line FELIX-5073: integration test. r1710330 | bimargulies | 2015-10-24 07:38:08 -0400 (Sat, 24 Oct 2015) | 1 line FELIX-5073: dependency-reduced-pom support; remove embedded items from pom. > Option to create dependency-reduced-pom exists > -- > > Key: FELIX-5073 > URL: https://issues.apache.org/jira/browse/FELIX-5073 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-3.0.0 >Reporter: Benson Margulies > Fix For: maven-bundle-plugin-3.0.2 > > > It would be convenient to have an option, like the dependency-reduced-pom > option of the maven-shade-plugin, that removes any inlined/embedded > dependencies from the pom of a bundle. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4970) all felix poms should advertise their SCM
[ https://issues.apache.org/jira/browse/FELIX-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved FELIX-4970. - Resolution: Fixed Fix Version/s: gogo.runtime-0.16.4 Fixed in r1710336. > all felix poms should advertise their SCM > - > > Key: FELIX-4970 > URL: https://issues.apache.org/jira/browse/FELIX-4970 > Project: Felix > Issue Type: Improvement > Reporter: Benson Margulies > Fix For: gogo.runtime-0.16.4 > > > It would be helpful if all the Felix poms followed the convention of having > an 'scm' section. The gogo path through the pom forest does not have any. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
