Proposal to revert component-matrix change

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal to revert component-matrix change

David Lloyd-2
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

jtgreene
Administrator
I agree. We can break the bom cycle a different way.

> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

David Lloyd-2
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 <[hidden email]> wrote:

> I agree. We can break the bom cycle a different way.
>
>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

Kabir Khan-2
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 <[hidden email]> 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 <[hidden email]> wrote:
>> I agree. We can break the bom cycle a different way.
>>
>>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

Rostislav Svoboda
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> I agree. We can break the bom cycle a different way.
>>
>>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

David Lloyd-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> > wrote:
>> >> I agree. We can break the bom cycle a different way.
>> >>
>> >>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]>
>> >>> 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
>> >>> [hidden email]
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> >
>> > --
>> > - DML
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>



--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

Eduardo Martins-2
In reply to this post by Rostislav Svoboda
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> I agree. We can break the bom cycle a different way.
>>
>>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

Brian Stansberry
In reply to this post by Kabir Khan-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> I agree. We can break the bom cycle a different way.
>>
>>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

Petr Sakar

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
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> I agree. We can break the bom cycle a different way.
>>
>>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

Eduardo Martins-2
In reply to this post by Eduardo Martins-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> I agree. We can break the bom cycle a different way.
>>
>>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

Kabir Khan-2
In reply to this post by Petr Sakar
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> >> I agree. We can break the bom cycle a different way.
>> >>
>> >>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
>> >>> [hidden email]
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> >
>> > --
>> > - DML
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

Darran Lofthouse-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> >> I agree. We can break the bom cycle a different way.
>> >>
>> >>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
>> >>> [hidden email]
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> >
>> > --
>> > - DML
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

Darran Lofthouse-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> >> I agree. We can break the bom cycle a different way.
>> >>
>> >>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
>> >>> [hidden email]
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> >
>> > --
>> > - DML
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

Kabir Khan-2
In reply to this post by Darran Lofthouse-2
We aim to have them merged once tests complete.

> On 10 May 2018, at 17:28, Darran Lofthouse <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
> >> >> I agree. We can break the bom cycle a different way.
> >> >>
> >> >>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
> >> >>> [hidden email]
> >> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> >
> >> >
> >> >
> >> > --
> >> > - DML
> >> > _______________________________________________
> >> > wildfly-dev mailing list
> >> > [hidden email]
> >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >>
> >> --
> >> Brian Stansberry
> >> Manager, Senior Principal Software Engineer
> >> Red Hat
> >
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

Tomaž Cerar-2
In reply to this post by Kabir Khan-2
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> >> I agree. We can break the bom cycle a different way.
>> >>
>> >>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
>> >>> [hidden email]
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> >
>> > --
>> > - DML
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to revert component-matrix change

Brian Stansberry

On Thu, May 10, 2018 at 3:19 PM, Tomaž Cerar <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>> >> I agree. We can break the bom cycle a different way.
>> >>
>> >>> On May 4, 2018, at 3:53 PM, David Lloyd <[hidden email]> 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
>> >>> [hidden email]
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> >
>> > --
>> > - DML
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev