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.
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