philsttr opened a new pull request #223:
URL: https://github.com/apache/maven-site/pull/223
Suggested by @michael-o via
https://github.com/apache/maven-deploy-plugin/pull/15#issuecomment-750933613
This is an automated messag
bertysentry opened a new pull request #49:
URL: https://github.com/apache/maven-doxia/pull/49
Broad update to **doxia-module-markdown**
* Properly exposed language class in fenced code blocks
* Re-implemented metadata processing
* Added unit tests
* Added integration tests (w
slawekjaranowski commented on a change in pull request #222:
URL: https://github.com/apache/maven-site/pull/222#discussion_r549502187
##
File path: content/resources/developers/maven-idea-codestyle.xml
##
@@ -16,186 +16,49 @@ KIND, either express or implied. See the License fo
elharo commented on a change in pull request #222:
URL: https://github.com/apache/maven-site/pull/222#discussion_r549498982
##
File path: content/resources/developers/maven-idea-codestyle.xml
##
@@ -16,186 +16,49 @@ KIND, either express or implied. See the License for the
spe
sparsick commented on pull request #222:
URL: https://github.com/apache/maven-site/pull/222#issuecomment-751847950
@slawekjaranowski Thanks for reviewing
This is an automated message from the Apache Git Service.
To respond to
slawekjaranowski commented on a change in pull request #222:
URL: https://github.com/apache/maven-site/pull/222#discussion_r549464651
##
File path: content/resources/developers/maven-idea-codestyle.xml
##
@@ -216,17 +79,34 @@ under the License.
+
+
+
michael-o commented on a change in pull request #191:
URL: https://github.com/apache/maven-site/pull/191#discussion_r549468517
##
File path:
content/apt/guides/introduction/introduction-to-dependency-mechanism.apt
##
@@ -174,9 +174,10 @@ Introduction to the Dependency Mechanis
mthmulders commented on pull request #222:
URL: https://github.com/apache/maven-site/pull/222#issuecomment-751827068
I don't know what the current style guidelines are, so I cannot really
review. But I'm definitely +1 for maintaining it in configuration files so we
can all easily conform t
>> Regarding javax: No, this was not the free decision of the Jakarta EE WG,
>> this was the SOLE CHOICE we had due to Oracle, as they forbid ALL changes
>> to the javax namespace, so the were FORCED to rename the workspace. Believe
>> me, nobody in the Jakarta EE WG thought that this is a good ide
Hi community,
Are there any plans about release of 3.2.0 version of Maven EAR Plugin?
It feels like there are no incomplete / blocking tasks in the issue tracker
- refer to
https://issues.apache.org/jira/projects/MEAR/issues?filter=allopenissuesonly
where only
improvements, new feature
Le lun. 28 déc. 2020 à 17:53, Markus KARG a écrit :
> Regarding javax: No, this was not the free decision of the Jakarta EE WG,
> this was the SOLE CHOICE we had due to Oracle, as they forbid ALL changes
> to the javax namespace, so the were FORCED to rename the workspace. Believe
> me, nobody in
Hi all,
I started a Github repository [1], where I will collect my lessons
learned. Contribution is welcome.
Regards,
Sandra
[1] https://github.com/sparsick/maven-contribution-newbie
Am 23.12.20 um 12:29 schrieb Sandra Parsick:
>
>> welcome in the Maven dev community!
>
> Thank you :)
>
>>
Regarding javax: No, this was not the free decision of the Jakarta EE WG, this
was the SOLE CHOICE we had due to Oracle, as they forbid ALL changes to the
javax namespace, so the were FORCED to rename the workspace. Believe me, nobody
in the Jakarta EE WG thought that this is a good idea, but we
> I am aware of editor-config, but it has one huge problem: you cannot refer to
> a centralized file.
> This means that IF we would use them, we need to keep them in sync for all
> ~100 repositories, which is a big no for me.
I understand your rejection. I solved this problem in one of my projec
Le lun. 28 déc. 2020 à 16:44, Markus KARG a écrit :
> I don't like the idea of simply keeping javax "and period" as it looks
> like us not moving forward, since people will learn about the history and
> future of that namespace; it is just NOT ours but that of Oracle / JCP /
> EF. We can keep it,
sparsick opened a new pull request #222:
URL: https://github.com/apache/maven-site/pull/222
This setting file was created by importing checkstyle settings in idea. Then
I compared it with @bmarwell self-created Intellji setting file for Maven
projects and add his XML code settings.
-
I don't like the idea of simply keeping javax "and period" as it looks like us
not moving forward, since people will learn about the history and future of
that namespace; it is just NOT ours but that of Oracle / JCP / EF. We can keep
it, but we definitively should add jakarta as an alternative.
We can also freeze it, jsr330 never moved and will likely never move (since
it is the most of the overlapping of underlying vendors) so guess moving to
jakarta will not halp anything - can only hurt us actually by creating a
new gap or another "cdi-api" issue - and moving to org.apache.maven will
r
With "dead" I mean: Nobody is allowed to add anything new in that namespace
-- neither classes nor interfaces nor even new parameters.
I would like that Maven 4 accepts both (old and new namespace).
-Markus
-Ursprüngliche Nachricht-
Von: Michael Osipov [mailto:micha...@apache.org]
Ge
If you think about such a change - Maven 4 should support both namespaces
with warning about deprecating javax.inject.
In this way developers will have more time and possibility to switch their
plugins/extensions to new namespaces.
Finally Maven 5 can support only new namespaces.
pon., 28 gru 2020
I agree javax will stay for years and doing any breaking change today would
just be bad for end users, that said we can already encourage plugins to
not use it and log a warning in maven plugin plugin.
For maven core we don't care much since we can change it when we want, it
will just impact extens
Am 2020-12-28 um 14:56 schrieb Markus KARG:
We are used to "import javax.inject.*" in Maven, but that namespace if dead
since Jakarta EE 9. Since November the new namespace is released "import
jakarta.inject.*". I wonder if Maven 4 really still wants to stick with the
dead namespace instead, or w
We are used to "import javax.inject.*" in Maven, but that namespace if dead
since Jakarta EE 9. Since November the new namespace is released "import
jakarta.inject.*". I wonder if Maven 4 really still wants to stick with the
dead namespace instead, or whether it makes sense that we adopt the new
na
I understand your concerns (had the same situation), and really would ask the
PMC to find a solution for that long delays. My motto is "release early,
release often" but at Apache this seems to be not wanted or not possile. :-(
Let's do it this way: We incubate the plugin until we think it is ri
I'm really open to help developing / maintaining such a plugin under Apache
Organization.
But as we see the release process in Apache is very slow ... I need it now,
and I don't want to wait for years so I decided to release it by myself.
Probably it is another topic how to make Apache projects m
Please turn it into an official Maven plugin, as there are many people out
there reluctant when it comes to third party due to sustained support etc.! :-)
-Markus
-Ursprüngliche Nachricht-
Von: Slawomir Jaranowski [mailto:s.jaranow...@gmail.com]
Gesendet: Montag, 28. Dezember 2020 13:09
Hi,
First version of Sign Maven Plugin was released -
https://github.com/s4u/sign-maven-plugin
It works with Maven 3.6.x and future version 4.x
If somebody is interested I invite them to test and collaborate.
pon., 14 gru 2020 o 21:42 Slawomir Jaranowski
napisał(a):
> Hi,
>
> The Idea of maki
27 matches
Mail list logo
