Description of problem: When working with a project, users are forced to enter Group ID, Artifact ID, and Version ID in order for them to properly build. Through discussion in the usability sessions, it seems that these are maven IDs that are surfacing through the user interface. We should autogenerate defaults for these fields and hide them from most users unless someone is interested in manipulating them.
What do you propose they are automatically generated from? We could prompt the user for three pieces of information and use those; but how does that differ to prompting the user for Group, Artifact and Version? BTW there is a also another BZ to default the version to a value (e.g. 0.1.1). Maven projects are central to Drools 6.0.
I'm not sure what the group and artifact actually are to suggest how to generate them. Is this documented somewhere that I could read and then give some suggestions when I understand the values better?
Catherine, there is no way I can think of inferring this kind of information. It is completely up to the user to define these 3 pieces of information. I will close this ticket. If we misunderstood the request, please let us know and reopen this ticket.
Guys, Lets step back a little bit from engineering mindset. Lets put ourselves in users shoes. As a user all I care about is creating artifacts, saving them, simulation if needed, test if needed, package them and execute them. Yes, the engineering architecture of the product requires defining all those IDs. The question is do the end user really need to define it ? It would make sense if the end user likes to use his favourite name for the ID like "PrakashCreatedThisForXXXBankCustomer" and things like that. In the end from the project perspective it does not matter what that ID constitute of. It could be called .. "xxxyyyaaaeeeccc" or whatever. The enduser just does not care what that is called. So, would it not make sense to autogenerate some unique ID and assign it whenever a new project is created. And if you still think the user should have a way to modify the ID, give a provision in the project view for the user to go and change the ID to whatever they like to. We do not need to expose users to things that has no value for them. Just because the our technology architecture requires certain things we need to find way to make it transparent to users. Does it makes sense ? I understand it may be quite a bit of effort for 6.0, but lets think in this direction to make it better for post 6.0.
Prakash, lets make an analogy here: lets say my mother did not care about giving me a name, so I would remain nameless. How would you call me when you wanted to talk to me? Or if my mother just said to the clerk at the registration office: generate a unique name for my son, I don't care. How easy would it be for people to communicate with me if my name was a unique hash code like: First Name: 2736afb34ca878273fab Family Name: 82730abcf536209bcfa Prakash, maybe you want to call it something else, but "Artifact ID" is the first name of the project, and "Group ID" is the family name. You can create your processes and rules in the workbench, but for an application to actually execute them it needs to access those processes and rules by a first name+family name, and that is the "group id" and "artifact id". The version can have a default value, like 1.0.0, and there is another ticket for that, but I just don't see how generating hashcode for the project name will make things easier for the user than just ask him to provide a first name and last name for his own project. Even worse, once you have 5 projects, if their names are all non-readable hash codes, how can the user easily differentiate between them? The workbench is an authoring environment, but in order for an application or the execution server to consume those artifacts, there must be a name, hopefully a human readable name so that the user knows which one he wants to interact with.
Rather than trying to auto-generate this there should be a workflow for each analyst to request a project. In this we can place non-technical fields to describe the project request. Someone in operations or development then approves this and creates the technical project for them, which they can then open. In addition to the artefact id there is also a name and description element - that is mean to be human readable. We didn't expose those in the UI, but that would probably soften things a little, and we might be able to do those name. These would be necessary as part of the workflow above anyway. Typically business systems have a higher level, which we do not have, which is aimed purely at the knowledge acquisition and management stage. This is when a business analyst first thinks of a project, defines it and acquires the knowledge to be able to author it. This is all before anything executable is authored. These systems, via workflows, are typically integrated and linked into the platform that allows authoring of the executable aspects. We only have the executable authoring part. Examples of this include New Wisdom, Idiom, rules express: http://www.newwisdomsoftware.com http://www.idiomsoftware.com http://www.rulearts.com So please let's leave this for now, we can look at the requirements around business knowledge acquisition, and plan for this properly in the future.
For 6.0 I have created a more reasonable BZ, that looks to just improve what we have - by improving communication: https://bugzilla.redhat.com/show_bug.cgi?id=1017886
The related BZ Mark mentions has already been completed, some additional help has been provided. Please review the screenshots provided an reevaluate whether this BZ still makes sense. One small step forward that can be done without going into the autogeneration of IDs (which is not a good idea) is to provide more sensible defaults: - group Id could be very often the same for all projects. We can provide and optional system variable with the default value for this, therefore, users will be provided a default value set by IT or DevOps. - Version, it could be defaulted to 1.0.0 if empty.
This was discussed and is being handled by BZ-1169622 *** This bug has been marked as a duplicate of bug 1169622 ***