Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute

2014-02-16 Thread Anders Hammar
Yes. Use a pom project and bind the assembly plugin to the build lifecycle.
Did you take a look at the project I linked to earlier? Just copy that
solution.

/Anders (mobile)
Den 16 feb 2014 14:37 skrev "Henrik Skriver Rasmussen" :

> Hi Robert
> Thanks - that sounds interesting and I will look into that Monday.
> But what is the right way to deploy a zip file build in the project to the
> artifactory repository then? Is it to only use deploy?
>
> Regards
> Henrik Skriver Rasmussen
>
> > On Feb 16, 2014, at 14:47, "Robert Scholte" 
> wrote:
> >
> > 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.htmland
>  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 <
> skrive...@gmail.com>:
> >
> >> 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  >wrote:
> >>
> >>> 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 
> wrote:
> 
>  You should really restart with the module 2 pom.
> >
> > Your multi-module structure is good. You have a separate
> pr

Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute

2014-02-16 Thread Henrik Skriver Rasmussen
Hi Robert
Thanks - that sounds interesting and I will look into that Monday.
But what is the right way to deploy a zip file build in the project to the 
artifactory repository then? Is it to only use deploy?

Regards
Henrik Skriver Rasmussen

> On Feb 16, 2014, at 14:47, "Robert Scholte"  wrote:
> 
> 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 
> :
> 
>> 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 wrote:
>> 
>>> 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  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
>>

Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute

2014-02-16 Thread Robert Scholte

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  
:



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  
wrote:



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   
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  inserted to replace project
> specific names.
>
> http://maven.apache.org/POM/4.0.0";
>
> xmlns:xsi="http://www.w3.org/2001

Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute

2014-02-16 Thread Henrik Skriver Rasmussen
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 wrote:

> 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  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  inserted to replace project
>>> > specific names.
>>> >
>>> > 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";>
>>> >
>>> > 4.0.0
>>> >
>>> > 
>>> >
>>> >  
>>> >
>>> >  
>>> >
>>> >  1.1-SNAPSHOT
>>> >
>>> > 
>>> >
>>> >  scripts
>>> >
>>> > pom
>>> >
>>> > scripts
>>> >
>>> > 
>>> >
>>> >  
>>> >
>>> >  UTF-8
>>> >
>>> >
>>>  UTF-8>> reporting.outputEncoding>
>>> >
>>> >  ${project.pa

Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute

2014-02-16 Thread Robert Scholte
Op Sun, 16 Feb 2014 08:15:25 +0100 schreef Henrik Skriver Rasmussen  
:



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  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  inserted to replace project
> specific names.
>
> 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";>
>
> 4.0.0
>
> 
>
>  
>
>  
>
>  1.1-SNAPSHOT
>
> 
>
>  scripts
>
> pom
>
> scripts
>
> 
>
>  
>
>  UTF-8
>
>
 UTF-8
>
>  ${project.parent.basedir}
>
> 
>
>   
>
>  
>
>  
>
>   org.apache.maven.plugins
>
>   maven-install-plugin
>
>   2.5.1
>
>   
>
>   true
>
>   
>
>  
>
>  
>
>   org.apache.maven.plugins
>
>   maven-assembly-plugin
>
>   2.4
>
>   
>
>   true
>
>   
>
>  
>
>  
>
>   org.apache.maven.plugins
>
>   maven-deploy-plugin
>
>   2.8.1
>
>   
>
>   true
>
>   
>
>  
>
>
>
> 
>
>  
>
>  
>
> deployprofile
>
>  
>
>   
>
>   
>
>org.codehaus.mojo
>
>exec-maven-plugin
>
>1.2.1
>
>
>
>
>
> Copy  into target folder and copy service jar into  
files/default

> 
>
> package
>
> 
>
> exec
>
> 
>
> 
>
> ${project.basedir}/build_cookbook.sh
>
> 
>
>  ${project.parent.artifactId}
>
>  ${project.parent.version}
>
> 
>
> 
>
>
>
>
>
>   
>
>   
>
>org.apache.maven.plugins
>
>maven-assembly-plugin
>
>2.4
>
>   
>
>
>
> deployprofile
>
> package
>
> 
>
> single
>
> 
>
> 
>
> ${project.parent.artifactId}-${project.parent.version}
> 
>
> ${project.build.directory}/
>
> true
>
> 
>
>  assembly/dist.xml
>
> 
>
> 
>
>
>
>
>
>   
>
>   
>
>org.apache.maven.plugins
>
>maven-deploy-plugin
>
>
>
>
>
> cookbook
>
> deploy
>
> 
>
> deploy-file
>
> 
>
> 
>
>   false
>
> artifactory
>
> zip
>
>  
${project.distributionManagement.snapshotRepository.url}

>
> false
>
> ${project.parent.artifactId}
>
> ${project.parent.groupId}
>
> ${project.parent.version}
>

Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute

2014-02-15 Thread Henrik Skriver Rasmussen
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?
2) Is it possible to state that no artifacts except explicitly stated
should be created/attached?
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.

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  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  inserted to replace project
> > specific names.
> >
> > 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";>
> >
> > 4.0.0
> >
> > 
> >
> >  
> >
> >  
> >
> >  1.1-SNAPSHOT
> >
> > 
> >
> >  scripts
> >
> > pom
> >
> > scripts
> >
> > 
> >
> >  
> >
> >  UTF-8
> >
> >
>  UTF-8
> >
> >  ${project.parent.basedir}
> >
> > 
> >
> >   
> >
> >  
> >
> >  
> >
> >   org.apache.maven.plugins
> >
> >   maven-install-plugin
> >
> >   2.5.1
> >
> >   
> >
> >   true
> >
> >   
> >
> >  
> >
> >  
> >
> >   org.apache.maven.plugins
> >
> >   maven-assembly-plugin
> >
> >   2.4
> >
> >   
> >
> >   true
> >
> >   
> >
> >  
> >
> >  
> >
> >   org.apache.maven.plugins
> >
> >   maven-deploy-plugin
> >
> >   2.8.1
> >
> >   
> >
> >   true
> >
> >   
> >
> >  
> >
> >
> >
> > 
> >
> >  
> >
> >  
> >
> > deployprofile
> >
> >  
> >
> >   
> >
> >   
> >
> >org.codehaus.mojo
> >
> >exec-maven-plugin
> >
> >1.2.1
> >
> >
> >
> >
> >
> > Copy  into target folder and copy service jar into files/default
> > 
> >
> > package
> >
> > 
> >
> > exec
> >
> > 
> >
> > 
> >
> > ${project.basedir}/build_cookbook.sh
> >
> > 
> >
> >  ${project.parent.artifactId}
> >
> >  ${project.parent.version}
> >
> > 
> >
> > 
> >
> >
> >
> >
> >
> >   
> >
> >   
> >
> >org.apache.maven.plugins
> >
> >maven-assembly-plugin
> >
> >2.4
> >
> >   
> >
> >
> >
> > deployprofile
> >
> > package
> >
> > 
> >
> > single
> >
> > 
> >
> > 
> >
> > ${project.parent.artifactId}-${project.parent.version}
> > 
> >
> > ${project.build.directory}/
> >
> > true
> >
> > 
> >
> >  assembly/dist.xml
> >
> > 
> >
> > 
> >
> >
> >
> >
> >
> >   
> >
> >   
> >
> >org.apache.maven.plugins
> >
> >maven-deploy-plugin
> >
> >
> >
> >
> >
> > cookbook
> >
> > deploy
> >
> > 
> >
> > deploy-file
> >
> > 
> >
> > 
> >
> >   false
> >
> > artifactory
> >
> > zip
> >
> > ${project.distributionManagement.snapshotRepository.url}
> >
> > false
> >
> > ${project.parent.artifactId}
> >
> > ${project.parent.groupId}
> >
> > ${project.parent.version}
> >
> > deploymentfile
> >
> > 
> >
> >
> >
> >
> ${project.build.directory}/${project.parent.artifactId}-${project.parent.version}-deploymentfile.zip
> >
> > 
> >
> > 
> >
> >
> >
> >
> >
> >   
> >
> >   
> >
> >  
> >
> >  
> >
> > 
> >
> > 
> >
> >
> > 

Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute

2014-02-13 Thread Anders Hammar
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  inserted to replace project
> specific names.
>
> 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";>
>
> 4.0.0
>
> 
>
>  
>
>  
>
>  1.1-SNAPSHOT
>
> 
>
>  scripts
>
> pom
>
> scripts
>
> 
>
>  
>
>  UTF-8
>
>  UTF-8
>
>  ${project.parent.basedir}
>
> 
>
>   
>
>  
>
>  
>
>   org.apache.maven.plugins
>
>   maven-install-plugin
>
>   2.5.1
>
>   
>
>   true
>
>   
>
>  
>
>  
>
>   org.apache.maven.plugins
>
>   maven-assembly-plugin
>
>   2.4
>
>   
>
>   true
>
>   
>
>  
>
>  
>
>   org.apache.maven.plugins
>
>   maven-deploy-plugin
>
>   2.8.1
>
>   
>
>   true
>
>   
>
>  
>
>
>
> 
>
>  
>
>  
>
> deployprofile
>
>  
>
>   
>
>   
>
>org.codehaus.mojo
>
>exec-maven-plugin
>
>1.2.1
>
>
>
>
>
> Copy  into target folder and copy service jar into files/default
> 
>
> package
>
> 
>
> exec
>
> 
>
> 
>
> ${project.basedir}/build_cookbook.sh
>
> 
>
>  ${project.parent.artifactId}
>
>  ${project.parent.version}
>
> 
>
> 
>
>
>
>
>
>   
>
>   
>
>org.apache.maven.plugins
>
>maven-assembly-plugin
>
>2.4
>
>   
>
>
>
> deployprofile
>
> package
>
> 
>
> single
>
> 
>
> 
>
> ${project.parent.artifactId}-${project.parent.version}
> 
>
> ${project.build.directory}/
>
> true
>
> 
>
>  assembly/dist.xml
>
> 
>
> 
>
>
>
>
>
>   
>
>   
>
>org.apache.maven.plugins
>
>maven-deploy-plugin
>
>
>
>
>
> cookbook
>
> deploy
>
> 
>
> deploy-file
>
> 
>
> 
>
>   false
>
> artifactory
>
> zip
>
> ${project.distributionManagement.snapshotRepository.url}
>
> false
>
> ${project.parent.artifactId}
>
> ${project.parent.groupId}
>
> ${project.parent.version}
>
> deploymentfile
>
> 
>
>
>
> ${project.build.directory}/${project.parent.artifactId}-${project.parent.version}-deploymentfile.zip
>
> 
>
> 
>
>
>
>
>
>   
>
>   
>
>  
>
>  
>
> 
>
> 
>
>
> Med venlig hilsen
> Henrik Skriver Rasmussen
>
>
> On Thu, Feb 13, 2014 at 2:15 PM, Anders Hammar  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
> > >
> >
>


Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute

2014-02-13 Thread Henrik Skriver Rasmussen
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  inserted to replace project
specific names.

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";>

4.0.0



 

 

 1.1-SNAPSHOT



 scripts

pom

scripts



 

 UTF-8

 UTF-8

 ${project.parent.basedir}



  

 

 

  org.apache.maven.plugins

  maven-install-plugin

  2.5.1

  

  true

  

 

 

  org.apache.maven.plugins

  maven-assembly-plugin

  2.4

  

  true

  

 

 

  org.apache.maven.plugins

  maven-deploy-plugin

  2.8.1

  

  true

  

 

   



 

 

deployprofile

 

  

  

   org.codehaus.mojo

   exec-maven-plugin

   1.2.1

   

   

Copy  into target folder and copy service jar into files/default


package



exec





${project.basedir}/build_cookbook.sh



 ${project.parent.artifactId}

 ${project.parent.version}





   

   

  

  

   org.apache.maven.plugins

   maven-assembly-plugin

   2.4

  

   

deployprofile

package



single





${project.parent.artifactId}-${project.parent.version}


${project.build.directory}/

true



 assembly/dist.xml





   

   

  

  

   org.apache.maven.plugins

   maven-deploy-plugin

   

   

cookbook

deploy



deploy-file





  false

artifactory

zip

${project.distributionManagement.snapshotRepository.url}

false

${project.parent.artifactId}

${project.parent.groupId}

${project.parent.version}

deploymentfile




${project.build.directory}/${project.parent.artifactId}-${project.parent.version}-deploymentfile.zip





   

   

  

  

 

 






Med venlig hilsen
Henrik Skriver Rasmussen


On Thu, Feb 13, 2014 at 2:15 PM, Anders Hammar  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
> >
>


Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute

2014-02-13 Thread Anders Hammar
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
>


Fwd: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute

2014-02-13 Thread Henrik Skriver Rasmussen
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