Re: [ANN] Application Assembler Maven Plugin 1.6 Released

[Dan Tran]

Very glad to hear appreciation for MOJO Team. Thank you.

-Dan


On Fri, Nov 8, 2013 at 1:00 PM, Curtis Rueden  wrote:

> Hi Dan,
>
> I just wanted to say thank you to the Application Assembler developers for
> creating this fantastic plugin. We just started using it for one of our
> projects and it is excellent. Your work is really appreciated!
>
> Regards,
> Curtis
>
>
> On Thu, Nov 7, 2013 at 10:05 AM, Dan Tran  wrote:
>
> > Hi,
> >
> > The Mojo team is pleased to announce the release of the Application
> > Assembler Maven Plugin version 1.6.
> >
> > The Application Assembler Plugin is a Maven plugin for generating
> > scripts for starting java applications. All dependencies and the
> > artifact of the project itself are placed in a generated Maven
> > repository in a defined assemble directory. All artifacts
> > (dependencies + the artifact from the project) are added to the
> > classpath in the generated bin scripts.
> >
> > http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/
> >
> > To get this update, simply specify the version in your project's
> > plugin configuration:
> >
> >   
> > org.codehaus.mojo
> > appassembler-maven-plugin
> > 1.6
> >   
> >
> > Release Notes
> >
> > Bug
> >
> >- [MAPPASM-188 ] - Empty
> >CLASSPATH_PREFIX adds current directory to classpath
> >- [MAPPASM-204 ] -
> Support
> >Solaris x86_64 - Commercial JSW only
> >- [MAPPASM-208 ] -
> >binFolder configuration is not used to generate path to environment
> > setup
> >file.
> >- [MAPPASM-211 ] - Null
> >pointer exception when providing empty 
> >
> > Improvement
> >
> >- [MAPPASM-59 ] -
> >appassembler chmod and bat file creation
> >- [MAPPASM-202 ] -
> >Deprecate program.name in favor of program.id
> >- [MAPPASM-207 ] - Add
> >CONFIGDIR environment variable for configurationDirectory property in
> >scripts
> >- [MAPPASM-209 ] - Allow
> >false for JSW daemons
> >
> > New Feature
> >
> >- [MAPPASM-206 ] -
> Support
> >endorsed lib folder
> >
> >
> >
> > Enjoy,
> >
> > The Mojo team.
> >
>

Re: Custom MANIFEST.MF maven-ejb-plugin

[Ron Wheeler]

Still not sure that you need to do this.
Assuming that you can not alter the manifest.mf, what would you do?

What are you trying to do that is so bizarre that no one else would need 
such a feature?


See below.




On 08/11/2013 4:03 PM, Surendran D wrote:

Couldn't find any way to achieve the previous scenario.

resolved my adding custom manifest.mf inside src/resources/ and copying
it... instead of generating one.



On Fri, Nov 8, 2013 at 9:30 AM, Surendran Duraisamy
wrote:


Hi,
How can I generate custom class-path: entries in my maven-ejb-plugin.

I have 3 jar A.jar, B.jar and C.jar in my maven dependency pom.xml. I need
to put only B.jar and C.jar in my Class-Path: entries of my MANIFEST.

I cannot use dependency scope provided as my project is referred by
another project which require dependency scope compile.

The other project can have a compile dependency on C.
If you don't provide C in your jar, where does it come from?



Is there any filters in maven-ejb-plugin or I exclude only specific
entries in my maven-ejb-plugin.

Thanks,





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: deplot at end not working

[Robert Scholte]

You could configure the maven-enforcer-plugin with something like

  
org.apache.maven.plugins:maven-install-plugin
  
  

org.apache.maven.plugins:maven-install-plugin:2.5.1
  

but this requires the same good structure and this is executed at the  
beginning of every project.

So it is still not a fail-fast solution.
A custom rule which is only executed by the root project and which loops  
over all the reactor builds will work as a fail-fast solution, but it is  
not the easiest thing to code. Even for me this would probably take a  
couple of hours to have a solid rule.


Robert


Op Fri, 08 Nov 2013 21:49:32 +0100 schreef Wayne Fay :

If you have a good structure of your project, you should be able to  
lock the

version for these plugins with the pluginManagement. That's by far the
simplest and probably best solution.


Agreed. Perhaps the various rules supported by the enforcer plugin
would be helpful in this regard?

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Custom MANIFEST.MF maven-ejb-plugin

[Surendran D]

Couldn't find any way to achieve the previous scenario.

resolved my adding custom manifest.mf inside src/resources/ and copying
it... instead of generating one.



On Fri, Nov 8, 2013 at 9:30 AM, Surendran Duraisamy
wrote:

> Hi,
> How can I generate custom class-path: entries in my maven-ejb-plugin.
>
> I have 3 jar A.jar, B.jar and C.jar in my maven dependency pom.xml. I need
> to put only B.jar and C.jar in my Class-Path: entries of my MANIFEST.
>
> I cannot use dependency scope provided as my project is referred by
> another project which require dependency scope compile.
>
> Is there any filters in maven-ejb-plugin or I exclude only specific
> entries in my maven-ejb-plugin.
>
> Thanks,
>
>

Re: [ANN] Application Assembler Maven Plugin 1.6 Released

[Curtis Rueden]

Hi Dan,

I just wanted to say thank you to the Application Assembler developers for
creating this fantastic plugin. We just started using it for one of our
projects and it is excellent. Your work is really appreciated!

Regards,
Curtis


On Thu, Nov 7, 2013 at 10:05 AM, Dan Tran  wrote:

> Hi,
>
> The Mojo team is pleased to announce the release of the Application
> Assembler Maven Plugin version 1.6.
>
> The Application Assembler Plugin is a Maven plugin for generating
> scripts for starting java applications. All dependencies and the
> artifact of the project itself are placed in a generated Maven
> repository in a defined assemble directory. All artifacts
> (dependencies + the artifact from the project) are added to the
> classpath in the generated bin scripts.
>
> http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/
>
> To get this update, simply specify the version in your project's
> plugin configuration:
>
>   
> org.codehaus.mojo
> appassembler-maven-plugin
> 1.6
>   
>
> Release Notes
>
> Bug
>
>- [MAPPASM-188 ] - Empty
>CLASSPATH_PREFIX adds current directory to classpath
>- [MAPPASM-204 ] - Support
>Solaris x86_64 - Commercial JSW only
>- [MAPPASM-208 ] -
>binFolder configuration is not used to generate path to environment
> setup
>file.
>- [MAPPASM-211 ] - Null
>pointer exception when providing empty 
>
> Improvement
>
>- [MAPPASM-59 ] -
>appassembler chmod and bat file creation
>- [MAPPASM-202 ] -
>Deprecate program.name in favor of program.id
>- [MAPPASM-207 ] - Add
>CONFIGDIR environment variable for configurationDirectory property in
>scripts
>- [MAPPASM-209 ] - Allow
>false for JSW daemons
>
> New Feature
>
>- [MAPPASM-206 ] - Support
>endorsed lib folder
>
>
>
> Enjoy,
>
> The Mojo team.
>

Re: deplot at end not working

[Wayne Fay]

> If you have a good structure of your project, you should be able to lock the
> version for these plugins with the pluginManagement. That's by far the
> simplest and probably best solution.

Agreed. Perhaps the various rules supported by the enforcer plugin
would be helpful in this regard?

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: deplot at end not working

[Robert Scholte]

1. No, the only open issue related to installAtEnd is MINSTALL-102.  
However, I have my doubts if this should be marked as a bug or just a  
requirement to be able to use installAtEnd.
Think about it: what would be the fix? The first time the m-install-p-2.6  
(which will probably be the next release) is used in a multimodule  
project, it must analyze all projects and count all 2.5.x versions.  
There's already a different strategy between 2.5 and 2.5.1. You must also  
ensure that the last module/project supports installAtEnd, which can be  
tricky with a multithreaded build.


In other words, it is indeed a requirement, otherwise installAtEnd won't  
work.


2. With the current behavior installAtEnd is disabled. The community asked  
for a solution to be able to install/deploy at the end and the current  
implementation is something which will work for most of the projects. It  
would be better if this could be fixed in the way Maven walks through the  
lifecycle, but I wouldn't expect something like this in one of the  
following Maven releases, because it will have a huge impact.


You could create a request for a new feature to verify the versions of  
these plugins, but it will only start checking with the first module which  
has the maven-install-plugin with this capability. So it could happen that  
the first 20 are installed because they relied on an older version.


If you have a good structure of your project, you should be able to lock  
the version for these plugins with the pluginManagement. That's by far the  
simplest and probably best solution.


Robert

Op Fri, 08 Nov 2013 19:36:23 +0100 schreef :


Thank you Andreas and Robert. That was probably the problem. That also
explains why there were like 4 artifacts (our of ~300) that did get
deployed.

Two questions:
1) is there an open bug already for this known issue? i would like to
follow it
2) Why is this the current behaviour? shouldn't it just fail the build as
soon as it detects a version mismatch? i've never seen a similar  
behaviour

in maven where you ask it to do something (deploy), it doesn't do it, but
finishes successfully

Alejandro Endo | Software Designer/Concepteur de logiciels




From:   "Robert Scholte" 
To: "Maven Users List" ,
Date:   2013-11-08 12:42 PM
Subject:Re: deplot at end not working



There are still a small number of cases where the *AtEnd doesn't work, so
I'm still glad I didn't made it the default behavior.
Most important is that all modules must use exactly the same version of
either the maven-install-plugin or maven-deploy-plugin, otherwise the
plugin can't keep track of the number of processed projects.
If it is still an issue and you can reproduce it with a small multimodule
example, upload it with a new JIRA issue, just like MINSTALL-102[1]
Other examples of integration tests can be found in subversion[2]

Robert

[1] https://jira.codehaus.org/browse/MINSTALL-102
[2]
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin/src/it/


Op Fri, 08 Nov 2013 18:21:20 +0100 schreef :


I'm using m-d-p 2.8.1 using the new deploy at end config. I also use
install at end in the m-i-p. However, what I see is that sometimes the
artifacts are not installed nor deployed at all.
I see the normal execution of the plugins with the ** will be deployed

at

end in both cases. But comparing the cases when it does work and when it
doesn't, when it does I see a final invocation to m-d-p where the deploy
happens. This last invocation sometimes doesn't happen. I have -X logs
for
both cases but the case where it doesn't work, the build is like
200modules so the log is 150MB

I'm using differential builds in jenkins (mvn -amd -pl ) in the one that
worked, and it built and deployed like 10artifacts that changed. But

when

I run it without -amd -pl, i.e. a full build, it never deploys nor
installs at end


This is the last part of when it doesn't work (some obfuscations done)

[DEBUG]   (f) retryFailedDeploymentCount = 1
[DEBUG]   (f) skip = false
[DEBUG]   (f) updateReleaseInfo = false
[DEBUG]   (f) project = MavenProject: com.tools:blah:1.0.0-SNAPSHOT @
/var/lib/jenkins/workspace/blah/tools/upgrade/pom.xml
[DEBUG] -- end configuration --
[INFO] Deploying com.tools:blah:1.0.0-SNAPSHOT at end
projectSucceeded com.tools:blah:1.0.0-SNAPSHOT
sessionEnded
[INFO]

[INFO] Reactor Summary:
[INFO]



when it does work i see at the end the deploy plugin running

Uploaded: http://someUrl/maven-metadata.xml (415 B at 1.0 KB/sec)
mojoSucceeded
org.apache.maven.plugins:maven-deploy-plugin:2.8.1(default-deploy)
projectSucceeded com.tools.other:foo.1.0.0-SNAPSHOT
sessionEnded
[INFO]

[INFO] Reactor Summary:
...


Is this a known issue or am I doing something wrong?

Let me know if someone needs more details

Thank you,
Alejandro Endo | Software Designer/Concepteur de 

Re: deplot at end not working

[Alejandro . Endo]

Thank you Andreas and Robert. That was probably the problem. That also 
explains why there were like 4 artifacts (our of ~300) that did get 
deployed.

Two questions:
1) is there an open bug already for this known issue? i would like to 
follow it
2) Why is this the current behaviour? shouldn't it just fail the build as 
soon as it detects a version mismatch? i've never seen a similar behaviour 
in maven where you ask it to do something (deploy), it doesn't do it, but 
finishes successfully

Alejandro Endo | Software Designer/Concepteur de logiciels




From:   "Robert Scholte" 
To: "Maven Users List" , 
Date:   2013-11-08 12:42 PM
Subject:Re: deplot at end not working



There are still a small number of cases where the *AtEnd doesn't work, so 
I'm still glad I didn't made it the default behavior.
Most important is that all modules must use exactly the same version of 
either the maven-install-plugin or maven-deploy-plugin, otherwise the 
plugin can't keep track of the number of processed projects.
If it is still an issue and you can reproduce it with a small multimodule 
example, upload it with a new JIRA issue, just like MINSTALL-102[1]
Other examples of integration tests can be found in subversion[2]

Robert

[1] https://jira.codehaus.org/browse/MINSTALL-102
[2] 
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin/src/it/


Op Fri, 08 Nov 2013 18:21:20 +0100 schreef :

> I'm using m-d-p 2.8.1 using the new deploy at end config. I also use
> install at end in the m-i-p. However, what I see is that sometimes the
> artifacts are not installed nor deployed at all.
> I see the normal execution of the plugins with the ** will be deployed 
at
> end in both cases. But comparing the cases when it does work and when it
> doesn't, when it does I see a final invocation to m-d-p where the deploy
> happens. This last invocation sometimes doesn't happen. I have -X logs 
> for
> both cases but the case where it doesn't work, the build is like
> 200modules so the log is 150MB
>
> I'm using differential builds in jenkins (mvn -amd -pl ) in the one that
> worked, and it built and deployed like 10artifacts that changed. But 
when
> I run it without -amd -pl, i.e. a full build, it never deploys nor
> installs at end
>
>
> This is the last part of when it doesn't work (some obfuscations done)
>
> [DEBUG]   (f) retryFailedDeploymentCount = 1
> [DEBUG]   (f) skip = false
> [DEBUG]   (f) updateReleaseInfo = false
> [DEBUG]   (f) project = MavenProject: com.tools:blah:1.0.0-SNAPSHOT @
> /var/lib/jenkins/workspace/blah/tools/upgrade/pom.xml
> [DEBUG] -- end configuration --
> [INFO] Deploying com.tools:blah:1.0.0-SNAPSHOT at end
> projectSucceeded com.tools:blah:1.0.0-SNAPSHOT
> sessionEnded
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> 
>
>
> when it does work i see at the end the deploy plugin running
>
> Uploaded: http://someUrl/maven-metadata.xml (415 B at 1.0 KB/sec)
> mojoSucceeded
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1(default-deploy)
> projectSucceeded com.tools.other:foo.1.0.0-SNAPSHOT
> sessionEnded
> [INFO]
> 
> [INFO] Reactor Summary:
> ...
>
>
> Is this a known issue or am I doing something wrong?
>
> Let me know if someone needs more details
>
> Thank you,
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: deplot at end not working

[Jeff MAURY]

—
Sent from Mailbox for iPhone

On Fri, Nov 8, 2013 at 6:22 PM, null  wrote:

> I'm using m-d-p 2.8.1 using the new deploy at end config. I also use 
> install at end in the m-i-p. However, what I see is that sometimes the 
> artifacts are not installed nor deployed at all.
> I see the normal execution of the plugins with the ** will be deployed at 
> end in both cases. But comparing the cases when it does work and when it 
> doesn't, when it does I see a final invocation to m-d-p where the deploy 
> happens. This last invocation sometimes doesn't happen. I have -X logs for 
> both cases but the case where it doesn't work, the build is like 
> 200modules so the log is 150MB
> I'm using differential builds in jenkins (mvn -amd -pl ) in the one that 
> worked, and it built and deployed like 10artifacts that changed. But when 
> I run it without -amd -pl, i.e. a full build, it never deploys nor 
> installs at end
> This is the last part of when it doesn't work (some obfuscations done)
> [DEBUG]   (f) retryFailedDeploymentCount = 1
> [DEBUG]   (f) skip = false
> [DEBUG]   (f) updateReleaseInfo = false
> [DEBUG]   (f) project = MavenProject: com.tools:blah:1.0.0-SNAPSHOT @ 
> /var/lib/jenkins/workspace/blah/tools/upgrade/pom.xml
> [DEBUG] -- end configuration --
> [INFO] Deploying com.tools:blah:1.0.0-SNAPSHOT at end
> projectSucceeded com.tools:blah:1.0.0-SNAPSHOT
> sessionEnded
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> 
> when it does work i see at the end the deploy plugin running
> Uploaded: http://someUrl/maven-metadata.xml (415 B at 1.0 KB/sec)
> mojoSucceeded 
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1(default-deploy)
> projectSucceeded com.tools.other:foo.1.0.0-SNAPSHOT
> sessionEnded
> [INFO] 
> 
> [INFO] Reactor Summary:
> ...
> Is this a known issue or am I doing something wrong?
> Let me know if someone needs more details
> Thank you, 
> Alejandro Endo | Software Designer/Concepteur de logiciels
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.

pmd:check has trouble loading reports from target/pmd.txt

[Andrew Pennebaker]

If I configure maven-pmd-plugin to use txt for the report,
then `mvn clean && mvn pmd:check` messes up, attempting to load the report
from `target/pmd.xml` instead of `target/pmd.txt`.

I tried specifying txt in both  and 
plugin sections, but mvn:check still doesn't know about the txt file.

I'm not sure if maven-pmd-plugin is able to parse back the violations from
the text format. If not, then maybe a good compromise is to always generate
both formats.

Using maven-pmd-plugin v3.0.1.

http://search.maven.org/#artifactdetails%7Corg.apache.maven.plugins%7Cmaven-pmd-plugin%7C3.0.1%7Cmaven-plugin

-- 
Cheers,

Andrew Pennebaker
apenneba...@42six.com

Re: AW: AW: AW: mvn release:prepare does not update parent version

[Robert Scholte]

Op Fri, 08 Nov 2013 16:30:30 +0100 schreef Markus Karg :

I wonder why someone fixed it but didn't close  
https://jira.codehaus.org/browse/MRELEASE-837...!


Well, is was probably already fixed for a long time. Since you only had a  
description it will take some time to fix it, since it must first be  
reproducible. That's why attaching a sample project helps, and a patch  
with a possible fix even more.


In this case it was the log-file which triggered me: first update the  
version of the plugin and see if it has been already been fixed.


It is all about being as complete as possible :)

Robert

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: deplot at end not working

[Andreas Gudian]

Hi,

Check if you really use 2.8.1 and 2.5.1 everywhere. If there is at least
one module that uses versions, it might just not work.


Am Freitag, 8. November 2013 schrieb :

> I'm using m-d-p 2.8.1 using the new deploy at end config. I also use
> install at end in the m-i-p. However, what I see is that sometimes the
> artifacts are not installed nor deployed at all.
> I see the normal execution of the plugins with the ** will be deployed at
> end in both cases. But comparing the cases when it does work and when it
> doesn't, when it does I see a final invocation to m-d-p where the deploy
> happens. This last invocation sometimes doesn't happen. I have -X logs for
> both cases but the case where it doesn't work, the build is like
> 200modules so the log is 150MB
>
> I'm using differential builds in jenkins (mvn -amd -pl ) in the one that
> worked, and it built and deployed like 10artifacts that changed. But when
> I run it without -amd -pl, i.e. a full build, it never deploys nor
> installs at end
>
>
> This is the last part of when it doesn't work (some obfuscations done)
>
> [DEBUG]   (f) retryFailedDeploymentCount = 1
> [DEBUG]   (f) skip = false
> [DEBUG]   (f) updateReleaseInfo = false
> [DEBUG]   (f) project = MavenProject: com.tools:blah:1.0.0-SNAPSHOT @
> /var/lib/jenkins/workspace/blah/tools/upgrade/pom.xml
> [DEBUG] -- end configuration --
> [INFO] Deploying com.tools:blah:1.0.0-SNAPSHOT at end
> projectSucceeded com.tools:blah:1.0.0-SNAPSHOT
> sessionEnded
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> 
>
>
> when it does work i see at the end the deploy plugin running
>
> Uploaded: http://someUrl/maven-metadata.xml (415 B at 1.0 KB/sec)
> mojoSucceeded
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1(default-deploy)
> projectSucceeded com.tools.other:foo.1.0.0-SNAPSHOT
> sessionEnded
> [INFO]
> 
> [INFO] Reactor Summary:
> ...
>
>
> Is this a known issue or am I doing something wrong?
>
> Let me know if someone needs more details
>
> Thank you,
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>

Re: deplot at end not working

[Robert Scholte]

There are still a small number of cases where the *AtEnd doesn't work, so  
I'm still glad I didn't made it the default behavior.
Most important is that all modules must use exactly the same version of  
either the maven-install-plugin or maven-deploy-plugin, otherwise the  
plugin can't keep track of the number of processed projects.
If it is still an issue and you can reproduce it with a small multimodule  
example, upload it with a new JIRA issue, just like MINSTALL-102[1]

Other examples of integration tests can be found in subversion[2]

Robert

[1] https://jira.codehaus.org/browse/MINSTALL-102
[2]  
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin/src/it/


Op Fri, 08 Nov 2013 18:21:20 +0100 schreef :


I'm using m-d-p 2.8.1 using the new deploy at end config. I also use
install at end in the m-i-p. However, what I see is that sometimes the
artifacts are not installed nor deployed at all.
I see the normal execution of the plugins with the ** will be deployed at
end in both cases. But comparing the cases when it does work and when it
doesn't, when it does I see a final invocation to m-d-p where the deploy
happens. This last invocation sometimes doesn't happen. I have -X logs  
for

both cases but the case where it doesn't work, the build is like
200modules so the log is 150MB

I'm using differential builds in jenkins (mvn -amd -pl ) in the one that
worked, and it built and deployed like 10artifacts that changed. But when
I run it without -amd -pl, i.e. a full build, it never deploys nor
installs at end


This is the last part of when it doesn't work (some obfuscations done)

[DEBUG]   (f) retryFailedDeploymentCount = 1
[DEBUG]   (f) skip = false
[DEBUG]   (f) updateReleaseInfo = false
[DEBUG]   (f) project = MavenProject: com.tools:blah:1.0.0-SNAPSHOT @
/var/lib/jenkins/workspace/blah/tools/upgrade/pom.xml
[DEBUG] -- end configuration --
[INFO] Deploying com.tools:blah:1.0.0-SNAPSHOT at end
projectSucceeded com.tools:blah:1.0.0-SNAPSHOT
sessionEnded
[INFO]

[INFO] Reactor Summary:
[INFO]



when it does work i see at the end the deploy plugin running

Uploaded: http://someUrl/maven-metadata.xml (415 B at 1.0 KB/sec)
mojoSucceeded
org.apache.maven.plugins:maven-deploy-plugin:2.8.1(default-deploy)
projectSucceeded com.tools.other:foo.1.0.0-SNAPSHOT
sessionEnded
[INFO]

[INFO] Reactor Summary:
...


Is this a known issue or am I doing something wrong?

Let me know if someone needs more details

Thank you,
Alejandro Endo | Software Designer/Concepteur de logiciels

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

deplot at end not working

[Alejandro . Endo]

I'm using m-d-p 2.8.1 using the new deploy at end config. I also use 
install at end in the m-i-p. However, what I see is that sometimes the 
artifacts are not installed nor deployed at all.
I see the normal execution of the plugins with the ** will be deployed at 
end in both cases. But comparing the cases when it does work and when it 
doesn't, when it does I see a final invocation to m-d-p where the deploy 
happens. This last invocation sometimes doesn't happen. I have -X logs for 
both cases but the case where it doesn't work, the build is like 
200modules so the log is 150MB

I'm using differential builds in jenkins (mvn -amd -pl ) in the one that 
worked, and it built and deployed like 10artifacts that changed. But when 
I run it without -amd -pl, i.e. a full build, it never deploys nor 
installs at end


This is the last part of when it doesn't work (some obfuscations done)

[DEBUG]   (f) retryFailedDeploymentCount = 1
[DEBUG]   (f) skip = false
[DEBUG]   (f) updateReleaseInfo = false
[DEBUG]   (f) project = MavenProject: com.tools:blah:1.0.0-SNAPSHOT @ 
/var/lib/jenkins/workspace/blah/tools/upgrade/pom.xml
[DEBUG] -- end configuration --
[INFO] Deploying com.tools:blah:1.0.0-SNAPSHOT at end
projectSucceeded com.tools:blah:1.0.0-SNAPSHOT
sessionEnded
[INFO] 

[INFO] Reactor Summary:
[INFO]



when it does work i see at the end the deploy plugin running

Uploaded: http://someUrl/maven-metadata.xml (415 B at 1.0 KB/sec)
mojoSucceeded 
org.apache.maven.plugins:maven-deploy-plugin:2.8.1(default-deploy)
projectSucceeded com.tools.other:foo.1.0.0-SNAPSHOT
sessionEnded
[INFO] 

[INFO] Reactor Summary:
...


Is this a known issue or am I doing something wrong?

Let me know if someone needs more details

Thank you, 
Alejandro Endo | Software Designer/Concepteur de logiciels

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

AW: AW: AW: mvn release:prepare does not update parent version

[Markus Karg]

Martin,

thank you for your explanations, but as it turned out the problem is fixed 
simply by using version 2.4.2 of the release plugin. I wonder why someone fixed 
it but didn't close https://jira.codehaus.org/browse/MRELEASE-837...!

Thanks for all
-Markus
 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Best Practice for Repository Names etc...

[Ron Wheeler]

We use the community version of Nexus but they do the same things.
See below
On 08/11/2013 7:30 AM, Jason Tesser wrote:

We have one piece of software that we sell.  There are a few github repos
which make up the code for this software.  We have been using only ANT for
years and all our libs are in WEB-INF/lib

We also write plugins against us to deploy in our system.

We are moving to using Maven for our Dependencies. We have Artifactory set
up and working.

My questions are as follows

1. For local Repositories should I stick with the convention that
Artifactory shipped with?
libs-release-local, libs-snapshot-local, plugins-release-local,
plugins-snapshot-local,-ext-release-local,ext-snapshot-local
I was wondering if I should just create one local repo and store everything
in it?

No. You need to keep things separate.
Generally, it is a good idea to follow the vendor's recommended 
structures until you have a good reason not to.
Some of the artifacts will be yours(hosted), most will be from other 
Maven repos (proxy).
You may want to have different access rules for different repos - who 
can read it, who can publish a snapshot, who can publish a release. You 
may have different rules about plug-ins than you do for application and 
library code.


2. Related to number 1. Can 1 repo not support the snapshots?
You are going to deploy many snapshots and few releases. Access (as 
above) is an issue. Rules about cleaning out old snapshots will be 
different than releases.

3. Related to 2 What is the best practice way to handle my branch which
people run everyday and gets commits everyday. This is during development.

Snapshots until you release.

4. Is there a recommended way to handle group/artifact naming. I have seen
many on the internet

Group - com.mycompany.project
Artifact - meaningful name
Version - x.y.z
works for us.
It should make things easier to find and you pretty quickly can see 
where something came from.
We have a "util" group "com.artifact_software.util" where we put 
utilities that are shared between projects.


I hope that this helps

Ron

Thank you,
Jason




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: AW: AW: mvn release:prepare does not update parent version

[Martin Gainty]

  


> From: k...@quipsy.de
> To: users@maven.apache.org
> Date: Fri, 8 Nov 2013 08:40:56 +0100
> Subject: AW: AW: mvn release:prepare does not update parent version
> 
> Martin,
> 
> thanks for your ideas, but...
> 
> 
> I agree that the docs do not say anything about the parent, but my question 
> is not about the docs, it is about this question the plugin is actually 
> asking:
> 
> "Resolve Project Dependency Snapshots.: 'my.group:my-parent' set to release? 
> (yes/no) yes: yes
> What is the next development version? (1.1-SNAPSHOT) 1.1-SNAPSHOT: "
> 
> "my.group:my-parent" *is the parent*. So why does this plugin ask this 
> question? *That* is my question! :-)

MG>I see 2 parts:
MG>1)maven-release-plugin creates a release (which is already accomplished)
MG>2)assignment of development-version to the version tag in pom which resolves
MG>current artifact
 
MG>When maven-release plugin is asking the question What is the next 
development version? 
MG>*may* lead the op to *assume* that the answer to the previous question 
release artifact 
MG>(my-parent) *should be* tagged with development version 1.1-SNAPSHOT
MG>(instead of the tagging current artifact with development version)

MG>Is it reasonable for maven-release-plugin that "next development version"
MG>(e.g. 1.1-SNAPSHOT) *should* be assigned to the any artifact other than 
current artifact?

> Also, I do not want to use another third-party plugin to update the parent at 
> every *deploy*. I only want the parent to be corrected to that level the 
> Maven Release Plugin suggests automatically *when preparing the release* (and 
> only then!). So unless prepare-release is a phase (which I am not aware of) 
> your suggested trick is not a solution to my actual problem. :-(
 
MG>Accomplishing your immediate objective using plugin (and perhaps profile)
MG>1)prepare-release is a plugin not a phase (i have never suggested otherwise)
MG>2) what was suggested is that you hook in a plugin to update parent with 
update-parent plugin to deploy MG>phase (with conditions activated as a 
profile) ..  
MG>the plugin was suggested  as a way to accomplish the objective 

MG>Setup Testing Environment:
MG>in order to accomplish your objective to tag the Development Version of 1.1 
to parent
MG>https://jira.codehaus.org/browse/MRELEASE-837 *should* be reclassified as an 
"enhancement request"
MG>please follow Roberts suggestion to implement 2.4.2 for maven-release-plugin 

 

MG>As the person who wants the enhancement there are 3 questions left 
unanswered:
 
MG>1)Implementation:
MG>should there be an attribute in configuration to update parentVersion
MG>1.1-SNAPSHOT?
MG>if not configuration attribute what other means should be used for parent to 
acquire this value?
 
MG>2)If additional attribute parentVersion is implemented should there be 
another question asked by maven-MG>release-plugin such as "parent version 
should be?..what should be the phrasing of the question?

MG>3)Is it reasonable to assume you will make the "development-version updates 
parent-version" enhancement MG>request for maven-release plugin
 
MG>?
> 
> Thanks!
> -Markus
MG>I think we're at the point where we need to ask the plugin to update the 
parent version
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
  

Best Practice for Repository Names etc...

[Jason Tesser]

We have one piece of software that we sell.  There are a few github repos
which make up the code for this software.  We have been using only ANT for
years and all our libs are in WEB-INF/lib

We also write plugins against us to deploy in our system.

We are moving to using Maven for our Dependencies. We have Artifactory set
up and working.

My questions are as follows

1. For local Repositories should I stick with the convention that
Artifactory shipped with?
libs-release-local, libs-snapshot-local, plugins-release-local,
plugins-snapshot-local,-ext-release-local,ext-snapshot-local
I was wondering if I should just create one local repo and store everything
in it?

2. Related to number 1. Can 1 repo not support the snapshots?

3. Related to 2 What is the best practice way to handle my branch which
people run everyday and gets commits everyday. This is during development.

4. Is there a recommended way to handle group/artifact naming. I have seen
many on the internet

Thank you,
Jason

Re: Plugin, how to resolve single dependency

[Olivier Lamy]

If the idea is to resolve an artifact when you know
groupId:artifactId:version[:type:classifier]

Try

 @Component
 protected ArtifactResolver resolver;

@Component
protected ArtifactFactory artifactFactory;

@Parameter(property = "localRepository", readonly = true)
protected ArtifactRepository localRepository;

   @Parameter( defaultValue = "${project.remoteArtifactRepositories}",
readonly = true, required = true )
protected List remoteRepositories;



protected Artifact resolve( String groupId, String artifactId,
String version, String type, String classifier )
throws MojoExecutionException
{
Artifact artifact =
artifactFactory.createArtifactWithClassifier( groupId, artifactId,
version, type, classifier );
resolver.resolve(artifact, remoteRepositories, localRepository);
return artifact;
}



On 8 November 2013 21:05, Stephen Colebourne  wrote:
> Any thoughts on this?
> Stephen
>
> On 6 November 2013 12:37, Stephen Colebourne  wrote:
>> I have a plugin that needs to access just one dependency from the project.
>>
>> Currently I use "@requiresDependencyResolution compile" and build the
>> entire classpath:
>> https://github.com/JodaOrg/joda-beans-maven-plugin/blob/master/src/main/java/org/joda/beans/maven/AbstractJodaBeansMojo.java#L213
>>
>> This is far from ideal as it requires the whole codebase that the
>> plugin is used on to compile, which is hard given that it is a code
>> generator...
>>
>> It looks like @requiresDependencyCollection might be what I need, but
>> what steps must I take to find the actual dependency I want and then
>> resolve just that one into a classpath?
>>
>> Feel free to examine the plugin:
>> https://github.com/JodaOrg/joda-beans-maven-plugin/blob/master/src/main/java/org/joda/beans/maven
>>
>> thanks
>> Stephen
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Plugin, how to resolve single dependency

[Stephen Colebourne]

Any thoughts on this?
Stephen

On 6 November 2013 12:37, Stephen Colebourne  wrote:
> I have a plugin that needs to access just one dependency from the project.
>
> Currently I use "@requiresDependencyResolution compile" and build the
> entire classpath:
> https://github.com/JodaOrg/joda-beans-maven-plugin/blob/master/src/main/java/org/joda/beans/maven/AbstractJodaBeansMojo.java#L213
>
> This is far from ideal as it requires the whole codebase that the
> plugin is used on to compile, which is hard given that it is a code
> generator...
>
> It looks like @requiresDependencyCollection might be what I need, but
> what steps must I take to find the actual dependency I want and then
> resolve just that one into a classpath?
>
> Feel free to examine the plugin:
> https://github.com/JodaOrg/joda-beans-maven-plugin/blob/master/src/main/java/org/joda/beans/maven
>
> thanks
> Stephen

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org