[jboss-jira] [JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
Ondrej Zizka (JIRA)
jira-events at lists.jboss.org
Mon Dec 2 05:15:07 EST 2013
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927768#comment-12927768 ]
Ondrej Zizka commented on WFLY-2426:
------------------------------------
I don't like the solution with file buried somewhere in the dir structure which is not even guaranteed to remain as is for future releases.
I've created the two PR's - 5551 and 5552, two impls of the same - adding version-base.txt.
Currently it uses ${project.version}. Is maitaining the version string manually necessary? IMO we should rely on the version from POM.
The name is version-base.properties.
1) it clearly declares the file format,
2) it declares that it's for the "base" layer.
Ad 2) - for other layers, another file would be added. This ensures that tools only looking for AS will find it, and it's version. Tools looking for all layers may simply check for version-*.properties, just like they would check for "modules/system/layers/" + layer + ...
> 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
> Assignee: Ondrej Zizka
>
> 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/LayeredDistributionsAndModulePathOrganization 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
More information about the jboss-jira
mailing list