date:20081002

I suspect the question you are asking is:

Is there any way to know what the timestamp is that has been used in
place of the -SNAPSHOT?

i.e. you need to know if this is 1.0-20081002.110956

The answer is that this value is only determined at the time that the
artifact is deployed... at which point it is too late to modify the
artifact so that it contains the -SNAPSHOT value... plus that would
have a side effect of modifying the artifact that goes into your
remote repository and you would then have different artifacts in your
local and remote repository. (which is a very bad thing)

Otherwise, if you are happy to know that the version is 1.0-SNAPSHOT
and not 0.9-SNAPSHOT or 1.0 then resource filtering is probably
the way to go... or better yet add the version to either the
specification-version or implementation-version attibutes in the
manifest of your jar that way you can pull the version of the class by
something like:

foo.getClass().getPackage().getManifest???().getImplementationVersion???()

2008/10/2 Magne Nordtveit [EMAIL PROTECTED]:
 On Wednesday 24 September 2008 18:42:27 mateamargo wrote:
 I have setted the version to 1.0-SNAPSHOT, but I need to know what's the
 current value. Is there a way to know that using any Maven API? or maybe
 generating a file after compiling?

 Thanks.

 What you can do, is to perform resource filtering on a text file you package
 into the jar, and then read this when querrying for the version. This is what
 we do for a number of our software, and it works like a charm. (Check [1] if
 you are unsure about what i mean)

 If you want to include buildnumber, i think there is a build number generating
 maven plugin you can use. I think i have seen something like that earlier.

 Magne

 [1] - http://maven.apache.org/plugins/maven-resources-plugin/
 --
 Magne Nordtveit [EMAIL PROTECTED]
 Systems Engineer
 Offshore Simulator Centre AS
 http://www.offsimcentre.no


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

Fwd: CFP open for ApacheCon Europe 2009




Begin forwarded message:


If you only have thirty seconds:

The Call for Papers for ApacheCon Europe 2009, to be held in  
Amsterdam, from 23rd to 27th March, is now open! Submit your  
proposals at http://eu.apachecon.com/c/aceu2009/cfp/ before 24th  
October.


Remember that early bird prices for ApacheCon US 2008, to be held in  
New Orleans, from 3rd to 7th November, will go up this Friday, at  
midnight Eastern time!


Sponsorship opportunities for ApacheCon US 2008 and ApacheCon EU  
2009 are still available. If you or your company are interested in  
becoming a sponsor, please contact Delia Frees at  
[EMAIL PROTECTED] for details.


***

If you want all the details:

ApacheCon Europe 2009 - Leading the Wave of Open Source
Amsterdam, The Netherlands
23rd to 27th March, 2009

Call for Papers Opens for ApacheCon Europe 2009

The Apache Software Foundation (ASF) invites submissions to its  
official conference, ApacheCon Europe 2009. To be held 23rd to 27th  
March, 2009 at the Mövenpick Hotel Amsterdam City Centre, ApacheCon  
serves as a forum for showcasing the ASF's latest developments,  
including its projects, membership, and community. ApacheCon offers  
unparalleled educational opportunities, with dedicated  
presentations, hands-on trainings, and sessions that address core  
technology, development, business/marketing, and licensing issues in  
Open Source.


ApacheCon's wide range of activities are designed to promote the  
exchange of ideas amongst ASF Members, innovators, developers,  
vendors, and users interested in the future of Open Source  
technology. The conference program includes competitively selected  
presentations, trainings/workshops, and a small number of invited  
speakers. All sessions undergo a peer review process by the  
ApacheCon Conference Planning team. The following information  
provides presentation category descriptions, and information about  
how to submit your

proposal.

Conference Themes and Topics

APACHECON 2009 - LEADING THE WAVE OF OPEN SOURCE

Building on the success of the last two years, we are excited to  
return to Amsterdam in 2009. We'll be continuing to offer our very  
popular two-day trainings, including certifications of completion  
for those who fulfill all the requirements of these trainings.


The ASF comprises some of the most active and recognized developers  
in the Open Source community. By bringing together the pioneers,  
developers, and users of flagship Open Source technologies,  
ApacheCon provides an influential platform for dialogue, between the  
speaker and the audience, between project contributors and the  
community at large, traversing a wide range of ideas, expertise, and  
personalities.


ApacheCon welcomes submissions from like-minded delegates across  
many fields, geographic locations, and areas of development. The  
breadth and loosely-structured nature of the Apache community lends  
itself to conference content that is also somewhat loosely- 
structured. Common themes of interest address groundbreaking  
technologies and emerging trends, successful practices (from  
development to deployment), and lessons learned (tips, tools, and  
tricks). In addition to technical content, ApacheCon invites  
Business Track submissions that address Open Source business,  
marketing, and legal/licensing issues.


Topics appropriate for submission to this conference are manifold,  
and may include but are not restricted to:


- Apache HTTP server topics such as installation, configuration, and  
migration
- ASF-wide projects such as Lucene, SpamAssassin, Jackrabbit, and  
Maven
- Scripting languages and dynamic content such as Java, Perl,  
Python, Ruby, XSL, and PHP

- Security and e-commerce
- Performance tuning, load balancing and high availability
- New technologies and broader initiatives such as Web Services and  
Web 2.0

- ASF-Incubated projects such as Sling, UIMA, and Shindig


Submission Guidelines
Submissions must include
- Title
- Speaker name, with affiliation and email address
- Speaker bio (100 words or less)
- Short description (50 words or less)
- Full description including abstract and objectives (200 words or
less)
- Expertise level (beginner to advanced)
- Format and duration (trainings vs. general presentation; half-,  
full- or two-day workshop, etc.)
- Intended audience and maximum number of participants (trainings  
only)

- Background knowledge expected of the participants (trainings only)


Types of Presentations

- Trainings/Workshops
- General Sessions
- Case Studies/Industry Profiles
- Invited Keynotes/Panels/Speakers
- Corporate Showcases  Demonstrations

BoF sessions and Fast Feather Track talks will be selected separately

Pre Conference Trainings/Workshops
Held on the first and second day of the conference – 2008-03-23 and  
2008-03-24, Trainings require a registration fee beyond the regular  
conference fee. Proposals may be submitted for half-day (3 hours),  
full-day (6 hours), or

Deterministic update of snapshots


If i am not wrong, with unique=false and policy=daily, snaphot updating
follows this rules:

1.- Update check (and posibly update itself) is made a day after last
publishing in the remote repository of the single artifact being checked. So
it could be at any time, any day, and different for every artifact, as they
are involved in the current build (not all artifacts at the same time at
12:00 pm, for example).

2.- As said in http://docs.codehaus.org/pages/viewpage.action?pageId=22585,
every time a new remote snapshot is published, it will overwrite a local
snapshot regardless of age. This is the only way to provide consistent
behaviour and avoid clock skew - for example, while it might make sense to
honour a local snapshot if it were newer than the remote snapshot, it may be
that the local one was built from older sources and so is, in fact, older.

For me, this could be very confusing in a team development process
(especially 2). 

I think a deterministic way of snapshot updating is preferable using
policiy=never. In this way you always preserve the same snaphots and,
eventually, you can use -U to compile with fresh snaphost and get in sync
with the team.

Of course, you get a deterministic way of snaphot updating at expense of
automatic updates, and posibilly, you can discover that one lazy developer
has never used -U and is using very old snaphots. 

Please, any comments are welcome.
-- 
View this message in context: 
http://www.nabble.com/Deterministic-update-of-snapshots-tp19776315p19776315.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]

DependencyManagement to force scope


I usually think in DependencyManagement as a by default section, i mean,
the version and scope you set in DependencyManagement is the version and
scope you get if ommited in the real dependency in the POM and child POMs.

But, i have found that if i insert  provided scope in the
DependencyManagement section, any compile dependency and transitive compile
dependency will be upgraded to provided.

Is this correct? Is this the intended behavior? If yes, this is a
inetresting tool to exclude artifacts form being packaged, right?


-- 
View this message in context: 
http://www.nabble.com/DependencyManagement-to-force-scope-tp19776450p19776450.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: Deterministic update of snapshots

2008-10-02 Thread Michael McCallum

deterministic and snapshot just don't go together... as the result of any 
update is non-deterministic and being able to undo an update if rather 
difficult.

you can use range to achieve and agile deterministic release process where you 
can roll forward or back anytime you like but get the latest by default...

assuming you have reasonable tests and some communication you rarely break 
people in this way

On Thu, 02 Oct 2008 22:43:03 softwarepills wrote:
 If i am not wrong, with unique=false and policy=daily, snaphot updating
 follows this rules:

 1.- Update check (and posibly update itself) is made a day after last
 publishing in the remote repository of the single artifact being checked.
 So it could be at any time, any day, and different for every artifact, as
 they are involved in the current build (not all artifacts at the same time
 at 12:00 pm, for example).

 2.- As said in http://docs.codehaus.org/pages/viewpage.action?pageId=22585,
 every time a new remote snapshot is published, it will overwrite a local
 snapshot regardless of age. This is the only way to provide consistent
 behaviour and avoid clock skew - for example, while it might make sense to
 honour a local snapshot if it were newer than the remote snapshot, it may
 be that the local one was built from older sources and so is, in fact,
 older.

 For me, this could be very confusing in a team development process
 (especially 2).

 I think a deterministic way of snapshot updating is preferable using
 policiy=never. In this way you always preserve the same snaphots and,
 eventually, you can use -U to compile with fresh snaphost and get in sync
 with the team.

 Of course, you get a deterministic way of snaphot updating at expense of
 automatic updates, and posibilly, you can discover that one lazy developer
 has never used -U and is using very old snaphots.

 Please, any comments are welcome.



-- 
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]

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

Re: How to manipulate the classpath in which a maven plugin operates

2008-10-02 Thread Christian Schuhegger



nicolas de loof-3 wrote:
 
 Add dependencies element to your plugin configuration to extend/override
 the plugin classpath. Please note this works fine only on maven 2.0.9
 

Sorry that I have to come back to this topic. I just added 
  dependency

groupIdorg.codehaus.castor/groupId

artifactIdcastor-codegen/artifactId
version1.2/version
  /dependency
to the dependencies of the castor-maven-plugin 2.0-alpha1 and I get a:
 java.lang.NoClassDefFoundError: org/apache/velocity/context/Context

Is it possible that transitive dependencies are not working for plugin
dependencies? I am using maven 2.0.9.

Thanks for any hints!
-- 
View this message in context: 
http://www.nabble.com/How-to-manipulate-the-classpath-in-which-a-maven-plugin-operates-tp18748495p19776574.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: DependencyManagement to force scope

2008-10-02 Thread Jörg Schaible

softwarepills wrote:
 I usually think in DependencyManagement as a by default section, i
 mean, the version and scope you set in DependencyManagement is the
 version and scope you get if ommited in the real dependency in the POM
 and child POMs.
 
 But, i have found that if i insert  provided scope in the
 DependencyManagement section, any compile dependency and transitive
 compile dependency will be upgraded to provided.
 
 Is this correct?

Yes.

 Is this the intended behavior? 

Yes.

 If yes, this is a inetresting tool to exclude artifacts form being packaged, 
 right?

Yes. 

:)

You'll need M2.0.6 or greater though ...

-Jörg

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

Re: DependencyManagement to force scope


Short and clear.

I didn't found this in either the two books of Maven or in the Maven docs.

Thanks a lot.


softwarepills wrote:
 
 I usually think in DependencyManagement as a by default section, i mean,
 the version and scope you set in DependencyManagement is the version and
 scope you get if ommited in the real dependency in the POM and child POMs.
 
 But, i have found that if i insert  provided scope in the
 DependencyManagement section, any compile dependency and transitive
 compile dependency will be upgraded to provided.
 
 Is this correct? Is this the intended behavior? If yes, this is a
 inetresting tool to exclude artifacts form being packaged, right?
 
 
 

-- 
View this message in context: 
http://www.nabble.com/DependencyManagement-to-force-scope-tp19776450p19776793.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: Deterministic update of snapshots


Thanks for your response.

Yes, you are right. But we are now starting the development of a big system,
so till we reach a stable stage where release is posible, we have many
snaphosts.

I was using deterministic applied to the update moment as now happens that
someone is working on a module and suddenly it get compile errors as some
snapshot has been updated. In that moment he may think that the error is due
to his own changes in the code of the assigned module. The result is that
many people comes to me to ask about strange behaviors of Maven.

So, only to let it clear, my assumptions 1 and 2 are correct?

If the answer is yes, do you think its correct to use policy=never in this
scenario?


Michael McCallum-3 wrote:
 
 deterministic and snapshot just don't go together... as the result of any 
 update is non-deterministic and being able to undo an update if rather 
 difficult.
 
 you can use range to achieve and agile deterministic release process where
 you 
 can roll forward or back anytime you like but get the latest by default...
 
 assuming you have reasonable tests and some communication you rarely break 
 people in this way
 
 On Thu, 02 Oct 2008 22:43:03 softwarepills wrote:
 If i am not wrong, with unique=false and policy=daily, snaphot updating
 follows this rules:

 1.- Update check (and posibly update itself) is made a day after last
 publishing in the remote repository of the single artifact being checked.
 So it could be at any time, any day, and different for every artifact, as
 they are involved in the current build (not all artifacts at the same
 time
 at 12:00 pm, for example).

 2.- As said in
 http://docs.codehaus.org/pages/viewpage.action?pageId=22585,
 every time a new remote snapshot is published, it will overwrite a local
 snapshot regardless of age. This is the only way to provide consistent
 behaviour and avoid clock skew - for example, while it might make sense
 to
 honour a local snapshot if it were newer than the remote snapshot, it may
 be that the local one was built from older sources and so is, in fact,
 older.

 For me, this could be very confusing in a team development process
 (especially 2).

 I think a deterministic way of snapshot updating is preferable using
 policiy=never. In this way you always preserve the same snaphots and,
 eventually, you can use -U to compile with fresh snaphost and get in sync
 with the team.

 Of course, you get a deterministic way of snaphot updating at expense of
 automatic updates, and posibilly, you can discover that one lazy
 developer
 has never used -U and is using very old snaphots.

 Please, any comments are welcome.
 
 
 
 -- 
 Michael McCallum
 Enterprise Engineer
 mailto:[EMAIL PROTECTED]
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Deterministic-update-of-snapshots-tp19776315p19776836.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: DependencyManagement to force scope


To clarify more the matter.

Should we think about DependencyManagement no only as a default value
provider, but also as a modifier of inherited dependencies? 
Does it apply to other parameters like the version itself and optional?.


Jörg Schaible-3 wrote:
 
 softwarepills wrote:
 I usually think in DependencyManagement as a by default section, i
 mean, the version and scope you set in DependencyManagement is the
 version and scope you get if ommited in the real dependency in the POM
 and child POMs.
 
 But, i have found that if i insert  provided scope in the
 DependencyManagement section, any compile dependency and transitive
 compile dependency will be upgraded to provided.
 
 Is this correct?
 
 Yes.
 
 Is this the intended behavior? 
 
 Yes.
 
 If yes, this is a inetresting tool to exclude artifacts form being
 packaged, right?
 
 Yes. 
 
 :)
 
 You'll need M2.0.6 or greater though ...
 
 -Jörg
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/DependencyManagement-to-force-scope-tp19776450p19776904.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]

mysterious assembly-plugin

2008-10-02 Thread Wolfgang.Winter

Hi,

I have great problems to solve a simple requirement with Maven2. I have
a Maven project with several sub-modules. Each submodule has its own
config- and install files. I want to distribute and deploy these files
together with its respective submodule artefact. The assembly-plugin
seems to be appropriate for this task but as I made always the
experience up to now with nearly every Maven functionality, it does not
work as expected and documented and error messages are mysterious.
Furthermore it is very hard to understand the different goals and
parameters of assembly-plugin and from where does it count paths.

 

I defined the plugin in my parent pom:

 

  plugin

artifactIdmaven-assembly-plugin/artifactId

configuration

  descriptors

descriptorassembly-descriptor.xml/descriptor

  /descriptors

  !--
archiveBaseDirectory${project.basedir}/archiveBaseDirectory--

/configuration

executions

  execution

idmake-assembly/id

phasepackage/phase

goals

  goalsingle/goal

/goals

  /execution

/executions

  /plugin

 

I defined the descriptor:

 

assembly

  idinstall/id

  formats

formatzip/format

  /formats

  fileSets

fileSet

  directorysrc/main/install/directory

  outputDirectory/outputDirectory

/fileSet

  /fileSets

  files

file

  sourcereadme.txt/source

  outputDirectory/outputDirectory

file

  /files

/assembly

 

I have modified these two in any possible way, I tried also goal
attached but when I execute mvn install I always get the error: you must
set at least one file.

 

[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-1:single' with
basic configurator --

[DEBUG]   (s) appendAssemblyId = true

[DEBUG]   (f) attach = true

[DEBUG]   (s) basedir = D:\projekte\core

[DEBUG]   (s) descriptors = [Ljava.io.File;@1742c56

[DEBUG]   (s) filters = []

[DEBUG]   (s) finalName = core-0.0.2-SNAPSHOT

[DEBUG]   (s) includeSite = false

[DEBUG]   (s) localRepository = [local] -
file://D:\projekte\maven-repository

[DEBUG]   (s) outputDirectory = D:\projekte\core\target

[DEBUG]   (f) project = MavenProject: net.atos.wlp:core:0.0.2-SNAPSHOT @
D:\projekte\core\pom.xml

[DEBUG]   (s) reactorProjects = [MavenProject:
net.atos.wlp:plugin-setproperties:0.0.2 @
D:\projekte\core\plugin-setproperties\pom.xml, MavenProject:
net.atos.wlp:grandparent-pom:0.0.2 @
D:\projekte\core\grandparent-pom\pom.xml, MavenProject:
net.atos.wlp:core-install:0.0.2-SNAPSHOT @
D:\projekte\core\install\pom.xml, MavenProject:
net.atos.wlp:plugin-jbossinstall:0.0.2-SNAPSHOT @
D:\projekte\core\plugin-jbossinstall\pom.xml, MavenProject:
net.atos.wlp:core:0.0.2-SNAPSHOT @ D:\projekte\core\pom.xml,
MavenProject: net.atos.wlp:core-database:0.0.2-SNAPSHOT @
D:\projekte\core\database\product\pom.xml, MavenProject:
net.atos.wlp:core-config:0.0.2-SNAPSHOT @
D:\projekte\core\config\product\pom.xml, MavenProject:
net.atos.wlp:core-template:0.0.2-SNAPSHOT @
D:\projekte\core\template\pom.xml, MavenProject:
net.atos.wlp:core-translation:0.0.2-SNAPSHOT @
D:\projekte\core\translation\product\pom.xml, MavenProject:
net.atos.wlp:plugin-translationimport:0.0.2-SNAPSHOT @
D:\projekte\core\plugin-translationimport\pom.xml, MavenProject:
net.atos.wlp:plugin-blobloader:0.0.2-SNAPSHOT @
D:\projekte\core\plugin-blobloader\pom.xml, MavenProject:
net.atos.wlp:parent-pom:0.0.2-SNAPSHOT @
D:\projekte\core\parent-pom\pom.xml, MavenProject:
net.atos.wlp:core-commonobjects:0.0.2-SNAPSHOT @
D:\projekte\core\commonobjects\pom.xml, MavenProject:
net.atos.wlp:core-log:0.0.2-SNAPSHOT @
D:\projekte\core\log\product\pom.xml, MavenProject:
net.atos.wlp:core-baselogservice:0.0.2-SNAPSHOT @
D:\projekte\core\baselogservice\product\pom.xml, MavenProject:
net.atos.wlp:core-logbean:0.0.2-SNAPSHOT @
D:\projekte\core\logbean\product\pom.xml, MavenProject:
net.atos.wlp:core-security:0.0.2-SNAPSHOT @
D:\projekte\core\security\product\pom.xml, MavenProject:
net.atos.wlp:core-batch:0.0.2-SNAPSHOT @ D:\projekte\core\batch\pom.xml,
MavenProject: net.atos.wlp:core-messaging:0.0.2-SNAPSHOT @
D:\projekte\core\messaging\product\pom.xml, MavenProject:
net.atos.wlp:core-starterservlet:0.0.2-SNAPSHOT @
D:\projekte\core\starterservlet\product\pom.xml, MavenProject:
net.atos.wlp:core-makeear:0.0.2-SNAPSHOT @
D:\projekte\core\makeear\pom.xml]

[DEBUG]   (f) remoteRepositories = [[internal] -
file://Y:/IPS/Produkt/maven-repository/internal, [central] -
http://repo1.maven.org/maven2]

[DEBUG]   (s) siteDirectory = D:\projekte\core\target\site

[DEBUG]   (s) tarLongFileMode = warn

[DEBUG]   (s) tempRoot = D:\projekte\core\target\archive-tmp

[DEBUG]   (s) workDirectory = D:\projekte\core\target\assembly\work

[DEBUG] -- end configuration --

[INFO] [assembly:single]

[DEBUG] Setting context classloader for plugin to:

Multi-module build and plugin classpath issue

2008-10-02 Thread Werner Guttmann

Hi,

I am committer for the Castor (http://www.castor.org) project, and I am
experiencing 'behaviour' I somehow find hard to understand.

We at castor have a multi-module setup, where some of the modules have
the maven plugin for Castor configured to generate java code from XML
schema. So far, so fine.

It now and then happens that we'd like to override the default
dependency for the Maven plugin for Castor in one module only (to e.g.
integrate some new functionality of the code generator). Whenever we do
this (i.e. add a dependency in the plugin configuration of one module
only) and execute a 'mvn install' in the project directory, we can see
that the new dependency is being picked up but for all modules that use
the Maven plugin for Castor - which is not what we want.

Questions: Is this expected behaviour ? Or are we missing something in
e.g. the plugin configuration to have the isolation we'd like to see ?

If I have failed to make myself understandable, let me know 

Regards
Werner

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

Re: How to manipulate the classpath in which a maven plugin operates

2008-10-02 Thread Werner Guttmann

Christian,

the problem might not be with Maven, but with the Maven plugin for
Castor (or the Castor XML code generator) itself.

If you need to stay with castor 1.2, I'd ask you to switch to e.g. the
user mailing list of Castor to discuss things; if not, why not try

dependency
  groupIdorg.codehaus.castor/groupId
  artifactIdcastor-codegen/artifactId
  version1.3rc1/version
/dependency

which I believe should make your problem disappear.

Werner

Christian Schuhegger wrote:
 
 nicolas de loof-3 wrote:
 Add dependencies element to your plugin configuration to extend/override
 the plugin classpath. Please note this works fine only on maven 2.0.9

 
 Sorry that I have to come back to this topic. I just added 
 dependency
   
 groupIdorg.codehaus.castor/groupId
   
 artifactIdcastor-codegen/artifactId
   version1.2/version
 /dependency
 to the dependencies of the castor-maven-plugin 2.0-alpha1 and I get a:
  java.lang.NoClassDefFoundError: org/apache/velocity/context/Context
 
 Is it possible that transitive dependencies are not working for plugin
 dependencies? I am using maven 2.0.9.
 
 Thanks for any hints!

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

Re: Multi-module build and plugin classpath issue

As far as I understand,

currently in Maven there is not isolation between plugins in different
projects.

If you have a multi-module build, the first use of a plugin in that
multi-module build will determine both the version and the dependencies that
are loaded into it's classloader for all subsequent plugin invokations
during the reactor build.

I'm not sure if this is what you wanted to hear, but it is what it is :-(

-Stephen

2008/10/2 Werner Guttmann [EMAIL PROTECTED]

 Hi,

 I am committer for the Castor (http://www.castor.org) project, and I am
 experiencing 'behaviour' I somehow find hard to understand.

 We at castor have a multi-module setup, where some of the modules have
 the maven plugin for Castor configured to generate java code from XML
 schema. So far, so fine.

 It now and then happens that we'd like to override the default
 dependency for the Maven plugin for Castor in one module only (to e.g.
 integrate some new functionality of the code generator). Whenever we do
 this (i.e. add a dependency in the plugin configuration of one module
 only) and execute a 'mvn install' in the project directory, we can see
 that the new dependency is being picked up but for all modules that use
 the Maven plugin for Castor - which is not what we want.

 Questions: Is this expected behaviour ? Or are we missing something in
 e.g. the plugin configuration to have the isolation we'd like to see ?

 If I have failed to make myself understandable, let me know 

 Regards
 Werner

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

RE: DependencyManagement to force scope

2008-10-02 Thread Anders Hammar

I'm not sure about the optional tag, but it does apply to version.
DependencyManagement is where you can specify the version to use for
transitive dependencies.
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management

/Anders

softwarepills wrote:

To clarify more the matter.

Should we think about DependencyManagement no only as a default value
provider, but also as a modifier of inherited dependencies?
Does it apply to other parameters like the version itself and
optional?.

Jörg Schaible-3 wrote:

softwarepills wrote:
I usually think in DependencyManagement as a by default section, i
mean, the version and scope you set in DependencyManagement is the
version and scope you get if ommited in the real dependency in the POM
and child POMs.

But, i have found that if i insert provided scope in the
DependencyManagement section, any compile dependency and transitive
compile dependency will be upgraded to provided.

Is this correct?

Yes.

Is this the intended behavior?

Yes.

If yes, this is a inetresting tool to exclude artifacts form being
packaged, right?

Yes.

You'll need M2.0.6 or greater though ...

-Jörg

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

--
View this message in context:
http://www.nabble.com/DependencyManagement-to-force-scope-tp19776450p19777972.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]

Generating changelog since last release?

2008-10-02 Thread Kent Närling

Is there any simple way of generating a report of SCM changes since last
release?
The changelog only takes range, date or tag (which doesn't even work with
svn) as types...

I guess there is no way for maven guess what tag/date belongs to previous
releases or even what the previous release number was?
(which makes this quite hard)

On the other hand, this would be a very sensible functionality to support...
maybe it would be possible to store historic information in the project that
plugins could use? just a thought...

RE: DependencyManagement to force scope

I see. Thank you.

So we can modify version, version an scope, but not, only scope. This is a
problem when you only want using it to upgrade a dependency to provided.
Then you are also manipulatig the version that should be resolved by Maven.

So it seems its not a good idea using it to exclude a sticky transitive
dependency that someone has set as compile but in your context is provided,
right?

Anders Hammar wrote:

/Anders

softwarepills wrote:

To clarify more the matter.

Jörg Schaible-3 wrote:

But, i have found that if i insert provided scope in the
DependencyManagement section, any compile dependency and transitive
compile dependency will be upgraded to provided.

Is this correct?

Yes.

Is this the intended behavior?

Yes.

If yes, this is a inetresting tool to exclude artifacts form being
packaged, right?

Yes.

You'll need M2.0.6 or greater though ...

-Jörg

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

--
View this message in context:
http://www.nabble.com/DependencyManagement-to-force-scope-tp19776450p19778474.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]

Has anybody successfully used check and pmd goals together?

2008-10-02 Thread Andre Dantas Rocha

Hi all,

 

I've been trying for about three days using the 'pmd' and 'check' goals
together. I don't know why, but every time I enable 'check' goal the report
returns PMD found no problems in your source code.

 

If I run without 'check' goal I can find a lot of problems in the code. The
configuration is below.

 

Could anybody help me?

 

Thanks,

 

Andre

 

build

   finalName${systemName}/finalName

   plugins

  plugin

 groupIdorg.apache.maven.plugins/groupId

 artifactIdmaven-jxr-plugin/artifactId

 version2.1/version

 configuration

aggregatetrue/aggregate

 /configuration 

  /plugin

  plugin

 groupIdorg.apache.maven.plugins/groupId

 artifactIdmaven-pmd-plugin/artifactId

 version2.4/version

 executions   

execution

idpmd/id

   configuration

  localespt_BR/locales

  failOnRuleViolationfalse/failOnRuleViolation

  failOnErrorfalse/failOnError

  targetJdk${maven.compiler.source}/targetJdk

  minimumTokens100/minimumTokens

  rulesets

 ruleset${configDir}/cef-pmd.xml/ruleset

  /rulesets 

  aggregatetrue/aggregate

  verbosetrue/verbose   

  failOnViolationfalse/failOnViolation

  failurePriority5/failurePriority

   /configuration

   phasecompile/phase

   goals

  goalpmd/goal

  goalcpd/goal

  goalcheck/goal

  goalcpd-check/goal 

   /goals

/execution 

 /executions

  /plugin

   /plugins

/build

RE: DependencyManagement to force scope

2008-10-02 Thread Anders Hammar

Well, as I see things, if you specify the artifact as provided then you also
want to define the version that is provided. IMO you do want to use the same
version in your Maven build as you're going to use in the targeted
environment. In fact, this was one of my key points in a Maven talk I did at
our local jug earlier this week.
Why would you use a different version (and/or implementation) in your build
than you're going to use when deployd?

/Anders

softwarepills wrote:

I see. Thank you.

So we can modify version, version an scope, but not, only scope. This is a
problem when you only want using it to upgrade a dependency to
provided. Then you are also manipulatig the version that should be
resolved by Maven.

So it seems its not a good idea using it to exclude a sticky transitive
dependency that someone has set as compile but in your context is
provided, right?

Anders Hammar wrote:

/Anders

softwarepills wrote:

To clarify more the matter.

Jörg Schaible-3 wrote:

But, i have found that if i insert provided scope in the
DependencyManagement section, any compile dependency and transitive
compile dependency will be upgraded to provided.

Is this correct?

Yes.

Is this the intended behavior?

Yes.

If yes, this is a inetresting tool to exclude artifacts form being
packaged, right?

Yes.

You'll need M2.0.6 or greater though ...

-Jörg

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

--
View this message in context:
http://www.nabble.com/DependencyManagement-to-force-scope-tp19776450p19779895.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: How to know programatically the SNAPSHOT version

2008-10-02 Thread mateamargo


 What you can do, is to perform resource filtering on a text file you
package 
 into the jar, and then read this when querrying for the version. This is
 what 
 we do for a number of our software, and it works like a charm

That's what I want to do. But, how do you get the artifcat timestamp? or
just just use 1.0-SNAPSHOT?

 i.e. you need to know if this is 1.0-20081002.110956

Yes.

Actually I'm using an Ant Task to run a shell script that modify a
properties file with the current timestamp, but the problem is that is not
the same as the repository.

So, is the deploy plugin which generates this number?
-- 
View this message in context: 
http://www.nabble.com/How-to-know-programatically-the-SNAPSHOT-version-tp19652998p19779917.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: Generating changelog since last release?

2008-10-02 Thread ehsavoie


Hi,
Wel that what we tried to do with the scmchangelog-maven-plugin : 
It uses the scm tags to determine the versions and parses the scm comments
to produce the changelog.
We are currently upgrading from Mojo sandbox ;o) and are hoping to release
soon.
Check it on http://mojo.codehaus.org/scmchangelog-maven-plugin/ 
Emmanuel


Kent Narling wrote:
 
 Is there any simple way of generating a report of SCM changes since last
 release?
 The changelog only takes range, date or tag (which doesn't even work with
 svn) as types...
 
 I guess there is no way for maven guess what tag/date belongs to previous
 releases or even what the previous release number was?
 (which makes this quite hard)
 
 On the other hand, this would be a very sensible functionality to
 support...
 maybe it would be possible to store historic information in the project
 that
 plugins could use? just a thought...
 
 

-- 
View this message in context: 
http://www.nabble.com/Generating-changelog-since-last-release--tp19778457p19780350.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]

Determining jar groupId ArtifactId for deploy-file


Hello,

I am fairly new to Maven and Archiva and would like some help on two issues
both related to the same problem.

We have to use 2 jar files: nclmsg.public.jar and nclutil.public.jar
provided to us by A third party (we need for compile and packaging (war))

1. In order to use them, I want to do a mvn deploy:deploy-file to our
repository, which is Archiva 

2. How do we figure out the groupId, artifactId and version of those jars... 
I searched the different repositories on the net, but didn't find anything,
probably because they were provided to us.

mvn deploy:deploy-file -Dfile=nclmsg.public.jar -DgroupId=???
-DartifactId=??? -Dversion= -Dpackaging=jar -DgeneratePom=true
-DcreateChecksum=true -DrepositoryId=3pp_cache
-Durl=dav:http://maven..se:/repository/3pp_cache

Can anyone help clarify this for me???

Sonia
-- 
View this message in context: 
http://www.nabble.com/Determining-jar-groupId-ArtifactId-for-deploy-file-tp19781489p19781489.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: Determining jar groupId ArtifactId for deploy-file

If they already exist in a maven repo... you could use that (provided it is
not a short groupId... so if it was www.somecompany.org that you got the
files you could use the groupId of com.somecompany)

If you are unsure in any way... you could use your groupId to ensure that it
is these exact jars that are used... i.e. com.ericsson.ncl

If you are bored you could crack-open the jar files and see what the common
package root is and use that

-Stephen

2008/10/2 solo1970 [EMAIL PROTECTED]

Hello,

I am fairly new to Maven and Archiva and would like some help on two issues
both related to the same problem.

We have to use 2 jar files: nclmsg.public.jar and nclutil.public.jar
provided to us by A third party (we need for compile and packaging (war))

1. In order to use them, I want to do a mvn deploy:deploy-file to our
repository, which is Archiva

2. How do we figure out the groupId, artifactId and version of those
jars...
I searched the different repositories on the net, but didn't find anything,
probably because they were provided to us.

mvn deploy:deploy-file -Dfile=nclmsg.public.jar -DgroupId=???
-DartifactId=??? -Dversion= -Dpackaging=jar -DgeneratePom=true
-DcreateChecksum=true -DrepositoryId=3pp_cache
-Durl=dav:http://maven..se:/repository/3pp_cache

Can anyone help clarify this for me???

Sonia
--
View this message in context:
http://www.nabble.com/Determining-jar-groupId-ArtifactId-for-deploy-file-tp19781489p19781489.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]

getting POM default build locations

2008-10-02 Thread Jacob Danner

Hi,
Sorry if this is a dumb question, I queried nabble and checked all the
docs I could find for an answer in advance.

I'm trying to find out how I can get the default values for a maven
pom. The POM reference (http://maven.apache.org/pom.html#Directories)
notes that the default sourceDirectory for a POM is:

${basedir}/src/main/java

and if the build/sourceDirectory element is not defined in the POM a call to

org.apache.maven.model.Model.getBuild().getSourceDirectory()
returns null.
I would like to know if there is a way (other than hard coding a value
to src/main/java) for me to retrieve the sourceDirectory value.

My code looks similar to:

String src = ...
URL pom = ...
MavenXpp3Reader mxr = new MavenXpp3Reader();
Model m = null;
m = mxr.read(new InputStreamReader(pom.openStream()));

MavenProject mp = new MavenProject(m);

if(mp.getBuild().getSourceDirectory() == null)
  src = HOW _TO_GET_DEFAULT_SRC_DIRECTORY

Any help is appreciated,
-jacobd

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

Re: Multi-module build and plugin classpath issue

2008-10-02 Thread Werner Guttmann

Thanks, Stephen, for confirming what we have already been assuming,
based upon our builds. And no, I would have very much liked to see a
different answer.

Let me just ask a few follow-ups:

a) Is this by design, or ...
b) Is this a current limitation of the reactor ?
c) Could this be overcome (in theory, at least), and
d) What would it take to see this changed ?

Thanks for your time
Werner

Stephen Connolly wrote:
 As far as I understand,
 
 currently in Maven there is not isolation between plugins in different
 projects.
 
 If you have a multi-module build, the first use of a plugin in that
 multi-module build will determine both the version and the dependencies that
 are loaded into it's classloader for all subsequent plugin invokations
 during the reactor build.
 
 I'm not sure if this is what you wanted to hear, but it is what it is :-(
 
 -Stephen
 
 2008/10/2 Werner Guttmann [EMAIL PROTECTED]
 
 Hi,

 I am committer for the Castor (http://www.castor.org) project, and I am
 experiencing 'behaviour' I somehow find hard to understand.

 We at castor have a multi-module setup, where some of the modules have
 the maven plugin for Castor configured to generate java code from XML
 schema. So far, so fine.

 It now and then happens that we'd like to override the default
 dependency for the Maven plugin for Castor in one module only (to e.g.
 integrate some new functionality of the code generator). Whenever we do
 this (i.e. add a dependency in the plugin configuration of one module
 only) and execute a 'mvn install' in the project directory, we can see
 that the new dependency is being picked up but for all modules that use
 the Maven plugin for Castor - which is not what we want.

 Questions: Is this expected behaviour ? Or are we missing something in
 e.g. the plugin configuration to have the isolation we'd like to see ?

 If I have failed to make myself understandable, let me know 

 Regards
 Werner

 -
 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: Has anybody successfully used check and pmd goals together?

2008-10-02 Thread Brian E. Fox

I think one of those is meant to be used from the command line and forks
the build while the other is meant to be bound. Check the docs.

-Original Message-
From: Andre Dantas Rocha [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 02, 2008 9:38 AM
To: users@maven.apache.org
Subject: Has anybody successfully used check and pmd goals together?

Hi all,

 

I've been trying for about three days using the 'pmd' and 'check' goals
together. I don't know why, but every time I enable 'check' goal the
report
returns PMD found no problems in your source code.

 

If I run without 'check' goal I can find a lot of problems in the code.
The
configuration is below.

 

Could anybody help me?

 

Thanks,

 

Andre

 

build

   finalName${systemName}/finalName

   plugins

  plugin

 groupIdorg.apache.maven.plugins/groupId

 artifactIdmaven-jxr-plugin/artifactId

 version2.1/version

 configuration

aggregatetrue/aggregate

 /configuration 

  /plugin

  plugin

 groupIdorg.apache.maven.plugins/groupId

 artifactIdmaven-pmd-plugin/artifactId

 version2.4/version

 executions   

execution

idpmd/id

   configuration

  localespt_BR/locales

  failOnRuleViolationfalse/failOnRuleViolation

  failOnErrorfalse/failOnError

  targetJdk${maven.compiler.source}/targetJdk

  minimumTokens100/minimumTokens

  rulesets

 ruleset${configDir}/cef-pmd.xml/ruleset

  /rulesets 

  aggregatetrue/aggregate

  verbosetrue/verbose   

  failOnViolationfalse/failOnViolation

  failurePriority5/failurePriority

   /configuration

   phasecompile/phase

   goals

  goalpmd/goal

  goalcpd/goal

  goalcheck/goal

  goalcpd-check/goal 

   /goals

/execution 

 /executions

  /plugin

   /plugins

/build


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

Re: Multi-module build and plugin classpath issue

my understanding is b and it's being worked on

2008/10/2 Werner Guttmann [EMAIL PROTECTED]:
 Thanks, Stephen, for confirming what we have already been assuming,
 based upon our builds. And no, I would have very much liked to see a
 different answer.

 Let me just ask a few follow-ups:

 a) Is this by design, or ...
 b) Is this a current limitation of the reactor ?
 c) Could this be overcome (in theory, at least), and
 d) What would it take to see this changed ?

 Thanks for your time
 Werner

 Stephen Connolly wrote:
 As far as I understand,

 currently in Maven there is not isolation between plugins in different
 projects.

 If you have a multi-module build, the first use of a plugin in that
 multi-module build will determine both the version and the dependencies that
 are loaded into it's classloader for all subsequent plugin invokations
 during the reactor build.

 I'm not sure if this is what you wanted to hear, but it is what it is :-(

 -Stephen

 2008/10/2 Werner Guttmann [EMAIL PROTECTED]

 Hi,

 I am committer for the Castor (http://www.castor.org) project, and I am
 experiencing 'behaviour' I somehow find hard to understand.

 We at castor have a multi-module setup, where some of the modules have
 the maven plugin for Castor configured to generate java code from XML
 schema. So far, so fine.

 It now and then happens that we'd like to override the default
 dependency for the Maven plugin for Castor in one module only (to e.g.
 integrate some new functionality of the code generator). Whenever we do
 this (i.e. add a dependency in the plugin configuration of one module
 only) and execute a 'mvn install' in the project directory, we can see
 that the new dependency is being picked up but for all modules that use
 the Maven plugin for Castor - which is not what we want.

 Questions: Is this expected behaviour ? Or are we missing something in
 e.g. the plugin configuration to have the isolation we'd like to see ?

 If I have failed to make myself understandable, let me know 

 Regards
 Werner

 -
 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: Maven Dependency Plugin Question

2008-10-02 Thread David

Thanks Wendy.  That looks good.

On Wed, Oct 1, 2008 at 7:22 PM, Wendy Smoak [EMAIL PROTECTED] wrote:

 On Wed, Oct 1, 2008 at 5:19 PM, David [EMAIL PROTECTED] wrote:

  I need to create a war, lets call it B that is 99% similar to another
 war
  file A that I currently have.  I have thought about creating a new
 project
  for war file B and using the dependency plugin to unpack war file A
 in
  it's target directory.  Currently the only difference between the two is
  some images though that could change as development continues.  I thought
  about using a profile in war file A for this but management wants to
 give
  it a different name so I thought that wouldn't work.  I'm I thinking this
  through correctly or is there another way I can do what I need to do?

 You might want to look at the 'war overlay' feature of the war plugin.

 --
 Wendy

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

RE: DependencyManagement to force scope

Yes, it has sense.

Thank you.

Anders Hammar wrote:

Well, as I see things, if you specify the artifact as provided then you
also want to define the version that is provided. IMO you do want to use
the same version in your Maven build as you're going to use in the
targeted environment. In fact, this was one of my key points in a Maven
talk I did at our local jug earlier this week.
Why would you use a different version (and/or implementation) in your
build than you're going to use when deployd?

/Anders

softwarepills wrote:

I see. Thank you.

So we can modify version, version an scope, but not, only scope. This is
a problem when you only want using it to upgrade a dependency to
provided. Then you are also manipulatig the version that should be
resolved by Maven.

So it seems its not a good idea using it to exclude a sticky transitive
dependency that someone has set as compile but in your context is
provided, right?

Anders Hammar wrote:

/Anders

softwarepills wrote:

To clarify more the matter.

Jörg Schaible-3 wrote:

But, i have found that if i insert provided scope in the
DependencyManagement section, any compile dependency and transitive
compile dependency will be upgraded to provided.

Is this correct?

Yes.

Is this the intended behavior?

Yes.

If yes, this is a inetresting tool to exclude artifacts form being
packaged, right?

Yes.

You'll need M2.0.6 or greater though ...

-Jörg

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

--
View this message in context:
http://www.nabble.com/DependencyManagement-to-force-scope-tp19776450p19784033.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: Deterministic update of snapshots


Please, could someone confirm points 1 and 2?


softwarepills wrote:
 
 Thanks for your response.
 
 Yes, you are right. But we are now starting the development of a big
 system, so till we reach a stable stage where release is posible, we have
 many snaphosts.
 
 I was using deterministic applied to the update moment as now happens
 that someone is working on a module and suddenly it get compile errors as
 some snapshot has been updated. In that moment he may think that the error
 is due to his own changes in the code of the assigned module. The result
 is that many people comes to me to ask about strange behaviors of Maven.
 
 So, only to let it clear, my assumptions 1 and 2 are correct?
 
 If the answer is yes, do you think its correct to use policy=never in this
 scenario?
 
 
 Michael McCallum-3 wrote:
 
 deterministic and snapshot just don't go together... as the result of any 
 update is non-deterministic and being able to undo an update if rather 
 difficult.
 
 you can use range to achieve and agile deterministic release process
 where you 
 can roll forward or back anytime you like but get the latest by
 default...
 
 assuming you have reasonable tests and some communication you rarely
 break 
 people in this way
 
 On Thu, 02 Oct 2008 22:43:03 softwarepills wrote:
 If i am not wrong, with unique=false and policy=daily, snaphot updating
 follows this rules:

 1.- Update check (and posibly update itself) is made a day after last
 publishing in the remote repository of the single artifact being
 checked.
 So it could be at any time, any day, and different for every artifact,
 as
 they are involved in the current build (not all artifacts at the same
 time
 at 12:00 pm, for example).

 2.- As said in
 http://docs.codehaus.org/pages/viewpage.action?pageId=22585,
 every time a new remote snapshot is published, it will overwrite a local
 snapshot regardless of age. This is the only way to provide consistent
 behaviour and avoid clock skew - for example, while it might make sense
 to
 honour a local snapshot if it were newer than the remote snapshot, it
 may
 be that the local one was built from older sources and so is, in fact,
 older.

 For me, this could be very confusing in a team development process
 (especially 2).

 I think a deterministic way of snapshot updating is preferable using
 policiy=never. In this way you always preserve the same snaphots and,
 eventually, you can use -U to compile with fresh snaphost and get in
 sync
 with the team.

 Of course, you get a deterministic way of snaphot updating at expense of
 automatic updates, and posibilly, you can discover that one lazy
 developer
 has never used -U and is using very old snaphots.

 Please, any comments are welcome.
 
 
 
 -- 
 Michael McCallum
 Enterprise Engineer
 mailto:[EMAIL PROTECTED]
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Deterministic-update-of-snapshots-tp19776315p19784075.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: How to know programatically the SNAPSHOT version

2008-10-02 Thread mateamargo


Looking through the code I found where the timestamp is generated:

http://svn.apache.org/viewvc/maven/artifact/trunk/src/main/java/org/apache/maven/artifact/transform/SnapshotTransformation.java?view=markup

It has two different methods for install and deploy:

transformForDeployment( Artifact, ArtifactRepository, ArtifactRepository )

and

transformForInstall( Artifact, ArtifactRepository )


The first one generates the timestamp. It's hardoced for deployment only, no
way to specifiy it for install.
-- 
View this message in context: 
http://www.nabble.com/How-to-know-programatically-the-SNAPSHOT-version-tp19652998p19784753.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: Docbook and Maven: The source of Maven: The Definitive Guide

2008-10-02 Thread Rusty Wright

Thanks.  I'm oblivious to the obvious; I did a google search and didn't 
find anything.



Jörg Schaible wrote:

Rusty Wright wrote:
  

Where is the documentation for the xsite plugin



xsite.codehaus.org

  

he says that we
should use instead of apt? 



- Jörg

-
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]

Launching more than one program

2008-10-02 Thread Trevor Harmon


In Ant, I am used to launching programs like this:

target name=foo
java classname=foo.Foo
arg value=-abc/
/java
/target

target name=bar
java classname=bar.Bar
arg value=-xyz/
/java
/target

ant foo -- launches Foo with parameter -abc
ant bar -- launches Bar with parameter -xyz

This doesn't seem to be possible in Maven. The problem, apparently, is  
that the exec:java goal maps to one and only one program. In other  
words, all I can do is this:


mvn exec:java

I can set it up to launch Foo or Bar, but it can't handle both.

Is there a way around this?

Trevor


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

Jar not in repository


I have another question.

What is best way in Maven to specify a dependency on a file system??? 
Without using the repositories???  Is there a way to do it?  Some of the
jars we need reside on ClearCase and we can't deploy them to the
repository.

I'd appreciate your input!

Sonia
-- 
View this message in context: 
http://www.nabble.com/Jar-not-in-repository-tp19785221p19785221.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]

creating a new directory with maven

2008-10-02 Thread Jerry Wang

Hi, I know I can use the antrun plugin to create a directory, but is there an 
existing maven plugin that is tailored to creating directories?

Thanks,
Jerry

RE: Jar not in repository

2008-10-02 Thread Edelson, Justin

You can use the system scope. But you really shouldn't as that behavior
is non-portable. 

Justin

-Original Message-
From: solo1970 [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 02, 2008 2:41 PM
To: users@maven.apache.org
Subject: Jar not in repository

I have another question.

What is best way in Maven to specify a dependency on a file system??? 
Without using the repositories???  Is there a way to do it?  Some of the
jars we need reside on ClearCase and we can't deploy them to the
repository.

I'd appreciate your input!

Sonia
--
View this message in context:
http://www.nabble.com/Jar-not-in-repository-tp19785221p19785221.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]

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

Re: Determining jar groupId ArtifactId for deploy-file

Ok, so if understand this correctly I can give it any groupId ArtifctId that
I choose regardless of the file name. Once deployed with those
coordinates, then that's what I use to declare the dependencies.

Sonia

Stephen Connolly-2 wrote:

If they already exist in a maven repo... you could use that (provided it
is
not a short groupId... so if it was www.somecompany.org that you got the
files you could use the groupId of com.somecompany)

If you are unsure in any way... you could use your groupId to ensure that
it
is these exact jars that are used... i.e. com.ericsson.ncl

If you are bored you could crack-open the jar files and see what the
common
package root is and use that

-Stephen

2008/10/2 solo1970 [EMAIL PROTECTED]

Hello,

I am fairly new to Maven and Archiva and would like some help on two
issues
both related to the same problem.

We have to use 2 jar files: nclmsg.public.jar and nclutil.public.jar
provided to us by A third party (we need for compile and packaging (war))

1. In order to use them, I want to do a mvn deploy:deploy-file to our
repository, which is Archiva

2. How do we figure out the groupId, artifactId and version of those
jars...
I searched the different repositories on the net, but didn't find
anything,
probably because they were provided to us.

Can anyone help clarify this for me???

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

--
View this message in context:
http://www.nabble.com/Determining-jar-groupId-ArtifactId-for-deploy-file-tp19781489p19785329.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: Determining jar groupId ArtifactId for deploy-file


yes, but it's best to use a group Id that you control

Sent from my iPod

On 2 Oct 2008, at 19:48, solo1970 [EMAIL PROTECTED]  
wrote:




Ok, so if understand this correctly I can give it any groupId  
ArtifctId that

I choose regardless of the file  name.  Once deployed with those
coordinates, then that's what I use to declare the dependencies.

Sonia



Stephen Connolly-2 wrote:


If they already exist in a maven repo... you could use that  
(provided it

is
not a short groupId... so if it was www.somecompany.org that you  
got the

files you could use the groupId of com.somecompany)

If you are unsure in any way... you could use your groupId to  
ensure that

it
is these exact jars that are used... i.e. com.ericsson.ncl

If you are bored you could crack-open the jar files and see what the
common
package root is and use that

-Stephen

2008/10/2 solo1970 [EMAIL PROTECTED]



Hello,

I am fairly new to Maven and Archiva and would like some help on two
issues
both related to the same problem.

We have to use 2 jar files: nclmsg.public.jar and nclutil.public.jar
provided to us by A third party (we need for compile and packaging  
(war))


1. In order to use them, I want to do a mvn deploy:deploy-file to  
our

repository, which is Archiva

2. How do we figure out the groupId, artifactId and version of those
jars...
I searched the different repositories on the net, but didn't find
anything,
probably because they were provided to us.

mvn deploy:deploy-file -Dfile=nclmsg.public.jar -DgroupId=???
-DartifactId=??? -Dversion= -Dpackaging=jar -DgeneratePom=true
-DcreateChecksum=true -DrepositoryId=3pp_cache
-Durl=dav:http://maven..se:/repository/3pp_cache

Can anyone help clarify this for me???

Sonia
--
View this message in context:
http://www.nabble.com/Determining-jar-groupId-ArtifactId-for-deploy-file-tp19781489p19781489.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]







--
View this message in context: 
http://www.nabble.com/Determining-jar-groupId-ArtifactId-for-deploy-file-tp19781489p19785329.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]



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

RE: Jar not in repository


I cannot use the system scope if I want to files to end up in my final
package...



justinedelson wrote:
 
 You can use the system scope. But you really shouldn't as that behavior
 is non-portable. 
 
 Justin
 
 -Original Message-
 From: solo1970 [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, October 02, 2008 2:41 PM
 To: users@maven.apache.org
 Subject: Jar not in repository
 
 
 I have another question.
 
 What is best way in Maven to specify a dependency on a file system??? 
 Without using the repositories???  Is there a way to do it?  Some of the
 jars we need reside on ClearCase and we can't deploy them to the
 repository.
 
 I'd appreciate your input!
 
 Sonia
 --
 View this message in context:
 http://www.nabble.com/Jar-not-in-repository-tp19785221p19785221.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]
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Jar-not-in-repository-tp19785221p19785764.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]

Specifying a dependent goal for exec goals

2008-10-02 Thread Trevor Harmon


Consider these commands:

mvn clean
mvn exec:java

The second line fails because the classes aren't there. it needs to be:

mvn clean
mvn install
mvn exec:java

Is there some way of having Maven run the install goal automatically?  
That is, I want to specify that the install goal must always run  
before exec:java does. I tried using the phase parameter but had no  
success.


Trevor


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

Re: Determining jar groupId ArtifactId for deploy-file

What does that mean exactly???

Stephen Connolly-2 wrote:

yes, but it's best to use a group Id that you control

Sent from my iPod

On 2 Oct 2008, at 19:48, solo1970 [EMAIL PROTECTED]
wrote:

Ok, so if understand this correctly I can give it any groupId
ArtifctId that
I choose regardless of the file name. Once deployed with those
coordinates, then that's what I use to declare the dependencies.

Sonia

Stephen Connolly-2 wrote:

If they already exist in a maven repo... you could use that
(provided it
is
not a short groupId... so if it was www.somecompany.org that you
got the
files you could use the groupId of com.somecompany)

If you are unsure in any way... you could use your groupId to
ensure that
it
is these exact jars that are used... i.e. com.ericsson.ncl

If you are bored you could crack-open the jar files and see what the
common
package root is and use that

-Stephen

2008/10/2 solo1970 [EMAIL PROTECTED]

Hello,

I am fairly new to Maven and Archiva and would like some help on two
issues
both related to the same problem.

We have to use 2 jar files: nclmsg.public.jar and nclutil.public.jar
provided to us by A third party (we need for compile and packaging
(war))

1. In order to use them, I want to do a mvn deploy:deploy-file to
our
repository, which is Archiva

2. How do we figure out the groupId, artifactId and version of those
jars...
I searched the different repositories on the net, but didn't find
anything,
probably because they were provided to us.

Can anyone help clarify this for me???

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

--
View this message in context:
http://www.nabble.com/Determining-jar-groupId-ArtifactId-for-deploy-file-tp19781489p19785329.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]

--
View this message in context:
http://www.nabble.com/Determining-jar-groupId-ArtifactId-for-deploy-file-tp19781489p19786021.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]

Ant task always tries to download one of my indirect dependencies

2008-10-02 Thread Rick Mann

Every time I build my project using ant and the maven ant task, it  
tries to download a dependency:


[artifact:dependencies] Downloading: org/hibernate/hibernate-commons- 
annotations/3.1.0.GA/hibernate-commons-annotations-3.1.0.GA.pom from  
main.repository


This does not seem to exist. A newer version does exist, but the build  
process still seems to try to get this one. Since the task runs for  
all targets, even targets that don't need any dependencies, it slows  
down my workflow.


How can I track down which of my direct dependencies is responsible?  
I've tried the verbose and debug output from ant, but I don't know how  
to interpret it.


TIA,

--
Rick


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

command line debug args for jetty plugin?

2008-10-02 Thread Mick Knutson

I am trying to connect to my Jetty application, but want to know how to add
the following to the jetty plugin:

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005



-- 
---
Thank You…

Mick Knutson
BASE Logic, inc.
(415) 354-4215

Website: http://baselogic.com
Blog: http://baselogic.com/blog
BLiNC Magazine: http://blincmagazine.com
Linked IN: http://linkedin.com/in/mickknutson
DJ Mick: http://djmick.com
MySpace: http://myspace.com/mickknutson
Vacation Rental: http://tahoe.baselogic.com

Re: Launching more than one program

2008-10-02 Thread Wayne Fay

Profiles can solve your problem.

But why are you needing to do this in the first place? Describe things
in more detail and perhaps someone will have a better recommendation.

Wayne

On Thu, Oct 2, 2008 at 11:21 AM, Trevor Harmon [EMAIL PROTECTED] wrote:
 In Ant, I am used to launching programs like this:

 target name=foo
java classname=foo.Foo
arg value=-abc/
/java
 /target

 target name=bar
java classname=bar.Bar
arg value=-xyz/
/java
 /target

 ant foo -- launches Foo with parameter -abc
 ant bar -- launches Bar with parameter -xyz

 This doesn't seem to be possible in Maven. The problem, apparently, is that
 the exec:java goal maps to one and only one program. In other words, all I
 can do is this:

 mvn exec:java

 I can set it up to launch Foo or Bar, but it can't handle both.

 Is there a way around this?

 Trevor


 -
 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: command line debug args for jetty plugin?

2008-10-02 Thread Andrew Robinson

jetty runs inside of maven, so just pass those settings in your
MAVEN_OPTS environment variable and attach to maven. That has worked
for me.

-Andrew

On Thu, Oct 2, 2008 at 1:48 PM, Mick Knutson [EMAIL PROTECTED] wrote:
 I am trying to connect to my Jetty application, but want to know how to add
 the following to the jetty plugin:

 -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005



 --
 ---
 Thank You…

 Mick Knutson
 BASE Logic, inc.
 (415) 354-4215

 Website: http://baselogic.com
 Blog: http://baselogic.com/blog
 BLiNC Magazine: http://blincmagazine.com
 Linked IN: http://linkedin.com/in/mickknutson
 DJ Mick: http://djmick.com
 MySpace: http://myspace.com/mickknutson
 Vacation Rental: http://tahoe.baselogic.com


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

Re: Launching more than one program

2008-10-02 Thread Andrew Robinson

configure 2 executions of the maven-exec-plugin, one for each of you
classes. Instead of using plugin/configuration use
plugin/executions/execution/configuration to setup the settings.

-Andrew

On Thu, Oct 2, 2008 at 12:21 PM, Trevor Harmon [EMAIL PROTECTED] wrote:
 In Ant, I am used to launching programs like this:

 target name=foo
java classname=foo.Foo
arg value=-abc/
/java
 /target

 target name=bar
java classname=bar.Bar
arg value=-xyz/
/java
 /target

 ant foo -- launches Foo with parameter -abc
 ant bar -- launches Bar with parameter -xyz

 This doesn't seem to be possible in Maven. The problem, apparently, is that
 the exec:java goal maps to one and only one program. In other words, all I
 can do is this:

 mvn exec:java

 I can set it up to launch Foo or Bar, but it can't handle both.

 Is there a way around this?

 Trevor


 -
 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: command line debug args for jetty plugin?

2008-10-02 Thread Olivier Lamy

Perso I use : mvnDebug jetty:run (and you have a debugger on port 8080)

2008/10/2 Mick Knutson [EMAIL PROTECTED]:
 I am trying to connect to my Jetty application, but want to know how to add
 the following to the jetty plugin:

 -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005



 --
 ---
 Thank You…

 Mick Knutson
 BASE Logic, inc.
 (415) 354-4215

 Website: http://baselogic.com
 Blog: http://baselogic.com/blog
 BLiNC Magazine: http://blincmagazine.com
 Linked IN: http://linkedin.com/in/mickknutson
 DJ Mick: http://djmick.com
 MySpace: http://myspace.com/mickknutson
 Vacation Rental: http://tahoe.baselogic.com


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

Re: Launching more than one program

2008-10-02 Thread Trevor Harmon


On Oct 2, 2008, at 3:58 PM, Wayne Fay wrote:


But why are you needing to do this in the first place? Describe things
in more detail and perhaps someone will have a better recommendation.


I'm not trying to do anything special. I just want to run a Java  
program with different parameters. Sometimes I need to run two  
different Java programs for one project.


If you want a specific example, here's one:

http://volta.svn.sourceforge.net/viewvc/volta/cascade/build.xml?view=markup

In this Ant script, Java is invoked in different ways depending on  
which target is specified.


ant quick-test
-- runs the main application with some simple test parameters

ant profile
-- runs a custom profiler program to test the performance of the  
application


I simply want to do the same thing in Maven.


Profiles can solve your problem.


Thanks for the pointer; I think that will work.





Trevor


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

Re: Determining jar groupId ArtifactId for deploy-file

you are working for ericsson... so com.ericsson.what.ever.you.want

Or if you are working on a project hosted on dev.java.net you'd use
net.java.dev.projectname

It's just like package names in java... there are no hard and fast
rules... but if you ever want to interact with the public
repositories, you'd want to ensure that the group Id you are using is
not used by anyone else...

For example, if you publish to your internal repo using com.sun... and
then sun publish to repo1 an artifact with the same groupId and
artifactId but a newer version, it may interfere with your build as
that newer version will bee seen in version ranges

If they deploy something with the same version, and your developers
accidentally get that one on their machein first you'll have all sorts
of trouble.

So the recommendation is to use a group ID that you control (in this
case by you, we mean your employers)

-Stephen

2008/10/2 solo1970 [EMAIL PROTECTED]:

What does that mean exactly???

Stephen Connolly-2 wrote:

yes, but it's best to use a group Id that you control

Sent from my iPod

On 2 Oct 2008, at 19:48, solo1970 [EMAIL PROTECTED]
wrote:

Ok, so if understand this correctly I can give it any groupId
ArtifctId that
I choose regardless of the file name. Once deployed with those
coordinates, then that's what I use to declare the dependencies.

Sonia

Stephen Connolly-2 wrote:

If they already exist in a maven repo... you could use that
(provided it
is
not a short groupId... so if it was www.somecompany.org that you
got the
files you could use the groupId of com.somecompany)

If you are unsure in any way... you could use your groupId to
ensure that
it
is these exact jars that are used... i.e. com.ericsson.ncl

If you are bored you could crack-open the jar files and see what the
common
package root is and use that

-Stephen

2008/10/2 solo1970 [EMAIL PROTECTED]

Hello,

I am fairly new to Maven and Archiva and would like some help on two
issues
both related to the same problem.

We have to use 2 jar files: nclmsg.public.jar and nclutil.public.jar
provided to us by A third party (we need for compile and packaging
(war))

1. In order to use them, I want to do a mvn deploy:deploy-file to
our
repository, which is Archiva

2. How do we figure out the groupId, artifactId and version of those
jars...
I searched the different repositories on the net, but didn't find
anything,
probably because they were provided to us.

Can anyone help clarify this for me???

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

--
View this message in context:
http://www.nabble.com/Determining-jar-groupId-ArtifactId-for-deploy-file-tp19781489p19785329.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]

--
View this message in context:
http://www.nabble.com/Determining-jar-groupId-ArtifactId-for-deploy-file-tp19781489p19786021.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: Jar not in repository

2008-10-02 Thread Wendy Smoak

On Thu, Oct 2, 2008 at 12:14 PM, solo1970
[EMAIL PROTECTED] wrote:

 I cannot use the system scope if I want to files to end up in my final
 package...

I just tested building a webapp with a dependency on a jar from the
repo, and it was included in WEB-INF/lib.  When I copied the jar into
a lib/ directory and included it as a system scoped dependency, I can
see it's on the classpath for compilation, but it doesn't get packaged
in the war.

That sounds like a bug to me.   If you'd like to [search JIRA and]
report it, I'll comment and attach my example.

Further evidence that system scope is a bad idea. :)

-- 
Wendy

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

Jeffrey N Hagelberg is out of the office.

2008-10-02 Thread Jeffrey N Hagelberg


I will be out of the office starting  10/02/2008 and will not return until
10/14/2008.

I am on vacation for the holidays.  I will respond to your message when I
return.  If it is something urgent, call my cell phone at 530-902-7638.

Building different EAR files

2008-10-02 Thread Felix Schmitz

Hello,

Our maven multimode project consists so far of four projects:

-WAR
-JAR
-EJB
-EJB
-EAR

I would to be able to build different EAR files out of this project setup.
For instance one EAR file containing just one EJB module and one EAR
file containing the rest.

How would you go about this?

Using different build profiles?

Thx!
Felix

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

RE: Jar not in repository

2008-10-02 Thread Edelson, Justin

http://maven.apache.org/guides/introduction/introduction-to-dependency-m
echanism.html implies this would be the case in that system scope is
similar to provided. This should probably be made more explicit.

Justin 

-Original Message-
From: Wendy Smoak [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 02, 2008 4:35 PM
To: Maven Users List
Subject: Re: Jar not in repository

On Thu, Oct 2, 2008 at 12:14 PM, solo1970
[EMAIL PROTECTED] wrote:

 I cannot use the system scope if I want to files to end up in my final

 package...

I just tested building a webapp with a dependency on a jar from the
repo, and it was included in WEB-INF/lib.  When I copied the jar into a
lib/ directory and included it as a system scoped dependency, I can see
it's on the classpath for compilation, but it doesn't get packaged in
the war.

That sounds like a bug to me.   If you'd like to [search JIRA and]
report it, I'll comment and attach my example.

Further evidence that system scope is a bad idea. :)

--
Wendy

-
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: Building different EAR files

2008-10-02 Thread Edelson, Justin

I would have different EAR projects.

Justin 

-Original Message-
From: Felix Schmitz [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 02, 2008 5:31 PM
To: users@maven.apache.org
Subject: Building different EAR files

Hello,

Our maven multimode project consists so far of four projects:

-WAR
-JAR
-EJB
-EJB
-EAR

I would to be able to build different EAR files out of this project
setup.
For instance one EAR file containing just one EJB module and one EAR
file containing the rest.

How would you go about this?

Using different build profiles?

Thx!
Felix

-
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: Jar not in repository

2008-10-02 Thread Wendy Smoak

Yes, that makes sense.  Okay, not a bug. :)  Just not very useful in this case.

I don't think we ever heard from the OP why the jars can't go into a
repository?  That they need to be stored in ClearCase doesn't mean
they can't also be in a repository...

-- 
Wendy

On Thu, Oct 2, 2008 at 2:31 PM, Edelson, Justin
[EMAIL PROTECTED] wrote:
 http://maven.apache.org/guides/introduction/introduction-to-dependency-m
 echanism.html implies this would be the case in that system scope is
 similar to provided. This should probably be made more explicit.

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

RE: creating a new directory with maven

2008-10-02 Thread Martin Gainty


try adding executions to your plugin
   plugin
  groupIdorg.codehaus.fu/groupId
  artifactIdbar/artifactId
  version1.0/version
executions
  execution
idsome_id/id
phasesome_phase/phase
configuration
  tasks
mkdir 
dir=${basedir}/target/test-classes/${test.projects.repository}/${test.projects.target.directory}//mkdir
   /tasks
/configuration
  /execution
/executions

Martin 
__ 
Disclaimer and confidentiality note 
Everything in this e-mail and any attachments relates to the official business 
of Sender. This transmission is of a confidential nature and Sender does not 
endorse distribution to any party other than intended recipient. Sender does 
not necessarily endorse content contained within this transmission. 


 Date: Thu, 2 Oct 2008 11:44:52 -0700
 From: [EMAIL PROTECTED]
 Subject: creating a new directory with maven
 To: users@maven.apache.org
 
 Hi, I know I can use the antrun plugin to create a directory, but is there an 
 existing maven plugin that is tailored to creating directories?
 
 Thanks,
 Jerry
 
 
 
   

_
See how Windows Mobile brings your life together—at home, work, or on the go.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/

Calling maven.xml from maven.xml (top level dir to several sub dirs)

2008-10-02 Thread [EMAIL PROTECTED]

I am trying to run maven.xml from another maven.xml - is it possible? Here
is the directory structure that I've:

Folder1
Subfolder1a
Subfolder1b
Subfolder1c
Subfolder1d

Each folder contains it's own maven.xml, project.xml. So, what I want to do
is, build all of them together using a single maven file. For that, I want
to put a maven.xml in the top level directory (Folder1) and call individual
maven.xml in each subfolder (folder1a, folder1b and so on).

Is it possible and how?

Thanks,
xarora

Can't Maven handle dependendies recursively?

2008-10-02 Thread youhaodeyi


I set up a maven project P1 which depends on the project P2. P2 includes
several dependencies which are used in P1. In this case, I must add these
dependencies in P1 too. If not, I will fail to build P1. How can I let maven
deal with this recursive dependencies?
-- 
View this message in context: 
http://www.nabble.com/Can%27t-Maven-handle-dependendies-recursively--tp19791304p19791304.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: Can't Maven handle dependendies recursively?

2008-10-02 Thread Wendy Smoak

On Thu, Oct 2, 2008 at 7:56 PM, youhaodeyi [EMAIL PROTECTED] wrote:
 I set up a maven project P1 which depends on the project P2. P2 includes
 several dependencies which are used in P1. In this case, I must add these
 dependencies in P1 too. If not, I will fail to build P1. How can I let maven
 deal with this recursive dependencies?

How are the dependencies declared in P2?  If they are in the default
compile scope, they should be transitive (so P1 should compile.)

-- 
Wendy

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

Re: Deprecated plugin goals

That sounds like a nasty bug. Can you file this under MHELP in JIRA?

Thanks,
Brett

2008/10/1 Trevor Harmon [EMAIL PROTECTED]:
 The following command:

 mvn help:describe -Dplugin=plugin

 where plugin is the name of a plugin, shows that every goal of the plugin
 is deprecated. For example:

 # mvn help:describe -Dplugin=compiler
 ...
 compiler:compile
  Description: Compiles application sources
  Deprecated. No reason given
 ...

 Why is this? How can everything be deprecated?

 Trevor


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





-- 
Brett Porter
Blog: http://blogs.exist.com/bporter/

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

Re: getting POM default build locations

Is there a reason you are constructing the project by hand, rather
than using MavenProjectBuilder which will process inheritence (which
includes the defaults, coming from the super POM).

- Brett

2008/10/3 Jacob Danner [EMAIL PROTECTED]:
 Hi,
 Sorry if this is a dumb question, I queried nabble and checked all the
 docs I could find for an answer in advance.

 I'm trying to find out how I can get the default values for a maven
 pom. The POM reference (http://maven.apache.org/pom.html#Directories)
 notes that the default sourceDirectory for a POM is:

 ${basedir}/src/main/java

 and if the build/sourceDirectory element is not defined in the POM a call to

 org.apache.maven.model.Model.getBuild().getSourceDirectory()
 returns null.
 I would like to know if there is a way (other than hard coding a value
 to src/main/java) for me to retrieve the sourceDirectory value.

 My code looks similar to:

String src = ...
URL pom = ...
MavenXpp3Reader mxr = new MavenXpp3Reader();
Model m = null;
m = mxr.read(new InputStreamReader(pom.openStream()));

MavenProject mp = new MavenProject(m);

if(mp.getBuild().getSourceDirectory() == null)
  src = HOW _TO_GET_DEFAULT_SRC_DIRECTORY

 Any help is appreciated,
 -jacobd

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





-- 
Brett Porter
Blog: http://blogs.exist.com/bporter/

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

Re: Specifying a dependent goal for exec goals

The only way is to go the other way around, ie to bind exec:java to
the install phase. Then run mvn install

If you don't always want to run that command, you could put it in a
profile so it would be mvn -PexecPurpose install

- Brett

2008/10/3 Trevor Harmon [EMAIL PROTECTED]:
 Consider these commands:

 mvn clean
 mvn exec:java

 The second line fails because the classes aren't there. it needs to be:

 mvn clean
 mvn install
 mvn exec:java

 Is there some way of having Maven run the install goal automatically? That
 is, I want to specify that the install goal must always run before exec:java
 does. I tried using the phase parameter but had no success.

 Trevor


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





-- 
Brett Porter
Blog: http://blogs.exist.com/bporter/

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

Re: getting POM default build locations

2008-10-02 Thread Jacob Danner

Hey Brett,
Thanks for taking a peek. I'm not really constructing the project by
hand. I'm trying to access the model from an existing POM. Since the
POM is using the default project structure the sourceDirectory element
is never defined.

I did look into your suggestion and got a new error:
DefaultProjectBuilderConfiguration pbc = new
DefaultProjectBuilderConfiguration();
MavenProjectBuilder mpb = new DefaultMavenProjectBuilder();
MavenProject mp = mpb.build(new File(pom.toURI()), new
DefaultProjectBuilderConfiguration());

produces an NPE for me
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:499)
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:202)

Thanks,
-jacobd


On Thu, Oct 2, 2008 at 9:05 PM, Brett Porter [EMAIL PROTECTED] wrote:
 Is there a reason you are constructing the project by hand, rather
 than using MavenProjectBuilder which will process inheritence (which
 includes the defaults, coming from the super POM).

 - Brett

 2008/10/3 Jacob Danner [EMAIL PROTECTED]:
 Hi,
 Sorry if this is a dumb question, I queried nabble and checked all the
 docs I could find for an answer in advance.

 I'm trying to find out how I can get the default values for a maven
 pom. The POM reference (http://maven.apache.org/pom.html#Directories)
 notes that the default sourceDirectory for a POM is:

 ${basedir}/src/main/java

 and if the build/sourceDirectory element is not defined in the POM a call to

 org.apache.maven.model.Model.getBuild().getSourceDirectory()
 returns null.
 I would like to know if there is a way (other than hard coding a value
 to src/main/java) for me to retrieve the sourceDirectory value.

 My code looks similar to:

String src = ...
URL pom = ...
MavenXpp3Reader mxr = new MavenXpp3Reader();
Model m = null;
m = mxr.read(new InputStreamReader(pom.openStream()));

MavenProject mp = new MavenProject(m);

if(mp.getBuild().getSourceDirectory() == null)
  src = HOW _TO_GET_DEFAULT_SRC_DIRECTORY

 Any help is appreciated,
 -jacobd

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





 --
 Brett Porter
 Blog: http://blogs.exist.com/bporter/

 -
 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: getting POM default build locations

Is this in a plugin or in standalone code?

The APIs aren't really designed for use outside of the Maven
environment at this stage.

- Brett

2008/10/3 Jacob Danner [EMAIL PROTECTED]:
 Hey Brett,
 Thanks for taking a peek. I'm not really constructing the project by
 hand. I'm trying to access the model from an existing POM. Since the
 POM is using the default project structure the sourceDirectory element
 is never defined.

 I did look into your suggestion and got a new error:
 DefaultProjectBuilderConfiguration pbc = new
 DefaultProjectBuilderConfiguration();
 MavenProjectBuilder mpb = new DefaultMavenProjectBuilder();
 MavenProject mp = mpb.build(new File(pom.toURI()), new
 DefaultProjectBuilderConfiguration());

 produces an NPE for me
 org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:499)
 org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:202)

 Thanks,
 -jacobd


 On Thu, Oct 2, 2008 at 9:05 PM, Brett Porter [EMAIL PROTECTED] wrote:
 Is there a reason you are constructing the project by hand, rather
 than using MavenProjectBuilder which will process inheritence (which
 includes the defaults, coming from the super POM).

 - Brett

 2008/10/3 Jacob Danner [EMAIL PROTECTED]:
 Hi,
 Sorry if this is a dumb question, I queried nabble and checked all the
 docs I could find for an answer in advance.

 I'm trying to find out how I can get the default values for a maven
 pom. The POM reference (http://maven.apache.org/pom.html#Directories)
 notes that the default sourceDirectory for a POM is:

 ${basedir}/src/main/java

 and if the build/sourceDirectory element is not defined in the POM a call to

 org.apache.maven.model.Model.getBuild().getSourceDirectory()
 returns null.
 I would like to know if there is a way (other than hard coding a value
 to src/main/java) for me to retrieve the sourceDirectory value.

 My code looks similar to:

String src = ...
URL pom = ...
MavenXpp3Reader mxr = new MavenXpp3Reader();
Model m = null;
m = mxr.read(new InputStreamReader(pom.openStream()));

MavenProject mp = new MavenProject(m);

if(mp.getBuild().getSourceDirectory() == null)
  src = HOW _TO_GET_DEFAULT_SRC_DIRECTORY

 Any help is appreciated,
 -jacobd

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





 --
 Brett Porter
 Blog: http://blogs.exist.com/bporter/

 -
 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]





-- 
Brett Porter
Blog: http://blogs.exist.com/bporter/

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

Re: getting POM default build locations

2008-10-02 Thread Jacob Danner

Thanks again Brett.
Its some standalone code I'm working on.
Any suggestions on whether or not I can work around this?
Thanks,
-jacobd

On Thu, Oct 2, 2008 at 10:08 PM, Brett Porter [EMAIL PROTECTED] wrote:
 Is this in a plugin or in standalone code?

 The APIs aren't really designed for use outside of the Maven
 environment at this stage.

 - Brett

 2008/10/3 Jacob Danner [EMAIL PROTECTED]:
 Hey Brett,
 Thanks for taking a peek. I'm not really constructing the project by
 hand. I'm trying to access the model from an existing POM. Since the
 POM is using the default project structure the sourceDirectory element
 is never defined.

 I did look into your suggestion and got a new error:
 DefaultProjectBuilderConfiguration pbc = new
 DefaultProjectBuilderConfiguration();
 MavenProjectBuilder mpb = new DefaultMavenProjectBuilder();
 MavenProject mp = mpb.build(new File(pom.toURI()), new
 DefaultProjectBuilderConfiguration());

 produces an NPE for me
 org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:499)
 org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:202)

 Thanks,
 -jacobd


 On Thu, Oct 2, 2008 at 9:05 PM, Brett Porter [EMAIL PROTECTED] wrote:
 Is there a reason you are constructing the project by hand, rather
 than using MavenProjectBuilder which will process inheritence (which
 includes the defaults, coming from the super POM).

 - Brett

 2008/10/3 Jacob Danner [EMAIL PROTECTED]:
 Hi,
 Sorry if this is a dumb question, I queried nabble and checked all the
 docs I could find for an answer in advance.

 I'm trying to find out how I can get the default values for a maven
 pom. The POM reference (http://maven.apache.org/pom.html#Directories)
 notes that the default sourceDirectory for a POM is:

 ${basedir}/src/main/java

 and if the build/sourceDirectory element is not defined in the POM a call 
 to

 org.apache.maven.model.Model.getBuild().getSourceDirectory()
 returns null.
 I would like to know if there is a way (other than hard coding a value
 to src/main/java) for me to retrieve the sourceDirectory value.

 My code looks similar to:

String src = ...
URL pom = ...
MavenXpp3Reader mxr = new MavenXpp3Reader();
Model m = null;
m = mxr.read(new InputStreamReader(pom.openStream()));

MavenProject mp = new MavenProject(m);

if(mp.getBuild().getSourceDirectory() == null)
  src = HOW _TO_GET_DEFAULT_SRC_DIRECTORY

 Any help is appreciated,
 -jacobd

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





 --
 Brett Porter
 Blog: http://blogs.exist.com/bporter/

 -
 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]





 --
 Brett Porter
 Blog: http://blogs.exist.com/bporter/

 -
 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: getting POM default build locations