[jboss-as7-dev] AS7-1807
Jason T. Greene
jason.greene at redhat.com
Fri Dec 30 00:33:54 EST 2011
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.zip
On 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 at 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
More information about the jboss-as7-dev
mailing list