Op Sun, 16 Feb 2014 08:15:25 +0100 schreef Henrik Skriver Rasmussen
<skrive...@gmail.com>:
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 <and...@hammar.net> 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 <
skrive...@gmail.com> 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 <and...@hammar.net>
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 <
> > skrive...@gmail.com> 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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
