Hello all,
As you have reflected on earlier, it is possible although somewhat clunky
to implement the Consumer vs Build POM today using the Maven Enforcer and a
custom rule to identify the two types of POM. I have done one such
implementation (found at GitHub
<https://github.com/lennartj/nazgul_tools/blob/master/codestyle/src/main/java/se/jguru/nazgul/tools/codestyle/enforcer/rules/ProjectType.java>)
which has been used in a lot of projects for about 10 years now, and is
based on some simple rules for [GroupID-ArtifactID-Packaging]. The
implementation provides such rules to identify project stereotypes of
different kinds, to enable applying different rules to different projects.
With a simple piece of logic, one can parse and match the respective values
within the POM to find out the type of project currently being built.
In the POM case, I simply called the stereotypes REACTOR and PARENT, since
one is used to construct the Maven reactor and one is used as parent for
other projects.
/**
* <p>Reactor project, of type pom. May not contain anything except
module definitions.</p>
*/
REACTOR(".*-reactor$", null, "pom"),
/**
* <p>Parent pom project, of type pom, defining dependencies and/or build
* life cycles. May not contain module definitions.</p>
*/
PARENT(".*-parent$", null, "pom"),
I basically needed some simple way to promote code health in refactoring
big enterprise codebases. It has worked well - so I'd say dividing the
currently somewhat overloaded POM into those 2 stereotypes is a good thing.
However, as people know that the Maven Way (tm) tends to be a successful
way to use Maven, I think we need to complement the documentation with some
pointers to "how you can structure your codebase" examples or
documentation.
I am certain there are quite a few out there in addition to the Nazgul
Tools Codestyle <https://github.com/lennartj/nazgul_tools>.
Fair?
2018-03-14 23:45 GMT+01:00 Hervé BOUTEMY <[email protected]>:
> IMHO, in this case, the dependency should be defined in the profile in the
> consumer POM, with resolved property of the profile.
>
> I don't know if flatten-maven-plugin currently detects such a situation
> and is
> able to move the parametrized dependency in main section to
> non-parametrized
> dependency in profile. Or at least detect that the situation is complex and
> require some tricks.
>
> This situation won't happen often, but sure, this will happen and we need
> to
> define what to do.
>
> Currently, the study in Git did not try to dig into implementation of the
> transformation: but this edge case will be a good one to test.
>
> Regards,
>
> Hervé
>
> Le mercredi 14 mars 2018, 13:21:21 CET Jörg Schaible a écrit :
> > Am Mon, 12 Mar 2018 01:12:52 +0100 schrieb Hervé BOUTEMY:
> >
> > [snip]
> >
> > >> > Why is <profiles/> required for consumers? I'm not aware how
> profiles
> > >> > of a dependency ever play(ed) a role in my "dependent" project?
> > >>
> > >> I can remember we had a discussion about that..my first reaction would
> > >> be saying no profiles needed in a consumer pom...but I'm not 100%
> > >> sure...we need to think that more in detail with different scenarios..
> > >
> > > Robert has a strong opinion on this, for profiles activated by OS or
> JDK
> > > version, like flatten-maven-plugin
> >
> > How would you solve this case then:
> >
> > Somewhere in a parent pom:
> > ============== %< =============
> > <profile>
> > <id>linux-amd64</id>
> > <activation>
> > <os>
> > <family>linux</family>
> > <arch>amd64</arch>
> > </os>
> > </activation>
> > <properties>
> > <swt.artifactId>org.eclipse.swt.gtk.linux.x86_64</swt.artifactId>
> > </properties>
> > </profile>
> > <profile>
> > <id>windows-amd64</id>
> > <activation>
> > <os>
> > <family>windows</family>
> > <arch>amd64</arch>
> > </os>
> > </activation>
> > <properties>
> > <swt.artifactId>org.eclipse.swt.win32.win32.x86_64</swt.art
> ifactId>
> > </properties>
> > </profile>
> > <!-- following more variants for supported platforms -->
> > ============== %< =============
> >
> > Somewhere in a child project X:
> >
> > ============== %< =============
> > <dependencies>
> > <dependency>
> > <groupId>org.eclipse.swt</groupId>
> > <artifactId>${swt.artifactId}</artifactId>
> > <version>3.106.0.v20170608-0516</version>
> > </dependency>
> > </dependencies>
> > ============== %< =============
> >
> > What would a consumer-pom.xml of X look like and how can a client of X
> > still depend on the proper dependency for its target platform?
> >
> > Cheers,
> > Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [email protected]
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
