Skip to Main Content
Integration


This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.


Status Future consideration
Workspace App Connect
Created by Guest
Created on Sep 11, 2024

Enhance and harmonize the Java development experience/process for message flows

#1 Our situation:

We are using Java ComputeNodes and thus Java to develop parts of our message flows. 
In this context we have the requirement to 
-    manage additional third party libraries 
-    manage additional resourcew within the Java projects (e.g. template files)

Today from our perspective the only way to achieve this is to 
-    use maven – for the dependency management of the third party libs and 
-    mqsicreatebar – to create the bar file

As mqsicreatebar is using Eclipse it will also take care about the maven dependencies if the right builders are set in the .project file. 
So far so good.

However: on our build pipelines we want and we need to avoid mqsicreatebar. 
Reason: it’s quite slow (because of the headless eclipse) and it’s more complex reg. the setup. 
Further we can not use mqsicreatebar at all – as we are not allowed to install additional tooling like xvfb on our build server 
Instead: we would like to use light weight tooling like ibmint (which is by the way promoted as new strategic CLI tool) 
However here we see two things: 
1) ibmint does not support Maven at all 
2.) ibmint does not provide any resource packaging for Java project.

#2 Our request / Idea: 
Well the maven support is of course “special” –  but at least it would be great if all ibm build/packaging tooling would behave the same way about additional resource files. 
Further: 
- what would be your recommend end-to-end development process for message flows including Java projects? Is there anything we have overseen?
 

Looking forward to your feedback. Thanks.
 

Idea priority High
  • Admin
    Ben Thompson
    Reply
    |
    Nov 28, 2024

    Thank you for taking the time to raise this request. We note the similarity of this suggestion to APPC-I-921 (https://integration-development.ideas.ibm.com/ideas/APPC-I-921) which was raised back in May of this year. Our decision at that time was to not take forward the suggestion in APPC-I-921 which was closed with the following commentary:


    Idea Review. Thank you for taking the time to raise this enhancement idea. Under the covers, the implementation of the mqsicreatebar command is utilizing eclipse running in headless mode. This brings with mqsicreatebar a requirement to have Toolkit / Eclipse installed where the build script is executing, and so avoiding this pre-requisite was one of the main reasons for investing in other packaging options (mqsipackagebar and ibmint) which do not need Eclipse. The requirement mentions that when Maven invokes mqsicreatebar the builders and natures result in the Java dependencies being dragged into the jar / bar. 

    We strongly suspect that this only works due to inheriting eclipse capabilities for grabbing the resources and building them in to the jar / bar. In order to get this same behaviour from ibmint, we would need to build capability into ibmint which has knowledge of eclipse builders and natures or alternatively options for Java building. It seems more maintainable for this to be done directly from your build tool or via your build tool calling into Maven to do this, rather than to do this indirectly through ibmint. Given this, on this occasion we will not be taking this suggestion forward right now.


    So … we don't think you have "missed" anything on this topic - you're quite correct in asserting that given that mqsicreatebar runs eclipse in headless mode, it is not for everyone and for this reason we were keen for the ibmint command option to not carry that prerequisite... as a result we would be disinclined to build capability into ibmint which would require eclipse builders. We absolutely stand by this aspect of the reply on the prior suggestion. The question then becomes whether ibmint should be enhanced to integrate directly with Maven and whether this brings any advantage over and above using Maven to do the java build directly in your build script environment. This is a more debatable aspect to the suggestion … in general we're keen to keep ACE build tools as close as we can to the ACE aspects, and leave java build tools to deal with java building … but given your tenacity in raising this again, we don't want to prematurely kill debate on this topic ... as usual we're always keen to hear from users and humble enough to acknowledge it in cases where our community disagrees ;o) … So in that spirit we'll place this suggestion into Future Consideration status for a while, and whilst not a high immediate business priority for us, we'll watch with interest for further community feedback and see where this leads.