date:20090408


Hi all,

We have a project consisting an ear, a web module and a ejb module. 

Project POM
|
|EJB POM
|
|WAR POM
|
|EAR POM 


We are calling mvn clean package statement for 'Project POM'. I noticed that 
EAR plugin try to fetch modules from different folders.

For, War project it is trying to get WAR POM project. (This is expected 
behaviour.)
However for, EJB project it is trying to get from Local Repository. And because 
of that I have to replace my command like that mvn clean install. 

Is this true? That is to say; Is it expected behaviour? To me, calling package 
lifecycle should be enough to generate an ear. 

Thanks

 
 
-- 
View this message in context: 
http://n2.nabble.com/Ear-plugin---EJB-module-tp2604318p2604318.html
Sent from the maven users mailing list archive at Nabble.com.


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

Re: Ear plugin EJB module

2009-04-08 Thread Stephane Nicoll

The ear plugin just uses the standard maven API. It relies on the Artifact
interface that should return the location of the file (target of the module,
local repository, etc).

I don't see much trouble here but if you can confirm this scenario with EJB
modules only, just file an issue with a projet that reproduce the problem.

HTH,
Stéphane

On Wed, Apr 8, 2009 at 12:33 PM, CemKoc
cem.koc.fwd+nbl...@gmail.comcem.koc.fwd%2bnbl...@gmail.com
 wrote:


 I have checked source of ear plugin in limited time, I noticed in EarMojo
 class:

 public void execute()


 final File sourceFile = module.getArtifact().getFile();
 final File destinationFile = buildDestinationFile( getWorkDirectory(),
 module.getUri() );
 ...
 ...
 ...
 unpack( sourceFile, destinationFile );

 -

 What is getFile() method returning? It seems that our configuration is a
 little bid buggy.

 Thanks
 --
 View this message in context:
 http://n2.nabble.com/Ear-plugin---EJB-module-tp2604318p2604407.html
 Sent from the maven users mailing list archive at Nabble.com.


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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

Re: Ear plugin EJB module


I have checked source of ear plugin in limited time, I noticed in EarMojo class:

public void execute()


final File sourceFile = module.getArtifact().getFile();
final File destinationFile = buildDestinationFile( getWorkDirectory(), 
module.getUri() );
...
...
... 
unpack( sourceFile, destinationFile );

-
 
What is getFile() method returning? It seems that our configuration is a little 
bid buggy.

Thanks
-- 
View this message in context: 
http://n2.nabble.com/Ear-plugin---EJB-module-tp2604318p2604407.html
Sent from the maven users mailing list archive at Nabble.com.


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

Re: Understanding SNAPSHOTS

2009-04-08 Thread Stephen Connolly

2009/4/8 Sergey Shcherbakov sshcherba...@echelon.de

 Thank you Brian,

 The way we currently prevent developers from deploying their local
 builds to the repo are the security permissions. But I have understood,
 that some kind of a repo-managing system should be used for more
 flexibility.

 Regarding snapshots and the way your QA works it all looks like you have
 adjusted your team workflow to the features the maven tool provides. And
 these features are not so flexible to cover all requirements of ISO
 driven development for instance. For example, need to distinguish and be
 able to recreate everything that gets officially built. If you say, that
 in this case we need to do only releases, then we don't need snapshots
 at all and would loose an option to use different repos for different
 build types.

 As I mentioned already, versions-maven-plugin can't update project's
 version (only dependencies, if I didn't miss something in the online
 description).


But the release plugin will update the project's version.
versions-maven-plugin will let you pick up the other projects' releases

(and technically you can update the project's version with
versions-maven-plugin if you change the root project's version and then run
mvn -N versions:update-child-modules )

-Stephen




 Best Regards,
 Sergey Shcherbakov.

 -Original Message-
 From: Brian Fox [mailto:bri...@sonatype.com]
 Sent: Tuesday, April 07, 2009 11:16 PM
 To: Maven Users List
 Cc: Guillaume Goulet; Kevin Coupland; Kyle Blaney
 Subject: RE: Understanding SNAPSHOTS

 1. How to distinguish snapshot build versions correctly? So that one
 snapshot build would not overwrite previous one in the repository.

 You don't, that's not the purpose. If you truly care about a particular
 snapshot version, then it should have been a
 release. It's meant only for looking at the latest version of unreleased
 code.

 2. How to set up correctly CI server to perform nightly and release
 builds not using maven SCM plug-ins (since our CI system has far richer
 functionality in this field).

 This is a bit trickier but there are some plugins available in Hudson to
 do this. We don't provide nightly releases,
 that's too much overhead. With the staging support, we are able to
 manage this directly from Maven on an intentional
 release basis...that is we decide when a release is ready and use the
 release plugin to do this. The CI is only
 producing snapshots on a constant basis.

 3. When a developer starts a build on his own machine which version
 should he use? There is always a risk that he will destroy an artifact
 in the repository.

 Not if you setup the permissions correctly, and especially not with
 staging support. Each build from a developer would
 go into their own staging repo created on the fly. It's impossible to
 accidentally release directly to your repo with
 this setup.

 4. How to perform automatic pom project version update? I am not
 talking
 about updating dependency versions to the latest version. I want to
 have a build version passed from the CI server automatically in the pom
 file in the repository. At the moment the recommended way is to update
 it manually, as I understand.

 I do it manually, but there are tools like the versions-maven-plugin
 that can assist you.



 -
 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: Maven 2.1 and Maven 2.0.9 changes

This change was by design in 2.1. You should be overriding the version  
in the child by specifying the dependencyManagement section again.


- Brett

On 08/04/2009, at 7:09 PM, Ben Storey wrote:


Hi,

We ran into a problem I thought I would make you aware of one of my
colleagues was running maven 2.1 and we were all running maven 2.0.9

When deploying with version 2.1.0 and you have properties setup like  
the

following in the root project.

prroperties

 commons-logging.version1.1/commons-logging.version

/properties

…

dependencyManagement

 dependencies

   dependency

  groupIdcommons-logging/groupId

  artifactIdcommons-logging/artifactId

  version${commons-logging.version} /groupId

   /dependency

 /dependencies

/dependencyManagement



When you do the deploy with 2.0.9 it deploys like above, however when
deploying in 2.1. it substitutes the dependencyManagement version  
property

like below.



dependencyManagement

 dependencies

   dependency

  groupIdcommons-logging/groupId

  artifactIdcommons-logging/artifactId

  version1.1/groupId

   /dependency

 /dependencies

/dependencyManagement



This means in the child projects we cannot override the version by the
following:



properties

 commons-logging.version1.1.1commons-logging.version

/properties


Because maven does not do the substitution because there is no  
variable to

substitute in the root descriptor.

With the way we are using maven currently the dependencyManagement  
elements

we want to be able to override some of our own library versions.

Is this an enhancement or a bug?

Cheers

Ben



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

Re: Release Plugin scmCommentPrefix issues

2009-04-08 Thread Heinrich Nirschl

On Tue, Apr 7, 2009 at 5:12 PM, Mykel Alvis mykel.al...@gmail.com wrote:
 When performing a release, I want to place an identifier into the release
 tag commit message (in subversion, in my case).

 Pasted directly from my command line running maven 2.0.9 with release plugin
 2.0-beta-9:

 $ mvn -B -DscmCommentPrefix=CM-524   release:prepare
 ---
 constituent[0]: file:/opt/maven/lib/maven-2.0.9-uber.jar
 ---
 java.lang.StringIndexOutOfBoundsException: String index out of range: -1
        at
 java.lang.AbstractStringBuilder.setLength(AbstractStringBuilder.java:146)
        at java.lang.StringBuffer.setLength(StringBuffer.java:154)
 {rest removed}

 Does the space in my scmCommentPrefix cause this?  I place the space there
 to separate the id from the rest of the string.

 Apparently whitespace is a problem, since
  mvn -B -DscmCommentPrefix=CM-524_  release:prepare
 works correctly.

 I looked in Jira but none of the issues seemed to match my problem.
 Apparently any whitespace within the string causes this issue.  Am I
 supplying the string incorrectly somehow?

 Thanks

 Mykel


This could be related to http://jira.codehaus.org/browse/MNG-2190

Maven does some magic to recover the command line parameters for
shells that do not support $@ and this fails in some cases.

Henry

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

Re: Ear plugin EJB module


Hi Stephane, 

I have some questions for you.

1 - Why are the default locations of war and ejb projects.

2 - In this scenario, without installing to a local repository and ejb project 
we can not produce an ear file. Is it normal? 

Thanks 


The ear plugin just uses the standard maven API. It relies on the Artifact
interface that should return the location of the file (target of the module,
local repository, etc).

I don't see much trouble here but if you can confirm this scenario with EJB
modules only, just file an issue with a projet that reproduce the problem.

HTH,
Stéphane



-- 
View this message in context: 
http://n2.nabble.com/Ear-plugin---EJB-module-tp2604318p2604674.html
Sent from the maven users mailing list archive at Nabble.com.


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

Re: Ear plugin EJB module


I mean 

1 - What are the default locations of war and ejb projects.

Sorry for typo 

Thanks 


Hi Stephane, 

I have some questions for you.

1 - Why are the default locations of war and ejb projects.

2 - In this scenario, without installing to a local repository and ejb project 
we can not produce an ear file. Is it normal? 

Thanks 


The ear plugin just uses the standard maven API. It relies on the Artifact
interface that should return the location of the file (target of the module,
local repository, etc).

I don't see much trouble here but if you can confirm this scenario with EJB
modules only, just file an issue with a projet that reproduce the problem.

HTH,
Stéphane





-- 
View this message in context: 
http://n2.nabble.com/Ear-plugin---EJB-module-tp2604318p2604679.html
Sent from the maven users mailing list archive at Nabble.com.


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

RE: LATEST and RELEASE release version management

2009-04-08 Thread Hayes, Peter

Version ranges seem to totally break reproducibility of released builds.


Personally, I'd like to see these eliminated from Maven altogether and
replaced with a separate version compatibility field that indicates
which versions of a dependency you are compatible with but still have a
specific version that you declare:

...
dependency
  groupIdorg.springframework/groupId
  artifactIdspring-core/artifactId
  version2.5.5/version
  compatibility[2.5,3.0-!)/compatibility
/dependency
...

This would ensure reproducibility while providing higher value version
information that could then be used within metadata and leveraged by
containers such as OSGI.

Pete

-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Wednesday, April 08, 2009 3:16 AM
To: Maven Users List
Cc: Maven Users List
Subject: Re: LATEST and RELEASE release version management

sounds like you want version ranges

[1.0,2.0-!)

Sent from my [rhymes with myPod] ;-)

On 8 Apr 2009, at 01:39, Tim che...@gmail.com wrote:

 http://jira.codehaus.org/browse/MNG-4089
 I need to read over the bug that was linked as a duplicate more  
 closely but
 I don't think it's the same thing.
 What I asked for was the same as what you said with 1.0-LATEST.
 Doing something like that or 1.0-RELEASE would actually be very  
 beneficial
 to people that know that minor releases won't break backwards  
 compatibility
 but will allow for more features without having to keep changing  
 versions.

 On Mon, Apr 6, 2009 at 6:29 PM, Brian E. Fox  
 bri...@reply.infinity.nuwrote:

 Having the release plugin translate these values at release time
 _before_ the validation build and tag is the only sane way to use  
 them.
 I currently have never use them because they aren't repeatable.



 From: Hayes, Peter [mailto:peter.ha...@fmr.com]
 Sent: Monday, April 06, 2009 12:12 PM
 To: Maven Users List
 Subject: RE: LATEST and RELEASE release version management



 Graham Leggett wrote:

 Having said that, it makes no sense to have the release plugin care
 about LATEST, because by definition, building against LATEST isn't
 repeatable, and in order for there to be a release, you need the  
 build
 to be repeatable.

 I think this does impact the release plugin as it could offer the
 ability to resolve the LATEST version at release time.  These builds
 would be reproducible because the release plugin tags the poms during
 the release process.

 I think what you're saying is that the build prior to the release  
 build
 is not guaranteed to have the same dependent artifacts as the release
 build.  I care about the release build being reproducible.

 Pete




 -- 

 Emo Philips
http://www.brainyquote.com/quotes/authors/e/emo_philips.html 
 
 - A computer once beat me at chess, but it was no match for me at
 kick
 boxing.

-
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: LATEST and RELEASE release version management

It does but that actually includes all SNAPSHOT versions. If you aren't
interested in snapshot versions as well that that will break.

On Wed, Apr 8, 2009 at 2:16 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 sounds like you want version ranges

 [1.0,2.0-!)

 Sent from my [rhymes with myPod] ;-)


 On 8 Apr 2009, at 01:39, Tim che...@gmail.com wrote:

  http://jira.codehaus.org/browse/MNG-4089
 I need to read over the bug that was linked as a duplicate more closely
 but
 I don't think it's the same thing.
 What I asked for was the same as what you said with 1.0-LATEST.
 Doing something like that or 1.0-RELEASE would actually be very beneficial
 to people that know that minor releases won't break backwards
 compatibility
 but will allow for more features without having to keep changing versions.

 On Mon, Apr 6, 2009 at 6:29 PM, Brian E. Fox bri...@reply.infinity.nu
 wrote:

  Having the release plugin translate these values at release time
 _before_ the validation build and tag is the only sane way to use them.
 I currently have never use them because they aren't repeatable.



 From: Hayes, Peter [mailto:peter.ha...@fmr.com]
 Sent: Monday, April 06, 2009 12:12 PM
 To: Maven Users List
 Subject: RE: LATEST and RELEASE release version management



 Graham Leggett wrote:

  Having said that, it makes no sense to have the release plugin care
 about LATEST, because by definition, building against LATEST isn't
 repeatable, and in order for there to be a release, you need the build
 to be repeatable.


 I think this does impact the release plugin as it could offer the
 ability to resolve the LATEST version at release time.  These builds
 would be reproducible because the release plugin tags the poms during
 the release process.

 I think what you're saying is that the build prior to the release build
 is not guaranteed to have the same dependent artifacts as the release
 build.  I care about the release build being reproducible.

 Pete




 --

 Emo Philips http://www.brainyquote.com/quotes/authors/e/emo_philips.html
 
 - A computer once beat me at chess, but it was no match for me at
 kick
 boxing.


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




-- 

Fred Allen http://www.brainyquote.com/quotes/authors/f/fred_allen.html  -
Washington is no place for a good actor. The competition from bad actors is
too great.

Re: Ear plugin EJB module


Thanks for clear explanation.

I have updated my maven to 2.1.0 a few minutes ago. (I was using 2.0.9)

Now,

I have tried it again, and result is same. It tries to fetch from local 
repository.

I will submit a bug in JIRA tonight.

Thank you




It depends. Maven is supposed to provide that based of your environment. If
you're running a reactor project, it will fetch the build from the target
directory of the module. If you're relying on an external dependency, it
will first resolve it and provide a link to your local repository.



 2 - In this scenario, without installing to a local repository and ejb
 project we can not produce an ear file. Is it normal?


No it's not. But I vaguely remember that there were some limitations with
some module types. If you can reproduce with the latest 2.0.x Maven release,
file a bug please.

Thanks,
Stéphane




-- 
View this message in context: 
http://n2.nabble.com/Ear-plugin---EJB-module-tp2604318p2604842.html
Sent from the maven users mailing list archive at Nabble.com.


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

Re: Surefire forking using junit 3 even with junit 4 dependency?

2009-04-08 Thread Jörg Schaible

Hi Tim,

Tim wrote at Mittwoch, 8. April 2009 14:05:

 Unfortunately not. It seems however that surefire is actually giving the
 wrong stacktrace.
 When I run this via the cli using the classpath that surefire says it is
 using I get a different exception.
 It seems that a dependency was missing at that point. When I added it, I
 got a new exception instead so it seems to be moving along.

are you running surefire in a multi project where some modules use still
JUnit 3 and the others JUnit 4? Remember, that a plugin is always loaded
only once. So if you add for one module JUnit 4 as dep to the plugin, it
does not help if the plugin has already be loaded elsewhere ...

- Jörg


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

Re: mirrors, oh mirrors



Is there any solution about this problem?  



I'd like mirrors to provide multiple alternate locations. I put the
improvement request here: http://jira.codehaus.org/browse/MNG-3772

Cheers,
Szczepan



-- 
View this message in context: 
http://n2.nabble.com/mirrors%2C-oh-mirrors-tp1125603p2604561.html
Sent from the maven users mailing list archive at Nabble.com.


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

Re: Ear plugin EJB module

2009-04-08 Thread Stephane Nicoll

On Wed, Apr 8, 2009 at 1:28 PM, CemKoc
cem.koc.fwd+nbl...@gmail.comcem.koc.fwd%2bnbl...@gmail.com
 wrote:


 Hi Stephane,

 I have some questions for you.

 1 - Why are the default locations of war and ejb projects.


It depends. Maven is supposed to provide that based of your environment. If
you're running a reactor project, it will fetch the build from the target
directory of the module. If you're relying on an external dependency, it
will first resolve it and provide a link to your local repository.



 2 - In this scenario, without installing to a local repository and ejb
 project we can not produce an ear file. Is it normal?


No it's not. But I vaguely remember that there were some limitations with
some module types. If you can reproduce with the latest 2.0.x Maven release,
file a bug please.

Thanks,
Stéphane


  --
 View this message in context:
 http://n2.nabble.com/Ear-plugin---EJB-module-tp2604318p2604674.html
 Sent from the maven users mailing list archive at Nabble.com.


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




-- 
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge

RE: Maven 2.1 and Maven 2.0.9 changes

2009-04-08 Thread Nord, James

Strange - I have exactly that and I just did a test with 2.1.0 and it
worked just the same as with 2.0.9

(mvn deploy of a snapshot version)

dependencyManagement
 dependencies
  dependency
   groupIdcom.nds.project/groupId 
   artifactIdruntime/artifactId 
   version${runtimeVersion}/version 
   scopeimport/scope 
   typepom/type 
  /dependency
 /dependencies
/dependencyManagement

Is it the core or a plug-in that is responsible for this?

/James 

 -Original Message-
 From: Brett Porter [mailto:br...@apache.org] 
 Sent: 08 April 2009 10:21
 To: Maven Users List
 Subject: Re: Maven 2.1 and Maven 2.0.9 changes
 
 This change was by design in 2.1. You should be overriding 
 the version in the child by specifying the 
 dependencyManagement section again.
 
 - Brett
 
 On 08/04/2009, at 7:09 PM, Ben Storey wrote:
 
  Hi,
 
  We ran into a problem I thought I would make you aware of one of my 
  colleagues was running maven 2.1 and we were all running maven 2.0.9
 
  When deploying with version 2.1.0 and you have properties 
 setup like 
  the following in the root project.
 
  prroperties
 
   commons-logging.version1.1/commons-logging.version
 
  /properties
 
  ...
 
  dependencyManagement
 
   dependencies
 
 dependency
 
groupIdcommons-logging/groupId
 
artifactIdcommons-logging/artifactId
 
version${commons-logging.version} /groupId
 
 /dependency
 
   /dependencies
 
  /dependencyManagement
 
 
 
  When you do the deploy with 2.0.9 it deploys like above, 
 however when 
  deploying in 2.1. it substitutes the dependencyManagement version 
  property like below.
 
 
 
  dependencyManagement
 
   dependencies
 
 dependency
 
groupIdcommons-logging/groupId
 
artifactIdcommons-logging/artifactId
 
version1.1/groupId
 
 /dependency
 
   /dependencies
 
  /dependencyManagement
 
 
 
  This means in the child projects we cannot override the 
 version by the
  following:
 
 
 
  properties
 
   commons-logging.version1.1.1commons-logging.version
 
  /properties
 
 
  Because maven does not do the substitution because there is no  
  variable to
  substitute in the root descriptor.
 
  With the way we are using maven currently the dependencyManagement  
  elements
  we want to be able to override some of our own library versions.
 
  Is this an enhancement or a bug?
 
  Cheers
 
  Ben
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 

**
This e-mail is confidential, the property of NDS Ltd and intended for the 
addressee only. Any dissemination, copying or distribution of this message or 
any attachments by anyone other than the intended recipient is strictly 
prohibited. If you have received this message in error, please immediately 
notify the postmas...@nds.com and destroy the original message. Messages sent 
to and from NDS may be monitored. NDS cannot guarantee any message delivery 
method is secure or error-free. Information could be intercepted, corrupted, 
lost, destroyed, arrive late or incomplete, or contain viruses. We do not 
accept responsibility for any errors or omissions in this message and/or 
attachment that arise as a result of transmission. You should carry out your 
own virus checks before opening any attachment. Any views or opinions presented 
are solely those of the author and do not necessarily represent those of NDS.

To protect the environment please do not print this e-mail unless necessary.

NDS Limited Registered Office: One London Road, Staines, Middlesex, TW18 4EX, 
United Kingdom. A company registered in England and Wales Registered no. 
3080780 VAT no. GB 603 8808 40-00
**

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

Packaging of provided Dependencie in war





Hy List,

i've configured dependencies (libraries) als Scope "provided", and
would aspect they are not packed to the destination war-File.

--- cut ---
    dependency
  groupIdjavax.servlet/groupId
  artifactIdservlet-api/artifactId
  version2.2/version
  scopeprovided/scope
    /dependency
    dependency
  groupIdjavax.mail/groupId
  artifactIdmail/artifactId
  version1.4/version
  scopeprovided/scope
    /dependency
    dependency
  groupIdjavax.activation/groupId
  artifactIdactivation/artifactId
  version1.1/version
  scopeprovided/scope
    /dependency
--- cut ---

but these 3 Libraries are in my destination war-File.



How can i configure this Dependencies in right way that they are
provided for compile, but are not in my destination war-File??

Thanks a lot.

Robert

Re: Maven 2.1 and Maven 2.0.9 changes

2009-04-08 Thread Ben Storey

Thanks for the quick update will do that.

On Wed, Apr 8, 2009 at 10:21 AM, Brett Porter br...@apache.org wrote:

 This change was by design in 2.1. You should be overriding the version in
 the child by specifying the dependencyManagement section again.

 - Brett


 On 08/04/2009, at 7:09 PM, Ben Storey wrote:

  Hi,

 We ran into a problem I thought I would make you aware of one of my
 colleagues was running maven 2.1 and we were all running maven 2.0.9

 When deploying with version 2.1.0 and you have properties setup like the
 following in the root project.

 prroperties

 commons-logging.version1.1/commons-logging.version

 /properties

 …

 dependencyManagement

  dependencies

   dependency

  groupIdcommons-logging/groupId

  artifactIdcommons-logging/artifactId

  version${commons-logging.version} /groupId

   /dependency

  /dependencies

 /dependencyManagement



 When you do the deploy with 2.0.9 it deploys like above, however when
 deploying in 2.1. it substitutes the dependencyManagement version property
 like below.



 dependencyManagement

  dependencies

   dependency

  groupIdcommons-logging/groupId

  artifactIdcommons-logging/artifactId

  version1.1/groupId

   /dependency

  /dependencies

 /dependencyManagement



 This means in the child projects we cannot override the version by the
 following:



 properties

 commons-logging.version1.1.1commons-logging.version

 /properties


 Because maven does not do the substitution because there is no variable to
 substitute in the root descriptor.

 With the way we are using maven currently the dependencyManagement
 elements
 we want to be able to override some of our own library versions.

 Is this an enhancement or a bug?

 Cheers

 Ben



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

Re: Surefire forking using junit 3 even with junit 4 dependency?

Unfortunately not. It seems however that surefire is actually giving the
wrong stacktrace.
When I run this via the cli using the classpath that surefire says it is
using I get a different exception.
It seems that a dependency was missing at that point. When I added it, I got
a new exception instead so it seems to be moving along.

On Tue, Apr 7, 2009 at 7:54 PM, Brett Porter br...@apache.org wrote:

 Is there more of a trace supplied from within Surefire? Have you searched
 to see if anyone else encountered this problem?

 Thanks,
 Brett



 On 08/04/2009, at 10:47 AM, Tim wrote:

  yea the tmp files look fine. In fact I see the correct junit jar version
 and
 all the dependency jars correctly in them.Still, I have no clue why it
 can't
 find a test class directly in it's classpath.

 On Tue, Apr 7, 2009 at 7:35 PM, Brett Porter br...@apache.org wrote:

  That sounds like a separate problem, however I can't tell what is wrong
 from the info here. Are you able to check the surefire temporary files to
 see if the arguments look reasonable?

 - Brett


 On 08/04/2009, at 10:27 AM, Tim wrote:

 It doesn't show the junit 3 jar but has the same problem:


 Forking command line: /bin/sh -c cd /home/tich/data/bps_trunk/bps-api 
 /usr/lib/jvm/jdk1.6.0_13/jre/bin/java -jar
 /tmp/surefirebooter2137625950913122347.jar
 /tmp/surefire4278370938049229367tmp /tmp/surefire3389360321643705255tmp
 org.apache.maven.surefire.booter.SurefireExecutionException:
 com.bps.test.PricingTestSetTestCase; nested exception is
 java.lang.NoClassDefFoundError: com.bps.test.PricingTestSetTestCase

 find -name PricingTestSetTestCase.class
 ./target/test-classes/com/bps/test/PricingTestSetTestCase.class

 On Tue, Apr 7, 2009 at 7:18 PM, Brett Porter br...@apache.org wrote:

 Can you try the latest version of the surefire plugin? (v2.4.3)



 On 08/04/2009, at 10:15 AM, Tim wrote:

 Yea. It's showing up as [INFO]junit:junit:jar:4.4:test with no
 version

  3
 in the list.This is with maven 2.1.0 AND 2.0.10 btw.
 The reason that I noticed this was because I have a base test class in
 a
 dependency that surefire was not able to find. But compilation was
 fine.

 On Tue, Apr 7, 2009 at 6:26 PM, Brett Porter br...@apache.org
 wrote:

 have you confirmed that dependency:list only shows junit 4?



 On 08/04/2009, at 9:18 AM, Tim wrote:

 Why do I see


  Forking command line: /usr/lib/jvm/jdk1.6.0_13/jre/bin/java
 -classpath




 /home/tich/.m2/repository/org/apache/maven/surefire/surefire-booter/2.3/surefire-booter-2.3.jar:/home/tich/.m2/repository/org/apache/maven/surefire/surefire-api/2.3/surefire-api-2.3.jar:/home/tich/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar:/home/tich/.m2/repository/commons-lang/commons-lang/2.1/commons-lang-2.1.jar:/home/tich/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar:/home/tich/.m2/repository/org/codehaus/plexus/plexus-container-default/1.0-alpha-8/plexus-container-default-1.0-alpha-8.jar:/home/tich/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar:/home/tich/.m2/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
 org.apache.maven.surefire.booter.SurefireBooter /tmp/surefire72
 Even when I am using junit 4.4 as a dependency?

 --

 Emo Philips 
 http://www.brainyquote.com/quotes/authors/e/emo_philips.html


  - A computer once beat me at chess, but it was no match for me at

  kick
 boxing.



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




  --

 Fred Allen 
 http://www.brainyquote.com/quotes/authors/f/fred_allen.html


  -
 Washington is no place for a good actor. The competition from bad
 actors
 is
 too great.



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




 --

 George Burns 
 http://www.brainyquote.com/quotes/authors/g/george_burns.html
 - I spent a year in that town, one Sunday.



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




 --

 Fred Allen http://www.brainyquote.com/quotes/authors/f/fred_allen.html
  -
 Washington is no place for a good actor. The competition from bad actors
 is
 too great.



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




-- 

Andy Warhol http://www.brainyquote.com/quotes/authors/a/andy_warhol.html
- I am a deeply superficial person.

Re: Surefire forking using junit 3 even with junit 4 dependency?

That's good to know :)
I can double check but that is probably not what is happening here since it
is defined in the parent pom as junit 4.

On Wed, Apr 8, 2009 at 7:15 AM, Jörg Schaible joerg.schai...@gmx.de wrote:

 Hi Tim,

 Tim wrote at Mittwoch, 8. April 2009 14:05:

  Unfortunately not. It seems however that surefire is actually giving the
  wrong stacktrace.
  When I run this via the cli using the classpath that surefire says it is
  using I get a different exception.
  It seems that a dependency was missing at that point. When I added it, I
  got a new exception instead so it seems to be moving along.

 are you running surefire in a multi project where some modules use still
 JUnit 3 and the others JUnit 4? Remember, that a plugin is always loaded
 only once. So if you add for one module JUnit 4 as dep to the plugin, it
 does not help if the plugin has already be loaded elsewhere ...

 - Jörg


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




-- 

Andy Warhol http://www.brainyquote.com/quotes/authors/a/andy_warhol.html
- I am a deeply superficial person.

Maven Overview Plugin version 1.4 has been released

2009-04-08 Thread Hubert Iwaniuk

Maven Overview Plugin version 1.4 has been released.

http://code.google.com/p/maven-overview-plugin/

Maven Overview Plugin graphs your Maven dependencies. You can use it
in plugin or report mode to generate just graph or integrate with site
generated by Maven respectively.

This release improves filtering:
http://code.google.com/p/maven-overview-plugin/issues/list?can=1q=la...http://code.google.com/p/maven-overview-plugin/issues/list?can=1q=label%3AMilestone-Filtering

You can now filter by max depth, scope and general artifact
properties, please refer to MOP documentation at
http://maven-overview-plugin.googlecode.com/svn/site/overview-mojo.html

Any questions are welcome at:
http://groups.google.com/group/maven-overview-plugin-discuss

MOP

Re: Packaging of provided Dependencie in war

2009-04-08 Thread Kyle Bober

That should work the way you have it configured. Did you run the clean goal
after you changed the dependency scope to provided. This will make sure that
a previous build that may have contained the dependencies is completely
removed.

-Kyle

On Wed, Apr 8, 2009 at 5:22 AM, Robert Einsle rob...@einsle.de wrote:

  Hy List,

 i've configured dependencies (libraries) als Scope provided, and would
 aspect they are not packed to the destination war-File.

 --- cut ---
 dependency
   groupIdjavax.servlet/groupId
   artifactIdservlet-api/artifactId
   version2.2/version
   scopeprovided/scope
 /dependency
 dependency
   groupIdjavax.mail/groupId
   artifactIdmail/artifactId
   version1.4/version
   scopeprovided/scope
 /dependency
 dependency
   groupIdjavax.activation/groupId
   artifactIdactivation/artifactId
   version1.1/version
   scopeprovided/scope
 /dependency
 --- cut ---

 but these 3 Libraries are in my destination war-File.



 How can i configure this Dependencies in right way that they are provided
 for compile, but are not in my destination war-File??

 Thanks a lot.

 Robert




-- 
-Act as if it were impossible to fail

Re: Packaging of provided Dependencie in war

Hy,

i think i run it several times, incl restart of my Developementenvironment.

Robert

Kyle Bober schrieb:
 That should work the way you have it configured. Did you run the clean
 goal after you changed the dependency scope to provided. This will
 make sure that a previous build that may have contained the
 dependencies is completely removed.

 -Kyle

 On Wed, Apr 8, 2009 at 5:22 AM, Robert Einsle rob...@einsle.de
 mailto:rob...@einsle.de wrote:

 Hy List,

 i've configured dependencies (libraries) als Scope provided, and
 would aspect they are not packed to the destination war-File.

 --- cut ---
 dependency
   groupIdjavax.servlet/groupId
   artifactIdservlet-api/artifactId
   version2.2/version
   scopeprovided/scope
 /dependency
 dependency
   groupIdjavax.mail/groupId
   artifactIdmail/artifactId
   version1.4/version
   scopeprovided/scope
 /dependency
 dependency
   groupIdjavax.activation/groupId
   artifactIdactivation/artifactId
   version1.1/version
   scopeprovided/scope
 /dependency
 --- cut ---

 but these 3 Libraries are in my destination war-File.



 How can i configure this Dependencies in right way that they are
 provided for compile, but are not in my destination war-File??

 Thanks a lot.

 Robert




 -- 
 -Act as if it were impossible to fail

Re: Packaging of provided Dependencie in war

2009-04-08 Thread Kyle Bober

Restarting you development environment will not remove the maven target
directory and artifacts. Try running the following Maven command 'mvn clean
package'  and check the contents of the
target/war_file_directory/WEB-INF/lib

-Kyle

On Wed, Apr 8, 2009 at 9:27 AM, Robert Einsle rob...@einsle.de wrote:

 Hy,

 i think i run it several times, incl restart of my Developementenvironment.

 Robert

 Kyle Bober schrieb:
  That should work the way you have it configured. Did you run the clean
  goal after you changed the dependency scope to provided. This will
  make sure that a previous build that may have contained the
  dependencies is completely removed.
 
  -Kyle
 
  On Wed, Apr 8, 2009 at 5:22 AM, Robert Einsle rob...@einsle.de
  mailto:rob...@einsle.de wrote:
 
  Hy List,
 
  i've configured dependencies (libraries) als Scope provided, and
  would aspect they are not packed to the destination war-File.
 
  --- cut ---
  dependency
groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId
version2.2/version
scopeprovided/scope
  /dependency
  dependency
groupIdjavax.mail/groupId
artifactIdmail/artifactId
version1.4/version
scopeprovided/scope
  /dependency
  dependency
groupIdjavax.activation/groupId
artifactIdactivation/artifactId
version1.1/version
scopeprovided/scope
  /dependency
  --- cut ---
 
  but these 3 Libraries are in my destination war-File.
 
 
 
  How can i configure this Dependencies in right way that they are
  provided for compile, but are not in my destination war-File??
 
  Thanks a lot.
 
  Robert
 
 
 
 
  --
  -Act as if it were impossible to fail




-- 
-Act as if it were impossible to fail

RE: Understanding SNAPSHOTS

2009-04-08 Thread Brian Fox


Regarding snapshots and the way your QA works it all looks like you have
adjusted your team workflow to the features the maven tool provides. 

Yes, this comes from years of using the tool, but is also adapted to our 
current environment.

And
these features are not so flexible to cover all requirements of ISO
driven development for instance. For example, need to distinguish and be
able to recreate everything that gets officially built. If you say, that
in this case we need to do only releases, then we don't need snapshots
at all and would loose an option to use different repos for different
build types.

I don't understand this statement. We produce releases whenever it needs to be 
traceable, those releases are
deterministic and rebuildable if needed from source. In a previous company, the 
snapshots were not used by qa, all
deliveries to qa where release builds. We used a 4 digit versioning where the 
last number was just a build number. We
did this because it wasn't known ahead of time if a given build would pass qa 
and be officially released. How you use
the system is up to your individual requirements.



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

Re: Packaging of provided Dependencie in war

Hy Kyle,

i tried it several Times.

But i will try again *gg*

and ... mail-1.4.jar, activation-1.1.jar and servlet-api-2.2.jar are in
WEB-INF/lib-directory ob war-File.

I tried this time run Mavon from outside of eclipse on command-line.

Robert

Kyle Bober schrieb:
 Restarting you development environment will not remove the maven target
 directory and artifacts. Try running the following Maven command 'mvn clean
 package'  and check the contents of the
 target/war_file_directory/WEB-INF/lib

 -Kyle

 On Wed, Apr 8, 2009 at 9:27 AM, Robert Einsle rob...@einsle.de wrote:

   
 Hy,

 i think i run it several times, incl restart of my Developementenvironment.

 Robert

 Kyle Bober schrieb:
 
 That should work the way you have it configured. Did you run the clean
 goal after you changed the dependency scope to provided. This will
 make sure that a previous build that may have contained the
 dependencies is completely removed.

 -Kyle

 On Wed, Apr 8, 2009 at 5:22 AM, Robert Einsle rob...@einsle.de
 mailto:rob...@einsle.de wrote:

 Hy List,

 i've configured dependencies (libraries) als Scope provided, and
 would aspect they are not packed to the destination war-File.

 --- cut ---
 dependency
   groupIdjavax.servlet/groupId
   artifactIdservlet-api/artifactId
   version2.2/version
   scopeprovided/scope
 /dependency
 dependency
   groupIdjavax.mail/groupId
   artifactIdmail/artifactId
   version1.4/version
   scopeprovided/scope
 /dependency
 dependency
   groupIdjavax.activation/groupId
   artifactIdactivation/artifactId
   version1.1/version
   scopeprovided/scope
 /dependency
 --- cut ---

 but these 3 Libraries are in my destination war-File.



 How can i configure this Dependencies in right way that they are
 provided for compile, but are not in my destination war-File??

 Thanks a lot.

 Robert




 --
 -Act as if it were impossible to fail

RE: Understanding SNAPSHOTS

2009-04-08 Thread Todd Thiessen

 So your formal releases are produced by manually running the release 
 plugin? And if it fails, you manually do a rollback, 
 depending on the 
 failure?
 
 Yes, we manually roll it back. It's not too bad with svn, but 
 a bit annoying I'll admit. We haven't tackled the release tools yet.

Ok cool. Myself and my collegues have been doing some thought in this
area as well as to how to improve how releases are done using Maven.
Once I formalize some of these thoughts I would like share them with the
community to get some feedback. Perhaps later today if I can squeeze it
in with my regular work ;-).

 When we start to converge on a release, we cut a branch for 
 that release stream. That means that when we actually start 
 staging releases, the devs have moved on to the next release 
 which is another trunk/branch.

This makes sense to me. In my mind, a release signifies an important
milestone in the project and generally indicates the need to open a new
branch so that you can reduce churn on that branch and continue regular
more risky feature work.

But this isn't the only work flow. Releases can be made off the trunk.
Its the continuous release strategy that I think is throwing me for a
bit of a loop. In this strategy many minor releases are made very often
during the develop of a large major release of the product. This is a
bit troublesome in the sense that your version number is constantly
changing thus make SNAPSHOT versions less valuable.

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

RE: buildpath probleme with eclipse:eclipse goal

2009-04-08 Thread florian.cavagnini

That's work!

Thanks for the help

 
Florian Cavagnini
IT / Gestion de Configuration
Immeuble Lumière
40 avenue des Terroirs de France
75012 Paris
T +33 1 57 22 55 83
E florian.cavagn...@ingdirect.fr
-Message d'origine-
De : Robert Hanson [mailto:iamroberthan...@gmail.com] 
Envoyé : mercredi 8 avril 2009 00:12
À : Maven Users List
Objet : Re: buildpath probleme with eclipse:eclipse goal

You can also set the AJDT version to none.

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
configuration
ajdtVersionnone/ajdtVersion
/configuration
/plugin

References:
  http://jira.codehaus.org/browse/MECLIPSE-200 (broke it)
  http://jira.codehaus.org/browse/MECLIPSE-544 (workaround)
  http://jira.codehaus.org/browse/MECLIPSE-547 (open)



On Tue, Apr 7, 2009 at 5:05 PM, Arnaud HERITIER aherit...@gmail.com wrote:
 there are several thread and issues opened about problem in the release 2.6
 of the plugin with aspectj projects.Set the version of the
 maven-eclipse-plugin to 2.5.1 in the dependencyManagement part of your pom
 to use the previous version while we are fixing it.

 On Tue, Apr 7, 2009 at 7:39 PM, florian.cavagn...@ingdirect.fr wrote:

 Hello

 Since two days, I don't know why but when I generate the eclipse
 configuration files (.classpath and .project) of my maven project with
 the eclipse plugin (goal eclipse:eclipse), it don't add all the
 dependencies listed in my pom.xml!

 And one in particular: org.aspectj.aspectjrt-1.5.4

 I tried with a simple pom with only one dependency:

 dependency
        groupIdorg.aspectj/groupId
        artifactIdaspectjrt/artifactId
        version1.6.0/version
        scopecompile/scope
 /dependency

 Depencency tree shows:

 [INFO]
 
 [INFO] Building Unnamed - mon.cul:prout:jar:1.0
 [INFO]    task-segment: [dependency:tree]
 [INFO]
 
 [INFO] [dependency:tree]
 [INFO] mon.cul:prout:jar:1.0
 [INFO] \- org.aspectj:aspectjrt:jar:1.6.0:compile
 [INFO]
 
 [INFO] BUILD SUCCESSFUL
 [INFO]
 
 [INFO] Total time: 6 seconds
 [INFO] Finished at: Tue Apr 07 19:36:49 CEST 2009
 [INFO] Final Memory: 11M/127M
 [INFO]
 


 But when I run eclipse:eclipse, I have nothing in my buildpath, only JRE
 library!

 [INFO]
 
 [INFO] Building Unnamed - mon.cul:prout:jar:1.0
 [INFO]    task-segment: [eclipse:clean, eclipse:eclipse]
 [INFO]
 
 [INFO] [eclipse:clean]
 [INFO] Deleting file: .project
 [INFO] Deleting file: .classpath
 [INFO] Deleting file: .wtpmodules
 [INFO] Deleting file: .component
 [INFO] Deleting file: org.eclipse.wst.common.component
 [INFO] Deleting file: org.eclipse.wst.common.project.facet.core.xml
 [INFO] Deleting file: org.eclipse.jdt.core.prefs
 [INFO] Deleting file: org.eclipse.ajdt.ui.prefs
 [INFO] Preparing eclipse:eclipse
 [INFO] No goals needed for project - skipping
 [INFO] [eclipse:eclipse]
 [INFO] Using Eclipse Workspace: D:\workspaces\SRC_MCA\Intense_Dev
 [INFO] no substring wtp server match.
 [INFO] Using as WTP server : Apache Tomcat v5.5
 [INFO] Adding default classpath container:
 org.eclipse.jdt.launching.JRE_CONTAINER
 [INFO] Not writing settings - defaults suffice
 [INFO] Wrote Eclipse project for prout to
 D:\workspaces\SRC_MCA\Intense_Dev\prout.
 [INFO]
       Sources for some artifacts are not available.
       Please run the same goal with the -DdownloadSources=true
 parameter in order to check remote repositories for sources.
       List of artifacts without a source archive:
         o org.aspectj:aspectjrt:1.6.0

       Javadoc for some artifacts is not available.
       Please run the same goal with the -DdownloadJavadocs=true
 parameter in order to check remote repositories for javadoc.
       List of artifacts without a javadoc archive:
         o org.aspectj:aspectjrt:1.6.0

 [INFO]
 
 [INFO] BUILD SUCCESSFUL
 [INFO]
 

 Did you know how to solve that?

 thanks


 -
 ATTENTION:
 The information in this electronic mail message is private and
 confidential, and only intended for the addressee. Should you
 receive this message by mistake, you are hereby notified that
 any disclosure, reproduction, distribution or use of this
 message is strictly prohibited. Please inform the sender by
 reply transmission and delete the message without copying or
 opening it.

RE: Understanding SNAPSHOTS

2009-04-08 Thread Todd Thiessen

 
 In a previous company, the snapshots were not used by qa, all 
 deliveries to qa where release builds. We used a 4 digit 
 versioning where the last number was just a build number. We 
 did this because it wasn't known ahead of time if a given 
 build would pass qa and be officially released. How you use 
 the system is up to your individual requirements.

Right. This is the continuous release strategy I was alluding to in my
previous email.  Because of the way Maven versions and releases work,
this makes SNAPSHOTs less valuable when using this release strategy. So
say you have 10 minor releases before a major. Anyone using a SNAPSHOT
version would have to change the version in all their POMs to truly
point to the latest development version.

This is why I think the way you guys have done it with Nexus (ie: QA
taking SNAPSHOTS) matches more closely to how Maven currently works.

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

How to create zip of all project artifact binaries?

2009-04-08 Thread David Hoffer

I would like to create a zip of my complete project binary artifacts.  (Also
one of sources and javadocs would be a bonus.) The project has many modules
and I need the resulting zip to structure the contents so each module has
its own folder containing it's artifact (jar, swc, etc) plus any runtime
dependencies.  I need this to run as part of the install goal, how can I
accomplish this?  If anyone has pom  assembly samples that would be great.

-Dave

Re: Question concerning settings-security.xml location

2009-04-08 Thread solo1970

I need to investigate the work-around you proposed, but by doing that won't I
disable Delete Artifact for ALL the users I would need to disable it
only for one user, because we need the Delete Artifact functionality for a
group of us who are SCMs.

Sonia

brettporter wrote:

On 08/04/2009, at 4:57 AM, solo1970 wrote:

Here is the use case:

With Archiva 2.1, they've added a Delete Artifact possibility in
the UI,
as long as you are a Repository Manager, you have access to it.
In the
past, we used the guest logon for everyone which was Repository
manager
for our snapshots and development repositories, hence no username/
password
in the settings.xml file. Ande everyone can deploy.

I'll answer that on the archiva list with the Q you asked there, and
it is easily fixed.

Now we don't want everyone to go to the UI and have the possibility to
delete artifacts from those repositories, so we can't give guest the
Repository manager role for those repositories.
We've then created a deployment user which has those roles, but we
need to
encrypt the password so that not everyone can login to the UI, but can
deploy from the command-line to those repositories.

If you give everyone the master password, you're effectively giving
away the passwords. It's a little hidden, but trivial for anyone to
figure out that wants to.

Cheers,
Brett

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

--
View this message in context:
http://www.nabble.com/Question-concerning-settings-security.xml-location-tp22932257p22951793.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: Specify text in Maven site generated pages

2009-04-08 Thread Stefano Fornari

Hi Hervé and All,
what's the best way to add a new report? I would like to run some
integration tests and generate a report to be added to the site. How
can I do it?

Thanks in advance,

Ste

On Fri, Sep 12, 2008 at 2:53 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
 Le vendredi 12 septembre 2008, Junco Hueco a écrit :
 Hi all,

 I've been looking for how to change the text that appears in the generated
 html pages from the Maven site plugin, but I haven't found any information
 about this.

 Where are the templates or files used to generate each page (index.html,
 license.html, integration.html, etc)?

 Thank you in advance.

 these files are generated by Maven Project Info Report Plugin
 http://maven.apache.org/plugins/maven-project-info-reports-plugin/

 and you can create more content:
 http://maven.apache.org/plugins/maven-site-plugin/examples/creating-content.html

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





-- 
Ste

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

RE: mirrors, oh mirrors

2009-04-08 Thread Brian E. Fox

Yes, Nexus 1.3 supports true mirrors.
http://www.sonatype.com/people/2009/03/new-feature-in-nexus-13-mirror-su
pport/

-Original Message-
From: CemKoc [mailto:cem.koc.fwd+nbl...@gmail.com] 
Sent: Wednesday, April 08, 2009 7:05 AM
To: users@maven.apache.org
Subject: Re: mirrors, oh mirrors

Is there any solution about this problem?  

I'd like mirrors to provide multiple alternate locations. I put the
improvement request here: http://jira.codehaus.org/browse/MNG-3772

Cheers,
Szczepan

-- 
View this message in context:
http://n2.nabble.com/mirrors%2C-oh-mirrors-tp1125603p2604561.html
Sent from the maven users mailing list archive at Nabble.com.

-
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: Packaging of provided Dependencie in war

2009-04-08 Thread Jörg Schaible

Hi Robert,

Robert Einsle wrote at Mittwoch, 8. April 2009 15:39:

 Hy Kyle,
 
 i tried it several Times.
 
 But i will try again *gg*
 
 and ... mail-1.4.jar, activation-1.1.jar and servlet-api-2.2.jar are in
 WEB-INF/lib-directory ob war-File.
 
 I tried this time run Mavon from outside of eclipse on command-line.

You don't have other wars as dependencies, don't you? Otherwise they might
be applied as overlays and these can inject those jars.

- Jörg


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

RE: JSP Precompile and WebSphere

2009-04-08 Thread Jerry Thome

We have a simple web app.  We test locally using Tomcat and then deploy 
through various lifecycles which run WebSphere 6.1.  Our JSP precompile 
process doesn't do anything IBM / WAS specific.  Some of our JSPs are very 
simple, and some are used by Spring.

We followed the instructions exactly as outlined here: 
http://mojo.codehaus.org/jspc-maven-plugin/usage.html   Well, we are using 
JDK 1.5 so we specify that via properties.

plugin
groupIdorg.codehaus.mojo/groupId
artifactIdjspc-maven-plugin/artifactId
executions
execution
idjspc/id
goals
goalcompile/goal
/goals
configuration
source${compileSource}/source
target${compileSource}/target
compilerVersion${compileSource}/compilerVersion
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
webXml${basedir}/target/jspweb.xml/webXml
/configuration
/plugin


Then, depending on the J2EE spec you're using, you need to include the 
right dependencies.  Make sure to include the jsp-runtime jar too. 

dependency
   groupIdjavax.servlet/groupId
   artifactIdjsp-api/artifactId
   version2.0/version
   scopeprovided/scope
/dependency
dependency
  groupIdjavax.servlet/groupId
  artifactIdjstl/artifactId
  version1.1.2/version
/dependency
dependency
  groupIdtaglibs/groupId
  artifactIdstandard/artifactId
  version1.1.2/version
/dependency

dependency
groupIdtomcat/groupId
artifactIdjasper-runtime/artifactId
version5.5.15/version
/dependency

We didn't change the WAS deployment descripters either.  Prior to using 
this precompile feature, we let WebSphere auto-compile. 

I won't guarantee this will work for you, but this is all that we did.

Good luck.





asokan02 asoka...@aol.com 

04/07/2009 10:06 AM
Please respond to
Maven Users List users@maven.apache.org



To
users@maven.apache.org
cc

Subject
RE: JSP Precompile and WebSphere







Hello Jerry

Is it possible to precompile JSPs for WebSphere using the jspc-maven 
plugin without a WebSphere installation on the machine that the comipation 
is done on? We do not have WAS installed on the our continuum servers and 
hence have been  stuck compiling JSPs at deployment time.  IBM's response 
to our question was that the only option is to run the jspBatch compiler 
that comes with WAS6.1.  Could you please post the details of how you got 
the jspc-maven plugin to precompile JSPs for WebSphere? 

Thanks



BTW, thanks for the info Martin.

To follow-up, we had to add a couple dependencies to the WAR in order for 
the precompiled JSPs to work under WebSphere.  That's it.  The JSP 
servlets generated from WebSphere were a bit different than what's 
generated by our Maven2 project.  The source extends different classes. 
Since our classes now extend org.apache.jasper.runtime.HttpJspBase and not 

IBM HttpJspBase classes, we had to add the jasper-runtime dependency... 
and maybe 1 or  2 others.

So, not a big deal.  It makes sense, I just had to think through it.

Thanks.





-- 
View this message in context: 
http://n2.nabble.com/JSP-Precompile-and-WebSphere-tp2534484p2599460.html
Sent from the maven users mailing list archive at Nabble.com.


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






The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail.

Re: JSP Precompile and WebSphere

Hy Jerry,

this is my only war-Project in Workspace. I'ts the only maven-Project in
Workspace.

Robert

Jerry Thome schrieb:
 We have a simple web app.  We test locally using Tomcat and then deploy 
 through various lifecycles which run WebSphere 6.1.  Our JSP precompile 
 process doesn't do anything IBM / WAS specific.  Some of our JSPs are very 
 simple, and some are used by Spring.

 We followed the instructions exactly as outlined here: 
 http://mojo.codehaus.org/jspc-maven-plugin/usage.html   Well, we are using 
 JDK 1.5 so we specify that via properties.

 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdjspc-maven-plugin/artifactId
 executions
 execution
 idjspc/id
 goals
 goalcompile/goal
 /goals
 configuration
 source${compileSource}/source
 target${compileSource}/target
 compilerVersion${compileSource}/compilerVersion
 /configuration
 /execution
 /executions
 /plugin
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-war-plugin/artifactId
 configuration
 webXml${basedir}/target/jspweb.xml/webXml
 /configuration
 /plugin


 Then, depending on the J2EE spec you're using, you need to include the 
 right dependencies.  Make sure to include the jsp-runtime jar too. 

 dependency
groupIdjavax.servlet/groupId
artifactIdjsp-api/artifactId
version2.0/version
scopeprovided/scope
 /dependency
 dependency
   groupIdjavax.servlet/groupId
   artifactIdjstl/artifactId
   version1.1.2/version
 /dependency
 dependency
   groupIdtaglibs/groupId
   artifactIdstandard/artifactId
   version1.1.2/version
 /dependency

 dependency
 groupIdtomcat/groupId
 artifactIdjasper-runtime/artifactId
 version5.5.15/version
 /dependency

 We didn't change the WAS deployment descripters either.  Prior to using 
 this precompile feature, we let WebSphere auto-compile. 

 I won't guarantee this will work for you, but this is all that we did.

 Good luck.





 asokan02 asoka...@aol.com 

 04/07/2009 10:06 AM
 Please respond to
 Maven Users List users@maven.apache.org



 To
 users@maven.apache.org
 cc

 Subject
 RE: JSP Precompile and WebSphere







 Hello Jerry

 Is it possible to precompile JSPs for WebSphere using the jspc-maven 
 plugin without a WebSphere installation on the machine that the comipation 
 is done on? We do not have WAS installed on the our continuum servers and 
 hence have been  stuck compiling JSPs at deployment time.  IBM's response 
 to our question was that the only option is to run the jspBatch compiler 
 that comes with WAS6.1.  Could you please post the details of how you got 
 the jspc-maven plugin to precompile JSPs for WebSphere? 

 Thanks



 BTW, thanks for the info Martin.

 To follow-up, we had to add a couple dependencies to the WAR in order for 
 the precompiled JSPs to work under WebSphere.  That's it.  The JSP 
 servlets generated from WebSphere were a bit different than what's 
 generated by our Maven2 project.  The source extends different classes. 
 Since our classes now extend org.apache.jasper.runtime.HttpJspBase and not 

 IBM HttpJspBase classes, we had to add the jasper-runtime dependency... 
 and maybe 1 or  2 others.

 So, not a big deal.  It makes sense, I just had to think through it.

 Thanks.





   

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

Re: Question concerning settings-security.xml location

I think this is best discussed with the corresponding Archiva issue
rather than on the Maven end.

On 09/04/2009, at 12:33 AM, solo1970 wrote:

I nede to investigate the run-around you proposed, but by doing that
won't I
disable Delete Artifact for ALL the users I would need to
disable it
only for one user, because we need the Delete Artifact
functionality for a

group of us who are SCMs.

Sonia

brettporter wrote:

On 08/04/2009, at 4:57 AM, solo1970 wrote:

Here is the use case:

I'll answer that on the archiva list with the Q you asked there, and
it is easily fixed.

Now we don't want everyone to go to the UI and have the
possibility to
delete artifacts from those repositories, so we can't give guest
the

Repository manager role for those repositories.
We've then created a deployment user which has those roles, but we
need to
encrypt the password so that not everyone can login to the UI, but
can

deploy from the command-line to those repositories.

If you give everyone the master password, you're effectively giving
away the passwords. It's a little hidden, but trivial for anyone to
figure out that wants to.

Cheers,
Brett

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

--
View this message in context:
http://www.nabble.com/Question-concerning-settings-security.xml-location-tp22932257p22951793.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: Surefire forking using junit 3 even with junit 4 dependency?

My coworker just found out that version 2.0 of surefire shows the correct
error msgs.So it seems that error handling was changed between them and now
it swallows the correct exceptions :-/
That would have saved a lot of time debugging this lol.

On Wed, Apr 8, 2009 at 7:45 AM, Tim che...@gmail.com wrote:

 That's good to know :)
 I can double check but that is probably not what is happening here since it
 is defined in the parent pom as junit 4.


 On Wed, Apr 8, 2009 at 7:15 AM, Jörg Schaible joerg.schai...@gmx.dewrote:

 Hi Tim,

 Tim wrote at Mittwoch, 8. April 2009 14:05:

  Unfortunately not. It seems however that surefire is actually giving the
  wrong stacktrace.
  When I run this via the cli using the classpath that surefire says it is
  using I get a different exception.
  It seems that a dependency was missing at that point. When I added it, I
  got a new exception instead so it seems to be moving along.

 are you running surefire in a multi project where some modules use still
 JUnit 3 and the others JUnit 4? Remember, that a plugin is always loaded
 only once. So if you add for one module JUnit 4 as dep to the plugin, it
 does not help if the plugin has already be loaded elsewhere ...

 - Jörg


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




 --

 Andy Warhol http://www.brainyquote.com/quotes/authors/a/andy_warhol.html - 
 I am a deeply superficial person.




-- 

Fred Allen http://www.brainyquote.com/quotes/authors/f/fred_allen.html  -
Washington is no place for a good actor. The competition from bad actors is
too great.

Re: Maven Overview Plugin version 1.4 has been released

2009-04-08 Thread Stephen Connolly

Ehhh,

FYI, AFAIK

maven-_-plugin is reserved for o.a.m.p plugins

all other plugins are supposed to use the pattern

_-maven-plugin

-Stephen

2009/4/8 Hubert Iwaniuk neo...@kungfoo.pl

 Maven Overview Plugin version 1.4 has been released.

 http://code.google.com/p/maven-overview-plugin/

 Maven Overview Plugin graphs your Maven dependencies. You can use it
 in plugin or report mode to generate just graph or integrate with site
 generated by Maven respectively.

 This release improves filtering:
 http://code.google.com/p/maven-overview-plugin/issues/list?can=1q=la...
 http://code.google.com/p/maven-overview-plugin/issues/list?can=1q=label%3AMilestone-Filtering
 

 You can now filter by max depth, scope and general artifact
 properties, please refer to MOP documentation at
 http://maven-overview-plugin.googlecode.com/svn/site/overview-mojo.html

 Any questions are welcome at:
 http://groups.google.com/group/maven-overview-plugin-discuss

 MOP

RE: Understanding SNAPSHOTS

2009-04-08 Thread Sergey Shcherbakov


My original question was

1. How to distinguish snapshot build versions correctly? So that one 
snapshot build would not overwrite previous one in the repository.

You don't, that's not the purpose. If you truly care about a particular
snapshot version, then it should have been a release. It's meant only
for looking at the latest version of unreleased code.

And I was confused with your answer. I believe it is still possible to
assign a unique version with -SNAPSHOT suffix to each snapshot build.
Thus we can distinguish snapshot builds and still pack them to the
snapshot repository. 
I think now that maven profiles could also be used to differentiate
target repositories depending on the build type.

The feature I miss (aside of my incompetence to answer a question why
maven is limited to only release and snapshot build types) is an
automatic project version update in the pom file that gets deployed to
the repository. Something similar to the maven 2.1 feature that
substitutes property references with actual values in the version
elements of the project dependencies (read about it in the adjacent
topic).


And
these features are not so flexible to cover all requirements of ISO
driven development for instance. For example, need to distinguish and
be
able to recreate everything that gets officially built. If you say,
that
in this case we need to do only releases, then we don't need snapshots
at all and would loose an option to use different repos for different
build types.

I don't understand this statement. We produce releases whenever it needs
to be traceable, those releases are
deterministic and rebuildable if needed from source. In a previous
company, the snapshots were not used by qa, all
deliveries to qa where release builds. We used a 4 digit versioning
where the last number was just a build number. We
did this because it wasn't known ahead of time if a given build would
pass qa and be officially released. How you use
the system is up to your individual requirements.



-
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: Maven Overview Plugin version 1.4 has been released

2009-04-08 Thread Dan Tran

Stephen,

as long as the plugin has its own groupId, the artifactId can be any thing.

-D


On Wed, Apr 8, 2009 at 8:43 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 Ehhh,

 FYI, AFAIK

 maven-_-plugin is reserved for o.a.m.p plugins

 all other plugins are supposed to use the pattern

 _-maven-plugin

 -Stephen

 2009/4/8 Hubert Iwaniuk neo...@kungfoo.pl

 Maven Overview Plugin version 1.4 has been released.

 http://code.google.com/p/maven-overview-plugin/

 Maven Overview Plugin graphs your Maven dependencies. You can use it
 in plugin or report mode to generate just graph or integrate with site
 generated by Maven respectively.

 This release improves filtering:
 http://code.google.com/p/maven-overview-plugin/issues/list?can=1q=la...
 http://code.google.com/p/maven-overview-plugin/issues/list?can=1q=label%3AMilestone-Filtering
 

 You can now filter by max depth, scope and general artifact
 properties, please refer to MOP documentation at
 http://maven-overview-plugin.googlecode.com/svn/site/overview-mojo.html

 Any questions are welcome at:
 http://groups.google.com/group/maven-overview-plugin-discuss

 MOP



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

Looking for a Maven report

2009-04-08 Thread solo1970


Hello everyone,

I am looking for a reposrt that could provide me with the following
functionality:
-In a multimodule project, list all the artifacts of the project with their
version
-Be able to filter that list based on classifier, groupId,

Anything of the sort out there???

Sonia
-- 
View this message in context: 
http://www.nabble.com/Looking-for-a-Maven-report-tp22954236p22954236.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: How to include extra files with maven-source-plugin?

2009-04-08 Thread Eric B.

 Wayne Fay wayne...@gmail.com wrote in message 
 news:52bab8690904071513q6dc03722tbf6c57a788458...@mail.gmail.com...
  I'm not quite sure I understand what you mean... It's not really sample
  code; it is the jsp code for the application that I am building. 
  Currently
  just the compiled jsp's are being included in the source jar. I'd like 
  the
  original source jsps to be included as well.

 So what you're saying is the following:
 1. You have a packagingwar/packaging project.
 2. You have JSP files in src/main/webapp.
 3. You're using the m-source-p to package up your source code.
 4. Those JSP files are not being added to the source code jar.
 Instead, they are coming in as Java files after being compiled by
 Jspc.

Correct.  I've looked at the jspc-maven-plugin but couldn't find anywhere 
that it might be removing the original jsp's from the file list, so I 
actually commented out the entire plugin from my pom to see if that would 
make a difference.  The only difference it makes is that the jsps now don't 
get compiled - pretty much as expected.  However, I would then have thought 
/ expected that the src/main/webapp directory would then appear in 
my -sources.jar file, but they still dont.  It seems as though only the 
src/main/java and src/main/resources directories show up in the sources.jar 
file.  Which now makes me even more confused.

From looking at the source code for the m-source-p plugin, it shows that the 
list of source files comes from MavenProject.getCompiledSources() or 
MavenProject.getResources().  I guess that by default, Maven only includes 
src/main/java as the getCompiledSources(), and I can't figure out how to add 
to that list.  But then again, am not sure that I would want to, as I assume 
the compiler plugin uses that list as the list of files to compile. 
Similarly, the getResrouces() gets the list of resources from teh build 
arguments.  So by default, src/main/resources, plus anything additional that 
I would put in the build/build section of the pom.  But then, all those 
resrouces end up in the war unless I explicitly ignore them.

It would seem to me that the sources under src/main/webapp should be 
included in the source jar.  I find it really surprising that noone else has 
encountered this problem before

Thanks,

Eric 




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

Integration testing best practices

2009-04-08 Thread Jason Voegele

I'm interested in knowing the current thinking on best practices for 
integration testing in Maven projects.  I did find a few articles on the Web 
that discuss this issue, but they all are a bit old now.  The most relevant 
article appears to be this one:

http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing

Maven: The Definitive Guide is curiously silent on this issue.

Can anyone point me to some up-to-date discussion of integration testing best 
practices for Maven?  Failing that, would you care to share your thoughts on 
this mailing list?

Thanks.

-- 
Jason Voegele
The Gordian Maxim:
If a string has one end, it has another.


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

Re: Looking for a Maven report

2009-04-08 Thread Kyle Bober

Just noticed there is a plugin maven-overview-pluing at
http://code.google.com/p/maven-overview-plugin/ Looks like it creates a
graphic report of the dependencies. Not sure if it supports the version
numbers yet. Also, the m2Eclipse plugin has a nice view that shows the
dependency graph of artifacts for a module.

-Kyle

On Wed, Apr 8, 2009 at 12:20 PM, solo1970
sonia.lodoviche...@ericsson.comwrote:


 Hello everyone,

 I am looking for a reposrt that could provide me with the following
 functionality:
 -In a multimodule project, list all the artifacts of the project with
 their
 version
 -Be able to filter that list based on classifier, groupId,

 Anything of the sort out there???

 Sonia
 --
 View this message in context:
 http://www.nabble.com/Looking-for-a-Maven-report-tp22954236p22954236.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


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




-- 
-Act as if it were impossible to fail

Re: Integration testing best practices

2009-04-08 Thread Wendy Smoak

On Wed, Apr 8, 2009 at 10:22 AM, Jason Voegele ja...@jvoegele.com wrote:
 I'm interested in knowing the current thinking on best practices for
 integration testing in Maven projects.  I did find a few articles on the Web
 that discuss this issue, but they all are a bit old now.  The most relevant
 article appears to be this one:

 http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing

Nothing much has changed since that... the easiest thing to do is to
put your integration tests in a separate module.

At least a few of us would like to see an integrationTestSource
element added to the pom and support for running them in the same
module using the existing integration test phases, but so far no one
has stepped up to propose a patch for consideration.

-- 
Wendy

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

m2eclipse and crashing on any access to pom.xml

2009-04-08 Thread Sean Davis

I am running eclipse under:

 java -version
java version 1.6.0_04
Java(TM) SE Runtime Environment (build 1.6.0_04-b12)
Java HotSpot(TM) 64-Bit Server VM (build 10.0-b19, mixed mode)

When I do anything to add a dependency, I get a crash of the VM:

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x2adcdb63522a, pid=18211, tid=1085491536
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b19 mixed mode
linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1f122a]
#
# An error report file with more information is saved as:
# /home/sdavis/eclipse/hs_err_pid18211.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Any suggestions as to how to alleviate the problem?  Do I really need to
back up to java 1.5 to use m2eclipse as some sites suggest?

Thanks,
Sean

RE: m2eclipse and crashing on any access to pom.xml

2009-04-08 Thread Brian E. Fox

The m2eclipse user list is more appropriate for this, but Igor found these 
links:
http://www.mail-archive.com/ubuntu-b...@lists.ubuntu.com/msg728168.html
http://dev.eclipse.org/newslists/news.eclipse.newcomer/msg21845.html
so it doesn't seem specific to M2e.


-Original Message-
From: seand...@gmail.com [mailto:seand...@gmail.com] On Behalf Of Sean Davis
Sent: Wednesday, April 08, 2009 3:09 PM
To: users@maven.apache.org
Subject: m2eclipse and crashing on any access to pom.xml

I am running eclipse under:

 java -version
java version 1.6.0_04
Java(TM) SE Runtime Environment (build 1.6.0_04-b12)
Java HotSpot(TM) 64-Bit Server VM (build 10.0-b19, mixed mode)

When I do anything to add a dependency, I get a crash of the VM:

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x2adcdb63522a, pid=18211, tid=1085491536
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b19 mixed mode
linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1f122a]
#
# An error report file with more information is saved as:
# /home/sdavis/eclipse/hs_err_pid18211.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Any suggestions as to how to alleviate the problem?  Do I really need to
back up to java 1.5 to use m2eclipse as some sites suggest?

Thanks,
Sean

Equivalent of latest.integration in maven ?

2009-04-08 Thread huser


Hi,

The developers setup the rev number in ivy.xml as latest.integration for
project dependencies. Is there an equivalent of this in Maven ? Revision
always pointing to latest SNAPSHOT version (coming from Nexus) ?

Thanks,
-- 
View this message in context: 
http://www.nabble.com/Equivalent-of-latest.integration-in-maven---tp22959682p22959682.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: Does Maven specify that groupId values will be period-separated components?

It relies on the period to do the path changes. That's not to say that  
it's required - you can have groups and paths that are some-other- 
value for example, but the convention is to use reverse-domain syntax  
like Java packages, which should be more easily recognised by a  
regular Maven user.


On 09/04/2009, at 8:28 AM, David M. Karr wrote:

I would never consider defining a groupId value that didn't look  
like a package name, but does Maven specify that groupId values have  
to be a set of period-separated components?  Apparently groupId  
values are translated to directory paths, but is that because of a  
convention, or a restriction?


The book Maven: a Definitive Guide says that periods are  
commonly used in groupIds, but I don't know how it would translate  
to directory paths without it specifically being in that form,  
unless there's some sort of component separator field defined  
somewhere.


-
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: archetype-metadata optional filesets?

2009-04-08 Thread Lachlan Deck


Anyone?

On 07/04/2009, at 8:56 AM, Lachlan Deck wrote:


Hi there,

Just a quick question: say I've got a fileset in the archetype  
descriptor like so:


?xml version=1.0 encoding=UTF-8?
archetype-descriptor name=woapplication-archetype
requiredProperties
...
/requiredProperties
fileSets
fileSet filtered=true packaged=true encoding=UTF-8
directorysrc/main/java/directory
includes
include**/*.java/include
/includes
/fileSet
...
/fileSets
/archetype-descriptor

Is it possible to define either an include/exlude or an optional  
fileset that's driven by the properties?
Otherwise, how do other people optionally include/exclude files  
during arhcetype:generate?


i.e., based on requiredProperties?


Thanks.


with regards,
--

Lachlan Deck




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

Re: Equivalent of latest.integration in maven ?