I am studying Arquillian platform. I am following
http://arquillian.org/guides/testing_java_persistence/#write_the_test
at a certain point of the guide, you can read:
"We define the Persistence Unit in a test-persistence.xml file that’s
corresponding to the target container. ShrinkWrap takes this file from
the classpath and puts it into its standard location within the
archive."
.addAsResource("test-persistence.xml", "META-INF/persistence.xml")
You can see this command in
src/test/java/org/arquillian/example/GamePersistenceTest.java
that is in the upper part of the page.
So my question is: is this piece of the guide a simply explanation of that code line, or is something you have to add into another class to do the example?
No, it's just explaining that line, it means you need to add this file onto classpath with ShrinkWrap in order to make the persistence work.
Related
I just upgraded to the newest version of Pharo Smalltalk. Before doing so, I "File-outed" a package from my old version called My-Pharo - a package I use for various configurations and customizations of Pharo itself, most notably a class to put back "Workspace" in the main menu. I then "File-ined/Installed" the file into my new version.
When I checked the SystemBrowser, I had correctly gotten the My-Pharo package, but I'd also picked up a package called My-Pharo-Manifest... I see My-Pharo-Manifest actually is part of my File-Out, and seems to contain the package-comment for My-Pharo .
What is this manifest, what is it's purpose, and how should it be used? Is there something I can/should do to "merge" the manifest (ie. the comment) back into the My-Pharo class? Should I move the content of My-Pharo-Manifest somewhere else? ...Or is my best bet to simply delete the Manifest-package, and re-write the package-comment for My-Pharo?
I'm not a seasoned Pharo developer, I use it just time to time. I'll try to answer your question from the source code. For more detailed answer you would have to get it from the ones that are actually do the development of Pharo.
What is manifest?
Manifest contains package metadata.
what is it's purpose?
The purpose is to make life easier for the SmallLint (Smalltalk Code Critics). It is there for its speedup, because without the manifest the SmallLint would have to check the rule results all the time. Package metadata helps in managing false positives and/or TODOs.
packages: If you check for the where is the #hasPackageNamed: used, you will find out that it is at SmallLintManifestChecker>>manifestBuilderOfPackage:.
methods: if you search for #hasManifestFor: SmallLintManifestChecker>>manifestBuilderOfMethod:
Is there something I can/should do to "merge" the manifest (ie. the
comment) back into the My-Pharo class? Should I move the content of
My-Pharo-Manifest somewhere else?
I would just leave it be. It helps the SmallLint to do its job.
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.
This should be an easy one, but it's driving me mad. I'm new to implementing plugins, and one that I'm looking at has the following dependency:
<depends>com.intellij.modules.lang</depends>
I cloned the intellij-community project and was expecting to see this defined as an extensionPoint in one of the many plugin.xml files in the project, but either I can't search correctly or it is somewhere else.
Anybody knows where I can find this definition?
Thanks,
a
I'm still no expert in plugin development, but I think I figured out parts of my problem.
First, I was wrong about com.intellij.modules.lang having to be defined as an extension point. Name of extensions need to have corresponding extension points, not dependencies.
Then com.intellij.modules.lang is defined in a
<module>
tag in a few xml files in the intellij source code, which is part of the SDK used by this project. One such file is platform/platform-resources/src/META-INF/PlatformLangPlugin.xml. Now I need to familiarize myself with the concept of modules, but the original question is not moot.
Thanks to anyone who spent a few seconds thinking about this problem.
POST 1: theoretical question
We use some software, that is actually a Web Module with its own Tomcat and shell scripts for controlling it. It has also a Plugin System, which allows you to upload a .jar file with a certain structure to add new functionality to the Application.
Question:
I would like to control&actually change the responses to different calls in the main system/application (not in my jar). Could I use AspectJ to do that? Why or why not? What would be the other general possibilities, except changing the code of the Main Application.
POST 2: the try
I tried to do it this way (in Eclipse):
In the AspectJ Project I added the jar file, where the classes to be woven are (actually I added it to the INPATH).
Exported the Project as "Jar with AspectJ support"
Deployed the jar file exported at the step 2: No result.
Questions:
In the exported aspect-jar, there are only the .class files of the AspectJ project, no .class files for the INPATH-Jar.
Should there be other classes, from the imported INPATH-jar?
In the exported aspect-jar there is no jar with the aspectj-runtime (aspectj-rt.jar). Should it be there, or how to configure the virtual machine to have it?
Yes, why not? If you could extend your question and explain (maybe with an example) which actors and actions there are in the system, we might be able to help you in a more conrete fashion. But basically I see no problem. The JAR modules might be loaded dynamically, but if you know which calls in the Tomcat app you want to intercept, you can easily instrument them either statically by reweaving the existing classes or dynamically via LTW (load-time weaving) during JVM start-up. There is no need to touch your uploaded JAR modules, which is, as I understand you, what you want to avoid.
You probably want to weave your main application's target classes via
execution(<methodsToBeChecked>) pointcut in combination with
around() advice.
The other details depend on your specific use case, the package, class and method names, parameters etc. The around advice can do one or several of the following things:
determine caller,
check call paramaters,
manipulate call parameters,
call original target with original or changed parameters,
alternatively not perform the original call at all,
pass back the result of the original call to the caller,
pass back a manipulated version of the result to the caller,
pass any synthetic value with the correct return type to the caller,
catch exceptions raised by the original call,
throw your own exceptions
etc.
Your fantasy (and AspectJ's few limitations) are the limit. :-)
Any ideas on how to include the xsd:annotation and xsd:documentation content defined in the schema as javadoc in the generated pojo using jibx???
For now I only get the schema fragment on top of the class but cant see the annotation documentation for the schema.
thanks for you time.
You seem to be experiencing an unexpected behavior, unless the lack of details in your question threw this answer off... If you're still in a bind after attempting troubleshooting as described below, the best would be for you to update your request with more information, such as an XSD fragment showing the setup, the versions you're using (Java, JiBX) and the command line you use for your codegen utility.
Start by taking a look at customizations documentation; make sure that the import-docs option, which is responsible to "Convert xs:documentation annotations in the schema definition to Javadocs in the generated [...]", is not set to false. The default value is true, so it should work...
Check that from a command line perspective, you're not overriding it. Alternatively, you could ensure is set explicitly (see this).
JiBX does automatically includes xsd:documentation content in the generated source code which will end up in your javadocs.
For a nice example, take a look at the opentravel.org schema which is included in the JiBX schema library.
Here is the opentravel schema definition for a 'ping' message:
http://opentravel.org/2011B/OTA_PingRQ.xsd.
Now download and unzip the javadoc.jar for the generated code from maven central:
http://search.maven.org/#search%7Cga%7C1%7Cfc%3Aorg.jibx.schema.org.opentravel._2011B.ping.PingRQ
Notice how the xsd:documentation displays nicely in the javadoc.
Hope this example helps!
Don Corley
JiBX contributor