3:53 p.m.
I propose we revert the component-matrix change. This change is
ostensibly to help in the creation of a BOM for the client libraries
and other dependent projects; however, the cost has turned out to be
somewhat higher than expected.
IntelliJ seems to be unable to cope with dependency changes in the
project due to the use of import from the root POM. This means that
the entire project must be force-reimported from time to time to keep
dependencies up to date, and forgetting to do so can lead to
development issues and lost time.
Also, I've observed that Maven itself does not always correctly
resolve versions anymore, when you're building from a submodule. I
don't really know why this is the case but I suspect that it's due to
some algorithmic ambiguity when the dependency tree is not linear like
it used to be.
I think that if we need to generate some BOM for use by external
projects, it should be done as a separate step and artifact which
acquires versions from the parent. I believe we had it this way at
one point, didn't we?
Anyway I think this change didn't work out, and we should undo it
while it's still remotely possible. WDYT?
--
- DML
4:04 p.m.
I agree. We can break the bom cycle a different way.
On May 4, 2018, at 3:53 PM, David Lloyd
<david.lloyd(a)redhat.com> wrote:
I propose we revert the component-matrix change. This change is
ostensibly to help in the creation of a BOM for the client libraries
and other dependent projects; however, the cost has turned out to be
somewhat higher than expected.
IntelliJ seems to be unable to cope with dependency changes in the
project due to the use of import from the root POM. This means that
the entire project must be force-reimported from time to time to keep
dependencies up to date, and forgetting to do so can lead to
development issues and lost time.
Also, I've observed that Maven itself does not always correctly
resolve versions anymore, when you're building from a submodule. I
don't really know why this is the case but I suspect that it's due to
some algorithmic ambiguity when the dependency tree is not linear like
it used to be.
I think that if we need to generate some BOM for use by external
projects, it should be done as a separate step and artifact which
acquires versions from the parent. I believe we had it this way at
one point, didn't we?
Anyway I think this change didn't work out, and we should undo it
while it's still remotely possible. WDYT?
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:11 p.m.
I've created https://issues.jboss.org/browse/WFLY-10330 and
https://issues.jboss.org/browse/WFCORE-3803 to track this.
On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
I agree. We can break the bom cycle a different way.
> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd(a)redhat.com> wrote:
>
> I propose we revert the component-matrix change. This change is
> ostensibly to help in the creation of a BOM for the client libraries
> and other dependent projects; however, the cost has turned out to be
> somewhat higher than expected.
>
> IntelliJ seems to be unable to cope with dependency changes in the
> project due to the use of import from the root POM. This means that
> the entire project must be force-reimported from time to time to keep
> dependencies up to date, and forgetting to do so can lead to
> development issues and lost time.
>
> Also, I've observed that Maven itself does not always correctly
> resolve versions anymore, when you're building from a submodule. I
> don't really know why this is the case but I suspect that it's due to
> some algorithmic ambiguity when the dependency tree is not linear like
> it used to be.
>
> I think that if we need to generate some BOM for use by external
> projects, it should be done as a separate step and artifact which
> acquires versions from the parent. I believe we had it this way at
> one point, didn't we?
>
> Anyway I think this change didn't work out, and we should undo it
> while it's still remotely possible. WDYT?
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML
4:25 a.m.
Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used? I've not played
with it
On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com>
wrote:
I've created https://issues.jboss.org/browse/WFLY-10330 and
https://issues.jboss.org/browse/WFCORE-3803 to track this.
On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
> I agree. We can break the bom cycle a different way.
>
>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd(a)redhat.com> wrote:
>>
>> I propose we revert the component-matrix change. This change is
>> ostensibly to help in the creation of a BOM for the client libraries
>> and other dependent projects; however, the cost has turned out to be
>> somewhat higher than expected.
>>
>> IntelliJ seems to be unable to cope with dependency changes in the
>> project due to the use of import from the root POM. This means that
>> the entire project must be force-reimported from time to time to keep
>> dependencies up to date, and forgetting to do so can lead to
>> development issues and lost time.
>>
>> Also, I've observed that Maven itself does not always correctly
>> resolve versions anymore, when you're building from a submodule. I
>> don't really know why this is the case but I suspect that it's due to
>> some algorithmic ambiguity when the dependency tree is not linear like
>> it used to be.
>>
>> I think that if we need to generate some BOM for use by external
>> projects, it should be done as a separate step and artifact which
>> acquires versions from the parent. I believe we had it this way at
>> one point, didn't we?
>>
>> Anyway I think this change didn't work out, and we should undo it
>> while it's still remotely possible. WDYT?
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:06 a.m.
Tomaz mentioned Quickstarts as one of the reasons to have BOMs in WF and
WF-CORE.
Eduardo should confirm that revert is fine for QS.
Rostislav
On Sat, May 5, 2018 at 11:25 AM, Kabir Khan <kkhan(a)redhat.com> wrote:
Perhaps https://github.com/jboss/bom-builder-maven-plugin can be
used?
I've not played with it
> On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com> wrote:
>
> I've created https://issues.jboss.org/browse/WFLY-10330 and
> https://issues.jboss.org/browse/WFCORE-3803 to track this.
>
> On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene(a)redhat.com>
wrote:
>> I agree. We can break the bom cycle a different way.
>>
>>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd(a)redhat.com>
wrote:
>>>
>>> I propose we revert the component-matrix change. This change is
>>> ostensibly to help in the creation of a BOM for the client libraries
>>> and other dependent projects; however, the cost has turned out to be
>>> somewhat higher than expected.
>>>
>>> IntelliJ seems to be unable to cope with dependency changes in the
>>> project due to the use of import from the root POM. This means that
>>> the entire project must be force-reimported from time to time to keep
>>> dependencies up to date, and forgetting to do so can lead to
>>> development issues and lost time.
>>>
>>> Also, I've observed that Maven itself does not always correctly
>>> resolve versions anymore, when you're building from a submodule. I
>>> don't really know why this is the case but I suspect that it's due
to
>>> some algorithmic ambiguity when the dependency tree is not linear like
>>> it used to be.
>>>
>>> I think that if we need to generate some BOM for use by external
>>> projects, it should be done as a separate step and artifact which
>>> acquires versions from the parent. I believe we had it this way at
>>> one point, didn't we?
>>>
>>> Anyway I think this change didn't work out, and we should undo it
>>> while it's still remotely possible. WDYT?
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> - DML
> _______________________________________________
> 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
10:08 a.m.
We can still create BOMs in WF and WFCORE. We would just have to do
so using a plugin or something similar.
On Tue, May 8, 2018 at 10:06 AM, Rostislav Svoboda <rsvoboda(a)redhat.com> wrote:
Tomaz mentioned Quickstarts as one of the reasons to have BOMs in WF
and
WF-CORE.
Eduardo should confirm that revert is fine for QS.
Rostislav
On Sat, May 5, 2018 at 11:25 AM, Kabir Khan <kkhan(a)redhat.com> wrote:
>
> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used?
> I've not played with it
>
> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com> wrote:
> >
> > I've created https://issues.jboss.org/browse/WFLY-10330 and
> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
> >
> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene(a)redhat.com>
> > wrote:
> >> I agree. We can break the bom cycle a different way.
> >>
> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd(a)redhat.com>
> >>> wrote:
> >>>
> >>> I propose we revert the component-matrix change. This change is
> >>> ostensibly to help in the creation of a BOM for the client libraries
> >>> and other dependent projects; however, the cost has turned out to be
> >>> somewhat higher than expected.
> >>>
> >>> IntelliJ seems to be unable to cope with dependency changes in the
> >>> project due to the use of import from the root POM. This means that
> >>> the entire project must be force-reimported from time to time to keep
> >>> dependencies up to date, and forgetting to do so can lead to
> >>> development issues and lost time.
> >>>
> >>> Also, I've observed that Maven itself does not always correctly
> >>> resolve versions anymore, when you're building from a submodule. I
> >>> don't really know why this is the case but I suspect that it's
due to
> >>> some algorithmic ambiguity when the dependency tree is not linear like
> >>> it used to be.
> >>>
> >>> I think that if we need to generate some BOM for use by external
> >>> projects, it should be done as a separate step and artifact which
> >>> acquires versions from the parent. I believe we had it this way at
> >>> one point, didn't we?
> >>>
> >>> Anyway I think this change didn't work out, and we should undo it
> >>> while it's still remotely possible. WDYT?
> >>>
> >>> --
> >>> - DML
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> >
> > --
> > - DML
> > _______________________________________________
> > 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
--
- DML
10:12 a.m.
We also revert back to what we had before in QS, and work out a better solution from
there.
—E
On 08 May 2018, at 16:06, Rostislav Svoboda
<rsvoboda(a)redhat.com> wrote:
Tomaz mentioned Quickstarts as one of the reasons to have BOMs in WF and WF-CORE.
Eduardo should confirm that revert is fine for QS.
Rostislav
On Sat, May 5, 2018 at 11:25 AM, Kabir Khan <kkhan(a)redhat.com
<mailto:kkhan@redhat.com>> wrote:
Perhaps https://github.com/jboss/bom-builder-maven-plugin
<https://github.com/jboss/bom-builder-maven-plugin> can be used? I've not played
with it
> On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com
<mailto:david.lloyd@redhat.com>> wrote:
>
> I've created https://issues.jboss.org/browse/WFLY-10330
<https://issues.jboss.org/browse/WFLY-10330> and
> https://issues.jboss.org/browse/WFCORE-3803
<https://issues.jboss.org/browse/WFCORE-3803> to track this.
>
> On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene(a)redhat.com
<mailto:jason.greene@redhat.com>> wrote:
>> I agree. We can break the bom cycle a different way.
>>
>>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd(a)redhat.com
<mailto:david.lloyd@redhat.com>> wrote:
>>>
>>> I propose we revert the component-matrix change. This change is
>>> ostensibly to help in the creation of a BOM for the client libraries
>>> and other dependent projects; however, the cost has turned out to be
>>> somewhat higher than expected.
>>>
>>> IntelliJ seems to be unable to cope with dependency changes in the
>>> project due to the use of import from the root POM. This means that
>>> the entire project must be force-reimported from time to time to keep
>>> dependencies up to date, and forgetting to do so can lead to
>>> development issues and lost time.
>>>
>>> Also, I've observed that Maven itself does not always correctly
>>> resolve versions anymore, when you're building from a submodule. I
>>> don't really know why this is the case but I suspect that it's due
to
>>> some algorithmic ambiguity when the dependency tree is not linear like
>>> it used to be.
>>>
>>> I think that if we need to generate some BOM for use by external
>>> projects, it should be done as a separate step and artifact which
>>> acquires versions from the parent. I believe we had it this way at
>>> one point, didn't we?
>>>
>>> Anyway I think this change didn't work out, and we should undo it
>>> while it's still remotely possible. WDYT?
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
7:11 a.m.
It turns out that the component-matrix was never added to Quickstarts, nothing to revert
there.
—E
On 08 May 2018, at 16:12, Eduardo Martins <emartins(a)redhat.com>
wrote:
We also revert back to what we had before in QS, and work out a better solution from
there.
—E
> On 08 May 2018, at 16:06, Rostislav Svoboda <rsvoboda(a)redhat.com
<mailto:rsvoboda@redhat.com>> wrote:
>
> Tomaz mentioned Quickstarts as one of the reasons to have BOMs in WF and WF-CORE.
>
> Eduardo should confirm that revert is fine for QS.
>
> Rostislav
>
> On Sat, May 5, 2018 at 11:25 AM, Kabir Khan <kkhan(a)redhat.com
<mailto:kkhan@redhat.com>> wrote:
> Perhaps https://github.com/jboss/bom-builder-maven-plugin
<https://github.com/jboss/bom-builder-maven-plugin> can be used? I've not played
with it
>
> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com
<mailto:david.lloyd@redhat.com>> wrote:
> >
> > I've created https://issues.jboss.org/browse/WFLY-10330
<https://issues.jboss.org/browse/WFLY-10330> and
> > https://issues.jboss.org/browse/WFCORE-3803
<https://issues.jboss.org/browse/WFCORE-3803> to track this.
> >
> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene(a)redhat.com
<mailto:jason.greene@redhat.com>> wrote:
> >> I agree. We can break the bom cycle a different way.
> >>
> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd(a)redhat.com
<mailto:david.lloyd@redhat.com>> wrote:
> >>>
> >>> I propose we revert the component-matrix change. This change is
> >>> ostensibly to help in the creation of a BOM for the client libraries
> >>> and other dependent projects; however, the cost has turned out to be
> >>> somewhat higher than expected.
> >>>
> >>> IntelliJ seems to be unable to cope with dependency changes in the
> >>> project due to the use of import from the root POM. This means that
> >>> the entire project must be force-reimported from time to time to keep
> >>> dependencies up to date, and forgetting to do so can lead to
> >>> development issues and lost time.
> >>>
> >>> Also, I've observed that Maven itself does not always correctly
> >>> resolve versions anymore, when you're building from a submodule. I
> >>> don't really know why this is the case but I suspect that it's
due to
> >>> some algorithmic ambiguity when the dependency tree is not linear like
> >>> it used to be.
> >>>
> >>> I think that if we need to generate some BOM for use by external
> >>> projects, it should be done as a separate step and artifact which
> >>> acquires versions from the parent. I believe we had it this way at
> >>> one point, didn't we?
> >>>
> >>> Anyway I think this change didn't work out, and we should undo it
> >>> while it's still remotely possible. WDYT?
> >>>
> >>> --
> >>> - DML
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> >
> >
> >
> > --
> > - DML
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
10:45 a.m.
Hi Paul and Petr,
Do you know of any uses of this plugin we could learn from?
Best regards,
Brian
On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan(a)redhat.com> wrote:
Perhaps https://github.com/jboss/bom-builder-maven-plugin can be
used?
I've not played with it
> On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com> wrote:
>
> I've created https://issues.jboss.org/browse/WFLY-10330 and
> https://issues.jboss.org/browse/WFCORE-3803 to track this.
>
> On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene(a)redhat.com>
wrote:
>> I agree. We can break the bom cycle a different way.
>>
>>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd(a)redhat.com>
wrote:
>>>
>>> I propose we revert the component-matrix change. This change is
>>> ostensibly to help in the creation of a BOM for the client libraries
>>> and other dependent projects; however, the cost has turned out to be
>>> somewhat higher than expected.
>>>
>>> IntelliJ seems to be unable to cope with dependency changes in the
>>> project due to the use of import from the root POM. This means that
>>> the entire project must be force-reimported from time to time to keep
>>> dependencies up to date, and forgetting to do so can lead to
>>> development issues and lost time.
>>>
>>> Also, I've observed that Maven itself does not always correctly
>>> resolve versions anymore, when you're building from a submodule. I
>>> don't really know why this is the case but I suspect that it's due
to
>>> some algorithmic ambiguity when the dependency tree is not linear like
>>> it used to be.
>>>
>>> I think that if we need to generate some BOM for use by external
>>> projects, it should be done as a separate step and artifact which
>>> acquires versions from the parent. I believe we had it this way at
>>> one point, didn't we?
>>>
>>> Anyway I think this change didn't work out, and we should undo it
>>> while it's still remotely possible. WDYT?
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> - DML
> _______________________________________________
> 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
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
1:30 a.m.
Plugin is used by EAP maven repo build to generate eap-runtime bom eg [1] based on the
feature packs dependency tree.
Relevant configuration is [2]
<http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-repository-testsuit...
Petr
[1]
http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-eap-7.2-maven-b...
[2]
http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-repository-testsuit...
On 05/08/2018 05:45 PM, Brian Stansberry wrote:
Hi Paul and Petr,
Do you know of any uses of this plugin we could learn from?
Best regards,
Brian
On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan(a)redhat.com
<mailto:kkhan@redhat.com>> wrote:
Perhaps https://github.com/jboss/bom-builder-maven-plugin
<https://github.com/jboss/bom-builder-maven-plugin> can be used?
I've not played with it
> On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com
<mailto:david.lloyd@redhat.com>> wrote:
>
> I've created https://issues.jboss.org/browse/WFLY-10330
<https://issues.jboss.org/browse/WFLY-10330> and
> https://issues.jboss.org/browse/WFCORE-3803
<https://issues.jboss.org/browse/WFCORE-3803> to track this.
>
> On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene(a)redhat.com
<mailto:jason.greene@redhat.com>> wrote:
>> I agree. We can break the bom cycle a different way.
>>
>>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd(a)redhat.com
<mailto:david.lloyd@redhat.com>> wrote:
>>>
>>> I propose we revert the component-matrix change. This change is
>>> ostensibly to help in the creation of a BOM for the client libraries
>>> and other dependent projects; however, the cost has turned out to be
>>> somewhat higher than expected.
>>>
>>> IntelliJ seems to be unable to cope with dependency changes in the
>>> project due to the use of import from the root POM. This means that
>>> the entire project must be force-reimported from time to time to keep
>>> dependencies up to date, and forgetting to do so can lead to
>>> development issues and lost time.
>>>
>>> Also, I've observed that Maven itself does not always correctly
>>> resolve versions anymore, when you're building from a submodule. I
>>> don't really know why this is the case but I suspect that it's
due to
>>> some algorithmic ambiguity when the dependency tree is not linear like
>>> it used to be.
>>>
>>> I think that if we need to generate some BOM for use by external
>>> projects, it should be done as a separate step and artifact which
>>> acquires versions from the parent. I believe we had it this way at
>>> one point, didn't we?
>>>
>>> Anyway I think this change didn't work out, and we should undo it
>>> while it's still remotely possible. WDYT?
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
11:13 a.m.
Here are the pull requests to move the version properties and dependency management back
into the root pom.xml and getting rid of the component-matrix.
https://github.com/wildfly/wildfly-core/pull/3275
https://github.com/wildfly/wildfly/pull/11200
We need to release a Beta of core tomorrow so it can get in for the feature freeze.
I am dabbling with generating the component-matrix contents by other means.
On 9 May 2018, at 07:30, Petr Sakar <psakar(a)redhat.com> wrote:
Plugin is used by EAP maven repo build to generate eap-runtime bom eg [1] based on the
feature packs dependency tree.
Relevant configuration is [2]
Petr
[1]
http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-eap-7.2-maven-b...
[2]
http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-repository-testsuit...
On 05/08/2018 05:45 PM, Brian Stansberry wrote:
> Hi Paul and Petr,
>
> Do you know of any uses of this plugin we could learn from?
>
> Best regards,
> Brian
>
> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan(a)redhat.com> wrote:
> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used? I've not
played with it
>
> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com> wrote:
> >
> > I've created https://issues.jboss.org/browse/WFLY-10330 and
> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
> >
> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene(a)redhat.com>
wrote:
> >> I agree. We can break the bom cycle a different way.
> >>
> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd(a)redhat.com>
wrote:
> >>>
> >>> I propose we revert the component-matrix change. This change is
> >>> ostensibly to help in the creation of a BOM for the client libraries
> >>> and other dependent projects; however, the cost has turned out to be
> >>> somewhat higher than expected.
> >>>
> >>> IntelliJ seems to be unable to cope with dependency changes in the
> >>> project due to the use of import from the root POM. This means that
> >>> the entire project must be force-reimported from time to time to keep
> >>> dependencies up to date, and forgetting to do so can lead to
> >>> development issues and lost time.
> >>>
> >>> Also, I've observed that Maven itself does not always correctly
> >>> resolve versions anymore, when you're building from a submodule. I
> >>> don't really know why this is the case but I suspect that it's
due to
> >>> some algorithmic ambiguity when the dependency tree is not linear like
> >>> it used to be.
> >>>
> >>> I think that if we need to generate some BOM for use by external
> >>> projects, it should be done as a separate step and artifact which
> >>> acquires versions from the parent. I believe we had it this way at
> >>> one point, didn't we?
> >>>
> >>> Anyway I think this change didn't work out, and we should undo it
> >>> while it's still remotely possible. WDYT?
> >>>
> >>> --
> >>> - DML
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> >
> > --
> > - DML
> > _______________________________________________
> > 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
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
11:28 a.m.
FYI I am planning a set of WildFly Elytron component upgrades tomorrow
morning.
Regards,
Darran Lofthouse.
On Thu, 10 May 2018 at 17:25 Kabir Khan <kkhan(a)redhat.com> wrote:
Here are the pull requests to move the version properties and
dependency
management back into the root pom.xml and getting rid of the
component-matrix.
https://github.com/wildfly/wildfly-core/pull/3275
https://github.com/wildfly/wildfly/pull/11200
We need to release a Beta of core tomorrow so it can get in for the
feature freeze.
I am dabbling with generating the component-matrix contents by other means.
> On 9 May 2018, at 07:30, Petr Sakar <psakar(a)redhat.com> wrote:
>
> Plugin is used by EAP maven repo build to generate eap-runtime bom eg
[1] based on the feature packs dependency tree.
>
> Relevant configuration is [2]
>
> Petr
>
> [1]
http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-eap-7.2-maven-b...
>
> [2]
http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-repository-testsuit...
>
> On 05/08/2018 05:45 PM, Brian Stansberry wrote:
>> Hi Paul and Petr,
>>
>> Do you know of any uses of this plugin we could learn from?
>>
>> Best regards,
>> Brian
>>
>> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan(a)redhat.com> wrote:
>> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used?
I've not played with it
>>
>> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com> wrote:
>> >
>> > I've created https://issues.jboss.org/browse/WFLY-10330 and
>> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
>> >
>> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene
<jason.greene(a)redhat.com>
wrote:
>> >> I agree. We can break the bom cycle a different way.
>> >>
>> >>> On May 4, 2018, at 3:53 PM, David Lloyd
<david.lloyd(a)redhat.com>
wrote:
>> >>>
>> >>> I propose we revert the component-matrix change. This change is
>> >>> ostensibly to help in the creation of a BOM for the client
libraries
>> >>> and other dependent projects; however, the cost has turned out to
be
>> >>> somewhat higher than expected.
>> >>>
>> >>> IntelliJ seems to be unable to cope with dependency changes in the
>> >>> project due to the use of import from the root POM. This means
that
>> >>> the entire project must be force-reimported from time to time to
keep
>> >>> dependencies up to date, and forgetting to do so can lead to
>> >>> development issues and lost time.
>> >>>
>> >>> Also, I've observed that Maven itself does not always
correctly
>> >>> resolve versions anymore, when you're building from a
submodule. I
>> >>> don't really know why this is the case but I suspect that
it's due
to
>> >>> some algorithmic ambiguity when the dependency tree is not linear
like
>> >>> it used to be.
>> >>>
>> >>> I think that if we need to generate some BOM for use by external
>> >>> projects, it should be done as a separate step and artifact which
>> >>> acquires versions from the parent. I believe we had it this way
at
>> >>> one point, didn't we?
>> >>>
>> >>> Anyway I think this change didn't work out, and we should undo
it
>> >>> while it's still remotely possible. WDYT?
>> >>>
>> >>> --
>> >>> - DML
>> >>> _______________________________________________
>> >>> wildfly-dev mailing list
>> >>> wildfly-dev(a)lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> >
>> > --
>> > - DML
>> > _______________________________________________
>> > 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
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
11:34 a.m.
Also this Blocker is dependent on a JBoss Modules upgrade that David is
currently working on - https://issues.jboss.org/browse/WFCORE-3799
On Thu, 10 May 2018 at 17:28 Darran Lofthouse <darran.lofthouse(a)redhat.com>
wrote:
FYI I am planning a set of WildFly Elytron component upgrades
tomorrow
morning.
Regards,
Darran Lofthouse.
On Thu, 10 May 2018 at 17:25 Kabir Khan <kkhan(a)redhat.com> wrote:
> Here are the pull requests to move the version properties and dependency
> management back into the root pom.xml and getting rid of the
> component-matrix.
>
> https://github.com/wildfly/wildfly-core/pull/3275
> https://github.com/wildfly/wildfly/pull/11200
>
> We need to release a Beta of core tomorrow so it can get in for the
> feature freeze.
>
> I am dabbling with generating the component-matrix contents by other
> means.
>
>
>
> > On 9 May 2018, at 07:30, Petr Sakar <psakar(a)redhat.com> wrote:
> >
> > Plugin is used by EAP maven repo build to generate eap-runtime bom eg
> [1] based on the feature packs dependency tree.
> >
> > Relevant configuration is [2]
> >
> > Petr
> >
> > [1]
>
http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-eap-7.2-maven-b...
> >
> > [2]
>
http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-repository-testsuit...
> >
> > On 05/08/2018 05:45 PM, Brian Stansberry wrote:
> >> Hi Paul and Petr,
> >>
> >> Do you know of any uses of this plugin we could learn from?
> >>
> >> Best regards,
> >> Brian
> >>
> >> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan(a)redhat.com> wrote:
> >> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be
> used? I've not played with it
> >>
> >> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com>
wrote:
> >> >
> >> > I've created https://issues.jboss.org/browse/WFLY-10330 and
> >> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
> >> >
> >> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <
> jason.greene(a)redhat.com> wrote:
> >> >> I agree. We can break the bom cycle a different way.
> >> >>
> >> >>> On May 4, 2018, at 3:53 PM, David Lloyd
<david.lloyd(a)redhat.com>
> wrote:
> >> >>>
> >> >>> I propose we revert the component-matrix change. This change
is
> >> >>> ostensibly to help in the creation of a BOM for the client
> libraries
> >> >>> and other dependent projects; however, the cost has turned out
to
> be
> >> >>> somewhat higher than expected.
> >> >>>
> >> >>> IntelliJ seems to be unable to cope with dependency changes in
the
> >> >>> project due to the use of import from the root POM. This
means
> that
> >> >>> the entire project must be force-reimported from time to time
to
> keep
> >> >>> dependencies up to date, and forgetting to do so can lead to
> >> >>> development issues and lost time.
> >> >>>
> >> >>> Also, I've observed that Maven itself does not always
correctly
> >> >>> resolve versions anymore, when you're building from a
submodule. I
> >> >>> don't really know why this is the case but I suspect that
it's due
> to
> >> >>> some algorithmic ambiguity when the dependency tree is not
linear
> like
> >> >>> it used to be.
> >> >>>
> >> >>> I think that if we need to generate some BOM for use by
external
> >> >>> projects, it should be done as a separate step and artifact
which
> >> >>> acquires versions from the parent. I believe we had it this
way at
> >> >>> one point, didn't we?
> >> >>>
> >> >>> Anyway I think this change didn't work out, and we should
undo it
> >> >>> while it's still remotely possible. WDYT?
> >> >>>
> >> >>> --
> >> >>> - DML
> >> >>> _______________________________________________
> >> >>> wildfly-dev mailing list
> >> >>> wildfly-dev(a)lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> >
> >> >
> >> >
> >> > --
> >> > - DML
> >> > _______________________________________________
> >> > 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
> >>
> >>
> >>
> >> --
> >> Brian Stansberry
> >> Manager, Senior Principal Software Engineer
> >> Red Hat
> >
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
11:36 a.m.
We aim to have them merged once tests complete.
On 10 May 2018, at 17:28, Darran Lofthouse
<darran.lofthouse(a)redhat.com> wrote:
FYI I am planning a set of WildFly Elytron component upgrades tomorrow morning.
Regards,
Darran Lofthouse.
On Thu, 10 May 2018 at 17:25 Kabir Khan <kkhan(a)redhat.com> wrote:
Here are the pull requests to move the version properties and dependency management back
into the root pom.xml and getting rid of the component-matrix.
https://github.com/wildfly/wildfly-core/pull/3275
https://github.com/wildfly/wildfly/pull/11200
We need to release a Beta of core tomorrow so it can get in for the feature freeze.
I am dabbling with generating the component-matrix contents by other means.
> On 9 May 2018, at 07:30, Petr Sakar <psakar(a)redhat.com> wrote:
>
> Plugin is used by EAP maven repo build to generate eap-runtime bom eg [1] based on
the feature packs dependency tree.
>
> Relevant configuration is [2]
>
> Petr
>
> [1]
http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-eap-7.2-maven-b...
>
> [2]
http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-repository-testsuit...
>
> On 05/08/2018 05:45 PM, Brian Stansberry wrote:
>> Hi Paul and Petr,
>>
>> Do you know of any uses of this plugin we could learn from?
>>
>> Best regards,
>> Brian
>>
>> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan(a)redhat.com> wrote:
>> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used? I've
not played with it
>>
>> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com> wrote:
>> >
>> > I've created https://issues.jboss.org/browse/WFLY-10330 and
>> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
>> >
>> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene
<jason.greene(a)redhat.com> wrote:
>> >> I agree. We can break the bom cycle a different way.
>> >>
>> >>> On May 4, 2018, at 3:53 PM, David Lloyd
<david.lloyd(a)redhat.com> wrote:
>> >>>
>> >>> I propose we revert the component-matrix change. This change is
>> >>> ostensibly to help in the creation of a BOM for the client
libraries
>> >>> and other dependent projects; however, the cost has turned out to
be
>> >>> somewhat higher than expected.
>> >>>
>> >>> IntelliJ seems to be unable to cope with dependency changes in the
>> >>> project due to the use of import from the root POM. This means
that
>> >>> the entire project must be force-reimported from time to time to
keep
>> >>> dependencies up to date, and forgetting to do so can lead to
>> >>> development issues and lost time.
>> >>>
>> >>> Also, I've observed that Maven itself does not always
correctly
>> >>> resolve versions anymore, when you're building from a
submodule. I
>> >>> don't really know why this is the case but I suspect that
it's due to
>> >>> some algorithmic ambiguity when the dependency tree is not linear
like
>> >>> it used to be.
>> >>>
>> >>> I think that if we need to generate some BOM for use by external
>> >>> projects, it should be done as a separate step and artifact which
>> >>> acquires versions from the parent. I believe we had it this way
at
>> >>> one point, didn't we?
>> >>>
>> >>> Anyway I think this change didn't work out, and we should undo
it
>> >>> while it's still remotely possible. WDYT?
>> >>>
>> >>> --
>> >>> - DML
>> >>> _______________________________________________
>> >>> wildfly-dev mailing list
>> >>> wildfly-dev(a)lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> >
>> > --
>> > - DML
>> > _______________________________________________
>> > 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
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:19 p.m.
I am dabbling with generating the component-matrix contents by other
means.
If component-matrix (or whatever is decided to be called) is not available
/ done / released
as part of server release itself or it is lacking any of the components or
is out of sync on release it is useless!
Main driver for having it like this was to provide users complete component
version matrix
so they are able to import it to their IDE to aid with sources when they
are debugging application running on server.
Currently only somewhat similar thing we have is "wildfly-parent" which is
much more than just component matrix.
So just keep in mind what the user requirements / desires are.
--
tomaz
On Thu, May 10, 2018 at 6:13 PM, Kabir Khan <kkhan(a)redhat.com> wrote:
Here are the pull requests to move the version properties and
dependency
management back into the root pom.xml and getting rid of the
component-matrix.
https://github.com/wildfly/wildfly-core/pull/3275
https://github.com/wildfly/wildfly/pull/11200
We need to release a Beta of core tomorrow so it can get in for the
feature freeze.
I am dabbling with generating the component-matrix contents by other means.
> On 9 May 2018, at 07:30, Petr Sakar <psakar(a)redhat.com> wrote:
>
> Plugin is used by EAP maven repo build to generate eap-runtime bom eg
[1] based on the feature packs dependency tree.
>
> Relevant configuration is [2]
>
> Petr
>
> [1] http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-
eap-7.2-maven-build/latest/maven/org/jboss/bom/eap-
runtime-artifacts/7.2.0.CD12.CR2/eap-runtime-artifacts-7.2.0.CD12.CR2.pom
>
> [2] http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-
repository-testsuite.git/tree/repository-content/dependency-
lists/eap-runtime-artifacts/pom.xml?h=eap-7.2.0.CD12#n105
>
> On 05/08/2018 05:45 PM, Brian Stansberry wrote:
>> Hi Paul and Petr,
>>
>> Do you know of any uses of this plugin we could learn from?
>>
>> Best regards,
>> Brian
>>
>> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan(a)redhat.com> wrote:
>> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used?
I've not played with it
>>
>> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com> wrote:
>> >
>> > I've created https://issues.jboss.org/browse/WFLY-10330 and
>> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
>> >
>> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene
<jason.greene(a)redhat.com>
wrote:
>> >> I agree. We can break the bom cycle a different way.
>> >>
>> >>> On May 4, 2018, at 3:53 PM, David Lloyd
<david.lloyd(a)redhat.com>
wrote:
>> >>>
>> >>> I propose we revert the component-matrix change. This change is
>> >>> ostensibly to help in the creation of a BOM for the client
libraries
>> >>> and other dependent projects; however, the cost has turned out to
be
>> >>> somewhat higher than expected.
>> >>>
>> >>> IntelliJ seems to be unable to cope with dependency changes in the
>> >>> project due to the use of import from the root POM. This means
that
>> >>> the entire project must be force-reimported from time to time to
keep
>> >>> dependencies up to date, and forgetting to do so can lead to
>> >>> development issues and lost time.
>> >>>
>> >>> Also, I've observed that Maven itself does not always
correctly
>> >>> resolve versions anymore, when you're building from a
submodule. I
>> >>> don't really know why this is the case but I suspect that
it's due
to
>> >>> some algorithmic ambiguity when the dependency tree is not linear
like
>> >>> it used to be.
>> >>>
>> >>> I think that if we need to generate some BOM for use by external
>> >>> projects, it should be done as a separate step and artifact which
>> >>> acquires versions from the parent. I believe we had it this way
at
>> >>> one point, didn't we?
>> >>>
>> >>> Anyway I think this change didn't work out, and we should undo
it
>> >>> while it's still remotely possible. WDYT?
>> >>>
>> >>> --
>> >>> - DML
>> >>> _______________________________________________
>> >>> wildfly-dev mailing list
>> >>> wildfly-dev(a)lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> >
>> > --
>> > - DML
>> > _______________________________________________
>> > 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
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:51 p.m.
On Thu, May 10, 2018 at 3:19 PM, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
> I am dabbling with generating the component-matrix contents by
other
means.
If component-matrix (or whatever is decided to be called) is not available
/ done / released
as part of server release itself
The idea is to generate it as part of the build itself.
or it is lacking any of the components or is out of sync on release it is
useless!
Main driver for having it like this was to provide users complete
component version matrix
so they are able to import it to their IDE to aid with sources when they
are debugging application running on server.
Currently only somewhat similar thing we have is "wildfly-parent" which is
much more than just component matrix.
So just keep in mind what the user requirements / desires are.
--
tomaz
On Thu, May 10, 2018 at 6:13 PM, Kabir Khan <kkhan(a)redhat.com> wrote:
> Here are the pull requests to move the version properties and dependency
> management back into the root pom.xml and getting rid of the
> component-matrix.
>
> https://github.com/wildfly/wildfly-core/pull/3275
> https://github.com/wildfly/wildfly/pull/11200
>
> We need to release a Beta of core tomorrow so it can get in for the
> feature freeze.
>
> I am dabbling with generating the component-matrix contents by other
> means.
>
>
>
> > On 9 May 2018, at 07:30, Petr Sakar <psakar(a)redhat.com> wrote:
> >
> > Plugin is used by EAP maven repo build to generate eap-runtime bom eg
> [1] based on the feature packs dependency tree.
> >
> > Relevant configuration is [2]
> >
> > Petr
> >
> > [1] http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-ea
> p-7.2-maven-build/latest/maven/org/jboss/bom/eap-runtime-
> artifacts/7.2.0.CD12.CR2/eap-runtime-artifacts-7.2.0.CD12.CR2.pom
> >
> > [2] http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-reposi
> tory-testsuite.git/tree/repository-content/dependency-lists/
> eap-runtime-artifacts/pom.xml?h=eap-7.2.0.CD12#n105
> >
> > On 05/08/2018 05:45 PM, Brian Stansberry wrote:
> >> Hi Paul and Petr,
> >>
> >> Do you know of any uses of this plugin we could learn from?
> >>
> >> Best regards,
> >> Brian
> >>
> >> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan(a)redhat.com> wrote:
> >> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be
> used? I've not played with it
> >>
> >> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd(a)redhat.com>
wrote:
> >> >
> >> > I've created https://issues.jboss.org/browse/WFLY-10330 and
> >> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
> >> >
> >> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <
> jason.greene(a)redhat.com> wrote:
> >> >> I agree. We can break the bom cycle a different way.
> >> >>
> >> >>> On May 4, 2018, at 3:53 PM, David Lloyd
<david.lloyd(a)redhat.com>
> wrote:
> >> >>>
> >> >>> I propose we revert the component-matrix change. This change
is
> >> >>> ostensibly to help in the creation of a BOM for the client
> libraries
> >> >>> and other dependent projects; however, the cost has turned out
to
> be
> >> >>> somewhat higher than expected.
> >> >>>
> >> >>> IntelliJ seems to be unable to cope with dependency changes in
the
> >> >>> project due to the use of import from the root POM. This
means
> that
> >> >>> the entire project must be force-reimported from time to time
to
> keep
> >> >>> dependencies up to date, and forgetting to do so can lead to
> >> >>> development issues and lost time.
> >> >>>
> >> >>> Also, I've observed that Maven itself does not always
correctly
> >> >>> resolve versions anymore, when you're building from a
submodule. I
> >> >>> don't really know why this is the case but I suspect that
it's due
> to
> >> >>> some algorithmic ambiguity when the dependency tree is not
linear
> like
> >> >>> it used to be.
> >> >>>
> >> >>> I think that if we need to generate some BOM for use by
external
> >> >>> projects, it should be done as a separate step and artifact
which
> >> >>> acquires versions from the parent. I believe we had it this
way at
> >> >>> one point, didn't we?
> >> >>>
> >> >>> Anyway I think this change didn't work out, and we should
undo it
> >> >>> while it's still remotely possible. WDYT?
> >> >>>
> >> >>> --
> >> >>> - DML
> >> >>> _______________________________________________
> >> >>> wildfly-dev mailing list
> >> >>> wildfly-dev(a)lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> >
> >> >
> >> >
> >> > --
> >> > - DML
> >> > _______________________________________________
> >> > 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
> >>
> >>
> >>
> >> --
> >> Brian Stansberry
> >> Manager, Senior Principal Software Engineer
> >> 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
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
2488
days inactive
2494
days old
15 comments
9 participants
participants (9)
-
Brian Stansberry -
Darran Lofthouse -
David Lloyd -
Eduardo Martins -
Jason Greene -
Kabir Khan -
Petr Sakar -
Rostislav Svoboda -
Tomaž Cerar