In 0.4.0 and 0.4.2 (1/9/14 build) Generate Client Libraries gives an alert that the endpoints tree cannot be found. Although the libraries are in fact generated they don't get copied into app-endpoints as they should.
This is a bug and can be tracked at :
https://code.google.com/p/android/issues/detail?can=4&start=0&num=100&q=&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars&groupby=&sort=&id=64537
What is the workaround?
To work around the failure of the automatic copy look for the generated code in app-AppEngine/google_generated like so...
After Generate Client Libraries, the code in
app-AppEngine/google_generated/endpoint/lib-expanded-source//endpoint/
{there are three .java files; endpoint.java, endpointRequest.java, and endpointRequestInitializer.java,
additionally there is a "model" folder with .java and CollectionResponse.java
}
are in fact the client libraries. copy them into
app-endpoints/src/endpoint-src/java/
good to go.
Related
I attempted to install the Traffic library for the book "A Touch of Class" but was not able to compile the examples. EiffelStudio complained about a base2.ecf file.
Error code: VD00
General configuration parsing error.
What to do: fix the configuration file.
Could not open file: \base2.ecf
$EIFFELBASE2\base2.ecf
base2.ecf is found in where Windows installed Eiffel: C:\Program Files\Eiffel Software\EiffelStudio 18.11 GPL\unstable\library\base2.ecf The offending line of code seems to be this in the Traffic configuration files:
I have attempted to change this configuration file pointing directly to where the file is, using the actual path, to no avail.
Setting the variable EIFFELBASE2 might help:
set "EIFFELBASE2=C:\Program Files\Eiffel Software\EiffelStudio 18.11 GPL\unstable\library"
Then, EiffelStudio should be started from the environment where the variable is set.
(However, I wonder if this is the library to be used with the examples, or if there is another one that comes together with the examples.)
Here my package is net-snmp.
Here is the task : Addition of Net-SNMP Source directory at path personal/apps/snmp/
Requirement is that it should download from website if there is change in version name and it should patch , configure and build soruce.
Hence, for that we need to configure Config.in and netsnmp.mk files in build/package/netsnmp in order to fulfill this requirement.
By adding following configuration in netsnmp.mk
NETSNMP_VERSION = 5.7.2.1
NETSNMP_SOURCE = net-snmp-$(NETSNMP_VERSION).tar.gz
NETSNMP_SITE = http://www.sourceforge.net/projects/net-snmp/files/net-snmp/$(NETSNMP_VERSION)
We can download the latest net-snmp tar ball which will be downloaded in dl/ folder in buildroot.
From here it will untar in build/output/build and will patch configure and build. After that it will build the executable at appropriate location inside target folder.
Here the issue is I want netsnmp source code to be at personal/apps/snmp folder which seems to be problematic and can edit the source in path personal/apps/snmp/ and configure build from here.
Any help and suggestion will be appreciated.
There is already a netsmp package in Buildroot. Why do you want to create another one?
Also, the Buildroot community is going to be much more reactive if you ask questions on the project's mailing list.
I have the following files which I would like to upload to Artifactory as a 9.8.0 versioned artifact.
NOTE: The first two files DO NOT have an extension (they are executable files i.e. if you open them/cat on it, you'll see junk characters).
Folder/files of a given version 9.8.0 in CVS is like:
com.company.project/gigaproject/v9.8.0/linux/gigainstall
com.company.project/gigaproject/v9.8.0/solaris/gigainstall
com.company.project/gigaproject/v9.8.0/win32/gigainstall.exe
com.company.project/gigaproject/v9.8.0/gigafile.dtd
com.company.project/gigaproject/v9.8.0/gigaanotherfile.dtd
com.company.project/gigaproject/v9.8.0/giga.jar
com.company.project/gigaproject/v9.8.0/giga.war
Uploading the above files which have an extension is very easy... You log in to Artifactory as an administrator/user which has access to deploy artifacts, click on "Deploy" tab, browse for the Artifactory file and once you select the file, click on "Upload" button.
Next you'll see a screen (like shown above). You'll tweak what you want in the fields on this page and once you click on "Deploy Artifact", you are done. All you have to make sure is you select the correct file.extension file while uploading and make sure the file extension is shown in the "Target Path" box correctly (with the version -x.x.x, etc.).
My questions:
Question 1: How do I upload an artifact which doesn't have an extension? It seems like Artifactory by default takes an artifact as a .jar extension. How can I upload the "gigainstall" artifact as shown in the folder/file structure above for both Linux and Solaris? I see I can use the artifact name as gigainstall-linux and gigainstall-solaris and differentiate it, but I am not sure how to tell Artifactory that this artifact doesn't have any extension.
I don't think the development team will start generating this artifact with a proper extension (as this artifact may be hard coded everywhere in other projects where they are currently getting it from CVS/SVN source control somewhere - which is itself a bad practice to store an artifact in a source control version tool).
Question 2: How would I tell a build system (for example, Gradle) to consume a non-extensioned artifact during, let's say, 'compile' task. In build.gradle under section dependencies { .. }, I will add something like as shown below, but I am not sure for non-extensioned files (the first two in the folder/file structure I mentioned above).
dependencies {
//compile 'com.company.project:gigainstall-linux:9.8.0#'
//compile 'com.company.project:gigainstall-linux:9.8.0#??????'
//compile 'com.company.project:gigainstall-linux:9.8.0#""'
//compile 'com.company.project:gigainstall-linux:9.8.0#"none"'
//compile 'com.company.project:gigainstall-linux:9.8.0#"NULL_or_something"'
// The following will easily get giga.jar version giga-9.8.0.jar from Artifactory repository
compile 'com.company.project:giga:9.8.0'
// The following will easily get giga.war
compile 'com.company.project:giga:9.8.0#war'
// Similarly, other extension based artifacts can be fetched from Artifactory
compile 'com.company.project:gigafile:9.8.0#dtd'
compile 'com.company.project:gigaanotherfile:9.8.0#dtd'
}
Answer 1 (will cover 2 as well in a different sense): Using Artifactory "Artifact Bundle" feature section under "Deploy" tab can do the TRICK for AT LEAST uploading the artifacts in a way we want, by creating a zip file first (containing the structure and artifacts in it) --OR you can upload the artifacts using/calling Artifactory REST API way.
High level idea:
Create a zip file called gigaproject.zip OR anyname.zip/.tar/compressed file which Artifactory can read. Inside the zip, create the structure - how these artifacts will be loaded to Artifactory
i.e.
gigaproject.zip will contain the following folders/structure/files.
Case 1:
com/company/project/gigaproject/9.8.0/linux/gigainstall
com/company/project/gigaproject/9.8.0/solaris/gigainstall
com/company/project/gigaproject/9.8.0/win32/gigainstall.exe
com/company/project/gigaproject/9.8.0/gigafile.dtd
com/company/project/gigaproject/9.8.0/gigaanotherfile.dtd
com/company/project/gigaproject/9.8.0/giga.jar
com/company/project/gigaproject/9.8.0/giga.war
NOTE: In case 1 example, I didn't use any -x.x.x in the filename (i.e. I'm using plain and simple giga.jar instead of giga-9.8.0.jar).
The above Upload/Deploy will result the files (as shown in the following snapshot):
So, we have achieved what we wanted. Actually (visibly speaking yes), but not in a way Artifactory usually stores these artifacts (as they should -x.x.x version embedded in the file name and where artifact id should match the artifact filename). Now, if you want to consume the following in a Gradle build file, you CANNOT as first, you haven't uploaded the filename with -x.x.x version name in it, secondly, the artifact id in our case 1 tree was "gigaproject" (after com/company/project folder), so Gradle way of defining what artifact id and what artifact file name you want won't work.
compile 'com.company.project:gigaproject:CANNOTSAY_HOW_TO_GET_GIGA_JARorGIGAINSTALL_with_without_extension'
Conclusion: It's possible to upload any files (with/without extension in Artifactory) in any structure but it depends how your build system will consume it or will be able to consume it or not.
- I deleted the structure I just created with case 1 .zip file from Artifactory repository to try next case#2 and deleted the .zip file I created.
Case 2:
Let's create an individual versioned file name for each artifact and also create structure in the format - how Artifactory actually stores them (an artifact as seen in a repository in a tree view) and create a .zip file containing that structure. Let's use the same "Artifact Bundle" feature to upload this .zip file to upload individual artifacts that we need in Artifactory - where artifact-id (second value which we mention while trying to consume it) would match the artifactfile name in Artifactory.
Folder/file structure for the .zip file:
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.linux
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.solaris
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.exe
com/company/project/gigafile/9.8.0/gigafile-9.8.0.dtd
com/company/project/gigaanotherfile/9.8.0/gigaanotherfile-9.8.0.dtd
com/company/project/giga/9.8.0/giga-9.8.0.jar
com/company/project/giga/9.8.0/giga-9.8.0.war
NOTE: This time, we'll be using the same "Artifact Bundle" feature and for similar files (gigainstall under both Linux/Solaris folders), I took the approach of creating gigainstall folder (containing gigainstall-9.8.0.linux and gigainstall-9.8.0.solaris file names) i.e. when we'll consume these artifacts in Gradle under dependencies { ... } section for compile, we'll use x.x.x# way to fetch these artifacts from Artifactory.
OK, once "Artifact Bundle" Deploy/Upload was successfully complete, I got the following message.
Successfully deployed 7 artifacts from archive: gigaproject.zip (1 seconds).
Now, let's see how it looks like in Artifactory while searching for one of the artifact/in Tree view. You can see we have the files now in place, with filename-x.x.x.extension way so that I can consume them easily in Gradle.
In Gradle build file (build.gradle), I'll mention:
dependencies {
compile "com.company.project:gigainstall:9.8.0#linux"
compile "com.company.project:gigainstall:9.8.0#solaris"
compile "com.company.project:gigainstall:9.8.0#linux"
compile "com.company.project:giga:9.8.0
compile "com.company.project:giga:9.8.0#war
compile "com.company.project:gigafile:9.8.0#dtd
compile "com.company.project:gigaanotherfile:9.8.0#dtd
}
OH OH!! - That didn't work, see below for Gradle error. Why? - Artifactory Bundle upload/deploy feature uploads a zip file content what you have in the .zip but it DOES NOT create a .pom file per artifact it deploys. Thus, making the Gradle build to fail. May be in Ant this might succeed. This occurred for each individual .jar/.war/.dtd/etc file. I'm just showing one error example.
While doing gradle clean build
Could not resolve all dependencies for configuration ':compile'.
> Could not resolve com.company.project:gigafile:0.0.0.
Required by:
com.company.project:ABCProjectWhichConsumesGIGAProjectArtifacts:1.64.0
> Could not GET 'http://artifactoryserver:8081/artifactory/ext-snapshot-local/com/company/project/gigafile/0.0.0/gigafile-0.0.0.pom'. Received status code 409 from server: Conflict
Case 3: Let's take a simple approach (workaround but will save a lot of pain).
Create gigaproject.zip file with the following structure, this approach takes - No x.x.x version value embedded in the individual artifact/filename in the folder/file structure. We will use "Single Artifact" approach (which will create the .pom for gigaproject.zip file automatically during the upload/deploy process provided by Artifactory). You'll still be able to get gigainstall file without needing any extension to its name using this approach. During the upload/deploy step, as you already have seen, you upload gigaproject.zip and artifactory will upload it to a given Target Repository as "gigaproject-x.x.x.zip" where x.x.x is 9.8.0 in our case. See the image snapshot below.
gigaproject/linux/gigainstall
gigaproject/solaris/gigainstall
gigaproject/win32/gigainstall.exe
gigaproject/gigafile.dtd
gigaproject/gigaanotherfile.dtd
gigaproject/gigaproject.zip
gigaproject/giga.jar
gigaproject/giga.war
Now, upload it in Artifactory using "Single Artifact" feature. Click "Deploy Artifact" once you tweak the values for GroupId, ArtifactId, Version, etc.
Once this is uploaded. You'll see in the zip artifact in the target repository (I took a bad example, usually this would be libs-snapshot-local or libs-release-local instead of ext-...), you'll be able to consume the ZIP artifact directly in Graddle:
dependencies {
// This is the only line we need now.
compile "com.company.project:gigaproject:9.8.0#zip"
}
Once the .zip is available to Gradle build system, now you can tell Gradle to unpack this .zip file somewhere in your build/workspace area where you can feed the actual(unpacked) files (gigainstall, .dtd, .jar, .war, etc.) to the build process/steps.
PS: Case# 1 and 2 would have worked for Ant I guess.
Answer 2:
If you have uploaded a non-extensioned file in either way. Make sure you have manually created/uploaded its POM file as well (i.e. if I uploaded gigainstall-9.8.0 as an artifact under com/company/project/gigainstall/9.8.0/gigainstall-9.8.0, then at the same level, I have to/should create it's POM file (see a simple template .pom file for a custom jar artifact or while uploading an extensioned file via "Single Artifact" deploy, you'll see what POM Editor window shows you) and upload both so that Gradle won't error out saying no POM conflict/error. Ant might not need pom (I didn't check that).
Once it's there in Artifactory, the following line should work -- OR comment please if you find another way.
dependencies {
// See nothing mentioned after - x.x.x#
compile "com.company.package:gigainstall:9.8.0#"
}
After adding Catel implementation to one of my views(mainPage) in my project I have a bug that crashes my Silverlight project. The only indication I have is :" A first chance exception of type 'System.NullReferenceException' occurred in Catel.MVVM " (just about after setting the RootVisual~) - I can't find what I'm doing wrong, and since I am planing on a long-term relationship with Catel I thought that stepping through Catel code might come in handy, so I tried and failed in all the following steps (any help will be appreciated.. because currently I'm stuck and can't find anything):
downloaded catel 3.9 source files (same as my nuget package) and tried building it.. failed with this error :
E:\Dev\Catel-3.9.0\src\Catel.Core\Catel.Core.SL5\Fody.targets(51,5): error MSB4036: The "Fody.WeavingTask" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with in the project file, or in the *.tasks files located in the "E:\WINDOWS\Microsoft.NET\Framework\v4.0.30319" directory. - trying to search and figure the reasons and overcome this, lead me to nowhere. :(
i have followed this "Stepping through the code" instruction in Catel documentation but noting really happened (I'm using VS2010..is this an issue ?? )
I read this article & readme.md at : https://github.com/GeertvanHorrik/GitHubLink about using GitHubLink to help you stepping through Catel code while debugging. I downloaded the release GitHubLink 1.3.0 from https://github.com/GeertvanHorrik/GitHubLink/releases/tag/1.3.0 ... but running this even with just the githublink.exe -help flag had thrown a exception..
I downloaded the Githublink-master source files but 0 projects were loaded (the GithubLink project file is incompatible with the current version of VS - I'm using VS2010)
can anyone help me either shade some light or:
overcome the build error I receive for catel (no.1)
instruct me how to set & step into catel ?
share the pdb files for Catel libs
It completely depends on the version you are using. If you are using the latest official one (3.9), stepping through the code is only possible by cloning the master branch and building the PDB files yourself.
In the latest prerelease versions via NuGet (the upcoming 4.0 version) you only have to enable the source server checkbox.
Note that you should never have to use GitHubLink yourself, that is for developers only (we run it during the build of Catel).
About the Fody task: it looks like the NuGet packages have not yet been restored on your side. In the lib folder there is a RestorePackages.bat which you can run to restore the packages.
I tried debugging on VS2012 and using Catel 4 pre-release (from Nuget)..
although I believe I did all the right things & settings in VS, I didnt get much further..
So I Opened (using a bin editor) the pdb file that was pulled by Nuget with the DLL, and took a look at the bin file.
the file have strings pointing to the source files at this directory :
C:\ci_ws\WS\1629\source\catel\src\catel/mvvm\catel.mvvm.shared..
So I have created a tree that starts with
c:\ci_ws\ws\1629\source
and downloaded the catel folder to that dir, renamed it from
"Catel-Develop" to just "Catel" in order to feet the location the pdb pointed.
To get things going I also had to add a "Symbol File(.pdb) location" in VS
option-> settings->Debugging->Symbols..(location/server list) to where the nuget download the packages.
in my case.. SolutionFolder\Packages\Catel.MVVM.3.9.0.1406062245-beta\lib\sl50..(I'm using Silverlight)
and then I was able to load the symbols and step/break into the code successfully ..
Maybe I missing something and there is a better way, but this the only way that worked for me..
The only question that still remains for me now is : What is the name of the Catel Github source branch that is matching the pre-release dll and pdb that Nuget is publishing at the moment (3.9.0.1406062245) ?
(I unchecked the general debug settings of : require source files to exactly match the original version)
I am unable to build my Web Application (not Web Site) in our build environement. We use DMAKE in our build environment (this unfortunately is non negotiable, therefore using MSBUILD is not permitted ) and when invoking the asp.net precompiler through
C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler -d -nologo -p Site -f -fixednames -errorstack -v / Debug
We get the following error
error ASPPARSE: Could not load type 'X.Y.Admin.Site.Global
If I compile from the ide it is successful. If i then compile with aspnet_compilier it is successful. So i only get a successful compile with aspnet_compiler when the target dll i am trying to compile is in the bin of the web application i am compiling.
I keep running into postings that talk about solutions using MSBUILD which unfortunately I cant try.
Any help would be appreciated
We had the same problem on our web application:
error ASPPARSE: Could not load type '...'
The problem was that we had the file on disk (on the project folder) but it wasn't included in our application project (in the .csproj file). We solved the problem by including the file in the project :)
I ran into a similar problem using NANT. The trick was to compile the web applications code files into a dll then include that when using aspnet_compiler.
use the command line compiler,either csc.exe (c#) or vbc.exe (visual basic), to compile your web application with an output of type library. This will create a dll that you can use in your aspnet_compiler task
Have you tried specifying the path using -p? Sounds to me like it can't find that type / assembly.
http://msdn.microsoft.com/en-us/library/ms229863(VS.80).aspx
For web applications, you have to build the .vb files into a dll and put that in the bin folder before you run the aspnet compiler. Check the output window in visual studio and you'll see the command line for the VB compiler. Run that first before you run the aspnet compiler, and the asp pages should be able to find the missing types.
This problem was resolved for me by simply deleting all bin and obj folders. Seems like they were in a bad state somehow. I also deleted the the .sou file, but I don't think that was the issue.
I received the same problem.
I fixed it by copying my webapp's DLL from the OBJ/DEBUG folder to the BIN folder.
I just had this error and found 2 ways to fix it, either:
Change the Codebehind attribute in the global.asax file to CodeFile and add "partial" to the class declaration
In the deployment project's property pages, set "Version output assemblies" and provide a version number
I don't really know why either worked, but it did.
solution :
-p Site path must have the directory path of .csproj file location.
ex :-
aspnet_compiler -p D:\Projects\MGM\mgm\mgm -v / D:\Projects\MGM-deploy\mgm_compiled