I understand now. But I have to say, even though I have read the git commit logs and JIRA cases it’s very difficult to figure out why this particular solution was chosen. And asking users to download a patch from github is still a hack, yes? If you agree it’s a hack, why didn’t anyone think to log a JIRA case to clean up?
Julian [1] https://issues.apache.org/jira/browse/EAGLE-365 <https://issues.apache.org/jira/browse/EAGLE-365> [2] https://github.com/apache/incubator-eagle/commit/9cd75b188941bf476878a2210984546e4e257c7a <https://github.com/apache/incubator-eagle/commit/9cd75b188941bf476878a2210984546e4e257c7a> [3] http://eagle.incubator.apache.org/docs/quick-start.html <http://eagle.incubator.apache.org/docs/quick-start.html> [4] https://github.com/apache/incubator-eagle/pull/180 <https://github.com/apache/incubator-eagle/pull/180> > On Jul 13, 2016, at 7:41 PM, Michael Wu <[email protected]> wrote: > > Hi Henry, > > The solution is we removed the jars out of the project source code folder, > and will use a PR patch to hold the files for downloading, so that > customers can succeed to build in this flow: download source code tar-ball > -> extract tar-ball -> apply the patch -> maven build. > > This approach has been documented on apache eagle quick-start guide page. > > Thanks. > Michael > > On Thu, Jul 14, 2016 at 12:33 AM, Henry Saputra <[email protected]> > wrote: > >> So what was the solution for this? Could someone points to JIRA or Github >> PR to fix this? >> >> Thanks much! >> >> - Henry >> >> On Mon, Jul 11, 2016 at 1:30 AM, Julian Hyde <[email protected]> wrote: >> >>> Can someone explain why these jar files have to be checked into git? >>> Many other jar (and other binary) files are retrieved from a maven >>> repo when you build; why not these? You can use maven magic to >>> extract/filter/copy these files exactly where you need them on the >>> first build. >>> >>> Source files have a sacred role in open source because (a) they can be >>> edited (a fundamental right granted by an open source license), (b) >>> they can be audited during a release. >>> >>> And, leaving the open source issues aside and just looking at the >>> software engineering, checking non-source files into a source-control >>> system, and especially into git, is often a bad idea. For instance, >>> projects hotly debate whether to check in java files generated by >>> protobuf, because the .proto file is the "source", and the .java files >>> are generated. Git doesn't handle binary files particularly well, and >>> if the binary is modified a few times the git repo starts to become >>> bloated in size. >>> >>> Julian >>> >>> >>> On Sun, Jul 10, 2016 at 8:28 PM, Zhang, Edward (GDI Hadoop) >>> <[email protected]> wrote: >>>> In 0.3 release, Hemanth uses a patch to work around this issue. Can we >>> use the same approach in 0.4 and in 0.5 we have decided to remove >>> dependency on tomcat. >>>> >>>> >>>> Thanks >>>> >>>> Edward >>>> >>>> ________________________________ >>>> From: Hao Chen <[email protected]> >>>> Sent: Sunday, July 10, 2016 8:17:48 PM >>>> To: [email protected] >>>> Subject: Re: [Discuss] what will be the decent way to remove jars from >>> source code for releases >>>> >>>> Yes, the jars are added into the source package intentionally, which is >>>> necessary for bootstrapping eagle service. So maybe it possible for us >>> the >>>> keep the jars following apache way? Otherwise we may need some >> additional >>>> work to refactoring our package method. >>>> >>>> - Hao >>>> >>>> On Mon, Jul 11, 2016 at 11:07 AM, Michael Wu <[email protected]> >> wrote: >>>> >>>>> Hi guys, >>>>> >>>>> Further tested and verified, the 3 jar dependencies are NECESSARY for >>> the >>>>> eagle-service to start up. Without them, we can build the project but >>> when >>>>> we deploy it, eagle-service fails to start up complaining the lack of >>> the >>>>> dependencies. So, we cannot simply remove them before packaging the >>> source >>>>> tar ball. >>>>> >>>>> @PPMC, so far, we can tell that the 3 remaining jars are intended to >> be >>>>> there for the project's normal functionalities, they are important and >>>>> cannot be removed, can we just vote them as passed, please? >>>>> >>>>> Michael >>>>> >>>>> On Sat, Jul 9, 2016 at 3:46 PM, Michael Wu <[email protected]> >> wrote: >>>>> >>>>>> Hi dev group, >>>>>> >>>>>> As you may know, we encountered the issue of having depended jars >>> within >>>>>> the source tar ball of 0.4.0-incubating RC1 and RC2, they are: >>>>>> *********************** >>>>>> eagle-assembly/src/main/lib/tomcat/bin/bootstrap.jar >>>>>> eagle-assembly/src/main/lib/tomcat/bin/commons-daemon.jar >>>>>> eagle-assembly/src/main/lib/tomcat/bin/tomcat-juli.jar >>>>>> *********************** >>>>>> >>>>>> I've verified, if the 3 jars are removed, maven build can also get >>>>> passed. >>>>>> But I'm still curious about what's the use of these jars, and will >> the >>>>>> removal of them affects eagle service while the service is deployed >>>>>> somewhere? >>>>>> >>>>>> So could anyone tell some details of the jars and give some advice >> on >>>>>> "shall we also remove the jars in git repository"? >>>>>> >>>>>> To my understanding, if we just remove the jars from source-RCx, >> then >>> the >>>>>> packaged tar ball will contain different files than the view we can >>> see >>>>> in >>>>>> git repository, will this situation violate release policy? Please >> you >>>>> guys >>>>>> know well about it DO give instructions. It's highly appreciated! >>>>>> >>>>>> Michael >>>>>> >>>>> >>> >>
