I use Weld on a Java SE application, and I was wondering if generate the Jandex index at build with a plugin will improve the startup.
For now, I didn't notice a performance improvement.
But i found 2 plugins for generating the index:
https://github.com/smallrye/jandex
and
https://github.com/wildfly/jandex-maven-plugin
Any idea witch one to use?
Thanks!
For now, I didn't notice a performance improvement.
This would only be noticeable for large deployments. The reasoning behind it is that having a Jandex index makes it possible to skip the discovery phase via reflection and instead allow Weld to browse a pre-built index.
That being said, there is no harm in using Jandex even on smaller deployments, it's just that the difference won't really be noticeable.
Any idea which one to use?
Short answer is - as of Jul 2022, if you want the maven plugin variant, use the WildFly one. If you want core artifact, use the one with org.jboss.jandex artifact group ID.
Longer answer is - the SmallRye one is the original repo, recently migrated from https://github.com/wildfly/jandex to https://github.com/smallrye/jandex.
It holds the sources of what used to be org.jboss.jandex artifact group ID (and is now io.smallrye). It also has maven plugin module but there is no public release yet and it will be a major version bump as well. Therefore, going forward, there will be an artifact groud ID change but otherwise it will retain the same artifact ID and it will all be hosted in one repo.
Related
I'm developing a private webapp in JSF which is available over the internet and now reached a stage where I wanted to introduce CI (Which I'm fairly new to) into the whole process. My current project setup looks like this:
myApp-persistence: maven project that handles DB access (DAOs and hibernate stuff)
myApp-core: maven project, that includes all the Java code (Beans and Utils). It has a dependency on myApp-persistence.jar
myApp-a: maven project just with frontend code (xhtml, css, JS). Has a dependency on myApp-core.jar
myApp-b: maven project just with frontend code (xhtml, css, JS). Has a dependency on myApp-core.jar
myApp-a and myApp-b are independent from each other, they are just different instances of the core for two different platforms and only display certain components differently or call different bean-methods.
Currently I'm deploying manually, i.e. use the eclipse built-in export as war function and then manually upload it to the deployments dir of my wildfly server on prod. I'm using BitBucket for versioning control and just recently discovered pipelines in BitBucket and implemented one for each repository (every project is a separate repo). Now myApp-persistence builds perfectly fine because all dependencies are accessible via the public maven repo but myApp-core (hence myApp-a and myApp-b, too) fails of course because myApp-persistence isn't published on the central maven repo.
Is it possible to tell BitBucket somehow to use the myApp-persistence.jar in the corresponding repo on BitBucket?
If yes, how? And can I also tell BitBucket to deploy directly to prod in case the build including tests ran fine?
If no, what would be a best practice to do that? I was thinking of using a second dev server (already available, so no big deal) as a CI server but then still I would need some advise or recommendations on which tools (Jenkins, artifactory, etc.) to use.
One important note maybe: I'm the only person working on this project so this might seem like an overkill but for me the process of setting that up is quite some valuable experience. That said, I'm not necessarily looking for the quickest solution but for the most professional and convenient solution.
From my point of view, you can find the solution in this post-https://christiangalsterer.wordpress.com/2015/04/23/continuous-integration-for-pull-requests-with-jenkins-and-stash/. It guides you step by step how to set up everything. The post is from 2015 but the process and idea are still the same. Hope it helps.
I'm trying to get into Groovy scripting in Jenkins, but there seems to be no docs about this and the API is kind of split between package hudson and jenkins. I understand that Hudson is Jenkins' former name, and my first guess is that the devs didn't rename the old packages, but used the new name for newer code - effectively creating a mess. Is this true or am I missing something?
You are somewhat right. Jenkins originated from Hudson , so left the old packages and classes as it is for 2 of the obvious reasons:
To support the old legacy classes and codes written/used all over world. Other wise it would be difficult for every developer to either change or use something like #deprecated #SuppressWarnings
It will take more time to change/restructure all the classes for Jenkins. Even Huge Java community also avoid such things and they only restructure the code when it requires the most. Like they did in Dictionary or Vector classes or even Collections framework during generics implementions.
You can also refer this page for some more answers: How to choose between Hudson and Jenkins?
I'd like to automatically increment my assembly versions based on this ruleset:
Revision is always 0
Build is incremented when the only WIT in the release is a Bug fix
Minor is incremented when the release contains any WIT other than a Bug fix; Build is then always set to 0
Major is never automatically incremented
Naturally this will require a build step that can interact in some way with the project.
My first thought was to build a small Windows Service that utilizes the TFS SDK to construct the version number based on these rules and return it via a WCF call, etc. But I run into a problem there with a business requirement that all code and functionality must be replicated into a VSTS project as well (the customer owns the code and must be able to proceed without me). There's no installing such a service there, of course.
I then considered installing the service on his server, in turn making it available to VSTS. This would pass the Rube Goldberg test with flying colors.
Is there an easier way of accomplishing this task? One that can work in both environments?
EDIT
I found this, but it's doubtful that the TFS SDK is registered in the GAC for VSTS.
Can someone confirm? Is the TFS SDK available to build scripts running on VSTS?
Well now that didn't take long.
I found this and this for using PowerShell to query the REST API. No GAC/SDK needed.
-- EDIT -----------------
I've intentionally excluded content from the pages behind these links as the solutions provided are exceedingly complex; it's not possible to cover the concepts here in a single post. In case the pages disappear or the URLs change, here are the links at archive.org:
1. PowerShell and vNext Builds
2. VSTS/TFS REST API: The basics and working with builds and releases
In any case, the concept is popular and well-covered—in the event these two become inaccessible, there are many others available on the same subject matter. As quickly as I found these, someone could find more.
We are using jenkins for CI and have some complex jobs interdependent.I just want to represent graphically or in any other way the dependencies of jobs.I investigated and installed dependency graph with graphviz representation but its giving too complex figures.Any one know any other plugins?
Consider some view plugins :
https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin (shows you dependency chains)
https://wiki.jenkins-ci.org/display/JENKINS/Delivery+Pipeline+Plugin (shows you dependency chains that affected previous runs)
Jenkins recently added first class support for workflow. Written and supported by Kohsuke.
Some times ago I asked the question about how to integrate an application using dependencies on a build server and I had quite satisfying answers. Today I am facing a different case. For a project I have to use non-redistribuable depedencies (RDL object model for SSRS). It means that out-of-the-box, these assemblies are not made to be deployed for development purpose. But somehow, I need to...
My first guess was to publish them in the GAC. Fine, it worked and the build server was able to compile the project smoothly. But then I realised that it broke some applications like the Report Server and the Report Builder (probably it would also break BIDS). So publishing in the GAC is definitely not a decent solution.
My second guess was to check the assemblies in source control. Well, it could work if I had only 2 assemblies for an amount of about 1MB. But here it is 23 assemblies and 29MB I have to check in, so it is definitely not suitable either.
I don't know much about MSBuild targets and maybe it could be a solution but I really have no idea on how to use it. I have been scratching my head hard and now I have to chose between breaking my builds or breaking my services!
As some people stated in comments we finally decided to source control the assemblies.
But as we are in an environment where we sometimes need to move a lot, which means not always in office, and need to work from distance with occasionally somewhat unreliable Internet connection, we decided to put some strict condition on whether we source control the assemblies or we deploy them on the build server and development machines.
Assemblies will be source controlled if all these criterias are met:
Assemblies/Framework is not deployable/redistribuable
Assemblies/Framework deployment may interfere with local machine services stability
Total amount of deployed assemblies on the project collection does not exceed 100MB
You could try using a different repository just for these assemblies, and do a checkout/update during the build job.
Also, if you want to keep it in the main repo as well, you could use svn:externals (http://svnbook.red-bean.com/en/1.0/ch07s03.html) to automatically update the DLLs when you update your working copy.