Re: [DISCUSS] New goal for install/deploy plugin?

[Romain Manni-Bucau]

Then I guess the new deploy logic is wrong since it does not enable to use
the mojo as a mojo (outside a predefined lifecycle which is against mojo
design) so should be relaxed (reverted?).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le sam. 25 févr. 2023 à 14:34, Tamás Cservenák  a
écrit :

> I dislike the idea to "toggle logic". This way, we would have 3 mojos with
> 3 different logic. Is simpler to understand, that invoke same mojo to do
> this or that, based on toggle.
>
> T
>
> On Sat, Feb 25, 2023, 13:18 Romain Manni-Bucau 
> wrote:
>
> > Hi,
> >
> > Maybe I missed some details but n unsafe toggle (parameter) to deploy
> > sounds like a good compromise to me.
> > Too much overlapping goals sounds weird and hard to understand.
> >
> > Le sam. 25 févr. 2023 à 12:39, Tamás Cservenák  a
> > écrit :
> >
> > > Howdy,
> > >
> > > Here is this thread:
> > > https://lists.apache.org/thread/lbbd5n92xjksyf53mlf12togxrvdbvhl
> > >
> > > In short, user is _partially_ building a module, and invokes
> > deploy:deploy,
> > > that now fails, as since 3.x version of install/deploy, there is a
> > "safety
> > > check" in these mojos, to not deploy partially (here it would deploy
> POM
> > > with packaging jar, but the main artifact is NOT built, only a
> classified
> > > one). User opted for this solution as it is "one liner", as deploy-file
> > > would require MANY parameters (does not reuse POM values).
> > >
> > > ===
> > >
> > > So, what about a new mojo for install/deploy plugins? (symmetrically
> for
> > > both install/deploy plugins, but explaining on case of deploy)
> > >
> > > deploy:deploy -- unchanged, works as today: "deploy project" and
> enforces
> > > repository hygiene, fails if POM refers to main artifact that is not
> > > present
> > > deploy:deploy-file -- unchanged, works as today, "deploy file" and
> > neglects
> > > exiting POM and requires MANY parameters
> > >
> > > and a new goal:
> > > deploy:deploy-artifacts -- this is a "mesh" between two above but would
> > > NEVER deploy POM. What this goal would essentially do, is "just
> blindly"
> > > deploy any (packaged) artifact (main or attached/classified) but would
> > NOT
> > > deploy a POM. Even if one classified artifact is present, it would
> deploy
> > > it. It MAY fail if invoked and the project has NOTHING to deploy. So,
> > like
> > > deploy-file but needs a project (to reuse coordinates from it)
> > >
> > > Related issues:
> > > https://issues.apache.org/jira/browse/MDEPLOY-205
> > > https://issues.apache.org/jira/browse/MINSTALL-118
> > >
> > > WDYT?
> > > Tamas
> > >
> >
>

Re: Test problem at head: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.1.1:unpack (unpack-classes) on project plexus-utils: Artifact has not been packaged yet.

[Eric Lilja]

Just curious, why is such an old version of maven-dependency-plugin used in
that build?

- Eric L

On Sat, Feb 25, 2023 at 2:46 PM Elliotte Rusty Harold 
wrote:

> On Sat, Feb 25, 2023 at 11:46 AM Guillaume Nodet 
> wrote:
> >
> > Which goal are you running ?
> > I think you need to run the package phase as hinted by the error.
> >
>
>
> mvn test
>
> also
>
> mvn compile; mvn test
> mvn clean test
> mvn package; mvn test
>
> All end with the same failure. This seems to be a regression in 4.0. I
> don't see this on the 3.9.x branch.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [HEADS UP] Maven Release 3.9.1 coming soon

[Tamás Cservenák]

Howdy,

I may be late, sorry about that, but few days ago pulled this page from
archive org (was hosted and lost on codehaus confluence):
https://cwiki.apache.org/confluence/display/MAVEN/Versioning

As based on this page was Maven3 versioning implemented, at least according
to this page:
https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes

That was written at dawn of Maven3.

Hth
T

On Sat, Feb 25, 2023, 15:26 Elliotte Rusty Harold 
wrote:

> After further investigation I'm willing to state that MNG-7701 is
> invalid, and I closed it.
>
> MNG-7700 is mostly invalid. There's a bit of a glitch around the
> "canonical representation" of version strings of the form 0.x that
> does not affect comparisons. However, nowhere do we define or promise
> anything about the canonical representation so it's hard to call it a
> bug.
>
> In all cases I've looked at, the comparison of two versions behaves
> according to spec. INHO, neither of these issues should block the
> release.
>
> On Fri, Feb 24, 2023 at 9:03 AM Tamás Cservenák 
> wrote:
> >
> > Howdy,
> >
> > just an update of Maven status (links will assume you are logged in to
> > JIRA):
> >
> > * 3.9.1 all done
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.1
> > * 3.9.1 candidates
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.1-candidate
> > (Elliotte plans to fix for weekend MNG-7700 and MNG-7701 if it is not
> > grabbed by anyone else until then)
> >
> > This means 3.9.1 is shaping really nicely
> >
> > Furthermore, for resolver:
> >
> > * 1.9.6 (will not make into 3.9.1 but probably 3.9.2):
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.6
> > (topic: bugfixes and improvements, would include
> > https://issues.apache.org/jira/browse/MNG-7705 that does not yet has
> > corresponding MRESOLVER issue)
> > * planned 1.10.0
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.10.0
> > (topic: HTTP/2 and other improvements, probably makes file-lock default)
> >
> > Thanks
> > T
> >
> >
> > On Fri, Feb 24, 2023 at 4:58 AM Jeremy Landis 
> > wrote:
> >
> > > Update on issue I'm facing.
> > >
> > > The issue is using the site:jar during the release process.  Rather
> than
> > > deploy site to any location, we jar it and deploy it with normal
> artifacts
> > > to Artifactory.  Since that plugin goal wants the full build
> (aggregate),
> > > it fails against numerous plugins such as javadoc, jxr, etc.  I presume
> > > rather than that running during package phase, it needs to be moved
> and run
> > > separately like how the site-deploy works with the release plugin.  Any
> > > ideas on best way to deal with this?  Right now it feels like its done
> in
> > > the right place, we even skip the 'site-deploy' entirely.  But clearly
> that
> > > isn't exactly good enough in this case.
> > >
> > > I don't think now that this is a maven 3.9.0 issue itself.  I think its
> > > more of something that is a big change in this specific use case that
> just
> > > needs some direction to resolve.  The more and more I've looked at
> this the
> > > more I've found little things that have changed over the years that had
> > > resulted in multiple site runs and some plugins from running exactly
> where
> > > expected.  So this has been a hugely beneficial effort for us and just
> need
> > > to figure this last bit out.  My next steps are to look more deeply
> into
> > > release plugin and how the site-deploy is actually working as that
> seems
> > > like I want to mimic that behaviour.
> > >
> > > Thanks,
> > >
> > > Jeremy
> > >
> > > -Original Message-
> > > From: Jeremy Landis 
> > > Sent: Wednesday, February 22, 2023 12:30 PM
> > > To: Maven Developers List 
> > > Subject: RE: [HEADS UP] Maven Release 3.9.1 coming soon
> > >
> > > Hi Tomas,
> > >
> > > Will get back to you on ability to collect that data, lots of hoops to
> do
> > > so.  It may be easier I just build sample project.
> > >
> > > On the cache, thanks for calling that out as not maven.  It was gradle
> > > enterprise maven extension.  I turned it off to rule it out and
> behaviour
> > > is the same just without any mention of the cache.
> > >
> > > I even tried to checkout the release tag and perform full build before
> > > running perform but that just failed with issues running install plugin
> > > during release:perform. So, I backed off to what is focus...
> > >
> > > To focus more on the site is the problem, I tried numerous attempts to
> > > make it stop running but couldn't get that to stick so I went into the
> > > cached parent used and set skip directly then ran release:perform
> again.
> > > It worked doing that.
> > >
> > > So on the aggregator behaviour change.  Assuming then pre 3.9.0, when
> site
> > > plugins encountered and forked, if it was not already 

Re: [HEADS UP] Maven Release 3.9.1 coming soon

[Elliotte Rusty Harold]

After further investigation I'm willing to state that MNG-7701 is
invalid, and I closed it.

MNG-7700 is mostly invalid. There's a bit of a glitch around the
"canonical representation" of version strings of the form 0.x that
does not affect comparisons. However, nowhere do we define or promise
anything about the canonical representation so it's hard to call it a
bug.

In all cases I've looked at, the comparison of two versions behaves
according to spec. INHO, neither of these issues should block the
release.

On Fri, Feb 24, 2023 at 9:03 AM Tamás Cservenák  wrote:
>
> Howdy,
>
> just an update of Maven status (links will assume you are logged in to
> JIRA):
>
> * 3.9.1 all done
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.1
> * 3.9.1 candidates
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.1-candidate
> (Elliotte plans to fix for weekend MNG-7700 and MNG-7701 if it is not
> grabbed by anyone else until then)
>
> This means 3.9.1 is shaping really nicely
>
> Furthermore, for resolver:
>
> * 1.9.6 (will not make into 3.9.1 but probably 3.9.2):
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.6
> (topic: bugfixes and improvements, would include
> https://issues.apache.org/jira/browse/MNG-7705 that does not yet has
> corresponding MRESOLVER issue)
> * planned 1.10.0
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.10.0
> (topic: HTTP/2 and other improvements, probably makes file-lock default)
>
> Thanks
> T
>
>
> On Fri, Feb 24, 2023 at 4:58 AM Jeremy Landis 
> wrote:
>
> > Update on issue I'm facing.
> >
> > The issue is using the site:jar during the release process.  Rather than
> > deploy site to any location, we jar it and deploy it with normal artifacts
> > to Artifactory.  Since that plugin goal wants the full build (aggregate),
> > it fails against numerous plugins such as javadoc, jxr, etc.  I presume
> > rather than that running during package phase, it needs to be moved and run
> > separately like how the site-deploy works with the release plugin.  Any
> > ideas on best way to deal with this?  Right now it feels like its done in
> > the right place, we even skip the 'site-deploy' entirely.  But clearly that
> > isn't exactly good enough in this case.
> >
> > I don't think now that this is a maven 3.9.0 issue itself.  I think its
> > more of something that is a big change in this specific use case that just
> > needs some direction to resolve.  The more and more I've looked at this the
> > more I've found little things that have changed over the years that had
> > resulted in multiple site runs and some plugins from running exactly where
> > expected.  So this has been a hugely beneficial effort for us and just need
> > to figure this last bit out.  My next steps are to look more deeply into
> > release plugin and how the site-deploy is actually working as that seems
> > like I want to mimic that behaviour.
> >
> > Thanks,
> >
> > Jeremy
> >
> > -Original Message-
> > From: Jeremy Landis 
> > Sent: Wednesday, February 22, 2023 12:30 PM
> > To: Maven Developers List 
> > Subject: RE: [HEADS UP] Maven Release 3.9.1 coming soon
> >
> > Hi Tomas,
> >
> > Will get back to you on ability to collect that data, lots of hoops to do
> > so.  It may be easier I just build sample project.
> >
> > On the cache, thanks for calling that out as not maven.  It was gradle
> > enterprise maven extension.  I turned it off to rule it out and behaviour
> > is the same just without any mention of the cache.
> >
> > I even tried to checkout the release tag and perform full build before
> > running perform but that just failed with issues running install plugin
> > during release:perform. So, I backed off to what is focus...
> >
> > To focus more on the site is the problem, I tried numerous attempts to
> > make it stop running but couldn't get that to stick so I went into the
> > cached parent used and set skip directly then ran release:perform again.
> > It worked doing that.
> >
> > So on the aggregator behaviour change.  Assuming then pre 3.9.0, when site
> > plugins encountered and forked, if it was not already built it would build
> > all?  That seems to be the problem...which would make sense why a single
> > module project does not encounter this at all.
> >
> > Thanks,
> >
> > Jeremy
> >
> > -Original Message-
> > From: Tamás Cservenák 
> > Sent: Wednesday, February 22, 2023 10:35 AM
> > To: Maven Developers List 
> > Subject: Re: [HEADS UP] Maven Release 3.9.1 coming soon
> >
> > Howdy,
> >
> > Wow, there are a lot of moving parts release plugin, site (within
> > release?)...
> >
> > Do you use any 3rd party extension maybe? (unsure what build cache is in
> > the realm of Maven 3.8.x, that works for you).
> >
> > But my first guess is a change in aggregator behaviour (pre 3.9.0 it was
> > 

Re: Test problem at head: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.1.1:unpack (unpack-classes) on project plexus-utils: Artifact has not been packaged yet.

[Elliotte Rusty Harold]

On Sat, Feb 25, 2023 at 11:46 AM Guillaume Nodet  wrote:
>
> Which goal are you running ?
> I think you need to run the package phase as hinted by the error.
>


mvn test

also

mvn compile; mvn test
mvn clean test
mvn package; mvn test

All end with the same failure. This seems to be a regression in 4.0. I
don't see this on the 3.9.x branch.

-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] New goal for install/deploy plugin?

[Tamás Cservenák]

I dislike the idea to "toggle logic". This way, we would have 3 mojos with
3 different logic. Is simpler to understand, that invoke same mojo to do
this or that, based on toggle.

T

On Sat, Feb 25, 2023, 13:18 Romain Manni-Bucau 
wrote:

> Hi,
>
> Maybe I missed some details but n unsafe toggle (parameter) to deploy
> sounds like a good compromise to me.
> Too much overlapping goals sounds weird and hard to understand.
>
> Le sam. 25 févr. 2023 à 12:39, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > Here is this thread:
> > https://lists.apache.org/thread/lbbd5n92xjksyf53mlf12togxrvdbvhl
> >
> > In short, user is _partially_ building a module, and invokes
> deploy:deploy,
> > that now fails, as since 3.x version of install/deploy, there is a
> "safety
> > check" in these mojos, to not deploy partially (here it would deploy POM
> > with packaging jar, but the main artifact is NOT built, only a classified
> > one). User opted for this solution as it is "one liner", as deploy-file
> > would require MANY parameters (does not reuse POM values).
> >
> > ===
> >
> > So, what about a new mojo for install/deploy plugins? (symmetrically for
> > both install/deploy plugins, but explaining on case of deploy)
> >
> > deploy:deploy -- unchanged, works as today: "deploy project" and enforces
> > repository hygiene, fails if POM refers to main artifact that is not
> > present
> > deploy:deploy-file -- unchanged, works as today, "deploy file" and
> neglects
> > exiting POM and requires MANY parameters
> >
> > and a new goal:
> > deploy:deploy-artifacts -- this is a "mesh" between two above but would
> > NEVER deploy POM. What this goal would essentially do, is "just blindly"
> > deploy any (packaged) artifact (main or attached/classified) but would
> NOT
> > deploy a POM. Even if one classified artifact is present, it would deploy
> > it. It MAY fail if invoked and the project has NOTHING to deploy. So,
> like
> > deploy-file but needs a project (to reuse coordinates from it)
> >
> > Related issues:
> > https://issues.apache.org/jira/browse/MDEPLOY-205
> > https://issues.apache.org/jira/browse/MINSTALL-118
> >
> > WDYT?
> > Tamas
> >
>

Re: [DISCUSS] New goal for install/deploy plugin?

[Romain Manni-Bucau]

Hi,

Maybe I missed some details but n unsafe toggle (parameter) to deploy
sounds like a good compromise to me.
Too much overlapping goals sounds weird and hard to understand.

Le sam. 25 févr. 2023 à 12:39, Tamás Cservenák  a
écrit :

> Howdy,
>
> Here is this thread:
> https://lists.apache.org/thread/lbbd5n92xjksyf53mlf12togxrvdbvhl
>
> In short, user is _partially_ building a module, and invokes deploy:deploy,
> that now fails, as since 3.x version of install/deploy, there is a "safety
> check" in these mojos, to not deploy partially (here it would deploy POM
> with packaging jar, but the main artifact is NOT built, only a classified
> one). User opted for this solution as it is "one liner", as deploy-file
> would require MANY parameters (does not reuse POM values).
>
> ===
>
> So, what about a new mojo for install/deploy plugins? (symmetrically for
> both install/deploy plugins, but explaining on case of deploy)
>
> deploy:deploy -- unchanged, works as today: "deploy project" and enforces
> repository hygiene, fails if POM refers to main artifact that is not
> present
> deploy:deploy-file -- unchanged, works as today, "deploy file" and neglects
> exiting POM and requires MANY parameters
>
> and a new goal:
> deploy:deploy-artifacts -- this is a "mesh" between two above but would
> NEVER deploy POM. What this goal would essentially do, is "just blindly"
> deploy any (packaged) artifact (main or attached/classified) but would NOT
> deploy a POM. Even if one classified artifact is present, it would deploy
> it. It MAY fail if invoked and the project has NOTHING to deploy. So, like
> deploy-file but needs a project (to reuse coordinates from it)
>
> Related issues:
> https://issues.apache.org/jira/browse/MDEPLOY-205
> https://issues.apache.org/jira/browse/MINSTALL-118
>
> WDYT?
> Tamas
>

Re: Test problem at head: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.1.1:unpack (unpack-classes) on project plexus-utils: Artifact has not been packaged yet.

[Guillaume Nodet]

Which goal are you running ?
I think you need to run the package phase as hinted by the error.

Le sam. 25 févr. 2023 à 07:58, Elliotte Rusty Harold  a
écrit :

> FYI, maven core tests fail for me (Java 1.8. Maven 3.8.7) when
> building at head like so. I'm not sure what to do about this:
>
> [INFO] Unpacking
>
> /Users/elharo/.m2/repository/org/codehaus/plexus/plexus-utils/3.5.0/plexus-utils-3.5.0.jar
> to /Users/elharo/maven/plexus-utils/target/classes with includes
> "**/*.class,**/*.xml" and excludes
>
> "org/codehaus/plexus/util/xml/Xpp3Dom.class,org/codehaus/plexus/util/xml/Xpp3DomBuilder.class"
> [INFO] Unpacking /Users/elharo/maven/api/maven-api-xml/target/classes
> to /Users/elharo/maven/plexus-utils/target/classes with includes
> "**/*" and excludes ""
> [INFO]
> 
> [INFO] Reactor Summary for Apache Maven 4.0.0-alpha-5-SNAPSHOT:
> [INFO]
> [INFO] Maven Dependencies BOM . SUCCESS [
> 1.726 s]
> [INFO] Apache Maven ... SUCCESS [
> 1.455 s]
> [INFO] Maven 4 API  SUCCESS [
> 0.089 s]
> [INFO] Maven 4 API Meta annotations ... SUCCESS [
> 0.382 s]
> [INFO] Maven 4 API XML  SUCCESS [
> 0.375 s]
> [INFO] Maven 4 API :: Model ... SUCCESS [
> 0.774 s]
> [INFO] Implementation of Maven API XML  SUCCESS [
> 2.186 s]
> [INFO] Maven Model  SUCCESS [
> 2.226 s]
> [INFO] Apache Maven Plexus-Utils .. FAILURE [
> 0.660 s]
> [INFO] Maven Artifact . SKIPPED
> [INFO] Maven Plugin API ... SKIPPED
> [INFO] Maven Builder Support .. SKIPPED
> [INFO] Maven Model XML Transform .. SKIPPED
> [INFO] Maven Model Builder  SKIPPED
> [INFO] Maven 4 API :: Settings  SKIPPED
> [INFO] Maven 4 API :: Toolchain ... SKIPPED
> [INFO] Maven 4 API :: Core  SKIPPED
> [INFO] Maven Settings . SKIPPED
> [INFO] Maven Settings Builder . SKIPPED
> [INFO] Maven Toolchain Model .. SKIPPED
> [INFO] Maven Toolchain Builder  SKIPPED
> [INFO] Maven Repository Metadata Model  SKIPPED
> [INFO] Maven Artifact Resolver Provider ... SKIPPED
> [INFO] Maven Core . SKIPPED
> [INFO] Maven SLF4J Wrapper  SKIPPED
> [INFO] Maven SLF4J Simple Provider  SKIPPED
> [INFO] Maven Embedder . SKIPPED
> [INFO] Maven Compat ... SKIPPED
> [INFO] Apache Maven Distribution .. SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  10.121 s
> [INFO] Finished at: 2023-02-25T01:50:54-05:00
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.1:unpack
> (unpack-classes) on project plexus-utils: Artifact has not been
> packaged yet. When used on reactor artifact, unpack should be executed
> after packaging: see MDEP-98. -> [Help 1]
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 

Guillaume Nodet

[DISCUSS] New goal for install/deploy plugin?

[Tamás Cservenák]

Howdy,

Here is this thread:
https://lists.apache.org/thread/lbbd5n92xjksyf53mlf12togxrvdbvhl

In short, user is _partially_ building a module, and invokes deploy:deploy,
that now fails, as since 3.x version of install/deploy, there is a "safety
check" in these mojos, to not deploy partially (here it would deploy POM
with packaging jar, but the main artifact is NOT built, only a classified
one). User opted for this solution as it is "one liner", as deploy-file
would require MANY parameters (does not reuse POM values).

===

So, what about a new mojo for install/deploy plugins? (symmetrically for
both install/deploy plugins, but explaining on case of deploy)

deploy:deploy -- unchanged, works as today: "deploy project" and enforces
repository hygiene, fails if POM refers to main artifact that is not present
deploy:deploy-file -- unchanged, works as today, "deploy file" and neglects
exiting POM and requires MANY parameters

and a new goal:
deploy:deploy-artifacts -- this is a "mesh" between two above but would
NEVER deploy POM. What this goal would essentially do, is "just blindly"
deploy any (packaged) artifact (main or attached/classified) but would NOT
deploy a POM. Even if one classified artifact is present, it would deploy
it. It MAY fail if invoked and the project has NOTHING to deploy. So, like
deploy-file but needs a project (to reuse coordinates from it)

Related issues:
https://issues.apache.org/jira/browse/MDEPLOY-205
https://issues.apache.org/jira/browse/MINSTALL-118

WDYT?
Tamas