Re: dependency:tree not displaying all dependencies?

2008-12-02 Thread Jaran Nilsen
Done: http://jira.codehaus.org/browse/MSHARED-84

On Tue, Dec 2, 2008 at 1:43 PM, Mark Hobson [EMAIL PROTECTED] wrote:
 Hi Jaran,

 Could you attach a minimal project that reproduces this problem to a
 JIRA issue here please:

 http://jira.codehaus.org/browse/MSHARED/component/13264

 That'll help keep track of it and I'll try to take a look when I've
 got a chance.

 Cheers,

 Mark

 2008/12/2 Jaran Nilsen [EMAIL PROTECTED]:
 Hi.

 I have an issue with the dependency plugin and the tree goal, or the
 eclipse plugin. I wanted to ask here before I file a bug report on
 this, to make sure it's not just me messing things up :P

 The problem is that several dependencies, which do not appear in the
 list generated by dependency:tree, keeps showing up in my classpath
 after I run eclipse:eclipse. This is specifically xerces:xerces:1.4.0
 and cglib:cglib-full:2.0.2.

 $ mvn dependency:tree | grep xerces
 [INFO] | |  +- xerces:xmlParserAPIs:jar:2.6.2:compile
 [INFO] | |  \- xerces:xercesImpl:jar:2.6.2:compile
 [INFO] |  \- xerces:dom3-xml-apis:jar:1.0:compile

 $ mvn dependency:tree | grep cglib
 [INFO] +- cglib:cglib:jar:2.2:compile

 Can anyone explain this behaviour, if it's a bug or if something is
 possibly wrong with my configuration. It's really annoying, because I
 have to manually remove these from the CP after I run eclipse:eclipse
 in order for my application to run through Eclipse (including running
 unit tests etc).

 However running mvn test works fine, so to me it seems there might be
 something with the eclipse:eclipse plugin. Has anyone experienced
 similar issues?

 Cheers,
 Jaran

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: dependency:tree not displaying all dependencies?

2008-12-02 Thread Mark Hobson
Hi Jaran,

Could you attach a minimal project that reproduces this problem to a
JIRA issue here please:

http://jira.codehaus.org/browse/MSHARED/component/13264

That'll help keep track of it and I'll try to take a look when I've
got a chance.

Cheers,

Mark

2008/12/2 Jaran Nilsen [EMAIL PROTECTED]:
 Hi.

 I have an issue with the dependency plugin and the tree goal, or the
 eclipse plugin. I wanted to ask here before I file a bug report on
 this, to make sure it's not just me messing things up :P

 The problem is that several dependencies, which do not appear in the
 list generated by dependency:tree, keeps showing up in my classpath
 after I run eclipse:eclipse. This is specifically xerces:xerces:1.4.0
 and cglib:cglib-full:2.0.2.

 $ mvn dependency:tree | grep xerces
 [INFO] | |  +- xerces:xmlParserAPIs:jar:2.6.2:compile
 [INFO] | |  \- xerces:xercesImpl:jar:2.6.2:compile
 [INFO] |  \- xerces:dom3-xml-apis:jar:1.0:compile

 $ mvn dependency:tree | grep cglib
 [INFO] +- cglib:cglib:jar:2.2:compile

 Can anyone explain this behaviour, if it's a bug or if something is
 possibly wrong with my configuration. It's really annoying, because I
 have to manually remove these from the CP after I run eclipse:eclipse
 in order for my application to run through Eclipse (including running
 unit tests etc).

 However running mvn test works fine, so to me it seems there might be
 something with the eclipse:eclipse plugin. Has anyone experienced
 similar issues?

 Cheers,
 Jaran

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



dependency:tree not displaying all dependencies?

2008-12-02 Thread Jaran Nilsen
Hi.

I have an issue with the dependency plugin and the tree goal, or the
eclipse plugin. I wanted to ask here before I file a bug report on
this, to make sure it's not just me messing things up :P

The problem is that several dependencies, which do not appear in the
list generated by dependency:tree, keeps showing up in my classpath
after I run eclipse:eclipse. This is specifically xerces:xerces:1.4.0
and cglib:cglib-full:2.0.2.

$ mvn dependency:tree | grep xerces
[INFO] | |  +- xerces:xmlParserAPIs:jar:2.6.2:compile
[INFO] | |  \- xerces:xercesImpl:jar:2.6.2:compile
[INFO] |  \- xerces:dom3-xml-apis:jar:1.0:compile

$ mvn dependency:tree | grep cglib
[INFO] +- cglib:cglib:jar:2.2:compile

Can anyone explain this behaviour, if it's a bug or if something is
possibly wrong with my configuration. It's really annoying, because I
have to manually remove these from the CP after I run eclipse:eclipse
in order for my application to run through Eclipse (including running
unit tests etc).

However running mvn test works fine, so to me it seems there might be
something with the eclipse:eclipse plugin. Has anyone experienced
similar issues?

Cheers,
Jaran

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Third party jars

2008-12-02 Thread John.Baker
Hi,

Thanks for the suggestion, but I was already aware of this and I was
wondering if there's an easier mechanism?   Such as mvn being smart with
the jar name and coming up with the group/artifact ID, but I suspect
that's beginning to ask too much!


John

 -Original Message-
 From: Stephen Connolly [mailto:[EMAIL PROTECTED] 
 Sent: 01 December 2008 08:49
 To: Maven Users List
 Subject: Re: Third party jars
 
 mvn deploy:deploy-file -DgroupId=foo -DartifactId=bar 
 -Dversion=1.0-foo -Dpackaging=jar -DgeneratePom=true 
 -Dfile=foo.jar ...
 
 And with newer versions of the maven-deploy-plugin, 
 generatePom defaults to true.
 
 It should be trivial for you to write a shell script or batch 
 file that loops through all the jar files in a directory and 
 just calls mvn to do the deploy for you.
 
 (BTW, the generated pom is a minimal pom, and does not 
 specify dependencies, but you just want to pull them all in, 
 so it will work for you and get you up and running)
 
 -Stephen
 
 2008/12/1 [EMAIL PROTECTED]
 
  Hi,
 
  Thanks for all the feedback.  I guess my reasoning was that 
 inventing 
  the meta data (group/artifactId/version) for 20 jars is a 
 little time 
  consuming - is there an easier way to do this?  I.e. Is 
 there a maven 
  command to take a directory full of jars and upload them 
 into my local 
  repository (~/.m2/repository) and generate a set of dependency 
  information for me?  Or even a pom with all the dependencies!
 
 
  John
 
   -Original Message-
   From: Alex Athanasopoulos [mailto:[EMAIL PROTECTED]
   Sent: 29 November 2008 10:34
   To: Maven Users List
   Subject: Re: Third party jars
  
   Why not put the jars in a repository?  A repository is 
 perfect for 
   containing 3rd party jars, and one of maven's major 
 benefits.  Once 
   you do that, you don't need to refer to the jars through 
 a hardcoded 
   path, but simply by a portable artifact identifier.  You 
 don't need 
   any special tools or repository managers, but you do need 
 to setup 
   your own remote repository somehow.
  
   I simply use mvn install:install-file, and then copy the 
 generated 
   files from my local repository to a remote repository that I have 
   created just for 3rd party libs.
  
   I'm fairly new to maven, and this is one of the first 
 things I had 
   to do.
The rest is just defining and managing repositories, 
 which can be a 
   discussion of its own.  I'm not using any repository managers yet 
   (learning to live with maven is enough work for me right 
 now).  My 
   A-B-Cs of repository management have been the following:
  
   A)  At first I used only my local repository, which I shared with 
   other developers by putting it under version control in svn, just 
   like I had my
   3rd party libs before maven.   I used mvn -o most of the
   time, to avoid
   accessing Maven's central repository.  I was a bit annoyed that I 
   had to use -o.  I tried to use the offline configuration in 
   settings.xml, but I couldn't get it to work (one of my first 
   frustrations with maven).  mvn -o worked reliably, but I had to 
   remember to use it.  Whenever I needed a piece of Maven that I 
   didn't have, I used mvn without the -o flag, and once everything 
   worked, I added the new artifacts from my local 
 repository to svn.  
   I did not add my snapshots.
  
   B)  I then figured out how to avoid the -o flag, by defining a 
   mirror of the central repository in my settings.xml.  The 
 mirror was 
   simply an http-accessible location of the single svn-managed 
   repository that I had.
Whenever I needed to use a new piece of maven, I 
 commented out the 
   mirror specifiction in my settings.xml, ran mvn so it 
 could get new 
   pieces from repo1.maven.org, and then took the comment out of 
   settings.xml.  The rest was as in A.
  
   C)  I now use two repositories:
   1)  A repository of non-maven released artifacts.
   Essentially this contains 3rd party libraries.  These are 
 libraries 
   that I've gotten directly from their source, and which 
 I've entered 
   in the repository through install:install-file.  I plan 
 to also put 
   my own released artifacts there.
  
   2)  A central-mirror repository that has just the things 
 that maven 
   needs (plugins and their dependencies).  This is the most 
 difficult 
   repository to manage, and a source of problems, as I find maven's 
   dependencies chaotic and unstable.  This is why I've 
 isolated them 
   from my other artifacts.
  
   D)  I plan to also use a snapshots repository that is 
 automatically 
   updated with my daily build artifacts.  In fact, I may simply 
   provide http access to the daily build's local repository.
   For now, I rebuild all of my artifacts locally.
  
   Alex
  
   On Fri, Nov 28, 2008 at 10:38 PM,
   [EMAIL PROTECTED] wrote:
  
Hi,
   
Is there any way to get the maven build process to 
 include a set 
of jars when compiling/packaging that are not in 

Repo1 Mirrors not Updated

2008-12-02 Thread Reinhard Nägele
Hi,

I was just trying to set up a new Wicket application using 
wicket-archetype-quickstart. I tried versions 1.3.5 and 1.4-rc1. Both failed. I 
then checked repo1 and did find the archetype artifacts. Then I figured we were 
using a repo1 mirror. I checked there and noticed that both, 1.3.5 and 1.4-rc1, 
did not make it to the mirror. I then checked several other public mirrors. 
None of them had the artifacts.

So, my question is why the mirrors were not updated. I thought mirrors were 
updated daily.

Reinhard


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Third party jars

2008-12-02 Thread Wayne Fay
 Thanks for the suggestion, but I was already aware of this and I was
 wondering if there's an easier mechanism?   Such as mvn being smart with
 the jar name and coming up with the group/artifact ID, but I suspect
 that's beginning to ask too much!

This just isn't something Maven can help you with. Write a shell
script that receives the version and groupId, runs through all the
items named *.jar in the directoy, uses the file name as the
artifactId, and then outputs the dependencies list at the end after
using mvn install or mvn deploy on them. I know someone posted
something along these lines a while back on this list, but don't
remember specifics, so you can search the archives and try to find it.

If you do create something, please send it back to this list or put it
in the Maven Users Wiki so others can benefit in the future.

Wayne

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Repo1 Mirrors not Updated

2008-12-02 Thread Carlos Sanchez
can you send the exact urls you were looking for?

On Tue, Dec 2, 2008 at 2:56 AM, Reinhard Nägele
[EMAIL PROTECTED] wrote:
 Hi,

 I was just trying to set up a new Wicket application using 
 wicket-archetype-quickstart. I tried versions 1.3.5 and 1.4-rc1. Both failed. 
 I then checked repo1 and did find the archetype artifacts. Then I figured we 
 were using a repo1 mirror. I checked there and noticed that both, 1.3.5 and 
 1.4-rc1, did not make it to the mirror. I then checked several other public 
 mirrors. None of them had the artifacts.

 So, my question is why the mirrors were not updated. I thought mirrors were 
 updated daily.

 Reinhard


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Repo1 Mirrors not Updated

2008-12-02 Thread Brian E. Fox
We push daily to a few mirrors, other mirrors are pulling from some other 
locations. Which mirror are you trying to use?

-Original Message-
From: Reinhard Nägele [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 02, 2008 2:56 AM
To: users@maven.apache.org
Subject: Repo1 Mirrors not Updated

Hi,

I was just trying to set up a new Wicket application using 
wicket-archetype-quickstart. I tried versions 1.3.5 and 1.4-rc1. Both failed. I 
then checked repo1 and did find the archetype artifacts. Then I figured we were 
using a repo1 mirror. I checked there and noticed that both, 1.3.5 and 1.4-rc1, 
did not make it to the mirror. I then checked several other public mirrors. 
None of them had the artifacts.

So, my question is why the mirrors were not updated. I thought mirrors were 
updated daily.

Reinhard


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: RE : [deploy-plugin] Abort deploy when a target is present

2008-12-02 Thread solo1970

Somehow I'm getting a little bit lost!!!  I tried to read the feeds but I
don't quite get it!

I'm just starting out with Maven (ver. 2.0.9) and I would like to have this
feature of NO re-reployement of the same version.  Can someone summarize?

How do I do this?  Is it available

Sonia




MATHUS Baptiste wrote:
 
 Hi all,
 
 If some people were still interested in this subject, I found the
 codecommit Brian was speaking about.
 I also commented the bug I logged: 
 http://jira.codehaus.org/browse/MDEPLOY-74?focusedCommentId=129147#action_129147
 
 The related improvement request (logged by Jason):
 http://jira.codehaus.org/browse/MARTIFACT-6
 
 With this modification, at the moment, the situation will be reversed: you
 won't be able to redeploy an artifact that has already been deployed (no
 problem for snapshot, which is taken apart). So, don't do mistakes :).
 You'll have to connect to your repository and manually deploy the wrong
 artifact(s).
 Anyway, Imo, it's actually far better to have no option in this case than
 in the old one (being able to redeploy any time you want).
 
 Cheers.
 
 -Original Message-
 From: Brian E. Fox [mailto:[EMAIL PROTECTED]
 Sent: Fri 3/28/2008 2:59 PM
 To: Maven Users List
 Subject: RE: RE : [deploy-plugin] Abort deploy when a target is present
  
 I'd have to check on this. I know in 2.1 it's on by default and there is
 no way to force it. Perhaps Jason put it in the wagon manager or something
 and not the plugin. 
 
 -Original Message-
 From: MATHUS Baptiste [mailto:[EMAIL PROTECTED] 
 Sent: Friday, March 28, 2008 2:53 AM
 To: Maven Users List
 Subject: RE : [deploy-plugin] Abort deploy when a target is present
 
 Great news!
 
 I had a quick look on
 https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/
 and did not see any log related to it.
 So was there already a logged bug about this:
 http://jira.codehaus.org/browse/MDEPLOY-74
 
 What/where is the new code, some 3.x or something? So, is there another
 svn repository for this? In fact, I'd be happy to be able to either use a
 new released version or help merging back this feature if possible.
 
 Cheers
 
  Message d'origine
 De: Brian E. Fox [mailto:[EMAIL PROTECTED]
 Date: jeu. 27/03/2008 18:45
 À: Maven Users List
 Objet : RE: [deploy-plugin] Abort deploy when a target is present
  
 This is the default in the new code, but it wasn't merged back to 2.0.x I
 believe.
 
 -Original Message-
 From: MATHUS Baptiste [mailto:[EMAIL PROTECTED]
 Sent: Thursday, March 27, 2008 9:32 AM
 To: Maven Users List
 Subject: [deploy-plugin] Abort deploy when a target is present
 
 Hi all,
 
 Recently, some developers did a release manually. So they put a release
 version in the pom and triggered a deploy. Everything fine but...
 The thing is: they forgot to re-update the pom.version to a new snapshot
 version.
 
 So, as the code is continuously integrated, at each new commit, the recent
 release was automatically overridden many times with the snapshot code
 before realizing it :-/.
 So, what I would like is to be able to put an additional option for maven
 when run inside the continuous integration server, something like
 -DdontOverrideRelease, that would make fail the deployment if the released
 artefact is already present.
 
 I've taken a quick look at
 http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html but
 it seems it's not currently possible.
 What do you think? Can a file an feature request about it in the plugin
 tracker?
 
 Thanks a lot.
 
 Cheers.
 --
 Baptiste
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-- 
View this message in context: 
http://www.nabble.com/-deploy-plugin--Abort-deploy-when-a-target-is-present-tp16329568p20800811.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: LATEST and RELEASE

2008-12-02 Thread Timothy Reilly
Just an observation from today when RELEASE didn't work for us. 

I was at someone's desk who normally build's the parent pom we are
trying to reference as RELEASE. His last build of the pom or perhaps
every build to his local repository is done without mvn install
-DupdateReleaseInfo=true (so false.) The dependent project failed to
build due to not resolving the RELEASE version. He rebuilt the parent
(corporate pom) with -DupdateReleaseInfo=true and then it worked.

My guess is that when RELEASE version is being resolved it finds the
artifact in the local repository but doesn't find the release metadata
and fails.
Perhaps, while resolving RELEASE all configured repositories need or
should be consulted... Seems like that doesn't happen. (first find fail)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



How to make .java files in src/main/resources available at runtime?

2008-12-02 Thread Geoffrey Kwan
Hi,

I'm trying to include some .java files in my src/main/resources but at
runtime those files get compiled and only the .class files are available. I
have placed .jpg, .txt, and .java files in my src/main/resources and what
ends up there at runtime is .jpg, .txt, and .class files. How can I make the
.java files available in my resources at runtime? I need the .java files
because they are going to be used by another application that interacts with
my application.

I have tried including .java files by following the directions here
http://maven.apache.org/plugins/maven-resources-plugin/examples/include-exclude.html
but my resources folder ended up completely empty at runtime.

Thanks,
Geoff