On Fri, Feb 14, 2020 at 8:11 AM Hervé BOUTEMY wrote:
> on that precise case ("commons" instead of "org.apache.commons"), it's
> from
> past Maven 1 repository format time.
>
> then such case is not added to Central for years, only projects that
> existed
> at early Maven 1 repository time (like j
on that precise case ("commons" instead of "org.apache.commons"), it's from
past Maven 1 repository format time.
then such case is not added to Central for years, only projects that existed
at early Maven 1 repository time (like junit, for example or other commons)
have such names: it's up to e
On Fri, Feb 14, 2020 at 6:37 AM Manfred Moser
wrote:
> From the very start of the work on the module system and throughout the
> work people from the Maven project have been involved.
>
> There was never a willingness to create any sort of enforcement.. only a
> request to the community to do the
>From the very start of the work on the module system and throughout the work
>people from the Maven project have been involved.
There was never a willingness to create any sort of enforcement.. only a
request to the community to do the right thing
>From my point of view the Maven project can n
Java modules is going to compound this problem we already have. If
projects can't get on board with correctly structuring their
GroupID/Artifacts then why would they use good naming conventions for the
Modules? Without good naming conventions, the risk of collisions
increases. Manfred's referenc
Agreed ... which is why no one ever went down that road in the last decade...
Sander Verhagen wrote on 2020-02-13 19:35 (GMT -08:00):
> Hi, y'all. (Disclaimer: I may not completely understand you're proposing.) I
> wonder what problem you are really trying to solve. People by now have lost
> th
Ownership of established GAVs and assignment of new ones is all managed by
Sonatype as part of the onboarding to OSSRH.
>From all I know there is no policy for changes.. its entirely up to the
>projects.
Maybe Brian or Joel or someone else who is still with Sonatype can chime in.
Also.. fyi t
Hi, y'all. (Disclaimer: I may not completely understand you're proposing.) I
wonder what problem you are really trying to solve. People by now have lost the
absolute expectation that the groupId is authoritative or certified in any way.
And the way that projects get moved between owners, without
Is there any kind of planned timeline to force compliance against old
projects?
For example:
- Force compliance
- Provide symlinks for backwards compatibility for a limited period of
time (1 year)
- Update Maven clients to provide warnings for symlinks during
builds/tests/etc
On
This is a left over from bad choices made decades ago. Now Maven Central has
well documented criteria ... very contrary to nearly all other binary repos..
https://central.sonatype.org/pages/ossrh-guide.html
https://central.sonatype.org/pages/requirements.html#correct-coordinates
And the video
I have been growing concerned about the process of allowing the creation of
GroupIDs, within the Maven Central repository, which do not adhere to the
naming guidelines. i.e. the GroupID must belong to a unique domain name
controlled by the project owner.
Even within the Apache family, there is no
All good thanks!
On Fri, 14 Feb 2020 at 08:14, Hervé BOUTEMY wrote:
> is it better now?
> :)
>
> it seems I forgot to push tags for this component 3 years ago, when doing
> the
> Git migration. Since I did not delete my local migration repository, I
> just
> pushed the tags
>
> I still have ever
is it better now?
:)
it seems I forgot to push tags for this component 3 years ago, when doing the
Git migration. Since I did not delete my local migration repository, I just
pushed the tags
I still have everything locally, then if you find any other component where I
forgot the tags, I can pu
Hi,
We solved 9 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230&version=12346541&styleName=Text
Staging repo:
https://repository.apache.org/content/repositories/maven-1551/
https://repository.apache.org/content/repositories/maven-1551/org/apache/maven/doxia/dox
The Apache Maven team is pleased to announce the release of the Apache Maven
Shade Plugin, version 3.2.2
This plugin provides the capability to package the artifact in an uber-jar,
including its dependencies and to shade - i.e. rename - the packages of some of
the dependencies.
https://maven
AFAIK these files are partly generated. Might be better to improve it there.
Robert
On 13-2-2020 07:29:46, Christofer Dutz wrote:
Hi all,
would it also be possible for some sort of official statement that when copying
the maven wrapper scripts (For Apache Projects), this doesn't explicitly have
Chris,
IANAL but I dont think we can make such a claim ... even though there is not
much to the code and scripts ... its still an Apache project and code of it..
Manfred
Christofer Dutz wrote on 2020-02-12 22:29 (GMT -08:00):
> Hi all,
>
> would it also be possible for some sort of official
I have maintained the wrapper in a separate repo the last couple of years. In
my opinion the wrapper should
automatically default to the latest release of Maven, but allow configuration
to use older versions.
Of course that comes with the usual claim that there is no such thing as
support for
Hi
I cannot find any tag in github for maven-filtering component
https://github.com/apache/maven-filtering/releases
Any idea?
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
19 matches
Mail list logo
