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.
Related
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.
Maybe I am trying to shove a round-peg into a square hole (as some of my research suggests) but I could not find any way to properly confirm or deny if what I am trying to do is possible or reasonable with Maven. Sadly, changing the nature of the project is not an option. Sorry for being verbose, but I want to make sure I explain the situation properly. I am somewhat of a maven newbie as well.
I have a multi-module project whose deliverable is separate .exe files for each of those modules. This project has different features depending on the client. Most are the same but some modules will include or exclude certain parts of code.
Hyper-Simplified Example
Client A
Module1
Module2
has feature x, feature y
Client B
Module1
Module2
has feature x, feature z
Currently, it is built with some batch files calling msbuild on pre-configured VisualStudio projects, which have the individual feature's source folders added to them.
Is there Maven-ish way of building the different versions individually without having to store the duplicate code like this example below?
project
+- root
| +- pom.xml
+- Module1
| +- pom.xml
| +- src
| | +- main
| | | +- c++
| | | +- include
+ Module2A
| +- pom.xml
| +- src
| | +- main
| | | +- c++
| | | | +- feature x
| | | | +- feature y
| | | +- include
+ Module2B
| +- pom.xml
| +- src
| | +- main
| | | +- c++
| | | | +- feature x
| | | | +- feature z
| | | +- include
Module2A and Module2B would both need to output Module2.exe
Ways that I have looked into possibly trying to use are profiles or some kind of inherited pom structure but neither seem to fit the bill. I really appreciate any insight someone has of techniques or plug-ins to help with this.
I have a multi-module Maven project (one level deep only). I like not to have to repeat the same things in all child projects, but how can I still do it (avoir repeating) when the parent project itself needs a different setting ?
The example I’m facing is when trying to produce a common folder for all artifacts and dependencies (but I can imagine other equivalent situations):
<properties>
<__.build.folder>../last_build</__.build.folder>
</properties>
Of course, this will lead to a situation where I have two last_build folder, one common to all child projects, one in the upper level folder.
How can I avoid that without having to duplicate the same setting in every child pom.xml ?
Can I use profiles ?
I don’t know, I’m new to Maven.
Thanks
Edit :
In this example, last_build is a subfolder of the folder containing the parent pom.xml. The child projects are all in other subfolders, from which last_build has to be addressed as "../last_build" - but not in the parent pom.xml !
|
*--rootFolder
| |
| *--last_build // aggregation folder
| |
| *--subProject1
| | |
| | *--pom.xml (../last_build)
| |
| *--subProject2
| | |
| | *--pom.xml (../last_build)
| |
| *--subProject3
| | |
| | *--pom.xml (../last_build)
| |
| *--pom.xml (last_build) // different here for the parent project
I don't think you're proceeding down a very useful path and I think that you may be confused about a few things.
First, at the highest level, your root or parent pom, there should be no project, no code, no resources, and no artifact, so there should also be no output or need for an output directory. All you should have at the highest level is the parent pom and subdirectories containing modules.
The next problem is that you think you need a common build folder. I am hard pushed to imagine a rational scenario where that would be necessary. The artifacts one typically builds in maven are self-contained jars/wars -- one per module, and these are cached in the local repo whenever you build through the install lifecycle. They can be used in situ from there.
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 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.