I want to split my Eclipse project into several modules. For simplicity's sake let's say those projects will be Client,Server and Common (which both Client and Server will depend on). There are several jars that would need to be used in all 3 projects.
Should I export the jars from the Common project or should each project define all of the external jars it depends on for itself?
I would suggest to use Maven in such scenario....
Good Luck!!!
Related
How can I share data between bundles in Karaf? I am loading two bundles in different features. I want to write into something like a shared memory segment from one of the bundles and read it from another bundle. Thanks
Basically you can use all ways to communicate as in any other java application. Not all libraries are nicely compatible to OSGi though.
One built in way to communicate in a loosely coupled way is the eventadmin service. See this tutorial from vogella for example.
The most typical case in OSGi is to let one bundle offer an OSGi service and the other one call it.
There are also libs like hazelcast which use kind of a shared memory even between nodes of a cluster. It is difficult to recommend one way without knowing more about your requirements and what you are trying to do.
I'm working on a pretty big application for Flex/Air. We are using GraniteDS and Tide to interact with the model from our Java EE server.
I've been reading about modularization and Modules in Flex. The application has already been built, and I'm figuring a way out to re-design some classes and parts. From what I've read so far, I understand a Module is a different swf which can be dynamically load. Most of the tutorials/documentation are oriented to Flash "programmers" who are using Flex or Air instead of real developers, so that makes online resources harder to get.
What I can't understand - yet - is how to encapsulate ActionScript classes or MXML views under this module.
I've separated some of the code into libraries. For example, the generated code from Granite is in a "server" library. But I would like to separate parts of the logic with its Moderators, Controllers and Views. Are modules the way to go? Is there a "modules for dummies" or "head first Flex Modules for programmers" like tutorial in order to get a better perspective in order to build my architecture? When to choose libraries and when to choose modules?
I'm using Flex 3.5, and a migration to Flex 4 is way far into the future, so no Flex 4 answers please, thanks!
Modules are the answer for encapsulating UI into different sections that do not depend on each other. Think of them like applications inside of applications.
If you want to encapsulate "code", meaning non-ui actionscript, then you really just want classes and packages of classes. You could also package that code into a swc, which is just a compiled version of that code that you can include in multiple projects (I think this is what you meant by libraries).
You wouldn't want to create a module just to contain non-ui code. You wouldn't want to use modules for separating out the model/view/controller in your application.
If you have part of your application, that for the most part runs completely on its own, with no real dependencies on the rest of the application except for maybe a little bit of information passed in, then it makes sense for modules.
Where we use modules mostly is for an application that has different sections to it where you are only working in one section at a time. There is no need for the other sections to be taking up resources, so we have the different sections in modules and load/unload them as necessary.
Does that help?
Edit in reply to the comment below:
By libraries I meant Flex Library
Projects, where you encapsulate
classses and use the swc. Can you have
these libraries inside a Flex Project?
(I use a separate Library Project for
each new library).
Yes, you can use these swc's (Libraries of code) inside of your flex projects. Just drop the swc in the lib directory in your flex/flash builder project and the code is automatically added to your classpath. Just make sure that everything that the code inside a single swc needs is inside that swc. Don't make a swc rely on another swc to function.
I'd like to be able to understand how to develop a Flex application such that I could provide implementation classes at runtime. In the Java world I'd specify interfaces in an JAR (e.g. myapp-api.jar), the implementation in a separate JAR (e.g. myapp-impl.jar) and package these along with other resources in the application WAR (e.g. myapp.war). Within the code of the application I would instantiate the implementation classes dynamically.
Is this approach possible in Flex? I'm aware that I can instantiate classes dynamically so that's a good start. I'm a bit confused by modules, RSLs and SWCs though.
I was hoping to create a SWF application that had references to an interfaces SWC and an implementation SWC. The idea is that if I need to tweak the application for a specific customer then I could create a new implementation SWC and not have to modify the SWF or interface SWC.
Any ideas?
This is a bit harder to do in flash/flex than it is in java, or at least it is a bit more obscure if you are coming from a java background). I have a couple of pointers for you.
You only have to use RSLs if you really want to have separate libraries of classes at runtime, and especially if you think this library will be used across several projects that the same set of people will be using. (They are mainly intended to decrease download/startup time)
You can also divide your app in several parts yourself - in that case you need to make sure that you don't pack the same info twice - this can be done by generating a linkreport on the first compiled swf and excluding these classes from the second compile. This is how modules work in flex.
SWCs are mainly used as a compile-time library (they are basically a zip containing a swf and a metadata xml file that describes its contents).
If you want to have a separate set of interfaces in a library you could generate a swc with the interfaces and compile another swc with the implementation, you should exclude the interfaces when compiling the implementation classes if you want to avoid having duplicate class/interface definitions. If you compile your final app when linking both the interface and implementation SWCs without excluding the classes you can just use your single final SWF to run the app - if you want to keep it really separate you should look into modules (or plain loading swfs if you are creating a pure actionscript project).
I did use SWCs myself as described above, and am now looking into RSLs and Modules myself for our curren project.
I am planning on a Flex project that involves incorporation of a lot of features.
Each 'feature' can be a component / module.
Which is preferred and what is the difference between a module and a component?
Thanks
The short answer is that it depends.
If you going to use all, or most, of your components during regular execution of the application - components would be alright.
By the sounds of things though, modules might be the better bet for your project.
Modules allow you to group components into external libraries (RSLs). These libraries can be embedded into your application (through project settings) or can be loaded dynamically at runtime (as separate files).
Modules would give you some benefits
Only loading the libraries needed (as needed) instead of all modules everytime.
Load only core modules initially to speed up the initial load time.
Changes to a component do not require you to recompile the application/
Find out more about creating modules here.
I'm doing some work with several shared .NET assemblies and a generic web application that I would like to handle better in our CC.NET/NAnt build environment.
Currently, we have several .NET assemblies (shared common code that we use in client projects) that exist in different .NET solutions within different repositories in our SCM (Vault incidentally). They are all configured under CC.NET separately so we have a decent amount of control over their build and deployment at present.
We have developed a CMS system that uses some of the .NET assemblies and includes a common administration website project and a template website example project. Out of this one solution we have the following elements that need to managed separately:
Admin interface is not tied to .NET so it is template based and we are developing a PHP backend for it currently.
CMS shared assembly build on top of our other common company wide assemblies.
Control over functionality within each major CMS build/release.
I'd like the build output of this solution to be a Visual Studio template, which we can use to develop other client sites and better manage version changes within the CMS itself, as we add features to the codebase.
I have a rough approach for all this and think it is achievable, however, I wanted to open this topic up for discussion and see what everyone else is doing when it comes to managing the build and deployment of multiple solutions.
Main considerations for us are:
Do we make use of the integration queue functionality in CC.NET to ensure a build order and pull together the assemblies we need for the CMS at build time?
Debugging within a CMS client site i.e. stepping into the shared assemblies' code when the client solution is a version of the base CMS system and therefore separate.
Developing and extending the CMS when it uses shared assemblies i.e. do we add the assembly projects to the trunk solution during development (across source control repositories) and then rely on the build to pull it together or do we use a different approach entirely?
Any other issues people might have experienced that could change our way of thinking?
Hopefully this question isn't too vague and some of you will have dealt with these issues. Look forward to hearing everyones experiences.
Many thanks!
Tim
I unfortunately cannot answer all of your points, but let me start with this one:
Do we make use of the integration queue functionality in CC.NET to
ensure a build order and pull together
the assemblies we need for the CMS at
build time?
The short answer is -yes, you should. The queue attribute ensures a build order within the running instance of CC.NET and is gives you serialization of the builds that depend on each other. For specifying which projects depend on each other, you should use project triggers. Do not rely on the queuePriority for this task.
You shold most likely pull the pieces you need to do the build at build time. Unless you have some time constraints on your individual builds.
Re:
Developing and extending the CMS when it uses shared assemblies i.e. do we add the assembly projects to the trunk solution during development (across source control repositories) and then rely on the build to pull it together or do we use a different approach entirely?
I'm fundamentally against distributing binaries in the trunk unless it's some libraries that does not need to be updated/changed on a frequent basis. If you build the shared assemblies yourself, you should consider pulling them from the artifacts on the build server(s).