Hey Guys,
Just wanted to make sure you see this.
JPackage provides a Maven distribution.
They are doing stuff to update the default
configuration, etc. which is part of what we discussed
for our "Repository Trust" goals.
In general I think a custom maven RPM package would be
ideal for us.
We create the baseline configuration the way we want
it so that predictability is ensured.
We could even RPM repositories, such that the
repository RPM would provide the baseline for a build
at a certain point in time, providing a guaranteed
starting point.
It looks like Deepak is the one working on this for
JPackage.
One of the things the Maven plugin should support is
the generation of multiple baseline configurations of
a certain package.
That will help us add additional settings, post
Deepaks sensible defaults. Thus our build
configuration would evolve along with ADS's needs,
while minimizing management overhead.
Cheers,
- Ole
Note: forwarded message attached.
____________________________________________________________________________________
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates
(http://voice.yahoo.com)
--- Begin Message ---
On Mon, 2006-10-30 at 17:07 +0100, Deepak Bhole wrote:
> Name : maven2 Relocations: (not relocatable)
> Version : 2.0.4 Vendor: JPackage Project
> Release : 9jpp Build Date: Fri 27 Oct 2006
> 10:53:28 PM CEST
> Install Date: (not installed) Build Host:
> to-jpackage2.toronto.redhat.com
> Group : Development/Build Tools Source RPM: (none)
> Size : 3903516 License: Apache Software License
> Signature : (none)
> Packager : Deepak Bhole <[EMAIL PROTECTED]>
> URL : http://maven.apache.org/
> Summary : Java project management and project comprehension tool.
> Description :
> Maven is a software project management and comprehension tool. Based on the
> concept of a project object model (POM), Maven can manage a project's build,
> reporting and documentation from a central piece of information.
>
> ---------------
> Deepak Bhole <[EMAIL PROTECTED]> 2.0.4-9jpp
> - Added a new mapping system
> - Added a jpp howto
> - Added support for plugin mixing
> - Wired in /usr/share/maven2/repository as one of the default repos
> ---------------
> W: maven2 summary-ended-with-dot Java project management and project
> comprehension tool.
> W: maven2 strange-permission maven2-script 0775
> W: maven2 strange-permission maven2-jpp-script 0775
> W: maven2 patch-not-applied Patch7: %{name}-jpp-mapping.patch
> W: maven2 uncompressed-zip /maven2-empty-dep.jar
> E: maven2 no-jar-manifest /maven2-empty-dep.jar
>
<snipped due to size>
Hi All,
This is now expected to be a stable version (in terms of major changes)
of maven2. It is backwards compatible with the older (8jpp) maven2, so
existing projects built around maven 8jpp will work fine. It is
recommended though that eventually, all packages should be designed to
work around 9jpp. This is for 2 reasons:
1. It is a lot easier to work with 9jpp
2. It will make it easier to build other dependent packages around the
package, as it will minimize the need for depmaps.
I added a readme to it that briefly mentions how 9jpp works. I am
attaching the text this message. Let me know if you have any questions.
PS: You can look at plexus-cdc, maven-doxia, maven-jxr, modello, etc. to
see how to build with maven2-2.0.4-9jpp.
Cheers,
Deepak
======
README
======
Notes on the JPackage version of Maven2 (2.0.4)
The maven2 version released with JPackage has extensive modifications to
ensure that it works smoothly in off-line mode. In order to facilitate
easier maintainability, minimal changes have been made, and most have
been kept in separate source files rather than patching into maven code.
How to use it:
Previously, when one needed to create a new rpm, for the build part they
needed to set up a depmap, run all poms in a project via an xsl
transformation that used the depmap to rewrite
groupid's/artifactid's/etc., supply repository locations, and then call
maven. Most of that has now been done away with.
Starting with the 9jpp release, to invoke maven in jpp mode, simply type
'mvn-jpp' with the -Dmaven2.jpp.depmap.file="..." argument if a separate
depmap is needed. The command action is almost the same as "mvn" -- only
that it supplies '-Dmaven2.offline.mode -Dmaven2.ignore.versions
-Dmaven2.usejppjars' prior to invoking maven.
Dependency maps/'depmaps':
To build a new project for a new JPackage rpm, a depmap still needs to
be created so as to allow finding of the new jars. But this is not too
different from the old way of using build-jar-repository with ant. The
idea is the same -- tell the build tool where to find the required
libraries.
The depmap has entries in the format:
<dependencies>
..
<dependency>
<maven>
<groupId>OGROUPID</groupId>
<artifactId>OARTIFACTID</artifactId>
<version>OVERSION</version>
</maven>
<jpp>
<groupId>NGROUPID</groupId>
<artifactId>NARTIFACTID</artifactId>
<version>NVERSION</version>
</jpp>
</dependency>
..
<dependencies>
Where OGROUPID, OARTIFACTID and OVERSION are old group/artifact/versions
(as they exist in your project) and NGROUPID, NARTIFACTID, NVERSION are
the new ones. For example:
<dependency>
<maven>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
</maven>
<jpp>
<groupId>JPP</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
</jpp>
</dependency>
The above mapping indicates that if any of the poms need an artifact
with groupid=junit, artifactid=junit and version=3.8.1, it can be found
at $REPOSITORY/JPP/junit.jar Where $REPOSITORY is one of the active
repositories with layout="jpp" ("jpp" is a new layout that has been
added to our maven2 rpm).
If maven2.ignore.versions is specified, any requirement of
groupid=junit, artifactid=junit will be satisfied with
$REPOSITORY/JPP/junit.jar (i.e. version will be ignored even if
mentioned in the depmap).
If only a <maven> element is supplied and no <jpp>, it is assumed that
the dependency is to be discarded. For example, some projects depend on
the 'velocity-dep' which has no equivalent jar in JPackage packages as
velocity-dep is just a monolithic jar containing velocity dependencies.
To remove velocity-dep then, you would add:
<dependency>
<maven>
<groupId>velocity</groupId>
<artifactId>velocity-dep</artifactId>
<version>1.4</version>
</maven>
</dependency>
to the depmap.
There are two system depmaps. An unversioned one is located
at: /etc/maven/maven2-versionless-depmap.xml. This is used when
-Dmaven2-ignore-versions is specified. A versioned one is located
at /etc/maven/maven2-depmap.xml. This is an autogenerated map which is
rebuilt each time the update_maven_depmap macro is called by an rpm.
Finally, a custom one can be specified via
-Dmaven2.jpp.depmap.file="..."
The versionless one contains depmap entries for items whose poms are
installed by maven2-common-poms (for now). As time passes, more and more
packages will start using the add_to_maven_depmap and
update_maven_depmap macros and hopefully, the versionless can be phased
out completely. If your project needs a mapping that is not already in
there, you will have to create a separate file and use it via the above
mentioned property.
The custom depmap has highest preference, followed by the versioned
depmap, followed by the versionless one
Packages adding their own depmaps:
Packages from now on should add their own depmap fragments when they get
installed. This is achieved by calling the add_to_maven_depmap macro for
each jar/artifact being installed, followed by calling
update_maven_depmap in the post and postun sections (note: this means
that there will have to be a jpackage-utils >= 0:1.7.2 post and postun
requirement for all packages that do this, since jpackage-utils 1.7.2
provides the macros). Finally, %{_mavendepmapfragdir}
(=/etc/maven/fragments) should be added in the %files section of the
main package. The idea is as follows:
The %install section of each package uses the add_to_maven_depmap macro
for each jar/pom that the main package and it's subpackages install. The
macro puts the resulting data in $RPM_BUILD_ROOT
%{_mavendepmapfragdir}/%{name}. update_maven_depmap in the post and
postun then cat's /etc/maven/fragments/*
into /etc/maven/maven2-depmap.xml which is read whenever mvn is run. See
the plexus-cdc spec for a simple example, and maven-doxia for a more
complex one.
New properties:
- maven2.offline.mode - Combined with maven2.ignore.versions, this
switch is analogous to maven2.jpp.mode in 8jpp and lower. It tells
maven to use the pre-configured jpackage repositories.
- maven2.ignore.versions - Combined with maven2.offline.mode, this
switch is analogous to maven2.jpp.mode in 8jpp and lower. It tells
maven to ignore versions when looking at the dependency map.
- maven2.usejppjars - This is a new option. When supplied, maven will
try to use jpackage jars whenever possible. It's main intention is to
allow users to use /usr/share/java files when available, and fetch
jars from the net if not. It may be combined with the above two
- maven2.jpp.depmap.file - This option tells maven where to find the
dependency mappings.
_______________________________________________
JPackage-discuss mailing list
[EMAIL PROTECTED]
https://www.zarb.org/mailman/listinfo/jpackage-discuss
--- End Message ---
