Is there a reason to adopt a flat layout in GAV of webjars ?
I mean, all groupId are set to "org.websjars". I like to contribute to webjars with polymer elements (core & paper). Its about 132 artifacts ...
I would like to use groupId like:
org.webjars.polymers.polymer
org.webjars.polymers.core
org.webjars.polymers.paper
org.webjars.polymers.misc
org.webjars.polymers.labs
org.webjars.polymers.deprecated
Good or bad idea / practice ?
Thanks
We've always used just org.webjars since there isn't a concept of a groupId in JS package repositories. That way the artifactId can correspond to the NPM / Bower artifact name. The only plans we have for using a different groupId are when we do a Bower sync where we'd make the groupId = org.webjars.bower.
Related
Sometimes I see extensions loading from the internet or built-in ones.
Canonical example:
load("#bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
However, I cannot distinguish local repo and known repo by looking at the load expression.
How can I check the source (location) of any repo which I see in my WORKSPACE/BUILD files?
If the Bazel label is sufficient as a source, you might try fetching repo roots with BUILD files with bazel query 'buildfiles(//...)'.
Otherwise, you could run bazel clean --expunge and run a build with --experimental_execution_log_file=<FILENAME>. This creates a protobuf based log of the actions by Bazel. In there, all internet repos are downloaded anew because of clean --expunge.
Check https://github.com/bazelbuild/bazel/tree/master/src/tools/execlog for a parser.
It is super inconvenient that this information is not available another way - afaik. I really hope someone swings by and corrects me, but this way you at least know the available sources you can correlate.
I'm new to Bazel, but as far as I understand:
Copy the name of the repo. E.g. io_bazel_rules_docker
Search it through the codebase
Look at how it's being loaded
E.g. if you see
http_archive(
name = "io_bazel_rules_docker",
...
)
http_file(
name = "io_bazel_rules_docker",
...
)
And you can conclude where it's coming from.
bazel query --output=build //external:repo_name works just fine.
I'm writing a post-build tool that synthesizes maven pom files after a bazel build. I'm using aspects to gather relevant information on the various targets.
One of the features involves adding external jar dependencies to the relevant pom files.
Lets assume our workspace contains the following target:
maven_jar(
name = "com_google_guava_guava",
artifact = "com.google.guava:guava:19.0",
)
and one of our BUILD files contains a target which has guava as a dependency
scala_library(
name = "somename",
srcs = glob(["*.scala"]) + glob(["*.java"]),
deps = [
"#com_google_guava_guava//jar:file" ,
],
In an aspect for this target how can one retrieve the attributes of maven_jar, specifically artifact?
(The closest I was able to get was:
[InputFileConfiguredTarget(#com_google_guava_guava//jar:guava-19.0.jar)]
Using ctx.rule.attr.srcs)
I could probably just parse the workspace external jars targets and get a map from the name to the artifact as a hybrid solution,
but a much more elegant solution would be for the aspect to provide the artifact by itself. Is it possible?
The "artifact" attribute is an attribute of a repository rule, which are not accessible from Skylark. The artifact seems like an information that could be integrated into the jar target in some way, feel free to file a feature request at https://github.com/bazelbuild/bazel/issues/new, with the reason why you need that.
I want to copy the list of users specified as Component Watchers (with the plugin of the same name) into the list of Watchers, at issue creation time. I'm trying to do this with a Script-Runner post-function, after creating a custom field of type Component Watchers.
The part that I'm missing is how to obtain the Component Watchers usernames as a list. Any idea?
Try the Behaviours plugin. There you can specify "behaviour"-s, that can be mapped to projects and issue types, and there you can specify Groovy Scripts to run during transitions.
It won't be easy, but it is versatile and does not eat too much resources.
i use one Neos installation for multiple domains with different content.
duplicating the package TYPO3.NeosDemoTypo3Org, removing the node-identifier and doing some replacements brought me nearby everything i need.
But only the first Settings.yaml found in Packages/Sites/ seems to be parsed. All changes to the Settings.yaml found in other packages (Test1 and Test2 in the following example) are ignored.
Packages/Sites/TYPO3.NeosDemoTypo3Org/Configuration/Settings.yaml
TYPO3:
Form:
yamlPersistenceManager:
savePath: 'resource://TYPO3.NeosDemoTypo3Org/Private/Form/'
Packages/Sites/UDF.Test1/Configuration/Settings.yaml
TYPO3:
Form:
yamlPersistenceManager:
savePath: 'resource://UDF.Test1/Private/Form/'
Packages/Sites/UDF.Test2/Configuration/Settings.yaml
TYPO3:
Form:
yamlPersistenceManager:
savePath: 'resource://UDF.Test2/Private/Form/'
When i delete the first Settings.yaml (Packages/Sites/UDF.Test2/Configuration/Settings.yaml), the next Setting.yaml in alphabetical order (Packages/Sites/UDF.Test1/Configuration/Settings.yaml) is used for all 3 site packages. When i also delete this file, the Settings.yaml from UDF.Test2 is used and so on.
would be awesome if somebody can enlighten me. I am new to flow and neos and any help is welcome. RTFM, i know, but as described here i have to believe, that it should work like i did?
alternative way?
is it possible not to set the savePath in the site package configuration but in the common settings ./Packages/Application/TYPO3.Form/Configuration/Settings.yaml
I see a {#package} placeholder in
### BASE ELEMENTS ###
# NAMING: base class for everything is RENDERABLE
'TYPO3.Form:Base':
renderingOptions:
templatePathPattern: 'resource://{#package}/Private/Form/{#type}.html'
but this doesn't work here
TYPO3:
Form:
yamlPersistenceManager:
#savePath: '%FLOW_PATH_DATA%Forms/'
savePath: 'resource://{#package}/Private/Form/'
as you see i am not really experienced with this stuff but i am very motivated.
All Settings.yaml are used, but the settings are merged in order of the package loading.
The loading order of packages again is based on their dependencies.
All three packages probably have the same dependencies so they are loaded one after the other (would need to check with which ordering), so third Settings.yaml is loaded, then second Settings.yaml is loaded and overwrites the third, then the first is loaded and again overwrites the second. Every setting path can only be set once, that's why.
In any case what you are trying to archive probably won't work. This is one of the things we have to fix (site package dependent configuration).
A possible workaround is either using a common package with the form configuration and just set the savePath to this package or using diferent subcontexts (like Production/Domain1 Production/Domain2) and setting this setting different per subcontext, then you could define the subcontext by domain (as the sites are triggered by domain anyway).
I have installed Jenkins for my projects. The automatic build and deployment is happening successfully.
I would like to get following data:
No. of classes with lines in the range 0-50
No. of classes with lines in the range 301-500
No. of classes with lines in the range 501-1000
No. of classes with lines > 1000 etc.
I'd like the same things for methods: Eg: No. of methods with lines in the range 0-50
How can I get this data?
Please let me know.
I suggest you use http://cloc.sourceforge.net/
You can then extract the data as SQL data import it in a H2 database (in-memory) to
group accordingly to your needs.
Perhaps more than you need, but have you looked at Sonar? (http://www.sonarsource.org/) It integrates with your build, and can provide the metrics you're looking for and a lot more besides.
There are several other useful and easy to use tools:
javancss: A Source Measurement Suite for Java http://www.kclee.de/clemens/java/javancss/
ckjm: Chidamber and Kemerer Java Metrics http://www.spinellis.gr/sw/ckjm/
Some relevant tools:
classycle - http://classycle.sourceforge.net/
jdepend - http://clarkware.com/software/JDepend.html
You can also use XRadar to aggregate all these report and get something called "Project health". XRadar also supports previously mentioned CLOC
I do not know if the issue is still relevant to you. The other responses do not address Jenkins. There are several plugins for Jenkins, such as http://www.dwheeler.com/sloccount/. After you install the plugin, you can retrieve code metrics via the Jenkins REST API.