When I am building a bundle, I need to embed a few jars (http-core and http-client) in my case. Using maven with flex plugin I get huge Import list - some of the stuff that I do not need. As of right now I am just negating the packages that I do not need in <Import-Package>, but I could also use Import-Package: resolution:=optional. I was wondering what is the preferred way and what are the advantages/disadvantages of either approaches?
Unfortunately people include a lot of "nice to have parts" (usually called utils) that cause these imports. Very often the culprits are separate of the core code that you want to use. If you use bndtools then you can easily inspect how the dependencies run.
In bndtools and maven you use bnd, and bnd makes it very easy to only copy part of the JAR into your bundle. That way you can minimize the dependencies. Just use Private-Package to copy the packages you really need and then look at the imports. If you import something that you think you need, add it to Private-Package (in bndtools you can do this with drag and drop).
At the end you can probably get rid of many unnecessary imports. However, there are usually some left. In that case decorate them with resolution:=optional in the Import-Package statement:
Import-Package: com.oracle.whatever; resolution:=optional, *
Don't forget the * at the end.
Related
I have a Unit-Test Project where i used MVVMCross for Dependency Injection, but since i made a Implementation of the Library which i tested for UWP, i kinda wanted to use the Unit-Test for both Implementations.
For that purpose i used Compiler Switches and ended up removing MVVMCross.
But when i uninstall it from the packages i always get "Resource.Attribute" does not contain a definition for "MvxBind" and some other MVVMCross attributes.
I rebuilded the project. I deleted the obj and bin folder and looked through every file in the project folder, but i cant find a thing why it keeps adding those attributes to my Ressource.Designer.cs
If i add MVVMCross back and just dont use it all, obviously it works. But i kinda want to remove it there, since it is just overkill.
In my Symfony2 app I'm having a very basic bundle named AnimalsBundle() with a very basic entity.
I can successfully extend this bundle by creating a new bundle MammalsBundle() via Bundle Inheritance. However, it is not possible to register one further bundle InsectsBundle() that also extends the AnimalsBundle(). Whenever I'm trying to do this, Symfony throws a
[LogicException]
Bundle "AnimalsTextBundle" is directly extended by two bundles "MammalsBundle" and "InsectsBundle".
So out of the box it's obviously not allowed. First of all, I'm not really sure why this is not allowed and - most important - how can I solve this?
I know it's been more than year now, but I just came across your question and the answer maybe useful to someone anyway..
Symfony doesn't allow a bundle to be extended directly by more than one bundle, simply because if two bundles are overriding the same files, it wouldn't be possible to determine what bundle should be used. However you can achieve what you want by doing the following :
AnimalsBundle <|---- MammalsBundle <|----- InsectsBundle
This way InsectsBundle indirectly has AnimalBundle as a parent and can override files from it.
I know, that this has been a log time since the question has been asked, but for those in need of an answer I'll suggest the following:
1) Try to avoid bundle inheritance except the cases you are 100% positive that you need to.
2) Given the example in question, the better setup will look smth like this: you have a CreatureBundle, which consists mostly of abstract classes and interfaces. Make each descendant bundle depend on CreatureBundle and implement each Creature specific code with those abstract classes and interfaces in CreatureBundle.
Based on personal experience I can tell that managing dependencies is much easier task than managing inheritance issues in case something goes wrong. If you'll ever need to alter the ancestor bundle's logic, you'll save yourself lot time by not having to dig through inherited code and alter the same logic in every descendant bundle.
Edit: Although my suggestions might lead to tighter coupling and basically contradicts latest Symfony's 'best practices' guide (which states that 'single bundle per app' is a best practice), in the end you'll realize that this approach eventually makes code maintenance easier.
I can't think of a use case where you could possibly need to do this. Bundles are meant to be almost like standalone applications. You have the dependency injection container at your disposal if you need resources from another bundle.
Perhaps you should re-think your project structure.
I have a basic problem with knowing which classes to import for a given application, renderer, AS package, mxml component, etc. There seems to be hundreds of classes (both mx and flash) and I'm never sure which one(s) to import... so I just keep adding import statements until the errors go away. Is there a reference somewhere that I don't know about? Or does this just come with experience? Also... does importing a load of classes actually make the file size larger or does Flex only import the classes used nregardless of what I specify? If it only uses what is needed, why wouldn't everyone just do: import mx.*;
I would suggest that if you find yourself bringing in tons of imports, you should ask yourself: Does this class do to much?
It is less of a technical issue, and more of problem of object-oriented design -- maintainability, testability and stability.
I do my best to limit my external dependencies. I try to conform to SOLID principles that tell me that classes should exist for one reason. If a class does too much, it is a "code smell" and an indication that you should split it up.
How much is too much? It is tough to have a specific litmus test or limit... I just ask myself "What does this class do"? If my answer contains an "and" in it, then I consider splitting it up.
I think your problem is a not a real problem if you use any half decent IDE. If you're not using one, you probably should (even if it's not stricly necessary and you can write and compile with notepad and the command line).
If you are using Flex/Flash Builder, it will add the imports automatically (and remove the unneeded ones as well). Also, you can use Ctrl + SPACE to prompt autocomplete, which should add the necessary imports.
Flash Develop also manages this for you (the shortcut was Ctrl + Shift + 1 if I recall correctly, but I haven't used FD for a while).
There are other IDEs out there that I haven't personally used but also have this very basic feature.
If you're using the Flash IDE, well, it really sucks for writting code, so you should probably consider writting your code in some other less brain-dead editor if you plan to do anything more than a couple of lines of code here and there (again, you can write code in the Flash IDE but why not taking advantage of better tools when they're available?).
When you get an error, look at the API Reference for the class, and then either import the whole package or just the class you want. Highlighting the class and hitting F1 should also work (but I never search help this way).
As for file size, see my answer on Is it possible to dynamically create an instance of user-defined Class in Action Script 3?
As Juan pointed out, use FlashDevelop, it is a great (and free) IDE.
If you're using FlashDevelop with the Flex Compiler, you can compile straight from FlashDevelop, and use the refactoring tools they offer to slim down your imports.
Aside from that though, if you're not referencing them, they don't get compiled, so it's not like your compiled swf is any bigger.
I'm having trouble finding good advice and common practices for the use of namespaces in Clojure. I realize that namespaces are not the same as Java packages so I'm trying to tease out the conventions in Clojure, which seem surprisingly hard to determine.
I think I have a pretty good idea how to split functions into clj files and even roughly how I'd want to organize those files into directories. But beyond that I'm having trouble finding the mechanics for my dev environment. Some inter-related questions:
Do I use the same uniqueness conventions for Clojure namespaces as I would normally use for Java packages? [ie backwards-company-domain.project.subsystem]
Should I save my files in a directory structure that matches my namespaces? [ala Java]
If I have multiple namespaces, do I need to compile all of my code into a jar and add it to my classpath to make it accessible?
Should each namespace compile to one jar? Or should I create a single jar that contains clj code from many namespaces?
Thanks...
I guess it's ok if you think it helps, but many Clojure projects don't do so -- cf. Compojure (using a top-level compojure ns and various compojure.* ns's for specific functionality), Ring, Leiningen... Clojure itself uses clojure.* (and clojure.contrib.* for contrib libraries), but that's a special case, I suppose.
Yes! You absolutely must do so, or else Clojure won't be able to find your namespaces. Also note that you musn't use the underscore in namespace names or the hyphen in filenames and wherever you use a hyphen in a namespace name, you must use an underscore in the filename (so that the ns my.cool-project is defined in a file called cool_project.clj in a directory called my).
You need to make sure all your stuff is on the classpath, but it doesn't matter if it's in a jar, multiple jars, a mixture of jars and directories on the filesystem... As long as it obeys the correct naming conventions (your point no. 2) you should be fine.
However, do not compile things ahead-of-time if there's no particular reason to do so -- this may prevent your code from being portable across various versions of Clojure without providing any benefits besides a slightly improved loading time.
You'll still need to use AOT compilation sometimes, notably in some Java interop scenarios -- the documentation of the relevant functions / macros always mentions that. There are examples of things requiring AOT in clojure.contrib; I've never needed it, so I can't provide much in the way of details.
I'd say you should use jars for functional units of code. E.g. Compojure and Ring get packaged as single jars containing many namespaces which together compose the whole package. Also, clojure.contrib is notably packaged as a single jar with multiple unrelated libraries; but that again may be a special case.
On the other hand, a single jar containing all of your project's code together with its dependencies might occasionally be useful for deployment. Check out the Leiningen build tool and its 'uberjar' facility if you think that sort of thing may be useful to you.
Strictly speaking, not necessary, though many Java projects have dropped that convention as well, especially for internal projects or private APIs. Do avoid single-segment namespaces though, which would result in classfiles being generated in the default package.
Yes.
Regarding 3 & 4, packaging and AOT compilation are entirely orthogonal to the question of namespace conventions.
I want to give credit to all open source libraries we use in our (commercial) application. I thought of showing a HTML page in our about dialog. Our build process uses ant and the third party libs are committed in svn.
What do you think is the best way of generating the HTML-Page?
Hard code the HTML-Page?
Switch dependency-management to apache-ivy and write some ant task to generate the html
Use maven-ant-tasks and write some ant task to generate the HTML
Use maven only to handle the dependencies and the HTML once, download them and commit them. The rest is done by the unchanged ant-scripts
Switch to maven2 (Hey boss, I want to switch to maven, in 1 month the build maybe work again...)
...
What elements should the about-dialog show?
Library name
Version
License
Author
Homepage
Changes made with link to source archive
...
Is there some best-practise-advice? Some good examples (applications having a nice about-dialog showing the dependencies)?
There are two different things you need to consider.
First, you may need to identify the licenses of the third-party code. This is often down with a THIRDPARTYLICENSE file. Sun Microsystems does this a lot. Look in the install directory for OpenOffice.org, for example. There are examples of .txt and .html versions of such files around.
Secondly, you may want to identify your dependencies in the About box in a brief way (and also refer to the file of license information). I would make sure the versions appear in the About box. One thing people want to quickly check for is an indication of whether the copy of your code they have needs to be replaced or updated because one of your library dependencies has a recently-disclosed bug or security vulnerability.
So I guess the other thing you want to include in the about box is a way for people to find your support site and any notices of importance to users of the particular version (whether or not you have a provision in your app for checking on-line for updates).
Ant task seems to be the best way. We do a similar thing in one of our projects. All the open source libraries are present in a specified folder. An Ant task reads the manifest of these libraries, versions and so on and generates an HTML, copies into another specified folder from where it is picked up by the web container.
Generating the page with each build would be wasteful if the libraries are not going to change often. Library versions may change, but the actual libraries don't. Easier to just create a HTML page would be the easiest way out, but that's one more maintenance head ache. Generate it once and include it with the package. The script can always be run again in case some changes are being made to the libraries (updating versions, adding new libraries).