If I have a package called xx.yy.product to group all product-related beans together, will it be against Java standards to have a bean called Product also within same package?
xx.yy.product
|
|-> Product.java
|-> ProductCategory.java
|-> ProductAlert.java
...
Thanks,
Paddy
No, it doesn't break any Java standard.
In your example, which is correct, packages are written with lower case. So you have com.xxx.product
According to Java standard class should start with uppercase letter. In this case Product. So it is clear that com.xxx.product refer to package and com.xxx.product.Product refer to class.
Related
Currently in our project we have layered architecture implemented in following way where Controller, Service, Repository are placed in the same package for each feature, for instance:
feature1:
Feature1Controller
Feature1Service
Feature1Repository
feature2:
Feature2Controller
Feature2Service
Feature2Repository
I've found following example of arch unit test where such classes are placed in dedicated packages https://github.com/TNG/ArchUnit-Examples/blob/master/example-junit5/src/test/java/com/tngtech/archunit/exampletest/junit5/LayeredArchitectureTest.java
Please suggest whether there is possibility to test layered architecture when all layers are in single package
If the file name conventions are followed properly across your project, how about you write custom test cases instead of using layeredArchitecture().
For Example:
classes().that().haveSimpleNameEndingWith("Service")
.should().onlyBeAccessed().byClassesThat().haveSimpleNameEndingWith("Controller")
noClasses().that().haveSimpleNameEndingWith("Service")
.should().accessClassesThat().haveSimpleNameEndingWith("Controller")
I know this question is rather old. But for the record, this has been possible for a while using predicates for the layers, e.g.
layeredArchitecture().consideringAllDependencies()
.layer("Controllers").definedBy(HasName.Predicates.nameEndingWith("Controller"))
.layer("Services").definedBy(HasName.Predicates.nameEndingWith("Service"))
.layer("Repository").definedBy(HasName.Predicates.nameEndingWith("Repository"))
.whereLayer("Controllers").mayNotBeAccessedByAnyLayer()
.whereLayer("Services").mayOnlyBeAccessedByLayers("Controllers")
.whereLayer("Repository").mayOnlyBeAccessedByLayers("Services")
However, I'm not sure how well this works in practice. Because usually you don't just have classes following this naming pattern and that's it. A service might also have some POJO as method parameter type (e.g. MyInput) and that should maybe for example not be used by repositories as well. Also, using forward dependency rules (mayOnlyAccessLayers(..)) this might then cause unwanted violations.
In Short:
Is there any preferred naming convention for cmake library targets - in particular when using namespaces?
Note:
Unless there is really an objective reason for it, I'm not asking about personal preferences, but whether there is either an "official" (e.g. recommended by kitware) or established (which might deviate) convention.
Details:
Lets say I have a library/framework foo which has the individual components bar and baz. So far, my naming convention looks like this:
add_library(foo-bar src1.cpp, scr2.cpp)
add_library(foo-baz src3.cpp, src4.cpp)
Now I want to add alias targets using the namespace (::) convention. E.g.
add_library(Foo::Bar ALIAS foo-bar)
add_library(Foo::Baz ALIAS foo-baz)
(Of course the question also extends to export sets, but I didn't want to complicate the question)
What I couldn't really find out however, is if there is a preferred or even official naming convention for those targets.
Things I've seen:
Namespace part:
some projects seem to capitalize the first letter, some not (the former seems to be more common)
Component part:
in some projects, the component name is the same as the binary name
with or without the "lib" prefix (libfoo-bar vs foo-bar)
with or without the namespace (foo-bar vs bar)
some projects capitalize the first letter
some projects use CamelCase some snake_case, even if the binaries or project names don't follow those conventions.
I guess the main problem is that there is no naming convention for libraries in general so that makes it hard to come up with a naming convention in CMake, but at least the capitilization for the first letter of the namespace and the component seem to be pretty common, so I was wondering if there is some guideline I should follow for future projects.
The cmake-developer documentation gives the following advice on namespaces:
When providing imported targets, these should be namespaced (hence the Foo:: prefix); CMake will recognize that values passed to target_link_libraries() that contain :: in their name are supposed to be imported targets (rather than just library names), and will produce appropriate diagnostic messages if that target does not exist (see policy CMP0028).
And the CMP0028 policy documentation says on the "common pattern" in the use of namespaces:
The use of double-colons is a common pattern used to namespace IMPORTED targets and ALIAS targets. When computing the link dependencies of a target, the name of each dependency could either be a target, or a file on disk. Previously, if a target was not found with a matching name, the name was considered to refer to a file on disk. This can lead to confusing error messages if there is a typo in what should be a target name.
And no, there are no CMake specific convention for the naming of library targets. But since the name is taken by default as the target's output name:
I prefer to take the same name for the targets as for my source code directory
And add no lib prefix, since this is automatically added by CMake depending on the platform you are compiling your project with
From the CMake Tutorial
The most official source you could get is probably an extract from the "Mastering CMake" book written by Ken Martin and Bill Hoffman from Kitware.
The tutorials from the book all use CamelCase and no namespaces for component/target names.
References
What is the naming convention for CMake scripts?
cmake usefulness of aliases
I'm currently in the process of moving some project from Ant to Maven. Conformist as I am, I want to use well-established conventions for finding groupId and artifactId, but I can't find any detailed conventions (there are some, but they don't cover the points I'm wondering about).
Take this project for instance, first the Java package: com.mycompany.teatimer
Tea timer is actually two words, but the Java package naming conventions forbid the insertion of underscores or hyphens, so I'm writing it all together.
I chose the groupId identical to the package ID because I think that's a good idea. Is it?
Finally, I have to pick an artifactId, I currently went for teatimer. But when I look at other Maven projects, they use hyphens to split words in artifactIds, like this: tea-timer. But it does look weird when concatenated to the groupId: com.mycompany.teatimer.tea-timer.
How would you do this?
Another example:
Package name: com.mycompany.awesomeinhouseframework
groupId: com.mycompany.awesomeinhouseframework (?)
artifactId: awesome-inhouse-framework (?)
Weirdness is highly subjective, I just suggest to follow the official recommendation:
Guide to naming conventions on groupId, artifactId and version
groupId will identify your project uniquely across all projects,
so we need to enforce a naming schema.
It has to follow the package name
rules, what means that has to be at
least as a domain name you control,
and you can create as many subgroups
as you want. Look at More information
about package names.
eg. org.apache.maven, org.apache.commons
A good way to determine the granularity of the groupId is to use
the project structure. That is, if the
current project is a multiple module
project, it should append a new
identifier to the parent's groupId.
eg. org.apache.maven, org.apache.maven.plugins,
org.apache.maven.reporting
artifactId is the name of the jar without version. If you created it
then you can choose whatever name you
want with lowercase letters and no
strange symbols. If it's a third party
jar you have to take the name of the
jar as it's distributed.
eg. maven, commons-math
version if you distribute it then you can choose any typical
version with numbers and dots (1.0,
1.1, 1.0.1, ...). Don't use dates as they are usually associated with
SNAPSHOT (nightly) builds. If it's a
third party artifact, you have to use
their version number whatever it is,
and as strange as it can look.
eg. 2.0, 2.0.1, 1.3.1
Your convention seems to be reasonable. If I were searching for your framework in the Maven repo, I would look for awesome-inhouse-framework-x.y.jar in com.mycompany.awesomeinhouseframework group directory. And I would find it there according to your convention.
Two simple rules work for me:
reverse-domain-packages for groupId (since such are quite unique) with all the constrains regarding Java packages names
project name as artifactId (keeping in mind that it should be jar-name friendly i.e. not contain characters that maybe invalid for a file name or just look weird)
Consider the following for building a basic first Maven application:
groupId
com.companyname
artifactId
project
version
0.0.1
However, I disagree the official definition of Guide to naming conventions on groupId, artifactId, and version which proposes the groupId must start with a reversed domain name you control.
com means this project belongs to a company, and org means this project belongs to a social organization. These are alright, but for those strange domain like xxx.tv, xxx.uk, xxx.cn, it does not make sense to name the groupId started with "tv.","cn.", the groupId should deliver the basic information of the project rather than the domain.
I'm in the middle of building an application but found myself too easily creating new packages without keeping the project's structure in mind.
Now, I'm trying to redo the whole project structure on paper first. I am using a Settings class with public properties, accessed as settings for several other classes around the project.
Now, since this Settings class applies for the whole project, I am unsure if it should be packaged and if so, in what kind of package should it exist? Or should it be in the root (the default package) with the main application class?
I've been thinking about putting it in my utils package, then again I don't think it really is an utlity. Any strategies on how to decide on such package structure for example for a Settings class?
Use of the default package is discouraged anyway (in java it is actually enforced as a warning as far as I know), even for the class containing the main.
Other than that, I prefer having a config package, even if it's the only class in there. I don't think it would fit in the utils package.
IMHO you should put it into a separate, low level package, since many other classes depend on it, but it (presumably) doesn't depend on anything. So it should definitely not be put in one package with the main application class. It could be in the utils package though, or in a separate package on the same level (e.g. config).
By "low level" I simply mean "low on the package dependency hierarchy", where a package A which depends on package B is higher than B. So it does not directly relate to the actual package hierarchy. The point is to avoid dependency cycles between your packages, so that you can have such an ordering between your packages.
Btw you should not use the root package in a real application.
I'm looking to choose a namespace for a library I'm writing and I'd like to avoid conflicts with other namespaces.
Does anyone know of a website that lists all of the class prefixes in use?
https://cocoadev.github.io/ChooseYourOwnPrefix/ is probably your best bet. It's not "official", but it's a place a lot of devs would look.
In practice, as long as you don't use one that Apple uses, you'll probably be fine.
According to the Apple "Programming in Objective C" document of 2012-12-13, Apple reserves all 2 character prefixes for use in their frameworks. Users are encouraged to employ 3 character prefixes when naming their classes to avoid conflicts with Apple. See the "Conventions" section for details.
As an alternative to initial-letters prefixes:
If you're writing an application, use no prefix. You're unlikely to encounter another class named AppController in your app.
Otherwise, use the product name as the prefix. For example, if you've written a color picker named “Whizbang”, name its principal class “WhizbangColorPicker”.
"You should try to choose namesthat clearly associate each symbol with your framework. For example, consider
adding a short prefix to all external symbol names. Prefixes help differentiate the symbols in your framework
from those in other frameworks and libraries. They also make it clear to other developers which framework is
being used. Typical prefixes include the first couple of letters or an acronym of your framework name. For
example, functions in the Core Graphics framework use the prefix “CG”
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/BPFrameworks.pdf