Enterpriser Server Jar Naming - Fix

Stefan Negrea snegrea at redhat.com
Tue Jul 23 19:50:01 UTC 2013



----- Original Message -----
> From: "Larry O'Leary" <loleary at redhat.com>
> > 
> > 2) Leave the server jar module name as is rhq-enterprise-server
> >   - two clear yes votes (Jay and John Sanda)
> >   - one clear no vote (Heiko) - the concern here is the length of the name
> >   
> > * This is only proposal I am still unclear if we reached consensus. On one
> > hand keeping this artifact name avoids confusion and make clear the
> > purpose of the module. But there were some concerns about the length of
> > the name even if the old post fix "-ejb3" will be dropped. So I am unclear
> > if there is another naming proposal and how to proceed.  Please refer to
> > my initial email for my arguments to keep the current artifact name.
> 
> -1
> 
> I just don't like the word enterprise in anything. Many of the customers
> I have worked with in the past would actually use this as criteria to
> NOT select a product. The idea is that if you see enterprise in the
> name, it means that you get inferior quality but its okay because the
> "enterprise" is supposed to make you feel like its the best. Granted,
> that isn't a great argument.
> 
> However, the name length is a very big issue. At the moment, users are
> forced to break their business rules as they pertain to installation and
> server placement within their file system. Simply putting RHQ in C:
> \Program Files (x86)\jboss\rhq\ results in a failure for RHQ 4.5 (can't
> speak for 4.8).
> 
> Dropping "enterprise" from the name might get one closer. Or how about
> not exploding archive files? Why is this done anyway? Shouldn't the
> rhq-server.jar be a JAR? Why is it exploded?
> 

rhq-server for the artifact name is going to be confusing since we package the app with that name. If rhq-enterprise-server is too long what could we replace enterprise with??  rhq-ent-server? rhq-??????-server?


Also, if we do change the name of the artifact we will break the artifact history. Would that be a problem for any external users that extend the core platform?


> > 
> > 3) Use the artifact names unchanged as the deployment names in the ear, dev
> > container, and any other place.
> >   - two clear yes votes (Jay and John Sanda)
> 
> -1
> 
> I suppose I don't have a strong preference here but it is annoying to
> see rhq/*rhq*/*rhq*/*rhq*. I KNOW ALREADY! :)  Just because Maven
> identifies the file using the artifact name and the version doesn't mean
> the distribution should. The same can be said for version numbers
> (actually those are even worse from the RHQ management/provisioning
> perspective).
> 
> 

All what this proposal does is to reduce the number of moving parts during packaging. If we deploy and expand jars under different names, it could be harder to debug packaging problems and user errors. So this is just to align internal module names with deployment structure. To fix the repetitive *rhq* we should look at flattening the structure rather than changing artifact names.

> 
> --
> Larry O'Leary
> https://plus.google.com/u/0/112645929986009801513
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list