You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by ja...@jpmorgan.com on 2006/06/29 01:47:14 UTC
How do I dynamically inject a dependency? (RePost)
As I haven't gotten any response in a few days, I thought it might help to
repost this.
I'm not sure if this is something that has already been accounted
for, or if I should submit a feature enchancement JIRA issue.
Sincerely,
James Carpenter
desk: 713-374-4374
email: james.le.carpenter@jpmorgan.com
========================================================================
I have a plugin which resolves a specified artifact, expands it into a
work area within target and then runs a code generator against contents
within the expanded artifact.
{Specifically the resolved artifact contains an XML-Schema, and the tool
being executed is a csharp xsd tool (similar to JAXB)}
The specified artifact is not an actual dependency of the plugin code,
nor is it a compiler or testing dependency of the project. That said
the specified artifact is required to build the project and should be
taken into account when maven determines a multi-project's build order.
What can the plugin do to ensure maven is aware of this specified
artifact as a build dependency, without affecting the dependencies seen
by the other plugins (compiler, etc.)?
One potential solution I have used in the past is to include the
specified artifact as a plugin dependency, but this is rather crude and
doesn't work in the general case.
Example POM snipt below:
Example assumes the com.acme.serverapp:client-schema:${project.version}
artifact contains the bigSchema.xml file. The maven-codegen-plugin is
assumed to perform the following steps:
1) resolve the specified artifact:
com.acme.serverapp:client-schema:${project.version}
2) unpack it in ${basedir}/target/csharp-workarea/maven-codegen-plugin/
3) point a code generator at the bigSchema.xml file to produce source
files in ${basedir}/target/generated-sources/maven-codegen-plugin
4) add the generated code to the MavenProject
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-codegen-plugin</artifact>
<version>1.2.3</version>
<configuration>
<schemaDependency>
<groupId>com.acme.serverapp</groupId>
<artifactId>client-schema</artifactId>
<version>${project.version}</version>
<type>jar</type> <!-- Could be any archive type. (tar,
zip, gzip, etc.)-->
<schemaFile>com/acme/serverapp/schema/bigSchema.xml</schemaFile>
</schemaDependency>
</configuration>
</plugin>
</plugins>
</build>
Assume a multiproject structure such as:
acmecode/pom.xml
acmecode/client-schema/pom.xml
acmecode/client-schema/src/main/resources/com/acme/serverapp/schema/bigSchema.xml
acmecode/schema-stubs/pom.xml #This is the pom using the plugin
As you can see, if one tries to perform a multi-module build within the
acmecode directory, its shear luck if the build order is correct.
This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
Re: How do I dynamically inject a dependency? (RePost)
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 6/29/06, dan tran <da...@gmail.com> wrote:
> I believe maven depends heavily on dependencies list to determine the
> correct order of the build
> with out that, you will need to setup that order via parent's modules
> elements.
Is that as you say? I am thinking for examples like the
maven-scm-plugin (uses another plugin for actuall access to the scm),
the maven-compiler-plugin (uses another plugin for handling the actual
compiler), the wagon stuff, ...
Are all of them actually using hard coded dependencies?
Jochen
--
Whenever you find yourself on the side of the
majority, it is time to pause and reflect.
(Mark Twain)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How do I dynamically inject a dependency? (RePost)
Posted by Brett Porter <br...@apache.org>.
Yep. This would be a worthwhile addition to JIRA for a later Maven
roadmap - we could have a tighter way of declaring dependencies for
plugins such that they can be taken into account. The current plugin >
dependencies is a bit of a hack.
So what you can do:
- use the order of the <modules> element to enforce it as dan suggested.
- possibly declare a project level dependency on the artifact, with type
pom so that it won't be used by anything else (a bit ugly but more
future proof that the first option).
Cheers,
Brett
On 29/06/2006 1:07 PM, dan tran wrote:
> I believe maven depends heavily on dependencies list to determine the
> correct order of the build
> with out that, you will need to setup that order via parent's modules
> elements.
>
> -D
>
>
> On 6/28/06, james.le.carpenter@jpmorgan.com
> <ja...@jpmorgan.com>
> wrote:
>>
>> As I haven't gotten any response in a few days, I thought it might
>> help to
>> repost this.
>>
>> I'm not sure if this is something that has already been accounted
>> for, or if I should submit a feature enchancement JIRA issue.
>>
>> Sincerely,
>> James Carpenter
>> desk: 713-374-4374
>> email: james.le.carpenter@jpmorgan.com
>>
>> ========================================================================
>> I have a plugin which resolves a specified artifact, expands it into a
>> work area within target and then runs a code generator against contents
>> within the expanded artifact.
>> {Specifically the resolved artifact contains an XML-Schema, and the tool
>> being executed is a csharp xsd tool (similar to JAXB)}
>>
>> The specified artifact is not an actual dependency of the plugin code,
>> nor is it a compiler or testing dependency of the project. That said
>> the specified artifact is required to build the project and should be
>> taken into account when maven determines a multi-project's build order.
>> What can the plugin do to ensure maven is aware of this specified
>> artifact as a build dependency, without affecting the dependencies seen
>> by the other plugins (compiler, etc.)?
>>
>> One potential solution I have used in the past is to include the
>> specified artifact as a plugin dependency, but this is rather crude and
>> doesn't work in the general case.
>>
>> Example POM snipt below:
>>
>> Example assumes the com.acme.serverapp:client-schema:${project.version}
>> artifact contains the bigSchema.xml file. The maven-codegen-plugin is
>> assumed to perform the following steps:
>> 1) resolve the specified artifact:
>> com.acme.serverapp:client-schema:${project.version}
>> 2) unpack it in ${basedir}/target/csharp-workarea/maven-codegen-plugin/
>> 3) point a code generator at the bigSchema.xml file to produce source
>> files in ${basedir}/target/generated-sources/maven-codegen-plugin
>> 4) add the generated code to the MavenProject
>>
>> <build>
>> <plugins>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-codegen-plugin</artifact>
>> <version>1.2.3</version>
>> <configuration>
>> <schemaDependency>
>> <groupId>com.acme.serverapp</groupId>
>> <artifactId>client-schema</artifactId>
>> <version>${project.version}</version>
>> <type>jar</type> <!-- Could be any archive type. (tar,
>> zip, gzip, etc.)-->
>>
>> <schemaFile>com/acme/serverapp/schema/bigSchema.xml</schemaFile>
>> </schemaDependency>
>> </configuration>
>> </plugin>
>> </plugins>
>> </build>
>>
>> Assume a multiproject structure such as:
>> acmecode/pom.xml
>> acmecode/client-schema/pom.xml
>>
>> acmecode/client-schema/src/main/resources/com/acme/serverapp/schema/bigSchema.xml
>>
>> acmecode/schema-stubs/pom.xml #This is the pom using the plugin
>>
>> As you can see, if one tries to perform a multi-module build within the
>> acmecode directory, its shear luck if the build order is correct.
>>
>>
>>
>> This communication is for informational purposes only. It is not intended
>> as an offer or solicitation for the purchase or sale of any financial
>> instrument or as an official confirmation of any transaction. All market
>> prices,
>> data and other information are not warranted as to completeness or
>> accuracy and
>> are subject to change without notice. Any comments or statements made
>> herein
>> do not necessarily reflect those of JPMorgan Chase & Co., its
>> subsidiaries
>> and affiliates.
>>
>
--
Brett Porter <br...@apache.org>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How do I dynamically inject a dependency? (RePost)
Posted by dan tran <da...@gmail.com>.
I believe maven depends heavily on dependencies list to determine the
correct order of the build
with out that, you will need to setup that order via parent's modules
elements.
-D
On 6/28/06, james.le.carpenter@jpmorgan.com <ja...@jpmorgan.com>
wrote:
>
> As I haven't gotten any response in a few days, I thought it might help to
> repost this.
>
> I'm not sure if this is something that has already been accounted
> for, or if I should submit a feature enchancement JIRA issue.
>
> Sincerely,
> James Carpenter
> desk: 713-374-4374
> email: james.le.carpenter@jpmorgan.com
>
> ========================================================================
> I have a plugin which resolves a specified artifact, expands it into a
> work area within target and then runs a code generator against contents
> within the expanded artifact.
> {Specifically the resolved artifact contains an XML-Schema, and the tool
> being executed is a csharp xsd tool (similar to JAXB)}
>
> The specified artifact is not an actual dependency of the plugin code,
> nor is it a compiler or testing dependency of the project. That said
> the specified artifact is required to build the project and should be
> taken into account when maven determines a multi-project's build order.
> What can the plugin do to ensure maven is aware of this specified
> artifact as a build dependency, without affecting the dependencies seen
> by the other plugins (compiler, etc.)?
>
> One potential solution I have used in the past is to include the
> specified artifact as a plugin dependency, but this is rather crude and
> doesn't work in the general case.
>
> Example POM snipt below:
>
> Example assumes the com.acme.serverapp:client-schema:${project.version}
> artifact contains the bigSchema.xml file. The maven-codegen-plugin is
> assumed to perform the following steps:
> 1) resolve the specified artifact:
> com.acme.serverapp:client-schema:${project.version}
> 2) unpack it in ${basedir}/target/csharp-workarea/maven-codegen-plugin/
> 3) point a code generator at the bigSchema.xml file to produce source
> files in ${basedir}/target/generated-sources/maven-codegen-plugin
> 4) add the generated code to the MavenProject
>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-codegen-plugin</artifact>
> <version>1.2.3</version>
> <configuration>
> <schemaDependency>
> <groupId>com.acme.serverapp</groupId>
> <artifactId>client-schema</artifactId>
> <version>${project.version}</version>
> <type>jar</type> <!-- Could be any archive type. (tar,
> zip, gzip, etc.)-->
>
> <schemaFile>com/acme/serverapp/schema/bigSchema.xml</schemaFile>
> </schemaDependency>
> </configuration>
> </plugin>
> </plugins>
> </build>
>
> Assume a multiproject structure such as:
> acmecode/pom.xml
> acmecode/client-schema/pom.xml
>
> acmecode/client-schema/src/main/resources/com/acme/serverapp/schema/bigSchema.xml
> acmecode/schema-stubs/pom.xml #This is the pom using the plugin
>
> As you can see, if one tries to perform a multi-module build within the
> acmecode directory, its shear luck if the build order is correct.
>
>
>
> This communication is for informational purposes only. It is not intended
> as an offer or solicitation for the purchase or sale of any financial
> instrument or as an official confirmation of any transaction. All market
> prices,
> data and other information are not warranted as to completeness or
> accuracy and
> are subject to change without notice. Any comments or statements made
> herein
> do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
> and affiliates.
>