Author: svn-site-role Date: Mon Aug 4 12:22:05 2025 New Revision: 1927610 Log: Site checkin for project Apache Maven Site
Modified: maven/website/content/archives/maven-2.x/index.html maven/website/content/archives/maven-2.x/maven-2.1-architectural-goals.html maven/website/content/examples/index.html maven/website/content/examples/injecting-properties-via-settings.html Modified: maven/website/content/archives/maven-2.x/index.html ============================================================================== --- maven/website/content/archives/maven-2.x/index.html Mon Aug 4 12:10:02 2025 (r1927609) +++ maven/website/content/archives/maven-2.x/index.html Mon Aug 4 12:22:05 2025 (r1927610) @@ -2,7 +2,7 @@ <!-- - | Generated by Apache Maven Doxia Site Renderer 2.0.0 from content/apt/archives/maven-2.x/index.apt at 2025-08-04 + | Generated by Apache Maven Doxia Site Renderer 2.0.0 from content/markdown/archives/maven-2.x/index.md at 2025-08-04 | Rendered using Apache Maven Fluido Skin 2.1.0 --> <html xmlns="http://www.w3.org/1999/xhtml"; lang="en"> @@ -10,9 +10,7 @@ <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0" /> - <meta name="author" content="Karl-Heinz Marbaise" /> - <meta name="date" content="2014-03-22" /> - <title>Maven 2 Graveyard – Maven</title> + <title>This is the Maven 2 Graveyard – Maven</title> <link rel="stylesheet" href="../../css/apache-maven-fluido-2.1.0.min.css" /> <link rel="stylesheet" href="../../css/site.css" /> <link rel="stylesheet" href="../../css/print.css" media="print" /> @@ -47,7 +45,7 @@ <ul class="breadcrumb"> <li><a href="https://www.apache.org/";>Apache</a><span class="divider">/</span></li> <li><a href="../../index.html">Maven</a><span class="divider">/</span></li> - <li class="active">Maven 2 Graveyard <a href="https://github.com/apache/maven-site/tree/master/content/apt/archives/maven-2.x/index.apt";><img src="../../images/accessories-text-editor.png" alt="Edit" /></a></li> + <li class="active">This is the Maven 2 Graveyard <a href="https://github.com/apache/maven-site/tree/master/content/markdown/archives/maven-2.x/index.md";><img src="../../images/accessories-text-editor.png" alt="Edit" /></a></li> <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2025-08-04</li> <li class="pull-right"><span class="divider">|</span> <a href="../../scm.html">Get Sources</a></li> @@ -133,34 +131,51 @@ </div> </header> <main id="bodyColumn" class="span10"> +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + +http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> <section><a id="This_is_the_Maven_2_Graveyard"></a> <h1>This is the Maven 2 Graveyard</h1> <p>Based on a decision for the End Of Lifetime of Maven 2 this location is intended as a graveyard for Maven 2 only related information and links.</p><section><a id="Plugin_List"></a> <h2>Plugin List</h2> <p>The following list of plugins contains plugins which are Maven 2 specific. Apart from that for those plugins which are listed here there are no updates/bug fixes planned etc.</p> -<table class="table table-bordered table-striped"> +<table class="table table-striped"> +<thead> <tr class="a"> -<th><b>Plugin</b></th> -<th><b>Type*</b></th> -<th><b>Version</b></th> -<th><b>Last Release Date</b></th> -<th><b>Description</b></th> -<th><b>Date of Funeral</b></th></tr> +<th><strong>Plugin</strong></th> +<th><strong>Type</strong>*</th> +<th><strong>Version</strong></th> +<th><strong>Last Release Date</strong></th> +<th><strong>Description</strong></th> +<th><strong>Date of Funeral</strong></th></tr></thead><tbody> <tr class="b"> -<td style="text-align: left;"><b>Core plugins</b></td> -<td style="text-align: left;"></td> -<td style="text-align: left;"></td> -<td style="text-align: left;"></td> -<td style="text-align: left;"><b>Plugins corresponding to default core phases (ie. clean, compile). They may have multiple goals as well.</b></td> -<td style="text-align: left;"></td></tr> +<td colspan="4"><strong>Core plugins</strong></td> +<td colspan="2"><strong>Plugins corresponding to default core phases (ie. clean, compile). They may have multiple goals as well.</strong></td></tr> <tr class="a"> -<td style="text-align: left;"><a href="/plugins/maven-reactor-plugin/"> <code>reactor</code></a></td> -<td style="text-align: left;">B</td> -<td style="text-align: left;">1.0</td> -<td style="text-align: left;">2008-09-27</td> -<td style="text-align: left;">Build a subset of interdependent projects in a reactor</td> -<td style="text-align: left;">2014-03-24</td></tr></table> -<p>* <b>B</b>uild or <b>R</b>eporting plugin</p></section></section> </main> +<td><a href="/plugins/maven-reactor-plugin/"><code>reactor</code></a></td> +<td>B</td> +<td>1.0</td> +<td>2008-09-27</td> +<td>Build a subset of interdependent projects in a reactor</td> +<td>2014-03-24</td></tr></tbody> +</table> + +<p>* <strong>B</strong>uild or <strong>R</strong>eporting plugin</p></section></section> </main> </div> </div> <hr/> Modified: maven/website/content/archives/maven-2.x/maven-2.1-architectural-goals.html ============================================================================== --- maven/website/content/archives/maven-2.x/maven-2.1-architectural-goals.html Mon Aug 4 12:10:02 2025 (r1927609) +++ maven/website/content/archives/maven-2.x/maven-2.1-architectural-goals.html Mon Aug 4 12:22:05 2025 (r1927610) @@ -2,7 +2,7 @@ <!-- - | Generated by Apache Maven Doxia Site Renderer 2.0.0 from content/apt/archives/maven-2.x/maven-2.1-architectural-goals.apt at 2025-08-04 + | Generated by Apache Maven Doxia Site Renderer 2.0.0 from content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md at 2025-08-04 | Rendered using Apache Maven Fluido Skin 2.1.0 --> <html xmlns="http://www.w3.org/1999/xhtml"; lang="en"> @@ -10,7 +10,6 @@ <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0" /> - <meta name="author" content="Jason van Zyl" /> <title>Maven 2.1 – Maven</title> <link rel="stylesheet" href="../../css/apache-maven-fluido-2.1.0.min.css" /> <link rel="stylesheet" href="../../css/site.css" /> @@ -46,7 +45,7 @@ <ul class="breadcrumb"> <li><a href="https://www.apache.org/";>Apache</a><span class="divider">/</span></li> <li><a href="../../index.html">Maven</a><span class="divider">/</span></li> - <li class="active">Maven 2.1 <a href="https://github.com/apache/maven-site/tree/master/content/apt/archives/maven-2.x/maven-2.1-architectural-goals.apt";><img src="../../images/accessories-text-editor.png" alt="Edit" /></a></li> + <li class="active">Maven 2.1 <a href="https://github.com/apache/maven-site/tree/master/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md";><img src="../../images/accessories-text-editor.png" alt="Edit" /></a></li> <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2025-08-04</li> <li class="pull-right"><span class="divider">|</span> <a href="../../scm.html">Get Sources</a></li> @@ -132,6 +131,24 @@ </div> </header> <main id="bodyColumn" class="span10"> +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + +http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> <section><a id="Maven_2.1"></a> <h1>Maven 2.1</h1> <p>Discussion: need some answers to these before even pushing this to the list TODO: Jesse and Greg spent a lot of time getting the async SSL working so a little description this work would be useful TODO: architecture document about Mercury transport as the async HTTP/DAV client TODO: example of user facing API for Mercury TODO: architecture document and spec for mercury (largely in the wiki) TODO: example of user facing API for maven-shared-model TODO: architecture document on maven itself, plugin manager, lifecycle executor, profile construction TODO: check with kenney to see if his work survived in substituting components or if it's his work that's actually making it work</p> @@ -145,17 +162,18 @@ <h2>Lifecycle</h2><section><a id="Aggregator_Mojo_Handling"></a> <h3>Aggregator Mojo Handling</h3> <p>Aggregator mojos bound to the lifecycle have been deprecated. This practice can produce some very strange results, and isn't really the right solution for many of the problems it attempts to solve. I'm hoping to include some better options for bracketing the normal build - both before, and after, explicitly - to make aggregator mojos obsolete, but for now they've been deprecated to avoid disrupting backward compatibility.</p> -<p>Also, aggregator mojos that *are* bound to the lifecycle will only be allowed to execute at most once during the build, to limit redundant execution. These mojos are meant to act on all projects in the reactor at once, and binding them to one pom.xml file is dangerous in that it can produce different build results depending on whether that pom.xml is included. This is further complicated if two modules in a reactor configure the same aggregator mojo...in which case, it may run multiple times...or, when the aggregator is configured in the parent pom, where it will run for each descendant module.</p></section></section><section><a id="Plugin_API"></a> +<p>Also, aggregator mojos that <em>are</em> bound to the lifecycle will only be allowed to execute at most once during the build, to limit redundant execution. These mojos are meant to act on all projects in the reactor at once, and binding them to one pom.xml file is dangerous in that it can produce different build results depending on whether that pom.xml is included. This is further complicated if two modules in a reactor configure the same aggregator mojo…in which case, it may run multiple times…or, when the aggregator is configured in the parent pom, where it will run for each descendant module.</p></section></section><section><a id="Plugin_API"></a> <h2>Plugin API</h2><section><a id="Shading_of_plexus-utils_causing_a_ClassCastException_on_plugin.getConfiguration.28.29_.28.5BMNG-3012.7Chttps.3A.2F.2Fissues.apache.org.2Fjira.2Fbrowse.2FMNG-3012.5D.29"></a> <h3>Shading of plexus-utils causing a ClassCastException on plugin.getConfiguration() ([MNG-3012|https://issues.apache.org/jira/browse/MNG-3012])</h3> <p>The fact that plexus-utils is hidden from plugins in the newer releases of Maven means that plugin.getConfiguration() from maven-model can cause a ClassCastException, if used from within a mojo. The plan to fix this is basically just to import Xpp3Dom from the shaded plexus-utils version in maven-core within the plugin's classrealm. This should allow us to share the same instance of that class (only, shouldn't really affect other p-u classes) and preserve backward compatibility for existing plugin releases.</p> <p>comment from kenney: The problem with this is that it's a hack. If xpp3dom/plexus utils is updated and the plugin requires the new xpp3dom class, which has a new method for instance, this will break the plugin.</p> <p>About this specific issue (MNG-3012): The best solution is to only share java., javax., and core maven api classes, so we can no longer export anything outside the plugin api (which includes maven-model, maven-project, maven-settings e.a.). This would require to phase out plugin.getConfiguration() and other model methods that return xpp3dom classes, and let them return interfaces present in the maven core api. Those interfaces would have an implementation class that implements both that interface and extends xpp3dom, which will be hidden for the plugin. Another solution could be to use xmlplexusconfiguration</p> <p>There's one more solution to consider; using ASM to rewrite plugins as they're loaded. We could add code modifiers that workaround incompatibilities by detecting usage patterns, like (Xpp3Dom) plugin.getConfiguration(). An example could be to modify the code to wrap Xpp3DomParser.parse( new StringReader( String.valueOf( /plugin.getConfiguration()/ ) ) ) around the call. This is even more of a hack though. Perhaps a mojo that scans for plugin incompatibilities using ASM is more feasible (no code modification).</p> -<p>So the basic problem we're up against is that there can be core api changes between major versions that pose incompatibilities for plugins written against an older version. The simplest solution would be to let plugins specify the maven versions they work against (which is partly present: <i>requires</i><i>mavenVersion</i>2.0.6<i>/mavenVersion</i><i>/requires</i>. If this field supports a versionrange, or we'd default the version interpretation above to mean [2.0.6,2.1), we can detect plugins that won't run. The shading mentioned above is solving only one incompatibility problem, and there are bound to be more. Maybe we even need 2 versions of a plugin at some point, targeted toward different maven versions, though I'd really like to avoid that. But we cannot just assume our 2.0 plugin api will never change across 'major' (read: minor) releases.</p></section><section><a id="Strategies_for_ensuring_backward_compatibility"></a> +<p>So the basic problem we're up against is that there can be core api changes between major versions that pose incompatibilities for plugins written against an older version. The simplest solution would be to let plugins specify the maven versions they work against (which is partly present: <em>requires__mavenVersion_2.0.6</em>/mavenVersion__/requires_. If this field supports a versionrange, or we'd default the version interpretation above to mean [2.0.6,2.1), we can detect plugins that won't run. The shading mentioned above is solving only one incompatibility problem, and there are bound to be more. Maybe we even need 2 versions of a plugin at some point, targeted toward different maven versions, though I'd really like to avoid that. But we cannot just assume our 2.0 plugin api will never change across ‘major’ (read: minor) releases.</p></section><section><a id="Strategies_for_ensuring_backward_compatibility"></a> <h3>Strategies for ensuring backward compatibility</h3> <p>Plugin integration testing</p> -<pre>jason: so when you and benjamin went through the tests you have "integration-tests" as the standard hook in the plugin build to grab on to? + +<pre><code class="nohighlight nocode">jason: so when you and benjamin went through the tests you have "integration-tests" as the standard hook in the plugin build to grab on to? [07:59am] jason: why is the activator a property negation? why don't you just run in hudson with -Pintegration-tests? [08:02am] jason: i want to document what you and benjamin have done as a strategy for ensuring backward compatibility [08:03am] ltheussl left the chat room. (Client closed connection) @@ -225,23 +243,28 @@ [08:17am] bentmann: Ah, I see [08:17am] jason: so i can try what i want and that's a great start [08:18am] jason: if our plugins don't all have ITs i cannot reasonably test 2.1 -[08:18am] jason: and any discussion about compatibility is pointless until that's done</pre></section><section><a id="POM_changes"></a> +[08:18am] jason: and any discussion about compatibility is pointless until that's done +</code></pre></section><section><a id="POM_changes"></a> <h3>POM changes</h3> <p>There are many changes that users have requested in the POM, in addition to wholesale formatting changes. Acommodating these requests is a little tricky because we need to support different versions simultaneously so that if projecta A builds with 2.0.x, project B can consume the project A POM using 2.1.x. We just need some way to easy support multiple versions and support mediation between the different versions.</p> <ul> -<li>Tags: loose categorization people to use to help categorize as they see fit * Categories: more standard categories that form over time by using category structures that exist or common tags that are used so often they become categories * Dendency excludes: being to transitively exclude a dependency * Properties on dependencies * Specification Dependencies * Schematron/RelaxNG descriptor for each plugin -- Bryon Jacob proposed a flexible model but XSD is hard to fight here so I'm not sure how far this will go</li></ul></section><section><a id="Embedding"></a> + +<li>Tags: loose categorization people to use to help categorize as they see fit * Categories: more standard categories that form over time by using category structures that exist or common tags that are used so often they become categories * Dendency excludes: being to transitively exclude a dependency * Properties on dependencies * Specification Dependencies * Schematron/RelaxNG descriptor for each plugin – Bryon Jacob proposed a flexible model but XSD is hard to fight here so I'm not sure how far this will go</li> +</ul></section><section><a id="Embedding"></a> <h3>Embedding</h3> <p>Full embedding of the Maven core is a major feature of the 2.1.x line. The embedder was created primarily for IDE integration and is now being consumed by m2eclipse, Mevenide and IDEA, but the embedder is also used by the Maven CLI to ensure parity between IDEs and the CLI as much as possible. To understand how the embedder work you can refer to the [Maven Embedder documentation|http://maven.apache.org/guides/mini/guide-embedding-m2.html].</p></section><section><a id="Custom_Components"></a> <h3>Custom Components</h3> -<p>As discussed in "Substituting of Custom Components", we now have two ways to insert new components into the system.</p> +<p>As discussed in “Substituting of Custom Components”, we now have two ways to insert new components into the system.</p> <p>Using a directory and specifying it in the Classworlds configuration. Tycho simply has a special set of components that load first before the standard maven components and they override the standard Maven components. Here's the example based on what Tycho is currently doing which allows custom components to be used.</p> -<pre>main is org.apache.maven.cli.MavenCli from plexus.core + +<pre><code class="nohighlight nocode">main is org.apache.maven.cli.MavenCli from plexus.core set maven.home default ${user.home}/m2 [plexus.core] load ${maven.home}/tycho/*.jar -load ${maven.home}/lib/*.jar</pre> +load ${maven.home}/lib/*.jar +</code></pre> <p>The embedder has the ContainerCustomizer which allow you to inject new component descriptors. This is used in the IDE integration (m2ecipse, Netbeans) for adding custom artifact resolvers.</p> <p>But what we ultimately need for Tycho is a way to dynamically pull in a set of components based on the packaging of a project. In our case with Tycho the packaging is maven-osgi-bundle and that should kick in the set of components that do builds for OSGi bundles. We also have another use case in Tycho where we are building OSGi bundles without a POM and actually using a manifest. In this case we need to somehow detect the manifest and then have the custom set of components kick in. In the case of Tycho we need a different project builder, and artifact resolver.</p></section><section><a id="Mercury"></a> <h3>Mercury</h3> @@ -249,17 +272,26 @@ load ${maven.home}/lib/*.jar</pre> <p>The primary reasons for replacing the code are that it is unmaintainable and nearly impossible to navigate, it uses completely non-standard structures and libraries for version calculations, the API is too hard for people to use, and it is not given to users to consume as a single componment to use. Users are forced to know how several complicated components interact in order to implement a mechanism of retrieving artifacts from a repository. The entire mechanism needs to be replaced with something that can be maintained and is reliable.</p> <p>Mercury started as some fixes to Maven Artifact to first help with embeddability and error reporting for IDE integration. This was a direct result of all IDE integrators having to reimplement the current artifact resolver to provide decent feedback to users when errors occured. The artifact subsystem would just die and leave the IDE in an unusable state. Milos was the first to implement his own artifact resolver, and Eugene soon had to do the same in m2eclipse. Oleg and I were also trying to use the current artifact mechanism in an embedded mode for some Eclipse plugins and this also proved to be quite painful. After the first attempt of removing the fail-fast behavior, Oleg and I decided to make a break from the old codebase and attempt to create Mercury with the following goals in mind:</p> <ul> -<li>Find the best people in the world to help create an awesome HTTP and DAV implementation. We did this by talking to Greg, Jan, and Jesse who are the Jetty folks and there just isn't anyone who knows HTTP better. Greg and Jan are awesome, and Jesse is Maven committer so we have some deep understanding of the issues involved. So what Oleg and I wanted to see was: ** Easy SSL support where mucky with certificates in the default install is not required. ** Connection pooling ** Connection parallelization ** Built in DAV client support for deployment ** Atomic retrieval: we make sure absolutely everything is been safely transported to disk before we place it in the local Maven repository ** Atomic deployment: in this case we could only support this using a special filter Greg created which blocks requests for any artifacts being deploy in the current set until the entire set land safely to disk. So it becomes impossible to ask for an artifact that refers to something else in the set b efore it is actually available. ** Starting thinking about a client that can understand GeoIP. Given the recent spikes in traffic we are going to start needing to distribute the load.</li> -<li>Find the best solution possible solution for dealing with version calculations, in particular ranges. For this we called on Daniel Le Berre and ask for some help in integrating his SAT4J library. We learned about the SAT4J library from the P2 project over at Eclipse.org at the last EclipseCon. SAT4J was deemed the best way forward by the P2 team in providing the most reliable, and most workable solution for doing version calculation. SAT4J provides ways to plug-in strategies to deal with our scopes, conflict resolution strategies and it is deadly fast. We felt we are in good company as we can call on Daniel and the P2 team and collaborate when difficult problems arise.</li> -<li>Find the best people to help with with security. This might an SSL-based solution to secure the channel where the source is known to be safe, a PGP-based solution where the contents must be secured assuming a hostile channel, or a combination of the two. To that end I have contacted the folks at the Legion of the Bouncy Castle and asked them to provide us the expertise to implement a safe and correct solution. I have not persued any help on the SSL. -<p>So in the end I believe it would be detrimental to use the Maven Artifact code in the 2.1.x tree and the change needs to be made to use Mercury before the first alpha ships. Oleg and I started this work, and Oleg has subsequently worked tirelessly on Mercury along with a great deal of help from Greg, Jan and Jesse. I think Oleg understands the requirements as he's seen Maven in action in one of the largest development environments in the world and watched how Maven can fail spectacularly.</p></li></ul></section><section><a id="Plugin_API_1"></a> + +<li> +<p>Find the best people in the world to help create an awesome HTTP and DAV implementation. We did this by talking to Greg, Jan, and Jesse who are the Jetty folks and there just isn't anyone who knows HTTP better. Greg and Jan are awesome, and Jesse is Maven committer so we have some deep understanding of the issues involved. So what Oleg and I wanted to see was: ** Easy SSL support where mucky with certificates in the default install is not required. ** Connection pooling ** Connection parallelization ** Built in DAV client support for deployment ** Atomic retrieval: we make sure absolutely everything is been safely transported to disk before we place it in the local Maven repository ** Atomic deployment: in this case we could only support this using a special filter Greg created which blocks requests for any artifacts being deploy in the current set until the entire set land safely to disk. So it becomes impossible to ask for an artifact that refers to something else in the set be fore it is actually available. ** Starting thinking about a client that can understand GeoIP. Given the recent spikes in traffic we are going to start needing to distribute the load.</p></li> +<li> +<p>Find the best solution possible solution for dealing with version calculations, in particular ranges. For this we called on Daniel Le Berre and ask for some help in integrating his SAT4J library. We learned about the SAT4J library from the P2 project over at Eclipse.org at the last EclipseCon. SAT4J was deemed the best way forward by the P2 team in providing the most reliable, and most workable solution for doing version calculation. SAT4J provides ways to plug-in strategies to deal with our scopes, conflict resolution strategies and it is deadly fast. We felt we are in good company as we can call on Daniel and the P2 team and collaborate when difficult problems arise.</p></li> +<li> +<p>Find the best people to help with with security. This might an SSL-based solution to secure the channel where the source is known to be safe, a PGP-based solution where the contents must be secured assuming a hostile channel, or a combination of the two. To that end I have contacted the folks at the Legion of the Bouncy Castle and asked them to provide us the expertise to implement a safe and correct solution. I have not persued any help on the SSL.</p> +<p>So in the end I believe it would be detrimental to use the Maven Artifact code in the 2.1.x tree and the change needs to be made to use Mercury before the first alpha ships. Oleg and I started this work, and Oleg has subsequently worked tirelessly on Mercury along with a great deal of help from Greg, Jan and Jesse. I think Oleg understands the requirements as he's seen Maven in action in one of the largest development environments in the world and watched how Maven can fail spectacularly.</p></li> +</ul></section><section><a id="Plugin_API_1"></a> <h3>Plugin API</h3> <ul> -<li>Symmetric output expressions * Java5 Mojo annotations (Yoav Landman has this working already) * Clean separation of plugins from reports. It's not good that those are the same thing in the Maven internals. ** Not using concrete XML classes in the Plugin API (Xpp3Dom)</li></ul></section><section><a id="Core_Refactorings"></a> + +<li>Symmetric output expressions * Java5 Mojo annotations (Yoav Landman has this working already) * Clean separation of plugins from reports. It's not good that those are the same thing in the Maven internals. ** Not using concrete XML classes in the Plugin API (Xpp3Dom)</li> +</ul></section><section><a id="Core_Refactorings"></a> <h3>Core Refactorings</h3> <ul> -<li>Project Builder architecture ** Maven shared model work: a new way of reading in the models for Maven that is not format dependent in any way i.e. XML, text, YAML, scripts, whatever. ** Pluggable model readers: this could leverage different implementations provided by the shared model work, but we still need a way to detect the type and version of the model that we want to consume ** A new terse format that uses attributes ** Automatic parent versioning ** New interpolation component (plexus-interpolation) ** Dynamic build sections ([MNG-3530|http://issues.apache.org/browse/MNG-3530]) ** Mixin support -- allowing a paramterizable template which can be imported with one line.</li> -<li>Remove the use of separate plugin repositories. We only need to pull resources from one repository. We started doing this but I've had a couple clients that want to separate the tools they use from the code they are developing/building. * Decouple script-based Plugins from the core -- we are a large part of the way here I need to summarize what was done. * Remove Settings from the core and make it a user facing configuration (This is primarily done -- jason) * Have one configuration model for request * Have one configuration model for session: session takes the request in the constructor and delegates * Domain logging * Plugin Manager ** Removal of the Plugin Registry (done) -- we moved in a direction where people lock down their versions and we've helped by putting default versions in the parent POM. ** Load Plugin dependencies into a separate ClassRealm (done) ** Plugin Execution Environment: Ability to run any version of a plugin where an environment is created which contains all the requirements for a particular version of the Plugin API * Lifecycle Executor ** Queryable Lifecycle *** The most important change in the embedding environment. You can actually query Maven for the complete execution before it happens. We must know the entire model of execution before we execute. * OSGi-like Classloading to support isolated execution environments</li></ul></section><section><a id="Java_5"></a> + +<li>Project Builder architecture ** Maven shared model work: a new way of reading in the models for Maven that is not format dependent in any way i.e. XML, text, YAML, scripts, whatever. ** Pluggable model readers: this could leverage different implementations provided by the shared model work, but we still need a way to detect the type and version of the model that we want to consume ** A new terse format that uses attributes ** Automatic parent versioning ** New interpolation component (plexus-interpolation) ** Dynamic build sections ([MNG-3530|http://issues.apache.org/browse/MNG-3530]) ** Mixin support – allowing a paramterizable template which can be imported with one line.</li> +<li>Remove the use of separate plugin repositories. We only need to pull resources from one repository. We started doing this but I've had a couple clients that want to separate the tools they use from the code they are developing/building. * Decouple script-based Plugins from the core – we are a large part of the way here I need to summarize what was done. * Remove Settings from the core and make it a user facing configuration (This is primarily done – jason) * Have one configuration model for request * Have one configuration model for session: session takes the request in the constructor and delegates * Domain logging * Plugin Manager ** Removal of the Plugin Registry (done) – we moved in a direction where people lock down their versions and we've helped by putting default versions in the parent POM. ** Load Plugin dependencies into a separate ClassRealm (done) ** Plugin Execution Environment: Ability to run any version of a plugin where an environment is crea ted which contains all the requirements for a particular version of the Plugin API * Lifecycle Executor ** Queryable Lifecycle *** The most important change in the embedding environment. You can actually query Maven for the complete execution before it happens. We must know the entire model of execution before we execute. * OSGi-like Classloading to support isolated execution environments</li> +</ul></section><section><a id="Java_5"></a> <h3>Java 5</h3> <p>Java5 annotations for plugins: we have two implementations that have now been merged in plexus-cdc. QDOX 1.7 has now been released so we may want to check the source level gleaning again. Jason Dillon has created a working class processing model. We need to deal with Plexus components and Maven plugins.</p></section><section><a id="Integration_and_promotion_of_scriptable_plugins"></a> <h3>Integration and promotion of scriptable plugins</h3><section><a id="Toolchains"></a> @@ -267,10 +299,12 @@ load ${maven.home}/lib/*.jar</pre> <p>Milos has implemented this and Shane had some feedback so this needs to be linked together</p></section></section><section><a id="Reporting"></a> <h3>Reporting</h3> <ul> -<li>Report Execution Environment: Ability to run any version of a report where an environment is created which contains all the requirements for a particular version of the Report API. * Decouple the reporting core. We need to get Doxia out of the core. Anything it needs to run should be isolated.</li></ul></section></section><section><a id="Other_Use_Cases_to_Integrate"></a> + +<li>Report Execution Environment: Ability to run any version of a report where an environment is created which contains all the requirements for a particular version of the Report API. * Decouple the reporting core. We need to get Doxia out of the core. Anything it needs to run should be isolated.</li> +</ul></section></section><section><a id="Other_Use_Cases_to_Integrate"></a> <h2>Other Use Cases to Integrate</h2><section><a id="Determining_project_type_in_Eclipse_.28Igor_Fedorenko.29"></a> <h3>Determining project type in Eclipse (Igor Fedorenko)</h3> -<p>Support for "java" projects in Eclipse has certain overhead and it is desirable to only enable for projects that actually require it. More specifically, java maven projects have JRE classpath container, maven classpath container, have java-specific UI elements enabled and are offered in various java-related searches. Also, tools like WTP and AJDT treat (eclipse) java projects specially.</p> +<p>Support for “java” projects in Eclipse has certain overhead and it is desirable to only enable for projects that actually require it. More specifically, java maven projects have JRE classpath container, maven classpath container, have java-specific UI elements enabled and are offered in various java-related searches. Also, tools like WTP and AJDT treat (eclipse) java projects specially.</p> <p>There is currently no direct way to tell if a (maven) project needs to be configured as java project in eclipse. The closest test condition I can think off is</p> <p>1 the project ArtifactHandler language=java</p> <p>and</p> @@ -282,13 +316,19 @@ load ${maven.home}/lib/*.jar</pre> <p>(in other words the project is java and either itself is added to classpath or has sources to compile).</p> <p>This test will return false negative for some WAR projects (not added to classpath and don't have any sources to compile). Also, compileSourceRoots and testCompileSourceRoots only become fully populated after running maven build lifecycle, which is expensive.</p> <ul> + <li>Extensions <ul> + <li>Different categories of extensions: providers vs packaging vs PMD/Checkstyle resources stuff in a JAR</li> <li>Transparent Extension Loading <ul> + <li>Any Wagon or SCM providers should get picked up automatically from SCM and distributionManagement URLs</li> -<li>Any extensions containing packaging/lifecycle related bits needs to be picked up automatically</li></ul></li></ul></li></ul></section></section></section> </main> +<li>Any extensions containing packaging/lifecycle related bits needs to be picked up automatically</li> +</ul></li> +</ul></li> +</ul></section></section></section> </main> </div> </div> <hr/> Modified: maven/website/content/examples/index.html ============================================================================== --- maven/website/content/examples/index.html Mon Aug 4 12:10:02 2025 (r1927609) +++ maven/website/content/examples/index.html Mon Aug 4 12:22:05 2025 (r1927610) @@ -2,7 +2,7 @@ <!-- - | Generated by Apache Maven Doxia Site Renderer 2.0.0 from content/apt/examples/index.apt at 2025-08-04 + | Generated by Apache Maven Doxia Site Renderer 2.0.0 from content/markdown/examples/index.md at 2025-08-04 | Rendered using Apache Maven Fluido Skin 2.1.0 --> <html xmlns="http://www.w3.org/1999/xhtml"; lang="en"> @@ -10,9 +10,7 @@ <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0" /> - <meta name="author" content="John Casey" /> - <meta name="date" content="2009-08-02" /> - <title>Summary of Maven Examples – Maven</title> + <title>Examples – Maven</title> <link rel="stylesheet" href="../css/apache-maven-fluido-2.1.0.min.css" /> <link rel="stylesheet" href="../css/site.css" /> <link rel="stylesheet" href="../css/print.css" media="print" /> @@ -47,7 +45,7 @@ <ul class="breadcrumb"> <li><a href="https://www.apache.org/";>Apache</a><span class="divider">/</span></li> <li><a href="../index.html">Maven</a><span class="divider">/</span></li> - <li class="active">Summary of Maven Examples <a href="https://github.com/apache/maven-site/tree/master/content/apt/examples/index.apt";><img src="../images/accessories-text-editor.png" alt="Edit" /></a></li> + <li class="active">Examples <a href="https://github.com/apache/maven-site/tree/master/content/markdown/examples/index.md";><img src="../images/accessories-text-editor.png" alt="Edit" /></a></li> <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2025-08-04</li> <li class="pull-right"><span class="divider">|</span> <a href="../scm.html">Get Sources</a></li> @@ -133,11 +131,31 @@ </div> </header> <main id="bodyColumn" class="span10"> +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + +http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> <section><a id="Examples"></a> <h1>Examples</h1> <ul> + <li><a href="./injecting-properties-via-settings.html">Injecting POM Properties via settings.xml</a></li> -<li><a href="./maven-3-lifecycle-extensions.html">Maven 3 lifecycle extensions</a></li></ul></section> </main> +<li><a href="./maven-3-lifecycle-extensions.html">Maven 3 lifecycle extensions</a></li> +</ul></section> </main> </div> </div> <hr/> Modified: maven/website/content/examples/injecting-properties-via-settings.html ============================================================================== --- maven/website/content/examples/injecting-properties-via-settings.html Mon Aug 4 12:10:02 2025 (r1927609) +++ maven/website/content/examples/injecting-properties-via-settings.html Mon Aug 4 12:22:05 2025 (r1927610) @@ -2,7 +2,7 @@ <!-- - | Generated by Apache Maven Doxia Site Renderer 2.0.0 from content/apt/examples/injecting-properties-via-settings.apt at 2025-08-04 + | Generated by Apache Maven Doxia Site Renderer 2.0.0 from content/markdown/examples/injecting-properties-via-settings.md at 2025-08-04 | Rendered using Apache Maven Fluido Skin 2.1.0 --> <html xmlns="http://www.w3.org/1999/xhtml"; lang="en"> @@ -10,8 +10,6 @@ <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> <meta name="generator" content="Apache Maven Doxia Site Renderer 2.0.0" /> - <meta name="author" content="John Casey" /> - <meta name="date" content="2006-04-20" /> <title>Example: Injecting POM Properties via Settings.xml – Maven</title> <link rel="stylesheet" href="../css/apache-maven-fluido-2.1.0.min.css" /> <link rel="stylesheet" href="../css/site.css" /> @@ -47,7 +45,7 @@ <ul class="breadcrumb"> <li><a href="https://www.apache.org/";>Apache</a><span class="divider">/</span></li> <li><a href="../index.html">Maven</a><span class="divider">/</span></li> - <li class="active">Example: Injecting POM Properties via Settings.xml <a href="https://github.com/apache/maven-site/tree/master/content/apt/examples/injecting-properties-via-settings.apt";><img src="../images/accessories-text-editor.png" alt="Edit" /></a></li> + <li class="active">Example: Injecting POM Properties via Settings.xml <a href="https://github.com/apache/maven-site/tree/master/content/markdown/examples/injecting-properties-via-settings.md";><img src="../images/accessories-text-editor.png" alt="Edit" /></a></li> <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2025-08-04</li> <li class="pull-right"><span class="divider">|</span> <a href="../scm.html">Get Sources</a></li> @@ -133,12 +131,31 @@ </div> </header> <main id="bodyColumn" class="span10"> +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + +http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> <section><a id="Example.3A_Injecting_POM_Properties_via_Settings.xml"></a> <h1>Example: Injecting POM Properties via Settings.xml</h1><section><a id="Impetus"></a> <h2>Impetus</h2> <p>You have a plugin parameter that should contain a user-specific value. This parameter has a common format (relative directory structure), but depends on knowing the directory of the installed application or something.</p></section><section><a id="Plugin_Configuration"></a> <h2>Plugin Configuration</h2> -<pre class="prettyprint linenums"><code><project xmlns="http://maven.apache.org/POM/4.0.0"> + +<pre class="prettyprint linenums"><code class="language-xml"><project xmlns="http://maven.apache.org/POM/4.0.0"> [...] <build> <plugins> @@ -151,9 +168,11 @@ </configuration> </plugin> </plugins> - </build></code></pre></section><section><a id="settings.xml"></a> + </build> +</code></pre></section><section><a id="settings.xml"></a> <h2><code>settings.xml</code></h2> -<pre class="prettyprint linenums"><code><settings> + +<pre class="prettyprint linenums"><code class="language-xml"><settings> [...] <profiles> <profile> @@ -167,9 +186,10 @@ <activeProfiles> <activeProfile>inject-application-home</activeProfile> </activeProfiles> -</settings></code></pre></section><section><a id="Explanation"></a> +</settings> +</code></pre></section><section><a id="Explanation"></a> <h2>Explanation</h2> -<p>When Maven loads the project's POM, it will pickup the activated profiles from the <code>activeProfiles</code> section of the <code>settings.xml</code> file, and inject the properties declared within the profile. When the POM is interpolated, the <code>application-home</code> property will already have been injected, so will allow the plugin's parameter value to be resolved.</p></section></section> </main> +<p>When Maven loads the project's POM, it will pick up the activated profiles from the <code>activeProfiles</code> section of the <code>settings.xml</code> file, and inject the properties declared within the profile. When the POM is interpolated, the <code>application-home</code> property will already have been injected, so will allow the plugin's parameter value to be resolved.</p></section></section> </main> </div> </div> <hr/>
