maven-glassfishbuild-extension
Used in:
components
- OverviewOverview
- VersionsVersions
- DependentsDependents
- DependenciesDependencies
<dependency>
<groupId>org.glassfish.build</groupId>
<artifactId>maven-glassfishbuild-extension</artifactId>
<version>3.2.2</version>
</dependency><!--
DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
Copyright (c) 2010-2011 Oracle and/or its affiliates. All rights reserved.
The contents of this file are subject to the terms of either the GNU
General Public License Version 2 only ("GPL") or the Common Development
and Distribution License("CDDL") (collectively, the "License"). You
may not use this file except in compliance with the License. You can
obtain a copy of the License at
https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
or packager/legal/LICENSE.txt. See the License for the specific
language governing permissions and limitations under the License.
When distributing the software, include this License Header Notice in each
file and include the License file at packager/legal/LICENSE.txt.
GPL Classpath Exception:
Oracle designates this particular file as subject to the "Classpath"
exception as provided by Oracle in the GPL Version 2 section of the License
file that accompanied this code.
Modifications:
If applicable, add the following below the License Header, with the fields
enclosed by brackets [] replaced by your own identifying information:
"Portions Copyright [year] [name of copyright owner]"
Contributor(s):
If you wish your version of this file to be governed by only the CDDL or
only the GPL Version 2, indicate your decision by adding "[Contributor]
elects to include this software in this distribution under the [CDDL or GPL
Version 2] license." If you don't indicate a single choice of license, a
recipient has the option to distribute your version of this file under
either the CDDL, the GPL Version 2 or to extend the choice of license to
its licensees as provided above. However, if you add GPL Version 2 code
and therefore, elected the GPL Version 2 license, then the option applies
only if the new code is made subject to such option by the copyright
holder.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<parent>
<groupId>org.glassfish.build</groupId>
<artifactId>parent-build-pom</artifactId>
<version>3.2.2</version>
<relativePath>../pom.xml</relativePath>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>maven-glassfishbuild-extension</artifactId>
<packaging>jar</packaging>
<name>Maven extension for building GlassFish</name>
<description>
GlassFish build depends on properly functioning several custom lifecycle mappings and
artifact handlers. Because these are necessary to resolve dependencies and to run
"gf:run" goal and etc., it is critical that these extensions be made available to
Maven early on during Maven execution.
This definition was originally in maven-glassfish-plugin, which was integrated
into Maven POM through <plugin>/<extensions>true marking, but after
a series of debugging to resolve artifact resolution failure problems, it turns
out that that doesn't cause Maven to load components early enough.
I tried to circumbent the prolem by also registering the maven-glassfish-plugin
as an extension module (via <build>/<extensions/<extension>), but that
apparently confuses Maven to no end --- I get build errors like this:
[INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-jar-plugin:2.1:jar': Unable to find the mojo 'org.apache.maven.plugins:maven-jar-plugin:2.1:jar' in the plugin 'org.apache.maven.plugins:maven-jar-plugin'
This is obviously one of the problematic areas of Maven, so to avoid doing hack
over hack, I'm simply moving the component definitions to its own module.
</description>
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-core</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
</project>
Open source consumption has exploded, with estimates placing this year’s downloads at over 6.6 trillion. This reliance on open source components, now making up to 90% of the modern software application, has ushered in both unprecedented innovation and complex challenges for software supply chains.
View the Report