On 7/25/14, 12:09 PM, James R. Perkins wrote:
On 07/24/2014 06:24 PM, Brian Stansberry wrote:
> On 7/24/14, 6:54 PM, James R. Perkins wrote:
>>
>> On 07/24/2014 03:15 PM, Brian Stansberry wrote:
>>> On 7/24/14, 5:03 PM, Frank Langelage wrote:
>>>> When using current WildFly build from sources I see this message after
>>>> startup is complete:
>>>> 24.07. 21:12:26,131 INFO [org.jboss.as#done] WFLYSRV0025: WildFly
>>>> 1.0.0.Alpha3 "Kenny" started in 28469ms - Started 374 of 500
services
>>>> (179 services are lazy, passive or on-demand)
>>>>
>>>> Two things I suppose to be changed:
>>>> 1. version is now the version of the underlying core, but version
>>>> of the
>>>> server should also be shown, or not? May be something like "WildFly
>>>> 9.0.0-Alpha-SNAPSHOT based on WildFly Core 1.0.0.Alpha3" ?
>>> IMHO it should just be the version of the full dist, with the core
>>> version only shown if whatever mechanism we add for letting a
>>> dist-based
>>> on core control this isn't implemented by a particular dist.
>> Probably not ideal, but something like this almost kind of works
>>
https://github.com/jamezp/wildfly/compare/name-test.
>
> Yeah, IIRC (which is chancy) in an IRC chat a few weeks back something
> like that looked like the likely solution. Some things to think about:
>
> 1) This is the EAP mechanism, so we'll need to think about how it will
> relate to EAP once that becomes relevant (i.e. don't steal its thing
> and then get stuck when it wants it back.) I think that's mostly just
> thinking about the log message we'll want to write adn ensuring
> ProductConfig can support that with the needed data.
Agreed.
>
> 2) product.conf as a file name kind of sucks for something that isn't
> a product
Again agreed.
EAP will probably want to keep it though, so perhaps ProductConfig can
check for 2 things, giving precedence to product.conf.
>
> 3) How this relates to the process of building a server when each of
> the pieces that make up that server (e.g. web-build) try to write that
> file, unless it's just trivial to have the final build win.
Maybe it's something we can enhance the build plugin to do now. Seems
there should be a reasonable solution. Maybe a simple properties file
lookup or something like that. Anyway I don't want to jump in the middle
if someone is already looking at it.
I doubt anyone is looking into this; IIRC it was just something that was
chatted about a bit. Ping Stuart if no one responds; if anyone is doing
anything it's likely him.
It's possible the provisioning stuff already handles all this just fine;
I am far from an expert on the current status.
>
>> We could clean the
>> Version API up though and probably do it a little different.
>>>
>>> Right now I assume we have no mechanism to let dists based on the core
>>> control this.
>>>
>>>> 2. the nickname "Kenny" already was used for WildFly 8.x. Time
to
>>>> create
>>>> a new one for 9.0.x, or?
>>> Please, let's drop code names!!! It's just another thing to screw
up.
>> +1
>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>
>
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat