Hi Henrik,
IMHO deploy-file (just like install-file) should *never* be a part of a
lifecycle, but should be run standalone and should only be used for
unavailable third party artifacts.
Looking back at your pom-fragment, you should do the following:
* if "deploymentfile" is being created by a Maven plugin, try to make that
plugin attach that file to the project.
* Use
http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html
and remove the deploy-file asap. This plugin does it's work as part of the
build lifecycle as it should be.
Robert
Op Sun, 16 Feb 2014 11:20:39 +0100 schreef Henrik Skriver Rasmussen
<[email protected]>:
Hi Robert
Thank you for your answer.
I would like to figure out how to simple skip the generation of the given
extra zip file because I do not know how now.
Any way to see during debug which goal will result in which artifact? Any
help on finding out when running my build will be appreciated.
I can not omit what I do not know to control nor can I not attach it
when I
do no what generates it.
Not creating or attaching the artifact solves the problem - but still, as
user of maven I still say that it is counter intuitive to have the
deploy-file goal not only deploy the specified file.
The deploy goal should deploy all - but not the deploy-file goal. :)
I know that is a different discussion about meaningful naming of APIs and
frankly I don't care now that I know.
But maven developers should care about simplifying and make maven APIs
intuitive since maven is not exactly gaining ground due to it's
simplicity
and transparency. ;)
That being said, I have been using maven for a looong time and enjoy it
most of the time - so keep up the good work!
regards
Henrik Skriver Rasmussen
On Sun, Feb 16, 2014 at 2:03 PM, Robert Scholte
<[email protected]>wrote:
Op Sun, 16 Feb 2014 08:15:25 +0100 schreef Henrik Skriver Rasmussen <
[email protected]>:
Thanks for the advice on how to restructure.
Could you have a look at the deploy-plugin project and the file
org.apache.maven.plugin.deploy.DeployFileMojo execute method line 376
in
version 2.8.1 ? I would really like to understand the following:
1) What controls which artifacts are attached the model for the given
project?
The plugin creating that artifact controls the attaching. For example:
http://maven.apache.org/plugins/maven-source-plugin/
xref/org/apache/maven/plugin/source/AbstractSourceJarMojo.html#307
Here the -sources.jar is attached to the project.
2) Is it possible to state that no artifacts except explicitly stated
should be created/attached?
The plugin creating that artifact
3) Is it really the intended behaviour of the deploy:file goal to also
deploy the attached artifacts? To me that is a very non-intuitive
behaviour.
Yes. If there are attachments created and these are attached, they are
uploaded as well. So if you don't want this, solve it at the source, i.e
the plugin creating the artifact. (for the maven-source-plugin: skip it
(best option) or just don't attach (acceptable option) )
For the same reason you won't find "delete" options in any of the
plugins.
It is a matter of excluding the correct files.
Robert
I Basically have a working setup which deploys the zip file I generate
to
repo with the name I have specified. But the only thing that bothers
me is
that for some unclear reason the same zip is deployed again with the
name
of the project in the same deploy:file goal. To me - that is a bug.
Should I open an issue instead somewhere and provide the patch which
fixes
this??
I already mailed the email listed in the top of the java file in
question
but he does not reply.
Med venlig hilsen
Henrik Skriver Rasmussen
On Thu, Feb 13, 2014 at 2:54 PM, Anders Hammar <[email protected]>
wrote:
You should really restart with the module 2 pom.
Your multi-module structure is good. You have a separate
projekt/module
which creates your distro. What you should do is to create the
"distro"
(zip or whatever) to be created as part of the normal build and then
deployed as the project's artifact it is.
This is done in many projects and you could for example have a look at
the
Maven core project where we create a zip and a tar file.
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;
f=apache-maven;hb=HEAD
So in the end, you will not use deploy:deploy-file. Also, your pom
will
be
very small with pretty much only the m-assembly-p being bound to the
build
lifecycle.
/Anders
On Thu, Feb 13, 2014 at 11:36 AM, Henrik Skriver Rasmussen <
[email protected]> wrote:
> Hi Anders
>
> I have a multi-module project with this structure:
>
> A (root and parent pom project)
> - module 1 - builds a jar as artifact
> - module 2 - uses module 1 jar artifact in assembly tries to
deploy
the
> assembled zip file to artifactory.
>
> This is the module 2 pom file with YYYY inserted to replace project
> specific names.
>
> <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/xsd/maven-4.0.0.xsd";>
>
> <modelVersion>4.0.0</modelVersion>
>
> <parent>
>
> <groupId>YYYY</groupId>
>
> <artifactId>YYYY</artifactId>
>
> <version>1.1-SNAPSHOT</version>
>
> </parent>
>
> <artifactId>scripts</artifactId>
>
> <packaging>pom</packaging>
>
> <name>scripts</name>
>
> <description>YYYY</description>
>
> <properties>
>
> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
>
>
<project.reporting.outputEncoding>UTF-8</project.
reporting.outputEncoding>
>
> <main.basedir>${project.parent.basedir}</main.basedir>
>
> </properties>
>
> <build>
>
> <plugins>
>
> <plugin>
>
> <groupId>org.apache.maven.plugins</groupId>
>
> <artifactId>maven-install-plugin</artifactId>
>
> <version>2.5.1</version>
>
> <configuration>
>
> <skip>true</skip>
>
> </configuration>
>
> </plugin>
>
> <plugin>
>
> <groupId>org.apache.maven.plugins</groupId>
>
> <artifactId>maven-assembly-plugin</artifactId>
>
> <version>2.4</version>
>
> <configuration>
>
> <skip>true</skip>
>
> </configuration>
>
> </plugin>
>
> <plugin>
>
> <groupId>org.apache.maven.plugins</groupId>
>
> <artifactId>maven-deploy-plugin</artifactId>
>
> <version>2.8.1</version>
>
> <configuration>
>
> <skip>true</skip>
>
> </configuration>
>
> </plugin>
>
> </plugins>
>
> </build>
>
> <profiles>
>
> <profile>
>
> <id>deployprofile</id>
>
> <build>
>
> <plugins>
>
> <plugin>
>
> <groupId>org.codehaus.mojo</groupId>
>
> <artifactId>exec-maven-plugin</artifactId>
>
> <version>1.2.1</version>
>
> <executions>
>
> <execution>
>
> <id>Copy into target folder and copy service jar into
files/default
> </id>
>
> <phase>package</phase>
>
> <goals>
>
> <goal>exec</goal>
>
> </goals>
>
> <configuration>
>
> <executable>${project.basedir}/build_cookbook.sh</executable>
>
> <arguments>
>
> <argument>${project.parent.artifactId}</argument>
>
> <argument>${project.parent.version}</argument>
>
> </arguments>
>
> </configuration>
>
> </execution>
>
> </executions>
>
> </plugin>
>
> <plugin>
>
> <groupId>org.apache.maven.plugins</groupId>
>
> <artifactId>maven-assembly-plugin</artifactId>
>
> <version>2.4</version>
>
> <executions>
>
> <execution>
>
> <id>deployprofile</id>
>
> <phase>package</phase>
>
> <goals>
>
> <goal>single</goal>
>
> </goals>
>
> <configuration>
>
>
<finalName>${project.parent.artifactId}-${project.parent.version}
> </finalName>
>
> <outputDirectory>${project.build.directory}/</outputDirectory>
>
> <filtering>true</filtering>
>
> <descriptors>
>
> <descriptor>assembly/dist.xml</descriptor>
>
> </descriptors>
>
> </configuration>
>
> </execution>
>
> </executions>
>
> </plugin>
>
> <plugin>
>
> <groupId>org.apache.maven.plugins</groupId>
>
> <artifactId>maven-deploy-plugin</artifactId>
>
> <executions>
>
> <execution>
>
> <id>cookbook</id>
>
> <phase>deploy</phase>
>
> <goals>
>
> <goal>deploy-file</goal>
>
> </goals>
>
> <configuration>
>
> <primaryArtifact>false</primaryArtifact>
>
> <repositoryId>artifactory</repositoryId>
>
> <packaging>zip</packaging>
>
> <url>${project.distributionManagement.
snapshotRepository.url}</url>
>
> <generatePom>false</generatePom>
>
> <artifactId>${project.parent.artifactId}</artifactId>
>
> <groupId>${project.parent.groupId}</groupId>
>
> <version>${project.parent.version}</version>
>
> <classifier>deploymentfile</classifier>
>
> <file>
>
>
>
>
${project.build.directory}/${project.parent.artifactId}-${
project.parent.version}-deploymentfile.zip
>
> </file>
>
> </configuration>
>
> </execution>
>
> </executions>
>
> </plugin>
>
> </plugins>
>
> </build>
>
> </profile>
>
> </profiles>
>
> </project>
>
>
> Med venlig hilsen
> Henrik Skriver Rasmussen
>
>
> On Thu, Feb 13, 2014 at 2:15 PM, Anders Hammar <[email protected]>
wrote:
>
> > You need to provide more info on what you're doing! Is the
> > deploy:deploy-file bound to the build lifecycle of a project? How?
> >
> > /Anders
> >
> >
> > On Thu, Feb 13, 2014 at 11:06 AM, Henrik Skriver Rasmussen <
> > [email protected]> wrote:
> >
> > > Hi
> > >
> > > I have a question about the expected behaviour of the
> deploy:deploy-file
> > > goal in the maven deploy plugin 2.8.1 which I am currently
using to
> > deploy
> > > one file.
> > >
> > > It surprised me that no matter what I did I kept getting more
artifacts
> > > deployed that I asked for and the reason is in the
> > > org.apache.maven.plugin.deploy.DeployFileMojo.execute line 376
where
> the
> > > attached artifacts are also deployed.
> > >
> > > Is this intended behaviour and if so how can I avoid this from
> happening?
> > >
> > > The goal name deploy-file indicates that one artifact (possible
incl.
> > > pom/metadata) is to be deployed and not also a throng of other
> artifacts.
> > >
> > > I will be happy to provide a patch where this is aspect is
removed.
> > >
> > > Thank you in advance
> > >
> > > regards
> > > Henrik Skriver Rasmussen
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
