content/xdoc/docs-required.xml - maven-site - Git at Google

 <?xml version="1.0"?>

 <!--
   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.
 -->

 <document xmlns="http://maven.apache.org/XDOC/2.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 https://maven.apache.org/xsd/xdoc-2.0.xsd">
 <!-- TODO: include back into site, after checking which are complete, add to instructions on how to contribute docs -->
   <properties>
     <title>Documentation Required</title>
     <author email="brett@apache.org">Brett Porter</author>
   </properties>
   <body>
     <section name="Documentation Required">
       <p>
         This page lists some of the most pressing documentation needs. If you feel something is missing, please be sure
         to let us know at the
         <a href="./mailing-lists.html">Maven Users Mailing List</a>.
       </p>
       <h4>Documentation for users</h4>
       <ul>
         <li>new SNAPSHOT handling -
           <i>partially done on Brett's blog</i>
         </li>
         <li>guide to dependencies, including:
           <ul>
             <li>dependency scoping - <i>especially system scope</i></li>
             <li>version range specifications</li>
             <li>conflict resolution</li>
           </ul>
         </li>
         <li>deployment mechanism</li>
         <li>dependency management</li>
         <li>plugin management -
           <i>in progress by J Matthew Pryor and John Casey</i>
         </li>
         <li>plugin configuration</li>
         <li>plugin downloading -
           <i>partial on Brett's blogs</i>
         </li>
         <li>report generation</li>
         <li>project inheritence and company wide strategy</li>
         <li>plugin documentation</li>
         <li>using POM-properties in conjunction with plugin configuration to abstract child-POM configs</li>
         <li>archetypes - writing and using</li>
         <li>plugin usage guide/summary for core plugins - <i>esp. release plugin</i></li>
         <li>strategy for migrating from Ant builds</li>
         <li>strategy for migrating from Maven 1.x builds - <i>esp. plugins that don't convert directly</i></li>
       </ul>
       <h4>Documentation for plugin authors</h4>
       <ul>
         <li>Beanshell examples</li>
         <li>plugin writing guide</li>
         <li>report writing guide</li>
         <li>site customisation guide</li>
         <li>common tips and tricks for accessing project/build data</li>
         <li>guide to available parameter expressions</li>
         <li>list of standards for submitting new plugins (minimum documentation, test coverage?)</li>
       </ul>
       <h4>Documentation for Maven developers</h4>
       <ul>
         <li>Lifecycle architecture</li>
         <li>High level architecture, components explanation</li>
         <li>Intro to Plexus</li>
         <li>contributors guide (add to current and consolidate, walk through some first steps)</li>
       </ul>
       <h4>Additional Notes</h4>
       <pre>
         Brett Porter wrote:
         > The active project changes during the reactor build. At the compile
         > stage, it refers to the target/classes directory. At the package
         > stage, it points to the jar file. If you are implementing your own
         > packaging goal, you need to call project.getArtifact().setFile( ... )
         > to ensure this is used.

         - multi module howto
         - per user scm setup
           - outline behaviour when connection and developConnection are defined

            Our current URL looks like:
            scm:cvs:pserver:@cvs.host.name:/cvsroot:module-version

            Using this URL, the default is to connect to the CVS server using the
            same userid as the current user.  This is the desired behavior and I
            don't want to mess that up.  I just would like a means to add a userid
            in the URL only in special circumstances like Continuum.

            We might want to do something where we say it is a best practice to
            specify a ${user} and take it from the environment and allow an override.

         - testing a plugin
         - How to get started behind an NTLM proxy.
         - How snapshots works
         - How do i use the lifecycle provided by a plugin:
         - How do i disable ibiblio
         - using version ranges
         - plugin expressions (look at bob allison's work)
         - overriding the central repository (use central)
         - description of what packagings are available and how they work
         - creating upload bundles
         - modello example
         - changing the snapshot policy frequency
         - overriding central repo
         - using POM info in applications: the POM is packaged so there is acccess
           continuum example to get the version.
         - quick description of scm,wagon,continuum
       </pre>
       <h4>Profiles Example</h4>
       <pre><![CDATA[
 it's possible to do it with m2 beta-1 and profiles.

 you declare profile in your pom like this:

    <profiles>
      <profile>
        <id>env-test</id>
        <activation>
          <property>
            <name>env</name>
            <value>test</value>
          </property>
        </activation>
        <properties>
          <appProperties>test.properties</appProperties>
        </properties>
      </profile>
      <profile>
        <id>env-production</id>
        <activation>
          <property>
            <name>env</name>
            <value>production</value>
          </property>
        </activation>
        <properties>
          <appProperties>app.properties</appProperties>
        </properties>
      </profile>
    </profiles>

 and you can run mvn with one of profiles like:
 mvn -P env-production clean:clean install ==> we use the profile id
 or
 mvn -Denv=test clean:clean install ==> we use the property env define in
 <activation>

 Emmanuel

 martin.kuhn@merkur.at wrote:
 > Hi,
 >
 > I'm a maven newbie and I try out maven 2.0 alpha 3.
 >
 > My questions:
 >
 > I have a project to build / deploy for three different enviroments (test,
 > integration, production).
 >
 > The difference beetween the bundles is only a properties file (there are
 > three different files: config-test.properties,
 > config-integration.properties ...).
 > In the build process I want to copy the right config file to a file with a
 > common name (config.properties -> the app should work with this config
 > file)
 >
 > Is there a solution to handle this with maven 2 or do I have to write a
 > plugin?
 >
         ]]>
       </pre>
     </section>
   </body>
 </document>
	<?xml version="1.0"?>

	<!--
	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.
	-->

	<document xmlns="http://maven.apache.org/XDOC/2.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 https://maven.apache.org/xsd/xdoc-2.0.xsd">
	<!-- TODO: include back into site, after checking which are complete, add to instructions on how to contribute docs -->
	<properties>
	<title>Documentation Required</title>
	<author email="brett@apache.org">Brett Porter</author>
	</properties>
	<body>
	<section name="Documentation Required">
	<p>
	This page lists some of the most pressing documentation needs. If you feel something is missing, please be sure
	to let us know at the
	<a href="./mailing-lists.html">Maven Users Mailing List</a>.
	</p>
	<h4>Documentation for users</h4>
	<ul>
	<li>new SNAPSHOT handling -
	<i>partially done on Brett's blog</i>
	</li>
	<li>guide to dependencies, including:
	<ul>
	<li>dependency scoping - <i>especially system scope</i></li>
	<li>version range specifications</li>
	<li>conflict resolution</li>
	</ul>
	</li>
	<li>deployment mechanism</li>
	<li>dependency management</li>
	<li>plugin management -
	<i>in progress by J Matthew Pryor and John Casey</i>
	</li>
	<li>plugin configuration</li>
	<li>plugin downloading -
	<i>partial on Brett's blogs</i>
	</li>
	<li>report generation</li>
	<li>project inheritence and company wide strategy</li>
	<li>plugin documentation</li>
	<li>using POM-properties in conjunction with plugin configuration to abstract child-POM configs</li>
	<li>archetypes - writing and using</li>
	<li>plugin usage guide/summary for core plugins - <i>esp. release plugin</i></li>
	<li>strategy for migrating from Ant builds</li>
	<li>strategy for migrating from Maven 1.x builds - <i>esp. plugins that don't convert directly</i></li>
	</ul>
	<h4>Documentation for plugin authors</h4>
	<ul>
	<li>Beanshell examples</li>
	<li>plugin writing guide</li>
	<li>report writing guide</li>
	<li>site customisation guide</li>
	<li>common tips and tricks for accessing project/build data</li>
	<li>guide to available parameter expressions</li>
	<li>list of standards for submitting new plugins (minimum documentation, test coverage?)</li>
	</ul>
	<h4>Documentation for Maven developers</h4>
	<ul>
	<li>Lifecycle architecture</li>
	<li>High level architecture, components explanation</li>
	<li>Intro to Plexus</li>
	<li>contributors guide (add to current and consolidate, walk through some first steps)</li>
	</ul>
	<h4>Additional Notes</h4>
	<pre>
	Brett Porter wrote:
	> The active project changes during the reactor build. At the compile
	> stage, it refers to the target/classes directory. At the package
	> stage, it points to the jar file. If you are implementing your own
	> packaging goal, you need to call project.getArtifact().setFile( ... )
	> to ensure this is used.

	- multi module howto
	- per user scm setup
	- outline behaviour when connection and developConnection are defined

	Our current URL looks like:
	scm:cvs:pserver:@cvs.host.name:/cvsroot:module-version

	Using this URL, the default is to connect to the CVS server using the
	same userid as the current user. This is the desired behavior and I
	don't want to mess that up. I just would like a means to add a userid
	in the URL only in special circumstances like Continuum.

	We might want to do something where we say it is a best practice to
	specify a ${user} and take it from the environment and allow an override.

	- testing a plugin
	- How to get started behind an NTLM proxy.
	- How snapshots works
	- How do i use the lifecycle provided by a plugin:
	- How do i disable ibiblio
	- using version ranges
	- plugin expressions (look at bob allison's work)
	- overriding the central repository (use central)
	- description of what packagings are available and how they work
	- creating upload bundles
	- modello example
	- changing the snapshot policy frequency
	- overriding central repo
	- using POM info in applications: the POM is packaged so there is acccess
	continuum example to get the version.
	- quick description of scm,wagon,continuum
	</pre>
	<h4>Profiles Example</h4>
	<pre><![CDATA[
	it's possible to do it with m2 beta-1 and profiles.

	you declare profile in your pom like this:

	<profiles>
	<profile>
	<id>env-test</id>
	<activation>
	<property>
	<name>env</name>
	<value>test</value>
	</property>
	</activation>
	<properties>
	<appProperties>test.properties</appProperties>
	</properties>
	</profile>
	<profile>
	<id>env-production</id>
	<activation>
	<property>
	<name>env</name>
	<value>production</value>
	</property>
	</activation>
	<properties>
	<appProperties>app.properties</appProperties>
	</properties>
	</profile>
	</profiles>

	and you can run mvn with one of profiles like:
	mvn -P env-production clean:clean install ==> we use the profile id
	or
	mvn -Denv=test clean:clean install ==> we use the property env define in
	<activation>

	Emmanuel

	martin.kuhn@merkur.at wrote:
	> Hi,
	>
	> I'm a maven newbie and I try out maven 2.0 alpha 3.
	>
	> My questions:
	>
	> I have a project to build / deploy for three different enviroments (test,
	> integration, production).
	>
	> The difference beetween the bundles is only a properties file (there are
	> three different files: config-test.properties,
	> config-integration.properties ...).
	> In the build process I want to copy the right config file to a file with a
	> common name (config.properties -> the app should work with this config
	> file)
	>
	> Is there a solution to handle this with maven 2 or do I have to write a
	> plugin?
	>
	]]>
	</pre>
	</section>
	</body>
	</document>