date:20101110

I don't think thats the same thing. The proposal is to take a snapshot artifact 
which was built using mvn deploy and promote it to the release repo. I think 
what you are referring to here Jason is how the release plugin first builds the 
snapshot, tags it, and then rebuilds the tag.

 -Original Message-
 From: Jason van Zyl [mailto:ja...@maven.org]
 Sent: Wednesday, November 10, 2010 5:44 AM
 To: Maven Users List
 Subject: Re: Continuous Delivery and Maven

 On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Todd) wrote:

  +1 here. Jez was indicating that it was Crucial that a snapshot build
 not get rebuilt when creating the release and simply get promoted to a
 release. That is simply not that way maven currently works. I hope that
 is now clear.

 Has nothing to do with Maven per se, this is just the way the Maven
 Release Plugin works. It doesn't mean it's the only way it can work. I
 know lots of of people who have re-implmented all or parts of the release
 plugin to prevent rebuilding.

  I do like the idea though of rebuilting a CD build after a successful
 CI build. I think that has potential.

  -Original Message-
  From: stug23 [mailto:pat.poden...@gmail.com]
  Sent: Monday, November 08, 2010 2:21 PM
  To: users@maven.apache.org
  Subject: Re: Continuous Delivery and Maven

  We need to figure out how to best leverage Maven (keeping in mind its
  process
  and practices) in a Continuous Delivery solution. I like the
 conversation
  around this topic and also see that there is this other discussion
 about
  the
  meaning of CD versus CI.

  From the comments so far, there has been a fair amount of discussion
  about
  how to use SNAPSHOTs as if they were something that they aren't.
 Namely
  retaining SNAPSHOTs all the way through release, possibly mutating the
  metadata to make the builds products look like released artifacts
 instead
  of
  SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT
 works
  well for a work in progress and not for a thing I want to keep,
 maybe
  a
  different approach would work better.

  Maybe it would make more sense to just burn lots of version numbers
 (e.g,
  3.5.1099) and always release with a new yet-to-be-defined Maven
 release
  plugin that reflects the processes involved with CD. If the concern is
  disk
  usage or inefficiency, perhaps some automation can make this more
  manageable?

  I would be interested in inputs on this topic from the Maven founders
 if
  they are following this thread.
  --
  View this message in context:
  http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
  tp3245370p3255592.html
  Sent from the Maven - Users mailing list archive at Nabble.com.

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

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

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 What matters is not ideas, but the people who have them. Good people can
 fix bad ideas, but good ideas can't save bad people.

  -- Paul Graham

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

Re: maven site broken on table generation

2010-11-10 Thread Lukas Theussl



There are 2 issues here: the one that Dennis pointed out that the last 
line of the table has to match the first; the other that you can't have 
all cells in all rows empty. Just add at least one row with at least one 
non-empty cell to make it work.


Since you say that this used to work, it would help to know in which 
version the regression happened, I have tried with 2.0 site plugin (you 
also have to downgrade the project-info-report-plugin then to avoid the 
ArrayIndexOutOfBounds) and got the same exception.


HTH,
-Lukas


On 11/10/2010 07:33 AM, Dennis Lundberg wrote:

On 2010-11-09 22:25, Huang, Thomas (388J) wrote:

Hi,

I am using Maven 2.2.1 and mave-site-plugin 2.1.1.  When I run 'maven site', it 
gives me an error on parsing my APT file on table generation.  It is stopped on 
the first line where I defined the table with

*--++   +
|
*--
...


I ran into a similar issue about a week ago. The problem was that some
rows in the table didn't have enough rows in it. It was not the lines of
data in the APT file, but rather the formatting rows that contained the
error.

*-+---+--+
| {{{./jboss-packaging-maven-plugin/}jboss-packaging}} | 2.1.1 |
*-+--+

The last line above needed to be replace with this one (notice the added
+ character)

*-+---+--+


See this URL (which seems to currently be down) for what I did to fix it:
http://fisheye.codehaus.org/changelog/mojo/?cs=12955



This used to worked and no change was made to my APT file.  I have tried older 
versions of the plugin.  The 2.1 plugin emit the same error.  All 2.0.x plugins 
emil an arrayoutofbound exception.  This is blocking my site deploy.  Please 
advice.


Thomas.

Re: RE: Continuous Delivery and Maven

2010-11-10 Thread Stephen Connolly

Imho taking a snapshot artefact and renaming as a release artefact and
pushing to the remote repo will never be supported by maven, but my
ship-maven-plugin (not ready for publishing yet) and some extra mojos added
to versions-maven-plugin should enable CD in a way that is in keeping with
the maven way, as long as ranges are used in place of snapshots. (will
also need minor tweaks to the maven-release-plugin, but these would be
backwards compatible tweaks that do not change its current behaviour, only
provide a hook for extending it)

- Stephen

On 10 Nov 2010 13:03, Thiessen, Todd (Todd) tthies...@avaya.com wrote:

I don't think thats the same thing. The proposal is to take a snapshot
artifact which was built using mvn deploy and promote it to the release
repo. I think what you are referring to here Jason is how the release plugin
first builds the snapshot, tags it, and then rebuilds the tag.


 -Original Message-
 From: Jason van Zyl [mailto:ja...@maven.org]
 Sent: Wednesday, Nove...

 Subject: Re: Continuous Delivery and Maven


 On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Tod...

Re: Eclipse multi-module project with maven

2010-11-10 Thread Antonio Petrelli

2010/11/10 jeb001 jeremy.jar...@gmail.com:
 I've seen that I should use profiles et filters.. but I don't know exactly
 how, with my 4-part project?

 In which pom.xml have I to define thoses filters ? each one ?
 I'm not sure this is the best way to do it..

Yes, each one you have such configurable resources.
1. Just create all your profiles and, in each profile, put specific properties.
2. Replace all the addresses in your resources with ${...}
placeholders connected to the property you defined in your poms.
3. Instruct Maven to filter resources (filtering is off by default):

resources
resource
filteringtrue/filtering
directorysrc/main/resources/directory
/resource
/resources

As an option, you can think of *not* putting addresses in pom.xml, but
inside your settings.xml and activated by specific profiles.
However, take in consideration what I said before: leave this kind of
configuration on the server itself.

HTH
Antonio

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

Re: M3 fails to download parent pom

2010-11-10 Thread Stephen Connolly

How have you defined your corp maven repo in your settings.xml

I'm wondering if it's a bug in maven 2 pulling releases from the wrong repo
and therefore you don't notice that the repo is defined incorrectly in
settings.xml

On 10 Nov 2010 08:39, mjsell mjse...@gmail.com wrote:


Yeah, this is definitely not a pom that exists in the project tree, so the
parent-pom resolution changes mentioned in the compatibility notes do not
apply.  In my case it is a corporate pom that is separately released, and
all of our project trees end up inheriting from a previously released
version of it.  Maven 2.2.1 successfully pulls it down from the remote
repository, but Maven 3.0 does not.  If it is in the local repository
everything works fine, but if it needs to be retrieved from the remote
repository then it just fails without trying.  Interestingly, if I change it
to a snapshot version of the corporate pom, then Maven 3 appears to
correctly attempt to pull it from the remote repositories.  This definitely
sounds like a bug to me.
--
View this message in context:
http://maven.40175.n5.nabble.com/M3-fails-to-download-parent-pom-tp3240199p3258005.html

Sent from the Maven - Users mailing list archive at Nabble.com.

---...

Re: Continuous Delivery and Maven

2010-11-10 Thread Jason van Zyl


On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Todd) wrote:

 +1 here. Jez was indicating that it was Crucial that a snapshot build not 
 get rebuilt when creating the release and simply get promoted to a release. 
 That is simply not that way maven currently works. I hope that is now clear.
 

Has nothing to do with Maven per se, this is just the way the Maven Release 
Plugin works. It doesn't mean it's the only way it can work. I know lots of of 
people who have re-implmented all or parts of the release plugin to prevent 
rebuilding.

 I do like the idea though of rebuilting a CD build after a successful CI 
 build. I think that has potential.
 
 -Original Message-
 From: stug23 [mailto:pat.poden...@gmail.com]
 Sent: Monday, November 08, 2010 2:21 PM
 To: users@maven.apache.org
 Subject: Re: Continuous Delivery and Maven
 
 
 We need to figure out how to best leverage Maven (keeping in mind its
 process
 and practices) in a Continuous Delivery solution. I like the conversation
 around this topic and also see that there is this other discussion about
 the
 meaning of CD versus CI.
 
 From the comments so far, there has been a fair amount of discussion
 about
 how to use SNAPSHOTs as if they were something that they aren't. Namely
 retaining SNAPSHOTs all the way through release, possibly mutating the
 metadata to make the builds products look like released artifacts instead
 of
 SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT works
 well for a work in progress and not for a thing I want to keep, maybe
 a
 different approach would work better.
 
 Maybe it would make more sense to just burn lots of version numbers (e.g,
 3.5.1099) and always release with a new yet-to-be-defined Maven release
 plugin that reflects the processes involved with CD. If the concern is
 disk
 usage or inefficiency, perhaps some automation can make this more
 manageable?
 
 I would be interested in inputs on this topic from the Maven founders if
 they are following this thread.
 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
 tp3245370p3255592.html
 Sent from the Maven - Users mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

What matters is not ideas, but the people who have them. Good people can fix 
bad ideas, but good ideas can't save bad people. 

 -- Paul Graham

Re: M3 fails to download parent pom

2010-11-10 Thread Martijn Dashorst

Here's the contents of settings.xml relevant to our repo manager:

mirrors
mirror
idour-repository/id
nameMaven Repository Manager running on 
corp.com/name
urlhttp://repo.corp.com/artifactory/repo/url
mirrorOf*/mirrorOf
/mirror
/mirrors

Martijn

On Wed, Nov 10, 2010 at 2:33 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 How have you defined your corp maven repo in your settings.xml

 I'm wondering if it's a bug in maven 2 pulling releases from the wrong repo
 and therefore you don't notice that the repo is defined incorrectly in
 settings.xml

 On 10 Nov 2010 08:39, mjsell mjse...@gmail.com wrote:


 Yeah, this is definitely not a pom that exists in the project tree, so the
 parent-pom resolution changes mentioned in the compatibility notes do not
 apply.  In my case it is a corporate pom that is separately released, and
 all of our project trees end up inheriting from a previously released
 version of it.  Maven 2.2.1 successfully pulls it down from the remote
 repository, but Maven 3.0 does not.  If it is in the local repository
 everything works fine, but if it needs to be retrieved from the remote
 repository then it just fails without trying.  Interestingly, if I change it
 to a snapshot version of the corporate pom, then Maven 3 appears to
 correctly attempt to pull it from the remote repositories.  This definitely
 sounds like a bug to me.
 --
 View this message in context:
 http://maven.40175.n5.nabble.com/M3-fails-to-download-parent-pom-tp3240199p3258005.html

 Sent from the Maven - Users mailing list archive at Nabble.com.

 ---...




-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

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

RE: RE: Continuous Delivery and Maven

Agreed Stephen. I think your proposal is the best so far. I just want to make 
sure we don't go back into a discussion about promoting snapshots to releases, 
as I believe that is where this discussion started.  To do that I think would 
require a significant re-architecture of maven which I don't think would be 
happening in the near future.

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Wednesday, November 10, 2010 8:29 AM
 To: Maven Users List
 Subject: Re: RE: Continuous Delivery and Maven

 Imho taking a snapshot artefact and renaming as a release artefact and
 pushing to the remote repo will never be supported by maven, but my
 ship-maven-plugin (not ready for publishing yet) and some extra mojos
 added
 to versions-maven-plugin should enable CD in a way that is in keeping
 with
 the maven way, as long as ranges are used in place of snapshots. (will
 also need minor tweaks to the maven-release-plugin, but these would be
 backwards compatible tweaks that do not change its current behaviour,
 only
 provide a hook for extending it)

 - Stephen

 On 10 Nov 2010 13:03, Thiessen, Todd (Todd) tthies...@avaya.com
 wrote:

 I don't think thats the same thing. The proposal is to take a snapshot
 artifact which was built using mvn deploy and promote it to the release
 repo. I think what you are referring to here Jason is how the release
 plugin
 first builds the snapshot, tags it, and then rebuilds the tag.

  -Original Message-
  From: Jason van Zyl [mailto:ja...@maven.org]
  Sent: Wednesday, Nove...

  Subject: Re: Continuous Delivery and Maven

  On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Tod...

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

Using Tomcat plugin to run webapp in a production environment

2010-11-10 Thread Bruno Borges

Have anyone experienced running a WAR project in production based on the
Maven Tomcat plugin?

We are considering to use it as we think it is simpler than installing a
whole Tomcat setup and deploying WAR files . Our usecase has only one
project and no more modules are planned. Each one on its own VM at Amazon
EC2.

All the configuration can be passed on to the Tomcat Plugin through
server.xml and context.xml.

Any feedback, comments or critics are welcome.

Best regards,
Bruno Borges
www.brunoborges.com.br
+55 21 76727099

The glory of great men should always be
measured by the means they have used to
acquire it.
 - Francois de La Rochefoucauld

Error building bin assembly

2010-11-10 Thread Jason Voegele

I am trying to use the pre-defined bin assembly descriptor (descriptorRef) 
and I am getting an error stating that A tar file cannot include itself.  
I've included a full stack trace below.  Does anyone know what might be wrong?  
Is there any other information I should include to help diagnose?  Thanks.

[INFO] Building tar : 
/Users/jvoegele/projects/terracotta/forge/sparse/tc-maven-plugin/tags/release-1.6.1/target/site/downloads/tc-maven-plugin-1.6.1-bin.tar.gz
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 18.239s
[INFO] Finished at: Wed Nov 10 09:37:36 EST 2010
[INFO] Final Memory: 33M/81M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:2.2:assembly (downloads) on 
project tc-maven-plugin: Failed to create assembly: Error creating assembly 
archive bin: A tar file cannot include itself. - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:2.2:assembly (downloads) on 
project tc-maven-plugin: Failed to create assembly: Error creating assembly 
archive bin: A tar file cannot include itself.
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create 
assembly: Error creating assembly archive bin: A tar file cannot include itself.
at 
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:468)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
... 19 more
Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: 
Error creating assembly archive bin: A tar file cannot include itself.
at 
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:196)
at 
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:409)
... 21 more
Caused by: org.codehaus.plexus.archiver.ArchiverException: A tar file cannot 
include itself.
at 
org.codehaus.plexus.archiver.tar.TarArchiver.execute(TarArchiver.java:202)
at 
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:871)
at 
org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:512)
at 
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:192)
... 22 more
[ERROR] 
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException


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

Re: Maven integration with bash script

2010-11-10 Thread Jacob Beard

The exec-maven-plugin turned out to be a good solution. Now the shell
script simply delegates to maven:

mvn -q exec:java -DscxmlInputArgs=$*

And the .bat script is virtually the same thing. Very clean and simple,
I think.

Thanks for your help with this,

Jake

On 10-11-09 02:25 PM, Benjamin Bentmann wrote:

Jacob Beard wrote:

With maven, however, the libraries are now kept in the location of the
maven repository, several directories deep, based on information kept in
the pom.xml file. I'd like to know, is there a maven solution for
extracting a particular classpath from a maven file, such that the
classpath can be used from a shell script? If not, is there at least a
reliable way of determining the location of the maven repository on
Windows and Unix platforms?

The structure of the local repository should be considered an
implementation detail and hard-coding paths to its contents should be
avoided.

[0] and related goals from the maven-dependency-plugin can be used to
create a lib directory of user-specified structure.

Maybe usage of the exec-maven-plugin [1] might be able to replace your
shell script completely.

Benjamin

[0]
http://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-project-dependencies.html

[1] http://mojo.codehaus.org/exec-maven-plugin/

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

Re: Using Tomcat plugin to run webapp in a production environment

2010-11-10 Thread Aldrin Leal

I ended up using Cargo for that. In my particular case, all I did was to
create a tomcat6 instance (via Ubuntu built-in package) and add the admin
webapp

IMMV however

--
-- Aldrin Leal, ald...@leal.eng.br / http://www.leal.eng.br/mnemetica/


On Wed, Nov 10, 2010 at 10:33 AM, Bruno Borges bruno.bor...@gmail.comwrote:

 Have anyone experienced running a WAR project in production based on the
 Maven Tomcat plugin?

 We are considering to use it as we think it is simpler than installing a
 whole Tomcat setup and deploying WAR files . Our usecase has only one
 project and no more modules are planned. Each one on its own VM at Amazon
 EC2.

 All the configuration can be passed on to the Tomcat Plugin through
 server.xml and context.xml.

 Any feedback, comments or critics are welcome.

 Best regards,
 Bruno Borges
 www.brunoborges.com.br
 +55 21 76727099

 The glory of great men should always be
 measured by the means they have used to
 acquire it.
  - Francois de La Rochefoucauld

Re: Possible to override standard Plexus component from build extension?

2010-11-10 Thread Jesse Glick


On 11/09/2010 06:43 PM, Benjamin Bentmann wrote:

Not possible.


Thanks, at least I will not waste more time trying.


usually accomplished by an artifact
handler for the dependency type in question which sets
includesDependencies=true like for WAR artifacts.


Interesting, did not think to look there. (Typically, there is no Javadoc on 
ArtifactHandler explaining what it does.) In my case this is already set to 
true:

component
  roleorg.apache.maven.artifact.handler.ArtifactHandler/role
  role-hintnbm/role-hint
  
implementationorg.apache.maven.artifact.handler.DefaultArtifactHandler/implementation
  configuration
typenbm/type
extensionjar/extension
packagingnbm/packaging
addedToClasspathtrue/addedToClasspath
languagejava/language
includesDependenciestrue/includesDependencies
  /configuration
/component

yet dependencies on this kind of artifact are still resolved transitively. (There is also a handler for extension nbm, which a separate mojo uses via attachArtifact, but 
these artifacts are not added to the classpath.)


Really I would prefer to override the ProjectDependenciesResolver in the _depending_ project (with packaging nbm), so that it does not traverse the graph for dependencies 
of type nbm in compile scope; it is fine for dependencies on nbm-packaged JARs to be transitive when used from a jar-packaging project. Dependencies of type jar should be 
transitive, and test-scope dependencies must be transitive even when of type nbm (*).


(*) Since Maven fails to properly distinguish between test compile and test runtime scope and this is only possible via hacky configuration in the Surefire plugin. 
Ideally tests would compile against compile  test scopes, and run against compile  runtime  test  test-runtime scopes. Including full transitive dependencies in the 
test compile classpath might seem harmless enough, but it can apparently make compilation vastly slower on Windows when the dependency graph is big.



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

Re: Surefire NPE

2010-11-10 Thread Cameron


I've tried hard coding the resource bundle path and I get the same result. 
And it only happens about half the time, regardless.

Judging by the stack trace, the problem is somehow related to what happens
when Surefire forks so that the tests run in their own JVM process.  When I
set forkMode to never, I don't get the error any more but several of my
tests fail because they require their own process.

Let me know if anyone has any other ideas.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Surefire-NPE-tp3246444p3258956.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: RE: Continuous Delivery and Maven

2010-11-10 Thread jhumble

Hey Todd.

My interpretation of what Jason is saying in his comment here -
http://www.lucasward.net/2010/11/maven-and-continuous-delivery.html - you
should be able to tag the code, and pluck the snapshot out and promote it to
a release repository... Someone just needs to do the two weeks of work to
add the tooling. is that this is exactly what he's saying. I'm going to
have a nose around the code and see if I think I can take a shot at it.

Thanks,

Jez.

On 10 November 2010 05:51, Thiessen, Todd (Todd) [via Maven]
ml-node+3258691-1180604705-143...@n5.nabble.comml-node%2b3258691-1180604705-143...@n5.nabble.com
wrote:

Agreed Stephen. I think your proposal is the best so far. I just want to
make sure we don't go back into a discussion about promoting snapshots to
releases, as I believe that is where this discussion started. To do that I
think would require a significant re-architecture of maven which I don't
think would be happening in the near future.

-Original Message-
From: Stephen Connolly [mailto:[hidden
email]http://user/SendEmail.jtp?type=nodenode=3258691i=0]

Sent: Wednesday, November 10, 2010 8:29 AM
To: Maven Users List
Subject: Re: RE: Continuous Delivery and Maven

Imho taking a snapshot artefact and renaming as a release artefact and
pushing to the remote repo will never be supported by maven, but my
ship-maven-plugin (not ready for publishing yet) and some extra mojos
added
to versions-maven-plugin should enable CD in a way that is in keeping
with
the maven way, as long as ranges are used in place of snapshots. (will
also need minor tweaks to the maven-release-plugin, but these would be
backwards compatible tweaks that do not change its current behaviour,
only
provide a hook for extending it)

- Stephen

On 10 Nov 2010 13:03, Thiessen, Todd (Todd) [hidden
email]http://user/SendEmail.jtp?type=nodenode=3258691i=1

wrote:

I don't think thats the same thing. The proposal is to take a snapshot
artifact which was built using mvn deploy and promote it to the release
repo. I think what you are referring to here Jason is how the release
plugin
first builds the snapshot, tags it, and then rebuilds the tag.

-Original Message-
From: Jason van Zyl [mailto:[hidden
email]http://user/SendEmail.jtp?type=nodenode=3258691i=2]

Sent: Wednesday, Nove...

Subject: Re: Continuous Delivery and Maven

On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Tod...

-
To unsubscribe, e-mail: [hidden
email]http://user/SendEmail.jtp?type=nodenode=3258691i=3
For additional commands, e-mail: [hidden
email]http://user/SendEmail.jtp?type=nodenode=3258691i=4

--
View message @
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3258691.html
To unsubscribe from Continuous Delivery and Maven, click
herehttp://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=3245370code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4MjM1NzMyNA==.

--
Jez Humble
Co-author, *Continuous Delivery http://continuousdelivery.com/*
http://continuousdelivery.com/
http://jezhumble.net/

--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259078.html
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: RE: Continuous Delivery and Maven

2010-11-10 Thread jhumble

BTW - I also think Stephen's suggestion is a good one - it's more or less
what I suggest in the book.

On 10 November 2010 09:45, Jez Humble j...@jezhumble.net wrote:

Hey Todd.

Thanks,

Jez.

On 10 November 2010 05:51, Thiessen, Todd (Todd) [via Maven]
ml-node+3258691-1180604705-143...@n5.nabble.comml-node%2b3258691-1180604705-143...@n5.nabble.com
wrote:

-Original Message-
From: Stephen Connolly [mailto:[hidden
email]http://user/SendEmail.jtp?type=nodenode=3258691i=0]

Sent: Wednesday, November 10, 2010 8:29 AM
To: Maven Users List
Subject: Re: RE: Continuous Delivery and Maven

also need minor tweaks to the maven-release-plugin, but these would be
backwards compatible tweaks that do not change its current behaviour,
only
provide a hook for extending it)

- Stephen

On 10 Nov 2010 13:03, Thiessen, Todd (Todd) [hidden
email]http://user/SendEmail.jtp?type=nodenode=3258691i=1

wrote:

-Original Message-
From: Jason van Zyl [mailto:[hidden
email]http://user/SendEmail.jtp?type=nodenode=3258691i=2]

Sent: Wednesday, Nove...

Subject: Re: Continuous Delivery and Maven

On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Tod...

-
To unsubscribe, e-mail: [hidden
email]http://user/SendEmail.jtp?type=nodenode=3258691i=3
For additional commands, e-mail: [hidden
email]http://user/SendEmail.jtp?type=nodenode=3258691i=4

--
Jez Humble
Co-author, *Continuous Delivery http://continuousdelivery.com/*
http://continuousdelivery.com/
http://jezhumble.net/

--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259081.html
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: Running tests twice and the build success status

2010-11-10 Thread Bogdan Calmac


OK, I've done some further investigation and discovered that this only
happens on our Hudson CI server. The cmdline maven build works as expected.

For reference, here is the JIRA for the Hudson project:
http://issues.hudson-ci.org/browse/HUDSON-8065
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Running-tests-twice-and-the-build-success-status-tp3257693p3259119.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: Continuous Delivery and Maven



stephenconnolly wrote:
 
 
 dependency
   groupIdfoo/groupId
   artifactIdbar/artifactId
   version[1.0,2.0)/version
 /dependency
 
 

This seems to me to a place where the Maven concept of
versionLATEST/version actually makes sense to use. If we add around this
your concept of writting the concreate version and checking-in, it ott work
nicely. With this approach you do not need to keep the meta data of what was
there previously (although I can see the benefit of supporting the ranges).

In a CD environment I'd imagine most of the time you would wnat to be
working against the latest released version of all your dependencies.

If one wanted to control versions of 3rd party stuff you coul duse your
repository manager to lock things down.


-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259183.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: Error building bin assembly

 full stack trace below.  Does anyone know what might be wrong?  Is there any
 other information I should include to help diagnose?  Thanks.

It might be helpful to send your configuration as well...

Wayne

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

RE: RE: Continuous Delivery and Maven

I am not entirely sure what Jason means when he says pluck the snapshot out 
and promote it to a release repository. I think he still means rebuild it from 
source but I agree that that statement is a bit unclear.

The release plugin, by default, builds twice. First it checks out the code as a 
snapshot. Then it creates the tag, checks out the tag and then rebuilds and 
deploys that. This is the final released artifact.

As Jason mentioned, a lot of people don't want the release process to build 
twice. So they skip the initial build of the snapshot and skip directly to the 
building of the tag and the release. If you could somehow identify the revison 
of what snapshot you wanted, you could check out and rebuild that as a release. 
I think this is what Jason means by plucking but he would have confirm that.

This isn't a promotion of the snapshot per ce. It still completely rebuilds 
the artifact from source. It just doesn't rebuild it twice.

But this is also I think different from what Stephen is proposing. I think what 
you are looking for is to skip, or at least ignore, the building of snapshots 
entirely. So with Stephen's idea, by adding a ship phase to the lifecycle, 
you would always be doing some kind of command like:

mvn ship

You would bind a modified release plugin to this phase to always build a 
release. You may want to even consider overriding the deploy phase to do 
nothing, or even overriding the deploy phase to ship and not even worry about 
adding a ship phase to the lifecycle.

What is missing, that you were asking for, is being able to use snapshot 
dependencies that are not in the reactor. Stephen was thinking that this wasn't 
very important, but I was under the impression that you felt it was.

I also read through the blog. I tend to agree that the release process of Maven 
is a bit more complicated than it needs to be. There is a strict seperation 
between snapshots and releases which I think is the primary cause. There are 
likely reasons for it and I would love for a guy like Jason van Zyl (the Maven 
founder) to provide some insight or history here. Or even another comment on 
the blog you linked. For example elaborate on the comment:

I believe the separation of snapshot and release repositories are required

From my understanding, to really embrace CD, there would have to be no 
difference between a snapshot and a release.

 -Original Message-
 From: jhumble [mailto:j...@jezhumble.net]
 Sent: Wednesday, November 10, 2010 12:47 PM
 To: users@maven.apache.org
 Subject: Re: RE: Continuous Delivery and Maven
 
 
 Hey Todd.
 
 My interpretation of what Jason is saying in his comment here -
 http://www.lucasward.net/2010/11/maven-and-continuous-delivery.html -
 you
 should be able to tag the code, and pluck the snapshot out and promote it
 to
 a release repository... Someone just needs to do the two weeks of work to
 add the tooling. is that this is exactly what he's saying. I'm going to
 have a nose around the code and see if I think I can take a shot at it.
 
 Thanks,
 
 Jez.
 
 On 10 November 2010 05:51, Thiessen, Todd (Todd) [via Maven] 
 ml-node+3258691-1180604705-143...@n5.nabble.comml-node%2B3258691-
 1180604705-143...@n5.nabble.com
  wrote:
 
  Agreed Stephen. I think your proposal is the best so far. I just want
 to
  make sure we don't go back into a discussion about promoting snapshots
 to
  releases, as I believe that is where this discussion started.  To do
 that I
  think would require a significant re-architecture of maven which I
 don't
  think would be happening in the near future.
 
   -Original Message-
   From: Stephen Connolly [mailto:[hidden
 email]http://user/SendEmail.jtp?type=nodenode=3258691i=0]
 
   Sent: Wednesday, November 10, 2010 8:29 AM
   To: Maven Users List
   Subject: Re: RE: Continuous Delivery and Maven
  
   Imho taking a snapshot artefact and renaming as a release artefact
 and
   pushing to the remote repo will never be supported by maven, but my
   ship-maven-plugin (not ready for publishing yet) and some extra mojos
   added
   to versions-maven-plugin should enable CD in a way that is in keeping
   with
   the maven way, as long as ranges are used in place of snapshots.
 (will
   also need minor tweaks to the maven-release-plugin, but these would
 be
   backwards compatible tweaks that do not change its current behaviour,
   only
   provide a hook for extending it)
  
   - Stephen
  
   On 10 Nov 2010 13:03, Thiessen, Todd (Todd) [hidden
 email]http://user/SendEmail.jtp?type=nodenode=3258691i=1
 
   wrote:
  
   I don't think thats the same thing. The proposal is to take a
 snapshot
   artifact which was built using mvn deploy and promote it to the
 release
   repo. I think what you are referring to here Jason is how the release
   plugin
   first builds the snapshot, tags it, and then rebuilds the tag.
  
  
-Original Message-
From: Jason van Zyl [mailto:[hidden

RE: Continuous Delivery and Maven

Is LATEST deprecate now?

But if I recall correctly, I don't think it would be quite right either as 
LATEST implies the latest release or snapshot. So you'll want to be careful 
here.

 -Original Message-
 From: jmorrow [mailto:j...@morrowmail.com]
 Sent: Wednesday, November 10, 2010 1:33 PM
 To: users@maven.apache.org
 Subject: Re: Continuous Delivery and Maven

 stephenconnolly wrote:

  dependency
groupIdfoo/groupId
artifactIdbar/artifactId
version[1.0,2.0)/version
  /dependency

 This seems to me to a place where the Maven concept of
 versionLATEST/version actually makes sense to use. If we add around
 this
 your concept of writting the concreate version and checking-in, it ott
 work
 nicely. With this approach you do not need to keep the meta data of what
 was
 there previously (although I can see the benefit of supporting the
 ranges).

 In a CD environment I'd imagine most of the time you would wnat to be
 working against the latest released version of all your dependencies.

 If one wanted to control versions of 3rd party stuff you coul duse your
 repository manager to lock things down.

 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
 tp3245370p3259183.html
 Sent from the Maven - Users mailing list archive at Nabble.com.

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

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

RE: Continuous Delivery and Maven

And you're right. You could probably use version ranges for this as Stephen was 
saying. Then you wouldn't use snapshot deps at all. All projects would simply 
use the mvn ship command instead of mvn deploy and never work with snapshots.

Make it so ;-). I'd love to see what you have 2 weeks ;-).

 -Original Message-
 From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com]
 Sent: Wednesday, November 10, 2010 2:24 PM
 To: Maven Users List
 Subject: RE: Continuous Delivery and Maven

 Is LATEST deprecate now?

 But if I recall correctly, I don't think it would be quite right either
 as LATEST implies the latest release or snapshot. So you'll want to be
 careful here.

  -Original Message-
  From: jmorrow [mailto:j...@morrowmail.com]
  Sent: Wednesday, November 10, 2010 1:33 PM
  To: users@maven.apache.org
  Subject: Re: Continuous Delivery and Maven

  stephenconnolly wrote:

   dependency
 groupIdfoo/groupId
 artifactIdbar/artifactId
 version[1.0,2.0)/version
   /dependency

  This seems to me to a place where the Maven concept of
  versionLATEST/version actually makes sense to use. If we add around
  this
  your concept of writting the concreate version and checking-in, it ott
  work
  nicely. With this approach you do not need to keep the meta data of
 what
  was
  there previously (although I can see the benefit of supporting the
  ranges).

  In a CD environment I'd imagine most of the time you would wnat to be
  working against the latest released version of all your dependencies.

  If one wanted to control versions of 3rd party stuff you coul duse your
  repository manager to lock things down.

  --
  View this message in context:
  http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
  tp3245370p3259183.html
  Sent from the Maven - Users mailing list archive at Nabble.com.

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

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

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

RE: Continuous Delivery and Maven

Thiessen, Todd (Todd) wrote:

Is LATEST deprecate now?

But if I recall correctly, I don't think it would be quite right either as
LATEST implies the latest release or snapshot. So you'll want to be
careful here.

https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-PluginMetaversionResolution

You are correct it is depricated as of 3.x. It has generally been thought of
as bad practice to use latest as you never really knew what version you were
dependent on and for non-CD approaches this makes complete sense. In CD I
think it embodies exactly what you do want, the latest code that has passed
a certain phase of the pipeline.

RELEASE would probably be better, but alas it is depricated as well.

I think it is unfortunate that this was removed from Maven 3 as it was
valuable in certain circumstances and now that CD is hitting the big time it
would be useful.

I don't like the idea of specifying the top end of the version range becasue
I am not in control of when the team I am dependent on updates their major
version number. I might not catch the change and continue development
against old versions, this would effectively render my CI environment
useless.

--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259341.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

RE: Continuous Delivery and Maven

I don't think you need to specify a top end. For example, you could use [1.0,).

http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-version-ranges.html

-Original Message-
From: jmorrow [mailto:j...@morrowmail.com]
Sent: Wednesday, November 10, 2010 2:51 PM
To: users@maven.apache.org
Subject: RE: Continuous Delivery and Maven

Thiessen, Todd (Todd) wrote:

Is LATEST deprecate now?

But if I recall correctly, I don't think it would be quite right either
as
LATEST implies the latest release or snapshot. So you'll want to be
careful here.

https://cwiki.apache.org/MAVEN/maven-3x-compatibility-
notes.html#Maven3.xCompatibilityNotes-PluginMetaversionResolution

You are correct it is depricated as of 3.x. It has generally been thought
of
as bad practice to use latest as you never really knew what version you
were
dependent on and for non-CD approaches this makes complete sense. In CD I
think it embodies exactly what you do want, the latest code that has
passed
a certain phase of the pipeline.

RELEASE would probably be better, but alas it is depricated as well.

I think it is unfortunate that this was removed from Maven 3 as it was
valuable in certain circumstances and now that CD is hitting the big time
it
would be useful.

I don't like the idea of specifying the top end of the version range
becasue
I am not in control of when the team I am dependent on updates their
major
version number. I might not catch the change and continue development
against old versions, this would effectively render my CI environment
useless.

--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
tp3245370p3259341.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

RE: Continuous Delivery and Maven


 The dep ranges make more sense to me because they can equate to
feature/functionality sets and still enable parallel development for all
those non-CD shops ;-)  I'm sure there is no notion of parallel
development in CD since they eschew branches in favor of Bliki feature
toggles (which are pretty cool I must say). Non-CD shops can still
benefit from this since it would further minimize POM management which
everyone seems to abhor.




Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-Original Message-
From: jmorrow [mailto:j...@morrowmail.com] 
Sent: Wednesday, November 10, 2010 2:51 PM
To: users@maven.apache.org
Subject: RE: Continuous Delivery and Maven



Thiessen, Todd (Todd) wrote:
 
 Is LATEST deprecate now?
 
 But if I recall correctly, I don't think it would be quite right 
 either as LATEST implies the latest release or snapshot. So you'll 
 want to be careful here.
 

https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.
xCompatibilityNotes-PluginMetaversionResolution

You are correct it is depricated as of 3.x. It has generally been
thought of as bad practice to use latest as you never really knew what
version you were dependent on and for non-CD approaches this makes
complete sense. In CD I think it embodies exactly what you do want, the
latest code that has passed a certain phase of the pipeline.

RELEASE would probably be better, but alas it is depricated as well.

I think it is unfortunate that this was removed from Maven 3 as it was
valuable in certain circumstances and now that CD is hitting the big
time it would be useful.

I don't like the idea of specifying the top end of the version range
becasue I am not in control of when the team I am dependent on updates
their major version number. I might not catch the change and continue
development against old versions, this would effectively render my CI
environment useless.




--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3259341.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


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

RE: Continuous Delivery and Maven

 Obviously there are times when that is the case but and others when the
boundary would be welcome.

-Original Message-
From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com] 
Sent: Wednesday, November 10, 2010 2:54 PM
To: Maven Users List
Subject: RE: Continuous Delivery and Maven

I don't think you need to specify a top end. For example, you could use
[1.0,).

http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-se
ct-version-ranges.html

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

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

Re: Error building bin assembly

2010-11-10 Thread Jason Voegele

Followup: I can reproduce this error with a very minimal project by using the 
maven-arcetype-plugin to create a simple project, and then adding the following 
plugin declaration to the POM:

  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.2/version
configuration
  descriptorRefs
descriptorRefsrc/descriptorRef
descriptorRefbin/descriptorRef
  /descriptorRefs
  
outputDirectory${project.build.directory}/site/downloads/outputDirectory
/configuration
executions
  execution
phasesite/phase
goals
  goalsingle/goal
/goals
  /execution
/executions
  /plugin

With this plugin declaration in place, I get the error when I execute either 
mvn assembly:single or mvn site.

Can anyone provide any clues?

Thanks


On Nov 10, 2010, at 10:02 AM, Jason Voegele wrote:
 I am trying to use the pre-defined bin assembly descriptor (descriptorRef) 
 and I am getting an error stating that A tar file cannot include itself.  
 I've included a full stack trace below.  Does anyone know what might be 
 wrong?  Is there any other information I should include to help diagnose?  
 Thanks.
 
 [INFO] Building tar : 
 /Users/jvoegele/projects/terracotta/forge/sparse/tc-maven-plugin/tags/release-1.6.1/target/site/downloads/tc-maven-plugin-1.6.1-bin.tar.gz
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 18.239s
 [INFO] Finished at: Wed Nov 10 09:37:36 EST 2010
 [INFO] Final Memory: 33M/81M
 [INFO] 
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.2:assembly (downloads) on 
 project tc-maven-plugin: Failed to create assembly: Error creating assembly 
 archive bin: A tar file cannot include itself. - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-assembly-plugin:2.2:assembly (downloads) 
 on project tc-maven-plugin: Failed to create assembly: Error creating 
 assembly archive bin: A tar file cannot include itself.
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151)
   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445)
   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:132)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create 
 assembly: Error creating assembly archive bin: A tar file cannot include 
 itself.
   at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:468)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
   ... 19 more
 Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: 
 Error creating assembly archive bin: A tar file cannot include itself.
   at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:196)
   at

Re: Continuous Delivery and Maven



stephenconnolly wrote:
 
 Well I regard that the project being delivered can only have internal
 -SNAPSHOT dependencies, all external (to the reactor) dependencies
 should be release dependencies.
 
 One of the things I have wanted to do with v-m-p is to hack around
 version ranges... for example...
 

Couldn't you use v-m-p to update the versions prior to running the release?
(Going down this road we would never have snapshot dependencies)
mvn versions:use-latest-versions release:prepare release:perform

or set it as a preparation goal.

This would update all versions to latest and checkin when done.

Developers could execute this prior to clean install to always be using the
latest stuff.

In fact you could also attach this to the validate phase so the goal does
not have to be specified.

-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259395.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

RE: Continuous Delivery and Maven


Certainly and I would promote that the solution using this mechanism should
allow a rang eto be specified. In a true CD shop though I think it would be
important the you could leave the upper bound off. It seems both are
supported so it is all good.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259400.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Figuring out the proper Maven dependency setting

2010-11-10 Thread marshall

Hi;
 This is probably a beginner question, but I thought it was worth posing 
because it is frequently very frustrating when working with Maven.
 Is there a clear way to know which particular dependencies Maven requires, 
when working with a set of jars/libraries?
 For example, I have been trying to get JPA and Hibernate configured properly 
in the pom.xml. I have tried so many different variations of dependencies 
(hibernate, hibernate-core, javax.persistence, JPA, MySQL, etc.) that I finally 
just threw up my hands in frustration.
I can get a Hibernate/JPA/MySQL application working just fine without Maven, 
but when I try to integrate Maven I'm lost as to which dependencies it needs. 
They seem to be different than the jars/libraries I specify in the classpath 
for a non-Maven build.
Thanks;
Mar

Re: Continuous Delivery and Maven



stephenconnolly wrote:
 
 so lets say for #1 we add a phase of ship... we'd have the standard
 lifecycle something like
 
 validate - ... - compile - ... - test - ... - package - ... -
 verify - install - deploy - ship
 
 that would allow us to bind our CD steps to the ship phase...
 

I'd be concerned about binding the CD steps to any phase in Maven. In my
mind a server deployment should happen by grabbing the deployable artifact
from your repository and sending it to the server. In CD we would need to
send the artifact to multiple servers through out the pipeline and
ultimately have a push-button deployment to production. CD is all about
making artifacts availible to be deployed not neccessarily forcing the
deployment. THis means we have to have a place where the latest blessed
version is staged and ready to go.

I see the Maven repo as an ideal place for this.

In our environment I feel the build build responsibility of maven ends
with an artifact being deployed/promoted in the repository. After that the
server deployment is triggered and picks up said artifact. I see many tools
as possible in this part of the process, most notably scripting or a
separate unique Maven invokation. I just think it is very important to
separate this phase/process from the build phase/process.

In many environments we'd also want to pull enviroment specific
configuration from a cmdb, add this to the deployable and then deploy. I
don't see how this could be easily accomodated if this is simply taked on to
the standard Maven life-cycle.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259411.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: Figuring out the proper Maven dependency setting


On Nov 10, 2010, at 3:40 PM, marshall wrote:

 Hi;
  This is probably a beginner question, but I thought it was worth posing 
 because it is frequently very frustrating when working with Maven.
  Is there a clear way to know which particular dependencies Maven requires, 
 when working with a set of jars/libraries?

This isn't as much a Maven question as it is a question on the organizations 
that package the dependencies, but here's some info.  Dependencies typically 
depend on other dependencies, and one eventually gets a transitive closure of 
dependencies.  You can see this in your build by running 'mvn dependency:tree'. 
This will show you a tree of who is pulling in what, and help make decisions on 
what to pull in at the top level and what you can ignore.

For instance, if you used to pull in asm for use with Hibernate, you can stop 
doing that, because the Hibernate dependency you choose will know better what 
exact version it was compiled at.  If you need a specific version of asm for 
your own needs, this is where things get more complicated.

These problems existed before Maven though.  Maven just gives you a bigger, 
more efficient gun to shoot yourself in the foot with.

Hope that helps...


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

RE: Figuring out the proper Maven dependency setting

+1

 -Original Message-
 From: Brian Topping [mailto:topp...@codehaus.org] 
 Sent: Wednesday, November 10, 2010 3:49 PM
 To: Maven Users List
 Subject: Re: Figuring out the proper Maven dependency setting

 On Nov 10, 2010, at 3:40 PM, marshall wrote:

  Hi;
   This is probably a beginner question, but I thought it was 
 worth posing because it is frequently very frustrating when 
 working with Maven.
   Is there a clear way to know which particular dependencies 
 Maven requires, when working with a set of jars/libraries?

 This isn't as much a Maven question as it is a question on 
 the organizations that package the dependencies, but here's 
 some info.  Dependencies typically depend on other 
 dependencies, and one eventually gets a transitive closure of 
 dependencies.  You can see this in your build by running 'mvn 
 dependency:tree'. This will show you a tree of who is pulling 
 in what, and help make decisions on what to pull in at the 
 top level and what you can ignore.

 For instance, if you used to pull in asm for use with 
 Hibernate, you can stop doing that, because the Hibernate 
 dependency you choose will know better what exact version it 
 was compiled at.  If you need a specific version of asm for 
 your own needs, this is where things get more complicated.

 These problems existed before Maven though.  Maven just gives 
 you a bigger, more efficient gun to shoot yourself in the foot with.

 Hope that helps...

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

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

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

RE: Continuous Delivery and Maven

I would agree with you on this one. I think one of the discussions that
is missing here is the idea of when or how we determine we have
*something of value*.

My assumptions is it goes something like this:

Build - Inspect and Test - Value? YES|NO

Right now the approach presented in this group was to *go back* and take
our *squishy* build, harden it, and ship it.

What I like about our current thinking is that we are taking a gamble,
up front, that what we built will have value so we take our *squishy*
build and harden it at build time so that IF it does pass whatever
quality gates are down the line we don't have to fear going back, we can
in fact *pluck it from the stream* or simply allow it to continue on
it's way.

 

 stephenconnolly wrote:
  
  so lets say for #1 we add a phase of ship... we'd have 
 the standard 
  lifecycle something like
  
  validate - ... - compile - ... - test - ... - package 
 - ... - 
  verify - install - deploy - ship
  
  that would allow us to bind our CD steps to the ship phase...
  
 
 I'd be concerned about binding the CD steps to any phase in 
 Maven. In my mind a server deployment should happen by 
 grabbing the deployable artifact from your repository and 
 sending it to the server. In CD we would need to send the 
 artifact to multiple servers through out the pipeline and 
 ultimately have a push-button deployment to production. CD 
 is all about making artifacts availible to be deployed not 
 neccessarily forcing the deployment. THis means we have to 
 have a place where the latest blessed version is staged and 
 ready to go.
 
 I see the Maven repo as an ideal place for this.
 
 In our environment I feel the build build responsibility of 
 maven ends with an artifact being deployed/promoted in the 
 repository. After that the server deployment is triggered and 
 picks up said artifact. I see many tools as possible in this 
 part of the process, most notably scripting or a separate 
 unique Maven invokation. I just think it is very important to 
 separate this phase/process from the build phase/process.
 
 In many environments we'd also want to pull enviroment 
 specific configuration from a cmdb, add this to the 
 deployable and then deploy. I don't see how this could be 
 easily accomodated if this is simply taked on to the standard 
 Maven life-cycle.
 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven
-tp3245370p3259411.html
 Sent from the Maven - Users mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


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

RE: Figuring out the proper Maven dependency setting

I would be curious if you could unpack you app and just replace the JARs
with ones from Maven repo's and have it still work.

I can't tell you how projects I've encountered where I cannot figure
what version a JAR is or where it came from. I am sure I have seen hand
modified JAR lumping packages together or JARs from IDE libraries that
aren't intended for distribution.

I have used the technique described here but I have also had too to
forensic type package level comparisons to try an find matches.
Eventually slugging our way through namespace collisions and knocking
down issues one Classpath Not Found at a time.

 -Original Message-
 From: Brian Topping [mailto:topp...@codehaus.org] 
 Sent: Wednesday, November 10, 2010 3:49 PM
 To: Maven Users List
 Subject: Re: Figuring out the proper Maven dependency setting
 
 
 On Nov 10, 2010, at 3:40 PM, marshall wrote:
 
  Hi;
   This is probably a beginner question, but I thought it was 
 worth posing because it is frequently very frustrating when 
 working with Maven.
   Is there a clear way to know which particular dependencies 
 Maven requires, when working with a set of jars/libraries?
 
 This isn't as much a Maven question as it is a question on 
 the organizations that package the dependencies, but here's 
 some info.  Dependencies typically depend on other 
 dependencies, and one eventually gets a transitive closure of 
 dependencies.  You can see this in your build by running 'mvn 
 dependency:tree'. This will show you a tree of who is pulling 
 in what, and help make decisions on what to pull in at the 
 top level and what you can ignore.
 
 For instance, if you used to pull in asm for use with 
 Hibernate, you can stop doing that, because the Hibernate 
 dependency you choose will know better what exact version it 
 was compiled at.  If you need a specific version of asm for 
 your own needs, this is where things get more complicated.
 
 These problems existed before Maven though.  Maven just gives 
 you a bigger, more efficient gun to shoot yourself in the foot with.
 
 Hope that helps...
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


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

Re: Figuring out the proper Maven dependency setting

2010-11-10 Thread Ron Wheeler


On 10/11/2010 3:40 PM, marshall wrote:

Hi;
  This is probably a beginner question, but I thought it was worth posing 
because it is frequently very frustrating when working with Maven.
  Is there a clear way to know which particular dependencies Maven requires, 
when working with a set of jars/libraries?
  For example, I have been trying to get JPA and Hibernate configured properly 
in the pom.xml. I have tried so many different variations of dependencies 
(hibernate, hibernate-core, javax.persistence, JPA, MySQL, etc.) that I finally 
just threw up my hands in frustration.
I can get a Hibernate/JPA/MySQL application working just fine without Maven, 
but when I try to integrate Maven I'm lost as to which dependencies it needs. 
They seem to be different than the jars/libraries I specify in the classpath 
for a non-Maven build.
Thanks;
Mar



We use Hibernate and Mysql all the time in Maven and have no problem 
specifying the versions
As you can see below, we only need 3 dependencies to get enough to make 
it all run and one of them is a connector for MS-SQL which we use 
against a remote database at another company.


This POM controls the dependencies of Hibernate and Mysql. It is mostly 
exclusions to stop old versions of libraries from being dragged in by 
mistake.
It took a bit of doing to get these the first time but it is nice now 
that we do not have a screen full of conflicting version notes.


This is used as a dependency of other similar POMs until we get a POM 
that contains the major framwork dependencies

lms-pom-spring-hibernate-mysql-tomcat which actual applications depend on.
When we want to change the MySQL connector, we only change it here and 
rebuild the other POMs to get everyone in synch.
The developer who is building a web service, servlet or portlet has no 
concern about the actual versions of the lower level stuff.
He is building with 1.9.1 of our base and gets whatever is supposed to 
be there.



We do the same thing for the Apache commons, CXF, Jasper dependencies, 
etc.  We have about 10 in total.
Most projects only need 5 or fewer dependencies to get everything and 
everything is a lot!


lms - Learning Management System - is the application umbrella.

We can usually release these very early in the project since these do 
not change very often but we do build a set of SNAPSHOTs to start.


project xmlns=http://maven.apache.org/POM/4.0.0; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd;

modelVersion4.0.0/modelVersion
parent
artifactIdlms-pom-master/artifactId
groupIdcom.company.lms/groupId
version1.9.1/version
/parent

groupIdcom.company.lms/groupId
artifactIdlms-pom-hibernate-mysql/artifactId
packagingpom/packaging
nameHibernate-MySQL/name
version1.9.1/version

descriptionHibernate and MySQL/description

properties
hibernate.version3.2.6.ga/hibernate.version
mysql-connector-java.version5.1.10/mysql-connector-java.version
jtds.version1.2.2/jtds.version
/properties
dependencies
dependency
groupIdorg.hibernate/groupId
artifactIdhibernate/artifactId
version${hibernate.version}/version
exclusions
exclusion
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
/exclusion
exclusion
groupIdcommons-collections/groupId
artifactIdcommons-collections/artifactId
/exclusion
exclusion
artifactIdasm/artifactId
groupIdasm/groupId
/exclusion
exclusion
artifactIdcglib/artifactId
groupIdcglib/groupId
/exclusion
exclusion
artifactIdantlr/artifactId
groupIdantlr/groupId
/exclusion
exclusion
artifactIdjta/artifactId
groupIdjavax.transaction/groupId
/exclusion
exclusion
artifactIddom4j/artifactId
groupIddom4j/groupId
/exclusion
/exclusions
/dependency
dependency
groupIdmysql/groupId
artifactIdmysql-connector-java/artifactId
version${mysql-connector-java.version}/version
/dependency
dependency
groupIdnet.sourceforge.jtds/groupId
artifactIdjtds/artifactId
version${jtds.version}/version
/dependency
/dependencies

/project

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

Re: Figuring out the proper Maven dependency setting


On Nov 10, 2010, at 4:06 PM, Yanko, Curtis wrote:

 I have used the technique described here but I have also had too to
 forensic type package level comparisons to try an find matches.
 Eventually slugging our way through namespace collisions and knocking
 down issues one Classpath Not Found at a time.

The directory entries in a Zip archive are not compressed.  This makes class 
names searchable with 'grep -R' on the local repository.  If you download and 
compile a lot of OSS projects that use Maven, chances are your repository has 
most of the dependencies you would normally want to use already in it.  

Alternately, to speed inquiries on jar contents, I use 
http://mvnrepository.com.  Once one drills down to the page for a specific 
version of a dependency, the package structure of the contents is displayed.  
It's a lot easier than constantly doing 'jar tvf filename' to see what's in 
there, and there's a bunch of additional information about the dependency on 
that page too.  It only works for jars in the central repo though, and sadly, 
there are a few things that could be made a lot nicer, but the authors have a 
full email box and apparently do not want to be bothered.



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

Re: Figuring out the proper Maven dependency setting


On Nov 10, 2010, at 4:20 PM, Ron Wheeler wrote:

 It is mostly exclusions to stop old versions of libraries from being dragged 
 in by mistake.
 It took a bit of doing to get these the first time but it is nice now that we 
 do not have a screen full of conflicting version notes.

So I guess you are then having to manually import the dependencies that you are 
excluding?  That is seriously painful. 

It seems to follow that you would also want to set exclusions on all the 
excluded dependencies that you manually import, right?  I mean, there's no 
telling that you might get a version of a transitive dependency somewhere that 
has two versions!  :-)

At that point, I don't know why you would bother with Maven at all.  The effort 
required to disable all the dependency functionality (one dependency at a time) 
is so much more painful than using it well.

I'm not trying to be mean here, just trying to illustrate how the situation 
degenerates.  

Have you tried not using exclusions at all, then using dependency:tree to debug 
conflicts?  Classpath conflicts where there are two versions of the same jar 
are usually pretty easy to spot, and when they happen, they make such a big 
mess of everything that it's hard to miss.  But dependency:tree will show you 
one or two root causes of the problem, then you can put in a single exclusion 
on the precise jar that is causing the problem.  Problem solved, and you still 
get updates to transitives like God intended.



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

Dual javadoc

2010-11-10 Thread Gerard Weatherby

Is there a way to configure the javadoc plugin to generate two sets of 
Javadoc output? We find it convenient to have both  the default public 
and showprivate/show versions.


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

Re: Running tests twice and the build success status

2010-11-10 Thread Stephen Connolly

That would be because hudson turns off failing a build if tests fail.

In hudson, failing tests is a yellow ball.

Build broken is a red ball

Everything hunky-dory is a blue ball.

your issue comes from using the crappy maven 2 project type in hudson which
modifies your build behind your back.
Use freestyle and ensure that the test reports pattern matches all your
output directories and you'll get your yellow balls again (assuming you add
-Dmaven.test.failure.ignore=true so that your hudson build can give yellow
balls)

By the way, yellow balls are better because they tell you how many tests are
failing... Developer builds should fail fast. CI builds should report how
badly the tests are failing to allow you to track progress

- Stephen

---
Sent from my Android phone, so random spelling mistakes are a direct result
of using swype to type on the screen

On 10 Nov 2010 18:01, Bogdan Calmac bcal...@gmail.com wrote:


OK, I've done some further investigation and discovered that this only
happens on our Hudson CI server. The cmdline maven build works as expected.

For reference, here is the JIRA for the Hudson project:
http://issues.hudson-ci.org/browse/HUDSON-8065
--
View this message in context:
http://maven.40175.n5.nabble.com/Running-tests-twice-and-the-build-success-status-tp3257693p3259119.html

Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-...

Re: Figuring out the proper Maven dependency setting

2010-11-10 Thread Ron Wheeler


On 10/11/2010 4:37 PM, Brian Topping wrote:

On Nov 10, 2010, at 4:20 PM, Ron Wheeler wrote:


It is mostly exclusions to stop old versions of libraries from being dragged in 
by mistake.
It took a bit of doing to get these the first time but it is nice now that we 
do not have a screen full of conflicting version notes.

So I guess you are then having to manually import the dependencies that you are 
excluding?  That is seriously painful.
We only did that once about a year ago. It was painful but now life is 
grand.
commons-logging is specified once for 60 projects and I know exactly 
what version is used everywhere.



It seems to follow that you would also want to set exclusions on all the 
excluded dependencies that you manually import, right?  I mean, there's no 
telling that you might get a version of a transitive dependency somewhere that 
has two versions!  :-)


No need that I can see for this.

At that point, I don't know why you would bother with Maven at all.
Maven manages all this for us,  builds all the right libraries. Tiny 
little POM files that are easy to maintain. Few dependencies and no 
exclusions. Easy to make a new one. Just copy and old one and change a 
few fields on the first screen of the POM editor.

  The effort required to disable all the dependency functionality (one 
dependency at a time) is so much more painful than using it well.


Not painful at all. No overhead once we set up our dependency POMs.

I'm not trying to be mean here, just trying to illustrate how the situation 
degenerates.




Have you tried not using exclusions at all, then using dependency:tree to debug 
conflicts?  Classpath conflicts where there are two versions of the same jar 
are usually pretty easy to spot, and when they happen, they make such a big 
mess of everything that it's hard to miss.  But dependency:tree will show you 
one or two root causes of the problem, then you can put in a single exclusion 
on the precise jar that is causing the problem.  Problem solved, and you still 
get updates to transitives like God intended.

Sure. That is how we started. Pain was constant. Drove us crazy. 
Conflicts all over the place. Multiple versions of third party libraries 
on the classpath. Never knew which combination was going to go in at 
run-time.
Once you get 70 portlets, servlets and web services to watch, you want 
to know what version of third party libraries you are building with.

If we decide to go to the latest Apache-POI, we just change it one place.
We do it carefully after a discussion about impact and risk.  We verify 
what other dependencies will be affected. But we only do it once and we 
do it under control.


No conflicts. Only things that break, are stuff that we wrote.

Another small note. We put all our shared libraries at the Tomcat level. 
Our war files are small and generally consist exclusively of our own code.

We only load 1 copy of commons-logging onto the server.

The scores of libraries are all aggregated into 10 library jar files 
that go on /lib.


Ron


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

RE: Figuring out the proper Maven dependency setting

I'm not talking about libraries, I'm talking about an app that has been
built for years either with Ant or without a build script. So we get a
known good EAR and de-construct it often finding JARs that don't exist
in the wild or are unidentifiable. So re-creating that EAR Maven can
become a real challenge.


 -Original Message-
 From: Brian Topping [mailto:topp...@codehaus.org] 
 Sent: Wednesday, November 10, 2010 4:25 PM
 To: Maven Users List
 Subject: Re: Figuring out the proper Maven dependency setting
 
 
 On Nov 10, 2010, at 4:06 PM, Yanko, Curtis wrote:
 
  I have used the technique described here but I have also had too to 
  forensic type package level comparisons to try an find matches.
  Eventually slugging our way through namespace collisions 
 and knocking 
  down issues one Classpath Not Found at a time.
 
 The directory entries in a Zip archive are not compressed.  
 This makes class names searchable with 'grep -R' on the local 
 repository.  If you download and compile a lot of OSS 
 projects that use Maven, chances are your repository has most 
 of the dependencies you would normally want to use already in it.  
 
 Alternately, to speed inquiries on jar contents, I use 
 http://mvnrepository.com.  Once one drills down to the page 
 for a specific version of a dependency, the package structure 
 of the contents is displayed.  It's a lot easier than 
 constantly doing 'jar tvf filename' to see what's in there, 
 and there's a bunch of additional information about the 
 dependency on that page too.  It only works for jars in the 
 central repo though, and sadly, there are a few things that 
 could be made a lot nicer, but the authors have a full email 
 box and apparently do not want to be bothered.
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


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

RE: Figuring out the proper Maven dependency setting


+1, That's the spirit! It's like I said, many teams for a long time have
under-valued the build process and deem the whole activity to be not
worth their time. And yet, so few teams I meet can provided me with a
bill-of-materials or even a basic architectural drawing showing the
relationship of their components. I very often find several JARs being
packaged that aren't needed. Large circular dependencies and my
favorite, 2 or 3 major versions within a family of libraries.
 

 -Original Message-
 From: Michael McCallum [mailto:mich...@redengine.co.nz] 
 Sent: Wednesday, November 10, 2010 4:44 PM
 To: Maven Users List
 Subject: Re: Figuring out the proper Maven dependency setting
 
 On Thursday 11 November 2010 09:48:34 Brian Topping wrote:
  
  These problems existed before Maven though.  Maven just 
 gives you a bigger, more efficient gun to shoot yourself in 
 the foot with.
  
 I'm more likely to say that now we _know_ what a mess we 
 have, where as before we were ignorant. In which case maven 
 is the tool that actually lets us take control and get it 
 right, even if its only in our own limited spheres of influence.
 
 Its not just a maven/java problem all the linux distributions 
 have done through the same pain.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


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

maven 3 profiles.xml replacement?

2010-11-10 Thread Scott Miller


Hi,

I am trying to upgrade a maven 2.x build system to a maven 3.x build  
system and have run in to a problem with the fact that profiles.xml is  
no longer supported.  Our current build iconfigures the built .ear  
file based on build properties supplied in profiles.xml.  These  
properties are used to configure which features in the application are  
activated based on the client for which the application is being  
built.  It also contains environment specific configuration  
information (database connection info, remote service urls, etc etc).   
We basically created a profiles.xml for each client, and then our  
build server (hudson) had a build track for each deployment which  
would use the correct profile.


Now that profiles.xml is no longer supported, I don't have a place to  
put all of this information.  We have a lot of these profiles files so  
I don't want this information added in to our pom directly.  Modifying  
settings.xml in a hudson build seems like a bad idea, since then if  
multiple hudson builds are run at once, they would impact eachother.


Does anyone have any ideas for how to work around this?

Thanks,

Scott

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

Whatever happened to j2ee-1.4.jar ?

2010-11-10 Thread Simon Lewis

Hi,

What's up with  http://repo2.maven.org/maven2/javax/j2ee/j2ee/1.4/

Shouldn't there be a jar in there ??

thanks
Simon

Re: Whatever happened to j2ee-1.4.jar ?

On Nov 10, 2010, at 9:58 PM, Simon Lewis wrote:

 What's up with  http://repo2.maven.org/maven2/javax/j2ee/j2ee/1.4/

You need to download it directly from the JavaEE site and install it with the 
instructions that you find in the build log.  License issues, it can't be 
distributed through the central repo.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Whatever happened to j2ee-1.4.jar ?

2010-11-10 Thread Simon Lewis

Ah ... ok, thanks

On Thu, Nov 11, 2010 at 4:08 PM, Brian Topping topp...@codehaus.org wrote:

 On Nov 10, 2010, at 9:58 PM, Simon Lewis wrote:

  What's up with  http://repo2.maven.org/maven2/javax/j2ee/j2ee/1.4/

 You need to download it directly from the JavaEE site and install it with
 the instructions that you find in the build log.  License issues, it can't
 be distributed through the central repo.
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Whatever happened to j2ee-1.4.jar ?

 You need to download it directly from the JavaEE site and install it with
 the instructions that you find in the build log.  License issues, it can't
 be distributed through the central repo.

You may also find what you need (spec-jar-wise) from the Geronimo project:
http://repo2.maven.org/maven2/org/apache/geronimo/specs/

Wayne

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

Re: maven 3 profiles.xml replacement?

 want this information added in to our pom directly.  Modifying settings.xml
 in a hudson build seems like a bad idea, since then if multiple hudson
 builds are run at once, they would impact eachother.

I don't understand this comment. You should be able to copy all your
profiles into one settings.xml file and then use various activation
options to turn one or another on for a given build.

http://maven.apache.org/settings.html

Wayne

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

Re: maven 3 profiles.xml replacement?

2010-11-10 Thread Scott Miller

Sorry, I guess I didn't explain.  The configuration settings need to  
be version controlled and the hudson server runs the builds for the  
whole company.


As it stands now, we pull the profiles.xml files from a different svn  
repo and copy them in as part of the hudson build.  I guess we could  
put the settings.xml file for the hudson user in to source control,  
but having all of that information from across all of our projects in  
one place is far from ideal.


-Scott

On Nov 10, 2010, at 7:57 PM, Wayne Fay wrote:

want this information added in to our pom directly.  Modifying  
settings.xml
in a hudson build seems like a bad idea, since then if multiple  
hudson

builds are run at once, they would impact eachother.


I don't understand this comment. You should be able to copy all your
profiles into one settings.xml file and then use various activation
options to turn one or another on for a given build.

http://maven.apache.org/settings.html

Wayne

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




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

Re: maven 3 profiles.xml replacement?