we are trying to develop a web application framework and build implementatins on top of it. This framwork will be versioned in SVN, live its own life in parallel to those implementations. It will have lots of spring config files, security config and so on. We would like to use those in those implementations.
What structure should such an project have? Keep everything together? Link particular folers (implementations) in "svn: externals"? We would like to use Maven, and create an archetype for those implementations, but is it possible to update the archetype after it has been changed in implementation applications?
Regards,
This is a good example :
http://www.sonatype.com/books/mvnex-book/reference/web.html
Also this book is very useful resource when starting with maven
I found this also :
http://www.avajava.com/tutorials/lessons/how-do-i-create-a-web-application-project-using-maven.html
I'd suggest you create your framework project as a simple jar project to include in your implementation, which would be war projects. For the Spring config files you have three options then:
Package them into your framework jar. This would make it hard for the implementations to customize it. I would not recommend it, unless your configuration is definitively fixed.
Use svn: externals. I have not much experience with that, but I think dependencies between svn repositories would be hard to manage.
Maintain these configuration files per implementation. So, an archetype would help to get started with an initial configuration. Then maintain these configuration files as your framework evolves. This is what we do most of the time. The good thing about Spring configuration is that it often rarely needs to be touched once you are confident with it.
Related
I have created a Selenium Java Framework with a proper folder structure. Basically my framework consists of few common utilities(page objects, reporting configurations and, driver initialization settings, etc.). This framework was developed to automate and validate web applications. We have a bunch of web applications in our organization that are common in nature and behavior. The Java framework that I have developed has some generic methods and page objects that can be utilized in all the web applications.
Now, I have pushed my framework to the Github. And, I want other teams in my organization also to use my framework. So, in my organization for each project, we create a new repo. Therefore, I wanted to know if by any chance my framework can be accessed by other teams of my organization in their projects.
I don't want anyone to clone my framework repo, add their tests, and push it back. As each project in my organization will have their own repo. Therefore, I simply want them to add my framework as a dependency in their project repo. And, when they clone their repo and do a maven build, they should be able to access the utilities of my framework. Please let me know if this is possible by any chance. Thanks! in advance.
You have multiple options.
Option 1:
Give read-only access to the outside your project users, so that they can extract and re-use the items from the framework without impact your code. Other teams can tailor the framework according to their needs (you can consider it as adv/ disadv)
Option 2:
Convert your framework into a jar and then share it with other teams. Ask them to use the jar. No Edits in framework possible.
We are exactly doing the same thing (we are using option-2 as below). Other teams need to use it as a dependency in their pom.xml. Two ways to use the dependency in maven:
If your company has maven artifactory management system, you can publish your framework jar into that and ask the other teams to use it as a dependency in their pom.xml directly
Else,
2. You need to prepare a jar file, and the other teams need to use it as a dependency using system scope level as below:
<!-- Framework -->
<dependency>
<groupId>com.test.group></groupId>
<artifactId>automation-framework</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>system</scope>
<systemPath>${jar.location}</systemPath>
</dependency>
groupId, artifactId, and version are the details of your framework project.
Other teams can create a folder called "libs" in in their project, and store your framework's jar in there. That location will go here: ${jar.location}
Every time you make changes to your framework and build new jar, they need to update the jar file under "libs" folder.
In this way, they can use all your utilities, but can't modify or publish any tests into your project.
You need to keep utils package and create all utils classes into that package and use it
In every projects you need to keep package for separate keeping utils classes
I have a complex structure of maven module with involves some like 20 modules for a standard application. The standard application is also supposed to contain spring xml files and packages folder setup from the start. Right now we are copying a example application and change the name all over it. But this seems like a lot of unnecessary work. I'm wondering what software would be best to use generate this.
I saw that maven had something for this called archetype but i'm not find much documentation and example on how to use it. Maybe there is better tool for this task.
When I first started looking at OSGi I was under the impression that you could just build a JAR and as-long as it had a manifest file, you could deploy it in a OSGi container. I imagined building my modules in a classic way (maven), and maybe use some plugin or something of the sort to write the manifest, I could then have my module that would basically be a standalone application communicating with other modules through OSGi.
Further reading about OSGi, I'm beginning to see more examples of it being used at a more low-level and basically replacing dependency injection and providing cross-cutting concern services like logging. And seems that using things like hibernate or others, is a problem... (or maybe I'm just missing something).
At least for me, I don't really see the point of having a such fine-gained level of modularity and integration to OSGi, I would much rather have a separate modules, each one of them having its own set of technologies and frameworks, and possibly a web resources and persistence layer. Is this achievable with OSGi? If yes, can you point me in the right direction, examples etc.?
edit, added some more details of how I'm trying to use OSGi:
I'm just envisioning the possibility of having a more than one-class module, that might have a more higher-level responsibility.
Like say agenda module. In this case I want to have things like, persistence of the events, add events, list events with filters, etc...
This agenda might have several internal classes, and might even need a persistence layer. So I would like to use something like Guice to DI those classes, and some JPA to persist my data.
I can understand that some X-cutting concerns like server or logging can have a bundle, but the data model is specific to the agenda bundle. So I think my question was at the end What is and what is not possible to do inside a bundle? And what should and shouldn't be done inside as a general practice?
Thanks!
Mauricio
You can use OSGi without forcing any dependencies on OSGi on the application code. However, since OSGi provides modularity, the middleware (your layers) need to have some knowledge of OSGi. The problem is that in a modular world you want to hide implementation details, that is the whole purpose. However, things like Spring and Hibernate tend to assume the classpath has no boundaries and they run head on into the fences. Fortunately, more and more middleware is becoming prepared for this, I heard Hibernate now has an effort and JPA is also available in OSGi.
OSGi is many things to many people, and you can almost pick and choose what parts of it you want to use:
Do you have a plain library that doesn't use any other dependencies? Sweet, just put up a minimal MANIFEST.MF listing the public packages, use maven to build your JAR and you're done.
Do you have dependencies? Same as (1), you just add the imported packages in your manifest.
Do you need to perform some initialization? Write an Activator, and mention it in your manifest.
Services? Just put the dependencies and descriptions of those in XML files and add them in the manifest.
And so on - just use the level where you are comfortable.
On the other hand, if you want to do web applications you really need to consider the architectural interplay between OSGi, the libraries you use, your application manager and the servlet/jee/whatever container. At what level will OSGi reside? In a general sense, there are OSGi->container->app, container->OSGi->app and container->app->OSGi solutions, and each has their own idiosyncrasies.
Concerning building with maven, you can use the Maven-Bundle-Plugin it helps you to build OSGi bundles without having to write the manifest on your own. All the required meta information will be in your POM.
Dependency injection can be achieved on top of the module layer. One possible solution would be Declarative Services which enables you to inject via an XML description or code annotations. It strongly reflects the dynamic nature of OSGi Services (dynamic binding unbinding of services).
The alternative is Blueprint which is based upon spring and features a very similar syntax. One key feature is that it can abstract the nature of binding and unbinding of services. If you think about using Spring, use Blueprint.
OSGi only implies how you structure your modules. You get a well defined graph of module interactions (who imports/exports a package? Who exports Services and who uses it?)
therefore you can build an enterprise architecture on top of it by building cohesive bundles for every task.
OSGi is sometimes referred to as a service-oriented architecture for the JVM. Looking at bundles as modular units that provide services helps define the right granularity: you'll usually have API bundles which are just here to provide java packages that define APIs, service bundles that provide implementations of these APIs, and utility/auxiliary bundles that provide the cross-cutting services that you mention.
You can use some dependency injection frameworks on top of OSGi, but from my experience (with Apache Sling and Adobe CQ5) keeping things simple is often better. The OSGi Service Component Runtime and Configuration Admin provide all I need to manage services, dependencies and configurations, especially if you design your system for that from the beginning.
You can find a bit more about our experience with OSGi in designing Adobe CQ5 in my "tales from the OSGi trenches" slides at http://www.slideshare.net/bdelacretaz/tales-from-the-osgi-trenches-2012-short-form-edition - that might help get a better feel for how OSGi is used in building complex systems.
I'm building a J2EE application in which I want to allows plugins. I'm fairly convince of the goodness of IoC framework, and so the application will have one to manage services.
Now, I want to allows plugins to be added as simple JAR dropped in the classpath + perhaps a simple configuration file to edit to activate them, in no way something looking like Spring XML config files.
Most of the plugin architecture will be base around strategy/pipeline/chain of command patterns: for example the best plugin for an action is chosen by strategy, several plugins add filtering actions to an user input thanks to a pipeline, and so one.
So, I want to be able to:
define service interfaces in the core application,
set-up core implementation for extensible services with the chosen pattern in the main application,
let third party plugins register themselves in these hooks.
The first 2 points are quite easy, with or without IoC. The last one seems more complex without support at the IoC container level, or at least there is a lot of plumbing to do (how to manage classpath/sevice discovery, how to manage service orders in pipeline when the context change (new plugins), how to manage service overriding, etc).
I do know that Tapestry5 is great in that regards[1], but I can't find anything really relevant for Spring and Guice. And my company is more a String/Guice one than a T5 one (well, if I'm able to show that it's the best solution...)
So I'm wondering:
if I missed some obvious documentation;
if my requirement are so specials;
if an IoC container is not the right tool for that, and I should look for OSGi or something else.
Thanks for any tips !
[1] http://tapestry.apache.org/tapestry5.1/tapestry-ioc/configuration.html
I'm not sure how this would work with exactly what you're looking to do, but Guice's basic mechanic for handling plugins is Multibindings. How you handle discovery of plugins is up to you, but there are a variety of choices including scanning the classpath for implementations of plugin interfaces, having plugins provide a Module that adds their implementation(s) to the multibinder(s), using a config file that lists the plugin implementation classes, etc.
As the link mentions, you'd need OSGi if you need plugins to be addable at runtime with no restart.
Have you considered having a look at the Java EE 6 solution - CDI, implementation is named Weld based on JBoss Seam - which might be useful?
Once you start dropping in jars and their dependencies and then go though a couple of iterations of this with different plugins and different dependency versions, then you will start to feel the pain that many "application host containers" succumb to.
One possible solution to this problem is OSGi, although I did note a Tapestry blog highlighting the pitfalls of the OSGi approach:
http://blog.tapestry5.de/index.php/2010/01/19/tapestry-ioc-modularization-of-web-applications-without-osgi/
Sometimes, it's very tediously to make own configuration, find all libraries, check it ...
So, is there any ready typical (template) config for appropriative task?
AppFuse can be used for generating project templates for your given choice and combination of technologies.
Spring Roo is designed for this. It's on RC2 for their 1.0 release now.
It has a command shell environment that allows you to pick and setup the parts of the Spring application you'd like to use. It generates the Spring config files, Maven setup, and templates the Java classes for you.
Besides being great for templating, it's also a good way to get yourself introduced to other parts of the Spring application stack (Web Flow, Security).
Maybe you'll find what you're looking for here: http://code.google.com/p/project-template/.
There is no ready made runtime config for your application but you can use things like Maven or Ivy to manage all the JARs you need automatically.
You could start from one of the examples as provided in the Spring download package and modify it to suits your need.