Multiple project dependencies

2008-11-03 Thread John.Baker

 Hello,
 
 I'm new to maven and I have a question regarding multiple projects and
 how the can be linked.  I've created a common code project, and I
 have another which depends upon this project.  I've got two
 directories, two pom files, etc., and the common code project can
 generate a jar file (mvn jar:jar).  The other project has a dependency
 in the pom.xml file:
 
 dependency
 groupIdcom.x.common/groupId
 artifactIdx.common/artifactId
 version0.0.1-SNAPSHOT/version
 /dependency
 
 When the mvn process runs, it contacts the repositories and tries to
 download this dependency, which will obviously fail.  How do I
 configure mvn to look locally for a dependency, and in this case, run
 mvn jar:jar in the common project directory to obtain the required
 jar?
 
 Many thanks,
 
 
 John
___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
___

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



RE: Multiple project dependencies

2008-11-04 Thread John.Baker
Graham,

Thanks for your advice.  I was wondering if parent/child relationships
were the answer.  However, there are two problems with this approach. 

The first is that I'm writing a plugin to a product and it created the
maven project, and I note it's declared a parent:

parent
groupIdcom.atlassian.confluence.plugin.base/groupId
artifactIdconfluence-plugin-base/artifactId
version17/version
/parent

So, my plugin already depends on the Confluence Plugin base, and depends
on my common code pom.  How is this structured?

The second is that I'm still somewhat unfamilar with the directory
structure for the parent/child relationships.  If I had poarent project
and two child projects, how does the parent tag of the child project
know where to find the parent project (on the filesystem).

Thanks,


John 

 -Original Message-
 From: Graham Leggett [mailto:[EMAIL PROTECTED] 
 Sent: 03 November 2008 21:00
 To: Maven Users List
 Subject: Re: Multiple project dependencies
 
 [EMAIL PROTECTED] wrote:
 
  I'm new to maven and I have a question regarding multiple projects 
  and how the can be linked.  I've created a common code 
 project, and 
  I have another which depends upon this project.  I've got two 
  directories, two pom files, etc., and the common code project can 
  generate a jar file (mvn jar:jar).  The other project has a 
  dependency in the pom.xml file:
 
  dependency
  groupIdcom.x.common/groupId
  artifactIdx.common/artifactId
  version0.0.1-SNAPSHOT/version
  /dependency
  
  When the mvn process runs, it contacts the repositories 
 and tries to 
  download this dependency, which will obviously fail.  How do I 
  configure mvn to look locally for a dependency, and in 
 this case, run 
  mvn jar:jar in the common project directory to obtain the required 
  jar?
 
 It depends on how you want to structure your code.
 
 If the common code is likely to follow it's own release 
 cycle, make a formal release of the common code, and then 
 make your code depend on that formal release. Don't do this 
 manually, use the release plugin to do this for you.
 
 If the common code is likely to change alongside the other 
 code, you might choose to build and release all the jars 
 together in one go.
 
 What you want to do is create a multi-module project by 
 creating a parent pom project, and add each of the multi 
 modules as children of this parent, using the module 
 element in the pom. In each child project, add the parent 
 tag pointing back to the parent pom.
 
 When you build the parent, all the modules listed within the 
 parent will be built.
 
 If your dependencies are configured correctly, maven will 
 figure out for itself what order things should be built in.
 
 Hint: in your children projects, make them inherit the 
 parent's version by putting in ${pom.version} as a variable. 
 For example:
 
   dependency
   groupIdcom.x.common/groupId
   artifactIdx.common/artifactId
   version${pom.version}/version
   /dependency
 
 When you release the parent, the children will be released 
 and versioned automatically.
 
 Regards,
 Graham
 --
 
___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
___

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



RE: Multiple project dependencies

2008-11-06 Thread John.Baker
Hi Rafael,

Thanks for your response.

My question surrounds dependencies, and while I understand how to
declare a dependency, what I want to know is how I make maven recompile
dependencies.

So if A depends on B, and I run 'mvn jar' in project B, how can I make
it recompile (and I guess, run 'mvn install') in A?  My scenerio is that
I will be making changes to both A and B, but both are separate projects
and I don't want to have to run 'mvn install' in A before doing anything
with project B.  Obviously, if A depends on B, A will not compile if B
has been modified in some way given A fetches A.jar from the repository.

Neither A or B share a common parent.  In fact, they could easily have
different parents.

Thanks,


John

 -Original Message-
 From: Rafael Trestini [mailto:[EMAIL PROTECTED] 
 Sent: 04 November 2008 18:32
 To: Maven Users List
 Subject: Re: Multiple project dependencies
 
 John,
 
 In this case, your parent pom (1st level pom.xml) will 
 inherit from 
 com.atlassian.concluence.plugin.base:confluence-plugin-base:17
 , and each module will inherit your parent pom. Example:
 /yourproject
pom.xml (your parent pom - inherits confluence plugin)
   /module-a
  pom.xml (your module-a pom - inherits parent pom)
   /module-b
  pom.xml (your module-b pom - inherits parent pom)
 
 Using the structure from example, your parent pom would use 
 the following module declaration:
 modules
modulemodule-a/module
modulemodule-b/module
 /modules
 
 In this approach, maven will search for a subdirectory named 
 module-a and other named module-b, each one containing a pom.xml.
 
 Remembering: there's a significant difference between 
 inheritance and dependency. If you need to *use*, for 
 example, X.jar that contains shared and/or common code, the 
 relation between this jar and your project is a dependency, 
 and not a inheritance, because X.jar is not _part-of_ your 
 project. However, if you have a module inside your project 
 with common code that concerns exclusively to the project, 
 this module is _part-of_ and is shared with other modules 
 inside your project.
 
 Hope it helps.
 
 Rafael Trestini
 
 On Tue, Nov 4, 2008 at 6:08 AM, 
 [EMAIL PROTECTED] wrote:
 
  Graham,
 
  Thanks for your advice.  I was wondering if parent/child 
 relationships 
  were the answer.  However, there are two problems with this 
 approach.
 
  The first is that I'm writing a plugin to a product and it 
 created the 
  maven project, and I note it's declared a parent:
 
 parent
 groupIdcom.atlassian.confluence.plugin.base/groupId
 artifactIdconfluence-plugin-base/artifactId
 version17/version
 /parent
 
  So, my plugin already depends on the Confluence Plugin base, and 
  depends on my common code pom.  How is this structured?
 
  The second is that I'm still somewhat unfamilar with the directory 
  structure for the parent/child relationships.  If I had poarent 
  project and two child projects, how does the parent tag 
 of the child 
  project know where to find the parent project (on the filesystem).
 
  Thanks,
 
 
  John
 
   -Original Message-
   From: Graham Leggett [mailto:[EMAIL PROTECTED]
   Sent: 03 November 2008 21:00
   To: Maven Users List
   Subject: Re: Multiple project dependencies
  
   [EMAIL PROTECTED] wrote:
  
I'm new to maven and I have a question regarding multiple 
projects and how the can be linked.  I've created a 
 common code
   project, and
I have another which depends upon this project.  I've got two 
directories, two pom files, etc., and the common code 
 project can 
generate a jar file (mvn jar:jar).  The other project has a 
dependency in the pom.xml file:
   
dependency
groupIdcom.x.common/groupId
artifactIdx.common/artifactId
version0.0.1-SNAPSHOT/version
/dependency
   
When the mvn process runs, it contacts the repositories
   and tries to
download this dependency, which will obviously fail.  How do I 
configure mvn to look locally for a dependency, and in
   this case, run
mvn jar:jar in the common project directory to obtain the 
required jar?
  
   It depends on how you want to structure your code.
  
   If the common code is likely to follow it's own release 
 cycle, make 
   a formal release of the common code, and then make your 
 code depend 
   on that formal release. Don't do this manually, use the release 
   plugin to do this for you.
  
   If the common code is likely to change alongside the 
 other code, you 
   might choose to build and release all the jars together in one go.
  
   What you want to do is create a multi-module project by 
 creating a 
   parent pom project, and add each of the multi modules as 
 children of 
   this parent, using the module element in the pom. In each child 
   project, add the parent tag pointing back to the parent pom.
  
   

RE: Multiple project dependencies

2008-11-07 Thread John.Baker
Hi,

B is a set of common code (such as LDAP user retrieval), and multiple projects 
will require this code.  I could simply have one project and a common package 
for what would reside in B, but I'd prefer to break it out as the unified 
source tree approach would become heavily dependent on multiple other systems.  
For example, if I'm writing a plugin for Confluence or JIRA then I want the 
builds to contain no references to the other product, however both require the 
common code.

I think Jorg's approach solves my problem.  It breaks up the projects into 
logical standalone components, while allowing me to compile them and produce a 
jar simultaneously.  However if there's a different approach then do let me 
know?  

I guess what I thought maven would provide is a mechanism that would check for 
changes in source to a dependency, and if so, compile those changes into 
classes before compiling the target.  So in my scenerio, I would compile A and 
that would result in a javac being run on the source of B, and the resulting 
classes being used to compile A - instead of a jar being generated for B, which 
is then installed in the repository, before being extracted to compile and jar 
A.


John

 -Original Message-
 From: Rafael Trestini [mailto:[EMAIL PROTECTED] 
 Sent: 06 November 2008 15:30
 To: Maven Users List
 Subject: Re: Multiple project dependencies
 
 John
 
 The Jorg's solution is very nice for your technical problem, 
 mainly if just one developer is working on codes.
 
 But let me know about development lifecycles of your 
 projects: If A depends B, but have no common code between 
 them, I suppose their have different life cycles. So when 
 you're coding into A, you must depend of a certain version of 
 B (ex: B-0.0.1-SNAPSHOT.jar) that is in your local 
 repository. If you have to modify B, when you use 'mvn 
 install', this version of B will be updated in repo, 
 consequently, available locally to A, without have to use 
 'mvn install' in A. ('mvn install'
 installs the package to local repository).
 In other hand, if there's a modification in B which broken 
 compatibility with A, you must to generate a new version of B (ex:
 B-0.1.0-SNAPSHOT.jar) and update pom.xml of A, for new 
 version of dependency (re-generating your IDE metadata, if 
 was the case).
 
 Rafael
 
 On Thu, Nov 6, 2008 at 8:42 AM, Jörg Schaible 
 [EMAIL PROTECTED] wrote:
  [EMAIL PROTECTED] wrote:
  Hi Rafael,
 
  Thanks for your response.
 
  My question surrounds dependencies, and while I understand how to 
  declare a dependency, what I want to know is how I make maven 
  recompile dependencies.
 
  So if A depends on B, and I run 'mvn jar' in project B, how can I 
  make it recompile (and I guess, run 'mvn install') in A?  
 My scenerio 
  is that I will be making changes to both A and B, but both are 
  separate projects and I don't want to have to run 'mvn 
 install' in A 
  before doing anything with project B.  Obviously, if A 
 depends on B, 
  A will not compile if B has been modified in some way 
 given A fetches 
  A.jar from the repository.
 
  Neither A or B share a common parent.  In fact, they could easily 
  have different parents.
 
  You can use what I call a builder POM. Create a pom.xml 
 somewhere with minimal entries and a module section ...
 
  modules
 modulepath to A/module
 modulepath to B/module
  /modules
 
  ... and build from the location of this builder POM. You 
 can give the pom a different name if you start Maven with the 
 -f option.
 
  - Jörg
 
  
 -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 
 --
 Responsibility is the price of freedom
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its 

RE: Multiple project dependencies

2008-11-10 Thread John.Baker
Hello,

Thanks for your feedback.

I really don't think I'm trying to make a simple problem into a
difficult one, so perhaps I can outline my thoughts again?

Consider two separate projects:  common and plugin.  In Eclipse, you'd
create two projects and add common to the build path of plugin.  If I
recall correctly, we can build these projects as a pair and run plugin -
any changes to the common project are reflected in plugin as it's run.

If I have to maven projects, common and plugin, where plugin declares
the dependency on common, the compilation process becomes a little more
tedious.  If a change is made to common, make install (compile a jar and
place into the repository) must be run before a make install/jar/etc.
can be run in the plugin project.  I guess this isn't an awful price to
pay if most of the work is being performed in Eclipse and running maven
is the last thing to do.  

It would be nice if maven had a mode where by it checked (perhaps
marked) dependencies for changes before possibly recompiling a new jar
and insertinog into the repository.  Obviously, if a build directory
exists and no source files have been changed (so no new classes are
generated), it need do nothing.  However if changes were detected then
it could rebuild a new jar and place into the repository.


John

 -Original Message-
 From: Graham Leggett [mailto:[EMAIL PROTECTED] 
 Sent: 07 November 2008 10:20
 To: Maven Users List
 Subject: Re: Multiple project dependencies
 
 [EMAIL PROTECTED] wrote:
 
  My question surrounds dependencies, and while I understand how to 
  declare a dependency, what I want to know is how I make maven 
  recompile dependencies.
  
  So if A depends on B, and I run 'mvn jar' in project B, how 
 can I make 
  it recompile (and I guess, run 'mvn install') in A?  My scenerio is 
  that I will be making changes to both A and B, but both are 
 separate 
  projects and I don't want to have to run 'mvn install' in A before 
  doing anything with project B.  Obviously, if A depends on 
 B, A will 
  not compile if B has been modified in some way given A 
 fetches A.jar from the repository.
  
  Neither A or B share a common parent.  In fact, they could 
 easily have 
  different parents.
 
 Having read and reread this, my gut feeling is that you're 
 potentially trying to make a simple problem into a complicated one.
 
 If A depends on B, and you want to B to trigger stuff 
 happening in A, that sounds like a classic circular 
 dependency problem, which is broken regardless of what build 
 strategy you use.
 
 Can you describe in more detail what problem you are trying solve?
 
 Regards,
 Graham
 --
 
___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
___

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



RE: Multiple project dependencies

2008-11-10 Thread John.Baker
Hi,

Perhaps I am simply thinking about one developer making life easier for 
themselves!  I hadn't considered the multiple developer aspect, although it may 
still be handy to have such functionality.  However someone suggested something 
about a parent pom and multiple modules, which seems a neat way of achieving 
such functionality without doing anything to maven.


John 

 -Original Message-
 From: Rafael Trestini [mailto:[EMAIL PROTECTED] 
 Sent: 07 November 2008 18:43
 To: Maven Users List
 Subject: Re: Multiple project dependencies
 
 John,
 
  I guess what I thought maven would provide is a mechanism 
 that would check for changes in source to a dependency, and 
 if so, compile those changes into classes before compiling the target.
 I'm not secure about this, but I guess maven don't do it (if 
 I'm wrong, please someone correct me). Maven check for update 
 in binary, not in source. It means when someone changes B, he 
 must do a 'mvn install' to copy this package (binary) to 
 local repository, and who is using A must have to get this 
 new version of dependency.
 In case where there's just one developer and just one 
 machine, this process is transparent, since all dependencies 
 points to same
 reference: the local repository.
 On other hand, if there's more then one developer, you have 
 to do 'mvn deploy' when the change is done, and, for example, 
 'mvn dependency:resolve' to update from repote do local repo.
 
 Trestini
 
 On Fri, Nov 7, 2008 at 7:40 AM,  
 [EMAIL PROTECTED] wrote:
  Hi,
 
  B is a set of common code (such as LDAP user retrieval), 
 and multiple projects will require this code.  I could simply 
 have one project and a common package for what would reside 
 in B, but I'd prefer to break it out as the unified source 
 tree approach would become heavily dependent on multiple 
 other systems.  For example, if I'm writing a plugin for 
 Confluence or JIRA then I want the builds to contain no 
 references to the other product, however both require the common code.
 
  I think Jorg's approach solves my problem.  It breaks up 
 the projects into logical standalone components, while 
 allowing me to compile them and produce a jar simultaneously. 
  However if there's a different approach then do let me know?
 
  I guess what I thought maven would provide is a mechanism 
 that would check for changes in source to a dependency, and 
 if so, compile those changes into classes before compiling 
 the target.  So in my scenerio, I would compile A and that 
 would result in a javac being run on the source of B, and the 
 resulting classes being used to compile A - instead of a jar 
 being generated for B, which is then installed in the 
 repository, before being extracted to compile and jar A.
 
 
  John
 
  -Original Message-
  From: Rafael Trestini [mailto:[EMAIL PROTECTED]
  Sent: 06 November 2008 15:30
  To: Maven Users List
  Subject: Re: Multiple project dependencies
 
  John
 
  The Jorg's solution is very nice for your technical 
 problem, mainly 
  if just one developer is working on codes.
 
  But let me know about development lifecycles of your
  projects: If A depends B, but have no common code between them, I 
  suppose their have different life cycles. So when you're 
 coding into 
  A, you must depend of a certain version of B (ex: 
  B-0.0.1-SNAPSHOT.jar) that is in your local repository. If 
 you have 
  to modify B, when you use 'mvn install', this version of B will be 
  updated in repo, consequently, available locally to A, 
 without have 
  to use 'mvn install' in A. ('mvn install'
  installs the package to local repository).
  In other hand, if there's a modification in B which broken 
  compatibility with A, you must to generate a new version of B (ex:
  B-0.1.0-SNAPSHOT.jar) and update pom.xml of A, for new version of 
  dependency (re-generating your IDE metadata, if was the case).
 
  Rafael
 
  On Thu, Nov 6, 2008 at 8:42 AM, Jörg Schaible 
  [EMAIL PROTECTED] wrote:
   [EMAIL PROTECTED] wrote:
   Hi Rafael,
  
   Thanks for your response.
  
   My question surrounds dependencies, and while I 
 understand how to 
   declare a dependency, what I want to know is how I make maven 
   recompile dependencies.
  
   So if A depends on B, and I run 'mvn jar' in project B, 
 how can I 
   make it recompile (and I guess, run 'mvn install') in A?
  My scenerio
   is that I will be making changes to both A and B, but both are 
   separate projects and I don't want to have to run 'mvn
  install' in A
   before doing anything with project B.  Obviously, if A
  depends on B,
   A will not compile if B has been modified in some way
  given A fetches
   A.jar from the repository.
  
   Neither A or B share a common parent.  In fact, they 
 could easily 
   have different parents.
  
   You can use what I call a builder POM. Create a pom.xml
  somewhere with minimal entries and a module section ...
  
   modules
  modulepath to A/module
  

Tomcat projects

2008-11-13 Thread John.Baker
Hello,

Is there a parent project that will insist in deploying resources to a
Tomcat project?  I am currently doing:

mvn -o jar:jar; cp target/CreateOrCommentHandler-0.0.1-SNAPSHOT.jar
~/tomcat/webapps/myapp/WEB-INF/lib/

However this doesn't seem very in tune with maven's way of doing things.
I'm writing a plugin for JIRA, so I assume there may be a parent project
that runs a local copy of Tomcat, but is there a smarter way?  If not,
how would I achieve the above?

Traditionally, I'd write an ant build file to deploy my jar file (and
any other resources - although in this case, I have just one jar file).

Finally, I noticed there was a way to get a list of targets in maven1 -
does this switch exist in maven2?

Thanks,


john


___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
___

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



RE: Tomcat projects

2008-11-14 Thread John.Baker
Hi,
 

 -Original Message-
 From: Wayne Fay [mailto:[EMAIL PROTECTED] 
 Sent: 13 November 2008 18:14
 To: Maven Users List
 Subject: Re: Tomcat projects

 Google tells me there are a few tomcat plugins for Maven.
 http://mojo.codehaus.org/tomcat-maven-plugin/
 http://cargo.codehaus.org/
 (read more: 
 http://www.gorerle.com/vlab-wiki/index.php?title=Tomcat_Deploy
 ment_in_Maven2)

I'll have a read.

  mvn -o jar:jar; cp target/CreateOrCommentHandler-0.0.1-SNAPSHOT.jar
  ~/tomcat/webapps/myapp/WEB-INF/lib/
 
 Any particular reason why you're invoking jar:jar rather than 
 simply mvn package, or even better, mvn clean package?

Well it takes 57 seconds to do something that should take a few seconds
using mvn package. 

I find that when I'm writing web projects, I want to deploy in under 5
seconds - if one is rapidly iterating between fiddling with javascript
and testing, a huge build process does not help.  I think it's very
important to keep this point on board when devising build systems.

  Finally, I noticed there was a way to get a list of targets 
 in maven1 
  - does this switch exist in maven2?
 
 The concept of a list of targets is not appropriate for 
 Maven2, as it is for ant and m1. You should be binding 
 plugins to the build lifecycle so every build automatically 
 uses the various plugins it requires at the proper time 
 during the lifecycle of your build.

If mvn package isn't a target, it's something else, and whatever else it
may be, it's something I pass to mvn to get output.  Therefore,
something to list these would be very helpful :)

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

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
___

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



Third party jars

2008-11-28 Thread John.Baker
Hi,

Is there any way to get the maven build process to include a set of jars
when compiling/packaging that are not in the repository?  I have some
vendor jars and I don't fancy packing them all up and placing them into
the repository - I just want to point maven at a lib directory?

Thanks,


john
___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
___

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



RE: Third party jars

2008-11-28 Thread John.Baker
Excellent - do you happen to have a pom extract to, say, include the
contents of ./lib on the compile path? 

 -Original Message-
 From: David C. Hicks [mailto:[EMAIL PROTECTED] 
 Sent: 28 November 2008 20:45
 To: Maven Users List
 Subject: Re: Third party jars
 
 The assembly plugin can add arbitrary files to your package.
 
 
 [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 the 
 repository?  I have 
  some vendor jars and I don't fancy packing them all up and placing 
  them into the repository - I just want to point maven at a 
 lib directory?
 
  Thanks,
 
 
  john
  ___
 
  This e-mail may contain information that is confidential, 
 privileged or otherwise protected from disclosure. If you are 
 not an intended recipient of this e-mail, do not duplicate or 
 redistribute it by any means. Please delete it and any 
 attachments and notify the sender that you have received it 
 in error. Unless specifically indicated, this e-mail is not 
 an offer to buy or sell or a solicitation to buy or sell any 
 securities, investment products or other financial product or 
 service, an official confirmation of any transaction, or an 
 official statement of Barclays. Any views or opinions 
 presented are solely those of the author and do not 
 necessarily represent those of Barclays. This e-mail is 
 subject to terms available at the following link: 
 www.barcap.com/emaildisclaimer. By messaging with Barclays 
 you consent to the foregoing.  Barclays Capital is the 
 investment banking division of Barclays Bank PLC, a company 
 registered in England (number 1026167) with its registered 
 office at 1 Churchill Place, London, E14 5HP.  This email may 
 relate to or be sent from other members of the Barclays Group.
  ___
 
  
 -
  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]
 
 
___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
___

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



RE: Third party jars

2008-12-01 Thread John.Baker
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 the 
 repository?  I have 
  some vendor jars and I don't fancy packing them all up and placing 
  them into the repository - I just want to point maven at a 
 lib directory?
 
  Thanks,
 
 
  john
  ___
 
  This e-mail may contain information that is confidential, 
 privileged 
  or otherwise protected from disclosure. If you are not an intended 
  recipient of this e-mail, do not duplicate or redistribute 
 it by any 
  means. Please delete it and any attachments and notify the 
 sender that 
  you have received it in error. Unless specifically indicated, this 
  e-mail is not an offer to buy or sell or a solicitation to 
 buy or sell 
  any securities, investment products or other financial product or 
  service, an official confirmation of any transaction, or an 
 official 
  statement of Barclays. Any views or opinions presented are solely 
  those of the author and do not necessarily represent those of 
  Barclays. This e-mail is subject to terms available at the 
 following 
  link: www.barcap.com/emaildisclaimer. By messaging with 
 Barclays you 
  consent to the foregoing.  Barclays Capital is the 
 investment banking 
  division of Barclays Bank PLC, a 

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