I am using the open-source JBoss BRMS application from jboss.org. Hopefully, if you clicked on this post you are familiar with this web application that can be used to develop applications that use Drools rules.
I am following along with the tutorial on building an application that uses a Decision Table to create the rules. That tutorial can be found here: http://www.jboss.org//quickstarts/brms/decision-table/index.html. I was able to successfully execute this tutorial after modifying the pom.xml some.
My question is how can I create my own similar application? This example application works by importing some Java classes into the BRMS repository and also putting a pre-configured Settings.xml file in the ./m2 Maven repository. There are also some folders at another location on my computer that contain 1) a pom.xml file and 2) a src and test directory which contain other things like java source files, compiled byte-code, and some XML files. How can I do this on my own and build my own JBoss BRMS Decision Table application? I was able to create some classes and a spreadsheet and validated this with JBoss BRMS but I am still confused on how to a) create the pom.xml file, b) create the Settings.xml file, and c) create the folders with the required program files like java source code to use Maven to build and run.
I have been reading the Drools documentation and the "proprietary documentation" from Red Hat on the business rules management system (BRMS) that is not too helpful as of yet. It is somewhat helpful but not really. I call it "proprietary documentation" because it is on access.redhat.com which requires a subscription to even download trial software. Jboss.org has completely free versions of similar software. I hope this made sense. Please reply in the comments if it did not make any sense to you.
Respectfully,
user3870315
Related
I am working on a project using the Java Spring framework, but I am (even after googling or looking through tutorials) unable to understand how it should be used.
Situation:
The project is(or, will be) made up of 3 separate web applications(for three different uses/target audiences) that uses the same database and to some extent functions and/or classes.
Database/cryptography-related classes and such are in a common folder under the project root, which seems appropriate.
Then there is a folder for gradle, used for starting the program("./gradlew app-one:bootRun"), which I suppose makes sense.
Then, there is a folder for one of the web applications("app-one") with related source code(Controllers, Services, etc.) and whatnot.
Problem:
I am tasked with adding the second application. Is it suppose to be a separate folder in the root directory?(Logically/By framework standards)
If it is not, how do I know what belongs to which application?
Do I need to use separate gradle commands to start each of the three applications? Is that even possible, and is it recommended/efficient/the best way to structure everything?
If you want to use maven,you can create a multi-module maven project with parent pom having all dependency management.A core project(jar) having all core functionality and three web projects(war) for your web modules which depend on this core project.You can start build and run these projects with a bat script from one place only.
Typically on a Java project using Maven, you place client-side source files in src/main/webapp. This directory includes your html, css, scripts, images, etc.
However, many grunt projects tend to place these files on the root. It's as if Grunt was designed with the idea that your project is the client-side application, not part of a large server-side project, such as using Java with Spring.
Given a Java project using Maven, where would be the best place to put your web-related source files?
Do you place them in src/main/webapp?
Do you make another directory altogether, such as src/web, and then on a build, copy everything to src/main/webapp?
My goal is to make the client-side build tool as transparent as possible. I guess the ideal case is to simply work from src/main/webapp as I have been doing all along - this is pretty unobtrusive to the way my project is currently setup.
However, if I work from src/main/webapp, I know that I will need to distinguish between src and build directories somehow anyway. I'm sure my html files can stay where they are, but there's definitely going to be a conflict of interest here with javascript and css files, and maybe images too.
Does it make sense to literally have a 100% separate source folder from src/main/webapp? Is there a way to do continuous building/copying/syncing of the application as you modify files, from src/web to src/main/webapp? Will this be inconvenient and cause frustrations and problems? Is it slow?
I would like any advice on the subject. Thank you.
Option 1: Put UI resources in src/main/webapp:
This is a quick-n-dirty solution popular on Github. It helps to keep example projects small and concise. In this case, usually people put the package.json, bower.json, Gruntfile.js and .bowerrc in the maven project's root directory, where the .bowerrc says to install components into src/main/webapp/bower_components.
If you have a task that minifies/transforms resources, the transformed resources can go to a new directory like src/main/webapp/dist. Then use something like grunt-usemin to make your app use the resources in the dist directory.
If your application will use a security framework (like, say, Spring Security), you might want all your resources in src/main/webapp so that the security framework can regulate access to those resources. However you can still achieve this using Option 2 by having a grunt task that copies the necessary resources into src/main/webapp.
Pros
Common approach on GitHub. Keeps everything in one project.
Cons
The version of files getting served by your server is a copy of those in src/main/webapp, so changing a file in src/main/webapp isn't immediately reflected in your deployed app. To get hot reloading, you need to use something like grunt-contrib-* stuff.
Frontend and backend code is all mixed together. Harder for two different teams to work on the code base.
Option 2: Put UI resources in a separate project:
You can achieve better project organization by keeping the UI and backend in completely separate projects. In this case the UI and the maven project would likely be sibling directories.
Then when deploying to a server, you either:
deploy both projects separately (call them myproject-ui and myproject-services). The javascript in myproject-ui makes RESTful service calls to myproject-services/**.
Use a grunt task to copy necessary resources to src/main/webapp, then deploy your (one) project.
Pros
The backend and the frontend are separated as much as possible
The frontend maintains the workflow and directory structure found in most client-side example apps, as you mentioned
"Deploying" the UI is a simple matter of creating a symlink from your server's deployment directory to you UI source code. Changing any UI code is automatically reflected in the deployed app.
You can have several different UIs deployed simultaneously (maybe you have myproject-admin-ui and myproject-user-ui). You could hit either one simply by visiting
http://localhost:8080/myproject-admin-ui
http://localhost:8080/myproject-user-ui
I recently started developing a plugin, which consist of several Eclipse Plugin-Projects. I use Maven/Yycho as a build tool and GitHub as version control system.
Now I was wondering what to push to my GitHub repositories. The POM files and Feature/Updatesites as well? It seems that this stuff is:
very User specific (the path are relative to the file structure on my computer)
do other developers need that stuff or should I give them the freedom of choosing their own build tools?
To clarify, I have right now 6 Eclipse projects:
*.plugin1
*.plugin1.tests
*.plugin2
*.releng
*.feature
*.p2updatesite
Would it be good practise to share everything? From my feeling I would say I will only share plugin1+tests & item # 2 (without the pom files) so that everyone can take care themselves about building.
You don't have to add to your repo:
anything that can easily be regenerated
anything with local paths specific to a user
Regarding building, ideally you should version at least a script able to generate the right pom, in order for a new contributor to be able to get going as fast as possible after cloning it.
If you can have config files with only relative paths (instead of absolute one), then you can include those, for others to use.
See for instance ".classpath and .project - check into version control or not?".
I have a maven project which generate zip generated from ant scripts. Then this zip is deployed to specific application server again using ant script. this is very complex for maintenance. Now we move to use maven for building zip, so what is standard way to doing with respect to developer and client
How to handle application server specific deployment(e.g for weblogic and jboss) Do I need to create 2 zip for each server?
How to handle global configuration parameter like database, product specific settings. Where to put them, and how it use by developer and client?
The installation of application sever is need to integrate with build cycle or what is best practice for it?
I'll try to answer based on my experience:
I use maven profiles for this. Especially since there are beans (classes) that are specific to only one app server at a time. See http://maven.apache.org/guides/introduction/introduction-to-profiles.html
maven supports placeholders. One build for every single environment: dev/qa/prod,etc. All you need is the properties file. (this is similar to properties in ant)
You do not need (usually, unless you have integration tests that are tight to the app server - and if you do, it seems wrong) an app server for the build itself.
I am trying to create a stand alone Java application that accepts an xmi model and an OCL file containing constraints applied to the model's meta-model. The application then validates the model against the ocl.
I have managed to do this inside eclipse using the EMF. However when I start to create the java app, many libraries are missing. Some of which I was able to locate in the plugins directory but some seem to be missing.
For example
org.eclipse.ocl.examples.library.oclstdlib.OCLstdlib;
cannot be found.
Is there a straight forward way, using the EMF to accomplish what I am trying to do. I have been trying to create something very much like the following:
http://subversion.assembla.com/svn/da_sw_tf/trunk/OCL/src/ocl/OCLEvaluator.java
Something missing, usually means something bad configured. Without more information I can only point you out to the OCL Help, where it explains why and how you need to do some manual registrations in order to execute OCL code in standalone mode.
Taken from the help:
"If you use Eclipse OCL within Eclipse you should find that the
appropriate registrations are provided for you automatically by the
plugin registration mechanisms.
However if you use Eclipse OCL outside Eclipse, for instance in JUnit
tests, you must provide the corresponding registrations in your code."
The eclipse plugins were located in my personal folder under .eclipse. I had completely forgotten about the personal instances of the plugins. Instead I re-installed everything only to realise the the libraries were not in the install directory plugins folder.
Installing the EMF and OCL plugins from the following link were correct.
http://download.eclipse.org/releases/kepler
note: you may have to change the above url to suit your particular eclipse version.