[wildfly-dev] Proposal to revert component-matrix change
Eduardo Martins
emartins at redhat.com
Wed May 9 08:11:02 EDT 2018
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 at 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 at redhat.com <mailto:rsvoboda at 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 at redhat.com <mailto:kkhan at 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 at redhat.com <mailto:david.lloyd at 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 at redhat.com <mailto:jason.greene at 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 at redhat.com <mailto:david.lloyd at 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 at lists.jboss.org <mailto:wildfly-dev at 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 at lists.jboss.org <mailto:wildfly-dev at 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 at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180509/169215e3/attachment.html
More information about the wildfly-dev
mailing list