Re: Publishing to Maven Central and non-OSS plugin dependencies

[Manfred Moser]

The documentation for publishing to Central is very comprehensive. I 
suggest you take a closer look. Specifically


https://central.sonatype.org/register/central-portal/

https://central.sonatype.org/publish/producer-terms/

https://repo1.maven.org/terms.html

And maybe contact a lawyer and Sonatype if unclear.

Manfred


On 2/29/2024 8:44 PM, Stanimir Stamenkov wrote:

Fri, 1 Mar 2024, /Olivier Lamy/:


users will not be able to rebuild from sources.
is it a requirement? No real idea as already said in this thread, you 
need to ask Sonatype.
But it breaks the concept of opensource as you cannot build from the 
sources :)


The sources uploaded to Maven Central are generally not sufficient for 
a rebuild.  They are convenient for debugging and quick look up, 
however one almost always need to go to the project's website, and 
download full sources necessary for a complete build.  The project's 
website could be just a source repository with a top-level README.


I don't think Sonatype has or can have a requirement of "online 
project site available".  There are older artifacts people still rely 
on, that may never be rebuilt because the original sites are long 
gone.  Does it mean they should be removed from Maven Central, for 
example?  I think it should be mainly up to the users to decide 
whether they want to use a particular artifact.


As far as I'm aware there could be Free Open-source and Non-free 
Open-source.  I don't know if complete build instructions are 
requirement for the latter, and Open-source in general?




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

Re: Publishing to Maven Central and non-OSS plugin dependencies

[Stanimir Stamenkov]

Fri, 1 Mar 2024, /Olivier Lamy/:


users will not be able to rebuild from sources.
is it a requirement? No real idea as already said in this thread, you 
need to ask Sonatype.

But it breaks the concept of opensource as you cannot build from the sources :)


The sources uploaded to Maven Central are generally not sufficient for a 
rebuild.  They are convenient for debugging and quick look up, however 
one almost always need to go to the project's website, and download full 
sources necessary for a complete build.  The project's website could be 
just a source repository with a top-level README.


I don't think Sonatype has or can have a requirement of "online project 
site available".  There are older artifacts people still rely on, that 
may never be rebuilt because the original sites are long gone.  Does it 
mean they should be removed from Maven Central, for example?  I think it 
should be mainly up to the users to decide whether they want to use a 
particular artifact.


As far as I'm aware there could be Free Open-source and Non-free 
Open-source.  I don't know if complete build instructions are 
requirement for the latter, and Open-source in general?


--
Stanimir

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

Re: Publishing to Maven Central and non-OSS plugin dependencies

[Olivier Lamy]

users will not be able to rebuild from sources.
is it a requirement? No real idea as already said in this thread, you
need to ask Sonatype.
But it breaks the concept of opensource as you cannot build from the sources :)

On Fri, 1 Mar 2024 at 02:25, Florent Biville  wrote:
>
> The real plugin is com.mycila:license-maven-plugin
>  and the non-OSS
> dependency brings a bunch of extra resources (authorized licenses,
> headers...).
>
> On Thu, Feb 29, 2024 at 2:14 PM Slawomir Jaranowski 
> wrote:
>
> > I can not fine mentioned plugin at all ...
> > https://repo.maven.apache.org/maven2/com/acme/
> >
> > What does it do ...?
> > Is it needed for the build project?
> > Can it be executed in profile?
> > Can it be replaced by something else ...?
> >
> > I will think about publishing projects which can not be build by outer
> > users, can not be a reproducible build check and so on ...
> >
> > So I would like to not publish something like this...
> >
> >
> >
> > czw., 29 lut 2024 o 13:41 Florent Biville 
> > napisał(a):
> >
> > > Yes, to clarify, our project has something like this:
> > >
> > > 
> > > com.acme.plugin
> > > plugin
> > > 4.2.42
> > > 
> > > 
> > > com.acme.plugin
> > > plugin-dep
> > > 42.4.2
> > > 
> > > 
> > > 
> > >
> > >
> > > On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák 
> > > wrote:
> > >
> > > > Howdy,
> > > >
> > > > You would need to ask Sonatype about that, and check here:
> > > > https://central.sonatype.org/publish/requirements/
> > > >
> > > > IMHO best to ask them about it: IIUC you want to deploy artifacts to
> > > > central that has dependencies not available from Central
> > > > (nor any other public repository?)
> > > >
> > > > Thanks
> > > > T
> > > >
> > > >
> > > >
> > > > On Thu, Feb 29, 2024 at 1:31 PM Florent Biville <
> > > florent.bivi...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I'm working on an open-source project that we want to release to
> > Maven
> > > > > Central in the coming weeks.
> > > > >
> > > > > The project currently includes a plugin dependency that is NOT
> > > > open-source
> > > > > (nor in a public GitHub repository). Is that a blocker for releases
> > to
> > > > > Maven Central? I know it would be for regular dependencies and
> > plugins,
> > > > but
> > > > > I'm not 100% sure about plugin dependencies in particular (although I
> > > > would
> > > > > guess it's the same).
> > > > >
> > > > > Any input would be appreciated,
> > > > >
> > > > > Best regards,
> > > > > Florent
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >

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

Re: problem resolving LATEST dependency in the local repo

[Greg Chabala]

> I recommend using a bot like Dependabot or Renovate to keep dependencies
up-to-date.

This seems a strange recommendation for an Ant user.

Re: problem resolving LATEST dependency in the local repo

[Nils Breunese]

I recommend using a bot like Dependabot or Renovate to keep dependencies 
up-to-date.

Nils.

> Op 29 feb 2024, om 16:05 heeft Tamás Cservenák  het 
> volgende geschreven:
> 
> Correct!
> It says "Maven 3.x no longer supports usage of these metaversions in the
> POM"
> 
> T
> 
> On Thu, Feb 29, 2024 at 4:04 PM Alan Snyder 
> wrote:
> 
>> The Maven 3 compatibility notes page can be read as saying that RELEASE
>> and LATEST are deprecated only for finding plugins, although it can also be
>> read as a general statement.
>> 
>> Which is the correct interpretation?
>> 
>> I quote:
>> 
>> Given the threat of non-reproducible builds imposed by automatic plugin
>> version resolution, this feature is scheduled for removal as far as plugin
>> declarations in the POM are concerned.
>> Internally, Maven 2.x used the special version markers RELEASE and LATEST
>> to support automatic plugin version resolution. These metaversions were
>> also recognized in the  element for a  declaration. For
>> the sake of reproducible builds, Maven 3.x no longer supports usage of
>> these metaversions in the POM. As a result, users will need to replace
>> occurrences of these metaversions with a concrete version.
>> 
>> Source:
>> https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution
>> 
>> I understand the drawbacks of using LATEST and RELEASE, but there are
>> situations where they are useful.
>> 
>> I should have stated explicitly that LATEST is resolved correctly for
>> artifacts in Maven Central.
>> 
>> 
>> 
>>> On Feb 29, 2024, at 12:40 AM, Tamás Cservenák 
>> wrote:
>>> 
>>> Howdy,
>>> 
>>> Yes, the "LATEST" Maven2 version keyword has been phased out in Maven3.
>>> They make builds non reproducible (just like snapshots): as it is a
>> "moving
>>> target".
>>> 
>>> T
>>> 
>>> 
>>> On Thu, Feb 29, 2024, 03:01 Alan Snyder 
>>> wrote:
>>> 
 I have been using the Maven Artifact Resolver Ant Tasks with success,
 except in one situation:
 
 When the artifact exists only in my local repo (with version
>> 1-SNAPSHOT),
 a dependency with version LATEST fails to resolve.
 
 An example of the error message:
 
 Could not collect dependencies: Failed to collect dependencies at
 org.violetlib:nls:jar:LATEST
 
 If I change the dependency to use 1-SNAPSHOT as the version, the
>> resolver
 succeeds.
 
 Is it intentional that a local repo does not support LATEST?
 
 In case it matters, the artifact was installed in the local repo using
>> mvn
 install:install-file.
 
 
 
>> 
>> 


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

Re: Publishing to Maven Central and non-OSS plugin dependencies

[Florent Biville]

The real plugin is com.mycila:license-maven-plugin
 and the non-OSS
dependency brings a bunch of extra resources (authorized licenses,
headers...).

On Thu, Feb 29, 2024 at 2:14 PM Slawomir Jaranowski 
wrote:

> I can not fine mentioned plugin at all ...
> https://repo.maven.apache.org/maven2/com/acme/
>
> What does it do ...?
> Is it needed for the build project?
> Can it be executed in profile?
> Can it be replaced by something else ...?
>
> I will think about publishing projects which can not be build by outer
> users, can not be a reproducible build check and so on ...
>
> So I would like to not publish something like this...
>
>
>
> czw., 29 lut 2024 o 13:41 Florent Biville 
> napisał(a):
>
> > Yes, to clarify, our project has something like this:
> >
> > 
> > com.acme.plugin
> > plugin
> > 4.2.42
> > 
> > 
> > com.acme.plugin
> > plugin-dep
> > 42.4.2
> > 
> > 
> > 
> >
> >
> > On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > You would need to ask Sonatype about that, and check here:
> > > https://central.sonatype.org/publish/requirements/
> > >
> > > IMHO best to ask them about it: IIUC you want to deploy artifacts to
> > > central that has dependencies not available from Central
> > > (nor any other public repository?)
> > >
> > > Thanks
> > > T
> > >
> > >
> > >
> > > On Thu, Feb 29, 2024 at 1:31 PM Florent Biville <
> > florent.bivi...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > I'm working on an open-source project that we want to release to
> Maven
> > > > Central in the coming weeks.
> > > >
> > > > The project currently includes a plugin dependency that is NOT
> > > open-source
> > > > (nor in a public GitHub repository). Is that a blocker for releases
> to
> > > > Maven Central? I know it would be for regular dependencies and
> plugins,
> > > but
> > > > I'm not 100% sure about plugin dependencies in particular (although I
> > > would
> > > > guess it's the same).
> > > >
> > > > Any input would be appreciated,
> > > >
> > > > Best regards,
> > > > Florent
> > > >
> > >
> >
>
>
> --
> Sławomir Jaranowski
>

Re: [VOTE] Require Java 17 for Maven 4

[Michael Bien]

+1 (non-binding; for JDK 17 or 21)

leaving JDK 8 behind is an important step for the java community.

-mbien

On 28.02.24 08:30, Benjamin Marwell wrote:

Hi Maven Devs/Users/Committers and PMC members!

After several discussions on the mailing lists, I would like to
start a vote in favour of setting the minimal Java bytecode target
of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.

This is a procedural majority vote [1*]:
You can also vote with fractions and negative votes are not vetoes.

Please also notice:
* Maven 3 will stay at Java 8 no matter what.
* We may raise Maven 4 to JDK 21 later if we feel like it (depending
on the release date).
   This is not part of this vote.
* The linked PR is not part of this vote (this is not a code vote).
   But you may take a look at it to understand the intended change.

PR: https://github.com/apache/maven/pull/1430

Maven-Parent will not be raised with this vote, the other PR is not
part of this vote.

Please refrain from starting discussions in this thread, but do
include a reasoning on downvotes and feel free to start a new
discussion on the mailing list, or comment on the existing ones.

---

Vote open for 72 hours:

[ ] +1 (set JDK17 min version for Maven 4.x)
[ ] +0
[ ] -1 (please include reasoning)

---

- Ben

[1*]: https://www.apache.org/foundation/voting.html

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




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

Re: problem resolving LATEST dependency in the local repo

[Tamás Cservenák]

Correct!
It says "Maven 3.x no longer supports usage of these metaversions in the
POM"

T

On Thu, Feb 29, 2024 at 4:04 PM Alan Snyder 
wrote:

> The Maven 3 compatibility notes page can be read as saying that RELEASE
> and LATEST are deprecated only for finding plugins, although it can also be
> read as a general statement.
>
> Which is the correct interpretation?
>
> I quote:
>
> Given the threat of non-reproducible builds imposed by automatic plugin
> version resolution, this feature is scheduled for removal as far as plugin
> declarations in the POM are concerned.
> Internally, Maven 2.x used the special version markers RELEASE and LATEST
> to support automatic plugin version resolution. These metaversions were
> also recognized in the  element for a  declaration. For
> the sake of reproducible builds, Maven 3.x no longer supports usage of
> these metaversions in the POM. As a result, users will need to replace
> occurrences of these metaversions with a concrete version.
>
> Source:
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution
>
> I understand the drawbacks of using LATEST and RELEASE, but there are
> situations where they are useful.
>
> I should have stated explicitly that LATEST is resolved correctly for
> artifacts in Maven Central.
>
>
>
> > On Feb 29, 2024, at 12:40 AM, Tamás Cservenák 
> wrote:
> >
> > Howdy,
> >
> > Yes, the "LATEST" Maven2 version keyword has been phased out in Maven3.
> > They make builds non reproducible (just like snapshots): as it is a
> "moving
> > target".
> >
> > T
> >
> >
> > On Thu, Feb 29, 2024, 03:01 Alan Snyder 
> > wrote:
> >
> >> I have been using the Maven Artifact Resolver Ant Tasks with success,
> >> except in one situation:
> >>
> >> When the artifact exists only in my local repo (with version
> 1-SNAPSHOT),
> >> a dependency with version LATEST fails to resolve.
> >>
> >> An example of the error message:
> >>
> >> Could not collect dependencies: Failed to collect dependencies at
> >> org.violetlib:nls:jar:LATEST
> >>
> >> If I change the dependency to use 1-SNAPSHOT as the version, the
> resolver
> >> succeeds.
> >>
> >> Is it intentional that a local repo does not support LATEST?
> >>
> >> In case it matters, the artifact was installed in the local repo using
> mvn
> >> install:install-file.
> >>
> >>
> >>
>
>

Re: problem resolving LATEST dependency in the local repo

[Alan Snyder]

The Maven 3 compatibility notes page can be read as saying that RELEASE and 
LATEST are deprecated only for finding plugins, although it can also be read as 
a general statement.

Which is the correct interpretation?

I quote:

Given the threat of non-reproducible builds imposed by automatic plugin version 
resolution, this feature is scheduled for removal as far as plugin declarations 
in the POM are concerned.
Internally, Maven 2.x used the special version markers RELEASE and LATEST to 
support automatic plugin version resolution. These metaversions were also 
recognized in the  element for a  declaration. For the sake of 
reproducible builds, Maven 3.x no longer supports usage of these metaversions 
in the POM. As a result, users will need to replace occurrences of these 
metaversions with a concrete version.

Source:  
https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution

I understand the drawbacks of using LATEST and RELEASE, but there are 
situations where they are useful.

I should have stated explicitly that LATEST is resolved correctly for artifacts 
in Maven Central.



> On Feb 29, 2024, at 12:40 AM, Tamás Cservenák  wrote:
> 
> Howdy,
> 
> Yes, the "LATEST" Maven2 version keyword has been phased out in Maven3.
> They make builds non reproducible (just like snapshots): as it is a "moving
> target".
> 
> T
> 
> 
> On Thu, Feb 29, 2024, 03:01 Alan Snyder 
> wrote:
> 
>> I have been using the Maven Artifact Resolver Ant Tasks with success,
>> except in one situation:
>> 
>> When the artifact exists only in my local repo (with version 1-SNAPSHOT),
>> a dependency with version LATEST fails to resolve.
>> 
>> An example of the error message:
>> 
>> Could not collect dependencies: Failed to collect dependencies at
>> org.violetlib:nls:jar:LATEST
>> 
>> If I change the dependency to use 1-SNAPSHOT as the version, the resolver
>> succeeds.
>> 
>> Is it intentional that a local repo does not support LATEST?
>> 
>> In case it matters, the artifact was installed in the local repo using mvn
>> install:install-file.
>> 
>> 
>> 

Re: Maven resilience to interrupted install to local repository

[Stanimir Stamenkov]

Thu, 29 Feb 2024, /Tamás Cservenák/:


am not Windows user, but we had several reports about issues, like this one:
https://issues.apache.org/jira/browse/MRESOLVER-372


I see.  Thank you for the reference.

As far as I'm aware, such "access denied" exceptions on Windows are not 
specific to atomic moves.  It could happen one process has opened a file 
for reading, preventing another from overwriting it immediately.  I 
guess such updates need a retry mechanism, at least for the atomic move 
part.




On Thu, Feb 29, 2024 at 1:40 PM Stanimir Stamenkov wrote:

Thu, 29 Feb 2024, /Tamás Cservenák/:


Resolver 1.9.18 uses the temp file technique you describe:
copies to (random) temp file located in the same directory where target 
file is, and then atomically moves the file to its place

(unless OS is windows, for obvious reasons).


Doesn't atomic file move/replace work on Windows?  I'm using 
Files.move() [1] with ATOMIC_MOVE [2] option to achieve the same 
technique on Windows successfully.


[1] 
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/Files.html#move(java.nio.file.Path,java.nio.file.Path,java.nio.file.CopyOption..
.)
[2] 
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/StandardCopyOption.html#ATOMIC_MOVE


--

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

Re: Publishing to Maven Central and non-OSS plugin dependencies

[Slawomir Jaranowski]

I can not fine mentioned plugin at all ...
https://repo.maven.apache.org/maven2/com/acme/

What does it do ...?
Is it needed for the build project?
Can it be executed in profile?
Can it be replaced by something else ...?

I will think about publishing projects which can not be build by outer
users, can not be a reproducible build check and so on ...

So I would like to not publish something like this...



czw., 29 lut 2024 o 13:41 Florent Biville 
napisał(a):

> Yes, to clarify, our project has something like this:
>
> 
> com.acme.plugin
> plugin
> 4.2.42
> 
> 
> com.acme.plugin
> plugin-dep
> 42.4.2
> 
> 
> 
>
>
> On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > You would need to ask Sonatype about that, and check here:
> > https://central.sonatype.org/publish/requirements/
> >
> > IMHO best to ask them about it: IIUC you want to deploy artifacts to
> > central that has dependencies not available from Central
> > (nor any other public repository?)
> >
> > Thanks
> > T
> >
> >
> >
> > On Thu, Feb 29, 2024 at 1:31 PM Florent Biville <
> florent.bivi...@gmail.com
> > >
> > wrote:
> >
> > > Hello,
> > >
> > > I'm working on an open-source project that we want to release to Maven
> > > Central in the coming weeks.
> > >
> > > The project currently includes a plugin dependency that is NOT
> > open-source
> > > (nor in a public GitHub repository). Is that a blocker for releases to
> > > Maven Central? I know it would be for regular dependencies and plugins,
> > but
> > > I'm not 100% sure about plugin dependencies in particular (although I
> > would
> > > guess it's the same).
> > >
> > > Any input would be appreciated,
> > >
> > > Best regards,
> > > Florent
> > >
> >
>


-- 
Sławomir Jaranowski

Re: Publishing to Maven Central and non-OSS plugin dependencies

[Tomo Suzuki]

(I’m just a Maven user)
It seems that, for consuming the artifact, the closed-source plugin seems
not a dependency. I believe it just works fine. Your company’s support team
might get questions like “I tried to build your library myself but the
build failed.”

Maven has a capability to replace pom.xml content when packaging a project.
The flatten Maven plugin uses it
https://www.mojohaus.org/flatten-maven-plugin/
.

Regards,
Tomo


On Thu, Feb 29, 2024 at 07:40 Florent Biville 
wrote:

> Yes, to clarify, our project has something like this:
>
> 
> com.acme.plugin
> plugin
> 4.2.42
> 
> 
> com.acme.plugin
> plugin-dep
> 42.4.2
> 
> 
> 
>
>
> On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > You would need to ask Sonatype about that, and check here:
> > https://central.sonatype.org/publish/requirements/
> >
> > IMHO best to ask them about it: IIUC you want to deploy artifacts to
> > central that has dependencies not available from Central
> > (nor any other public repository?)
> >
> > Thanks
> > T
> >
> >
> >
> > On Thu, Feb 29, 2024 at 1:31 PM Florent Biville <
> florent.bivi...@gmail.com
> > >
> > wrote:
> >
> > > Hello,
> > >
> > > I'm working on an open-source project that we want to release to Maven
> > > Central in the coming weeks.
> > >
> > > The project currently includes a plugin dependency that is NOT
> > open-source
> > > (nor in a public GitHub repository). Is that a blocker for releases to
> > > Maven Central? I know it would be for regular dependencies and plugins,
> > but
> > > I'm not 100% sure about plugin dependencies in particular (although I
> > would
> > > guess it's the same).
> > >
> > > Any input would be appreciated,
> > >
> > > Best regards,
> > > Florent
> > >
> >
>

Re: Maven resilience to interrupted install to local repository

[Tamás Cservenák]

Howdy,

am not Windows user, but we had several reports about issues, like this one:
https://issues.apache.org/jira/browse/MRESOLVER-372

T

On Thu, Feb 29, 2024 at 1:40 PM Stanimir Stamenkov
 wrote:

> Thu, 29 Feb 2024, /Tamás Cservenák/:
>
> > Resolver 1.9.18 uses the temp file technique you describe:
> > copies to (random) temp file located in the same directory where target
> > file is, and then atomically moves the file to its place
> > (unless OS is windows, for obvious reasons).
>
> Doesn't atomic file move/replace work on Windows?  I'm using
> Files.move() [1] with ATOMIC_MOVE [2] option to achieve the same
> technique on Windows successfully.
>
> [1]
>
> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/Files.html#move(java.nio.file.Path,java.nio.file.Path,java.nio.file.CopyOption..
> .)
> [2]
>
> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/StandardCopyOption.html#ATOMIC_MOVE
>
> --
> Stanimir
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Publishing to Maven Central and non-OSS plugin dependencies

[Florent Biville]

Yes, to clarify, our project has something like this:


com.acme.plugin
plugin
4.2.42


com.acme.plugin
plugin-dep
42.4.2





On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák  wrote:

> Howdy,
>
> You would need to ask Sonatype about that, and check here:
> https://central.sonatype.org/publish/requirements/
>
> IMHO best to ask them about it: IIUC you want to deploy artifacts to
> central that has dependencies not available from Central
> (nor any other public repository?)
>
> Thanks
> T
>
>
>
> On Thu, Feb 29, 2024 at 1:31 PM Florent Biville  >
> wrote:
>
> > Hello,
> >
> > I'm working on an open-source project that we want to release to Maven
> > Central in the coming weeks.
> >
> > The project currently includes a plugin dependency that is NOT
> open-source
> > (nor in a public GitHub repository). Is that a blocker for releases to
> > Maven Central? I know it would be for regular dependencies and plugins,
> but
> > I'm not 100% sure about plugin dependencies in particular (although I
> would
> > guess it's the same).
> >
> > Any input would be appreciated,
> >
> > Best regards,
> > Florent
> >
>

Re: Maven resilience to interrupted install to local repository

[Stanimir Stamenkov]

Thu, 29 Feb 2024, /Tamás Cservenák/:


Resolver 1.9.18 uses the temp file technique you describe:
copies to (random) temp file located in the same directory where target 
file is, and then atomically moves the file to its place

(unless OS is windows, for obvious reasons).


Doesn't atomic file move/replace work on Windows?  I'm using 
Files.move() [1] with ATOMIC_MOVE [2] option to achieve the same 
technique on Windows successfully.


[1] 
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/Files.html#move(java.nio.file.Path,java.nio.file.Path,java.nio.file.CopyOption...)
[2] 
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/StandardCopyOption.html#ATOMIC_MOVE


--
Stanimir

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

Re: Publishing to Maven Central and non-OSS plugin dependencies

[Tamás Cservenák]

Howdy,

You would need to ask Sonatype about that, and check here:
https://central.sonatype.org/publish/requirements/

IMHO best to ask them about it: IIUC you want to deploy artifacts to
central that has dependencies not available from Central
(nor any other public repository?)

Thanks
T



On Thu, Feb 29, 2024 at 1:31 PM Florent Biville 
wrote:

> Hello,
>
> I'm working on an open-source project that we want to release to Maven
> Central in the coming weeks.
>
> The project currently includes a plugin dependency that is NOT open-source
> (nor in a public GitHub repository). Is that a blocker for releases to
> Maven Central? I know it would be for regular dependencies and plugins, but
> I'm not 100% sure about plugin dependencies in particular (although I would
> guess it's the same).
>
> Any input would be appreciated,
>
> Best regards,
> Florent
>

Publishing to Maven Central and non-OSS plugin dependencies

[Florent Biville]

Hello,

I'm working on an open-source project that we want to release to Maven
Central in the coming weeks.

The project currently includes a plugin dependency that is NOT open-source
(nor in a public GitHub repository). Is that a blocker for releases to
Maven Central? I know it would be for regular dependencies and plugins, but
I'm not 100% sure about plugin dependencies in particular (although I would
guess it's the same).

Any input would be appreciated,

Best regards,
Florent

Re: Maven resilience to interrupted install to local repository

[Tamás Cservenák]

Resolver 1.9.18 uses the temp file technique you describe:
copies to (random) temp file located in the same directory where target
file is, and then atomically moves the file to its place
(unless OS is windows, for obvious reasons).

T

On Thu, Feb 29, 2024 at 12:17 PM Václav Haisman  wrote:

> Hi.
>
> How resilient is Maven to JVM being killed (K8s POD being killed) while it
> is installing artifact files into a local repository? Does it do the copy
> into a temporary file then rename method or does it copy into the target
> artifact file directly?
>
> --
> VH
>

Re: [VOTE] Require Java 17 for Maven 4

[Van Hoa Phan]

+1

On Wed, Feb 28, 2024 at 6:31 PM Benjamin Marwell 
wrote:

> Hi Maven Devs/Users/Committers and PMC members!
>
> After several discussions on the mailing lists, I would like to
> start a vote in favour of setting the minimal Java bytecode target
> of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.
>
> This is a procedural majority vote [1*]:
> You can also vote with fractions and negative votes are not vetoes.
>
> Please also notice:
> * Maven 3 will stay at Java 8 no matter what.
> * We may raise Maven 4 to JDK 21 later if we feel like it (depending
> on the release date).
>   This is not part of this vote.
> * The linked PR is not part of this vote (this is not a code vote).
>   But you may take a look at it to understand the intended change.
>
> PR: https://github.com/apache/maven/pull/1430
>
> Maven-Parent will not be raised with this vote, the other PR is not
> part of this vote.
>
> Please refrain from starting discussions in this thread, but do
> include a reasoning on downvotes and feel free to start a new
> discussion on the mailing list, or comment on the existing ones.
>
> ---
>
> Vote open for 72 hours:
>
> [ ] +1 (set JDK17 min version for Maven 4.x)
> [ ] +0
> [ ] -1 (please include reasoning)
>
> ---
>
> - Ben
>
> [1*]: https://www.apache.org/foundation/voting.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Maven resilience to interrupted install to local repository

[Václav Haisman]

Hi.

How resilient is Maven to JVM being killed (K8s POD being killed) while it
is installing artifact files into a local repository? Does it do the copy
into a temporary file then rename method or does it copy into the target
artifact file directly?

-- 
VH

Re: [VOTE] Require Java 17 for Maven 4

[Dirk Olmes]

+1 (nonbinding)

On 2/28/24 08:30, Benjamin Marwell wrote:

Hi Maven Devs/Users/Committers and PMC members!

After several discussions on the mailing lists, I would like to
start a vote in favour of setting the minimal Java bytecode target
of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.

This is a procedural majority vote [1*]:
You can also vote with fractions and negative votes are not vetoes.

Please also notice:
* Maven 3 will stay at Java 8 no matter what.
* We may raise Maven 4 to JDK 21 later if we feel like it (depending
on the release date).
   This is not part of this vote.
* The linked PR is not part of this vote (this is not a code vote).
   But you may take a look at it to understand the intended change.

PR: https://github.com/apache/maven/pull/1430

Maven-Parent will not be raised with this vote, the other PR is not
part of this vote.

Please refrain from starting discussions in this thread, but do
include a reasoning on downvotes and feel free to start a new
discussion on the mailing list, or comment on the existing ones.

---

Vote open for 72 hours:

[ ] +1 (set JDK17 min version for Maven 4.x)
[ ] +0
[ ] -1 (please include reasoning)

---

- Ben

[1*]: https://www.apache.org/foundation/voting.html

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




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

Re: problem resolving LATEST dependency in the local repo

[Tamás Cservenák]

Howdy,

Yes, the "LATEST" Maven2 version keyword has been phased out in Maven3.
They make builds non reproducible (just like snapshots): as it is a "moving
target".

T


On Thu, Feb 29, 2024, 03:01 Alan Snyder 
wrote:

> I have been using the Maven Artifact Resolver Ant Tasks with success,
> except in one situation:
>
> When the artifact exists only in my local repo (with version 1-SNAPSHOT),
> a dependency with version LATEST fails to resolve.
>
> An example of the error message:
>
> Could not collect dependencies: Failed to collect dependencies at
> org.violetlib:nls:jar:LATEST
>
> If I change the dependency to use 1-SNAPSHOT as the version, the resolver
> succeeds.
>
> Is it intentional that a local repo does not support LATEST?
>
> In case it matters, the artifact was installed in the local repo using mvn
> install:install-file.
>
>
>

Re: [VOTE] Require Java 17 for Maven 4

[Enrico Olivelli]

+1 (Non binding)

Enrico

Il Gio 29 Feb 2024, 09:01 Tim te Beek  ha scritto:

> +1  from occasional contributor
>
> Would unblock phasing out more utils methods & dependencies.
>
> On Thu, Feb 29, 2024 at 8:53 AM Thomas Matthijs  wrote:
>
> > +1
> >
> >
> > On Wed, Feb 28, 2024, at 08:30, Benjamin Marwell wrote:
> > > Hi Maven Devs/Users/Committers and PMC members!
> > >
> > > After several discussions on the mailing lists, I would like to
> > > start a vote in favour of setting the minimal Java bytecode target
> > > of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.
> > >
> > > This is a procedural majority vote [1*]:
> > > You can also vote with fractions and negative votes are not vetoes.
> > >
> > > Please also notice:
> > > * Maven 3 will stay at Java 8 no matter what.
> > > * We may raise Maven 4 to JDK 21 later if we feel like it (depending
> > > on the release date).
> > >   This is not part of this vote.
> > > * The linked PR is not part of this vote (this is not a code vote).
> > >   But you may take a look at it to understand the intended change.
> > >
> > > PR: https://github.com/apache/maven/pull/1430
> > >
> > > Maven-Parent will not be raised with this vote, the other PR is not
> > > part of this vote.
> > >
> > > Please refrain from starting discussions in this thread, but do
> > > include a reasoning on downvotes and feel free to start a new
> > > discussion on the mailing list, or comment on the existing ones.
> > >
> > > ---
> > >
> > > Vote open for 72 hours:
> > >
> > > [ ] +1 (set JDK17 min version for Maven 4.x)
> > > [ ] +0
> > > [ ] -1 (please include reasoning)
> > >
> > > ---
> > >
> > > - Ben
> > >
> > > [1*]: https://www.apache.org/foundation/voting.html
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>