Hervé,
I've created https://github.com/apache/maven-archetypes/pull/6. The
existing documentation doesn't mention versions apart from the archetypes',
did you want something about that added to the site page? And should I
reference a Jira ticket? This isn't a code change, but it's not a doc-only
ch
dependabot[bot] opened a new pull request #51:
URL: https://github.com/apache/maven-doxia/pull/51
Bumps commons-io from 2.6 to 2.8.0.
[
* I wondered whether we should actually remove these
bertysentry opened a new pull request #34:
URL: https://github.com/apache/maven-site-plugin/pull/34
* Fixed integration tests for **doxia-formats* wrt fenced code blocks
* Upgraded to Doxia 1.10-SNAPSHOT
This is an automat
Le dim. 3 janv. 2021 à 19:04, Robert Scholte a
écrit :
> I don't remember all those details anymore, because I hit those in the
> beginning.
> Trying things over and over again I decided that this is probably the most
> successful approach.
>
>
> What of the goals was to keep the pom.xml as is as
I don't remember all those details anymore, because I hit those in the
beginning.
Trying things over and over again I decided that this is probably the most
successful approach.
What of the goals was to keep the pom.xml as is as much as possible.
We can only decide for the specific Maven elemen
yes, providing a PR would help: I intent do release archetypes soon
I don't know what's the best choice to do
but IMHO there may some explanations to put to the documentation page or the
archetype
https://maven.apache.org/archetypes/maven-archetype-webapp/
Regards,
Hervé
Le dimanche 3 janvier
The Maven team is pleased to announce the release of the Apache Maven EAR
Plugin, version 3.2.0
This plugin generates a J2EE Enterprise Archive (EAR) file.
https://maven.apache.org/plugins/maven-ear-plugin/
You should specify the version in your project's plugin configuration:
org.apache.ma
Le dim. 3 janv. 2021 à 16:18, Robert Scholte a
écrit :
> > So what I was expecting was: raw xml model -> converted to unified
> consumed model -> extensions -> model processing.
>
> This is only the build pom part. You're missing the consume part, where
> the xml is distributed.
>
Yes but with p
> So what I was expecting was: raw xml model -> converted to unified consumed
>model -> extensions -> model processing.
This is only the build pom part. You're missing the consume part, where the xml
is distributed.
Build is raw + enrich, consumer is raw + enrich + reduce (removing relativePath
Hi all,
I kind of join Matthieu thoughts there, there is no point to work at xml
level to create the consumed pom - comments is not a point since it can
commonly/easily refer to a dropped part of the pom so they should be
stripped.
Current extension model got proven adapted and adopted, using a lo
Hi Matthieu,
As you understand, something had to be changed to move Maven forward.
I've decided to pick up that challenge and came up with the current solution.
My main concerns was that I wanted to keep the fileModel as much as is.
That includes the license, comments and element order.
This inf
Hi,
The vote has passed with the following result:
+1 : Michael Osipov, Sylwester Lachiewicz, Elliotte Rusty Harold, Hervé
Boutemy, Olivier Lamy
PMC quorum reached
I will promote the artifacts to the central repo.
-
To unsu
Thanks Robert for the video link.
I fully understand the rationales behind the separation of
build/consumer pom and the video provides some insights on it and you
explain the actual implementation to introduce this change.
Still I do not fully understand why it was decided to work on top of XML by
16 matches
Mail list logo
