Author: svn-site-role
Date: Sat Feb 18 20:40:58 2023
New Revision: 1907743
Log:
Site checkin for project Apache Maven Site
Modified:
maven/website/content/aether.html
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/configure.html
maven/website/content/developers/committer-environment.html
maven/website/content/developers/committer-settings.html
maven/website/content/developers/compatibility-plan.html
maven/website/content/developers/conventions/code.html
maven/website/content/developers/conventions/git.html
maven/website/content/developers/dependency-policies.html
maven/website/content/developers/index.html
maven/website/content/developers/release/index.html
maven/website/content/developers/release/maven-project-release-procedure.html
maven/website/content/developers/release/parent-pom-release.html
maven/website/content/developers/release/pmc-gpg-keys.html
maven/website/content/developers/retirement-plan-plugins.html
maven/website/content/developers/website/deploy-component-reference-documentation.html
maven/website/content/developers/website/deploy-maven-website.html
maven/website/content/developers/website/index.html
maven/website/content/developers/website/website-overview.html
maven/website/content/developers/welcome-to-new-committers.html
maven/website/content/docs/3.2.1/release-notes.html
maven/website/content/docs/3.2.2/release-notes.html
maven/website/content/docs/3.2.3/release-notes.html
maven/website/content/docs/3.2.5/release-notes.html
maven/website/content/docs/3.3.1/release-notes.html
maven/website/content/docs/3.3.3/release-notes.html
maven/website/content/docs/3.3.9/release-notes.html
maven/website/content/docs/3.5.0-alpha-1/release-notes.html
maven/website/content/docs/3.5.0-beta-1/release-notes.html
maven/website/content/docs/3.5.0/release-notes.html
maven/website/content/docs/3.5.2/release-notes.html
maven/website/content/docs/3.5.3/release-notes.html
maven/website/content/docs/3.5.4/release-notes.html
maven/website/content/docs/3.6.0/release-notes.html
maven/website/content/docs/3.6.1/release-notes.html
maven/website/content/docs/3.6.2/release-notes.html
maven/website/content/docs/3.6.3/release-notes.html
maven/website/content/docs/3.8.1/release-notes.html
maven/website/content/docs/3.8.2/release-notes.html
maven/website/content/docs/3.8.3/release-notes.html
maven/website/content/docs/3.8.4/release-notes.html
maven/website/content/docs/3.8.5/release-notes.html
maven/website/content/docs/3.8.6/release-notes.html
maven/website/content/docs/3.8.7/release-notes.html
maven/website/content/docs/3.9.0/release-notes.html
maven/website/content/docs/4.0.0-alpha-2/release-notes.html
maven/website/content/docs/4.0.0-alpha-3/release-notes.html
maven/website/content/docs/4.0.0-alpha-4/release-notes.html
maven/website/content/docs/history.html
maven/website/content/examples/index.html
maven/website/content/examples/injecting-properties-via-settings.html
maven/website/content/faq-unoffical.html
maven/website/content/glossary.html
maven/website/content/guides/development/guide-building-maven.html
maven/website/content/guides/development/guide-committer-school.html
maven/website/content/guides/development/guide-documentation-style.html
maven/website/content/guides/development/guide-helping.html
maven/website/content/guides/development/guide-maven-development.html
maven/website/content/guides/development/guide-plugin-documentation.html
maven/website/content/guides/development/guide-testing-development-plugins.html
maven/website/content/guides/development/guide-testing-releases.html
maven/website/content/guides/getting-started/index.html
maven/website/content/guides/getting-started/maven-in-five-minutes.html
maven/website/content/guides/getting-started/windows-prerequisites.html
maven/website/content/guides/introduction/introduction-to-archetypes.html
maven/website/content/guides/introduction/introduction-to-dependency-mechanism.html
maven/website/content/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
maven/website/content/guides/introduction/introduction-to-plugin-prefix-mapping.html
maven/website/content/guides/introduction/introduction-to-plugins.html
maven/website/content/guides/introduction/introduction-to-profiles.html
maven/website/content/guides/introduction/introduction-to-repositories.html
maven/website/content/guides/introduction/introduction-to-the-lifecycle.html
maven/website/content/guides/introduction/introduction-to-the-pom.html
maven/website/content/guides/introduction/introduction-to-the-standard-directory-layout.html
maven/website/content/guides/mini/guide-3rd-party-jars-local.html
maven/website/content/guides/mini/guide-3rd-party-jars-remote.html
maven/website/content/guides/mini/guide-archive-configuration.html
maven/website/content/guides/mini/guide-assemblies.html
maven/website/content/guides/mini/guide-attached-tests.html
maven/website/content/guides/mini/guide-bash-m2-completion.html
maven/website/content/guides/mini/guide-building-for-different-environments.html
maven/website/content/guides/mini/guide-configuring-maven.html
maven/website/content/guides/mini/guide-configuring-plugins.html
maven/website/content/guides/mini/guide-creating-archetypes.html
maven/website/content/guides/mini/guide-default-execution-ids.html
maven/website/content/guides/mini/guide-deployment-security-settings.html
maven/website/content/guides/mini/guide-encryption.html
maven/website/content/guides/mini/guide-generating-sources.html
maven/website/content/guides/mini/guide-http-settings.html
maven/website/content/guides/mini/guide-large-scale-centralized-deployments.html
maven/website/content/guides/mini/guide-manifest.html
maven/website/content/guides/mini/guide-maven-classloading.html
maven/website/content/guides/mini/guide-mirror-settings.html
maven/website/content/guides/mini/guide-multiple-modules.html
maven/website/content/guides/mini/guide-multiple-repositories.html
maven/website/content/guides/mini/guide-naming-conventions.html
maven/website/content/guides/mini/guide-new-committers.html
maven/website/content/guides/mini/guide-proxies.html
maven/website/content/guides/mini/guide-releasing.html
maven/website/content/guides/mini/guide-relocation.html
maven/website/content/guides/mini/guide-repository-ssl.html
maven/website/content/guides/mini/guide-reproducible-builds.html
maven/website/content/guides/mini/guide-site.html
maven/website/content/guides/mini/guide-snippet-macro.html
maven/website/content/guides/mini/guide-using-ant.html
maven/website/content/guides/mini/guide-using-extensions.html
maven/website/content/guides/mini/guide-using-modello.html
maven/website/content/guides/mini/guide-using-one-source-directory.html
maven/website/content/guides/mini/guide-using-toolchains.html
maven/website/content/guides/mini/guide-wagon-providers.html
maven/website/content/guides/plugin/guide-java-plugin-development.html
maven/website/content/guides/plugin/guide-java-report-plugin-development.html
maven/website/content/install.html
maven/website/content/issue-management.html
maven/website/content/maven-features.html
maven/website/content/maven-jsr330.html
maven/website/content/maven-site-1.0-site.jar
maven/website/content/plugin-developers/common-bugs.html
maven/website/content/plugin-developers/cookbook/index.html
maven/website/content/plugin-developers/cookbook/plexus-plugin-upgrade.html
maven/website/content/plugin-developers/index.html
maven/website/content/plugin-developers/plugin-documenting.html
maven/website/content/plugin-developers/plugin-testing.html
maven/website/content/plugins/index.html
maven/website/content/plugins/localization.html
maven/website/content/repository/central-index.html
maven/website/content/repository/central-metadata.html
maven/website/content/repository/guide-central-repository-upload.html
maven/website/content/run-maven/index.html
maven/website/content/security-plexus-archiver.html
maven/website/content/security.html
maven/website/content/settings.html
maven/website/content/shared/index.html
maven/website/content/skins/index.html
maven/website/content/users/getting-help.html
maven/website/content/users/index.html
Modified: maven/website/content/aether.html
==============================================================================
--- maven/website/content/aether.html (original)
+++ maven/website/content/aether.html Sat Feb 18 20:40:58 2023
@@ -177,8 +177,8 @@ and through <a href="https://issues.apac
<td>no OSGi bundles in Apache Maven</td></tr>
<tr class="b">
<td><strong>P2 repo</strong></td>
-<td><<a href="http://download.eclipse.org/aether/aether-core/releases/";
class="externalLink">http://download.eclipse.org/aether/aether-core/releases/</a><br
/><a href="http://download.eclipse.org/aether/maven-aether-provider/releases/";
class="externalLink">http://download.eclipse.org/aether/maven-aether-provider/releases/</a></td>
-<td>no> P2 repo</td></tr>
+<td><a href="http://download.eclipse.org/aether/aether-core/releases/";
class="externalLink">http://download.eclipse.org/aether/aether-core/releases/</a><br
/><a href="http://download.eclipse.org/aether/maven-aether-provider/releases/";
class="externalLink">http://download.eclipse.org/aether/maven-aether-provider/releases/</a></td>
+<td>no P2 repo</td></tr>
<tr class="a">
<td><strong>API java packages</strong></td>
<td>org.eclipse.aether…</td>
Modified: maven/website/content/archives/maven-2.x/index.html
==============================================================================
--- maven/website/content/archives/maven-2.x/index.html (original)
+++ maven/website/content/archives/maven-2.x/index.html Sat Feb 18 20:40:58 2023
@@ -2,7 +2,7 @@
<!--
- | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
content/markdown/archives/maven-2.x/index.md at 2023-02-18
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
content/apt/archives/maven-2.x/index.apt at 2023-02-18
| Rendered using Apache Maven Fluido Skin 1.11.1
-->
<html xmlns="http://www.w3.org/1999/xhtml"; lang="">
@@ -48,7 +48,7 @@
<ul class="breadcrumb">
<li class=""><a href="https://www.apache.org/"; class="externalLink"
title="Apache">Apache</a><span class="divider">/</span></li>
<li class=""><a href="../../index.html" title="Maven">Maven</a><span
class="divider">/</span></li>
- <li class="active ">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" title="Edit" /></a></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" title="Edit" /></a></li>
<li id="publishDate" class="pull-right"><span class="divider">|</span>
Last Published: 2023-02-18</li>
<li class="pull-right"><span class="divider">|</span>
<a href="../../scm.html" title="Get Sources">Get Sources</a></li>
@@ -123,51 +123,34 @@
</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><section>
-<h2>This is the Maven 2 Graveyard</h2>
+<section>
+<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>
-<h3>Plugin List</h3>
+<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-striped">
-<thead>
+<table class="bodyTable bodyTableBorder">
<tr class="a">
-<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>
+<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>
<tr class="b">
-<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>
+<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>
<tr class="a">
-<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></section>
+<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>
</div>
</div>
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
(original)
+++ maven/website/content/archives/maven-2.x/maven-2.1-architectural-goals.html
Sat Feb 18 20:40:58 2023
@@ -2,7 +2,7 @@
<!--
- | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md at
2023-02-18
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
content/apt/archives/maven-2.x/maven-2.1-architectural-goals.apt at 2023-02-18
| Rendered using Apache Maven Fluido Skin 1.11.1
-->
<html xmlns="http://www.w3.org/1999/xhtml"; lang="">
@@ -46,7 +46,7 @@
<ul class="breadcrumb">
<li class=""><a href="https://www.apache.org/"; class="externalLink"
title="Apache">Apache</a><span class="divider">/</span></li>
<li class=""><a href="../../index.html" title="Maven">Maven</a><span
class="divider">/</span></li>
- <li class="active ">Maven <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" title="Edit" /></a></li>
+ <li class="active ">Maven <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" title="Edit" /></a></li>
<li id="publishDate" class="pull-right"><span class="divider">|</span>
Last Published: 2023-02-18</li>
<li class="pull-right"><span class="divider">|</span>
<a href="../../scm.html" title="Get Sources">Get Sources</a></li>
@@ -121,303 +121,72 @@
</div>
</header>
<main id="bodyColumn" class="span10" >
-<p>h1. Maven 2.1 – Jason van Zyl</p>
-<p>~~ 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
-~~
-~~ <a href="http://www.apache.org/licenses/LICENSE-2.0";
class="externalLink">http://www.apache.org/licenses/LICENSE-2.0</a>
-~~
-~~ 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.</p>
-<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>
-<p>Technical Preparation: not necessary before discussions can start but
helpful to help guide how we concretely determine backward compat
-TODO: get an explanation of the process Arnaud and Benjamin have for plugins.
I started by capturing the log
-TODO: document standard setup for Hudson we have so people can see the results
of testing
-TODO: setup hudson with emma for code coverage and ask VELO to help us setup
coverage for integration tests</p>
-<p>h2. Architectural Goals</p>
-<p>h3. Backward Compatibility</p>
-<p>We must ensure that plugins and reports written against the Maven 2.0.x
APIs remain to work in 2.1. We don't want people to have to rewrite
-their plugins. There are several plugins that are using the current artifact
resolution code that will not be supported (please see the Mercury section
below). The
-ones that are in our control we can port over to use Mercury, and external
users will have to deal with the major version change. Most people will not be
affected and
-Mercury will be a far better solution.</p>
-<p>We must also ensure that POMs of version 4.0.0 are supported in 2.1.x along
with the behavior currently experienced. We are relying heavily on our
integrations tests right
-now but as we move forward the work that Shane is doing on the project builder
with maven-shared-model will help us to accommodate different versions of a
POM, and different
-formats we decide to support. The maven-shared-model code has no limitation to
formats of XML, or any of format like YAML, script, or anything else anyone can
dream up. These
-implementations may find use outside of Maven. For example someone might build
something with the Maven Embedder, JRuby, and Mercury to create a JRuby-based
system. The
-same could be done for Groovy, or Intercal.</p>
-<p>h2. Plugin and Extension Loading</p>
-<p>Maven's mechanisms for loading plugins and build extensions has been
refactored. You can find more information in the [Maven 2.1 Plugin and
Extension Loading Design] document.</p>
-<p>h2. Lifecycle</p>
-<p>h3. Aggregator Mojo Handling</p>
-<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 <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>
-<p>h2. Plugin API</p>
-<p>h3. Shading of plexus-utils causing a ClassCastException on
plugin.getConfiguration()
([MNG-3012|http://jira.codehaus.org/browse/MNG-3012])</p>
-<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:
<code><requires><mavenVersion>2.0.6</mavenVersion></requires></code>.
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>
-<p>h3. Strategies for ensuring backward compatibility</p>
-<ul>
-
-<li>Plugin integration testing</li>
-</ul>
-<p>{code}
-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)
-[08:04am] aheritier: I started with this idea to have an additional profile
that we activate with a property like integration-tests=true
-[08:05am] jason: yah, i think -Pintegration-tests=true in a schedule in hudson
is fine
-[08:05am] jason: don't think the skip property is necessary
-[08:05am] bentmann joined the chat room.
-[08:05am] aheritier: but others showed me that he major part of existing
integration tests were activated with skipTests ! true
-[08:05am] aheritier: I asked why
-[08:05am] aheritier: they said it was to be sure to launch it by default
-[08:06am] aheritier: but to have the possibility to deactivate them if we skip
tests
-[08:06am] jason: sure, so by default they run
-[08:07am] aheritier: yes.
-[08:07am] aheritier: I prefer to activate them if I want
-[08:07am] jason: yes
-[08:07am] aheritier: not to have them always
-[08:07am] jason: i agree that should be the pattern
-[08:07am] aheritier: it's too long
-[08:07am] jason: a smoke test in one mode
-[08:07am] jason: and then turn them all on in hudson
-[08:07am] aheritier: it's why we invented CI servers
-[08:07am] aheritier: yes
-[08:07am] eu left the chat room. (Ping timeout)
-[08:08am] jason: i will document the setup but you and ben should figure out
the pattern you want for a given plugin test
-[08:08am] jason: and i'll document this as a strategy for testing 2.1
-[08:08am] eu joined the chat room.
-[08:08am] ekuleshov is now known as eu.
-[08:08am] jason: as i would like to take your setup, and parameterize the
version of maven
-[08:08am] jason: so when some changes are made in 2.1 i'll run the plugin
smoke test first
-[08:09am] jason: make sure nothing we change in the apis or hooks is screwed up
-[08:09am] jason: and then run the ITs to make sure those plugins are working
-[08:09am] jason: i already know a handful that are not working
-[08:09am] bentmann: jason: How exactly do you intend to parametrize the Maven
version? As far as I see, you only need to run them with the Maven of your
choice.
-[08:10am] jason: by taking the existing build, read the job, and change the
version
-[08:10am] jason: i have tools for reading/writing jobs
-[08:10am] jason: but even low tech cloning the job and changing the maven
installation
-[08:10am] bentmann: So the parametrization is limited to the Hudson job
config, right?
-[08:11am] jason: actually you could parameterize anything if you control the
job reading/writing
-[08:11am] eu left the chat room. (Ping timeout)
-[08:11am] jason: but this is something kohsuke added himself about a week ago
-[08:11am] jason: in hudson itself
-[08:11am] jason: i will create a set of parameters to test old/new versions of
maven with a given set of plugins
-[08:12am] jason: this is a great start, we couldn't do it if the plugins
didn't have the same hook
-[08:12am] jason: so all the maven plugin builds now have
“integration-tests” profiles?
-[08:12am] bentmann: Well, not all, only those that ITs before.
-[08:12am] ekuleshov joined the chat room.
-[08:12am] veleno left the chat room. (veleno)
-[08:13am] jason: well that's a start and they are at least consistent now
-[08:13am] ekuleshov is now known as eu.
-[08:13am] jason: which is a great start
-[08:13am] bentmann: I believe you just need to try to setup a Hudson job with
Maven 2.1 to build “maven-plugins” and see what's missing in
terms of config
-[08:14am] jason: not sure what you mean
-[08:14am] bentmann: IIRC, both Invoker and Shitty were picking up the
maven.home from the currently running Maven, so the ITs should inherit that
-[08:14am] jason: also, do you guys have a quick way to tell what plugins don't
have ITs?
-[08:14am] bentmann: Seach for src/it…
-[08:15am] jason: yes, i want to make more a report but i can do that
-[08:15am] jason: so anything that does have ITs you guys have made consistent?
-[08:15am] jason: yes?
-[08:15am] bentmann: Not sure what kind of consistency you actually require
-[08:16am] bentmann: The IT profile should be named equal for all of them
-[08:16am] bentmann: by inheriting from the parent
-[08:16am] i386_left the chat room. (i386_)
-[08:16am] bentmann: whether the are run by Invoker or Shitty shouldn't matter,
I guess
-[08:17am] jason: no, the actual project just needs a profile name the same.
not taken from the parent but stated in the project itself
-[08:17am] jason: though the parent could specify that profile which just echos
“No ITs”
-[08:17am] jason: so in a run we would know which plugins don't have ITs at all
-[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
-{code}</p>
-<p>h3. POM changes</p>
-<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</li>
-<li>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</li>
-<li>Dendency excludes: being to transitively exclude a dependency</li>
-<li>Properties on dependencies</li>
-<li>Specification Dependencies</li>
-<li>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>
-<p>h3. Embedding</p>
-<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>
-<p>h3. Custom Components</p>
-<p>As discussed in [Substituting of Custom
Components|http://docs.codehaus.org/display/MAVEN/Substitution+of+Custom+Maven+Components]
we now have two ways
-to insert new components into the system.</p>
-<ul>
-
-<li>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.</li>
-</ul>
-<p>{code}
-main is org.apache.maven.cli.MavenCli from plexus.core</p>
-<p>set maven.home default ${user.home}/m2</p>
-<p>[plexus.core]
-load ${maven.home}/tycho/<em>.jar
-load ${maven.home}/lib/</em>.jar
-{code}</p>
-<ul>
-
-<li>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.</li>
-</ul>
-<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>
-<p>h3. Mercury</p>
-<p>Mercury is a replacement for the current Maven Artifact subsystem, and a
complete replacement for the HTTP and DAV portions of the existing
transport.</p>
-<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>
-<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 before 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></li>
-</ul>
-<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>
-<p>h3. Plugin API</p>
-<ul>
-
-<li>Symmetric output expressions</li>
-<li>Java5 Mojo annotations (Yoav Landman has this working already)</li>
-<li>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>
-<p>h3. Core Refactorings</p>
-<ul>
-
-<li>
-<p>Project Builder
([architecture|http://docs.codehaus.org/display/MAVENUSER/Project+Builder])
-**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://jira.codehaus.org/browse/MNG-3530])
-** Mixin support – allowing a paramterizable template which can be
imported with one line.</p></li>
-<li>
-<p>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.</p></li>
-<li>
-<p>Decouple script-based Plugins from the core – we are a large part of
the way here I need to summarize what was done.</p></li>
-<li>
-<p>Remove Settings from the core and make it a user facing configuration (This
is primarily done – jason)</p></li>
-<li>
-<p>Have one configuration model for request</p></li>
-<li>
-<p>Have one configuration model for session: session takes the request in the
constructor and delegates</p></li>
-<li>
-<p>Domain logging</p></li>
-<li>
-<p>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</p></li>
-<li>
-<p>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.</p></li>
-<li>
-<p>OSGi-like Classloading to support isolated execution environments</p></li>
-</ul>
-<p>h3. Java 5</p>
-<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>
-<p>h3. Integration and promotion of scriptable plugins</p>
-<p>h3. Toolchains</p>
-<ul>
-
-<li>Milos has implemented this and Shane had some feedback so this needs to be
linked together</li>
-</ul>
-<p>h3. Reporting</p>
-<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.</li>
-<li>Decouple the reporting core. We need to get Doxia out of the core.
Anything it needs to run should be isolated.</li>
-</ul>
-<p>h1. Other Use Cases to Integrate</p>
-<p>h2. Determining project type in Eclipse (Igor Fedorenko)</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>
-<p>2.1 ArtifactHandler addedToClasspath=true</p>
-<p>or</p>
-<p>2.2 MavenProject.getCompileSourceRoots().size() > 0</p>
-<p>or</p>
-<p>2.3 MavenProject.getTestCompileSourceRoots().size() > 0</p>
-<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
-**Different categories of extensions: providers vs packaging vs PMD/Checkstyle
resources stuff in a JAR
-** Transparent Extension Loading
-***Any Wagon or SCM providers should get picked up automatically from SCM and
distributionManagement URLs
-*** Any extensions containing packaging/lifecycle related bits needs to be
picked up automatically</li>
-</ul>
+<section>
+<h1>h1. Maven 2.1 -- Jason van Zyl</h1></section><section>
+<h1>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</h1></section><section>
+<h1>Technical Preparation: not necessary before discussions can start but
helpful to help guide how we concretely determine backward compat TODO: get an
explanation of the process Arnaud and Benjamin have for plugins. I started by
capturing the log TODO: document standard setup for Hudson we have so people
can see the results of testing TODO: setup hudson with emma for code coverage
and ask VELO to help us setup coverage for integration
tests</h1></section><section>
+<h1>h2. Architectural Goals</h1></section><section>
+<h1>h3. Backward Compatibility</h1></section><section>
+<h1>We must ensure that plugins and reports written against the Maven 2.0.x
APIs remain to work in 2.1. We don't want people to have to rewrite their
plugins. There are several plugins that are using the current artifact
resolution code that will not be supported (please see the Mercury section
below). The ones that are in our control we can port over to use Mercury, and
external users will have to deal with the major version change. Most people
will not be affected and Mercury will be a far better
solution.</h1></section><section>
+<h1>We must also ensure that POMs of version 4.0.0 are supported in 2.1.x
along with the behavior currently experienced. We are relying heavily on our
integrations tests right now but as we move forward the work that Shane is
doing on the project builder with maven-shared-model will help us to
accommodate different versions of a POM, and different formats we decide to
support. The maven-shared-model code has no limitation to formats of XML, or
any of format like YAML, script, or anything else anyone can dream up. These
implementations may find use outside of Maven. For example someone might build
something with the Maven Embedder, JRuby, and Mercury to create a JRuby-based
system. The same could be done for Groovy, or Intercal.</h1></section><section>
+<h1>h2. Plugin and Extension Loading</h1></section><section>
+<h1>Maven's mechanisms for loading plugins and build extensions has been
refactored. You can find more information in the [Maven 2.1 Plugin and
Extension Loading Design] document.</h1></section><section>
+<h1>h2. Lifecycle</h1></section><section>
+<h1>h3. Aggregator Mojo Handling</h1></section><section>
+<h1>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.</h1></section><section>
+<h1>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.</h1></section><section>
+<h1>h2. Plugin API</h1></section><section>
+<h1>h3. Shading of plexus-utils causing a ClassCastException on
plugin.getConfiguration()
([MNG-3012|http://jira.codehaus.org/browse/MNG-3012])</h1>
+<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></section><section>
+<h1>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.</h1></section><section>
+<h1>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</h1></section><section>
+<h1>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).</h1></section><section>
+<h1>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.</h1></section><section>
+<h1>h3. Strategies for ensuring backward compatibility</h1><section>
+<h2>Plugin integration testing</h2></section></section><section>
+<h1><a id="code">code</a> 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) [08:04am] aheritier: I started with this idea to have an additional
profile that we activate with a property like integration-tests=true [08:05am]
jason: yah, i think -Pintegration-tests=true in a schedule in hudson is fine
[08:05am] jason: don't think the skip property is necessary [08:05am] bentmann
joined the chat room. [08:05am] aheritier: but others showed me that he major
part of existing integration tests were activated with skipTests ! true
[08:05am] aheritier: I asked why [08:05am] aheritier: they said it
was to be sure to launch it by default [08:06am] aheritier: but to have the
possibility to deactivate them if we skip tests [08:06am] jason: sure, so by
default they run [08:07am] aheritier: yes. [08:07am] aheritier: I prefer to
activate them if I want [08:07am] jason: yes [08:07am] aheritier: not to have
them always [08:07am] jason: i agree that should be the pattern [08:07am]
aheritier: it's too long [08:07am] jason: a smoke test in one mode [08:07am]
jason: and then turn them all on in hudson [08:07am] aheritier: it's why we
invented CI servers [08:07am] aheritier: yes [08:07am] eu left the chat room.
(Ping timeout) [08:08am] jason: i will document the setup but you and ben
should figure out the pattern you want for a given plugin test [08:08am] jason:
and i'll document this as a strategy for testing 2.1 [08:08am] eu joined the
chat room. [08:08am] ekuleshov is now known as eu. [08:08am] jason: as i would
like to take your setup, and parameterize the version of maven [08:08am] j
ason: so when some changes are made in 2.1 i'll run the plugin smoke test
first [08:09am] jason: make sure nothing we change in the apis or hooks is
screwed up [08:09am] jason: and then run the ITs to make sure those plugins are
working [08:09am] jason: i already know a handful that are not working
[08:09am] bentmann: jason: How exactly do you intend to parametrize the Maven
version? As far as I see, you only need to run them with the Maven of your
choice. [08:10am] jason: by taking the existing build, read the job, and change
the version [08:10am] jason: i have tools for reading/writing jobs [08:10am]
jason: but even low tech cloning the job and changing the maven installation
[08:10am] bentmann: So the parametrization is limited to the Hudson job config,
right? [08:11am] jason: actually you could parameterize anything if you control
the job reading/writing [08:11am] eu left the chat room. (Ping timeout)
[08:11am] jason: but this is something kohsuke added himself about a week ago
[08:11am] jason: in hudson itself [08:11am] jason: i will create a set of
parameters to test old/new versions of maven with a given set of plugins
[08:12am] jason: this is a great start, we couldn't do it if the plugins didn't
have the same hook [08:12am] jason: so all the maven plugin builds now have
"integration-tests" profiles? [08:12am] bentmann: Well, not all, only
those that ITs before. [08:12am] ekuleshov joined the chat room. [08:12am]
veleno left the chat room. (veleno) [08:13am] jason: well that's a start and
they are at least consistent now [08:13am] ekuleshov is now known as eu.
[08:13am] jason: which is a great start [08:13am] bentmann: I believe you just
need to try to setup a Hudson job with Maven 2.1 to build
"maven-plugins" and see what's missing in terms of config [08:14am]
jason: not sure what you mean [08:14am] bentmann: IIRC, both Invoker and Shitty
were picking up the maven.home from the currently running Maven, so the ITs
should inherit tha
t [08:14am] jason: also, do you guys have a quick way to tell what plugins
don't have ITs? [08:14am] bentmann: Seach for src/it... [08:15am] jason: yes, i
want to make more a report but i can do that [08:15am] jason: so anything that
does have ITs you guys have made consistent? [08:15am] jason: yes? [08:15am]
bentmann: Not sure what kind of consistency you actually require [08:16am]
bentmann: The IT profile should be named equal for all of them [08:16am]
bentmann: by inheriting from the parent [08:16am] i386_ left the chat room.
(i386_) [08:16am] bentmann: whether the are run by Invoker or Shitty shouldn't
matter, I guess [08:17am] jason: no, the actual project just needs a profile
name the same. not taken from the parent but stated in the project itself
[08:17am] jason: though the parent could specify that profile which just echos
"No ITs" [08:17am] jason: so in a run we would know which plugins
don't have ITs at all [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 <a
id="code">code</a></h1></section><section>
+<h1>h3. POM changes</h1></section><section>
+<h1>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.</h1><section>
+<h2>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</h2></section></section><section>
+<h1>h3. Embedding</h1></section><section>
+<h1>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].</h1></section><section>
+<h1>h3. Custom Components</h1></section><section>
+<h1>As discussed in [Substituting of Custom
Components|http://docs.codehaus.org/display/MAVEN/Substitution+of+Custom+Maven+Components]
we now have two ways to insert new components into the system.</h1><section>
+<h2>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.</h2></section></section><section>
+<h1><a id="code">code</a> main is org.apache.maven.cli.MavenCli from
plexus.core </h1></section><section>
+<h1>set maven.home default $<a id="user.home">user.home</a>/m2
</h1><figure><img src="plexus.core" alt="" /><figcaption> load $<a
id="maven.home">maven.home</a>/tycho/*.jar load $<a
id="maven.home">maven.home</a>/lib/*.jar <a
id="code">code</a></figcaption></figure><section>
+<h2>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.</h2></section></section><section>
+<h1>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.</h1></section><section>
+<h1>h3. Mercury</h1></section><section>
+<h1>Mercury is a replacement for the current Maven Artifact subsystem, and a
complete replacement for the HTTP and DAV portions of the existing
transport.</h1></section><section>
+<h1>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. </h1></section><section>
+<h1>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:</h1><section>
+<h2>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.</h2></section><section>
+<h2>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.
</h2></section><section>
+<h2>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.</h2></section></section><section>
+<h1>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. </h1></section><section>
+<h1>h3. Plugin API * 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)</h1></section><section>
+<h1>h3. Core Refactorings * Project Builder
([architecture|http://docs.codehaus.org/display/MAVENUSER/Project+Builder]) **
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://jira.codehaus.org/browse/MNG-3530]) ** Mixin support --
allowing a paramterizable template which can be imported with one
line.</h1><section>
+<h2>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</h2></section></section><section>
+<h1>h3. Java 5</h1></section><section>
+<h1>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.</h1></section><section>
+<h1>h3. Integration and promotion of scriptable plugins</h1></section><section>
+<h1>h3. Toolchains * Milos has implemented this and Shane had some feedback so
this needs to be linked together</h1></section><section>
+<h1>h3. Reporting * 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.</h1></section><section>
+<h1>h1. Other Use Cases to Integrate</h1></section><section>
+<h1>h2. Determining project type in Eclipse (Igor
Fedorenko)</h1></section><section>
+<h1>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.</h1></section><section>
+<h1>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</h1></section><section>
+<h1>1 the project ArtifactHandler language=java</h1></section><section>
+<h1>and</h1></section><section>
+<h1>2.1 ArtifactHandler addedToClasspath=true</h1></section><section>
+<h1>or</h1></section><section>
+<h1>2.2 MavenProject.getCompileSourceRoots().size() >
0</h1></section><section>
+<h1>or</h1></section><section>
+<h1>2.3 MavenProject.getTestCompileSourceRoots().size() >
0</h1></section><section>
+<h1>(in other words the project is java and either itself is added to
classpath or has sources to compile).</h1></section><section>
+<h1>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.</h1><section>
+<h2>Extensions ** Different categories of extensions: providers vs packaging
vs PMD/Checkstyle resources stuff in a JAR ** Transparent Extension Loading ***
Any Wagon or SCM providers should get picked up automatically from SCM and
distributionManagement URLs *** Any extensions containing packaging/lifecycle
related bits needs to be picked up automatically</h2></section></section>
</main>
</div>
</div>
Modified: maven/website/content/configure.html
==============================================================================
--- maven/website/content/configure.html (original)
+++ maven/website/content/configure.html Sat Feb 18 20:40:58 2023
@@ -150,22 +150,22 @@ under the License.
<p>The configuration for Apache Maven usage itself and projects built with
resides
in a number of places:</p><section>
-<h2><code>MAVEN_OPTS</code> environment variable</h2>
+<h2><code>MAVEN_OPTS</code> environment variable:</h2>
<p>This variable contains parameters used to start up the JVM running Maven and
can be used to supply additional options to it. E.g. JVM memory
settings could be defined with the value <code>-Xms256m
-Xmx512m</code>.</p></section><section>
-<h2><code>MAVEN_ARGS</code> environment variable</h2>
+<h2><code>MAVEN_ARGS</code> environment variable:</h2>
<p>Starting with Maven 3.9.0, this variable contains arguments passed to Maven
before
CLI arguments. E.g., options and goals could be defined with the value
<code>-B -V checkstyle:checkstyle</code>.</p></section><section>
-<h2><code>settings.xml</code> file</h2>
+<h2><code>settings.xml</code> file:</h2>
<p>Located in USER_HOME/.m2 the settings files is designed to contain any
configuration for Maven usage across projects.</p></section><section>
-<h2><code>.mvn</code> directory</h2>
+<h2><code>.mvn</code> directory:</h2>
<p>Located within the project's top level directory, the files
<code>maven.config</code>, <code>jvm.config</code>, and
<code>extensions.xml</code>
contain project specific configuration for running Maven.</p>
<p>This directory is part of the project and may be checked in into your
version control.</p><section>
-<h3><code>.mvn/extensions.xml</code> file</h3>
+<h3><code>.mvn/extensions.xml</code> file:</h3>
<p>The old way (up to Maven 3.2.5) was to create a jar (must be shaded if you
have other dependencies) which contains the extension and put
it manually into the <code>${MAVEN_HOME}/lib/ext</code> directory. This means
you had to change the Maven installation. The consequence was that everyone
who likes to use this needed to change it’s installation and makes the
on-boarding for a developer much more inconvenient. The other
@@ -183,7 +183,7 @@ options to your Maven build every time y
</extensions>
</code></pre></div>
<p>Now you can simply use an extension by defining the usual maven coordinates
groupId, artifactId, version as any other artifact. Furthermore all transitive
dependencies of those extensions will automatically being downloaded from your
repository. So no need to create a shaded artifact
anymore.</p></section><section>
-<h3><code>.mvn/maven.config</code> file</h3>
+<h3><code>.mvn/maven.config</code> file:</h3>
<p>It’s really hard to define a general set of options for calling the
maven command line. Starting with Maven 3.3.1+, this can be solved by
putting this
options to a script but this can now simple being done by defining
<code>${maven.projectBasedir}/.mvn/maven.config</code> file which contains the
@@ -196,7 +196,7 @@ The <code>${maven.projectBasedir}/.mvn/m
-U
--fail-at-end
</code></pre></div></section><section>
-<h3><code>.mvn/jvm.config</code> file</h3>
+<h3><code>.mvn/jvm.config</code> file:</h3>
<p>Starting with Maven 3.3.1+ you can define JVM configuration via
<code>${maven.projectBasedir}/.mvn/jvm.config</code> file which means you can
define the options for your build on a per project base. This file will become
part of your project and will be checked in along with your project. So no need
anymore for <code>MAVEN_OPTS</code>, <code>.mavenrc</code> files. So for
example if you put the following JVM options into the
<code>${maven.projectBasedir}/.mvn/jvm.config</code> file</p>
<div class="source"><pre class="prettyprint linenums"><code>-Xmx2048m
-Xms1024m -XX:MaxPermSize=512m -Djava.awt.headless=true
Modified: maven/website/content/developers/committer-environment.html
==============================================================================
--- maven/website/content/developers/committer-environment.html (original)
+++ maven/website/content/developers/committer-environment.html Sat Feb 18
20:40:58 2023
@@ -2,7 +2,7 @@
<!--
- | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
content/markdown/developers/committer-environment.md at 2023-02-18
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
content/apt/developers/committer-environment.apt at 2023-02-18
| Rendered using Apache Maven Fluido Skin 1.11.1
-->
<html xmlns="http://www.w3.org/1999/xhtml"; lang="">
@@ -48,7 +48,7 @@
<ul class="breadcrumb">
<li class=""><a href="https://www.apache.org/"; class="externalLink"
title="Apache">Apache</a><span class="divider">/</span></li>
<li class=""><a href="../index.html" title="Maven">Maven</a><span
class="divider">/</span></li>
- <li class="active ">Developers centre - Committer Environment <a
href="https://github.com/apache/maven-site/tree/master/content/markdown/developers/committer-environment.md";><img
src="../images/accessories-text-editor.png" title="Edit" /></a></li>
+ <li class="active ">Developers centre - Committer Environment <a
href="https://github.com/apache/maven-site/tree/master/content/apt/developers/committer-environment.apt";><img
src="../images/accessories-text-editor.png" title="Edit" /></a></li>
<li id="publishDate" class="pull-right"><span class="divider">|</span>
Last Published: 2023-02-18</li>
<li class="pull-right"><span class="divider">|</span>
<a href="../scm.html" title="Get Sources">Get Sources</a></li>
@@ -140,41 +140,19 @@
</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><section>
-<h2>Committer Environment</h2><section>
-<h3>Introduction</h3>
+<section>
+<h1>Committer Environment</h1><section>
+<h2>Introduction</h2>
<p>This document describes how to set up the Maven committer
environment.</p></section><section>
-<h3>Source File Encoding</h3>
+<h2>Source File Encoding</h2>
<p>When editing source files, make sure you use the right file encoding. For
the Maven project, UTF-8 has been chosen as the default file encoding. UTF-8 is
an encoding scheme for the Unicode character set that can encode all characters
that Java can handle. The source files should not contain the byte order mark
(BOM). There are exceptions to this general rule. For instance, properties
files are encoded using ISO-8859-1 as per the JRE API, so please keep this in
mind, too.</p></section><section>
-<h3>Maven Code Style</h3>
+<h2>Maven Code Style</h2>
<p>Refer to <a href="./conventions/code.html">Maven Code Style And Code
Conventions</a></p></section><section>
-<h3>Useful software</h3>
+<h2>Useful software</h2>
<p>The Maven Team uses assorted software. Here is a partial list:</p>
<ul>
-
-<li>
-<p><a href="https://www.cygwin.com/"; class="externalLink">Cygwin</a>:
collection of free software tools that allow various versions of Microsoft
Windows to act somewhat like a Unix system</p></li>
-<li>
-<p><a href="https://www.gnupg.org/"; class="externalLink">GnuPG</a>: GNU
Privacy Guard.</p></li>
-</ul></section></section></section>
+<li><a class="externalLink" href="https://www.cygwin.com/";>Cygwin</a>:
collection of free software tools that allow various versions of Microsoft
Windows to act somewhat like a Unix system</li>
+<li><a class="externalLink" href="https://www.gnupg.org/";>GnuPG</a>: GNU
Privacy Guard.</li></ul></section></section>
</main>
</div>
</div>
Modified: maven/website/content/developers/committer-settings.html
==============================================================================
--- maven/website/content/developers/committer-settings.html (original)
+++ maven/website/content/developers/committer-settings.html Sat Feb 18
20:40:58 2023
@@ -2,7 +2,7 @@
<!--
- | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
content/markdown/developers/committer-settings.md at 2023-02-18
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
content/apt/developers/committer-settings.apt at 2023-02-18
| Rendered using Apache Maven Fluido Skin 1.11.1
-->
<html xmlns="http://www.w3.org/1999/xhtml"; lang="">
@@ -10,7 +10,8 @@
<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-M4"
/>
- <meta name="author" content="Vincent Siveton, Dennis Lundberg" />
+ <meta name="author" content="Vincent Siveton
+Dennis Lundberg" />
<meta name="date" content="2011-05-23" />
<title>Maven – Developers centre - Committer Settings</title>
<link rel="stylesheet" href="../css/apache-maven-fluido-1.11.1.min.css" />
@@ -48,7 +49,7 @@
<ul class="breadcrumb">
<li class=""><a href="https://www.apache.org/"; class="externalLink"
title="Apache">Apache</a><span class="divider">/</span></li>
<li class=""><a href="../index.html" title="Maven">Maven</a><span
class="divider">/</span></li>
- <li class="active ">Developers centre - Committer Settings <a
href="https://github.com/apache/maven-site/tree/master/content/markdown/developers/committer-settings.md";><img
src="../images/accessories-text-editor.png" title="Edit" /></a></li>
+ <li class="active ">Developers centre - Committer Settings <a
href="https://github.com/apache/maven-site/tree/master/content/apt/developers/committer-settings.apt";><img
src="../images/accessories-text-editor.png" title="Edit" /></a></li>
<li id="publishDate" class="pull-right"><span class="divider">|</span>
Last Published: 2023-02-18</li>
<li class="pull-right"><span class="divider">|</span>
<a href="../scm.html" title="Get Sources">Get Sources</a></li>
@@ -140,32 +141,13 @@
</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><section>
-<h2>Introduction</h2>
+<section>
+<h1>Introduction</h1>
<p>This document is intended to set up the Maven committer settings, i.e. the
<code>${user.home}/.m2/settings.xml</code>.</p><section>
-<h3>Enable Apache Servers</h3>
+<h2>Enable Apache Servers</h2>
<p>Maven uses several servers configuration to deploy snapshots and releases
on the Apache servers. You need to tell to Maven what your Apache username
is.</p>
-<p><strong>It is highly recommended to use Maven's <a
href="../guides/mini/guide-encryption.html">password encryption
capabilities</a> for your passwords</strong>.</p>
-
-<div class="source"><pre class="prettyprint linenums"><code
class="language-xml"><settings>
+<p><b>It is highly recommended to use Maven's <a
href="../guides/mini/guide-encryption.html"> password encryption
capabilities</a> for your passwords</b>.</p>
+<div class="source"><pre class="prettyprint linenums"><settings>
...
<servers>
<!-- To publish a snapshot of some part of Maven -->
@@ -182,12 +164,10 @@ under the License.
</server>
...
</servers>
-</settings>
-</code></pre></div></section><section>
-<h3>Enable sending announcement e-mails</h3>
+</settings></pre></div></section><section>
+<h2>Enable sending announcement e-mails</h2>
<p>To be able to send out announcements of Maven releases you need to add a
couple of properties to the <code>apache-release</code> profile.</p>
-
-<div class="source"><pre class="prettyprint linenums"><code
class="language-xml"><settings>
+<div class="source"><pre class="prettyprint linenums"><settings>
...
<profiles>
<profile>
@@ -199,8 +179,7 @@ under the License.
</profile>
...
</profiles>
-</settings>
-</code></pre></div></section></section></section>
+</settings></pre></div></section></section>
</main>
</div>
</div>
Modified: maven/website/content/developers/compatibility-plan.html
==============================================================================
--- maven/website/content/developers/compatibility-plan.html (original)
+++ maven/website/content/developers/compatibility-plan.html Sat Feb 18
20:40:58 2023
@@ -2,7 +2,7 @@
<!--
- | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
content/markdown/developers/compatibility-plan.md at 2023-02-18
+ | Generated by Apache Maven Doxia Site Renderer 2.0.0-M4 from
content/apt/developers/compatibility-plan.apt at 2023-02-18
| Rendered using Apache Maven Fluido Skin 1.11.1
-->
<html xmlns="http://www.w3.org/1999/xhtml"; lang="">
@@ -48,7 +48,7 @@
<ul class="breadcrumb">
<li class=""><a href="https://www.apache.org/"; class="externalLink"
title="Apache">Apache</a><span class="divider">/</span></li>
<li class=""><a href="../index.html" title="Maven">Maven</a><span
class="divider">/</span></li>
- <li class="active ">Maven Plugins Compatibility Plan <a
href="https://github.com/apache/maven-site/tree/master/content/markdown/developers/compatibility-plan.md";><img
src="../images/accessories-text-editor.png" title="Edit" /></a></li>
+ <li class="active ">Maven Plugins Compatibility Plan <a
href="https://github.com/apache/maven-site/tree/master/content/apt/developers/compatibility-plan.apt";><img
src="../images/accessories-text-editor.png" title="Edit" /></a></li>
<li id="publishDate" class="pull-right"><span class="divider">|</span>
Last Published: 2023-02-18</li>
<li class="pull-right"><span class="divider">|</span>
<a href="../scm.html" title="Get Sources">Get Sources</a></li>
@@ -140,63 +140,32 @@
</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><section>
-<h2>Maven Plugins Compatibility Plan</h2><section>
-<h3>Scope</h3>
+<section>
+<h1>Maven Plugins Compatibility Plan</h1><section>
+<h2>Scope</h2>
<p>This page describes the system requirements plan, which consists of:</p>
-<p>1 minimum <strong>Java</strong> runtime prerequisite for Maven plugins,
which can be extended to shared components,</p>
-<p>1 minimum <strong>Maven</strong> runtime prerequisite for plugins.</p>
-<p>Such requirements are displayed as “System Requirements” in
every plugin info report (see <a
href="/plugins/maven-clean-plugin/plugin-info.html">this example</a>).</p>
-<p>Consolidated view for all LATEST plugins release is visible in a <a
href="https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html";
class="externalLink">daily generated report</a>.</p></section><section>
-<h3>Maven Plan</h3>
+<ol style="list-style-type: decimal">
+<li>minimum <b>Java</b> runtime prerequisite for Maven plugins, which can be
extended to shared components,</li>
+<li>minimum <b>Maven</b> runtime prerequisite for plugins.</li></ol>
+<p>Such requirements are displayed as "System Requirements" in every
plugin info report (see <a
href="/plugins/maven-clean-plugin/plugin-info.html">this example</a>).</p>
+<p>Consolidated view for all LATEST plugins release is visible in a <a
class="externalLink"
href="https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html";>daily
generated report</a>.</p></section><section>
+<h2>Maven Plan</h2>
<ul>
-
-<li>
-<p>Until 2012, Maven 2.2.1 + Java 5 prerequisites, with plugins versions in
2.x</p></li>
-<li>
-<p>Since 2012, Maven 3.0 + Java 7 prerequisites, with plugins in 3.x.y</p></li>
-<li>
-<p>Since June 2020, Maven Plugin API used by plugins >= 3.1.0 + Java 8
prerequisites <a href="https://s.apache.org/MVN-PLUGIN-MIGRATION-3.1";
class="externalLink">Technical details</a></p></li>
-</ul></section><section>
-<h3>Context</h3>
+<li>Until 2012, Maven 2.2.1 + Java 5 prerequisites, with plugins versions in
2.x</li>
+<li>Since 2012, Maven 3.0 + Java 7 prerequisites, with plugins in 3.x.y</li>
+<li>Since June 2020, Maven Plugin API used by plugins >= 3.1.0 + Java 8
prerequisites <a class="externalLink"
href="https://s.apache.org/MVN-PLUGIN-MIGRATION-3.1";>Technical
details</a></li></ul></section><section>
+<h2>Context</h2>
<ul>
-
-<li>
-<p>Maven core history with Java prerequisite is available in the <a
href="/docs/history.html">release notes</a></p></li>
-<li>
-<p>JDK/JRE availability dates:</p></li>
-<li>
-<p>Java 5 (2004) is closed source, End of Public Update in 2009</p></li>
-<li>
-<p>Java 6 (2006) is Open Source, maintained at OpenJDK until 2018</p></li>
-<li>
-<p>Java 7 (2011) is Open Source, maintained <a
href="https://wiki.openjdk.java.net/display/jdk7u"; class="externalLink">at
OpenJDK</a> at least until June 2020</p></li>
-<li>
-<p>Java 8 (2014) is Open Source, maintained <a
href="https://wiki.openjdk.java.net/display/jdk8u"; class="externalLink">at
OpenJDK</a> at least until September 2023</p></li>
-<li>
-<p>Java 11 (LTS, 2018) is Open Source, maintained <a
href="https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u";
class="externalLink">at OpenJDK</a> at least until September 2025</p></li>
-<li>
-<p>see <a href="https://javaalmanac.io/jdk/"; class="externalLink">Java Version
Almanac</a> for updated JDK releases</p></li>
-</ul>
-<p>see also <a
href="https://docs.google.com/document/d/1nFGazvrCvHMZJgFstlbzoHjpAVwv5DEdnaBr_5pKuHo";
class="externalLink">Java Is Still Free</a> for more
details</p></section></section></section>
+<li>Maven core history with Java prerequisite is available in the <a
href="/docs/history.html">release notes</a></li>
+<li>JDK/JRE availability dates:
+<ul>
+<li>Java 5 (2004) is closed source, End of Public Update in 2009</li>
+<li>Java 6 (2006) is Open Source, maintained at OpenJDK until 2018</li>
+<li>Java 7 (2011) is Open Source, maintained <a class="externalLink"
href="https://wiki.openjdk.java.net/display/jdk7u";>at OpenJDK</a> at least
until June 2020 </li>
+<li>Java 8 (2014) is Open Source, maintained <a class="externalLink"
href="https://wiki.openjdk.java.net/display/jdk8u";>at OpenJDK</a> at least
until September 2023</li>
+<li>Java 11 (LTS, 2018) is Open Source, maintained <a class="externalLink"
href="https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u";>at OpenJDK</a>
at least until September 2025</li>
+<li>see <a class="externalLink" href="https://javaalmanac.io/jdk/";>Java
Version Almanac</a> for updated JDK releases</li></ul>
+<p>see also <a class="externalLink"
href="https://docs.google.com/document/d/1nFGazvrCvHMZJgFstlbzoHjpAVwv5DEdnaBr_5pKuHo";>Java
Is Still Free</a> for more details</p></li></ul></section></section>
</main>
</div>
</div>
