I have committed a slightly different solution that is triggered by
creating an optional product.conf in the bin directory. This file
specifies the "slot" to load for the product definition module
(org.jboss.as.product). This module includes a MANIFEST.MF which defines
a product name, a product version, and also the slot to use for the
console. These values are used to compute startup log messages and are
also present as root attributes in the management model. The use of the
indirection file avoids forcing IDEs or other launchers to know the
product to pass as a parameter, and it also allows for multiple
different product definitions modules.
If there is no product.conf, standard community behavior is exhibited.
I compiled a mock EAP 6.0 example using the EAP L&F build of the console:
Just extract the following in jboss.home:
http://dl.dropbox.com/u/712508/prod-example.zipOn 12/13/11 10:06 AM, Jason T. Greene wrote:
I think we are intermixing maven modules and jboss modules here. I think
it's very desirable that we have a *different* jboss module per product
so that there is no delta required between the AS7 core platform build
and the product. However we still need that common name, so a jboss
module alias works well.
The code inside of AS somewhere does
moduleLoader.findModule("org.jboss.as.product") or whatever, and we just
have one tiny module.xml that aggregates the community product module.
None of this though needs a maven module, it can all just be built from
build. The product process simply has to replace that one "alias"
module.xml.
On 12/13/11 9:59 AM, Brian Stansberry wrote:
I have a feeling this isn't really answering your question, but here goes...
I vaguely envisioned this as being based on a ServiceLoader. So we would
define an interface. In an artifact that will pretty much never change.
So products can depend on version 1.0 of that interface pretty much
forever. Different products would have a module that implements that
interface and exposes its impl via ServiceLoader. The build would deal
with deal with getting the correct module in place.
Since the interface can pretty much never change, it should be real
generic. Probably just provides a properties map.
Map<String, String> getProductConfigurationSettings()
On 12/12/11 5:19 PM, Paul Gier wrote:
I started working on a way to modularize the product name and version in
the startup/shutdown logs of AS7 [1][2]. There is a new module called
"product" which contains the product name and version. However this
approach doesn't seem good to me because the "host-controller",
"process-controller", and "server" modules all now have dependencies on
this new module.
Ideally, I want to set this up so that there is sort of a placeholder
product name/version used during the build or these modules, but then
this can be overridden by the product module later in the build. Anyone
have suggestions about how to do this?
Thanks!
[1]https://github.com/pgier/jboss-as/commits/AS7-1807
[2]https://issues.jboss.org/browse/AS7-1807
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev