Re: [VOTE] Pulsar Release 2.0.0-rc1-incubating Candidate 5
Hi Matteo, I think I can help with that, Please fill an issue to track this question. I can post some reference as a comment to the issue that you can take a look. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Sun, May 27, 2018 at 1:30 PM, Matteo Merli wrote: > Hi Willem, I'm personally not familiar with BOM in Maven but we'll surely > take > a look. We just want to ensure that, out of the box, users won't have to > experience weird runtime errors, due when incompatible versions of some > library > required by different components. > > We'll look into this and few other options to achieve that without > including twice > some of the dependencies in different forms. > > Thank, > Matteo > > On Sat, May 26, 2018 at 7:21 PM Willem Jiang > wrote: > > > My suggestion is using BOM the manage the third party dependencies which > > could save you some time to build a uber jar. > > It's not a blocker issue for the release, but it's a common practice to > > resolve the version conflicts of third party dependencies. > > > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Sat, May 26, 2018 at 8:22 AM, Sijie Guo wrote: > > > > > Thank you Willem. Comments inline > > > > > > On Fri, May 25, 2018 at 4:03 PM, Willem Jiang > > > wrote: > > > > > > > my +1. > > > > > > > > I checked: > > > > > > > > The sign and check sum for both src and binary distributions. > > > > The License and Notice file for src and binary distributions. > > > > I can build the binary from source. > > > > > > > > Here are some minor issues I found, it's not blocker issues please > > verify > > > > them and we can fix it in the next release. > > > > > > > > 1. It's a little big size for the binary , so I checked the files. > > > > It looks like there are java-instance.jar which holds all the jars in > > the > > > > lib directory. I think we need to find a way to avoid shipping the > jars > > > > twice. > > > > > > > > > > java-instance.jar is a uber jar including all the dependencies for > > running > > > pulsar functions in process mode. > > > > > > it is needed for this release, because there are conflicts between > > > different protobuf/netty versions. so we have to do proper shading to > > > handle that. > > > > > > we are addressing that in master, the situation can be improved in 2.1 > > > release. > > > > > > > > > > > > > > 2. There are three different version of Netty in the library, > > > > io.netty-netty-3.10.1.Final.jar > > > > io.netty-netty-all-4.1.21.Final.jar > > > > io.netty-netty-codec-http2-4.1.12.Final.jar > > > > > > > > as netty 3.x and netty4.x use different package name, we may need to > go > > > > through all the netty 4.x dependencies. > > > > > > > > > > yeah. pulsar is using 4.1.21, however 3.10.1 and 4.1.12 are coming from > > its > > > transitive dependencies. hope that clarifies. > > > > > > > > > > > > > > > > > > Willem Jiang > > > > > > > > Twitter: willemjiang > > > > Weibo: 姜宁willem > > > > > > > > On Thu, May 24, 2018 at 1:21 PM, Matteo Merli > > wrote: > > > > > > > > > This is the fifth release candidate for Apache Pulsar, version > > > > > 2.0.0-rc1-incubating. > > > > > > > > > > Pulsar is a highly scalable, low latency messaging platform running > > on > > > > > commodity hardware. > > > > > It provides simple pub-sub semantics over topics, guaranteed > > > > at-least-once > > > > > delivery of > > > > > messages, automatic cursor management for subscribers, and > > > > geo-replication. > > > > > > > > > > The only difference from previous candidate is a fix on the LICENSE > > > > > attached to bin distribution to correctly reflect all dependencies > > and > > > > > versions. > > > > > > > > > > Link to the voting thread on pulsar dev list: > > > > > https://lists.apache.org/thread.html/ > 81359fe55cb75cd1621a70e9a5a0af > > > > > 02fb1a84549ab0046d335182fa@%3Cdev.pulsar.apache.org%3E > > > > > > > > > > It fixes the following issues: > > > > > https://github.com/apache/incubator-pulsar/milestone/12?closed=1 > > > > > > > > > > *** Please download, test and vote on this release. This vote will > > stay > > > > > open > > > > > for at least 72 hours *** > > > > > > > > > > Note that we are voting upon the source (tag), binaries are > provided > > > for > > > > > convenience. > > > > > > > > > > Source and binary files: > > > > > https://dist.apache.org/repos/dist/dev/incubator/pulsar/ > > > > > pulsar-2.0.0-rc1-incubating-candidate-5/ > > > > > > > > > > SHA-1 checksums: > > > > > 72ee624c9b1485cc4c12b71e3807c7c05ec900ad > > > > > apache-pulsar-2.0.0-rc1-incubating-bin.tar.gz > > > > > c525457db8f9c4ea859c595c93e9207631cda19f > > > > > apache-pulsar-2.0.0-rc1-incubating-src.tar.gz > > > > > > > > > > Maven staging repo: > > > > > https://repository.apache.org/content/repositories/ > > > orgapachepulsar-1017/ > > > > > > > > > > The tag to be voted upon: > > > > > v2.0.0-rc1-incubating-candidate-5 (08708a198606fb934e46f6cb0b614f > > > > > 2babf613e4) > > > > > http
Re: [VOTE] Release Apache NetBeans 9.0 RC1 (incubating) rc1
Silly question but must Apache releases include test data?
Is there a restriction on such minor binary files in the repository or just
binary files in the release zip?
I see no problem excluding all the tests in future NetBeans releases.
--emi
‐‐‐ Original Message ‐‐‐
On 27 May 2018 7:36 AM, Jan Lahoda wrote:
> On Sun, May 27, 2018 at 12:20 AM, Justin Mclean jus...@classsoftware.com
>
> wrote:
>
> > Hi,
> >
> > > I wonder where exactly (most) of these files come from.
> >
> > Sorry, many apologies, and my mistake as I looked at your last release by
> >
> > accident. Changing my vote to +0 (binding).
> >
> > I can still see the md5 hashes in the office release area [1] these should
> >
> > be removed (but that’s a minor issue).
> >
> > Re unexpected binary files it’s not open source if it contains
> >
> > unmodifiable code, that’s usually a class file in a jar file but that could
> >
> > also include things like obfuscated code or even minified JS.
> >
> > This RC1 for instance contains this jar [2] but as it contains no code
> >
> > that’s fine. But the _java.main.i in [3] is in a binary format and doesn’t
> >
> > seem to be compressed file.
>
> I think one could argue it is a compressed file[1], one just needs a
>
> special tool to get the uncompressed version (as one needs to get data out
>
> of the .zip or .tar.gz file):
>
> $ unzip incubating-netbeans-java-9.0-rc1-source.zip
>
> mercurial/test/qa-functional/data/JavaApp_repo.zip
>
> Archive: incubating-netbeans-java-9.0-rc1-source.zip
>
> inflating: mercurial/test/qa-functional/data/JavaApp_repo.zip
>
> $ cd mercurial/test/qa-functional/data/
>
> $ unzip JavaApp_repo.zip
>
> Archive: JavaApp_repo.zip
>
> creating: .hg/
>
> creating: .hg/store/
>
> creating: .hg/store/data/
>
> extracting: .hg/store/data/build.xml.i
>
> inflating: .hg/store/data/manifest.mf.i
>
> creating: .hg/store/data/nbproject/
>
> extracting: .hg/store/data/nbproject/build-impl.xml.i
>
> inflating: .hg/store/data/nbproject/genfiles.properties.i
>
> extracting: .hg/store/data/nbproject/project.properties.i
>
> inflating: .hg/store/data/nbproject/project.xml.i
>
> creating: .hg/store/data/src/
>
> creating: .hg/store/data/src/javaapp/
>
> inflating: .hg/store/data/src/javaapp/_main.java.i
>
> inflating: .hg/store/00manifest.i
>
> inflating: .hg/store/00changelog.i
>
> inflating: .hg/store/undo
>
> extracting: .hg/requires
>
> inflating: .hg/00changelog.i
>
> inflating: .hg/dirstate
>
> inflating: .hg/undo.dirstate
>
> extracting: .hgignore
>
> $ hg log
>
> changeset: 0:8df7d6dbbdba
>
> tag: tip
>
> user: Padraig OBriain padraig.obri...@sun.com
>
> date: Tue Jul 17 14:13:47 2007 +0100
>
> summary: Initial commit
>
> $ hg cat -r 0 src/javaapp/Main.java
>
> /*
>
> - Main.java
> -
> - Created on Jul 17, 2007, 2:13:19 PM
> -
> - To change this template, choose Tools | Templates
> - and open the template in the editor.
>
> /package javaapp;/*
>
> -
> - @author padraigo
>
> /public class Main {/*
>
> - @param args the command line arguments
>
> */
>
> public static void main(String[] args) {
>
> // TODO code application logic here
>
> }
>
> }
>
> (here I'd argue this file has no degree of creativity: this is simply
> the
>
> new file template at that time with file name, date and author filled
>
> automatically by the IDE.)
>
> [1] or, more in generally multiple compressed files, as this can hold
>
> multiple revisions of the file, although there is only one revision
> in this
>
> repo.
>
> Jan
>
>
> > Thanks,
> >
> > Justin
> >
> > 1. https://dist.apache.org/repos/dist/dev/incubator/netbeans/
> >
> > incubating-netbeans-java/incubating-9.0-rc1-rc1/
> >
> > 2. ./autoupdate.services/test/unit/src/org/netbeans/api/
> >
> > autoupdate/data/empty.jar
> >
> > 3. ./mercurial/test/qa-functional/data/JavaApp_repo.zip
> >
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >
> > For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache NetBeans 9.0 RC1 (incubating) rc1
Hi folks! Justin, thanks for talking such a deep look and catching those flaws, really appreciated! Here is my personal view: It's just test data, and if we can guarantee that the test data is IP clean then it's not a problem. I remember other ASF projects which have class files compiled with old Java versions checked in as class files. They are used to verify backward compatibility of our bytecode parsers (proxy logic). And of course you cannot ever build those within the same build! Afair we also committed the orignal Java sources with a comment about how to reproduce those. Or in the maven-scm-providers-svn and maven-scm-providers-git we do this as well. There we have a zip of a .svn and .git repos to verify the repo functionality. That's perfectly fine as long as the content is cleared. I've went through all of those zips [1] and verified them. Most contain just extremely simple sample XSDs. The zips are on the Oracle contribution list. So they are covered by the code drop. I think it's not a show stopper as they are dead simple and contain no IP able content, but to have it even more polished we might later re-package them and add an ALv2 LICENSE file to the zip files (just to be dead sure). The Java parts are either empty jars (funny that an Oracle project has something cmpiled with Azul Zulu btw ;) ) or dead simple (just method signature with empty body). So nothiing which constitutes originary IP again. Rest looks fine, so +1 from me (binding). txs and LieGrue, strub [1] ~/tmp/delete/incubating-netbeans-java-9.0-rc1-source$>find . -name "*.zip" ./projectimport.eclipse.core/test/unit/data/myeclipselibstest.zip ./websvc.saas.codegen/test/unit/src/org/netbeans/modules/websvc/saas/codegen/JavaApplication.zip ./mercurial/test/qa-functional/data/JavaApp_repo.zip ./mercurial/test/qa-functional/data/files/pp.zip ./ide.kit/test/qa-functional/data/biglist.zip ./subversion/test/unit/data/SvnWcParserData.zip ./subversion/test/qa-functional/data/files/pp.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve12.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve13.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve11.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve10.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve14.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve15.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve8.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve9.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/performance1.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/performance2.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/cyclic_dependencies.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve4.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve5.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve7.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve6.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve2.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve3.zip ./xml.schema.model/test/unit/src/org/netbeans/modules/xml/schema/model/resources/resolve1.zip ./git/test/qa-functional/data/files/pp.zip > Am 27.05.2018 um 10:29 schrieb Emilian Bold : > > Silly question but must Apache releases include test data? > > Is there a restriction on such minor binary files in the repository or just > binary files in the release zip? > > I see no problem excluding all the tests in future NetBeans releases. > > --emi > > ‐‐‐ Original Message ‐‐‐ > > On 27 May 2018 7:36 AM, Jan Lahoda wrote: > >> On Sun, May 27, 2018 at 12:20 AM, Justin Mclean jus...@classsoftware.com >> >> wrote: >> >>> Hi, >>> I wonder where exactly (most) of these files come from. >>> >>> Sorry, many apologies, and my mistake as I looked at your last release by >>> >>> accident. Changing my vote to +0 (binding). >>> >>> I can still see the md5 hashes in the office release area [1] these should >>> >>> be removed (but that’s a minor issue). >>> >>> Re unexpected binary files it’s not open source if it contains >>> >>> unmodifiable code, that’s usually a class file in a jar file but that could >>> >>> also include things like obfuscated code or even minified JS. >>> >>> This RC1 for instance contains this jar [2] but as it contains no code >>> >>> that’s fine. But the _java.main.i in [3] is in a binary format and d
