[wildfly-dev] Proposal to revert component-matrix change

[Brian Stansberry]

On Thu, May 10, 2018 at 3:19 PM, Tomaž Cerar <tomaz.cerar at 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 at 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 at 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 at 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 at 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 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>
>> 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
>> >> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > - DML
>> >> > _______________________________________________
>> >> > wildfly-dev mailing list
>> >> > wildfly-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180510/0fa4b028/attachment-0001.html