[
https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin....
]
Rob Stryker commented on WFLY-2426:
-----------------------------------
This file is already scanned by our tools to get the information. There were previous bugs
in our implementation regarding our incorrect implementation of it (see JBIDE-14993, there
was a 2nd jira about it but i cant find it). We had previously been looking in
"modules/system/layers/" + layer + "/org/jboss/as/product/" + layer +
"/dir/META-INF"; but it seems we should have been looking in
"modules/system/layers/" + layer + "/org/jboss/as/product/" + slot +
"/dir/META-INF";
I don't think this file needs to be moved to root. It's useful where it is now,
since all finally agree on where this file should live. But I believe this needs to be
more official and perhaps have some type of unit test if it's at all possible to
ensure that every release has this file in the proper location. It's pretty official
now, and more people do depend on it, so it seems it's pretty stable at this point and
won't need to be moved up to root.
Easily accessible static information describing the release
-----------------------------------------------------------
Key: WFLY-2426
URL:
https://issues.jboss.org/browse/WFLY-2426
Project: WildFly
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Server
Reporter: Brian Stansberry
Tools that work with a WF installation need to identify what they are working with before
they can launch or interact with the server. Specifically, they need to know the version.
They likely need to know other information as well, such as the name of the software; e.g.
whether it is WildFly itself or some other project based on WildFly.
This information should be provided in standard format in a text file in a standard
location in the distribution (probably in bin). The text file should be generated as part
of the build.
The solution to this issue should consider the requirements of other
"identities" that may be based on WildFly. See [1] for the definition of an
identity.
The solution to this issue should consider the needs of products based on WildFly and
other non-product identities. For example, can the existing product.conf contain the
necessary information for a product, with some differently named but largely equivalent
file being used in a non-product distribution?
The solution to this issue should consider the implications for the patching tool.
[1]
https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira