The pom next to the artifact will be correct and ready to be consumed.
Only the /META-INF/maven/{G}/{A}/pom.xml will now be the local pom. If you make
use of some new features this pom might be incomplete, but AFAIK there are only
a few cases where this embedded pom is used.
Robert
On 12-11-2020 22:38:33, Romain Manni-Bucau <[email protected]> wrote:
Le jeu. 12 nov. 2020 à 22:14, Robert Scholte a
écrit :
> The discussion is first of all saying the next release should be
> 4.0.0-alpha-1 (or something similar), so 3.6.3 was the last of the Maven 3
> releases unless we need to backport security fixes.
> What to add to that release is the next discussion.
> Signing is only relevant for releases, but I think most companies don't
> sign jars for their internal projects.
> For those developers the missing features don't matter, but they can
> benefit from a huge amount of improvements.
>
I disagree, a release is not only about signing but also letting others
consume artifacts you produce.
Having a proof it works for us is important before considering it can be a
released feature (on by default).
Also agree we shouldnt put a lot of features per release so maybe just the
pom one in alpha-1? This ensures people can test what we propose and not
only something else more shining.
> Robert
> On 12-11-2020 21:55:51, Romain Manni-Bucau wrote:
> Hmm, if it does not work e2e then even an alpha is pointless cause nobody
> can test it further than a hello world, was my point.
>
> Le jeu. 12 nov. 2020 à 21:01, Robert Scholte a
> écrit :
>
> > I don't expect that signing will work with the the first alpha, but that
> > shouldn't stop us of collecting feedback.
> > Also we need to have a look at all plugins that do something with the
> pom,
> > like every packaging plugin, maven-source-plugin, maven-release-plugin to
> > ensure the "right" pom is added.
> >
> > And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even
> > though they are stable).
> > There's still enough work to reach 4.0.0, but most likely the first
> alphas
> > are already good enough for the majority.
> >
> > On 12-11-2020 20:45:09, Romain Manni-Bucau wrote:
> > Did we already do mvn or mvn plugins (multimodules) release with the
> > consumer/producer pom feature?
> > If so +1 to do a v4 with this new feature "for us" and v5 with real user
> > features and align it with the xsd.
> >
> > Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> > écrit :
> >
> > > Hi,
> > >
> > > It is already several years ago where we started discussing about Maven
> > > Next Generations.
> > > Clearly we needed to work on the pom, because over time we're facing
> more
> > > and more limitations.
> > > For (Maven) Central the Model 4.0.0 will be required pom format,
> there's
> > > no discussion about that. So we needed a new architecture where
> there's a
> > > local pom that is transformed to Model 4.0.0 or where it can be
> > generated.
> > > With the implementation of MNG-6656 and the improvement with MNG-6957
> > > we've made the first and important steps based on pom transformation.
> If
> > > this concept proofs itself, we can start thinking about enhancing the
> pom
> > > model.
> > >
> > > When talking about Model 5.0.0 it looked like it would be great to
> > > introduce it for Maven 5. There was even a period where we thought
> about
> > > skipping Maven 4, just to sync the Model version with the Maven
> version.
> > > However, we discovered that this would be a huge change, and that we
> > would
> > > probably need a couple of Maven 4 releases before moving to Maven 5.
> > Maven
> > > 4 would consist of preparation releases.
> > > I've started writing the build/consumer to proof that the it is indeed
> > > possible to separate the local pom from the distributed pom, even
> though
> > > they both are currently still Model 4.0.0 compatible.
> > > The original idea was:
> > > Maven 3: build/consumer feature disabled by default
> > > Maven 4: build/consumer feature enabled by default
> > >
> > > Maven 5: Model 5
> > >
> > > We were worried that this wouldn't give us enough feedback.
> > > maven-integration-testing shows that build/consumer does work. There
> > should
> > > be enough trust to enable it by default, it shouldn't impact existing
> > > projects (the last find by Michael was actually great. It demonstrated
> > the
> > > effect when using threads. The fix made sense and Maven was stable
> > again).
> > > But it is simply not enough. We need much more feedback.
> > >
> > > Meanwhile other improvements have been done, that has impact:
> > > - new behavior of reactor commandline arguments
> > > - upgrade of default versions of plugins per packaging type
> > > - requiring Java 8
> > > - Maven wrapper
> > > - there's a PR waiting that will shift the logic of the
> > > ProjectBuilder/ModelBuilder. As this is quite important for more people
> > to
> > > understand, I'll record a Q&A with Maarten+Martin soon and share it
> with
> > > you.
> > > There are probably more, but all these already defend my opinion about
> > the
> > > next Maven version.
> > >
> > > To me it is not a Maven 3 anymore, we're reached a point where we
> should
> > > start calling it Maven 4.
> > > The next release should probably have an alpha suffix, just to give
> users
> > > the chance to do alpha testing.
> > >
> > > WDYT?
> > > Robert
> > >
> > >
> >
>
