AS7-1807

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

AS7-1807

Paul Gier
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: AS7-1807

Carlo de Wolf
The only thing I don't like is the module name
'jboss-as-product-config', because it has no 1:1 relationship with a
'product'. It is more a 'distro' config, but I don't like that either.
How about 'jboss-as-version-config'?

For Fedora we would assume a different identity as well, unless we can
get the full AS functionality up and running. This I doubt, because
there are two requirements which contradict AS requirements:
- must use only latest version (so no Hibernate 3 for example)
- must use only FOSS (vs should use only FOSS)

Carlo

PS. Personally I think we should have the Hibernate 3 option in Fedora,
but that would entail a different packaging strategy.

On 12/13/2011 12:19 AM, 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: AS7-1807

Brian Stansberry
In reply to this post by Paul Gier
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: AS7-1807

jtgreene
Administrator
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
>> [hidden email]
>> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: AS7-1807

David Lloyd-2
The real question is, what combinations of products do we allow to be
installed in one repository?  And, what's the expected behavior in each
case?

On 12/13/2011 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>
>


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: AS7-1807

jtgreene
Administrator
In reply to this post by jtgreene
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
>>> [hidden email]
>>> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: AS7-1807

Heiko Braun


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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

--

Heiko Braun
Senior Software Engineer
JBoss by Red Hat






_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: AS7-1807

jtgreene
Administrator
There should be near zero impact. The intention is to support the
compile-per-product setup you currently have. The only additional setp
that is needed is to have a module descriptor with a different slot for
every different product (e.g. org.jboss.as.console:eap,
org.jboss.as.console:soa-p, etc vs :main), but that is just an EAP build
task.

The different slots allows for the same module repository to be shared
for multiple products, should we decide to do that in the future (less
disk space)

On 1/9/12 5:35 AM, Heiko Braun wrote:

>
>
> 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
>>>>> [hidden email]
>>>>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> --
>
> Heiko Braun
> Senior Software Engineer
> JBoss by Red Hat
> http://about.me/hbraun
>
>
>
>
>


--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev