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


_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev



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