I decided to push a .NET Standard class library to an existing local NuGet repo at my workplace.
I did it by having the NuGet package automatically pushed after the build in Visual Studio:
nuget push [PACKAGE_FILENAME] -Source [REPO_ON_THE_NETWORK]
Prior to my push, there were 3 pre-existing packages for other projects in the repo. After my push, the only project visible - via the NuGet Package Manager UI in Visual Studio - was the one I just pushed. I can consume my project from the NuGet repo without issues.
I took a look in the folder itself on the network, and this is what I saw:
[ ] Repo
|
|_ [ ] Proj1
| |
| |_ [ ] v1.0.0
| | |
| | |_ [ ] lib
| | | |
| | | |_ [ ] net20
| | | | |
| | | | |_ .dll
| | | | |_ .pdb
| | | |
| | | |_ [ ] net46
| | | |
| | | |_ .dll
| | | |_ .pdb
| | |
| | |_ .nupkg
| | |_ .nupkg.sha512
| | |_ .nuspec
| |
| |_ [ ] v1.0.1
| |
| |_ .nupkg
| |_ .nupkg.sha512
| |_ .nuspec
|
|_ [ ] MyRecentlyPushedProj
|
|_ .nupkg
I have three questions:
Why are the folder's organized in such different ways? Notice how one folder has a sub-folder with the actual project binaries, while the others don't. Also notice how my recently-pushed project lacks everything except for the NuGet package file.
When we manually delete the recently-pushed project from the repo, then the old projects reappear in the NuGet Package Manager UI. Does having differently-organized folders mess with NuGet's ability to scan the repo? Has the way NuGet organizes the projects changed over time (with newer versions)?
How am I able to consume the recently-pushed project successfully without the folder containing any of the binaries?
From the hierarchy tree you drew, I can see some differences:
Your package doesn't come with a version.
Your package doesn't have a lib folder.
Now, there are two ways of publishing a NuGet package with NuGet CLI: push and add.
The main difference is that add is for non-HTTP package source (as stated on MSDN) and that it publishes the package in a hierarchic manner, while push doesn't always (and it usually depends on how the feed was initialized).
My recommendation is that you check the documentation I added, and based on that decide whether to use one command or the other. From what I can gather, you should use add.
Hope this helps.
Related
I have a install program looks like
SomeRoot
|_ customSetup.exe
|_ \productA
| |_ productA.msi
| |_ setup.exe
| |_ ISSetup.dll
| |_ setup.ini
| |_ <other file generated by installshield..>
| ...
When user use customSetup.exe to install productA, customSetup.exe will call \productA\setup.exe.
Sometimes, when User have already installed productA, and customSetup.exe
have to uninstall productA first, but the installshield's uninstall string
not found, customSetup.exe will call 'msiexec /x' to uninstall productA.
Under the mentioned situation, I found files under \productA was copied to SomeRoot, I have no idea how it works.
Can someone help me with the following:
I have 2 private git repositories private1 and private2.
I need to import a package from repo private1 into private2.
Structure of repo private1 is as follows :
private1 --
|
|- actions --
| | - go.sum
| | - go.mod (github.xyz.com/private1/actions)
| | - commons -- (package commons)
| | - commons.go
|-operations--
| | - go.sum
| | - go.mod (github.xyz.com/private1/actions)
| | - interceptor --
| | - interceptor.go
I want to import package 'commons' in my other repo private2.
What should be added to the go.mod of repo private 2?
if i use 'github.xyz.com/private1/actions' , i get the following error
go: github.xyz.com/private1/actions#v0.0.0-20211203184031-723259d523a2: unrecognized import path "github.xyz.com/private1/actions'": reading https://github.xyz.com/private1/actions?go-get=1: 404 Not Found
Since your modules/packages are in a private git repositories you cannot access them directly, you either have to download the modules locally and use them or publish them so that you (and others) can use.
How to guides:
Developing and publishing modules
Call your code from another module
I have a scenario where its step definitions resides in multiple files. For instance the login step resides in login_steps.rb and a search related step resides in search_steps.rb
Cucumber outputs undefined steps for any step that is not in login_steps.rb. The step definitions are run only when its present in login_steps.rb. Is it required to place all the step definitions of a scenario in the same file?
My folder structure
Project folder
└─ features
├─ pages
├─ scenarios
├─ step_definitions
└─ support
Command I used:
cucumber -r features features\scenarios\Test.feature
The whole point to Cucumber and the POM is that you have flexibility and do not need to re-write your steps per feature file. This is what my directory structure looks like:
Root
- features
- step_definitions
- step_definition.rb
- support
- env.rb
- lib
- BasePage.rb
- feature.feature
Basically, with this directory structure, it doesn't matter where your step definitions are AS LONG AS YOU REQUIRE THE SPECIFIC PAGE YOU'RE REFERENCING (your BasePage.rb file, for example)
require File.join(File.dirname(__FILE__), '..', '..', 'lib', 'pages', 'BasePage')
And /^I do something$/ do
#page = BasePage.new(#test_env)
#page.verify_el(css)
end
I'm not familiar with the specifics of RoR and cucumber, but I do use cucumber-jvm. Using steps from different files is supported. Note the documentation https://github.com/cucumber/cucumber/wiki/Cucumber-Backgrounder#where-do-i-put-tests specifically mentions it.
Sorry I can't be more help with the specific issue, but what you are trying to do (use step from different files) is workable.
This might be a "violation" but I would combine the answers from Whitney Imura and Dave W just to make the answer more clear...
You ask:
"Is it required to place all the step
definitions of a scenario in the same file?"
No. You can place your step definitions in logically distinct files within various folders, as you see fit (example below). After all, it is just ruby code.
Essentially Your command is correct for running an individual feature that has step definitions in various other folders...
cucumber -r features features\entities\entity.feature
If you do not run it as above, you will get missing stepdefs... Here I execute tests on a current project as a means to demonstrate:
cucumber
60 scenarios (14 undefined, 46 passed)
409 steps (32 skipped, 26 undefined, 351 passed)
cucumber -r features
60 scenarios (60 passed)
409 steps (409 passed)
As described in the Cucumber documentation, you can arrange your tests to suite your logical breakdown of your features:
|__ features
| |__ entities
| | |__ entity.feature
| | |__ step_definitions
| | |__ anything.rb
| | |__ entity_steps.rb
| |__ locations
| | |__ location.feature
| | |__ step_definitions
| | |__location_steps.rb
| |__ sites
| | |__ step_definitions
| |__ step_definitions
| | |__ local_assert_steps.rb
| | |__ local_crud_response_steps.rb
| | |__ local_email_steps.rb
| | |__ local_file_steps.rb
| | |__ local_script_steps.rb
| | |__ local_steps.rb
| | |__ local_web_steps.rb
` | |__ local_xml_file_steps.rb
|__ support
|__ env.rb
|__ local_env.rb
|__ local_transforms.rb
I'm trying to create a war that is to be deployed in an EAR and that should contain only images.
My war source organization is as follows :
+---src
| +---main
| | +---java
| | +---resources
| | | \---META-INF
| | | \---resources
| | | \---images
| | | placeholder_image.jpg
| | | placeholder_template.png
| | |
| | \---webapp
| | \---WEB-INF
| \---test
| +---java
| \---resources
and my war effective organization is
+---META-INF
\---WEB-INF
\---classes
\---META-INF
\---resources
\---images
placeholder_image.jpg
placeholder_template.png
The images I want to serve are in the src/main/resources/META-INF/resources/images folder.
I package this war using maven-war-plugin.
Under which url will those images be available on my local machine, provided my war is indicated as available under the http://localhost:8080/myapp/ path ?
None. Content from WEB-INF is not statically served, resources is for classpath resources. You need to put the images (folder) directly under webapp or add an servlet that serves the content.
This depends on whether you deploy the war in a Servlet-3-compatible container like Tomcat 7 or Jetty 8.
If so, your resources should be visible under http://localhost:8080/myapp/images/....
See also this post, where the only difference is that the resources are packaged in a jar. For jars, this feature makes more sense than for WEB-INF/classes, as, like the first answer points out, you should simply put your resources directly into src/main/webapp if they are located in the same Maven module.
I have project like this.
MainProject
|
+- SubProject1
|
+- SubProject2
|
+- SubProject3
And i am trying to execute MVN SITE command. I am able to setup all other section in Project Information Section.
All sub module's POM.XML have SubProject1 entry for this.
that's why i am able to see that module name in Project Modules Section.
But when i am trying to click the submodule link it's looking for HTML file under PARENT PROJECT so something like this.
MainProject/target/site/SubModule1/index.html
Actually that location i don't find anything. So what is the correct approach for MultiModule structure SITE creating ?
Looking for some good multi module material or website to read on this and which can fix my issue. Or if you have guys have any POM.XML to use it please post it here.
Indeed, the hierarchy in your IDE (Eclipse ?)does not follow the one which will be produced if you run site:deploy (using the distributionManagement section).
When you will generate the site with site:deploy, it will put all elements in (up to apache http server conventions for example) :
/var/htdocs/
|
+- /MainProject
|
+---/SubProject1
| |
| +--- /index.html
|
+--- /SubProject2
| |
| +--- /index.html
|
+--- /SubProject3
| |
| +--- /index.html
|
+--- /index.html
And you have physically in your workspace :
D:/workspace/
|
+- /MainProject
|
+---/SubProject1
| |
| +--- /target
| | |
| | +--- /index.html
|
+--- /SubProject2
| |
| +--- /target
| | |
| | +--- /index.html
|
+--- /SubProject3
| |
| +--- /target
| | |
| | +--- /index.html
|
+--- /target
| |
| +--- /index.html
So, you have one level more between root projects and file than when it's deploy. This structure is not suitable for links which are created aiming a site:deploy :)
If I'm mistaken on your issue, tell me, but it sounds like quite common.