I am on play 2.5.2
I know that the default packaging system do expect something like :
app/
controllers/
models/
views/
But I would like it to be :
app/
foo/
controllers/
models/
views/
How can I achieve this ?
Over there : https://www.playframework.com/documentation/2.5.x/Anatomy
They do say that :
Note that in Play, the controllers, models and views package name conventions are now just that and can be changed if needed (such as prefixing everything with com.yourcompany).
But that doesn't tell me how.
Thanks
You can just place your controllers, models and views in the desired package. No additional configuration is needed. When writing your routes file you will have to prefix the entries with the package though. So instead of writing
/foo controllers.FooController.bar()
You'll have to write:
/foo foo.controller.FooController.bar()
Related
I am new to the sbt and mill, and I am practicing to use both tool to build the chisel (scala project). View this github repo as a reference, I am wondering to know how to write the mill-version build.sh in that repo.
Here is my directory structure
─ chisel-template (root directory / projects directory)
├── build.sc
├── build.sh
├── src
| └─main
| └─scala
| └─lab1
| └─Mux2.scala
└── _temphelper.scala
What the build.sh do is preparing a boilerplate as main function in the root directory to make compile and run process much easier, and it's sbt version. I'm curious that why sbt can detect the main function (_temphelper.Elaborate) even it's not in the src/main directory. And when I change to use Mill, Mill can't detect the _temphelper.scala at all, unless I move the file to root/src/main. Is there settings that can make Mill do what sbt can do?
I'm not sure whether this issue is related to...
altering the sourceDirectories in sbt and chiselMoudule.sources in Mill. Any advice is welcome.
modify the millSourcePath to realize my request.
My quetions is What setting should I do to make mill can detect the main class that be in the root directory?
This is because sbt is including any Scala files it finds in the project root directory as sources files, unless told otherwise.
In contrast, Mill will only use the source files found under whatever directories are specified with sources. As a consequence, you may want to add the project root directory as source directory, but I strongly advice to do not so.
Best is to move the _temphelper.scala file either to one of the source directories or create a new dedicated directory, move the file there and add this directory to the sources like this:
object chiselModule extends CrossSbtModule // ...
{
def sources = T.sources {
super.sources() ++ Seq(PathRef(T.workspace / "your" / "new" / "directory"))
}
}
I'm little confused by various terminologies used in the SystemJS configuration. It talks about module, location, package etc...
Isn't module in JS is a single file, and package is a collection of modules or files? If so, how a module can be an alias to a package?
This is from the documentation page:
The map option is similar to paths, but acts very early in the normalization process. It allows you to map a module alias to a location or package:
Yes module is a single file, in javascript it's just the file name (with assumed .js extension) in quotes after from keyword in
import ... from 'some-module';
In SystemJS config file, paths and map can be used to define what actual file or URL that some-module refers to.
packages in config file allow you to apply a set of configuration parameters (default extension, module format, custom loader etc) for all modules in or below particular location (the key in packages object).
One of the settings in packages is main, which is similar to main in package.json in node (except that it's default value is empty, not index.js): it determines which file is loaded when the package location itself appears in from in import statement.
So, I think "how a module can be an alias to a package?" question about this
The map option is similar to paths, but acts very early in the
normalization process. It allows you to map a module alias to a
location or package:
can be explained on this example:
paths: {
'npm:': 'node_modules/'
},
map: {
'some-module': 'npm:some-module'
},
packages: {
'some-module': {
main: './index.js'
}
}
when these map, packages and path settings are applied by SystemJS to
import something from 'some-module';
they will cause SystemJS to load a module from node_modules/some-module/index.js under baseURL.
and
import something from 'some-module/subcomponent';
is mapped to node_modules/some-module/subcomponent.js.
Note: this is based on my experience with SystemJS 0.19. I haven't tried 0.20 yet.
I have a Swift library with a core module plus optional bonus modules. I would like to use the following directory layout, mapping to exported Swift package names as shown:
Taco/
Source/
Core/ → import Taco
Toppings/ → import TacoToppings
SideDishes/ → import TacoSideDishes
To my eyes, that’s a sensible-looking project layout. However, if I’m reading the docs right, this will pollute the global module namespace with unhelpful names like “Core”. It seems that SwiftPM will only export a module whose name is identical to the directory name, and thus I have to do this:
Taco/
Source/
Taco/
TacoToppings/
TacoSideDishes/
Is there a way to configure Package.swift to use the tidier directory layout above and still export the desired module names?
Alternatively, is it possible to make the Core, Toppings, and SideDishes modules internal to the project, and export them all to the world as one big Taco module?
There is not currently a clean way to do this, but it seems like a reasonable request. I recommend filing an enhancement request at http://bugs.swift.org for it.
There is one "hacky" way you can do this:
Create your sources in the desired internal layout:
Sources/Core
Sources/Toppings
Add additional symbolic links for the desired module names:
ln -s Core Sources/Taco
ln -s Toppings Sources/TacoToppings
Add an exclude directive to the manifest to ignore the non-desired module name:
let package = Package(
name: "Taco",
exclude: ["Sources/Core", "Sources/Toppings"]
)
is it possible to make the Core, Toppings, and SideDishes modules internal to the project, and export them all to the world as one big Taco module?
No, unfortunately there is no way to do this currently, and it requires substantial compiler work to be able to support.
I have three GWT modules that will have some code in common - typically domain classes - and also share the same server instance. My first thought was to organize it like this:
app1/client/
app2/client/
app3/client/
server/
shared/
The modules would then have in their descriptors:
<source path = "client"/>
<source path = "../shared"/>
But it seems like that the ../shared path is not working.
Is this the way to go, or are there better ways?
I found at least on solution that works: Have all the modules in the same package, like this:
client/app1/App1.java
client/app2/App2.java
client/app3/App3.java
app1.gwt.xml
app2.gwt.xml
app3.gwt.xml
server/
shared/
I still kept subpackages app1, app2 and app3, but that's off course optional.
With this organization the module descriptors should say:
<source path = "client"/>
<source path = "shared"/>
Let's say that I want to define a module "Pair" in com.mycompany.common such that the source is located in com.mycompany.common (and not com.mycompany.common.client). How would I do this? Alternatively, let's say that I have the flexibility of defining the module "Pair" in com.mycompany instead while still having the source in com.mycompany.common.
Thanks to a quick search on google, I found the answer myself. One can add a source path tag to the module xml file to define the source directory instead of leaving it to the default "client." For example, Pair.gwt.xml would look something like this:
<module>
...
<source path="."/>
...
</module>
... if we wanted the gwt.xml file to be in the same directory as the source.
But when compiling this module, we get a "Non-canonical source package: ./" warning. Is this ok to ignore?