I have experience in swapping business logic in .NET by loading assemblies, and using reflection to find an implemented interface. This enabled behaviour composition at runtime, by simply distributing and placing DLL files into its working directory. How can I achieve the same in Clojure?
I have been informed I could compile my Lein project without AoT compilation, with dependency on a class which the JVM will search for I assume from sibling JAR files? I've also seen Java 9 has a solution called "Jigsaw", and there other projects such as lein-jlink too. I'm unsure if those are suitable.
I'd really appreciate an article/tutorial, working example, or a good few hints on how to do this as I'm new to JVM also.
My project in particular would involve a business logic model "module" loaded at startup, consuming messages and producing messages in return. It's meant to be somewhat a blackbox.
An alternate route I'd like to avoid is an MQTT-style approach where distributed modules are relatively heavy standalone programs.
Thank you for your time.
In plain Java you can have use same approach as you did in C#: you develop a core and provide interfaces that can be used for extensions, then you inspect (using reflection) the Java CLASSPATH for implementations of the interface in Jar files (this is the same idea of DLLs), but the Java CLASSPATH is either an environment variable or a command-line parameter with a list of paths where to search for Jar files.
In Clojure, you have the advantage that you can distribute libraries either as compiled code or as source code which the Clojure runtime will load. I'd recommend looking into the Deps and CLI guide because it will give you good guidance into how to:
add dependencies on a configuration file through various means, including loading dependencies from private repos, or even a dependency in a git repo at an exact commit
launching you code with the various switches or configuration you might need, so that you can change behaviour by editing a config file
I have two questions about Worklight 6.2 build process:
Question 1: Is it possible to integrate the standard Worklight (6.2) build process with a custom build step?
I need to add it as follows:
Init build process
WLApp Build (optimization step)
Custom step
WLApp packaging
Adapters build and packaging
WAR build and packaging
End build process
Question 2 (about step 3): Is it possible to modify wlapp files before wlapp packaging process (immediatly after the optimization step)?
I'm using the CLI command: wl build.
As of Worklight 6.2, there is no supported way to perform custom activities during the standard Worklight build. For production purposes, where you may want to obfuscate JS, shrink images, etc, it is common to perform this on a build system, PRIOR to the WL build and packaging. This complicates the per-environment optimization, but is the best we can do at this time.
As far as hacking the resulting WLApp file, I do not believe this could be done, as it will fail security checks, once deployed.
We are looking to enable extending the build process in a future release. There are already RFEs defined for this that we are evaluating. Along similar lines, we are looking into providing easy obfuscation of JS resources during a build. This is already possible with Mobile and Desktop WebApps, that we want to extend to include deployable apps.
I'm evaluating Bamboo to replace our Jenkins setup and have a couple questions. I have a .NET solution that generates two artifacts: a packaged website and an MSI. I have three environments I deploy to: test, stage, production. Our Jenkins server in turn has three jobs--one for each environment. Each job builds the solution, copies in configuration files for the environment it will be deployed to and then deploys the artifacts. Reading the documentation and other stuff (https://answers.atlassian.com/questions/19562/plans-stages-jobs-best-practices), I'm getting mixed signals about how deployment should work with Bamboo. It seems to me like deployment plans expect artifacts to exist and then deploy them. But, build plans include deployment steps as well. How is all of this supposed to interact together?
The reason I'm confused is because I have environment specific configuration files that get packaged during a build. Any direction on how this should work?
I posted the question to the Atlassian board as well and got an answer I think I like the best:
Jason Monsorno · 762 karma · Aug 30 '13 at 04:38 PM
Deployment projects in Bamboo seem to be dependant on the existance of
an artifact, the catch is you don't necessary need to use that
artifact so you could use an empty artifact and do completely
independent steps. Deployment projects are still fairly new to Bamboo
and your structure may favor the "normal" workflow so each environment
would be a separate manual stage.
The Deployment project do have a separate workflow and versioning. To
use Deployment projects in your scenario, I'd suggest making the
artifact the entire checkout then each Deployment environment can
build a copy of the artifact. The space-saving/less-time-efficient
option would be to just save the current revision in a file as the
artifact and use that to check it out and build in each Deployment
environment.
I know Maven has a central repository that you can upload build artifacts (assemblies) and reference them in your build script so that you get the latest versions.
Is there any similar tool (other than Maven for .Net) that provides a way to centrally store artifacts and reference them in MSBuild scripts?
I'm trying to figure out how to incorporate a library solution we have that is used across all our other solutions (contains common data access, schemas, etc.)
We don't always automatically want it included in our projects as sometimes we need to stay on a particular version for one project until that project is ready to upgrade to the latest.
If I were you, I'd create a build system that allows publishing packaged 'modules' from one end, and importing from the other end.
You create a shared directory at a global place within your organization and this becomes your "central Repository" you're talking of.
Alas, I'm not aware of any public implementation of such an msbuild system.
I am working on a fairly large project (with a number of modules, a bunch of external libraries etc.) and we are now considering switching from Ant to Maven. I understand the differences between the two, but I am not convinced that it is really worth spending time converting the project layout, setting up all the dependencies, teaching developers and configuration managers doing things "the new way" etc.
There are a lot of resources on the web describing how to migrate from Ant to Maven, but I haven't found that many that say why :-)
Before changing your build system, ask yourself (and the group) why you're changing? If you're changing just because Maven is the "new thing", don't. If you actually see a technical reason to migrate, do it.
In general, unless there's a major compelling reason to do so (new capabilities or much simpler management), I'd say stay with what you have for the current project, but consider Maven for future projects.
Have you read chapter 1 of "Maven, the definitive guide"? In particular, 1.7 Comparing Maven with Ant has an interesting discussion.
I agree with the other answers that advise caution. Maven has strong points, but nothing that can't be done by an Ant build process:
dependency management: Ant has the Ivy subproject, which can interact with Maven repositories.
convention over configuration: you can also do that with Ant, it's just a matter of establishing the rules and enforcing them.
build lifecycle: same as above, you can enforce a convention over the tasks exposed by each build.
build logic reuse (Maven plugins): you can also achieve that in Ant with macrodefs and task libraries.
The thing is, with Maven you get these features out-of-the-box, while with Ant you need a rock-solid build, a very strict set of rules and a way to enforce them (for instance, make sure that everyone follows the conventions when they create a new subproject, that they reuse the existing blocks instead of doing everything from scratch, etc.).
Personally, I would see how well the existing process addresses the issues above: how are dependencies managed, is there a central repository? Are the project structures uniform (when I checkout a project I don't know, how long does it take to figure out how to build it)? Is there some form of build logic reuse, or does each project reinvent the wheel? Which of these features are needed?
Then I would try to balance the cost of adding the missing features to the existing Ant script, against the cost of migrating to Maven (if you don't know Maven, that also includes the cost of learning it).
In any case, I suggest you build a small Maven prototype (5 to 10 projects) illustrating the common cases in your build. You can test a lot of Maven's features with dummy projects containing little java logic (use the archetype plugin to generate them).
Before Maven we were checking dependency libraries (typically third-party, open source variety) into source control - so that we could insure our components compiled and got packaged with the precise versions intended.
Now with Maven in place, we're relying on artifact repositories to hold those versions and we let our pom.xml dependency declarations be the official means of defining version dependencies. This has proven to be a simplifying approach that makes project organization in version control repositories (and their Hudson build projects) much easier to devise. Our local artifact repository is under backup policy along with our source control repositories. It's nice to use the Maven tools to go and search and specify a needed library version. We also use parent pom files to specify dependencies that other project poms inherit by default. So if you want all projects to use the same log4j version, then that is specified in one place in the parent pom file. (But any project can at anytime override and specify a specific version instead of just accepting the default from the parent pom.)
Here is the secret to a successful adoption of Maven:
Use Maven project build approach for
your new greenfield projects
Modify existing legacy projects that
use ant build.xml files to incorporate Maven task
for managing depenedencies (a hybrid
approach)
The benefit is that you can then get all of your projects under Maven dependency management, which is of course it's greatest benefit.
The nice thing about the Maven task for ant, where you specify all dependencies in a pom.xml file, is that it involves just modest modification of the existing ant build.xml file to incorporate Maven for this. From the ant file's perspective, Maven is just a means for defining classpath definitions, which are subsequently used by the various ant build task.
The Maven scope classifier of dependencies can be utilized when defining classpaths such that a suitable classpath can be set for compiling, running unit test, packaging, et al. Other definitions in the pom can also be accessed as ant property definitions.
A lot of existing ant build files are rather complex. It can be a formidable undertaking to convert such projects to a full Maven build process. This hybrid approach of having Maven manage all the dependencies and leave the bulk of the ant build.xml file as is, is most pragmatic.
First, like I'm sure a lot of people will mention, Ant and Maven are not exactly intended to solve the same goals. Since you said you understand what each provides, I won't get into the details of that, so suffice it to say that Ant lets you define the details of how to build individual components, while Maven manages the dependencies between components plus Maven lets you define a complete project build cycle from compile through test and deploy in a programmatic way.
I've used Maven on a couple projects in the past, and I just started using it on another one recently. There are plenty of articles on the net that compare Ant and Maven, so you can look at those, but from my experience, its always worthwhile to consider how you can improve a project. Dependency management and build lifecycle are two important aspects of any large project, and Maven helps in both those areas. If you already have a good build system in place using ant, and your dependencies are kept in a easy to access central location, and you don't plan on extending your build process to include any more advanced build management, then maybe you should stay with what you have.
On the other hand, if you want to use a continuous integration server like hudson or an artifact repository like nexus, then moving your project to maven can really help with build efficiency and automation. You probably would like maven in those situations because the full cycle from dependency to build to artifact can be achieved using those types of tools and you'll be able to better control your builds and releases. On my current project we have many modules and dependencies, like you mention. Migrating to maven so we could use hudson and nexus really helped because we could drop all those 3rd party jars into a nexus repository and stop having to check them into version control or email them around. Also, builds were out of hand because the CM people had a build plan as a document that they would sometimes follow, but making that part of your project (i.e., the pom.xml) defines how you are supposed to build and lets you enforce it. Maven is the glue that holds all of those things together.
In the end, its a matter of how long you expect the project to last, how good your process is now, whether you want to clean up your dependencies, whether you want to enforce your build plan, and whether you want to have the option to use continuous integration and artifact management. If you any of those things, Maven is a strong candidate.