Develop Reference

Load different resources when testing in Python

First of all let me put you in context. My main background is Java and I'm working in Python since 2 months ago. I don't know if the approach it's wrong due to my Java background and in Python has a different solution or it's just a technical ignorance problem.
In Java often you have a packaging structure like:
project
|___src
|___main
| |___java/MyClass.java
| |___resources/properties.file
|
|___test
|___java/MyClassTest.java
|___resources/properties.file
Thus, when you execute this from tests (with Maven or IDE):
this.getClass().getResourceAsStream(resourcePath);
Either Maven or IDE loads the test path in the classpath, making test resources available rather than the ones within the main package.
Conversely, when previous line is executed as main, only the resources within the main path are loaded to the classpath.
My question is: Is there any mechanism in Python to simulate this feature? Does Python have other ways to manage resources depending on the execution path?

I think mock might be what you are looking for. It allows for 'mock'ing out external functions to limit the test to strictly the unit under test.
This could mean changing some of the philosophy around some of it. For example, if you want to test that a function is reading a file correctly the filename would get passed to the method as a parameter. In your unit test for the function, pass in a different filename from your test folder.
In another test mock out the open call to the os to check that the method responds as expected when the file is not there, or cannot be opened, or whatever other mis-behaviors you want to test for.

No, Python has no deployable like Java has (WAR, JAR, etc...). You will run your code directly from the source, so, just read the file.
In the Java context, you do not have the code when it is deployed. So every resource should be package inside a file (JAR or WAR).
If you want to find the file in the current folder, look this question.

I don't know very well Python but you are right to ask yourself the question
as separating test and application code makes part of good practice to have a robust/reliable application and tests.
The pytest (a known test framework for Python) documentation explains in its best practice guide the two ways (separating and not separating the test code from the application).
Here is the part referencing the isolated layout :
Choosing a test layout / import rules
pytest supports two common test layouts:
Tests outside application code
Putting tests into an extra directory outside your actual application
code might be useful if you have many functional tests or for other
reasons want to keep tests separate from actual application code
(often a good idea): setup.py
mypkg/
init.py
app.py
view.py
tests/
test_app.py
test_view.py
...
This way your tests can run easily against an installed version of
mypkg.
Note that using this scheme your test files must have unique names,
because pytest will import them as top-level modules since there are
no packages to derive a full package name from. In other words, the
test files in the example above will be imported as test_app and
test_view top-level modules by adding tests/ to sys.path.
If you need to have test modules with the same name, you might add
init.py files to your tests folder and subfolders, changing them to packages: setup.py
mypkg/
...
tests/
init.py
foo/
init.py
test_view.py
bar/
init.py
test_view.py
Now pytest will load the modules as tests.foo.test_view and
tests.bar.test_view, allowing you to have modules with the same name.
But now this introduces a subtle problem: in order to load the test
modules from the tests directory, pytest prepends the root of the
repository to sys.path, which adds the side-effect that now mypkg is
also importable. This is problematic if you are using a tool like tox
to test your package in a virtual environment, because you want to
test the installed version of your package, not the local code from
the repository.
In this situation, it is strongly suggested to use a src layout where
application root package resides in a sub-directory of your root:
setup.py
src/
mypkg/
init.py
app.py
view.py
tests/
init.py
foo/
init.py
test_view.py
bar/
init.py
test_view.py This layout prevents a lot of common pitfalls and has many benefits, which are better explained in this
excellent blog post by Ionel Cristian Mărieș.
https://docs.pytest.org/en/latest/goodpractices.html

how to include all subdirectories as gradle modules?

I'm going to have a lot of submodules in my main project directory x, like x/module1, x/module2...
can i avoid manually adding every single module into settings.gradle? can i somehow script it to find all the subdirectories and add them automatically?

As cricket_007 already mentioned, Gradle is based on the Groovy programming language (which is, like Java, executed in the JVM) and the settings.gradle file is nothing more but a Groovy script.
Whenever you use include 'project', the include method of a Settings instance is called, so for your goal, you could simply create a loop which iterates over all folders and calls include for each of them.
A more 'groovyesque' approach would be the usage of a closure for each subdirectory, provided by the Groovy SDK extension for the File class:
file('.').eachDir { sub ->
include sub.name
}
There are multiple ways to solve your problem, e.g. since the include method accepts an array of project path strings, you could also aggregate all required paths first and pass them all together. Simply get familiar with the Gradle docs and decide on your own, what solution suits your case the best.

Maven-war-plugin - remove files

I am developing maven plagin that obfuscates js files. It does the following -:
takes *.js files from target,
obfuscates them using google closure,
creates *.min.js files in target,
if it's necessary removes sources (unobfuscated files) from target.
In order to get point between package phase and prepare-package phase I use the following solution: https://stackoverflow.com/a/27566620/2022068
Everything is ok. Plugin is ready. However I have the following problem - if I remove source file, maven-war-plugin copies it again. Maybe it has some mechanism of checking - I don't know. The only thing that I can do now is to delete and create empty file. Than the source file exists but it's empty.
My qeustion - can I somehow remove files from target finally, forever...?

You probably need to teach this to the maven-war-plugin. I have no example that does the same thing but there are packageExcludes (see: http://maven.apache.org/plugins/maven-war-plugin/examples/including-excluding-files-from-war.html) which seems not exactly what you need but also warSourceExcludes: http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#warSourceExcludes
The war plugin has its own mechanism of copying files (aside from the resources plugin). That may be the issue here. There are some examples on filtering as well: http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html
Maybe treating the files you don't want to see as excludes will work (if warSourceExcludes is something different than what you plan to do).

Java Package Vs Folder-Structure? what is the difference

I would like to know What are the difference between folder-structure and package used in Eclipse IDE for Java EE development.
When do we use which one and why?.
Whats should be the practice
create a folder structure like src/com/utils and then create a class inside it
create a package like src.com.util and then create a class inside it
which option would be better and easy to deploy if i have to write a ant script later for deployment ?
if i go for the folder-structure will the deployment is as easy as copying files from development to deployment target ?

If you configured stuffs correctly. Adding a folder inside src, is same as adding a package from File > New Package.
So, it's up to you, whatever feels comfortable to you -- add a folder or create a package. Also, when you put stuffs under src the package name starts from subfolder. So, src/com/naishe/test will be package com.naishe.test.

Basically there is no difference, both are the same.
In both the cases, the folder structure will be src/com/utils.
and in both the cases, you will need to mention
package com.utils;
as first line in the class
Since it doesn't have any difference practically, it won't make any difference to ant script.

"Packaging helps us to avoid class name collision when we use the same class name as that of others. For example, if we have a class name called "Vector", its name would crash with the Vector class from JDK. However, this never happens because JDK use java.util as a package name for the Vector class (java.util.Vector). So our Vector class can be named as "Vector" or we can put it into another package like com.mycompany.Vector without fighting with anyone. The benefits of using package reflect the ease of maintenance, organization, and increase collaboration among developers. Understanding the concept of package will also help us manage and use files stored in jar files in more efficient ways."
check out http://www.jarticles.com/package/package_eng.html for more information on packages

create a package like 'src.com.util'
That sounds like a mistake. The package name should be 'com.util', and 'src' is the name of the source folder.
Other than that, I fail to see what the difference is between your two choices. The result is the same, right? Just different steps in the GUI to arrive at it. The wizard to create a new package in Eclipse is just a wrapper around creating the appropriate folder hierarchy within a source folder.
You don't need to create empty packages at all, you can directly create classes (the package will be created automatically if it does not already exist).

A package is automatically "source folder" where folder is just a normal folder.
When you compile an Eclipse project, all files in source folders are compiled but not in regular folders (unless those regular folders a)

folder structure or to be specific source folder in eclipse is meant just for eclipse but package is universal irrespective of any editor..

Prevent Eclipse Java Builder from Compiling Java-Like Source

I'm in the process of writing an eclipse plugin for my programming language Whiley (see http://whiley.org). The plugin is working reasonably well, although there's lots to do. Two pieces of the jigsaw are:
I've created a "Whiley Builder" by subclassing incremental project builder. This handles building and cleaning of "*.whiley" files.
I've created a content-type called "Whiley Source Files" for "*.whiley" files, which extends "org.eclipse.jdt.core.javaSource" (this follows Andrew Eisenberg's suggestion).
The advantage of having the content-type extend javaSource is that it immediately fits into the package explorer, etc. In principle, I could fleshout ICompilationUnit to provide more useful info, although I haven't done that yet.
The disadvantage is that the Java builder is trying to compile my whiley files ... and it obviously can't. Originally, I had the Java Builder run first, then the Whiley builder. Superficially, this actually worked out quite well since all of the errors from the Java Builder were discarded by the Whiley Builder (for whiley files). However, I actually want the Whiley Builder to run first, as this is the best way for me to resolve dependencies between Java and Whiley files.
Which leads me to my question: can I stop the Java builder from trying to compile certain java-like resources? Specifically, in my case, those with the "*.whiley" extension. As an alternative, I was wondering whether my Whiley Builder could somehow update the resource delta to remove those files which it has dealt with.
Thoughts?

A quick way:
- Right-click on the offending item (Can be a file or folder)
- Select Java Build Path > Exclude
This adds an "exclude pattern" to your project the "pattern"
is the exact path to the file or folder you right-clicked on.
To add a general pattern you can do:
- Project > Properties > Java Build Path > Source
- Click on "Excluded"
- Click on "Edit"
- Click on "Add"
I like to add these exclude patterns:
**/*.Old
**/Old/ Trailing slash is required
These will get Eclipse to ignore all files with ".Old" extension
and all folders called "Old".
Source : http://www.davekb.com/browse_programming_tips:eclipse_exclude_ignore_certian_files_extensions:txt

I'm not a Java guy so pardon the stuidity on this answer...
If you wrote the whiley builder can't you just change the "whiley spec" so that all whiley code must be enclosed in a Java comment block... there by preventing eclipse from compling it?