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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > >

To what degree would this impact the web management interface? Regards, Heiko On Dec 30, 2011, at 6:33 AM, Jason T. Greene wrote: > 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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- Heiko Braun Senior Software Engineer JBoss by Red Hat http://about.me/hbraun