Agree not sure why such "marketing buzz around this" as the idea is to
share artifacts so they need to be installed or deployed.
The only issue I can see with install vs verify is the compilation of
everything all the time.
because m-compiler-p detects a new artifact of a module in the reactor
and
Howdy,
So, here is "stage No1" that pretty much already delivers what existing
site had:
https://github.com/jaxen-xpath/jaxen/pull/145
Point is: before, it was two runs to build and site (and took a total of 2
minutes), while now it is 10 seconds more than "build artifacts" (35 sec).
To build it
Howdy,
I am pretty much convinced it can do all that site is able to do.
Let's see the jaxen conversion result once done.
Also, this would not push anything, I always wrote (at least intended to)
"static site tool is left at discretion of user", I just mentioned JBake as
something that can buy ou
Please do NOT consider jbake.
We (shiro team) ported the page to jbake, and it is really a mess.
Many things are not supported which can easily be done in other static
site generators.
There is absolutely no progress. No java.time support. JSON/YAML
support is broken and needs a lot of workarounds.
I don't think would OSGi actually bring much in our case. The goal is to
have maven-core only export a given set of packages to the plugins, with no
libraries at all. Each plugin has its own classloader only importing the
v4 api from maven-core.
Le mer. 16 nov. 2022 à 13:00, Christoph Läubrich
Hi,
Guess classrealm is fine for maven, it does not bring much issues (less
than OSGi or JPMS to be concrete), the real issue is the stability of the
exposed API.
Thanks the hard work Guillaume did on that for maven 4 I guess it is mainly
a matter of deciding what we do for maven 3.
Due to the res
That page is part of "admin" bits, so Olivier pasted wrong one, here is the
correct one:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20fixVersion%20%3D%20maven-dependency-tree-3.2.1
On Wed, Nov 16, 2022 at 1:11 PM Elliotte Rusty Harold
wrote:
> "Sorry, you can't view
Howdy,
I am pretty much sure your site could be pretty much "transported" to use
jbake-maven-plugin instead of maven-site-plugin.
I am aware of the long history of the Maven project, being here since 2006,
but still...
I don't think what I propose is "build a lamborghini instead of a ford
pickup"
"Sorry, you can't view this page
This page is only available to Jira Software users. If you think you
should be a Jira Software user, you should ask your administrator to
give you application access to Jira Software."
Is something misconfigured in Jira? I shouldn't have to be logged in
to see thi
I like some parts of this. I don't agree with others. I agree that
maven site isn't competitive with other site builders, but that was
never really its purpose. I think it's OK for generating a site for a
Maven project. I wouldn't expect it to be used for anything else. As a
maintainer of one such
If you really like to separate API and get out of the ClassRealm-Hell
OSGi would be much more suitable:
https://issues.apache.org/jira/browse/MNG-7518
Am 16.11.22 um 12:30 schrieb Gary Gregory:
As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11 and
adopt JPMS to better def
Maybe Maven 5, as if we do it in 4, we would break the whole world :)
Maven 4 will provide API, but will also keep "backward compat" to Maven 3,
kinda offer "transition time" for the plugins from 3 to 4. Maven 2
compatibility is out of scope naturally.
So with initial Maven 4 releases, plugins shou
As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11 and
adopt JPMS to better define its public APIs.
Gary
On Wed, Nov 16, 2022, 05:06 Tamás Cservenák wrote:
> Yes, to define rules is quite easy, but to make our users to obey them is
> tricky :D
>
> In general, I guess, we sh
On 2022/11/16 10:04:36 Tamás Cservenák wrote:
...
> In general, I guess, we should. For this reason JapiCmp has been used in
> Resolver since 1.9.0 (as noted on refd page end).
I added https://issues.apache.org/jira/browse/MNG-7598 to track that. Currently
we did a poor job when this was intend
Howdy,
This is really just a brainstorming thread I'd like to spin, regarding
Maven Site stuff.
Again, the message is in wiki
https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site
But I would like to make discussion happen here on dev ML.
Thanks
T
Yes, to define rules is quite easy, but to make our users to obey them is
tricky :D
In general, I guess, we should. For this reason JapiCmp has been used in
Resolver since 1.9.0 (as noted on refd page end).
But while this was "kinda simple" to achieve in Resolver, I am really
unsure if it is doab
I guess this is the easy part, the tricky question remains: Do we need to make
sure that all Maven 3 API interfaces/classes stay 100% backwards compatible
until we reach 4.100/5.0/whatever?
This wasn't handled consistently in master till now, e.g. the classes generated
from
https://github.com/
Addendum:
1, we did discuss this Resolver 1.9.1 page with @Guillaume Nodet
and we agreed it has to change. Resolver was always
using these Javadoc tags to mark the intent, but we should switch to
annotations (Resolver predates Java5). This implies we'd need some
"maven-really-shared-tooling" stuff
Unsure we want to deprecate all of Maven :)
But yes, in general, 3.x "Maven API" was "all that users can grab" sadly,
and is probably our major source of problems and reason we started Maven 4
API.
IMO, I'd consider them as "whole", and just say "starting with Maven
4.100/5.0/whatever" the maven-
I see now there is already
https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
but to me the javadoc is not explicit enough. It should state: Only Maven is
allowed to implement/extend types with this annotation.
Konrad
On
Hi,
Unfortunately Maven 3 didn’t define a proper API. In effect everything somehow
exposed through class loaders was considered API by plugin/extension developers.
For Maven 4 a completely separate API was established in package
“org.apache.maven.api”, but what about the old packages used and exp
Please also update documentation sites:
https://maven.apache.org/pom-archives/asf-LATEST/
https://maven.apache.org/pom-archives/maven-LATEST/
https://maven.apache.org/shared-archives/maven-shared-resources-LATEST/
wt., 15 lis 2022 o 10:18 Guillaume Nodet napisał(a):
> I've staged a few release
+1
śr., 16 lis 2022 o 03:05 Olivier Lamy napisał(a):
> Hi,
> I'd like to release Maven Dependency Tree 3.2.1
> We made one enhancement
> https://issues.apache.org/jira/projects/MSHARED/versions/12352234
>
> Staging repository
> https://repository.apache.org/content/repositories/maven-1826/
>
> s
One note about:
> Note: this dependency in test scope is "acceptable" and actually
required by some testing frameworks (see below).
I think it is actually *not* acceptable and will cause confusions and
there are already some work going on not requiring it anymore, so
probably this can be upd
+1
pon., 14 lis 2022 o 15:25 Tamás Cservenák napisał(a):
> Howdy,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.1
>
> There are still some issues in JIRA:
> https://issues.apache.org/jira/projects/MRESOLVER/issues
Howdy,
Recently we had several queries about testing Maven Plugins, but in
general I think we should make plugin developers aware of incoming changes.
Hence, I assembled the following wiki page, that may become Maven Site page
as well, and (irrelevant is it becoming site page or not) probably shou
26 matches
Mail list logo
