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?
Related
I have a GWT application (FooGwtApp) and a library module (FooLib) used as a dependency in FooGwtApp. The package structure of FooLib looks like this:
packageFoo.ImportantClass
packageFoo.UnimportantClass
packageBar.OtherClass
I want ImportantClass (and only ImportantClass) to be compiled to JS by the GWT compiler. Moving ImportantClass to another package is not an option.
I created ImportantClass.gwt.xml within packageFoo with the following content:
<module>
<inherits name="com.google.gwt.user.User"/>
<source path="" includes="**/ImportantClass*"/>
</module>
Next I put an inherited reference to the ImportantClass module definition in FooGwtApp.gwt.xml (this seems to work: the IDE recognizes it, and is able to parse the reference to ImportantClass.gwt.xml).
Now If I put references to ImportantClass into FooGwtApp's client code, the GWT compiler fails, because it does not find ImportantClass on the source path:
No source code is available for type packageFoo.ImportantClass; did you forget to inherit a required module?
I likely messed up sommething in the source path / includes attribute in ImportantClass.gwt.xml - either defining the current package as root package with path="" is not a valid notation or something's wrong with the includes attribute. Or both. Or neither.
Can you give me a clue about where it all went wrong?
It turns out the problem was not in ImportantClass.gwt.xml, but in other Maven related stuff:
ImportantClass.gwt.xml should be placed under src/main/resources/packageFoo, not src/main/java/packageFoo, otherwise it won't be packaged into the binary jar.
GWT compiler compiles from Java source to Javascript source. This means we don't just need ImportantClass.class in FooLib.jar, but also its source. Best solution for this is to use maven-source-plugin in FooLib's pom.xml and also to import the FooLib dependency into FooGwtApp with sources classifier.
On the latter topic, see the following SO answers:
Maven: Distribute source code with with jar-with-dependencies
How to properly include Java sources in Maven?
After fixing the above problems, the source path declaration present in the question works.
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 can't use functions of custom subdirectories.
My Code Organziation
I have under "src" a path hierarchy like
a/b
with all my directories and go-Files (it is the "root" of my project). The directories contain no subdirectories and it works fine. So the deepest path is "a/b/c". E.g. I have
a/b/c
and
a/b/d
with some go-files. Import of "a/b/d" and calling a function with "d.DoSomething()" from a file in "a/b/c" works fine.
Problem description
Now I want ot reorganize "a/b/d". I move some files from "a/b/d" to
a/b/d/e
and the rest of the files to
a/b/d/f
If try to import "a/b/d/e" with import-statement
import ( "a/b/d/e" )
from the same file in "/a/b/c" and want to call "e.DoSomething()" (it is the place, where the file with the "DoSomething-function" moved to), I get an error at the line, where I call "e.DoSomething()": "undefined: e".
While searching for a result, I've nowhere seen examples with deeper path hierarchies. Is it generally not possible to use/import subdirectories or what's the problem?
go-version I used: go1.2.2 linux/amd64
Thanks for any advices
Your approach is completely wrong. Go has absolutely no concept of importing files or directories, all you can import in Go are packages. It now happens that the name of a package is it's path relative to GOPATH and you import packages by that name. But the identifier under which an imported package is available in the importing code depends on the package declaration of the package. You cannot simply "move" files between directories as each directory (for the go tool) is a single package without changing the package declaration.
You can have package x under path a/b/c. When you import package x with import ( "a/b/c" ) all the exported stuff from package x is available to you as x.ExportedName.
Please read http://blog.golang.org/organizing-go-code carefully.
Try and do a go build in a/b/d/e first, before trying to build in a/b: that will generate the compiled classes you want to import.
This might be a little too difficult to do with perl, but I'm hoping someone can at least help me find the correct direction to accomplish this.
Currently we have a Nexus server that is holding all of our .jar files. One of the applications needs to use 3rd party common jars that are being defined in a .properties file.
The properties file looks like this
commons-logging=commons-logging-1.1.1.jar
commons-io=commons-io-2.3.jar
httpcore=httpcore-4.2.1.jar
I am being asked to create a Perl script that will skim through this properties file, then compare that version(i.e. commons-logging-1.1.1.jar) with a version that is located elsewhere. If the version in the properties file is not the same, it will then copy the new .jar file to the common jar location.
An example
In C:\commons there is a commons-logging-1.1.0
In the properties file, it is specified that commons-logging=commons-logging-1.1.1.jar is needed. The perl script would then read the .properties file, determine that commons-logging-1.1.1 is not the same as the commons-logging-1.1.0 found in the commons folder and would replace it.
We can also use maven for something like this, but I'm not sure how we can make it so the developer can just define what jar is needed in a properties file and replace it in a specific folder.
Any help would be greatly appreciated.
It's hard to know what problems you are having with this. Perhaps this program will help?
use strict;
use warnings;
open my $fh, '<', '.properties' or die $!;
while (<$fh>) {
if (/^([\w-]+)=\1-([\d.]+)\.jar$/) {
my ($lib, $ver) = ($1, $2);
print qq(Library "$lib" needs version $ver\n);
}
else {
warn "Error in .properties line $.: $_";
}
}
output
Library "commons-logging" needs version 1.1.1
Library "commons-io" needs version 2.3
Library "httpcore" needs version 4.2.1
Sounds like you've been asked to write a dependency management client.
I would suggest using Apache ivy, which has a convenient command-line client.
Example
This ivy command:
java -jar ivy.jar -ivy ivy.xml -retrieve "lib/[artifact]-[revision](-[classifier]).[ext]"
creates a "lib" directory populated with the jars listed in the ivy file:
├── ivy.xml
└── lib
├── commons-io-2.3.jar
├── commons-logging-1.1.1.jar
└── httpcore-4.2.1.jar
The real advantage of this approach is that ivy will also download the transitive dependencies.
Additionally ivy will cache the files previously downloaded. This means it's simpler to just delete an older directory and get ivy to create a new directory containing the jars. (Rather than going to the effort of comparing files)
ivy.xml
<ivy-module version="2.0">
<info organisation="myorg" module="mymodule" />
<dependencies>
<dependency org="commons-logging" name="commons-logging" rev="1.1.1" conf="default"/>
<dependency org="commons-io" name="commons-io" rev="2.3" conf="default"/>
<dependency org="org.apache.httpcomponents" name="httpcore" rev="4.2.1" conf="default"/>
</dependencies>
</ivy-module>
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"/>