On Mon, Aug 1, 2016 at 3:34 PM, Abhishek Tiwari < [email protected]> wrote:
> Hi Imesh, > > Thanks for the feedback. I completely agree with the naming of executable. > Unfortunately, go install builds executable using module name and main() > has to be inside main module name (based on what I have read so far). A > quick search did not provide any solution so I will tackle this later. If > anyone has addressed this in the community, please let me know. > > Create a folder with the name that you want go give for the binary and move the <main>.go file to that folder. That would create the binary using the folder name. > Import statement for common is fully qualified since that is the root > level package. If I try prefixing that with project name, that will not > work, as Go will try to look for the package in the following: > <project-root-path>/src/<package-name> > > I have also provided instruction to build the project without Eclipse [1]. > It looks like your GOPATH is missing the path of the source directory of > project. My GOPATH has following additional entry for the project: > /Users/abhishektiwari/dev/test-framework > > Could you please try adding the source root to GOPATH in your > bash_profile. Please let me know if you still face issues with the build. > I tend to disagree with your approach. Building a project should not be that much of a trouble. Ideally the project should build with the following commands: go get github.com/<organization>/<project-name> cd $GOPATH/src/ github.com/<organization>/<project-name> go build Thanks > [1]. https://github.com/abhishek0198/test-framework#build-without-eclipse > > Thanks > Abhishek > > On Mon, Aug 1, 2016 at 2:46 PM, Imesh Gunaratne <[email protected]> wrote: > >> Hi Abhishek, >> >> On Mon, Aug 1, 2016 at 6:15 AM, Abhishek Tiwari < >> [email protected]> wrote: >> >>> Hi Imesh, >>> >>> The project is currently structured around standard Golang project >>> created by eclipse, you can add eclipse plugin, create a new project with >>> existing sources and it should compile fine. I will add complete >>> instructions on Github and update this thread. >>> >> >> I do not think we should use Eclipse specific build tools. The project >> should be able to build from the shell with standard go build commands. >> I went through the updated README and still the given instructions seem >> to be not working: >> >> ~/dev/test-framework$ go install -v -gcflags "-N -l" ./... >> src/main/config_parser.go:24:2: cannot find package "common" in any of: >> /usr/local/go/src/common (from $GOROOT) >> /Users/imesh/dev/go/src/common (from $GOPATH) >> >> I see couple of problems in the code: >> >> - The executable name should be meaningful. I do not think main is >> much meaningful binary name. >> - Import statements which refer packages from the same project should >> use fully qualified package names [1]. See [2]. This might be the root >> cause of the above error. >> >> [1] >> >> https://github.com/abhishek0198/test-framework/blob/master/src/main/config_parser.go#L24 >> [2] >> https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/iptables/proxier.go#L38 >> >> Thanks >> >> >> >>> Chamila, >>> The tests I am working on are custom tests which aims at verifying few >>> endpoints using CURL. I tried using existing tests for ESB, and that didn't >>> help either since setup steps of those tests requires a lot of efforts. If >>> developers from specific projects can help out with configuration, then we >>> can run existing full fledged tests. >>> >>> Thanks >>> Abhishek >>> >>> On Thu, Jul 28, 2016 at 9:08 PM, Chamila De Alwis <[email protected]> >>> wrote: >>> >>>> >>>> On Thu, Jul 28, 2016 at 4:19 AM, Abhishek Tiwari < >>>> [email protected]> wrote: >>>> >>>>> 2. I am currently working on adding the ability to run smoke tests >>>>> from the framework. The idea is to have the capability of having product >>>>> specific smoke tests, then teams with more product knowledge can add smoke >>>>> tests. I will add smoke tests for ESB at this point. >>>>> >>>> >>>> Would these be custom tests that are specific to WSO2 Dockerfiles >>>> context or generic tests that aim to test the product code? It would be >>>> better if we can reuse the generic tests, as new tests would not be >>>> attractive to the developers. >>>> >>>> >>>> Regards, >>>> Chamila de Alwis >>>> Committer and PMC Member - Apache Stratos >>>> Senior Software Engineer | WSO2 >>>> Blog: https://medium.com/@chamilad >>>> >>>> >>>> >>> >> >> >> -- >> *Imesh Gunaratne* >> Software Architect >> WSO2 Inc: http://wso2.com >> T: +94 11 214 5345 M: +94 77 374 2057 >> W: https://medium.com/@imesh TW: @imesh >> lean. enterprise. middleware >> >> > -- *Imesh Gunaratne* Software Architect WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: https://medium.com/@imesh TW: @imesh lean. enterprise. middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
