12:34 p.m.
Hello All,
I've had a few issues file recently against the wildfly-maven-plugin
about CLI commands that aren't available to the plugin. The issue is I'm
using the CLI API to take commands and create DMR operations out of
them. Since the commands can be defined in the subsystems I don't see
those commands as I'm not operating in a modular environment.
This led me to create a new API in for the Launcher API [1]. All this
does is build a command to launch a new CLI process. I'm sure if it
would be useful to others or not. If not maybe it doesn't belong in the
launcher API and I should just keep it in the maven plugin.
Any opinions are welcome. Let me know if you'd find this useful.
[1]: https://github.com/wildfly/wildfly-core/pull/764
--
James R. Perkins
JBoss by Red Hat
2:57 p.m.
The biggest thing is whether Alexey and Joe are comfortable to commiting
to what you've done as a long term API.
On 6/9/15 12:34 PM, James R. Perkins wrote:
Hello All,
I've had a few issues file recently against the wildfly-maven-plugin
about CLI commands that aren't available to the plugin. The issue is I'm
using the CLI API to take commands and create DMR operations out of
them. Since the commands can be defined in the subsystems I don't see
those commands as I'm not operating in a modular environment.
This led me to create a new API in for the Launcher API [1]. All this
does is build a command to launch a new CLI process. I'm sure if it
would be useful to others or not. If not maybe it doesn't belong in the
launcher API and I should just keep it in the maven plugin.
Any opinions are welcome. Let me know if you'd find this useful.
[1]: https://github.com/wildfly/wildfly-core/pull/764
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
3:17 p.m.
I don't mind maintaining it, but yeah their input would be helpful.
Though if I'm the only one that would use it then maybe it just doesn't
belong in WildFly at all :)
On 06/09/2015 12:57 PM, Brian Stansberry wrote:
The biggest thing is whether Alexey and Joe are comfortable to
commiting
to what you've done as a long term API.
On 6/9/15 12:34 PM, James R. Perkins wrote:
> Hello All,
> I've had a few issues file recently against the wildfly-maven-plugin
> about CLI commands that aren't available to the plugin. The issue is I'm
> using the CLI API to take commands and create DMR operations out of
> them. Since the commands can be defined in the subsystems I don't see
> those commands as I'm not operating in a modular environment.
>
> This led me to create a new API in for the Launcher API [1]. All this
> does is build a command to launch a new CLI process. I'm sure if it
> would be useful to others or not. If not maybe it doesn't belong in the
> launcher API and I should just keep it in the maven plugin.
>
> Any opinions are welcome. Let me know if you'd find this useful.
>
> [1]: https://github.com/wildfly/wildfly-core/pull/764
>
--
James R. Perkins
JBoss by Red Hat
6:01 a.m.
I was actually about to create a much more basic process builder to restructure the CLI
tests a bit.
In a general sense I think I'm comfortable maintaining an API like this. If it's
not maintained here, something similar, but more basic, should already be getting
maintained in the testsuite anyway. Otherwise we're missing test coverage. So I
don't see much additional work involved. It's just a matter of remembering where
to do it. Not whether it would be getting done.
Unless there's some other impact I'm not seeing?
-- Joe
----- Original Message -----
From: "James R. Perkins" <jperkins(a)redhat.com>
To: wildfly-dev(a)lists.jboss.org
Sent: Wednesday, June 10, 2015 4:17:53 AM
Subject: Re: [wildfly-dev] CLI Command Builder
I don't mind maintaining it, but yeah their input would be helpful.
Though if I'm the only one that would use it then maybe it just
doesn't
belong in WildFly at all :)
On 06/09/2015 12:57 PM, Brian Stansberry wrote:
> The biggest thing is whether Alexey and Joe are comfortable to
> commiting
> to what you've done as a long term API.
>
> On 6/9/15 12:34 PM, James R. Perkins wrote:
>> Hello All,
>> I've had a few issues file recently against the
>> wildfly-maven-plugin
>> about CLI commands that aren't available to the plugin. The issue
>> is I'm
>> using the CLI API to take commands and create DMR operations out
>> of
>> them. Since the commands can be defined in the subsystems I don't
>> see
>> those commands as I'm not operating in a modular environment.
>>
>> This led me to create a new API in for the Launcher API [1]. All
>> this
>> does is build a command to launch a new CLI process. I'm sure if
>> it
>> would be useful to others or not. If not maybe it doesn't belong
>> in the
>> launcher API and I should just keep it in the maven plugin.
>>
>> Any opinions are welcome. Let me know if you'd find this useful.
>>
>> [1]: https://github.com/wildfly/wildfly-core/pull/764
>>
>
--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
7:07 a.m.
I agree with Joe. Thanks James for looking into this.
Alexey
On 06/10/2015 01:01 PM, Edward Wertz wrote:
I was actually about to create a much more basic process builder to
restructure the CLI tests a bit.
In a general sense I think I'm comfortable maintaining an API like this. If it's
not maintained here, something similar, but more basic, should already be getting
maintained in the testsuite anyway. Otherwise we're missing test coverage. So I
don't see much additional work involved. It's just a matter of remembering where
to do it. Not whether it would be getting done.
Unless there's some other impact I'm not seeing?
-- Joe
----- Original Message -----
> From: "James R. Perkins" <jperkins(a)redhat.com>
> To: wildfly-dev(a)lists.jboss.org
> Sent: Wednesday, June 10, 2015 4:17:53 AM
> Subject: Re: [wildfly-dev] CLI Command Builder
>
> I don't mind maintaining it, but yeah their input would be helpful.
> Though if I'm the only one that would use it then maybe it just
> doesn't
> belong in WildFly at all :)
>
> On 06/09/2015 12:57 PM, Brian Stansberry wrote:
>> The biggest thing is whether Alexey and Joe are comfortable to
>> commiting
>> to what you've done as a long term API.
>>
>> On 6/9/15 12:34 PM, James R. Perkins wrote:
>>> Hello All,
>>> I've had a few issues file recently against the
>>> wildfly-maven-plugin
>>> about CLI commands that aren't available to the plugin. The issue
>>> is I'm
>>> using the CLI API to take commands and create DMR operations out
>>> of
>>> them. Since the commands can be defined in the subsystems I don't
>>> see
>>> those commands as I'm not operating in a modular environment.
>>>
>>> This led me to create a new API in for the Launcher API [1]. All
>>> this
>>> does is build a command to launch a new CLI process. I'm sure if
>>> it
>>> would be useful to others or not. If not maybe it doesn't belong
>>> in the
>>> launcher API and I should just keep it in the maven plugin.
>>>
>>> Any opinions are welcome. Let me know if you'd find this useful.
>>>
>>> [1]: https://github.com/wildfly/wildfly-core/pull/764
>>>
>>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:27 a.m.
I think it has potential and is interesting.
The big problem I keep having with these are that unless I'm missing
something
I can't use one version of this library to control multiple versions of
WildFly/EAP
- I must still have the matching jar to the exact runtime version,
correct ?
meaning using it from tools that need to support multiple versions
without
wanting to ask the user to choose a specific jar this is of limited use
outside
something like maven plugins :/
/max
Hello All,
I've had a few issues file recently against the wildfly-maven-plugin
about CLI commands that aren't available to the plugin. The issue is
I'm
using the CLI API to take commands and create DMR operations out of
them. Since the commands can be defined in the subsystems I don't see
those commands as I'm not operating in a modular environment.
This led me to create a new API in for the Launcher API [1]. All this
does is build a command to launch a new CLI process. I'm sure if it
would be useful to others or not. If not maybe it doesn't belong in
the
launcher API and I should just keep it in the maven plugin.
Any opinions are welcome. Let me know if you'd find this useful.
[1]: https://github.com/wildfly/wildfly-core/pull/764
--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
/max
http://about.me/maxandersen
2:32 a.m.
Won't you miss some command handlers that can be loaded through the subsystems
themselves ?
Emmanuel
Le 10/06/2015 09:27, Max Rydahl Andersen a écrit :
I think it has potential and is interesting.
The big problem I keep having with these are that unless I'm missing
something
I can't use one version of this library to control multiple versions of
WildFly/EAP
- I must still have the matching jar to the exact runtime version,
correct ?
meaning using it from tools that need to support multiple versions
without
wanting to ask the user to choose a specific jar this is of limited use
outside
something like maven plugins :/
/max
> Hello All,
> I've had a few issues file recently against the wildfly-maven-plugin
> about CLI commands that aren't available to the plugin. The issue is
> I'm
> using the CLI API to take commands and create DMR operations out of
> them. Since the commands can be defined in the subsystems I don't see
> those commands as I'm not operating in a modular environment.
>
> This led me to create a new API in for the Launcher API [1]. All this
> does is build a command to launch a new CLI process. I'm sure if it
> would be useful to others or not. If not maybe it doesn't belong in
> the
> launcher API and I should just keep it in the maven plugin.
>
> Any opinions are welcome. Let me know if you'd find this useful.
>
> [1]: https://github.com/wildfly/wildfly-core/pull/764
>
> --
> James R. Perkins
> JBoss by Red Hat
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
/max
http://about.me/maxandersen
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:40 a.m.
That's the reason I created this was so the wildfly-maven-plugin could
use jboss-modules to launch CLI and execute commands which means it
should discover them. At least that's how I thought it worked.
On 06/10/2015 12:32 AM, Emmanuel Hugonnet wrote:
Won't you miss some command handlers that can be loaded through
the subsystems themselves ?
Emmanuel
Le 10/06/2015 09:27, Max Rydahl Andersen a écrit :
> I think it has potential and is interesting.
>
> The big problem I keep having with these are that unless I'm missing
> something
> I can't use one version of this library to control multiple versions of
> WildFly/EAP
> - I must still have the matching jar to the exact runtime version,
> correct ?
>
> meaning using it from tools that need to support multiple versions
> without
> wanting to ask the user to choose a specific jar this is of limited use
> outside
> something like maven plugins :/
>
> /max
>
>
>> Hello All,
>> I've had a few issues file recently against the wildfly-maven-plugin
>> about CLI commands that aren't available to the plugin. The issue is
>> I'm
>> using the CLI API to take commands and create DMR operations out of
>> them. Since the commands can be defined in the subsystems I don't see
>> those commands as I'm not operating in a modular environment.
>>
>> This led me to create a new API in for the Launcher API [1]. All this
>> does is build a command to launch a new CLI process. I'm sure if it
>> would be useful to others or not. If not maybe it doesn't belong in
>> the
>> launcher API and I should just keep it in the maven plugin.
>>
>> Any opinions are welcome. Let me know if you'd find this useful.
>>
>> [1]: https://github.com/wildfly/wildfly-core/pull/764
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
James R. Perkins
JBoss by Red Hat
10:37 a.m.
I don't see why it wouldn't work with all versions. All it really does
is create command strings to be passed to a ProcessBuilder. Since it's
new in WildFly it will default to WildFly settings, but you should be
able to override them. In most cases, maybe all, no parameters entry
parameters have changed.
If the tooling can have a hard dependency on something like
org.wildfly.core:wildfly-launcher I don't see why it wouldn't work with
any version. Let me know if I'm missing something though.
Last time I tested the wildfly-maven-plugin will work with EAP, it's
just not it's target so the defaults don't match for connecting the
controller. The only thing you'd have to do is override the port to 9999.
On 06/10/2015 12:27 AM, Max Rydahl Andersen wrote:
I think it has potential and is interesting.
The big problem I keep having with these are that unless I'm missing
something
I can't use one version of this library to control multiple versions
of WildFly/EAP
- I must still have the matching jar to the exact runtime version,
correct ?
meaning using it from tools that need to support multiple versions
without
wanting to ask the user to choose a specific jar this is of limited
use outside
something like maven plugins :/
/max
> Hello All,
> I've had a few issues file recently against the wildfly-maven-plugin
> about CLI commands that aren't available to the plugin. The issue is I'm
> using the CLI API to take commands and create DMR operations out of
> them. Since the commands can be defined in the subsystems I don't see
> those commands as I'm not operating in a modular environment.
>
> This led me to create a new API in for the Launcher API [1]. All this
> does is build a command to launch a new CLI process. I'm sure if it
> would be useful to others or not. If not maybe it doesn't belong in the
> launcher API and I should just keep it in the maven plugin.
>
> Any opinions are welcome. Let me know if you'd find this useful.
>
> [1]: https://github.com/wildfly/wildfly-core/pull/764
>
> --
> James R. Perkins
> JBoss by Red Hat
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
/max
http://about.me/maxandersen
--
James R. Perkins
JBoss by Red Hat
10:44 a.m.
New subject: Launching multiple versions from the launcher jar
I changed the title as this is a different topic.
It's a good point, Max. It seems like it should be possible to have some
sort of factory API to specify the version of the process being launched.
Apologies in advance, James, if that's already there.
There are funny details to consider, e.g. how to specify the version,
since now it's really WildFly Core versions that are relevant, while
previous releases are AS or EAP or WildFly full.
My guess is what's there now will work for any release we've had since
AS 7.0. We haven't been changing our launch commands. Of course there
may be some new args introduced over time that won't work on old
releases, but that's to be expected.
On 6/10/15 2:27 AM, Max Rydahl Andersen wrote:
I think it has potential and is interesting.
The big problem I keep having with these are that unless I'm missing
something
I can't use one version of this library to control multiple versions of
WildFly/EAP
- I must still have the matching jar to the exact runtime version,
correct ?
meaning using it from tools that need to support multiple versions
without
wanting to ask the user to choose a specific jar this is of limited use
outside
something like maven plugins :/
/max
> Hello All,
> I've had a few issues file recently against the wildfly-maven-plugin
> about CLI commands that aren't available to the plugin. The issue is
> I'm
> using the CLI API to take commands and create DMR operations out of
> them. Since the commands can be defined in the subsystems I don't see
> those commands as I'm not operating in a modular environment.
>
> This led me to create a new API in for the Launcher API [1]. All this
> does is build a command to launch a new CLI process. I'm sure if it
> would be useful to others or not. If not maybe it doesn't belong in
> the
> launcher API and I should just keep it in the maven plugin.
>
> Any opinions are welcome. Let me know if you'd find this useful.
>
> [1]: https://github.com/wildfly/wildfly-core/pull/764
>
> --
> James R. Perkins
> JBoss by Red Hat
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
/max
http://about.me/maxandersen
_______________________________________________
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
3452
days inactive
3453
days old
9 comments
6 participants
participants (6)
-
Alexey Loubyansky -
Brian Stansberry -
Edward Wertz -
Emmanuel Hugonnet -
James R. Perkins -
Max Rydahl Andersen