How to manipulate the classpath in which a maven plugin operates

2008-07-31 Thread Christian Schuhegger

Hello,

I just ran into a problem where I used the castor maven plugin as 
described here:

http://www.castor.org/srcgen-maven-plugin.html

I assumed that a plugin would use the same classpath as the project 
itself where I included castor 1.2. But I seems as if a maven plugin 
operates in its own classpath. I used the version 1.0 of the above 
plugin which uses castor 0.97 and therefore the source generator did not 
produce a hashcode method that new versions will produce.


Is it somehow possible to manipulate the classpath of a maven plugin, 
e.g. via exclusions and additional dependencies, so that a newer version 
of castor could be injected?


I will have the same problem with the idlj-maven-plugin:
http://mojo.codehaus.org/idlj-maven-plugin/index.html
which still uses a very old version of jacorb. This plugin seems to be 
abandonned:

http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=11698fixfor=-1

I expect that most of these plugins will still work with newer versions 
of the jars they depend on, because the source code generator will 
normally not change its external interface.


Thanks for any clarifications,
--
Christian Schuhegger
http://www.el-chef.de/

-
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-07-31 Thread nicolas de loof
Add dependencies element to your plugin configuration to extend/override
the plugin classpath. Please note this works fine only on maven 2.0.9

2008/7/31 Christian Schuhegger [EMAIL PROTECTED]

 Hello,

 I just ran into a problem where I used the castor maven plugin as described
 here:
 http://www.castor.org/srcgen-maven-plugin.html

 I assumed that a plugin would use the same classpath as the project itself
 where I included castor 1.2. But I seems as if a maven plugin operates in
 its own classpath. I used the version 1.0 of the above plugin which uses
 castor 0.97 and therefore the source generator did not produce a hashcode
 method that new versions will produce.

 Is it somehow possible to manipulate the classpath of a maven plugin, e.g.
 via exclusions and additional dependencies, so that a newer version of
 castor could be injected?

 I will have the same problem with the idlj-maven-plugin:
 http://mojo.codehaus.org/idlj-maven-plugin/index.html
 which still uses a very old version of jacorb. This plugin seems to be
 abandonned:

 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=11698fixfor=-1

 I expect that most of these plugins will still work with newer versions of
 the jars they depend on, because the source code generator will normally not
 change its external interface.

 Thanks for any clarifications,
 --
 Christian Schuhegger
 http://www.el-chef.de/

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




Re: PMD/CPD Maven 2 Plugin Question

2008-07-31 Thread Carlos Alonso

Hi Elliot.

At this point I'm not able to explain you exactly what the 
pluginManagement do, but I think that section is like a summary of what 
plugins you're using and that is more suitable in a parent pom. Then, in 
children poms or in a section below the one you're showing should be 
declared the plugin directly into the build section, but not below a 
pluginManagement one. Do you understand?


So the easiest solution is to remove the pluginManagement tags. Also, 
I've to point that the configuration tags are more suitable within the 
execution tag itself. Showing that the specified configuration is 
associated to the specified execution.


Finally, your code snippet should become like this:

build
.
.
.
 plugins 
   plugin

 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-pmd-plugin/artifactId
 executions
   execution
 phasepackage/phase
 goals
   goalcpd/goal
 /goals

configuration
linkXreffalse/linkXref
targetJdk1.5/targetJdk
aggregatetrue/aggregate
ignoreLiteralstrue/ignoreLiterals
ignoreIdentifierstrue/ignoreIdentifiers
/configuration
   /execution
 /executions
/plugin
.
.
.
/plugins
/build




Hope it helps.
Carlos


[EMAIL PROTECTED] escribió:
I am trying to integrate the pmd/cpd maven 2 plugin into our project. 


Pmd/cpd information is located here: http://pmd.sourceforge.net/cpd.html
Pmd/cpd maven 2 plugin information is located here: 
http://maven.apache.org/plugins/maven-pmd-plugin/index.html . This plugin 
will allow us to generate the pmd/cpd report.


I want to be able to run the cpd tool everytime we run mvn clean package.

In the main pom.xml, I have:

build
pluginManagement
  plugins 
plugin

  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-pmd-plugin/artifactId
  configuration
linkXreffalse/linkXref
targetJdk1.5/targetJdk
aggregatetrue/aggregate
ignoreLiteralstrue/ignoreLiterals
ignoreIdentifierstrue/ignoreIdentifiers
/configuration
  executions
execution
  phasepackage/phase
  goals
goalcpd/goal
  /goals
/execution
  /executions
 /plugin



However, when I went ahead and run mvn package, it does not generate the 
report. 
I can generate the report if I run: mvn package pmd:cpd with the 
configuration values, but I would like to integrate it so that everytime I 
run mvn package, it will generate the report.


Any help/pointers will be appreciated.

Thanks,

Elliot Ng

-
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase  Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase 
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.
  



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



Re: excluding some .properties files

2008-07-31 Thread Jeff Mutonho
I've also tried this :

webResources
  resource
   directorysrc/directory
   excludes
 exclude**/*.java/exclude
 excludelog4j.properties/exclude
 excludemanager.properties/exclude
   /excludes
   includes
includemessages_en.properties/include
  /includes
   /resource
  /webResources


but still without any success.


-- 

Don't take the name of root in vain.

Jeff Mutonho
Cape Town
South Africa

GoogleTalk : ejbengine
Skype : ejbengine
Registered Linux user number 366042


Re: PMD/CPD Maven 2 Plugin Question

2008-07-31 Thread Stephen Connolly
The pluginManagement is a section where you define the default configuration
for any child projects if they decide to use the plugin, or if you invoke
the plugin directly (i.e. outside of the lifecycle)

The plugins section in the build defines the plugin configuration for that
project and can override the settings in pluginManagement

On Thu, Jul 31, 2008 at 7:38 AM, Carlos Alonso [EMAIL PROTECTED] wrote:

 Hi Elliot.

 At this point I'm not able to explain you exactly what the pluginManagement
 do, but I think that section is like a summary of what plugins you're using
 and that is more suitable in a parent pom. Then, in children poms or in a
 section below the one you're showing should be declared the plugin directly
 into the build section, but not below a pluginManagement one. Do you
 understand?

 So the easiest solution is to remove the pluginManagement tags. Also, I've
 to point that the configuration tags are more suitable within the execution
 tag itself. Showing that the specified configuration is associated to the
 specified execution.

 Finally, your code snippet should become like this:

 build
.
.
.
 plugins   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-pmd-plugin/artifactId
 executions
   execution
 phasepackage/phase
 goals
   goalcpd/goal
 /goals

configuration
linkXreffalse/linkXref
targetJdk1.5/targetJdk
aggregatetrue/aggregate
ignoreLiteralstrue/ignoreLiterals
ignoreIdentifierstrue/ignoreIdentifiers
/configuration
   /execution
 /executions
/plugin
.
.
.
/plugins
 /build




 Hope it helps.
 Carlos


 [EMAIL PROTECTED] escribió:

  I am trying to integrate the pmd/cpd maven 2 plugin into our project.
 Pmd/cpd information is located here: http://pmd.sourceforge.net/cpd.html
 Pmd/cpd maven 2 plugin information is located here:
 http://maven.apache.org/plugins/maven-pmd-plugin/index.html . This plugin
 will allow us to generate the pmd/cpd report.

 I want to be able to run the cpd tool everytime we run mvn clean package.

 In the main pom.xml, I have:

 build
pluginManagement
  pluginsplugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-pmd-plugin/artifactId
  configuration
linkXreffalse/linkXref
targetJdk1.5/targetJdk
aggregatetrue/aggregate
ignoreLiteralstrue/ignoreLiterals
ignoreIdentifierstrue/ignoreIdentifiers
/configuration
  executions
execution
  phasepackage/phase
  goals
goalcpd/goal
  /goals
/execution
  /executions
 /plugin



 However, when I went ahead and run mvn package, it does not generate the
 report. I can generate the report if I run: mvn package pmd:cpd with the
 configuration values, but I would like to integrate it so that everytime I
 run mvn package, it will generate the report.

 Any help/pointers will be appreciated.

 Thanks,

 Elliot Ng

 -
 This communication is for informational purposes only. It is not
 intended as an offer or solicitation for the purchase or sale of
 any financial instrument or as an official confirmation of any
 transaction. All market prices, data and other information are not
 warranted as to completeness or accuracy and are subject to change
 without notice. Any comments or statements made herein do not
 necessarily reflect those of JPMorgan Chase  Co., its subsidiaries
 and affiliates.

 This transmission may contain information that is privileged,
 confidential, legally privileged, and/or exempt from disclosure
 under applicable law. If you are not the intended recipient, you
 are hereby notified that any disclosure, copying, distribution, or
 use of the information contained herein (including any reliance
 thereon) is STRICTLY PROHIBITED. Although this transmission and any
 attachments are believed to be free of any virus or other defect
 that might affect any computer system into which it is received and
 opened, it is the responsibility of the recipient to ensure that it
 is virus free and no responsibility is accepted by JPMorgan Chase 
 Co., its subsidiaries and affiliates, as applicable, for any loss
 or damage arising in any way from its use. If you received this
 transmission in error, please immediately contact the sender and
 destroy the material in its entirety, whether in electronic or hard
 copy format. Thank you.

 Please refer to 

JMS plugin

2008-07-31 Thread Lustig, Marc (Allianz Deutschland, externer Mitarbeiter)
Somebody knows of a Maven2-plugin to send JMS-messages?
 


Re: excluding some .properties files

2008-07-31 Thread Stephen Connolly
Have you tried using maven's default project layout?

On Thu, Jul 31, 2008 at 7:47 AM, Jeff Mutonho [EMAIL PROTECTED] wrote:

 I've also tried this :

 webResources
   resource
   directorysrc/directory
   excludes
 exclude**/*.java/exclude
 excludelog4j.properties/exclude
 excludemanager.properties/exclude
   /excludes
   includes
includemessages_en.properties/include
  /includes
   /resource
   /webResources


 but still without any success.


 --

 Don't take the name of root in vain.

 Jeff Mutonho
 Cape Town
 South Africa

 GoogleTalk : ejbengine
 Skype : ejbengine
 Registered Linux user number 366042



Re: Snapshot parent

2008-07-31 Thread sverhagen


Michael McCallum-3 wrote:
 
 On Thu, 31 Jul 2008 09:44:41 sverhagen wrote:
 In Continuous Integration spirit, we have snapshot dependencies between
 all
 our own components.
 We have also set components to use snapshots of their parents (parent
 ...
 version...-SNAPSHOT).
 Is the latter good practice?
 It will mean that I can't release a component without releasing its
 parents, won't it?
 
 you can achieve the same result using version ranges...
 

We have ranges on dependencies.
So all developers are always using the latest version of any of our own
components.
Latest version is typically a snapshot, since all components are always in
snapshot state in the SCM repository and the build server deploys them as
such to our internal Maven repository.

It appears that ranges on parent relationships are not allowed.


Michael McCallum-3 wrote:
 
 i would not recommend snapshot parents...
 
 consider that continuous integration is there to verify that your
 artifacts 
 are consistent and have valid inter artifact assumptions... if you use 
 snapshots how do you really know whats broken and what fixes it you would
 be 
 better off having a staging repository and a final release repository
 
 using the release plugin to manage the lifecycle rather than snapshots
 gives 
 you far greater control
 

This sounds like you're promoting not to use snapshots at all. That appears
not to be the Maven and C.I. spirit, is it?

I'm probably mis-understanding you ...
-- 
View this message in context: 
http://www.nabble.com/Snapshot-parent-tp18743503p18749742.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: excluding some .properties files

2008-07-31 Thread Jeff Mutonho
On Thu, Jul 31, 2008 at 10:04 AM, Stephen Connolly 
[EMAIL PROTECTED] wrote:

 Have you tried using maven's default project layout?


Nope , but I've finally got it working.It seems just listing the files (as
shown below)I wish to excludes in successive exclude tags DOESN'T  work :

webResources
  resource
   directorysrc/directory
   excludes
 exclude**/*.java/exclude
 excludelog4j.properties/exclude
 excludemanager.properties/exclude
   /excludes
   includes
includemessages_en.properties/include
  /includes
   /resource
  /webResources


BUT , a single exclude with all the file names separated by commas and
using the pattern matching string works.This is what I have and it works as
I wish it to.After re-reading the docs , it makes sense , but perhaps the
docs can be improved to explain this.

warSourceExcludes**/*.java,**/log4j.properties,**/manager.properties/warSourceExcludes




Don't take the name of root in vain.

Jeff Mutonho
Cape Town
South Africa

GoogleTalk : ejbengine
Skype : ejbengine
Registered Linux user number 366042


Re: Maven WAR with self-classes as package

2008-07-31 Thread zm

WOW! AWESOME! :)

I'll try this in a minute!


Thanks


Wendy Smoak-3 wrote:
 
 On Wed, Jul 30, 2008 at 10:27 AM, zm [EMAIL PROTECTED] wrote:
 
 I have a WAR project that builds correctly in Maven2.

 What I want to know, is if there is a way of making maven to do an
 internal
 JAR package of the WAR classes.
 
 http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html
 
 archiveClasses - boolean - Whether a JAR file will be created for the
 classes in the webapp. Using this optional configuration parameter
 will make the generated classes to be archived into a jar file and the
 classes directory will then be excluded from the webapp. Default value
 is false.
 
 (There is a configuration example on the Usage page, just replace the
 parameter name inside the configuration element, or ask if you need a
 complete example.)
 
 -- 
 Wendy
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Maven-WAR-with-self-classes-as-package-tp18738442p18750119.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]



nexus unable to download artifacts

2008-07-31 Thread freak182

Hello,
I install sonatype nexus as repo manager.I configure maven settings xml as
describe in the tutorial. But when i simply run mvn clean with empty local
repository nexus doesn't download necessesary artifacts. Did i missed
something on my configuration?

Thanks a lot.
Cheers.
-- 
View this message in context: 
http://www.nabble.com/nexus-unable-to-download-artifacts-tp18750225p18750225.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: Maven WAR with self-classes as package

2008-07-31 Thread zm

It didn't work as expected ... :(

I have the following in my pon.xml:

build
outputDirectoryWebContent/WEB-INF/classes/outputDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.0.1/version
executions
goalexplode/goal
/executions
configuration 
archiveClassestrue/archiveClasses
dependentWarIncludes
**/resources/*.*
/dependentWarIncludes 
 
webResources
resource
!-- this is relative 
to the pom.xml directory --

directory${basedir}/WebContent/directory
/resource
/webResources
/configuration
/plugin   
/plugins
/build

The problem is that it creates a jar file inside lib dir, as expected and
just like I need it. But still it doesn't delete the classes from the
WEB-INF\classes folder.

I've found  http://jira.codehaus.org/browse/MWAR-82 this reported issue ,
with no solution ... probably was tested, but still I don't get the desired
results.

Any idea?

Thanks




Wendy Smoak-3 wrote:
 
 On Wed, Jul 30, 2008 at 10:27 AM, zm [EMAIL PROTECTED] wrote:
 
 I have a WAR project that builds correctly in Maven2.

 What I want to know, is if there is a way of making maven to do an
 internal
 JAR package of the WAR classes.
 
 http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html
 
 archiveClasses - boolean - Whether a JAR file will be created for the
 classes in the webapp. Using this optional configuration parameter
 will make the generated classes to be archived into a jar file and the
 classes directory will then be excluded from the webapp. Default value
 is false.
 
 (There is a configuration example on the Usage page, just replace the
 parameter name inside the configuration element, or ask if you need a
 complete example.)
 
 -- 
 Wendy
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Maven-WAR-with-self-classes-as-package-tp18738442p18750322.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: Maven WAR with self-classes as package

2008-07-31 Thread Manuel EVENO
Did you make a clean command before ?

On Thu, Jul 31, 2008 at 10:53 AM, zm [EMAIL PROTECTED] wrote:


 It didn't work as expected ... :(

 I have the following in my pon.xml:

build

  outputDirectoryWebContent/WEB-INF/classes/outputDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.0.1/version
executions
goalexplode/goal
/executions
configuration

  archiveClassestrue/archiveClasses
dependentWarIncludes
**/resources/*.*
/dependentWarIncludes
webResources
resource
!-- this is
 relative to the pom.xml directory --

  directory${basedir}/WebContent/directory
/resource
/webResources
/configuration
/plugin
/plugins
/build

 The problem is that it creates a jar file inside lib dir, as expected and
 just like I need it. But still it doesn't delete the classes from the
 WEB-INF\classes folder.

 I've found  http://jira.codehaus.org/browse/MWAR-82 this reported issue ,
 with no solution ... probably was tested, but still I don't get the desired
 results.

 Any idea?

 Thanks




 Wendy Smoak-3 wrote:
 
  On Wed, Jul 30, 2008 at 10:27 AM, zm [EMAIL PROTECTED] wrote:
 
  I have a WAR project that builds correctly in Maven2.
 
  What I want to know, is if there is a way of making maven to do an
  internal
  JAR package of the WAR classes.
 
  http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html
 
  archiveClasses - boolean - Whether a JAR file will be created for the
  classes in the webapp. Using this optional configuration parameter
  will make the generated classes to be archived into a jar file and the
  classes directory will then be excluded from the webapp. Default value
  is false.
 
  (There is a configuration example on the Usage page, just replace the
  parameter name inside the configuration element, or ask if you need a
  complete example.)
 
  --
  Wendy
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Maven-WAR-with-self-classes-as-package-tp18738442p18750322.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: Maven WAR with self-classes as package

2008-07-31 Thread zm

My procedure was:

mvn clean

I've checked that the target folder has completely disappeared, and then

mvn clean package

The problem persists.


Thanks



Manuel EVENO wrote:
 
 Did you make a clean command before ?
 
 On Thu, Jul 31, 2008 at 10:53 AM, zm [EMAIL PROTECTED] wrote:
 

 It didn't work as expected ... :(

 I have the following in my pon.xml:

build

  outputDirectoryWebContent/WEB-INF/classes/outputDirectory
plugins
plugin
   
 groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.0.1/version
executions
goalexplode/goal
/executions
configuration

  archiveClassestrue/archiveClasses
dependentWarIncludes
**/resources/*.*
/dependentWarIncludes
webResources
resource
!-- this is
 relative to the pom.xml directory --

  directory${basedir}/WebContent/directory
/resource
/webResources
/configuration
/plugin
/plugins
/build

 The problem is that it creates a jar file inside lib dir, as expected and
 just like I need it. But still it doesn't delete the classes from the
 WEB-INF\classes folder.

 I've found  http://jira.codehaus.org/browse/MWAR-82 this reported issue ,
 with no solution ... probably was tested, but still I don't get the
 desired
 results.

 Any idea?

 Thanks




 Wendy Smoak-3 wrote:
 
  On Wed, Jul 30, 2008 at 10:27 AM, zm [EMAIL PROTECTED] wrote:
 
  I have a WAR project that builds correctly in Maven2.
 
  What I want to know, is if there is a way of making maven to do an
  internal
  JAR package of the WAR classes.
 
  http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html
 
  archiveClasses - boolean - Whether a JAR file will be created for the
  classes in the webapp. Using this optional configuration parameter
  will make the generated classes to be archived into a jar file and the
  classes directory will then be excluded from the webapp. Default value
  is false.
 
  (There is a configuration example on the Usage page, just replace the
  parameter name inside the configuration element, or ask if you need a
  complete example.)
 
  --
  Wendy
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Maven-WAR-with-self-classes-as-package-tp18738442p18750322.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/Maven-WAR-with-self-classes-as-package-tp18738442p18750658.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]



how to make archetype resource copy as package structure

2008-07-31 Thread qrtt1

Hello, I create an archetype for my project.
there are my archetype.xml

archetype
idarchetype/id
sources
sourcesrc/main/java/DummyNode.java/source
/sources
testSources
sourcesrc/test/java/DummyNodeTest.java/source
/testSources
resources
resourcesrc/main/resources/app-config.xml/resource
/resources
/archetype

My *.java can move to package directory but app-config.xml doesn't
How do I do can make it move to apporiate locations?

-- 
View this message in context: 
http://www.nabble.com/how-to-make-archetype-resource-copy-as-package-structure-tp18751132p18751132.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: Maven WAR with self-classes as package

2008-07-31 Thread Mark Struberg
Hi!

The problem may be the 
outputDirectoryWebContent/WEB-INF/classes/outputDirectory
in your pom.

Is your webapp stuff also in this WebContent folder? So you use it to generate 
the classes into your 'source' folder? 

Usually the classes go to target/classes and will be jared there. For what I 
remember, they will afterwards NOT be removed from this place! So if you use 
your source folder for holding this classes, they will most likely simply be 
copied into your war.
Try to remove the outputDirectory setting and use war:inplace to generate a 
debuggable environment.

You can call the single steps from the default lifecyclye manually and watch 
this directory closely.

LieGrü,
strub

--- zm [EMAIL PROTECTED] schrieb am Do, 31.7.2008:

 Von: zm [EMAIL PROTECTED]
 Betreff: Re: Maven WAR with self-classes as package
 An: users@maven.apache.org
 Datum: Donnerstag, 31. Juli 2008, 11:18
 My procedure was:
 
 mvn clean
 
 I've checked that the target folder has completely
 disappeared, and then
 
 mvn clean package
 
 The problem persists.
 
 
 Thanks
 
 
 
 Manuel EVENO wrote:
  
  Did you make a clean command before ?
  
  On Thu, Jul 31, 2008 at 10:53 AM, zm
 [EMAIL PROTECTED] wrote:
  
 
  It didn't work as expected ... :(
 
  I have the following in my pon.xml:
 
 build
 
  
 outputDirectoryWebContent/WEB-INF/classes/outputDirectory
 plugins
 plugin

 
 groupIdorg.apache.maven.plugins/groupId

 artifactIdmaven-war-plugin/artifactId

 version2.0.1/version
 executions

 goalexplode/goal
 /executions

 configuration
 
   archiveClassestrue/archiveClasses

 dependentWarIncludes

 **/resources/*.*

 /dependentWarIncludes

 webResources

 resource

 !-- this is
  relative to the pom.xml directory --
 
  
 directory${basedir}/WebContent/directory

 /resource

 /webResources

 /configuration
 /plugin
 /plugins
 /build
 
  The problem is that it creates a jar file inside
 lib dir, as expected and
  just like I need it. But still it doesn't
 delete the classes from the
  WEB-INF\classes folder.
 
  I've found 
 http://jira.codehaus.org/browse/MWAR-82 this reported issue
 ,
  with no solution ... probably was tested, but
 still I don't get the
  desired
  results.
 
  Any idea?
 
  Thanks
 
 
 
 
  Wendy Smoak-3 wrote:
  
   On Wed, Jul 30, 2008 at 10:27 AM, zm
 [EMAIL PROTECTED] wrote:
  
   I have a WAR project that builds
 correctly in Maven2.
  
   What I want to know, is if there is a way
 of making maven to do an
   internal
   JAR package of the WAR classes.
  
  
 http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html
  
   archiveClasses - boolean - Whether a JAR file
 will be created for the
   classes in the webapp. Using this optional
 configuration parameter
   will make the generated classes to be
 archived into a jar file and the
   classes directory will then be excluded from
 the webapp. Default value
   is false.
  
   (There is a configuration example on the
 Usage page, just replace the
   parameter name inside the configuration
 element, or ask if you need a
   complete example.)
  
   --
   Wendy
  
  
 -
   To unsubscribe, e-mail:
 [EMAIL PROTECTED]
   For additional commands, e-mail:
 [EMAIL PROTECTED]
  
  
  
 
  --
  View this message in context:
 
 http://www.nabble.com/Maven-WAR-with-self-classes-as-package-tp18738442p18750322.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/Maven-WAR-with-self-classes-as-package-tp18738442p18750658.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]


  __
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com

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

Re: how to make archetype resource copy as package structure

2008-07-31 Thread Simone Gianni
Hi,
I was struggling with the same problem just a few minutes ago, and seems
like there is a solution.

Instead of using the archetype.xml file to manage your resources, you
can create a file name archetype-metadata.xml, where you have more
fine-graned managing of the archetype structure, for example, for your
problem :

?xml version=1.0 encoding=UTF-8?
*archetype*-descriptor name=basic

  fileSets
fileSet filtered=true *packaged*=true
  directorysrc/main/java/directory
  includes
include**/*.java/include
  /includes
/fileSet
fileSet filtered=true *packaged*=true
  directorysrc/test/java/directory
  includes
include**/*.java/include
  /includes
/fileSet
fileSet filtered=true *packaged*=true
  directorysrc/main/*resources*/directory
  includes
include**/app-config.xml/include
  /includes
/fileSet
  /fileSets
/*archetype*-descriptor

As you can see, the packaged=true attribute makes Maven put that files
inside the package. I'm trying to make it work right now, not yet
successfully :(. Anyway, it is documented here :
http://maven.apache.org/plugins/maven-archetype-plugin/specification/archetype-metadata.html


Simone

qrtt1 wrote:
 Hello, I create an archetype for my project.
 there are my archetype.xml

 archetype
   idarchetype/id
   sources
   sourcesrc/main/java/DummyNode.java/source
   /sources
   testSources
   sourcesrc/test/java/DummyNodeTest.java/source
   /testSources
   resources
   resourcesrc/main/resources/app-config.xml/resource
   /resources
 /archetype

 My *.java can move to package directory but app-config.xml doesn't
 How do I do can make it move to apporiate locations?

   


-- 
Simone Gianni
http://www.simonegianni.it/
CEO Semeru s.r.l.
Apache Committer


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



RE: M 2.0.5 - Failure executing javac

2008-07-31 Thread Martin Gainty

Please restate the inquiry

Martin 
USCitizen(Contractor)
__ 
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. 


 Subject: Re: M 2.0.5 - Failure executing javac
 Date: Wed, 30 Jul 2008 22:51:27 -0500
 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 CC: users@maven.apache.org
 
 Cool, thank you. 
 
 
 This message (including any attachments) contains confidential information 
 intended for a specific individual and purpose, and is protected by law.  If 
 you are not the intended recipient, you should delete this message. 
 
 
 Any disclosure, copying, or distribution of this message, or the taking of 
 any action based on it, is strictly prohibited. [v.E.1]

_
Stay in touch when you're away with Windows Live Messenger.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_messenger2_072008

Archiva and Nexus index

2008-07-31 Thread Alexander Vaysberg

Hi,
can an archiva produce a nexus index?

Alexander Vaysberg.

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



Re: Maven 'deploy' relationship to large-scale software deployment

2008-07-31 Thread stug23

Am I alone in needing to understand how Maven relates to large-scale software
deployment?

   :confused:


stug23 wrote:
 
 Maven has its own notion of 'deploying' a software artifact to a Maven
 repository. And there are quite a number of 'out of band' Maven plugins
 such as Cargo that can remotely deploy a war file to a running web
 container.
 
 My question centers on how Maven relates to situations where once a
 software system has been built and tested, the software components then
 need to be globally distributed to many sites. This notion of 'deploying'
 would appear to be quite different than the one embodied in Maven's deploy
 goal.
 
 What experiences have developers here had in leveraging Maven for
 large-scale deployments? When did you  stop using Maven and resort to
 other solutions for deploying bundled software to many distributed sites?
 Or were you able to use Maven for your large-scale software deployment
 right out to the sites?
 
 I would be interested in comments on how others have dealt with this part
 of software deployment. My use case involves distributing 10s of SOA
 services and web applications to many sites.
 

-- 
View this message in context: 
http://www.nabble.com/Maven-%27deploy%27-relationship-to-large-scale-software-deployment-tp18717756p18755789.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: Strange m2 2.0.9 behavior

2008-07-31 Thread EJ Ciramella
Done - MNG-3692

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 8:36 PM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

Definitely news to me. Please file a bug in the war project as it
shouldn't stomp on the regular resource processing. At least you can
define the war plugin version back to 2.0.2 and get working again.

-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 2:26 PM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

For what it's worth - this is a change between the 2.0.2 version of the
war plugin to the 2.1-alpha-1 version (which is included in the 2.0.9
superpom).

This isn't called out (clearly) anywhere that I could find.

-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 1:51 PM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

Ok, I can reproduce this regularly.

We have a version.html file that has a ${label} token inside (as listed
below).  When I run with maven 2.0.9, using mvn install, I can see
that version.html is copied into the target location twice, once via
process-resources (and it's expanded at this point) and then a second
time when the war plugin says:

[INFO] Assembling webapp[pdtApp] in
[E:\work\up-svcs\lty\rel\LTY-R66.0\programData\pdt-web\target\pdtApp-66.
0-SNAPSHOT]
[INFO] Processing war project-
[INFO] Webapp assembled in[2530 msecs]

This is a change since mvn 2.0.5.

I've NOT defined a war plugin, I'm only telling maven that the
packaging is war.  Is it looking at all the defined resources and
copying them over?





-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 1:13 PM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

Additionally, when did maven start expanding ${} to something like


MavenProject: lty:pdtApp:66.0-SNAPSHOT @
E:\work\up-svcs\lty\rel\LTY-R66.0\programData\pdt-web\pom.xml



-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 11:33 AM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

After some more research, here's what I've found.

When I run mvn install -Dfoo=bar, I can see version.html get copied
twice to:

project\webmodule\target\webmodule-X.X-SNAPSHOT

I ran with -X -e, but only see ONE copy step happen.  Basically, when
the war is generated, it copies over the file a second time but
unprocessed.

Is this a fundamental change between maven 2.0.5 and 2.0.9?

-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 29, 2008 3:31 PM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

I'm having a really hard time reproducing this outside of cruisecontrol.

Basically, we have this relationship:

Parent2 - parent1 - child

It's the child project who's process-resources step copies the
version.html from source to target replacing the ${label} within.

I've been able to reproduce this once building from the top most level,
but it takes 20 - 25 minutes for each build.  I trimmed away all the
other modules, and it properly replaces the ${label}.

I guess I was wondering if anyone else has seen anything like this at
all (with 2.0.9).

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 29, 2008 3:18 PM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behaviour

Can you get us a sample project to work on?

-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 29, 2008 10:27 AM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behaviour

Is no one else replacing tokens with some values on the commandline?

Again - this worked great with 2.0.5 but stopped working in 2.0.9.

-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 28, 2008 4:52 PM
To: users@maven.apache.org
Subject: Strange m2 2.0.9 behaviour

I'm seeing an issue with 2.0.9 I think.  Between the 21st and the 22nd,
the only change in the build environment was upgrading from 2.0.5 to
2.0.9.  

 

We're running cruise control and we are injecting the ${label} value
into some of our files during the build.  On the 22nd, this stopped
working leaving behind ${label} in the files that used to be processed
by the process-resources phase.

 

Is this a known issue or anything?  Anyone else seeing this?


-
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 

Re: Where is the default reports reference?

2008-07-31 Thread Kathryn Huxtable

So no one wants to answer this? -K

On Jul 28, 2008, at 6:08 AM, Kathryn Huxtable wrote:

I'm wanting to edit the menu in my site for the Project  
Documentation, which is produced by the site.xml line


menu ref=reports/

In particular, I want it not to be collapsable.

An easy way to do that would be great, but I'm wondering where that  
information comes from. Surely it's not code...


-K

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



maven-test-plugin-1.8.2/plugin.jelly:46:72: maven:addPath: cannot find the path to add to specified by 'id': maven.test.compile.src.set

2008-07-31 Thread Alexey.Yudichev
I am getting the following internal exception in maven test plugin 1.8.2
working inside maven 1.1. Where is this property
(maven.test.compile.src.set) supposed to be set initially?

 

Errors stack :

 Unable to obtain goal [all:rebuildWithoutTest]

 File.. file:/C:/p4/tcw/TCW_S_Dev/fo_tcw_fip/TCW/maven.xml

 Element... m:reactor

 Line.. 24

 Column 45

 Unable to obtain goal [tcw:buildWithoutTest]

 cannot find the path to add to specified by 'id':
maven.test.compile.src.set

 File..
file:/c:/temp/.maven/cache/maven-test-plugin-1.8.2/plugin.jelly

 Element... maven:addPath

 Line.. 46

 Column 72

 

Exception stack traces :

org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal
[all:rebuildWithoutTest]

at org.apache.maven.werkz.Goal.fire(Goal.java:698)

at org.apache.maven.werkz.Goal.attain(Goal.java:623)

at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:526)

at org.apache.maven.werkz.Goal.attain(Goal.java:621)

at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:712
)

at
org.apache.maven.MavenSession.attainGoals(MavenSession.java:265)

at org.apache.maven.cli.App.doMain(App.java:307)

at org.apache.maven.cli.App.main(App.java:217)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at com.werken.forehead.Forehead.run(Forehead.java:551)

at com.werken.forehead.Forehead.main(Forehead.java:581)

Caused by: org.apache.commons.jelly.JellyTagException:
file:/C:/p4/tcw/TCW_S_Dev/fo_tcw_fip/TCW/maven.xml:24:45: m:reactor
Reactor subproje

ct failure occurred

at
org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:380)

at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)

at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j
ava:83)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc
tion(MavenGoalTag.java:116)

at org.apache.maven.werkz.Goal.fire(Goal.java:691)

at org.apache.maven.werkz.Goal.attain(Goal.java:623)

at
org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:209)

at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGo
alTag.java:115)

at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)

at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j
ava:83)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc
tion(MavenGoalTag.java:116)

at org.apache.maven.werkz.Goal.fire(Goal.java:691)

... 13 more

Caused by: org.apache.maven.werkz.UnattainableGoalException: Unable to
obtain goal [tcw:buildWithoutTest]

at org.apache.maven.werkz.Goal.fire(Goal.java:698)

at org.apache.maven.werkz.Goal.attain(Goal.java:623)

at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:712
)

at
org.apache.maven.MavenSession.attainGoals(MavenSession.java:265)

at
org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:370)

... 26 more

Caused by: org.apache.commons.jelly.JellyTagException:
file:/c:/temp/.maven/cache/maven-test-plugin-1.8.2/plugin.jelly:46:72:
maven:addPath

 cannot find the path to add to specified by 'id':
maven.test.compile.src.set

at
org.apache.maven.jelly.tags.maven.AddPathTag.doTag(AddPathTag.java:67)

at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)

at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j
ava:83)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc
tion(MavenGoalTag.java:116)

at org.apache.maven.werkz.Goal.fire(Goal.java:691)

at org.apache.maven.werkz.Goal.attain(Goal.java:623)

at
org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:209)

at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGo
alTag.java:115)

at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)

at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j
ava:83)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc
tion(MavenGoalTag.java:116)

at org.apache.maven.werkz.Goal.fire(Goal.java:691)

at 

Custom properties injected within the execution of archetype:create

2008-07-31 Thread Alexandre Touret

Hello,
I m currently trying to inject a custom property in the execution of the
creation of a project my an archetype. I'd like to maven resolves this
property like groupId or artifactId in a pom file.

I tried to both inject the property in the command line (eg.: -Dmyproperty )
and the settings file. I already have the same result.
Then I also tried to create an archetype-metadata.xml file and parameterize
a required property -- same result.

Is my wish possible  ?If yes , how to inject a property in the execution of
archetype:create ?

Thanks in advance for your help


Regards,
Alexandre




-- 
View this message in context: 
http://www.nabble.com/Custom-properties-injected-within-the-execution-of-archetype%3Acreate-tp18756993p18756993.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 make archetype resource copy as package structure

2008-07-31 Thread qrtt1


Hi Simone Gianni-2:

I found something interesting that meta-data is needless.
Using archetype:generate will work well, the resources is packaged to
directory automatically.

C:\temptree orz
列出資料夾 PATH
磁碟區序列號碼為 08A8-9415
C:\TEMP\ORZ
└─src
├─main
│  ├─java
│  │  └─orz
│  └─resources
│  └─orz
└─test
└─java
└─orz

PS. `orz' is my groupId
-- 
View this message in context: 
http://www.nabble.com/how-to-make-archetype-resource-copy-as-package-structure-tp18751132p18757053.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: maven-test-plugin-1.8.2/plugin.jelly:46:72: maven:addPath: cannot find the path to add to specified by 'id': maven.test.compile.src.set

2008-07-31 Thread Lukas Theussl



You are using a custom goal in maven.xml, so we'd need to see what's in 
there to be able to help you. The maven.test.compile.src.set property 
[1] holds the directory of test sources so you probably need something like


maven:addPath id=maven.test.compile.src.set refid=your_test_sources/

HTH,
-Lukas


[1] http://maven.apache.org/maven-1.x/plugins/test/properties.html



[EMAIL PROTECTED] wrote:

I am getting the following internal exception in maven test plugin 1.8.2
working inside maven 1.1. Where is this property
(maven.test.compile.src.set) supposed to be set initially?

 


Errors stack :



Unable to obtain goal [all:rebuildWithoutTest]




File.. file:/C:/p4/tcw/TCW_S_Dev/fo_tcw_fip/TCW/maven.xml




Element... m:reactor




Line.. 24




Column 45




Unable to obtain goal [tcw:buildWithoutTest]




cannot find the path to add to specified by 'id':


maven.test.compile.src.set



File..


file:/c:/temp/.maven/cache/maven-test-plugin-1.8.2/plugin.jelly



Element... maven:addPath




Line.. 46




Column 72



 


Exception stack traces :

org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal
[all:rebuildWithoutTest]

at org.apache.maven.werkz.Goal.fire(Goal.java:698)

at org.apache.maven.werkz.Goal.attain(Goal.java:623)

at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:526)

at org.apache.maven.werkz.Goal.attain(Goal.java:621)

at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:712
)

at
org.apache.maven.MavenSession.attainGoals(MavenSession.java:265)

at org.apache.maven.cli.App.doMain(App.java:307)

at org.apache.maven.cli.App.main(App.java:217)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at com.werken.forehead.Forehead.run(Forehead.java:551)

at com.werken.forehead.Forehead.main(Forehead.java:581)

Caused by: org.apache.commons.jelly.JellyTagException:
file:/C:/p4/tcw/TCW_S_Dev/fo_tcw_fip/TCW/maven.xml:24:45: m:reactor
Reactor subproje

ct failure occurred

at
org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:380)

at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)

at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j
ava:83)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc
tion(MavenGoalTag.java:116)

at org.apache.maven.werkz.Goal.fire(Goal.java:691)

at org.apache.maven.werkz.Goal.attain(Goal.java:623)

at
org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:209)

at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGo
alTag.java:115)

at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)

at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j
ava:83)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc
tion(MavenGoalTag.java:116)

at org.apache.maven.werkz.Goal.fire(Goal.java:691)

... 13 more

Caused by: org.apache.maven.werkz.UnattainableGoalException: Unable to
obtain goal [tcw:buildWithoutTest]

at org.apache.maven.werkz.Goal.fire(Goal.java:698)

at org.apache.maven.werkz.Goal.attain(Goal.java:623)

at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:712
)

at
org.apache.maven.MavenSession.attainGoals(MavenSession.java:265)

at
org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:370)

... 26 more

Caused by: org.apache.commons.jelly.JellyTagException:
file:/c:/temp/.maven/cache/maven-test-plugin-1.8.2/plugin.jelly:46:72:
maven:addPath

 cannot find the path to add to specified by 'id':
maven.test.compile.src.set

at
org.apache.maven.jelly.tags.maven.AddPathTag.doTag(AddPathTag.java:67)

at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)

at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j
ava:83)

at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc
tion(MavenGoalTag.java:116)

at org.apache.maven.werkz.Goal.fire(Goal.java:691)

at org.apache.maven.werkz.Goal.attain(Goal.java:623)

at
org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:209)

at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGo
alTag.java:115)

  

Re: Archiva and Nexus index

2008-07-31 Thread Brett Porter
not yet, but we intend to support it.

http://markmail.org/message/irbmwkoxx6phqx7c

2008/7/31 Alexander Vaysberg [EMAIL PROTECTED]:
 Hi,
 can an archiva produce a nexus index?

 Alexander Vaysberg.

 -
 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: Strange m2 2.0.9 behavior

2008-07-31 Thread EJ Ciramella
P.S. - how do we get notified there are changes (especially since I'm
going to be forcing an older version)?

-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 31, 2008 10:27 AM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

Done - MNG-3692

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 8:36 PM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

Definitely news to me. Please file a bug in the war project as it
shouldn't stomp on the regular resource processing. At least you can
define the war plugin version back to 2.0.2 and get working again.

-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 2:26 PM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

For what it's worth - this is a change between the 2.0.2 version of the
war plugin to the 2.1-alpha-1 version (which is included in the 2.0.9
superpom).

This isn't called out (clearly) anywhere that I could find.

-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 1:51 PM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

Ok, I can reproduce this regularly.

We have a version.html file that has a ${label} token inside (as listed
below).  When I run with maven 2.0.9, using mvn install, I can see
that version.html is copied into the target location twice, once via
process-resources (and it's expanded at this point) and then a second
time when the war plugin says:

[INFO] Assembling webapp[pdtApp] in
[E:\work\up-svcs\lty\rel\LTY-R66.0\programData\pdt-web\target\pdtApp-66.
0-SNAPSHOT]
[INFO] Processing war project-
[INFO] Webapp assembled in[2530 msecs]

This is a change since mvn 2.0.5.

I've NOT defined a war plugin, I'm only telling maven that the
packaging is war.  Is it looking at all the defined resources and
copying them over?





-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 1:13 PM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

Additionally, when did maven start expanding ${} to something like


MavenProject: lty:pdtApp:66.0-SNAPSHOT @
E:\work\up-svcs\lty\rel\LTY-R66.0\programData\pdt-web\pom.xml



-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 30, 2008 11:33 AM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

After some more research, here's what I've found.

When I run mvn install -Dfoo=bar, I can see version.html get copied
twice to:

project\webmodule\target\webmodule-X.X-SNAPSHOT

I ran with -X -e, but only see ONE copy step happen.  Basically, when
the war is generated, it copies over the file a second time but
unprocessed.

Is this a fundamental change between maven 2.0.5 and 2.0.9?

-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 29, 2008 3:31 PM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behavior

I'm having a really hard time reproducing this outside of cruisecontrol.

Basically, we have this relationship:

Parent2 - parent1 - child

It's the child project who's process-resources step copies the
version.html from source to target replacing the ${label} within.

I've been able to reproduce this once building from the top most level,
but it takes 20 - 25 minutes for each build.  I trimmed away all the
other modules, and it properly replaces the ${label}.

I guess I was wondering if anyone else has seen anything like this at
all (with 2.0.9).

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 29, 2008 3:18 PM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behaviour

Can you get us a sample project to work on?

-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 29, 2008 10:27 AM
To: Maven Users List
Subject: RE: Strange m2 2.0.9 behaviour

Is no one else replacing tokens with some values on the commandline?

Again - this worked great with 2.0.5 but stopped working in 2.0.9.

-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 28, 2008 4:52 PM
To: users@maven.apache.org
Subject: Strange m2 2.0.9 behaviour

I'm seeing an issue with 2.0.9 I think.  Between the 21st and the 22nd,
the only change in the build environment was upgrading from 2.0.5 to
2.0.9.  

 

We're running cruise control and we are injecting the ${label} value
into some of our files during the build.  On the 22nd, this stopped
working leaving behind ${label} in the files that used to be processed
by the process-resources phase.

 

Is this a known issue or anything?  Anyone else seeing this?


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



[m2] maven-checkstyle-plugin, v2.2 - includeTestSourceDirectory, xref links broken

2008-07-31 Thread Dan Rollo
I have configured the reporting section of my pom.xml to include the jxr
report AND the checkstyle report (with the includeTestSourceDirectory
element) as shown below:

!-- generates a cross-reference of the project's sources --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jxr-plugin/artifactId
version2.1/version
/plugin

!-- generates report regarding the code style --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.2/version
configuration
!-- based on config/sun_checks.xml, but also checks for
headers in source files --

configLocationconfig/jdbc4olap_checks.xml/configLocation

includeTestSourceDirectorytrue/includeTestSourceDirectory
/configuration
/plugin


I'm seeing the problems below:

1. The xref link to the Source pages in the checkstyle report page is
broken. The source xref link for Unit Test Source files is not using the
default value of the destDir for jxr test sources. From the jxr plugin docs
for jxr:test-jxr:

destDir

Folder where the Xref files will be copied to.

* Type: java.lang.String
* Required: No
* Expression: ${project.reporting.outputDirectory}/xref-test

I think the checkstyle plugin should:
- assume the default dir for jxr:test-jxr
- provide it's own additional override setting (similar to xrefLocation,
but for test sources). like: testXrefLocation.

2. When I include the includeTestSourceDirectory element, the source xref
link for production (non-test) classes has a mangled URL: the first letter
of the package is ommitted in the link:
file:///.../jdbc4olap/target/site/xref/org/jdbc4olap/xmla/XmlaProperties.html#10
  missing o or org
file:///.../jdbc4olap/target/site/xref/rg/jdbc4olap/xmla/XmlaProperties.html#10

If I remove the includeTestSourceDirectory element, the xref links to
production sources are fine.

[BTW, there is a LICENSE.txt file at the root of my project (in case anyone
thought a missing default header file would affect this), and the checkstyle
report properly flags missing headers.]

I searched for prior posts and jira issues about this, but found none. Is
this a known issue? Should I file a jira? Any ideas on a workaround that
would allow me to both includeTestSourceDirectory AND link to sources?

Thanks,
Dan


Re: [m2] maven-checkstyle-plugin, v2.2 - includeTestSourceDirectory, xref links broken

2008-07-31 Thread Dennis Lundberg

Hi Dan

Please file these as 2 different issues for the Checkstyle Plugin:

http://jira.codehaus.org/browse/MCHECKSTYLE

Please include a complete pom.xml for each one, as it helps us to debug 
that particular issue.


Dan Rollo wrote:

I have configured the reporting section of my pom.xml to include the jxr
report AND the checkstyle report (with the includeTestSourceDirectory
element) as shown below:

!-- generates a cross-reference of the project's sources --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jxr-plugin/artifactId
version2.1/version
/plugin

!-- generates report regarding the code style --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.2/version
configuration
!-- based on config/sun_checks.xml, but also checks for
headers in source files --

configLocationconfig/jdbc4olap_checks.xml/configLocation

includeTestSourceDirectorytrue/includeTestSourceDirectory
/configuration
/plugin


I'm seeing the problems below:

1. The xref link to the Source pages in the checkstyle report page is
broken. The source xref link for Unit Test Source files is not using the
default value of the destDir for jxr test sources. From the jxr plugin docs
for jxr:test-jxr:

destDir

Folder where the Xref files will be copied to.

* Type: java.lang.String
* Required: No
* Expression: ${project.reporting.outputDirectory}/xref-test

I think the checkstyle plugin should:
- assume the default dir for jxr:test-jxr
- provide it's own additional override setting (similar to xrefLocation,
but for test sources). like: testXrefLocation.

2. When I include the includeTestSourceDirectory element, the source xref
link for production (non-test) classes has a mangled URL: the first letter
of the package is ommitted in the link:
file:///.../jdbc4olap/target/site/xref/org/jdbc4olap/xmla/XmlaProperties.html#10
  missing o or org
file:///.../jdbc4olap/target/site/xref/rg/jdbc4olap/xmla/XmlaProperties.html#10

If I remove the includeTestSourceDirectory element, the xref links to
production sources are fine.

[BTW, there is a LICENSE.txt file at the root of my project (in case anyone
thought a missing default header file would affect this), and the checkstyle
report properly flags missing headers.]

I searched for prior posts and jira issues about this, but found none. Is
this a known issue? Should I file a jira? Any ideas on a workaround that
would allow me to both includeTestSourceDirectory AND link to sources?

Thanks,
Dan




--
Dennis Lundberg

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



[SURVEY] Which plugin would you like us to release?

2008-07-31 Thread Dennis Lundberg

Hello everyone

I'm going to try something new here. It's an experiment and we'll see 
how it goes. I have set up a very simple survey over at SurveyMonkey, to 
get a feel for what you, our users, want us to do next when it comes to 
plugin releases. Remember, this is *not* about fixing issues - it's 
about getting releases out.


So please help us help you, by answering this one question survey:

http://www.surveymonkey.com/s.aspx?sm=M6IB7I_2fVmpKddfv1oCM_2few_3d_3d

--
Dennis Lundberg

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



RE: Release:branch from a tag

2008-07-31 Thread evans022

I have the same question.  What is the correct steps in order to create a
branch from a tag using the release:branch goal?

Thank you,
Jason


Nick Stolwijk wrote:
 
 Can someone comment on this mail? Is the release:branch goal fitted to
 create a branch from a tag and update the version numbers?
 
 With regards,
 
 Nick Stolwijk
 ~Java Developer~
 
 Iprofs BV.
 Claus Sluterweg 125
 2012 WS Haarlem
 www.iprofs.nl
 
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Tue 6/10/2008 11:15
 To: users@maven.apache.org
 Subject: Release:branch from a tag
  
 I am trying to create a branch from a tag with the release plugin. I have
 a checkout from trunk and try the following command:
 
 mvn release:branch -Dtag=TestProject-1.4 -DbranchName=TestProject-1.4.x s
 -DupdateBranchVersions=true
 
 I was expecting that a branch (/branches/TestProject-1.4.x) was created
 from a tag (/tags/TestProject-1.4) but it is created from the current
 trunk (/trunk). It seems the -Dtag option doesn't do anything, because it
 is creating a branch from the current trunk. Is it really necessary to
 checkout a tag before branching it? I've looked at the ReleaseManager
 source and it seems the tag option isn't considered at all.
 
 With regards,
 
 Nick Stolwijk
 ~Java Developer~
 
 Iprofs BV.
 Claus Sluterweg 125
 2012 WS Haarlem
 www.iprofs.nl
 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Release%3Abranch-from-a-tag-tp17751076p18762978.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: Maven 'deploy' relationship to large-scale software deployment

2008-07-31 Thread EJ Ciramella
No, I don't understand how to do it either.  I just stepped out of a
meeting where we were discussing how we can deploy the same set of
applications (which _some_ share properties) across 10 - 15 different
environments.  Some environments have different configurations, some are
carbon copies.

There doesn't seem to be any maven solution to either/all of these
problems:

1 - Where does a property go (say db connection string) that's shared
between different applications such that there isn't duplication?  No
one wants to have to search/replace values in various profiles.xml or
pom.xml files (I don't mind, but others in the organization have
objected).  Here, since there are so many applications pointed at the
same db, that could be a dozen or so files that have the same db string.

2 - How does one deploy said generated application zip/tar file?
There's nothing I can see supplied in any plugin to support large scale
deployments (say, six app servers, four web servers, a db server, a
utils server and another half dozen or so third party servers).  We've
been using ant and a internally written shell script.

3 - How do people configure these things?  I've heard every answer from
we generate a zipped/tarred up application file for every environment
to we use installshield and don't have to worry and everything in
between.  We have in one environment alone, 6 jboss servers for ONE
application.  That ear that gets deployed there (and all it's supporting
files) even compressed in a zip takes close to 200 mb.  I'm not about to
generate 1200 mb worth of ear files with each build (sometimes there's
three or more built in a single day).

I feel like either there are different terms to describe these things or
no one is doing anything to this scale.

I'd love some feedback/suggestions as to how others are doing this.

-Original Message-
From: stug23 [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 31, 2008 10:25 AM
To: users@maven.apache.org
Subject: Re: Maven 'deploy' relationship to large-scale software
deployment


Am I alone in needing to understand how Maven relates to large-scale
software
deployment?

   :confused:


stug23 wrote:
 
 Maven has its own notion of 'deploying' a software artifact to a Maven
 repository. And there are quite a number of 'out of band' Maven
plugins
 such as Cargo that can remotely deploy a war file to a running web
 container.
 
 My question centers on how Maven relates to situations where once a
 software system has been built and tested, the software components
then
 need to be globally distributed to many sites. This notion of
'deploying'
 would appear to be quite different than the one embodied in Maven's
deploy
 goal.
 
 What experiences have developers here had in leveraging Maven for
 large-scale deployments? When did you  stop using Maven and resort to
 other solutions for deploying bundled software to many distributed
sites?
 Or were you able to use Maven for your large-scale software deployment
 right out to the sites?
 
 I would be interested in comments on how others have dealt with this
part
 of software deployment. My use case involves distributing 10s of SOA
 services and web applications to many sites.
 

-- 
View this message in context:
http://www.nabble.com/Maven-%27deploy%27-relationship-to-large-scale-sof
tware-deployment-tp18717756p18755789.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]



PRofiles and Pom cleanup

2008-07-31 Thread Clifton

Wassup y'all? I've been maintaining a multi-module client/server Maven2
project for quite some time now and it's getting out of hand. One thing I'd
like to know is how to properly arrange/configure profiles. To give an
example of what I'm trying to do, we have multiple developer setups that we
support, local deployment, local debug deployment, local JMX JProfile
enabled deployment, remote developer deployment, remote with debug, remote
with JMX... you get the picture. We also have various servers we deploy to
remotely. Staging servers, developer servers, QA servers, production
servers, etc. Then we have a bunch of different servers in the backend that
our app talks to. Currently our profiles are exploding into a Matrix of
every possible configuration you can imagine. We use a grandparent pom to
manage most of these configurations but then some more developer specific
(as needs arrive) start popping up in a profiles.xml file in the root of our
project. I'd like to organize things logically. Something like profile
groupings where we'd have all of the production servers we talk to in the
back end grouped into production/staging/qa/dev while all of our project pom
files referr to them using symbolic proerties. For Eg. we'd have an
image.slicing.server defined as a property which is set in each of the
profile groups dev/qa/prod/etc. I'd also like to define profiles that set
properties which trigger the activation of other profiles so that we can
activate one profile (like LancasterDev profile) and cause a chain
activation of several other profiles (activate LancasterServerRoom1, Debug,
and DeviceEmultaor). I think this is a restriction of Maven because it
doesn't seem to work as I thought it would. At any rate, could somebody
share some best practices or good experiences with profiles under Maven2?
Any insight is appreciated.

-
Cliff
http://codeforfun.wordpress.com
http://www.nabble.com/file/u156847/Cliff-in-the-lab.png 
-- 
View this message in context: 
http://www.nabble.com/PRofiles-and-Pom-cleanup-tp18763136p18763136.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: Maven 'deploy' relationship to large-scale software deployment

2008-07-31 Thread Brett Porter
I think you'll find that Maven itself stops at the repository. So the
best thing to do is to use tools that can take artifacts from the
repository and deploy them.

There are lots of other solutions around for doing this sort of thing
beyond that point and they specialise in handling the new set of
problems it brings. I've generally found those doing the deployment
are very separate from the rest of the development team and often have
their own chosen set of tooling.

You could use Maven itself to do this - though I'm not aware of any
plugins that focus on this. While Cargo is generally used for test
setups, it could serve this purpose as well, but it's mostly a space
for a new piece of work.

Cheers,
Brett

2008/8/1 EJ Ciramella [EMAIL PROTECTED]:
 No, I don't understand how to do it either.  I just stepped out of a
 meeting where we were discussing how we can deploy the same set of
 applications (which _some_ share properties) across 10 - 15 different
 environments.  Some environments have different configurations, some are
 carbon copies.

 There doesn't seem to be any maven solution to either/all of these
 problems:

 1 - Where does a property go (say db connection string) that's shared
 between different applications such that there isn't duplication?  No
 one wants to have to search/replace values in various profiles.xml or
 pom.xml files (I don't mind, but others in the organization have
 objected).  Here, since there are so many applications pointed at the
 same db, that could be a dozen or so files that have the same db string.

 2 - How does one deploy said generated application zip/tar file?
 There's nothing I can see supplied in any plugin to support large scale
 deployments (say, six app servers, four web servers, a db server, a
 utils server and another half dozen or so third party servers).  We've
 been using ant and a internally written shell script.

 3 - How do people configure these things?  I've heard every answer from
 we generate a zipped/tarred up application file for every environment
 to we use installshield and don't have to worry and everything in
 between.  We have in one environment alone, 6 jboss servers for ONE
 application.  That ear that gets deployed there (and all it's supporting
 files) even compressed in a zip takes close to 200 mb.  I'm not about to
 generate 1200 mb worth of ear files with each build (sometimes there's
 three or more built in a single day).

 I feel like either there are different terms to describe these things or
 no one is doing anything to this scale.

 I'd love some feedback/suggestions as to how others are doing this.

 -Original Message-
 From: stug23 [mailto:[EMAIL PROTECTED]
 Sent: Thursday, July 31, 2008 10:25 AM
 To: users@maven.apache.org
 Subject: Re: Maven 'deploy' relationship to large-scale software
 deployment


 Am I alone in needing to understand how Maven relates to large-scale
 software
 deployment?

   :confused:


 stug23 wrote:

 Maven has its own notion of 'deploying' a software artifact to a Maven
 repository. And there are quite a number of 'out of band' Maven
 plugins
 such as Cargo that can remotely deploy a war file to a running web
 container.

 My question centers on how Maven relates to situations where once a
 software system has been built and tested, the software components
 then
 need to be globally distributed to many sites. This notion of
 'deploying'
 would appear to be quite different than the one embodied in Maven's
 deploy
 goal.

 What experiences have developers here had in leveraging Maven for
 large-scale deployments? When did you  stop using Maven and resort to
 other solutions for deploying bundled software to many distributed
 sites?
 Or were you able to use Maven for your large-scale software deployment
 right out to the sites?

 I would be interested in comments on how others have dealt with this
 part
 of software deployment. My use case involves distributing 10s of SOA
 services and web applications to many sites.


 --
 View this message in context:
 http://www.nabble.com/Maven-%27deploy%27-relationship-to-large-scale-sof
 tware-deployment-tp18717756p18755789.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]





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

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



RE: Maven 'deploy' relationship to large-scale software deployment

2008-07-31 Thread EJ Ciramella
This only hints at solutions to #2 below:

 2 - How does one deploy said generated application zip/tar file?
 There's nothing I can see supplied in any plugin to support large
scale
 deployments (say, six app servers, four web servers, a db server, a
 utils server and another half dozen or so third party servers).  We've
 been using ant and an internally written shell script.

Yes, we drop maven once the build is headed anywhere other than the
local machine - but even within this developer environment, how do you
share properties/configuration/etc across different applications without
massive copy/paste duplication?  How does anyone build to support
multiple environments?  Are you really rebuilding the ear with a
different configuration?  Is your ear over say, 20 mb?

Are people just NOT building this level of complexity within maven?

Even if the configuration/profiles was pushed out into a corporate pom
(something outside of the general project structure), if/when that
changed, you'd have a million poms to update to point them to a new
parent version.

-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 31, 2008 4:48 PM
To: Maven Users List
Subject: Re: Maven 'deploy' relationship to large-scale software
deployment

I think you'll find that Maven itself stops at the repository. So the
best thing to do is to use tools that can take artifacts from the
repository and deploy them.

There are lots of other solutions around for doing this sort of thing
beyond that point and they specialise in handling the new set of
problems it brings. I've generally found those doing the deployment
are very separate from the rest of the development team and often have
their own chosen set of tooling.

You could use Maven itself to do this - though I'm not aware of any
plugins that focus on this. While Cargo is generally used for test
setups, it could serve this purpose as well, but it's mostly a space
for a new piece of work.

Cheers,
Brett

2008/8/1 EJ Ciramella [EMAIL PROTECTED]:
 No, I don't understand how to do it either.  I just stepped out of a
 meeting where we were discussing how we can deploy the same set of
 applications (which _some_ share properties) across 10 - 15 different
 environments.  Some environments have different configurations, some
are
 carbon copies.

 There doesn't seem to be any maven solution to either/all of these
 problems:

 1 - Where does a property go (say db connection string) that's shared
 between different applications such that there isn't duplication?  No
 one wants to have to search/replace values in various profiles.xml or
 pom.xml files (I don't mind, but others in the organization have
 objected).  Here, since there are so many applications pointed at the
 same db, that could be a dozen or so files that have the same db
string.

 2 - How does one deploy said generated application zip/tar file?
 There's nothing I can see supplied in any plugin to support large
scale
 deployments (say, six app servers, four web servers, a db server, a
 utils server and another half dozen or so third party servers).  We've
 been using ant and a internally written shell script.

 3 - How do people configure these things?  I've heard every answer
from
 we generate a zipped/tarred up application file for every
environment
 to we use installshield and don't have to worry and everything in
 between.  We have in one environment alone, 6 jboss servers for ONE
 application.  That ear that gets deployed there (and all it's
supporting
 files) even compressed in a zip takes close to 200 mb.  I'm not about
to
 generate 1200 mb worth of ear files with each build (sometimes there's
 three or more built in a single day).

 I feel like either there are different terms to describe these things
or
 no one is doing anything to this scale.

 I'd love some feedback/suggestions as to how others are doing this.

 -Original Message-
 From: stug23 [mailto:[EMAIL PROTECTED]
 Sent: Thursday, July 31, 2008 10:25 AM
 To: users@maven.apache.org
 Subject: Re: Maven 'deploy' relationship to large-scale software
 deployment


 Am I alone in needing to understand how Maven relates to large-scale
 software
 deployment?

   :confused:


 stug23 wrote:

 Maven has its own notion of 'deploying' a software artifact to a
Maven
 repository. And there are quite a number of 'out of band' Maven
 plugins
 such as Cargo that can remotely deploy a war file to a running web
 container.

 My question centers on how Maven relates to situations where once a
 software system has been built and tested, the software components
 then
 need to be globally distributed to many sites. This notion of
 'deploying'
 would appear to be quite different than the one embodied in Maven's
 deploy
 goal.

 What experiences have developers here had in leveraging Maven for
 large-scale deployments? When did you  stop using Maven and resort to
 other solutions for deploying bundled software to many distributed
 sites?
 Or 

Eclipse - Maven Integration

2008-07-31 Thread Morgovsky, Alexander (US - Glen Mills)
I would like to create a maven plugin in eclipse which will throw up a
message box with radio buttons, check boxes, etc..What would be the way
to start this?  Thanks. 


This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and is protected by law.  If 
you are not the intended recipient, you should delete this message. 


Any disclosure, copying, or distribution of this message, or the taking of any 
action based on it, is strictly prohibited. [v.E.1]


Re: Maven 'deploy' relationship to large-scale software deployment

2008-07-31 Thread Brett Porter
2008/8/1 EJ Ciramella [EMAIL PROTECTED]:
 This only hints at solutions to #2 below:

 2 - How does one deploy said generated application zip/tar file?
 There's nothing I can see supplied in any plugin to support large
 scale
 deployments (say, six app servers, four web servers, a db server, a
 utils server and another half dozen or so third party servers).  We've
 been using ant and an internally written shell script.

 Yes, we drop maven once the build is headed anywhere other than the
 local machine - but even within this developer environment, how do you
 share properties/configuration/etc across different applications without
 massive copy/paste duplication?  How does anyone build to support
 multiple environments?  Are you really rebuilding the ear with a
 different configuration?  Is your ear over say, 20 mb?

 Are people just NOT building this level of complexity within maven?

 Even if the configuration/profiles was pushed out into a corporate pom
 (something outside of the general project structure), if/when that
 changed, you'd have a million poms to update to point them to a new
 parent version.

Sorry, I was replying to the OP, I just hit the wrong box in gmail.

I highly recommend externalised configuration wherever possible - that
is to have the ear or more general artifact not have any knowledge of
it's target deployment environment.

The classic example of database connections, using JNDI can be managed
in the server configuration by the deployer rather than built into the
artifact.

Another alternative, if the information must be within the artifact,
is to post-process the artifact on deployment to put the appropriate
settings in rather than deploying 6 versions to the repository. This
is again separate deployment tooling that would be needed and the
configuration for the target environments is managed along with it.

If you do get into the situation where you want to share properties
and settings in the original build and share them across teams, the
best solution is to use the dependency plugin to unpack an artifact so
that the information can be consolidated and deployed within that
artifact.

HTH,
Brett

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



Re: Maven 'deploy' relationship to large-scale software deployment

2008-07-31 Thread stug23

Yes I have found that Cargo has some nice capabilities for deploying into
remote containers, along with the war merging capability to address cases
where services and/or other components need to be combined in certain
deployments.

I do find it interesting that there aren't more tools (well as far as I am
aware at this point...) that are designed specifically to perform
large-scale deployment from a Maven repository to multiple (in some cases
many ~100s) destinations.

With respect to your posting on configuration, I totally agree -- it just
makes sense to separate configuration from the jars/wars/ears to the
greatest extent possible. It's much easier to configure for a site when it
doesn't involve ripping apart jars/wars/ears in order to accomplish
site-specific configurations. It can become quite unmanageable to build the
same war file over and over again just to accommodate a couple of tweaks in
an XML configuration file.

Thanks for the replies thus far to my original question! 

Has anyone else out there got more examples of tools that extract from Maven
repository and then construct large-scale deployments to multiple sites?





Brett Porter wrote:
 
 I think you'll find that Maven itself stops at the repository. So the
 best thing to do is to use tools that can take artifacts from the
 repository and deploy them.
 
 There are lots of other solutions around for doing this sort of thing
 beyond that point and they specialise in handling the new set of
 problems it brings. I've generally found those doing the deployment
 are very separate from the rest of the development team and often have
 their own chosen set of tooling.
 
 You could use Maven itself to do this - though I'm not aware of any
 plugins that focus on this. While Cargo is generally used for test
 setups, it could serve this purpose as well, but it's mostly a space
 for a new piece of work.
 
 Cheers,
 Brett
 
 2008/8/1 EJ Ciramella [EMAIL PROTECTED]:
 No, I don't understand how to do it either.  I just stepped out of a
 meeting where we were discussing how we can deploy the same set of
 applications (which _some_ share properties) across 10 - 15 different
 environments.  Some environments have different configurations, some are
 carbon copies.

 There doesn't seem to be any maven solution to either/all of these
 problems:

 1 - Where does a property go (say db connection string) that's shared
 between different applications such that there isn't duplication?  No
 one wants to have to search/replace values in various profiles.xml or
 pom.xml files (I don't mind, but others in the organization have
 objected).  Here, since there are so many applications pointed at the
 same db, that could be a dozen or so files that have the same db string.

 2 - How does one deploy said generated application zip/tar file?
 There's nothing I can see supplied in any plugin to support large scale
 deployments (say, six app servers, four web servers, a db server, a
 utils server and another half dozen or so third party servers).  We've
 been using ant and a internally written shell script.

 3 - How do people configure these things?  I've heard every answer from
 we generate a zipped/tarred up application file for every environment
 to we use installshield and don't have to worry and everything in
 between.  We have in one environment alone, 6 jboss servers for ONE
 application.  That ear that gets deployed there (and all it's supporting
 files) even compressed in a zip takes close to 200 mb.  I'm not about to
 generate 1200 mb worth of ear files with each build (sometimes there's
 three or more built in a single day).

 I feel like either there are different terms to describe these things or
 no one is doing anything to this scale.

 I'd love some feedback/suggestions as to how others are doing this.

 -Original Message-
 From: stug23 [mailto:[EMAIL PROTECTED]
 Sent: Thursday, July 31, 2008 10:25 AM
 To: users@maven.apache.org
 Subject: Re: Maven 'deploy' relationship to large-scale software
 deployment


 Am I alone in needing to understand how Maven relates to large-scale
 software
 deployment?

   :confused:


 stug23 wrote:

 Maven has its own notion of 'deploying' a software artifact to a Maven
 repository. And there are quite a number of 'out of band' Maven
 plugins
 such as Cargo that can remotely deploy a war file to a running web
 container.

 My question centers on how Maven relates to situations where once a
 software system has been built and tested, the software components
 then
 need to be globally distributed to many sites. This notion of
 'deploying'
 would appear to be quite different than the one embodied in Maven's
 deploy
 goal.

 What experiences have developers here had in leveraging Maven for
 large-scale deployments? When did you  stop using Maven and resort to
 other solutions for deploying bundled software to many distributed
 sites?
 Or were you able to use Maven for your large-scale software deployment
 right out to the 

RE: Maven 'deploy' relationship to large-scale software deployment

2008-07-31 Thread EJ Ciramella
Right - this is a slice of the answer and I agree - the real heart of
the matter is, where does the configuration live?  In settings.xml?
Profiles.xml?  Filter files?

How can you reuse them in a deployment world where you're not using
maven?

I'd like to know how people are handling these things.

 If you do get into the situation where you want to share properties
 and settings in the original build and share them across teams, the
 best solution is to use the dependency plugin to unpack an artifact so
 that the information can be consolidated and deployed within that
 artifact.

I looked into this, but that wouldn't work.  If you unpack say, a
profiles.xml file, it's too late in the build sequence.  You'd need to
unpack, stop, start up your build again.  And if you use a filter file,
you can't override those properties from your settings.xml.

Is there some other magic I'm not seeing here?

-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 31, 2008 5:10 PM
To: Maven Users List
Subject: Re: Maven 'deploy' relationship to large-scale software
deployment

2008/8/1 EJ Ciramella [EMAIL PROTECTED]:
 This only hints at solutions to #2 below:

 2 - How does one deploy said generated application zip/tar file?
 There's nothing I can see supplied in any plugin to support large
 scale
 deployments (say, six app servers, four web servers, a db server, a
 utils server and another half dozen or so third party servers).
We've
 been using ant and an internally written shell script.

 Yes, we drop maven once the build is headed anywhere other than the
 local machine - but even within this developer environment, how do you
 share properties/configuration/etc across different applications
without
 massive copy/paste duplication?  How does anyone build to support
 multiple environments?  Are you really rebuilding the ear with a
 different configuration?  Is your ear over say, 20 mb?

 Are people just NOT building this level of complexity within maven?

 Even if the configuration/profiles was pushed out into a corporate
pom
 (something outside of the general project structure), if/when that
 changed, you'd have a million poms to update to point them to a new
 parent version.

Sorry, I was replying to the OP, I just hit the wrong box in gmail.

I highly recommend externalised configuration wherever possible - that
is to have the ear or more general artifact not have any knowledge of
it's target deployment environment.

The classic example of database connections, using JNDI can be managed
in the server configuration by the deployer rather than built into the
artifact.

Another alternative, if the information must be within the artifact,
is to post-process the artifact on deployment to put the appropriate
settings in rather than deploying 6 versions to the repository. This
is again separate deployment tooling that would be needed and the
configuration for the target environments is managed along with it.

If you do get into the situation where you want to share properties
and settings in the original build and share them across teams, the
best solution is to use the dependency plugin to unpack an artifact so
that the information can be consolidated and deployed within that
artifact.

HTH,
Brett

-
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 'deploy' relationship to large-scale software deployment

2008-07-31 Thread Wendy Smoak
On Thu, Jul 31, 2008 at 2:32 PM, stug23 [EMAIL PROTECTED] wrote:

 I do find it interesting that there aren't more tools (well as far as I am
 aware at this point...) that are designed specifically to perform
 large-scale deployment from a Maven repository to multiple (in some cases
 many ~100s) destinations.

You might want to look at SmartFrog... http://smartfrog.org/

-- 
Wendy

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



Re: Maven 'deploy' relationship to large-scale software deployment

2008-07-31 Thread Brett Porter
2008/8/1 EJ Ciramella [EMAIL PROTECTED]:
 I looked into this, but that wouldn't work.  If you unpack say, a
 profiles.xml file, it's too late in the build sequence.  You'd need to
 unpack, stop, start up your build again.  And if you use a filter file,
 you can't override those properties from your settings.xml.

 Is there some other magic I'm not seeing here?

I wasn't suggesting the unpacking of these files - it is very unlikely
settings or profiles would contain application configuration. They are
the environment for the build, not the environment for the deployment.

the artifact can be used for filter files, resource descriptors, or
other configuration files built into the artifact - but again, this
gets into the situation where you either need to build for multiple
targets or post-process the artifacts, which often isn't ideal. The
technique is much better for sharing non-environmental configuration
among multiple applications instead.

If you do separate the configuration from the build, then how you
manage it is really dependant on how others deploy the application.

Cheers,
Brett

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

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



Re: [SURVEY] Which plugin would you like us to release?

2008-07-31 Thread Samuel Le Berrigaud
Hi Dennis,

It would be nice to vote for multiple plugins. Picking only one plugin
from this list is quite difficult…

SaM

On Fri, Aug 1, 2008 at 5:52 AM, Dennis Lundberg [EMAIL PROTECTED] wrote:
 Hello everyone

 I'm going to try something new here. It's an experiment and we'll see how it
 goes. I have set up a very simple survey over at SurveyMonkey, to get a feel
 for what you, our users, want us to do next when it comes to plugin
 releases. Remember, this is *not* about fixing issues - it's about getting
 releases out.

 So please help us help you, by answering this one question survey:

 http://www.surveymonkey.com/s.aspx?sm=M6IB7I_2fVmpKddfv1oCM_2few_3d_3d

 --
 Dennis Lundberg

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




Re: [SURVEY] Which plugin would you like us to release?

2008-07-31 Thread Dennis Lundberg

Thanks for your feedback Sam, I'll keep that in mind for the next survey.

Samuel Le Berrigaud wrote:

Hi Dennis,

It would be nice to vote for multiple plugins. Picking only one plugin
from this list is quite difficult…

SaM

On Fri, Aug 1, 2008 at 5:52 AM, Dennis Lundberg [EMAIL PROTECTED] wrote:

Hello everyone

I'm going to try something new here. It's an experiment and we'll see how it
goes. I have set up a very simple survey over at SurveyMonkey, to get a feel
for what you, our users, want us to do next when it comes to plugin
releases. Remember, this is *not* about fixing issues - it's about getting
releases out.

So please help us help you, by answering this one question survey:

http://www.surveymonkey.com/s.aspx?sm=M6IB7I_2fVmpKddfv1oCM_2few_3d_3d

--
Dennis Lundberg

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





--
Dennis Lundberg

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



Maven Presentation

2008-07-31 Thread Chris Pall
I'll be giving a Maven presentation in the next couple of months, and wanted
to know if anyone had any good resources on this sort of thing. I want to
highlight how Maven is significantly better than what we are currently
doing, which is relatively typical: ant scripts with custom deploy systems
(to push configurations). What are the biggest points that make using maven
better, I've read the What is Maven? page, and I've got the five main
bullet points. Should I just stick to those?

A google search brings up the following:

http://wiki.wsmoak.net/cgi-bin/wiki.pl?Maven/Presentation

Which suggests that if we've got a working ant build, there's no real point
to using maven, which surprised me, cause the maven documentation suggests
that Maven is more than a build system. How do I really make the case that
it does more than this?


-- cgp


Re: Release Plugin - Resolving Snapshot Dependencies

2008-07-31 Thread Craig
Geoffrey,

Could it be this bug http://jira.codehaus.org/browse/MRELEASE-350 ?

Try choosing option '1' instead of option '0'.

regards,
Craig

On Thu, Jul 31, 2008 at 2:18 AM, Geoffrey Wiseman 
[EMAIL PROTECTED] wrote:

 When I'm using the Maven release plugin in a project that depends on
 snapshots, it offers me the ability to roll forward to the release.  That
 seems like a nice feature to have, but it never seems to work for me.  See
 below:

 [INFO] Resuming release from phase 'check-dependency-snapshots'
 [INFO] Checking dependencies and plugins for snapshots ...
 There are still some remaining snapshot dependencies.: Do you want to
 resolve them now? (yes/no) no: : yes
 Dependency type to resolve,: specify the selection number ( 0:All 1:Project
 Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : 0
 Resolve All Snapshots.: 'com.feedroom.feedroom-commons:frc-test' set to
 release? (yes/no) yes: : yes
 What is the next development version? (1.4-SNAPSHOT) 1.4-SNAPSHOT: :
 'com.feedroom.feedroom-commons:frc-common' set to release? (yes/no) yes: :
 yes
 What is the next development version? (1.4-SNAPSHOT) 1.4-SNAPSHOT: :
 [INFO]
 
 [ERROR] BUILD FAILURE
 [INFO]
 
 [INFO] Can't release project due to non released dependencies :
com.feedroom.feedroom-commons:frc-common:jar:1.3-SNAPSHOT:compile
com.feedroom.feedroom-commons:frc-test:jar:1.3-SNAPSHOT:test

 Am I missing something about how this is supposed to work?  It seems like
 it's trying and failing to resolve the dependencies and move forward.

  - Geoffrey
 --
 Geoffrey Wiseman



Maven 2.0.5

2008-07-31 Thread Morgovsky, Alexander (US - Glen Mills)
I have an antrun plugin which has the following definition..however,
even though I bind it to the validate phase, it doesn't run first, the
Maven Clean Plugin runs first...How can have this run first?  Thanks.

 

executions

  execution

idclean/id

phasevalidate/phase

goals

  goalrun/goal

/goals

configuration

  tasks

delete
dir=${project.build.directory}/

mkdir
dir=${project.build.directory}/

  /tasks

/configuration

  /execution

/executions 


This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and is protected by law.  If 
you are not the intended recipient, you should delete this message. 


Any disclosure, copying, or distribution of this message, or the taking of any 
action based on it, is strictly prohibited. [v.E.1]


Re: [m2] maven-checkstyle-plugin, v2.2 - includeTestSourceDirectory, xref links broken

2008-07-31 Thread Dan Rollo
Hi Dennis,

Done:

http://jira.codehaus.org/browse/MCHECKSTYLE-99

Title: includeTestSourceDirectory should use default test sources xref
output dir: ${project.reporting.outputDirectory}/xref-test


http://jira.codehaus.org/browse/MCHECKSTYLE-100

Title: Using includeTestSourceDirectory element truncates xref link to
production (non-test) classes

Thanks,
Dan


Subject:
Re: [m2] maven-checkstyle-plugin, v2.2 - includeTestSourceDirectory, xref
links broken
From:
Dennis Lundberg [EMAIL PROTECTED]
Date:
Thu, 31 Jul 2008 21:08:42 +0200
To:
Maven Users List users@maven.apache.org

Hi Dan

Please file these as 2 different issues for the Checkstyle Plugin:

http://jira.codehaus.org/browse/MCHECKSTYLE

Please include a complete pom.xml for each one, as it helps us to debug that
particular issue.

Dan Rollo wrote:
 I have configured the reporting section of my pom.xml to include the jxr
 report AND the checkstyle report (with the includeTestSourceDirectory
 element) as shown below:

 !-- generates a cross-reference of the project's sources --
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-jxr-plugin/artifactId
 version2.1/version
 /plugin

 !-- generates report regarding the code style --
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-checkstyle-plugin/artifactId
 version2.2/version
 configuration
 !-- based on config/sun_checks.xml, but also checks
for
 headers in source files --

 configLocationconfig/jdbc4olap_checks.xml/configLocation

 includeTestSourceDirectorytrue/includeTestSourceDirectory
 /configuration
 /plugin


 I'm seeing the problems below:

 1. The xref link to the Source pages in the checkstyle report page is
 broken. The source xref link for Unit Test Source files is not using the
 default value of the destDir for jxr test sources. From the jxr plugin
docs
 for jxr:test-jxr:

 destDir

 Folder where the Xref files will be copied to.

 * Type: java.lang.String
 * Required: No
 * Expression: ${project.reporting.outputDirectory}/xref-test

 I think the checkstyle plugin should:
 - assume the default dir for jxr:test-jxr
 - provide it's own additional override setting (similar to
xrefLocation,
 but for test sources). like: testXrefLocation.

 2. When I include the includeTestSourceDirectory element, the source
xref
 link for production (non-test) classes has a mangled URL: the first
letter
 of the package is ommitted in the link:

file:///.../jdbc4olap/target/site/xref/org/jdbc4olap/xmla/XmlaProperties.html#10
   missing o or org

file:///.../jdbc4olap/target/site/xref/rg/jdbc4olap/xmla/XmlaProperties.html#10

 If I remove the includeTestSourceDirectory element, the xref links to
 production sources are fine.

 [BTW, there is a LICENSE.txt file at the root of my project (in case
anyone
 thought a missing default header file would affect this), and the
checkstyle
 report properly flags missing headers.]

 I searched for prior posts and jira issues about this, but found none. Is
 this a known issue? Should I file a jira? Any ideas on a workaround that
 would allow me to both includeTestSourceDirectory AND link to sources?

 Thanks,
 Dan



-- 
Dennis Lundberg


Re: nexus unable to download artifacts

2008-07-31 Thread Brian E. Fox
Hard to say. What things are missing? Are they snapshots, plugins, other?


On 7/31/08 4:46 AM, freak182 [EMAIL PROTECTED] wrote:

 
 
 Hello,
 I install sonatype nexus as repo manager.I configure maven settings xml as
 describe in the tutorial. But when i simply run mvn clean with empty local
 repository nexus doesn't download necessesary artifacts. Did i missed
 something on my configuration?
 
 Thanks a lot.
 Cheers.
 --
 View this message in context:
 http://www.nabble.com/nexus-unable-to-download-artifacts-tp18750225p18750225.h
 tml
 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: Release Plugin - Resolving Snapshot Dependencies

2008-07-31 Thread Geoffrey Wiseman
On Thu, Jul 31, 2008 at 7:11 PM, Craig [EMAIL PROTECTED] wrote:

 Geoffrey,

 Could it be this bug http://jira.codehaus.org/browse/MRELEASE-350 ?

 Try choosing option '1' instead of option '0'.

 regards,
 Craig


I'm fairly certain I tried 1 as well, but without having done so in the last
12 hours, i'm not sure.  ;)  I'll try that next time, see if it helps.
-- 
Geoffrey Wiseman


Re: nexus unable to download artifacts

2008-07-31 Thread freak182

Hello,

here is the scenario to make it more clear:

1. a fresh install apache maven and set the mirror to internal repo to nexus
 (nexus is also fresh install and configured to point to maven central repo)

2. get a existing maven project and run mvn eclipse:eclipse

Thanks a lot.
Cheers.

 


Brian E Fox wrote:
 
 Hard to say. What things are missing? Are they snapshots, plugins, other?
 
 
 On 7/31/08 4:46 AM, freak182 [EMAIL PROTECTED] wrote:
 
 
 
 Hello,
 I install sonatype nexus as repo manager.I configure maven settings xml
 as
 describe in the tutorial. But when i simply run mvn clean with empty
 local
 repository nexus doesn't download necessesary artifacts. Did i missed
 something on my configuration?
 
 Thanks a lot.
 Cheers.
 --
 View this message in context:
 http://www.nabble.com/nexus-unable-to-download-artifacts-tp18750225p18750225.h
 tml
 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/nexus-unable-to-download-artifacts-tp18750225p18767942.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: Maven Presentation

2008-07-31 Thread Jason van Zyl
Ping me offline and you can have one of the 12 Maven presentations  
I've given over the years as a starting point.


On 31-Jul-08, at 4:08 PM, Chris Pall wrote:

I'll be giving a Maven presentation in the next couple of months,  
and wanted
to know if anyone had any good resources on this sort of thing. I  
want to

highlight how Maven is significantly better than what we are currently
doing, which is relatively typical: ant scripts with custom deploy  
systems
(to push configurations). What are the biggest points that make  
using maven
better, I've read the What is Maven? page, and I've got the five  
main

bullet points. Should I just stick to those?

A google search brings up the following:

http://wiki.wsmoak.net/cgi-bin/wiki.pl?Maven/Presentation

Which suggests that if we've got a working ant build, there's no  
real point
to using maven, which surprised me, cause the maven documentation  
suggests
that Maven is more than a build system. How do I really make the  
case that

it does more than this?


-- cgp


Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.

-- Eric Hoffer, Reflections on the Human Condition


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