The Alfa language submitted to OASIS by Axiomatics looks quite nice. However I wonder whether there is any free compiler from Alfa to XACML. The license file which comes with the Axiomatics Eclipse plugin states it is for non-commercial / evaluation. And it is not integrated with Maven etc. Is there some free alternative?
Related
I want to use Kotlin with the Spring Tools suite plugin for VSCode but it only supports Java (For things like intellisense).
I know I should just use intelliJ and I will for now but I program in a lot of different languages daily and I would like to do all of this from the same tool.
The Spring Tools 4 extension for VSCode does not support Kotlin yet (for the Spring specific tooling). Feel free to comment on https://github.com/spring-projects/sts4/issues/163
I am looking for a plugin to use in IntelliJ to edit visually a .bpmn file. I installed the JBoss jBPM plugin, but it doesn't associate or open up a *.bpmn2 file. Can someone suggest if this supported in IntelliJ or another plugin is available to visually edit a .bpmn2 file?
JBoss JBPM plugin is an old plugin that covers Jboss proprietary jPDL notation but doesn't cover BPMN. There is also ActiBPM plugin ((https://plugins.jetbrains.com/plugin/7429?pr=), but it seems to be dead. Unfortunately there is no better tool for IntelliJ, so you probably remain stuck with your current tools (I'm stuck with Eclipse + Camunda plugin).
Unfortunately, most BPMN 2.0 engines I've seen use slightly different dialects. It means that the file structure is the same. But the details, like executed Java class reference, are provided in a slightly different way, for example by using custom XML namespace that is relevant to the concrete BPMN engine.
I've created a plugin for Flowable BPMN and IntelliJ with navigation-to-code-support:
https://plugins.jetbrains.com/plugin/14318-flowable-bpmn-visualizer
And sources are here:
https://github.com/valb3r/flowable-bpmn-intellij-plugin
What I suggest is community participation in expanding this plugin or forking it to support i.e. JBPMN BPMN 2.0 dialect, as all we need to change is XML Parser, and all other parts of the plugin can remain as is
Can Workspace Mechanic be configured to load certain rules only if a given plugin or feature is installed?
For example, we have both Java and C++ developers. As it stands today, you get the option to follow both Java AND C++ guidelines in the workspace popup. Can Workspace Mechanic check if JDT and/or CDT are installed?
I do not think Workspace Mechnanic supports this out of the box. However, as it provides extension points, you may be able to build your own plugin to reach your goal. I did it once, but had to use a fragment to access internal capabilities not to reinvent the wheel.
My customer needs a more organized inventory of all 3rd-party libraries (such as JAR files) that are used in production for their projects. I am involved with a number of their Java-based projects. Their inventory has not been consistently maintained in the past and the time has come to account for all the libraries that are currently being used (there are quite a few!) and to enforce a structured process for introducing new libraries into the build environment.
I have tried pitching the idea of using Maven and Artifactory in their build process to leverage those tools' ability to manage a repository of binary libraries and handle transitive library dependencies. The customer is resistent to the suggestion because they think it will create more work for them to maintain an Artifactory server and learn the basics of Maven.
Currently, their Java projects are all built using Ant scripts. Transitive dependencies are largely managed by trial-and-error. The inventory of libraries currently in use is maintained by hand and the binaries are stored in a Subversion repository. The customer recognizes that this needs to be improved, but the current suggestions for improvement involve more ad-hoc "manage it by hand" approaches.
I want to convince the customer that a combination of Maven and Artifactory is a viable off-the-shelf solution for their Java library management needs. Can anyone direct me to literature/materials that I can use to create a presentation for my customer on the features and strengths of Maven and Artifactory?
Any other arguments/suggestions/etc that would assist me in this would also be appreciated.
I want to convince the customer that a combination of Maven and Artifactory is a viable off-the-shelf solution for their Java library management needs.
As pointed out in a comment, your customer doesn't necessarily need to fully adopt Maven to benefit from dependency management, you could adapt the existing ant scripts to use the Maven Ant tasks or Ivy. This might be less scary and already remove some pain.
Regarding the way Maven manages dependencies, I would simply explain that:
An artifact is identified by coordinates (groupId, artifactId, version).
This allows to store store them using a standardized directory structure (a repository)
A dependency is more that a JAR: it's a JAR with a POM which enables things like transitive dependencies resolution.
And the benefits of such a dependency management solution are:
no mess with dependencies, they are uniquely identified (no more "what version is that?" syndrom)
no more binary data in the VCS (faster checkout, less space)
easier reuse of artifacts between projects (no more jars sent by email)
easier management with transitive dependency resolution
And because you don't want to rely on public repositories, because you need to store your own artifacts, you need an enterprise repository. My personal choice would be Nexus:
because it's file based (unlike Artifactory, and I don't want to put my artifacts in a database)
because it's simple to install/use
because it's easy to administrate
Here are some resources about Nexus (sorry, I just don't use Artifactory):
Should we use Nexus or Artifactory for a Maven Repo?
Ning’s Migration from Artifactory to Nexus Professional
From Apache Archiva to Sonatype Nexus
And just in case, here are some presentation material about Maven:
Several presentations by Arnaud Héritier.
Maven 2.x by Jason van Zyl.
Maven 2.0 - Improve your build patterns by Vincent Massol.
3.5. Core Concepts in the Maven Definitive Guide
I have some basic questions in eclipse plugin development, can anyone give clarification of the following questions,
When should we have to add features in our plugin development ?
What is the difference between feature and plugin.xml ?
Regards
Mathan
As mentioned in this thread:
A plugin is the eclipse "unit of work". An OSGi bundle that supplies a classpath and can contribute to eclipse through extensions.
A fragment points to a host plugin, and anything it provides (classpath, extensions, etc) are "sucked" into the host plugin. A fragment is also a more specialized OSGi bundle.
A feature represents a versioned collection of plugins, and is used for configuration management in eclipse. They can be deployed manually or through the update manager. If you want to deploy through the update manager, then you need to use features to represent your plugins.
So if you want to manage your plugin or plugins through the update manager, a feature is in order.
You can find more in the Eclipse Help:
Feature
Features do not contain any code.
They merely describe a set of plug-ins that provide the function for the feature and information about how to update it.
Features are packaged in a feature archive file and described using a feature manifest file, feature.xml.
Plugin
While features are organized for the purposes of distributing and updating products, plug-ins are organized to facilitate the development of the product function among the product team. The development team determines when to carve up program function into a separate plug-in.
Plug-ins are packaged in a plug-in archive file and described using a plug-in manifest file, plugin.xml.