I would like to specify credentials for a single URL in http_archive, using a netrc file contained in my workspace. I have tried the following without success:
I have tried to specify the "userinfo" part of my URL like http://<user>:<password>#host/path just to get an authentication error.
I have tinkered with the netrc attribute of http_archive, but I can only see, how to use absolute pathnames there; I would prefer to include the netrc in my workspace.
Do I have to write my own repository rule or is there another way?
In the meantime, I have created my own repository rule because I could not find a simple alternative. That went well, but comprehensive documentation for repository_ctx.download_and_extract is lacking, so it turned out to be trial and error ;-).
Take a look at this PR named "Readd support for authentication and .netrc". It seems to contain a improved version of the http_archive that supports .netrc files.
def _http_archive_impl(ctx):
...
"netrc": attr.string(
doc = "Location of the .netrc file to use for authentication",
),
...
I do not know the current status of this feature - maybe its already part of the newest Bazel version (at the time of writing this post 3.4.1)
Related
(Sample) Problem:
When a yaml source contains conflicting definitions, e.g. myClass and MyClass both generating into a java class MyClass with one overwriting the other, no warning or error occurs.
Other similar cases can occur the same way (e.g. via implicitly generated classes from complex entries of type: array).
Framing
has to work without modifying the source file
there is exactly one source file, for whatever that's worth
has to work as a Maven plugin
tested with swagger-codegen-maven-plugin 2.4.0 and 2.4.22
am familiar with JAXB2 and both of its common Maven plugins:
jaxb2-maven-plugin
maven-jaxb2-plugin
am not familiar with swagger-codegen-maven-plugin
did not find solutions (or even corresponding problem reports) using Google searches
swagger codegen strict
swagger-codegen-maven-plugin strict
swagger codegen name collision
swagger-codegen-maven-plugin name collision
swagger codegen resolve name collision
swagger-codegen-maven-plugin resolve name collision
found this closed issue describing a similar issue (silently generates corrupt code), which appears to be mostly unrelated and is alledgedly long fixed
Question
What is the proper solution that produces
an eagerly failing generation process
amended via externally configured customBindings
without touching the yaml source file
?
Solution ideas:
Use JAXB2 instead
JAXB2
fails generation where a generated file already exists
allows a separate customBindings.xjs file to modify generation of
classes
can be adapted to work with YAML using
JacksonJaxbYAMLProvider
However it seems that the common Maven plugins jaxb2-maven-plugin and maven-jaxb2-plugin do not support YAMl definition files (out of the box?). [1]
Use Mustache files to resolve the name collision
The Mustache language seems to provide the necessary facilities to implement rules similar to JAXBs xjb.
However
binding a Mustache template to a class has to be done by name (<class name>.mustache), aka. name collision in particular cannot be resolved from an external file [2]
this does not help with the silence of errors in generated code - one cannot fix the error, while unaware of it
1 - Searches for this topic have yielded one result that it does not work out-of-the-box (duh) and no results whether it can be made to work using the extensions interface both plugins support.
2 - I could not find the relevant part directly within Swagger codegen documentation, but here is a relevant part of the implemented-by-Swagger OpenAPI generator documentation.
I'm trying to build a CCTray/CCMenu clone in Electron and want to know if there's a spec document for parsing the XML document? I can get much of it from checking my Travis version, but I'd like to know the actual spec
Our source code sadly has outdated info. A quick search reveals https://github.com/erikdoe/ccmenu/wiki/Multiple-Project-Summary-Reporting-Standard, which claims to have resurrected the "lost" standard.
Yes, the spec for CCTray is available from here: https://cctray.org/v1/
We have an growing swagger API/openAPI and for documenting changes we like to document on a path or parameter (and perhaps definition) since which version of the API it is available.
The swagger specification knows the info.version field, but on paths or parameters I could not find something refering to this version.
Perhaps vendor extensions beginning with a x-... like x-since might be helpful. At least validation does not fail using them.
But is there perhaps any existing implementation for this use case?
I'm not aware of any existing attribute in OpenAPI/Swagger 2.0 spec to meet your need so you should go with vendor extensions (x-since, x-created-on, x-created-by, etc)
This is part of an ongoing project... splitting out domain objects so they can be consumed by multiple applications. The database migration files for the domain objects live with the plugin... but we want the apps to be able to reference them during a dbm-update.
I can get the application to recognize the plugin changelog, but after that, the changelog does not perform includes and process them as I expect.
Using GrailsPluginUtils I am able to get the path of the plugin and the plugin changelog, with which I do an include file. If I put the changeSet right in that file I am good, it runs. If I move it to a separate file in the same folder, or in a sub-folder, and reference it via "./someFile.groovy" it seems to FIND it but does not process it. I say it seems to find it because if I do NOT use a relative file path, the migration process throws an error saying it cannot find the file e.g., "someFile.groovy"...
I have workarounds but they are not acceptable because we want to control the order of how the DB migrations occur by using sub-directors with a _changelog.groovy that then includes the actual transformations (changeSets). But they are not being "include"ed.
If I use includeAll, it will grab any and all scripts in that one folder, but again, does not process any other includes referenced therein. I can write a script to scan the folders recursively but again, that requires a lot of coding to parse the _changelogs and grab the appropriate inclusion order, etc.
I really just want "include file:" to work as it does in a given application for its own changelog files.
Has anyone else done this? Am I missing something terribly obvious?
In the app...
databaseChangeLog {
...
include file: "${GrailsPluginUtils.pluginInfos.find { it.name == 'my-plugin' }.pluginDir}/grails-app/migrations/my_plugin_changes"
}
... in the plugin...
databaseChangeLog {
include file: "./someChangeLogChangeSet.groovy"
}
Thank you...
We had also tried adding changelog files to the plugin where our domains live but were unable to access it from the main app. However, if you want to access your files from other location then you could specify this property in your config file and give the folder name here Or even copy all the migrations to the appropriate location to the main app.
grails.plugin.databasemigration.changelogLocation = 'migrations'
If you do find a actual solution to this, please post it.
How to configure JIRA_HOME? I'm getting an error:
Configured jira.home '/Users/codedroid/Downloads/atlassian-jira-5.1-standalone' must not be a parent directory of the webapp servlet path '/Users/codedroid/Downloads/atlassian-jira-5.1-standalone/atlassian-jira'
Changed it and now I get this:
Configured jira.home '/Users/codedroid/Downloads/atlassian-jira-5.1-standalone/atlassian-jira' must not be the same as the webapp servlet path '/Users/codedroid/Downloads/atlassian-jira-5.1-standalone/atlassian-jira'
Have a look in here, if you're still having troubles please write what did you set JIRA_HOME to be and where did you defined it, thanks.
EDIT
Yea, that documentation is more of 'how to' instead of 'what'. A better explanation of what the JIRA_HOME should be is writen in more details here.
Anyway, if you feel that the documentation are confusing or just bad, you could do everyone a favour and write it at the bottom of the page, under comments, so other could see it easily.
The JIRA documentation does NOT! make it clear even to a seasoned programmer that this JIRA_HOME directory is referring to a data directory and not the installation directory. If there are any JIRA folks out there please fix this outragious misunderstanding in your documentation. JAVA_HOME refers to you guessed it the installation location of java. Its called a 'convention' if you want to invent some other meaning please say so it your documentation and don't wast valuable developer time on installing your productivity tool. Think its not a problem? Google 'must not be the same as the webapp servlet path' and see what you get back. Thanks for wasting my afternoon, and no doubt the time of many others.
(warning) However, avoid locating the JIRA Home Directory inside the JIRA Installation Directory.
This appears in only documentation point and is not the first place people look as noted above
Just create a folder named JIRA, then set the environment variable JIRA_HOME as D:\JIRA, as well as the application properties file.
# jira-application.properties
jira.home = D:\\JIRA
Don't be confused with the JAVA_HOME, JIRA_HOME has absolutely nothing to do with the folder of your zip ball downloaded from official website.
JIRA_HOME is an empty folder where JIRA will create everything it needs in a RUNTIME.
It is NOT a folder where your unpacked JIRA distribution resides.
P.S. yes it is confusing still in 2021