date:20101109

What goal did you specify? The plugin exists at Maven central.

/Anders

On Tue, Nov 9, 2010 at 00:09, Johan Hedin johan.he...@mawell.com wrote:

 Maven refuses to build. Version 1.0 of maven-enforcer-plugin in the
 repo1.maven.org is empty.


 [INFO]
 
 Downloading:
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.pom
 Downloading:
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.jar
 [INFO]
 
 [ERROR] BUILD FAILURE
 [INFO]
 
 [INFO] A required plugin was not found: Plugin could not be found - check
 that the goal name is correct: Unable to download the artifact from any
 repository

 Try downloading the file manually from the project website.

 Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.plugins
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin
 -Dfile=/path/to/file

 Alternatively, if you host your own repository you can deploy the file
 there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots (scpexe://
 repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases (scpexe://
 repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots (scpexe://
 repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases (scpexe://
 repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)

 TIA

 Johan Hedin


 -
 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 think some of the issues are around missuse of Maven.

Maven is a build tool, use it to do your build.

CD needs a separate layer above Maven to do the deployment... now one
could use maven plugins to provide that layer, but there are two
issues I see:

1. the maven lifecycle does not include the phases you require

2. inbetween invokations of maven, we have no means to share state

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... ok, so
people would have to get used to the fact that Maven uses deploy to
mean copy artifact to remote maven repo and not the CD meaning of
deploy... but people can Just Get Over It(TM)

that allows any build to just go

mvn clean ship

and away we go... except that we would be dealing with -SNAPSHOTs...

so to correct for that we would change the release goals using the
release plugin to be ship in place of deploy... to gain speed (at
the expense of better tested releases), we could even modify the
preparation goals using the release plugin to be just clean validate
and not clean verify

then

mvn release:prepare

would be quick

mvn release:perform

would do the CD

H... most of this is actually fine for CD, and we don't even
really need the ship phase as we could just bind to the deploy phase
using the release profile to ensure that it only takes place during a
release...

The down side is we have no way to roll-back easily

e.g. we've just released 2.1.5652 but we have egg on our face due to
an automated QA test that is giving a false pass... we have no way to
revert back to 2.1.5651 except:
 A. to revert the commits and roll a new release
 B. put in the 2.1.5651 artifact by hand

we can check-out the tag for 2.1.5651 and run mvn ship -DskipTests
or mvn deploy -Prelease -DskipTests depending on whether we actually
got the ship phase into the standard lifecycle or whether we just
used the release profile to bind to the deploy phase but at the
end of the day, that would be rebuilding the binaries... which (with a
strict QA hat on) invalidates testing...

I think what you need to do is have a maven-ship-plugin or a
ship-maven-plugin that works a little like this:

it takes a parameter shipVersion which by default evaluates the
property shipVersion, but if that property is not defines then
defaults to ${project.version}

The m-s-p then resolves the shipVersion of the project artifact and
passes that file onto a ship script...

so if I have a war project foo:bar:1.0-SNAPSHOT:war

mvn ship:ship -DshipVersion=1.0.56

will redeploy the old version 1.0.56

mvn package ship:ship

will build the current source code and ship that

mvn ship:ship

will resolve the latest 1.0-SNAPSHOT from the local/remote repos and ship that

we could add a parameter allowSnapshots that will default to false in
order to prevent accidental deployment of non-releases

and if you are doing CD you can bind ship:ship to the deploy phase in
your release profile.

I think I'll knock something together @mojo to help with this

On 8 November 2010 19:20, stug23 pat.poden...@gmail.com wrote:

 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

Re: Version 1.0 of maven-enforcer-plugin not deployed

It can take a few hours to fully sync if it's more than 24 hours
after the announcement, then it's time to start screaming!

On 8 November 2010 23:09, Johan Hedin johan.he...@mawell.com wrote:
 Maven refuses to build. Version 1.0 of maven-enforcer-plugin in the 
 repo1.maven.org is empty.


 [INFO] 
 
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.pom
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.jar
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] A required plugin was not found: Plugin could not be found - check 
 that the goal name is correct: Unable to download the artifact from any 
 repository

 Try downloading the file manually from the project website.

 Then, install it using the command:
    mvn install:install-file -DgroupId=org.apache.maven.plugins 
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin 
 -Dfile=/path/to/file

 Alternatively, if you host your own repository you can deploy the file there:
    mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins 
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin 
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots 
 (scpexe://repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases 
 (scpexe://repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots 
 (scpexe://repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases 
 (scpexe://repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)

 TIA

 Johan Hedin


 -
 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: Version 1.0 of maven-enforcer-plugin not deployed

Oh and I can see the artifact just fine

On 9 November 2010 09:25, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 It can take a few hours to fully sync if it's more than 24 hours
 after the announcement, then it's time to start screaming!

 On 8 November 2010 23:09, Johan Hedin johan.he...@mawell.com wrote:
 Maven refuses to build. Version 1.0 of maven-enforcer-plugin in the 
 repo1.maven.org is empty.


 [INFO] 
 
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.pom
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.jar
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] A required plugin was not found: Plugin could not be found - check 
 that the goal name is correct: Unable to download the artifact from any 
 repository

 Try downloading the file manually from the project website.

 Then, install it using the command:
    mvn install:install-file -DgroupId=org.apache.maven.plugins 
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin 
 -Dfile=/path/to/file

 Alternatively, if you host your own repository you can deploy the file there:
    mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins 
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin 
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots 
 (scpexe://repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases 
 (scpexe://repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots 
 (scpexe://repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases 
 (scpexe://repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)

 TIA

 Johan Hedin


 -
 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

Wagon in 3.0: No connector

2010-11-09 Thread Jochen Wiedmann

Does anyone have an idea, why this one works flawlessly (some
parameters omitted):

  /c/Prg/apache-maven-2.2.1/bin/mvn deploy:deploy-file ...
-Durl=scp://shell.sourceforge.net/home/groups/c/cs/csutils/htdocs/repository

But this one doesn't:

/c/Prg/apache-maven-3.0/bin/mvn deploy:deploy-file ...
-Durl=scp://shell.sourceforge.net/home/groups/c/cs/csutils/htdocs/repository
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building JaxMas 0.2.2
[INFO] 
[INFO]
[INFO] --- maven-deploy-plugin:2.5:deploy-file (default-cli) @
jaxmas-registry ---
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 0.517s
[INFO] Finished at: Tue Nov 09 10:29:54 CET 2010
[INFO] Final Memory: 4M/121M
[INFO] 
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy-file
(default-cli) on project jaxmas-registry: Failed to deploy
artifacts/metadata: No connector available to access repository sf.net
(scp://shell.sourceforge.net/home/groups/c/cs/csutils/htdocs/repository)
of type default using the available factories
WagonRepositoryConnectorFactory - [Help 1]



-- 
I Am What I Am And That's All What I Yam (Popeye)

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

Re: Wagon in 3.0: No connector

2010-11-09 Thread Olivier Lamy

Hi Jochen,
This can be probably fixed with adding wagon scp in the deploy plugin
dependencies.

-- 
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy


2010/11/9 Jochen Wiedmann jochen.wiedm...@gmail.com:
 Does anyone have an idea, why this one works flawlessly (some
 parameters omitted):

  /c/Prg/apache-maven-2.2.1/bin/mvn deploy:deploy-file ...
 -Durl=scp://shell.sourceforge.net/home/groups/c/cs/csutils/htdocs/repository

 But this one doesn't:

 /c/Prg/apache-maven-3.0/bin/mvn deploy:deploy-file ...
 -Durl=scp://shell.sourceforge.net/home/groups/c/cs/csutils/htdocs/repository
 [INFO] Scanning for projects...
 [INFO]
 [INFO] 
 
 [INFO] Building JaxMas 0.2.2
 [INFO] 
 
 [INFO]
 [INFO] --- maven-deploy-plugin:2.5:deploy-file (default-cli) @
 jaxmas-registry ---
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 0.517s
 [INFO] Finished at: Tue Nov 09 10:29:54 CET 2010
 [INFO] Final Memory: 4M/121M
 [INFO] 
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy-file
 (default-cli) on project jaxmas-registry: Failed to deploy
 artifacts/metadata: No connector available to access repository sf.net
 (scp://shell.sourceforge.net/home/groups/c/cs/csutils/htdocs/repository)
 of type default using the available factories
 WagonRepositoryConnectorFactory - [Help 1]



 --
 I Am What I Am And That's All What I Yam (Popeye)

 -
 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: Wagon in 3.0: No connector

http://lmgtfy.com/?q=maven+3+wagon+scpl=1

Google rocks! :-)

/Anders

On Tue, Nov 9, 2010 at 10:30, Jochen Wiedmann jochen.wiedm...@gmail.comwrote:

 Does anyone have an idea, why this one works flawlessly (some
 parameters omitted):

  /c/Prg/apache-maven-2.2.1/bin/mvn deploy:deploy-file ...
 -Durl=scp://
 shell.sourceforge.net/home/groups/c/cs/csutils/htdocs/repository

 But this one doesn't:

 /c/Prg/apache-maven-3.0/bin/mvn deploy:deploy-file ...
 -Durl=scp://
 shell.sourceforge.net/home/groups/c/cs/csutils/htdocs/repository
 [INFO] Scanning for projects...
 [INFO]
 [INFO]
 
 [INFO] Building JaxMas 0.2.2
 [INFO]
 
 [INFO]
 [INFO] --- maven-deploy-plugin:2.5:deploy-file (default-cli) @
 jaxmas-registry ---
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 0.517s
 [INFO] Finished at: Tue Nov 09 10:29:54 CET 2010
 [INFO] Final Memory: 4M/121M
 [INFO]
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy-file
 (default-cli) on project jaxmas-registry: Failed to deploy
 artifacts/metadata: No connector available to access repository sf.net
 (scp://shell.sourceforge.net/home/groups/c/cs/csutils/htdocs/repository)
 of type default using the available factories
 WagonRepositoryConnectorFactory - [Help 1]



 --
 I Am What I Am And That's All What I Yam (Popeye)

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

Re: Wagon in 3.0: No connector

2010-11-09 Thread Jochen Wiedmann

In the case of deploy:file, I can hardly add this to the pom file,
can't I? I'd see this as a regression.


On Tue, Nov 9, 2010 at 10:33 AM, Anders Hammar and...@hammar.net wrote:
 http://lmgtfy.com/?q=maven+3+wagon+scpl=1

 Google rocks! :-)

 /Anders

 On Tue, Nov 9, 2010 at 10:30, Jochen Wiedmann 
 jochen.wiedm...@gmail.comwrote:

 Does anyone have an idea, why this one works flawlessly (some
 parameters omitted):

  /c/Prg/apache-maven-2.2.1/bin/mvn deploy:deploy-file ...
 -Durl=scp://
 shell.sourceforge.net/home/groups/c/cs/csutils/htdocs/repository

 But this one doesn't:

 /c/Prg/apache-maven-3.0/bin/mvn deploy:deploy-file ...
 -Durl=scp://
 shell.sourceforge.net/home/groups/c/cs/csutils/htdocs/repository
 [INFO] Scanning for projects...
 [INFO]
 [INFO]
 
 [INFO] Building JaxMas 0.2.2
 [INFO]
 
 [INFO]
 [INFO] --- maven-deploy-plugin:2.5:deploy-file (default-cli) @
 jaxmas-registry ---
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 0.517s
 [INFO] Finished at: Tue Nov 09 10:29:54 CET 2010
 [INFO] Final Memory: 4M/121M
 [INFO]
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy-file
 (default-cli) on project jaxmas-registry: Failed to deploy
 artifacts/metadata: No connector available to access repository sf.net
 (scp://shell.sourceforge.net/home/groups/c/cs/csutils/htdocs/repository)
 of type default using the available factories
 WagonRepositoryConnectorFactory - [Help 1]



 --
 I Am What I Am And That's All What I Yam (Popeye)

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






-- 
I Am What I Am And That's All What I Yam (Popeye)

-
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


Start by getting it working with Eclipse and Maven.
Tell Maven and Eclipse that you are trying to build a standalone 
application when you create the Eclipse project.
It will structure your project so that it builds one with the assets in 
the right place to run it.


Points to remember
1) Don't fight Maven. It always wins.
2) Lots of people are building whatever it is that you are building and 
have already solved ALL the typical problems and built these solutions 
into Maven and Eclipse.
3) If it doesn't work, you have done something wrong. This is the 
hardest one to deal with
4) Get the basics right first and customize later once you know how it 
should hang together.
5) When asking a question in the forum, ask in terms of what you are 
trying to accomplish not how. You will get much better advice if people 
know what you want to accomplish as a result. How should I set up maven 
to build a standalone Java application(compiler)? than How do I make 
maven tell Ant about classpaths?.


The members here are really great and very helpful.
You will get all the support that you need to make this work well.

Ron

On 09/11/2010 8:29 AM, Jacob Beard wrote:

Hi Ron,

Thanks for the reply.

On 10-11-09 02:06 PM, Ron Wheeler wrote:
If you are using a decent IDE (Eclipse STS for example) with Maven 
support, you should not need any of this.

Maven and Eclipse will get everything you need onto the classpath.

My project is a compiler, so I feel that it's important that it be 
accessible from the command line, just as it's not necessary to fire 
up an Netbeans in order to use javac.


I can think of a hacky solution that might work, which is to pass the 
classpath from Maven to Ant using Maven Ant Tasks, and then allow Ant 
to echo it out. But I was hoping that this might be a solved problem, 
and that there might be a cleaner maven solution to making this work.


I'd appreciate any advice you can offer. Thanks,

Jake

-
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: Custom assembly of multi module project

On 09/11/2010 9:03 AM, Anders Hammar wrote:

I think you should start by separating the configurations from your
binaries. Then it will be so much easier creating the custom zip you want.
You would also avoid having the configuration files duplicated (like outisde
the jars as well as inside some of the jars). That will sooner or later get
you or someone else into trouble.

+1 I have been a victim of this practice. Very unpleasant.

/Anders

On Tue, Nov 9, 2010 at 14:14, jon.mithejon.mi...@gmail.com wrote:

Hi,

I'm trying to switch over to maven for a project I developing in work, new
to maven and finding packaging it a little tricky.

The app I am writing has a core framework module and then a bunch of other
modules that provide plugin like functionality. The idea being I can
produce different builds with different combinations of modules /
functionality. The confusing bit is each module specifies its own configs
+
other config like resources and these must be aggregated together in the
build. So my project:

Parent Project
--Core Module
src/main/java
src/main/config
src/main/other_resource_directory
--Module A
src/main/java
src/main/config
src/main/other_resource_directory
--Module B
src/main/java
src/main/config
src/main/other_resource_directory

needs to go to the final package / zipped artifact:

./core.jar
./moduleA.jar
./moduleB.jar
./config/all configs accross all modules
./other_resource_directory/all other resources accross all modules

As I understand, I need to use the maven-assembly-plugin to do most of
this,
and to include the custom directories I need.

I think I need to define each module artifact as a zip file with the target
jar in it and the 2 folders. Which involves writing an assembly plugin
instance in the plugin management of the parent POM and my own assembly
descriptor. The idea being I can reference the plugin as an artifact in
each of my sub modules, i.e:
pluginartifactIdmodule-bundle/artifactId/plugin.

So I think that may work for each of my sub-modules, but I have no idea
then
how to process these artifacts to aggregate this into a zip in the format
above. I think the artifact is I would get atm is a jar containing all the
zipped artifacts from each modules. So when that artifact is being created
I need to process the zips from the modules / unpackage each module and
copy
configs across etc.

Talked to a friend who said maybe this is not quite within the maven way
and
he suggested gradle may be worthwhile looking into but am quite interested
to know if this should be possible in maven.

Thanks for any help figuring this out,
Jon
--
View this message in context:
http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3256773.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: Maven integration with bash script

On 09/11/2010 7:34 AM, Jacob Beard wrote:

Hi,

My project is built around Mozilla Rhino, but and I'm transitioning to
maven for the build system. When my project was using ant, I had a
task that would download dependencies to the local lib/ directory in
the project. I then had a shell script that would run the project,
including the rhino library and other libraries on the classpath by
refering to its local path. So something like this:

java -cp
lib/java/js.jar:lib/java/commons-cli.jar:lib/java/serializer.jar:lib/java/xalan.jar:lib/java/xercesImpl.jar:lib/java/xml-apis.jar
org.mozilla.javascript.tools.shell.Main -debug $*

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?

I'd appreciate any guidance anyone can provide. Thanks,

Jake

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

If you are using a decent IDE (Eclipse STS for example) with Maven
support, you should not need any of this.

Maven and Eclipse will get everything you need onto the classpath.

Ron
Ron

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

Maven integration with bash script

2010-11-09 Thread Jacob Beard


Hi,

My project is built around Mozilla Rhino, but and I'm transitioning to 
maven for the build system. When my project was using ant, I had a task 
that would download dependencies to the local lib/ directory in the 
project. I then had a shell script that would run the project, including 
the rhino library and other libraries on the classpath by refering to 
its local path. So something like this:


java -cp 
lib/java/js.jar:lib/java/commons-cli.jar:lib/java/serializer.jar:lib/java/xalan.jar:lib/java/xercesImpl.jar:lib/java/xml-apis.jar 
org.mozilla.javascript.tools.shell.Main -debug $*


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?


I'd appreciate any guidance anyone can provide. Thanks,

Jake

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

RE: Continuous Delivery and Maven

+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.

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

Re: Eclipse multi-module project with maven


On 09/11/2010 9:09 AM, Anders Hammar wrote:

Yes, a parent is a pom project. Your api project is a jar project - it
creates a jar.

So create an aggregating project which can also be the parent project. Then
create three jar projects, which are listed as modules.
There are create resources on the Internet explaining all this.

Regarding Eclipse: use m2eclipse and it will take care of everything for
you.
Eclipse STS includes maven integration and is also a good IDE for use 
with Maven.



/Anders

On Tue, Nov 9, 2010 at 15:05, jeb001jeremy.jar...@gmail.com  wrote:


Ok, I guess there's a confusion speaking about parent project..

In my case, web and batch project needs Api jar file to work.. but, I
should
not consider the Api project as the parent ?

By the way, if create one aggregating Maven project listing 3 modules..
should I declare the sourceFolder in the eclipse classPath ?

--
View this message in context:
http://maven.40175.n5.nabble.com/Eclipse-multi-module-project-with-maven-tp3256822p3256876.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: Eclipse multi-module project with maven

2010-11-09 Thread Greg Akins

Could you show us the contents of the parent pom.xml?

On Tue, Nov 9, 2010 at 8:37 AM, jeb001 jeremy.jar...@gmail.com wrote:

Hi,

I'm a new user of maven.. I've seen part of response at my question, but
never exactly got
what I expect.
So, before introducing maven into my project, I had 3 differents projects.
The Api, a batch project, and a web project.
Both web and batch project needs the api.jar to compile.

So, I've made a maven project including my API project.
In the pom.xml, I just added 2 modules (web and batch).

I understood that with maven, it's better to include the project'son into
the parent.
I've got now one project including web and batch project.
It's seems to work, when I build it, the batch project make a jar file, and
the web one make a war file.

The problem is right here : both sons project are not compiled. Maybe should
I add them to the eclipse build path ? I don't really know what' the way...

Thx for your help

--
View this message in context:
http://maven.40175.n5.nabble.com/Eclipse-multi-module-project-with-maven-tp3256822p3256822.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

--
Greg Akins

http://insomnia-consulting.org
http://www.pghcodingdojo.org
http://pittjug.dev.java.net
http://twitter.com/akinsgre
http://www.linkedin.com/in/akinsgre

-
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-09 Thread Benjamin Bentmann


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: Continuous Delivery and Maven

.
 
  I think it is crucial that the release artifact DOES get rebuilt.
 
 
 I think that exactly the opposite is true

I know you think that. You're beating a dead horse. But that isn't the point 
here. It is crucial for Maven that it gets rebuilt. It is simply the way Maven 
is architected. Little to do with what I or you want or think.  That just a 
simple fact I think you will need to accept.

I think is time to move on. I think you have enough feedback to try and get 
what you want working with a plugin or whatever. Best way to learn is to do.

-
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 use CI or CD, so you can take my opinions with a grain of salt

My understanding that an application that gets to a CD stage, is ready 
for testing by human beings.
In order to test an application, people need to know what the system is 
supposed to do.
If a person tests a search function  at the CD stage and it always 
returns John Smith regardless of criteria, this would be flagged as an 
error.
At this point, I would expect that any behaviour that does not meet the 
spec would require the creation of a trouble ticket.


My understanding is that CI will work very well with SNAPSHOTS.

However, a SNAPSHOT will pass all of its tests even though it may only 
offer stub functions and be tested with mock data.
A SNAPSHOT passes to a Release Candidate when the functionality meets 
the specification and it is ready to be tested with real data and will 
interact with the rest of the system according to the specifications.


It makes no sense to me to allow a SNAPSHOT through a CI stage to a CD 
stage.
This would create chaos in the testing group as they would be generating 
all kinds of trouble tickets for nothing.


In my opinion, the use of SNAPSHOTs is essential to an organization 
using CD simply to prevent the CD stage from kicking in as long as there 
is a SNAPSHOT in the CI process. If you do allow SNAPSHOTs into the CD 
stage, this should be a big red flag to the QA team that trouble tickets 
should not be raised and that testing should be closely coordinated with 
the development team to avoid wasting time and pissing off team members.


Ron


On 09/11/2010 6:16 AM, Kief wrote:


Thiessen, Todd (Todd) wrote:

Imagine trying to have a CI build while always having enough information
in the pom to point to an exact version of your dependencies? Lets say I
get a feature working in my checkout, and do a build locally before
committing.  The build would have to point to a fixed version of all my
dependencies.  If the dependencies change while I am working, they would
have to change on the fly.

But of course the formal CI build would also have to ensure it points to
the latest fixed version of all dependencies. It would have to modify the
pom on the fly and it could change to point to a more recent version of
a dependency since there is time between when I run the build in my
checkout and the time I commit.


I don't think it's necessary for the local developer builds to be pinned to
specific versions of dependencies; pinning only needs to happen on commit,
probably as part of the CI. So the CI would pull together the latest version
of each dependency at that point in time, and make sure the information is
included in the artefact.


Thiessen, Todd (Todd) wrote:

I am against the idea of having an automated process massaging a snapshot
and turning it into a release. You simply run the risk of building
something that you didn't anticipate. If you want to build a release,
build a formal release. This will include ensuring that all of your
transtive dependencies are also a formal release. That way you control
exactly what revision of what transitive dependencies will be built as a
release.


Reading through this thread, I see two unreconcilable processes for managing
the build -  release cycle. One involves running builds through CI with no
intention of releasing them to production. Call it progressive delivery,
since you're progressively building your code to the point where you're
ready to release it. The other approach involves assuming that any build
that passes CI will be promoted to the next stage, and may eventually reach
production, i.e. continuous delivery.

Although the two approaches are essentially unreconcilable for a given
project, I don't see any reason why Maven can't support both. The main
obstacle seems to be resistance to the validity of alternative processes.

I don't think continuous delivery requires massaging snapshots; personally I
think Maven's snapshot concept isn't useful for CD. Each CI build needs to
be treated as a release, and dependencies from other teams should only be
pulled from builds that have passed CI. Promotion of a build through the
pipeline shouldn't involve fiddling with the artefact, but should be managed
externally by whatever toolset you're using to manage the pipeline.

CD may or may not require modification to Maven and/or plugins to inject the
information (at CI) needed to rebuild it. It sounds to me that if the build
and its dependencies are all treated as releases rather than snapshots, the
information is probably in there.

Does anyone have a reason why Maven snapshots would be useful or necessary
to a project following CD?

Kief


-Original Message-
From: stug23 [mailto:pat.poden...@gmail.com]
Sent: Sunday, November 07, 2010 12:17 PM
To: users@maven.apache.org
Subject: RE: Continuous Delivery and Maven


I suspect that there is a reasonable way to adjust the builds in Maven
such
that they robustly support Continuous Delivery. I know that

Re: Eclipse multi-module project with maven

Keep your aggregating project clean. Move you build stuff to a separate
module.

/Anders

On Tue, Nov 9, 2010 at 15:02, jeb001 jeremy.jar...@gmail.com wrote:


 sure, here it is :


 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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdfr.gouv.finances.douane.dnsce.mavenProject/groupId
artifactIdMavenProject/artifactId
version1.0.2-SNAPSHOT/version
packagingpom/packaging
nameMavenProject/name

dependencies
!-- dependencies --
/dependencies

build

resources
resource
directory${basedir}/conf/directory
/resource
/resources
testResources
testResource
directory${basedir}/confTest/directory
/testResource
/testResources


  testSourceDirectory${basedir}/JunitSources/testSourceDirectory
outputDirectory${basedir}/classes/outputDirectory

  testOutputDirectory${basedir}/classes/testOutputDirectory
plugins
plugin
groupIdorg.codehaus.mojo/groupId

  artifactIdbuild-helper-maven-plugin/artifactId
version1.5/version
executions
execution

  phasegenerate-sources/phase
goals

  goaladd-source/goal
/goals
configuration
sources

  source${basedir}/IbatisSources/source

  source${basedir}/PersistanceSources/source

  source${basedir}/JavaSources/source
/sources
/configuration
/execution
/executions
/plugin
plugin

  artifactIdmaven-compiler-plugin/artifactId
version2.3.1/version
configuration
source1.5/source
target1.5/target
/configuration
/plugin
/plugins
/build

  modules
moduleMavenBatch/module
moduleMavenWeb/module
  /modules

 /project
 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Eclipse-multi-module-project-with-maven-tp3256822p3256864.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

2010-11-09 Thread Kief



Thiessen, Todd (Todd) wrote:
 
 Imagine trying to have a CI build while always having enough information
 in the pom to point to an exact version of your dependencies? Lets say I
 get a feature working in my checkout, and do a build locally before
 committing.  The build would have to point to a fixed version of all my
 dependencies.  If the dependencies change while I am working, they would
 have to change on the fly.
 
 But of course the formal CI build would also have to ensure it points to
 the latest fixed version of all dependencies. It would have to modify the
 pom on the fly and it could change to point to a more recent version of
 a dependency since there is time between when I run the build in my
 checkout and the time I commit.
 

I don't think it's necessary for the local developer builds to be pinned to
specific versions of dependencies; pinning only needs to happen on commit,
probably as part of the CI. So the CI would pull together the latest version
of each dependency at that point in time, and make sure the information is
included in the artefact. 


Thiessen, Todd (Todd) wrote:
 
 I am against the idea of having an automated process massaging a snapshot
 and turning it into a release. You simply run the risk of building
 something that you didn't anticipate. If you want to build a release,
 build a formal release. This will include ensuring that all of your
 transtive dependencies are also a formal release. That way you control
 exactly what revision of what transitive dependencies will be built as a
 release.
 

Reading through this thread, I see two unreconcilable processes for managing
the build - release cycle. One involves running builds through CI with no
intention of releasing them to production. Call it progressive delivery,
since you're progressively building your code to the point where you're
ready to release it. The other approach involves assuming that any build
that passes CI will be promoted to the next stage, and may eventually reach
production, i.e. continuous delivery.

Although the two approaches are essentially unreconcilable for a given
project, I don't see any reason why Maven can't support both. The main
obstacle seems to be resistance to the validity of alternative processes.

I don't think continuous delivery requires massaging snapshots; personally I
think Maven's snapshot concept isn't useful for CD. Each CI build needs to
be treated as a release, and dependencies from other teams should only be
pulled from builds that have passed CI. Promotion of a build through the
pipeline shouldn't involve fiddling with the artefact, but should be managed
externally by whatever toolset you're using to manage the pipeline.

CD may or may not require modification to Maven and/or plugins to inject the
information (at CI) needed to rebuild it. It sounds to me that if the build
and its dependencies are all treated as releases rather than snapshots, the
information is probably in there.

Does anyone have a reason why Maven snapshots would be useful or necessary
to a project following CD?

Kief

 -Original Message-
 From: stug23 [mailto:pat.poden...@gmail.com]
 Sent: Sunday, November 07, 2010 12:17 PM
 To: users@maven.apache.org
 Subject: RE: Continuous Delivery and Maven
 
 
 I suspect that there is a reasonable way to adjust the builds in Maven
 such
 that they robustly support Continuous Delivery. I know that Jason van Zyl
 has started looking at CD as well.
 
 On the Google forum
 http://groups.google.com/group/continuousdelivery/browse_thread/thread/c
 8440681058f2db8
 Chris Hilton commented:
 
 3. In my ideal world, I would probably either extend the release
 plugin or write a new one with functionality to take a snapshot
 artifact and make it a release artifact, which would still introduce
 slight changes but pretty mild ones. I thought I had read a feature
 request or wish list about this, but can't find it now.
 
 The current Maven release plugin, as it is, was not designed to handle
 the
 notion of CD. So it does make sense to tailor this aspect of releasing
 Maven
 artifacts to better support CD.
 
 Also a quick examination of the Maven versions plugin shows that it has
 facilities to handle updating versions of projects and their
 dependencies.
 So it looks as if it is more a matter of adjustment of Maven build to
 produce a result that aligns with CD than a matter of Maven not being
 suitable for CD. I think that the main stumbling block is SNAPSHOTS
 because
 they inherently are not releasable -- part of the process of releasing
 with
 the current Maven release plugin is to fail when there are SNAPSHOT
 dependencies.
 
 Another clear requirement for any changes to Maven or its build behavior
 is
 that the current behavior must be maintained for the many projects that
 haven't embraced (or won't embrace) Continuous Delivery. So I imagine a
 Maven build's behavior being altered through configuration (or a switch
 of
 some sort) to comply with the desired

Re: Eclipse multi-module project with maven

2010-11-09 Thread Antonio Petrelli

2010/11/9 jeb001 jeremy.jar...@gmail.com:
 In my case, web and batch project needs Api jar file to work.. but, I should
 not consider the Api project as the parent ?

No, it's a dependency.

 By the way, if create one aggregating Maven project listing 3 modules..
 should I declare the sourceFolder in the eclipse classPath ?

Do it in every single module or, better, use the standard directory
(src/main/java).

Antonio

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

Custom assembly of multi module project

2010-11-09 Thread jon.mithe

Hi,

I'm trying to switch over to maven for a project I developing in work, new
to maven and finding packaging it a little tricky.

The app I am writing has a core framework module and then a bunch of other
modules that provide plugin like functionality. The idea being I can
produce different builds with different combinations of modules /
functionality. The confusing bit is each module specifies its own configs +
other config like resources and these must be aggregated together in the
build. So my project:

needs to go to the final package / zipped artifact:

./core.jar
./moduleA.jar
./moduleB.jar
./config/all configs accross all modules
./other_resource_directory/all other resources accross all modules

As I understand, I need to use the maven-assembly-plugin to do most of this,
and to include the custom directories I need.

So I think that may work for each of my sub-modules, but I have no idea then
how to process these artifacts to aggregate this into a zip in the format
above. I think the artifact is I would get atm is a jar containing all the
zipped artifacts from each modules. So when that artifact is being created
I need to process the zips from the modules / unpackage each module and copy
configs across etc.

Talked to a friend who said maybe this is not quite within the maven way and
he suggested gradle may be worthwhile looking into but am quite interested
to know if this should be possible in maven.

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

RE: Continuous Delivery and Maven

Hey Stephen. I read through your idea a little more closely and I like it.

The only thing I think it is missing is the ability to use snapshots as 
dependencies. That is a very powerful feature of maven that I don't think you'd 
want to lose if your using CD.

It is almost like you'd want a mode in Maven. Say you had some kind of flag 
that said Continuous Delivery mode. In this mode, you would only use release 
repositories when deploying artifacts or downloading artifacts. Nothing would 
ever get built as a snapshot, even if your pom has snapshot versions. In CD 
mode, you always use the latest release artifact of your dependencies. You 
could never pull artifacts from a snapshot repository in this mode.

So, for example lets my project's version iss 1.0-SNAPSHOT. When I do:

mvn deploy

it would deploy release 1.0-0001 to the release repo.

If my project had any snapshot dependencies, it wouldn't have to checkout and 
rebuild these. Those dependencies would also have to be in CD mode and all 
artifacts would have to be to the release repo. So if my project has a 
dependency on some artifact with version:

3.2-SNAPSHOT

while in CD mode, maven would query the release repo, find the latest release 
artifact (say 3.2-0122) and use that.

This would of course fill up your release repo but I think you would need to 
think of a release repo a little differently if your doing CD.

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Tuesday, November 09, 2010 4:24 AM
 To: Maven Users List
 Subject: Re: Continuous Delivery and Maven
 
 I think some of the issues are around missuse of Maven.
 
 Maven is a build tool, use it to do your build.
 
 CD needs a separate layer above Maven to do the deployment... now one
 could use maven plugins to provide that layer, but there are two
 issues I see:
 
 1. the maven lifecycle does not include the phases you require
 
 2. inbetween invokations of maven, we have no means to share state
 
 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... ok, so
 people would have to get used to the fact that Maven uses deploy to
 mean copy artifact to remote maven repo and not the CD meaning of
 deploy... but people can Just Get Over It(TM)
 
 that allows any build to just go
 
 mvn clean ship
 
 and away we go... except that we would be dealing with -SNAPSHOTs...
 
 so to correct for that we would change the release goals using the
 release plugin to be ship in place of deploy... to gain speed (at
 the expense of better tested releases), we could even modify the
 preparation goals using the release plugin to be just clean validate
 and not clean verify
 
 then
 
 mvn release:prepare
 
 would be quick
 
 mvn release:perform
 
 would do the CD
 
 H... most of this is actually fine for CD, and we don't even
 really need the ship phase as we could just bind to the deploy phase
 using the release profile to ensure that it only takes place during a
 release...
 
 The down side is we have no way to roll-back easily
 
 e.g. we've just released 2.1.5652 but we have egg on our face due to
 an automated QA test that is giving a false pass... we have no way to
 revert back to 2.1.5651 except:
  A. to revert the commits and roll a new release
  B. put in the 2.1.5651 artifact by hand
 
 we can check-out the tag for 2.1.5651 and run mvn ship -DskipTests
 or mvn deploy -Prelease -DskipTests depending on whether we actually
 got the ship phase into the standard lifecycle or whether we just
 used the release profile to bind to the deploy phase but at the
 end of the day, that would be rebuilding the binaries... which (with a
 strict QA hat on) invalidates testing...
 
 I think what you need to do is have a maven-ship-plugin or a
 ship-maven-plugin that works a little like this:
 
 it takes a parameter shipVersion which by default evaluates the
 property shipVersion, but if that property is not defines then
 defaults to ${project.version}
 
 The m-s-p then resolves the shipVersion of the project artifact and
 passes that file onto a ship script...
 
 so if I have a war project foo:bar:1.0-SNAPSHOT:war
 
 mvn ship:ship -DshipVersion=1.0.56
 
 will redeploy the old version 1.0.56
 
 mvn package ship:ship
 
 will build the current source code and ship that
 
 mvn ship:ship
 
 will resolve the latest 1.0-SNAPSHOT from the local/remote repos and ship
 that
 
 we could add a parameter allowSnapshots that will default to false in
 order to prevent accidental deployment of non-releases
 
 and if you are doing CD you can bind ship:ship to the deploy phase in
 your release profile.
 
 I think I'll knock something together @mojo to help with this
 
 On 8 November 2010 19:20, stug23 pat.poden...@gmail.com wrote:
 
  We need to figure out how to best

Re: Maven integration with bash script

2010-11-09 Thread Jacob Beard



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.


Great links, I think these are both really promising approaches. Thanks 
for the insight.


Jake

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

Re: Eclipse multi-module project with maven

You should create one aggregating Maven project, which is a pom project
which lists your three modules (api, batch, and web).
Then, in the sub-folders stated by your module names, create the Maven
projects that will be creating your jars.

So, in total you will have four Maven projects. This is what's called a
multi-module project which is explained in many places on the Internet.

/Anders

On Tue, Nov 9, 2010 at 14:37, jeb001 jeremy.jar...@gmail.com wrote:

Hi,

So, I've made a maven project including my API project.
In the pom.xml, I just added 2 modules (web and batch).

The problem is right here : both sons project are not compiled. Maybe
should
I add them to the eclipse build path ? I don't really know what' the way...

Thx for your help

--
View this message in context:
http://maven.40175.n5.nabble.com/Eclipse-multi-module-project-with-maven-tp3256822p3256822.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: Eclipse multi-module project with maven


sure, here it is :


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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdfr.gouv.finances.douane.dnsce.mavenProject/groupId
artifactIdMavenProject/artifactId
version1.0.2-SNAPSHOT/version
packagingpom/packaging
nameMavenProject/name

dependencies
!-- dependencies --   
/dependencies

build

resources
resource
directory${basedir}/conf/directory
/resource
/resources
testResources
testResource
directory${basedir}/confTest/directory
/testResource
/testResources


testSourceDirectory${basedir}/JunitSources/testSourceDirectory
outputDirectory${basedir}/classes/outputDirectory
testOutputDirectory${basedir}/classes/testOutputDirectory
plugins
plugin
groupIdorg.codehaus.mojo/groupId

artifactIdbuild-helper-maven-plugin/artifactId
version1.5/version
executions
execution
phasegenerate-sources/phase
goals
goaladd-source/goal
/goals
configuration
sources

source${basedir}/IbatisSources/source   


source${basedir}/PersistanceSources/source

source${basedir}/JavaSources/source
/sources
/configuration
/execution
/executions
/plugin
plugin
artifactIdmaven-compiler-plugin/artifactId
version2.3.1/version
configuration
source1.5/source
target1.5/target
/configuration
/plugin
/plugins
/build

  modules
moduleMavenBatch/module
moduleMavenWeb/module
  /modules
  
/project
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Eclipse-multi-module-project-with-maven-tp3256822p3256864.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: Custom assembly of multi module project

/Anders

On Tue, Nov 9, 2010 at 14:14, jon.mithe jon.mi...@gmail.com wrote:

Hi,

I'm trying to switch over to maven for a project I developing in work, new
to maven and finding packaging it a little tricky.

needs to go to the final package / zipped artifact:

./core.jar
./moduleA.jar
./moduleB.jar
./config/all configs accross all modules
./other_resource_directory/all other resources accross all modules

As I understand, I need to use the maven-assembly-plugin to do most of
this,
and to include the custom directories I need.

Talked to a friend who said maybe this is not quite within the maven way
and
he suggested gradle may be worthwhile looking into but am quite interested
to know if this should be possible in maven.

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

Re: Eclipse multi-module project with maven


Ok, I guess there's a confusion speaking about parent project.. 

In my case, web and batch project needs Api jar file to work.. but, I should
not consider the Api project as the parent ?

By the way, if create one aggregating Maven project listing 3 modules..
should I declare the sourceFolder in the eclipse classPath ?

-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Eclipse-multi-module-project-with-maven-tp3256822p3256876.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: Eclipse multi-module project with maven

Yes, a parent is a pom project. Your api project is a jar project - it
creates a jar.

So create an aggregating project which can also be the parent project. Then
create three jar projects, which are listed as modules.
There are create resources on the Internet explaining all this.

Regarding Eclipse: use m2eclipse and it will take care of everything for
you.

/Anders

On Tue, Nov 9, 2010 at 15:05, jeb001 jeremy.jar...@gmail.com wrote:


 Ok, I guess there's a confusion speaking about parent project..

 In my case, web and batch project needs Api jar file to work.. but, I
 should
 not consider the Api project as the parent ?

 By the way, if create one aggregating Maven project listing 3 modules..
 should I declare the sourceFolder in the eclipse classPath ?

 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Eclipse-multi-module-project-with-maven-tp3256822p3256876.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

Eclipse multi-module project with maven


Hi,

I'm a new user of maven.. I've seen part of response at my question, but
never exactly got
what I expect.
So, before introducing maven into my project, I had 3 differents projects.
The Api, a batch project, and a web project. 
Both web and batch project needs the api.jar to compile. 

So, I've made a maven project including my API project.
In the pom.xml, I just added 2 modules (web and batch).

I understood that with maven, it's better to include the project'son into
the parent. 
I've got now one project including web and batch project.
It's seems to work, when I build it, the batch project make a jar file, and
the web one make a war file.

The problem is right here : both sons project are not compiled. Maybe should
I add them to the eclipse build path ? I don't really know what' the way...

Thx for your help

-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Eclipse-multi-module-project-with-maven-tp3256822p3256822.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: M3 fails to download parent pom

2010-11-09 Thread MK Tan

Have you go through
https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ParentPOMResolution

On Nov 9, 2010 4:37 PM, mjsell mjse...@gmail.com wrote:

 I ran into this today when trying to move to Maven 3.. any news? Has a
 ticket been written?
 --
 View this message in context:
http://maven.40175.n5.nabble.com/M3-fails-to-download-parent-pom-tp3240199p3256007.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: Eclipse multi-module project with maven


Ok, there's no hierarchy in a parent project..

I try to apply your recommendations, thanks for your help,

Jeremy.

-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Eclipse-multi-module-project-with-maven-tp3256822p3256891.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

On 9 November 2010 14:10, Thiessen, Todd (Todd) tthies...@avaya.com wrote:
 Hey Stephen. I read through your idea a little more closely and I like it.

 The only thing I think it is missing is the ability to use snapshots as 
 dependencies. That is a very powerful feature of maven that I don't think 
 you'd want to lose if your using CD.

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

if we develop using

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

when we run the preparation goals in release:prepare, we have the
opertunity to modify the pom and have that modified pom checked in, so
there is nothing stopping us from resolving the range, e.g.

dependency
  groupIdfoo/groupId
  artifactIdbar/artifactId
  version1.1.3/version
/dependency

and now the tag is a locked down reproducible build but the
developer is stuck with the locked down version...

so, if somehow we can tweak things... stick in a comment... or better
yet an XML PI

dependency
  groupIdfoo/groupId
  artifactIdbar/artifactId
  version1.1.3/version
  ?org.codehaus.mojo:versions-maven-plugin range=[1.0,2.0)?
/dependency

then all we need is a postReleaseGoals added to release:prepare and we
can have v-m-p put the version ranges back in...

Which would give you repeatable releases and bleeding edge
dependencies... but only released dependencies.

The problem with -SNAPSHOTs is that they can be deployed without
having passed testing.

MRM staging support is really about having atomic releases of
multi-module artifacts, e.g. make sure they either all get deployed or
none get deployed.

-Stephen


 It is almost like you'd want a mode in Maven. Say you had some kind of flag 
 that said Continuous Delivery mode. In this mode, you would only use 
 release repositories when deploying artifacts or downloading artifacts. 
 Nothing would ever get built as a snapshot, even if your pom has snapshot 
 versions. In CD mode, you always use the latest release artifact of your 
 dependencies. You could never pull artifacts from a snapshot repository in 
 this mode.

 So, for example lets my project's version iss 1.0-SNAPSHOT. When I do:

 mvn deploy

 it would deploy release 1.0-0001 to the release repo.

 If my project had any snapshot dependencies, it wouldn't have to checkout and 
 rebuild these. Those dependencies would also have to be in CD mode and all 
 artifacts would have to be to the release repo. So if my project has a 
 dependency on some artifact with version:

 3.2-SNAPSHOT

 while in CD mode, maven would query the release repo, find the latest release 
 artifact (say 3.2-0122) and use that.

 This would of course fill up your release repo but I think you would need to 
 think of a release repo a little differently if your doing CD.

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Tuesday, November 09, 2010 4:24 AM
 To: Maven Users List
 Subject: Re: Continuous Delivery and Maven

 I think some of the issues are around missuse of Maven.

 Maven is a build tool, use it to do your build.

 CD needs a separate layer above Maven to do the deployment... now one
 could use maven plugins to provide that layer, but there are two
 issues I see:

 1. the maven lifecycle does not include the phases you require

 2. inbetween invokations of maven, we have no means to share state

 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... ok, so
 people would have to get used to the fact that Maven uses deploy to
 mean copy artifact to remote maven repo and not the CD meaning of
 deploy... but people can Just Get Over It(TM)

 that allows any build to just go

 mvn clean ship

 and away we go... except that we would be dealing with -SNAPSHOTs...

 so to correct for that we would change the release goals using the
 release plugin to be ship in place of deploy... to gain speed (at
 the expense of better tested releases), we could even modify the
 preparation goals using the release plugin to be just clean validate
 and not clean verify

 then

 mvn release:prepare

 would be quick

 mvn release:perform

 would do the CD

 H... most of this is actually fine for CD, and we don't even
 really need the ship phase as we could just bind to the deploy phase
 using the release profile to ensure that it only takes place during a
 release...

 The down side is we have no way to roll-back easily

 e.g. we've just released 2.1.5652 but we have egg on our face due to
 an automated QA test that is giving a false pass... we have no way to
 revert

Re: Custom assembly of multi module project

Create a separate project for the config. In Maven, one project = one
artifact. Sure, you can create additional artifacts, but that's the golden
rule.

/Anders

On Tue, Nov 9, 2010 at 15:35, jon.mithe jon.mi...@gmail.com wrote:


 Thanks for the reply.   Yeah that is what I am trying to achieve.  So there
 are no configuration files within the jars and I'm trying to keep the
 configs in the extra folder on the side.  As far as I'm aware maven can
 only
 produce one artifact from the module during the build, so the only way I
 can
 see it will work would be some sort of zip/jar with all the complied jars
 inside + the extra config directories attached on the side.

 Trying to think of ways to simplify the build, but cant see any.

 Hmm.

 Thanks,
 Jon
 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3256929.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: M3 fails to download parent pom

2010-11-09 Thread Martijn Dashorst

Yes, and that doesn't describe our case.

Company wide parent pom, similar to the ASF parent pom. is a separate
svn project, not linked from any reactor.

Project specific parent pom with submodules. Project parent pom
extends company wide parent pom.

New release of company wide parent pom : going from version 1 to version 2.

Project specific parent pom adjusts version for company wide parent
pom from 1 to 2.

Maven 3 fails to build: it doesn't download version 2 of company wide
parent pom.

Martijn

On Tue, Nov 9, 2010 at 3:12 PM, MK Tan mktan...@gmail.com wrote:
 Have you go through
 https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ParentPOMResolution

 On Nov 9, 2010 4:37 PM, mjsell mjse...@gmail.com wrote:

 I ran into this today when trying to move to Maven 3.. any news? Has a
 ticket been written?
 --
 View this message in context:
 http://maven.40175.n5.nabble.com/M3-fails-to-download-parent-pom-tp3240199p3256007.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





-- 
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: Continuous Delivery and Maven


 This was precisely where I was headed.

I was thinking about using version ranges in depMgmnt and *burning lots
of versions in the CI process but having a release plugin that ID's the
version retrieved and re-wrote the POM to be version specific at package
time.

I'm drawn to the idea of using an all Maven solution as opposed to
relying on extracting meta-data from an SCC tool or even a Maven Repo.
Between the help:effective-pom and the dependency-resolve plugins we
should be able to retrieve all of the info we need to packed a fully
baked POM into the artifact itself.




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

-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-tp3245370
p3255592.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: Maven integration with bash script

2010-11-09 Thread Benson Margulies

maven-appassembler-plugin? maven-dependency-plugin, especially
combined with a MANIFEST.MF class path?

On Tue, Nov 9, 2010 at 8:31 AM, Jacob Beard jbea...@cs.mcgill.ca wrote:

 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.

 Great links, I think these are both really promising approaches. Thanks for
 the insight.

 Jake

 -
 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

 
 Does anyone have a reason why Maven snapshots would be useful or
 necessary
 to a project following CD?
 

From what I am understanding from Jez is that it is crucial that your CI built 
with snapshots isn't wasted. That you can treat that build as a release 
without having to rebuild. That I think was the crux of our back and forth 
banter ;-).

I agree that if you used releases only for CD, it makes much more sense. But 
then how do we reconcile the flexibility one gets from working with snapshots?

I think someone else on this thread had a good idea; you'd have your CI/CD 
process automatically cut a release of the core project and all of its snapshot 
transitive dependencies. Once the released CD build is done, it would then have 
to revert itself back to a snapshot and all versions of all transitive 
dependencies that were snapshots back to snapshots.

This would definitely require some work but could be done.

I think the only loose end we have is the ability to promote a CI build (ie: 
something built as a snapshot) to a release build. I don't see a solution to 
that.

-
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-09 Thread Jacob Beard


Hi Ron,

Thanks for the reply.

On 10-11-09 02:06 PM, Ron Wheeler wrote:
If you are using a decent IDE (Eclipse STS for example) with Maven 
support, you should not need any of this.

Maven and Eclipse will get everything you need onto the classpath.

My project is a compiler, so I feel that it's important that it be 
accessible from the command line, just as it's not necessary to fire up 
an Netbeans in order to use javac.


I can think of a hacky solution that might work, which is to pass the 
classpath from Maven to Ant using Maven Ant Tasks, and then allow Ant to 
echo it out. But I was hoping that this might be a solved problem, and 
that there might be a cleaner maven solution to making this work.


I'd appreciate any advice you can offer. Thanks,

Jake

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

RE: Continuous Delivery and Maven

What if you just avoid the check in?  Only package the pom and deploy the jar?




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

-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Tuesday, November 09, 2010 9:32 AM
To: Maven Users List
Subject: Re: Continuous Delivery and Maven

On 9 November 2010 14:10, Thiessen, Todd (Todd) tthies...@avaya.com wrote:
 Hey Stephen. I read through your idea a little more closely and I like it.

 The only thing I think it is missing is the ability to use snapshots as 
 dependencies. That is a very powerful feature of maven that I don't think 
 you'd want to lose if your using CD.

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

if we develop using

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

when we run the preparation goals in release:prepare, we have the opertunity to 
modify the pom and have that modified pom checked in, so there is nothing 
stopping us from resolving the range, e.g.

dependency
  groupIdfoo/groupId
  artifactIdbar/artifactId
  version1.1.3/version
/dependency

and now the tag is a locked down reproducible build but the developer is 
stuck with the locked down version...

so, if somehow we can tweak things... stick in a comment... or better yet an 
XML PI

dependency
  groupIdfoo/groupId
  artifactIdbar/artifactId
  version1.1.3/version
  ?org.codehaus.mojo:versions-maven-plugin range=[1.0,2.0)? /dependency

then all we need is a postReleaseGoals added to release:prepare and we can have 
v-m-p put the version ranges back in...

Which would give you repeatable releases and bleeding edge dependencies... but 
only released dependencies.

The problem with -SNAPSHOTs is that they can be deployed without having passed 
testing.

MRM staging support is really about having atomic releases of multi-module 
artifacts, e.g. make sure they either all get deployed or none get deployed.

-Stephen


 It is almost like you'd want a mode in Maven. Say you had some kind of flag 
 that said Continuous Delivery mode. In this mode, you would only use 
 release repositories when deploying artifacts or downloading artifacts. 
 Nothing would ever get built as a snapshot, even if your pom has snapshot 
 versions. In CD mode, you always use the latest release artifact of your 
 dependencies. You could never pull artifacts from a snapshot repository in 
 this mode.

 So, for example lets my project's version iss 1.0-SNAPSHOT. When I do:

 mvn deploy

 it would deploy release 1.0-0001 to the release repo.

 If my project had any snapshot dependencies, it wouldn't have to checkout and 
 rebuild these. Those dependencies would also have to be in CD mode and all 
 artifacts would have to be to the release repo. So if my project has a 
 dependency on some artifact with version:

 3.2-SNAPSHOT

 while in CD mode, maven would query the release repo, find the latest release 
 artifact (say 3.2-0122) and use that.

 This would of course fill up your release repo but I think you would need to 
 think of a release repo a little differently if your doing CD.

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Tuesday, November 09, 2010 4:24 AM
 To: Maven Users List
 Subject: Re: Continuous Delivery and Maven

 I think some of the issues are around missuse of Maven.

 Maven is a build tool, use it to do your build.

 CD needs a separate layer above Maven to do the deployment... now one 
 could use maven plugins to provide that layer, but there are two 
 issues I see:

 1. the maven lifecycle does not include the phases you require

 2. inbetween invokations of maven, we have no means to share state

 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... ok, 
 so people would have to get used to the fact that Maven uses deploy 
 to mean copy artifact to remote maven repo and not the CD meaning 
 of deploy... but people can Just Get Over It(TM)

 that allows any build to just go

 mvn clean ship

 and away we go... except that we would be dealing with -SNAPSHOTs...

 so to correct for that we would change the release goals using the 
 release plugin to be ship in place of deploy... to gain speed (at 
 the expense of better tested releases), we could even modify the 
 preparation goals using the release plugin to be just clean validate
 and not clean verify

 then

 mvn release:prepare

 would be quick

 mvn

Re: Custom assembly of multi module project

2010-11-09 Thread jon.mithe


Thanks for the reply.   Yeah that is what I am trying to achieve.  So there
are no configuration files within the jars and I'm trying to keep the
configs in the extra folder on the side.  As far as I'm aware maven can only
produce one artifact from the module during the build, so the only way I can
see it will work would be some sort of zip/jar with all the complied jars
inside + the extra config directories attached on the side.

Trying to think of ways to simplify the build, but cant see any.

Hmm.

Thanks,
Jon
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3256929.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

Why bother... the checkin is automatic and actually a good thing IMHO

On 9 November 2010 15:37, Yanko, Curtis curt_ya...@uhc.com wrote:
 What if you just avoid the check in?  Only package the pom and deploy the jar?


 

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

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Tuesday, November 09, 2010 9:32 AM
 To: Maven Users List
 Subject: Re: Continuous Delivery and Maven

 On 9 November 2010 14:10, Thiessen, Todd (Todd) tthies...@avaya.com wrote:
 Hey Stephen. I read through your idea a little more closely and I like it.

 The only thing I think it is missing is the ability to use snapshots as 
 dependencies. That is a very powerful feature of maven that I don't think 
 you'd want to lose if your using CD.

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

 if we develop using

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

 when we run the preparation goals in release:prepare, we have the opertunity 
 to modify the pom and have that modified pom checked in, so there is nothing 
 stopping us from resolving the range, e.g.

 dependency
  groupIdfoo/groupId
  artifactIdbar/artifactId
  version1.1.3/version
 /dependency

 and now the tag is a locked down reproducible build but the developer is 
 stuck with the locked down version...

 so, if somehow we can tweak things... stick in a comment... or better yet an 
 XML PI

 dependency
  groupIdfoo/groupId
  artifactIdbar/artifactId
  version1.1.3/version
  ?org.codehaus.mojo:versions-maven-plugin range=[1.0,2.0)? /dependency

 then all we need is a postReleaseGoals added to release:prepare and we can 
 have v-m-p put the version ranges back in...

 Which would give you repeatable releases and bleeding edge dependencies... 
 but only released dependencies.

 The problem with -SNAPSHOTs is that they can be deployed without having 
 passed testing.

 MRM staging support is really about having atomic releases of multi-module 
 artifacts, e.g. make sure they either all get deployed or none get deployed.

 -Stephen


 It is almost like you'd want a mode in Maven. Say you had some kind of flag 
 that said Continuous Delivery mode. In this mode, you would only use 
 release repositories when deploying artifacts or downloading artifacts. 
 Nothing would ever get built as a snapshot, even if your pom has snapshot 
 versions. In CD mode, you always use the latest release artifact of your 
 dependencies. You could never pull artifacts from a snapshot repository in 
 this mode.

 So, for example lets my project's version iss 1.0-SNAPSHOT. When I do:

 mvn deploy

 it would deploy release 1.0-0001 to the release repo.

 If my project had any snapshot dependencies, it wouldn't have to checkout 
 and rebuild these. Those dependencies would also have to be in CD mode and 
 all artifacts would have to be to the release repo. So if my project has a 
 dependency on some artifact with version:

 3.2-SNAPSHOT

 while in CD mode, maven would query the release repo, find the latest 
 release artifact (say 3.2-0122) and use that.

 This would of course fill up your release repo but I think you would need to 
 think of a release repo a little differently if your doing CD.

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Tuesday, November 09, 2010 4:24 AM
 To: Maven Users List
 Subject: Re: Continuous Delivery and Maven

 I think some of the issues are around missuse of Maven.

 Maven is a build tool, use it to do your build.

 CD needs a separate layer above Maven to do the deployment... now one
 could use maven plugins to provide that layer, but there are two
 issues I see:

 1. the maven lifecycle does not include the phases you require

 2. inbetween invokations of maven, we have no means to share state

 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... ok,
 so people would have to get used to the fact that Maven uses deploy
 to mean copy artifact to remote maven repo and not the CD meaning
 of deploy... but people can Just Get Over It(TM)

 that allows any build to just go

 mvn clean ship

 and away we go... except that we would be dealing with -SNAPSHOTs...

 so to correct for that we would change the release goals using the
 release plugin to be ship in place of deploy... to gain speed (at
 the expense of better tested releases), we could

GAE Service abusing public Maven repos

2010-11-09 Thread Brian Fox

We've just discovered a Google App Engine app called pomyard abusing
several repos. Based on the behavior and name of the service, I have
reason to believe they may be attempting to scrape public all maven
repos not just central, ignoring robots.txt. If you have a public
repo, I suggest you block the user agent shown below.


72.14.194.17
GET /content/groups/sourceforge/net/sf/microlog/microlog-logger-core/2.2.2/
HTTP/1.1 499 0 - AppEngine-Google;
(+http://code.google.com/appengine; appid: pomyard)

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

Re: Custom assembly of multi module project

2010-11-09 Thread jon.mithe

Interesting. I think I have found some unpacking elements in the assembly
plugin when I write my own descriptor. So it may be possible... needs more
research.

I think I understand what you are saying about separating the config from
the binaries. But I'm not sold on the idea of creating it in a different
project. The way I'm trying to do it, the code + the config is completely
separate, i.e. its not jar'ed with the classes and I do not have any issues
with duplication. The code and the config is a tightly linked enitity so I
feel uneasy about splitting them into 2 separate projects (albeit linked by
a dependency).

What concerns me most is I feel that doing it this way would be a work
around for the way maven builds, i.e. I'm starting to think my project does
not seem to fit nicely with maven way of doing things :/

Thanks again for all you help, I'm not giving up on maven yet but I think I
need to take a more in depth look at gradle and see if it fits this any
better.

Thanks,
Jon.

Ron Wheeler wrote:

On 09/11/2010 9:03 AM, Anders Hammar wrote:
I think you should start by separating the configurations from your
binaries. Then it will be so much easier creating the custom zip you
want.
You would also avoid having the configuration files duplicated (like
outisde
the jars as well as inside some of the jars). That will sooner or later
get
you or someone else into trouble.
+1 I have been a victim of this practice. Very unpleasant.
/Anders

On Tue, Nov 9, 2010 at 14:14, jon.mithejon.mi...@gmail.com wrote:

Hi,

I'm trying to switch over to maven for a project I developing in work,
new
to maven and finding packaging it a little tricky.

The app I am writing has a core framework module and then a bunch of
other
modules that provide plugin like functionality. The idea being I can
produce different builds with different combinations of modules /
functionality. The confusing bit is each module specifies its own
configs
+
other config like resources and these must be aggregated together in the
build. So my project:

needs to go to the final package / zipped artifact:

./core.jar
./moduleA.jar
./moduleB.jar
./config/all configs accross all modules
./other_resource_directory/all other resources accross all modules

As I understand, I need to use the maven-assembly-plugin to do most of
this,
and to include the custom directories I need.

I think I need to define each module artifact as a zip file with the
target
jar in it and the 2 folders. Which involves writing an assembly plugin
instance in the plugin management of the parent POM and my own assembly
descriptor. The idea being I can reference the plugin as an artifact in
each of my sub modules, i.e:
pluginartifactIdmodule-bundle/artifactId/plugin.

So I think that may work for each of my sub-modules, but I have no idea
then
how to process these artifacts to aggregate this into a zip in the
format
above. I think the artifact is I would get atm is a jar containing all
the
zipped artifacts from each modules. So when that artifact is being
created
I need to process the zips from the modules / unpackage each module and
copy
configs across etc.

Talked to a friend who said maybe this is not quite within the maven way
and
he suggested gradle may be worthwhile looking into but am quite
interested
to know if this should be possible in maven.

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

--
View this message in context:
http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3257165.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

Because I thought we want to keep the version ranges in SCC for developers and 
just package the POM fully versioned for that build.




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

-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Tuesday, November 09, 2010 11:05 AM
To: Maven Users List
Subject: Re: Continuous Delivery and Maven

Why bother... the checkin is automatic and actually a good thing IMHO

On 9 November 2010 15:37, Yanko, Curtis curt_ya...@uhc.com wrote:
 What if you just avoid the check in?  Only package the pom and deploy the jar?


 

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

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Tuesday, November 09, 2010 9:32 AM
 To: Maven Users List
 Subject: Re: Continuous Delivery and Maven

 On 9 November 2010 14:10, Thiessen, Todd (Todd) tthies...@avaya.com wrote:
 Hey Stephen. I read through your idea a little more closely and I like it.

 The only thing I think it is missing is the ability to use snapshots as 
 dependencies. That is a very powerful feature of maven that I don't think 
 you'd want to lose if your using CD.

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

 if we develop using

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

 when we run the preparation goals in release:prepare, we have the opertunity 
 to modify the pom and have that modified pom checked in, so there is nothing 
 stopping us from resolving the range, e.g.

 dependency
  groupIdfoo/groupId
  artifactIdbar/artifactId
  version1.1.3/version
 /dependency

 and now the tag is a locked down reproducible build but the developer is 
 stuck with the locked down version...

 so, if somehow we can tweak things... stick in a comment... or better 
 yet an XML PI

 dependency
  groupIdfoo/groupId
  artifactIdbar/artifactId
  version1.1.3/version
  ?org.codehaus.mojo:versions-maven-plugin range=[1.0,2.0)? 
 /dependency

 then all we need is a postReleaseGoals added to release:prepare and we can 
 have v-m-p put the version ranges back in...

 Which would give you repeatable releases and bleeding edge dependencies... 
 but only released dependencies.

 The problem with -SNAPSHOTs is that they can be deployed without having 
 passed testing.

 MRM staging support is really about having atomic releases of multi-module 
 artifacts, e.g. make sure they either all get deployed or none get deployed.

 -Stephen


 It is almost like you'd want a mode in Maven. Say you had some kind of flag 
 that said Continuous Delivery mode. In this mode, you would only use 
 release repositories when deploying artifacts or downloading artifacts. 
 Nothing would ever get built as a snapshot, even if your pom has snapshot 
 versions. In CD mode, you always use the latest release artifact of your 
 dependencies. You could never pull artifacts from a snapshot repository in 
 this mode.

 So, for example lets my project's version iss 1.0-SNAPSHOT. When I do:

 mvn deploy

 it would deploy release 1.0-0001 to the release repo.

 If my project had any snapshot dependencies, it wouldn't have to checkout 
 and rebuild these. Those dependencies would also have to be in CD mode and 
 all artifacts would have to be to the release repo. So if my project has a 
 dependency on some artifact with version:

 3.2-SNAPSHOT

 while in CD mode, maven would query the release repo, find the latest 
 release artifact (say 3.2-0122) and use that.

 This would of course fill up your release repo but I think you would need to 
 think of a release repo a little differently if your doing CD.

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Tuesday, November 09, 2010 4:24 AM
 To: Maven Users List
 Subject: Re: Continuous Delivery and Maven

 I think some of the issues are around missuse of Maven.

 Maven is a build tool, use it to do your build.

 CD needs a separate layer above Maven to do the deployment... now 
 one could use maven plugins to provide that layer, but there are two 
 issues I see:

 1. the maven lifecycle does not include the phases you require

 2. inbetween invokations of maven, we have no means to share state

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

release:perform deploy goal fails with duplicate deployment

2010-11-09 Thread Trevor Paterson


Hi

Can anyone tell me if I can change the deploy configuration to prevent
this

In a multi-module project I am getting problems deploying multiple release
artifacts (each module builds 3 artifacts for deployment:  .jar,
-sources.jar and -javadoc.jar )

running mvn release:prepare release:perform on the parent project...

everything proceeds fine until the final repository deployment
(the artifacts build ok in target/checkout/_module_/target)

the main .jar deploys ok, 
then the -sources.jar deploys ok,
but then an attempt is made to deploy the -sources.jar a second time:
causing a build failure 

[INFO] [deploy:deploy {execution: default-deploy}]
Uploading:
http://***:8080/archiva/repository/internal//org/resspecies/resspecies-model/0.13/resspecies-model-0.13.jar
23K uploaded  (resspecies-model-0.13.jar)
[INFO] Uploading project information for resspecies-model 0.13
[INFO] Retrieving previous metadata from archiva.internal
[INFO] Uploading repository metadata for: 'artifact
org.resspecies:resspecies-model'
Uploading:
http://***:8080/archiva/repository/internal//org/resspecies/resspecies-model/0.13/resspecies-model-0.13-sources.jar
17K uploaded  (resspecies-model-0.13-sources.jar)
Uploading:
http://***:8080/archiva/repository/internal//org/resspecies/resspecies-model/0.13/resspecies-model-0.13-sources.jar
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error deploying artifact: Failed to transfer file:
http://***:8080/archiva/repository/internal/org/resspecies/resspecies-model/0.13/resspecies-model-0.13-sources.jar.
Return code is: 409
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/release-perform-deploy-goal-fails-with-duplicate-deployment-tp3257211p3257211.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: release:perform deploy goal fails with duplicate deployment

2010-11-09 Thread Wendy Smoak

On Tue, Nov 9, 2010 at 11:53 AM, Trevor Paterson
trevor.pater...@roslin.ed.ac.uk wrote:

 the main .jar deploys ok,
 then the -sources.jar deploys ok,
 but then an attempt is made to deploy the -sources.jar a second time:
 causing a build failure

That's not normal.  What version of Maven are you using?  Is there
anything in the pom that could be causing it to think there are two
-sources jars?
  From here it looks like the classified source jar has gotten
attached twice, though I'm unsure if that's really possible.

(Meanwhile if you need to get this release out, you can disable the
Archiva feature that prevents overwriting released artifacts
temporarily for that repository.  Ask on the Archiva users list if you
need more help.)

-- 
Wendy

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

Re: Maven release:branch commiting things on tags

2010-11-09 Thread Frederic Camblor

-DupdateWorkingCopyVersion=false doesn't solve the problem.

Just filed a JIRA : http://jira.codehaus.org/browse/MRELEASE-612

On Mon, Nov 8, 2010 at 11:35 PM, Jon Paynter kittl...@gmail.com wrote:


 I ran into simmilar behavior when trying to persuade the plugin to make me
 a
 new branch.  The plugin seems to get very confused when you change the
 default values of updateWorkingCopyVersions or updateBranchVersions.

 I did not get a strait answer so i found another solution here:
 http://mojo.codehaus.org/versions-maven-plugin/

 Definately file an issue.
 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Re-Maven-release-branch-commiting-things-on-tags-tp3247052p3255932.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: Maven release:branch commiting things on tags

2010-11-09 Thread Wendy Smoak

On Tue, Nov 9, 2010 at 12:30 PM, Frederic Camblor fcamb...@gmail.com wrote:
 -DupdateWorkingCopyVersion=false doesn't solve the problem.

 Just filed a JIRA : http://jira.codehaus.org/browse/MRELEASE-612

I linked it to http://jira.codehaus.org/browse/MRELEASE-335 (and
closed it as a duplicate).

-- 
Wendy

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

Re: Custom assembly of multi module project

2010-11-09 Thread Jon Paynter

On Tue, Nov 9, 2010 at 8:34 AM, jon.mithe jon.mi...@gmail.com wrote:


 Interesting.  I think I have found some unpacking elements in the assembly
 plugin when I write my own descriptor.  So it may be possible... needs more
 research.

 I think I understand what you are saying about separating the config from
 the binaries.  But I'm not sold on the idea of creating it in a different
 project.  The way I'm trying to do it, the code + the config is completely
 separate, i.e. its not jar'ed with the classes and I do not have any issues
 with duplication.  The code and the config is a tightly linked enitity so I
 feel uneasy about splitting them into 2 separate projects (albeit linked by
 a dependency).

 What concerns me most is I feel that doing it this way would be a work
 around for the way maven builds, i.e. I'm starting to think my project does
 not seem to fit nicely with maven way of doing things :/

 Thanks again for all you help, I'm not giving up on maven yet but I think I
 need to take a more in depth look at gradle and see if it fits this any
 better.

I recently finished solving a very simmilar problem. with trying to package
things.  Before conversion to maven, the structure looked like this (yes its
using ant)
Parent Project
--Common configs
--Module A
 moduleA.jar
 moduleA.ear
 moduleA.war
 src/config
 build.xml
--Module B
 moduleB.jar
 moduleB.ear
 moduleB.war
 src/config
 build.xml
/dist/ModuleA/ModuleA.ear
/dist/ModuleA/config/
/dist/ModuleB/ModuleB.ear
/dist/ModuleB/config/

Once all the dust settled, I ended up with a structure like this:
Parent Project
--Common Configs
src/main/other_resource_directory

--Module A
src/main/config
ModuleA_jar
---src/main/java
ModuleA_war
---src/main/webapp
ModuleA_ear
---src/main/META-INF
ModuleA_Package
---src/main/assembly
---target/ModuleA.zip

--Module B
src/main/config
ModuleB_jar
---src/main/java
ModuleB_war
---src/main/webapp
ModuleB_ear
---src/main/META-INF
ModuleB_Package
---src/main/assembly
---target/ModuleB.zip

Packaging_project
---target/dist/ModuleA/ModuleA.ear
---target/dist/ModuleA/config/
---target/dist/ModuleB/ModuleB.ear
---target/dist/ModuleB/config/

The key here was first to seperate things out so each project produces
exactly one _binary_ artifact.  Then to seperate the packaging/assembly from
the compiling.

In moduleA_package and moduleB_package, the resulting zip file is marked as
attached, so it gets stored in the repository.
the packaging_project then depends on only whats needed to distribute -
which is just the zip file.  The zip file is unpacked into its proper
directory.

the moduleA_package and moduleB_package are assemblies that do filtering and
copying of the config files.  its not a very elagant solution to the common
configs, but it does work.

Practical to have optional submodules, getting their artifacts from intranet repo if absent?

2010-11-09 Thread KARR, DAVID (ATTSI)


 I currently work on a large enterprise app built with Ant.  The app is
divided into several projects divided into functional areas.  In order
to build the entire EAR, all of the projects have to be built, even if
you're only working on a single one of those projects.

I'm examining how we could make this work better if we were using Maven.

I guess a straightforward implementation of this would have a main
project POM that specifies all the subprojects as submodules, and also
their artifacts as dependencies.

It almost seems to me that what I need is the ability to have the main
POM be somewhat dynamic, such that if I'm only working on a single one
of those subprojects, but I need to assemble the EAR containing all of
the artifacts, then the projects that I don't have checked out would get
their submodule entry temporarily deleted, and I would get their
artifacts from the intranet repo.

I would be using m2eclipse.

Does any of this make sense?

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

Re: Practical to have optional submodules, getting their artifacts from intranet repo if absent?

2010-11-09 Thread Vincent Latombe

What you want can be achieved by having one big aggregator that contains all
your modules and your ears, and use the reactor feature.

By typing mvn -pl my-project:app -am, where my-project:app is the groupId of
your ear, you will actually build the ear and all its transitive
dependencies accross your whole reactor.

I would also add that in an environment where you have continuous
integration, with snapshots deployed regularly on a corporate repository,
the need to build everything from scratch will vanish as you will need to
build only what you changed and its downstream dependencies (-amd is very
useful for that)

Vincent


2010/11/9 KARR, DAVID (ATTSI) dk0...@att.com


  I currently work on a large enterprise app built with Ant.  The app is
 divided into several projects divided into functional areas.  In order
 to build the entire EAR, all of the projects have to be built, even if
 you're only working on a single one of those projects.

 I'm examining how we could make this work better if we were using Maven.

 I guess a straightforward implementation of this would have a main
 project POM that specifies all the subprojects as submodules, and also
 their artifacts as dependencies.

 It almost seems to me that what I need is the ability to have the main
 POM be somewhat dynamic, such that if I'm only working on a single one
 of those subprojects, but I need to assemble the EAR containing all of
 the artifacts, then the projects that I don't have checked out would get
 their submodule entry temporarily deleted, and I would get their
 artifacts from the intranet repo.

 I would be using m2eclipse.

 Does any of this make sense?

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

Re: Practical to have optional submodules, getting their artifacts from intranet repo if absent?

2010-11-09 Thread Ben Caradoc-Davies

You can use profiles to enable the optional building of submodules (you 
can use a top-level aggregating pom if the projects are distinct). Note 
that, if you have built a module locally, maven will use the version 
from your local repo if it is newer than a deployed version. If not 
built locally, maven will download the dependency from a remote repo. I 
think this is what you want.


When you run maven, specify -P options to enable profiles to turn on 
optional submodules. You can have multiple profiles active at once:

http://maven.apache.org/guides/introduction/introduction-to-profiles.html

As an example, GeoTools and GeoServer use profiles to enable the 
building of optional plugins. Here is the pom for unsupported GeoTools 
plugins:

http://svn.osgeo.org/geotools/trunk/modules/unsupported/pom.xml

A similar technique is used for GeoServer extensions:
https://svn.codehaus.org/geoserver/trunk/src/extension/pom.xml

Kind regards,
Ben.

On 10/11/10 06:36, KARR, DAVID (ATTSI) wrote:


  I currently work on a large enterprise app built with Ant.  The app is
divided into several projects divided into functional areas.  In order
to build the entire EAR, all of the projects have to be built, even if
you're only working on a single one of those projects.

I'm examining how we could make this work better if we were using Maven.

I guess a straightforward implementation of this would have a main
project POM that specifies all the subprojects as submodules, and also
their artifacts as dependencies.

It almost seems to me that what I need is the ability to have the main
POM be somewhat dynamic, such that if I'm only working on a single one
of those subprojects, but I need to assemble the EAR containing all of
the artifacts, then the projects that I don't have checked out would get
their submodule entry temporarily deleted, and I would get their
artifacts from the intranet repo.

I would be using m2eclipse.

Does any of this make sense?

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





--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

-
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

But if we do it my way, the tag has the resolved versions, while trunk keeps
the ranges... Best of all worlds ;-)

On 9 Nov 2010 16:21, Yanko, Curtis curt_ya...@uhc.com wrote:

Because I thought we want to keep the version ranges in SCC for developers
and just package the POM fully versioned for that build.





Curt Yanko | Continuous Integration Services | UnitedHealth Grou...

Sent: Tuesday, November 09, 2010 11:05 AM
To: Maven Users List
Subject: Re: Continuous Delivery and ...

Running tests twice and the build success status

2010-11-09 Thread Bogdan Calmac


Our project is configured to run the unit tests twice, with oracle and mssql
databases. This is achieved by configuring two executions of the surefire
plugin and passing in a different system property. Here is the relevant
snippet from the POM:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-surefire-plugin/artifactId
  executions
execution
  iddefault-test/id
  configuration
   
systemPropertyVariablestestDBTypesmssql/testDBTypes/systemPropertyVariables
   
reportsDirectory${project.build.directory}/surefire-reports-mssql/reportsDirectory
  /configuration
/execution
execution
  idoracle/id
  phasetest/phase
  goalsgoaltest/goal/goals
  configuration
   
systemPropertyVariablestestDBTypesoracle/testDBTypes/systemPropertyVariables
   
reportsDirectory${project.build.directory}/surefire-reports-oracle/reportsDirectory
  /configuration
/execution
  /executions
/plugin


This setup works fine but we've recently discovered that the build appears
as successful when the mssql tests pass and the oracle tests fail. The build
continues and the artifacts are deployed as if nothing happened. It looks
like the mssql execution sets some flag that tests passed and it doesn't
matter what happens with the oracle execution.

Any idea how to get the build to fail when either of the test executions
fail (which is the common-sense expectation)?

Could this be just a bug or are we abusing surefire with this kind of
configuration?

We are using maven 2.2.1, surefire 2.6 and testng 5.14.1

Also, here is the relevant console output for the build:

[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
c:\hudson\jobs\commons\workspace\target\surefire-reports-mssql

---
 T E S T S
---
Running TestSuite
...
Tests run: 374, Failures: 0, Errors: 0, Skipped: 0

[HUDSON] Recording test results
[INFO] [surefire:test {execution: oracle}]
[INFO] Surefire report directory:
c:\hudson\jobs\commons\workspace\target\surefire-reports-oracle

---
 T E S T S
---
Running TestSuite
Tests run: 374, Failures: 2, Errors: 0, Skipped: 0

[ERROR] There are test failures.

Please refer to
c:\hudson\jobs\commons\workspace\target\surefire-reports-oracle for the
individual test results.
[HUDSON] Recording test results
[INFO] [jar:jar {execution: default-jar}]
[INFO] [install:install {execution: default-install}]
[INFO] [deploy:deploy {execution: default-deploy}]
Uploading:
http://hudson/nexus/content/repositories/snapshots/com/knoa/knoa-commons/5.6.3-SNAPSHOT/knoa-commons-5.6.3-SNAPSHOT-sources.jar
221K uploaded  (knoa-commons-5.6.3-SNAPSHOT-sources.jar)
[INFO]

[INFO] BUILD SUCCESSFUL
[INFO]

[INFO] Total time: 10 minutes 16 seconds
[INFO] Finished at: Tue Nov 09 15:05:44 EST 2010
[INFO] Final Memory: 19M/47M
[INFO]


-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Running-tests-twice-and-the-build-success-status-tp3257693p3257693.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: Running tests twice and the build success status

You might be better served with the maven-failsafe-plugin as you want
to decouple running tests from failing the build (i.e. you want to run
all tests and then fail the build)

Also, if you are using a real database, they sound more like
integration tests... again a use case for m-f-p

But having said all that, I don't see why what you are trying to do
shouldn't work with m-s-p

-Stephen

On 9 November 2010 21:17, Bogdan Calmac bcal...@gmail.com wrote:

 Our project is configured to run the unit tests twice, with oracle and mssql
 databases. This is achieved by configuring two executions of the surefire
 plugin and passing in a different system property. Here is the relevant
 snippet from the POM:

            plugin
              groupIdorg.apache.maven.plugins/groupId
              artifactIdmaven-surefire-plugin/artifactId
              executions
                execution
                  iddefault-test/id
                  configuration

 systemPropertyVariablestestDBTypesmssql/testDBTypes/systemPropertyVariables

 reportsDirectory${project.build.directory}/surefire-reports-mssql/reportsDirectory
                  /configuration
                /execution
                execution
                  idoracle/id
                  phasetest/phase
                  goalsgoaltest/goal/goals
                  configuration

 systemPropertyVariablestestDBTypesoracle/testDBTypes/systemPropertyVariables

 reportsDirectory${project.build.directory}/surefire-reports-oracle/reportsDirectory
                  /configuration
                /execution
              /executions
            /plugin


 This setup works fine but we've recently discovered that the build appears
 as successful when the mssql tests pass and the oracle tests fail. The build
 continues and the artifacts are deployed as if nothing happened. It looks
 like the mssql execution sets some flag that tests passed and it doesn't
 matter what happens with the oracle execution.

 Any idea how to get the build to fail when either of the test executions
 fail (which is the common-sense expectation)?

 Could this be just a bug or are we abusing surefire with this kind of
 configuration?

 We are using maven 2.2.1, surefire 2.6 and testng 5.14.1

 Also, here is the relevant console output for the build:

 [INFO] [surefire:test {execution: default-test}]
 [INFO] Surefire report directory:
 c:\hudson\jobs\commons\workspace\target\surefire-reports-mssql

 ---
  T E S T S
 ---
 Running TestSuite
 ...
 Tests run: 374, Failures: 0, Errors: 0, Skipped: 0

 [HUDSON] Recording test results
 [INFO] [surefire:test {execution: oracle}]
 [INFO] Surefire report directory:
 c:\hudson\jobs\commons\workspace\target\surefire-reports-oracle

 ---
  T E S T S
 ---
 Running TestSuite
 Tests run: 374, Failures: 2, Errors: 0, Skipped: 0

 [ERROR] There are test failures.

 Please refer to
 c:\hudson\jobs\commons\workspace\target\surefire-reports-oracle for the
 individual test results.
 [HUDSON] Recording test results
 [INFO] [jar:jar {execution: default-jar}]
 [INFO] [install:install {execution: default-install}]
 [INFO] [deploy:deploy {execution: default-deploy}]
 Uploading:
 http://hudson/nexus/content/repositories/snapshots/com/knoa/knoa-commons/5.6.3-SNAPSHOT/knoa-commons-5.6.3-SNAPSHOT-sources.jar
 221K uploaded  (knoa-commons-5.6.3-SNAPSHOT-sources.jar)
 [INFO]
 
 [INFO] BUILD SUCCESSFUL
 [INFO]
 
 [INFO] Total time: 10 minutes 16 seconds
 [INFO] Finished at: Tue Nov 09 15:05:44 EST 2010
 [INFO] Final Memory: 19M/47M
 [INFO]
 

 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/Running-tests-twice-and-the-build-success-status-tp3257693p3257693.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: Practical to have optional submodules, getting their artifacts from intranet repo if absent?

I have used profiles activated by the presence of the pom.xml file in
the sub-module

so you have

if A/pom.xml exists then add module A
if B/pom.xml exists then add module B

-Stephen

On 9 November 2010 20:59, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
 You can use profiles to enable the optional building of submodules (you can
 use a top-level aggregating pom if the projects are distinct). Note that, if
 you have built a module locally, maven will use the version from your local
 repo if it is newer than a deployed version. If not built locally, maven
 will download the dependency from a remote repo. I think this is what you
 want.

 When you run maven, specify -P options to enable profiles to turn on
 optional submodules. You can have multiple profiles active at once:
 http://maven.apache.org/guides/introduction/introduction-to-profiles.html

 As an example, GeoTools and GeoServer use profiles to enable the building of
 optional plugins. Here is the pom for unsupported GeoTools plugins:
 http://svn.osgeo.org/geotools/trunk/modules/unsupported/pom.xml

 A similar technique is used for GeoServer extensions:
 https://svn.codehaus.org/geoserver/trunk/src/extension/pom.xml

 Kind regards,
 Ben.

 On 10/11/10 06:36, KARR, DAVID (ATTSI) wrote:

  I currently work on a large enterprise app built with Ant.  The app is
 divided into several projects divided into functional areas.  In order
 to build the entire EAR, all of the projects have to be built, even if
 you're only working on a single one of those projects.

 I'm examining how we could make this work better if we were using Maven.

 I guess a straightforward implementation of this would have a main
 project POM that specifies all the subprojects as submodules, and also
 their artifacts as dependencies.

 It almost seems to me that what I need is the ability to have the main
 POM be somewhat dynamic, such that if I'm only working on a single one
 of those subprojects, but I need to assemble the EAR containing all of
 the artifacts, then the projects that I don't have checked out would get
 their submodule entry temporarily deleted, and I would get their
 artifacts from the intranet repo.

 I would be using m2eclipse.

 Does any of this make sense?

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




 --
 Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
 Software Engineering Team Leader
 CSIRO Earth Science and Resource Engineering
 Australian Resources Research Centre

 -
 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: Running tests twice and the build success status

2010-11-09 Thread Bogdan Calmac


No, I don't necessarily want to decouple the tests from the build. It's also
OK if the build fails after running only the mssql tests. The only thing is
that I don't want the build to succeed when after of the test executions
failed.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Running-tests-twice-and-the-build-success-status-tp3257693p3257729.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

maven site broken on table generation

2010-11-09 Thread Huang, Thomas (388J)

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

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


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: Running tests twice and the build success status

By decouple, I mean decouple failing from running... i.e. run tests, run
tests, check tests, check tests... Not run tests, check tests, run tests,
check tests

On 9 Nov 2010 21:43, Bogdan Calmac bcal...@gmail.com wrote:


No, I don't necessarily want to decouple the tests from the build. It's also
OK if the build fails after running only the mssql tests. The only thing is
that I don't want the build to succeed when after of the test executions
failed.
--
View this message in context:
http://maven.40175.n5.nabble.com/Running-tests-twice-and-the-build-success-status-tp3257693p3257729.html

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

---...

Possible to override standard Plexus component from build extension?

2010-11-09 Thread Jesse Glick

I am interested in experimenting with whether a plugin running in Maven 3 and declared as a build extension can *replace* a standard service. In particular, I would like 
to replace DefaultProjectDependenciesResolver with a variant that behaves specially on certain kinds of dependency artifacts (does not resolve them transitively). But I 
cannot find any documentation anywhere on how to do this, or whether it is even possible. So far what I tried was to create a class in the extension


@Component(role=ProjectDependenciesResolver.class)
public class ... implements ProjectDependenciesResolver {...}

But its methods do not seem to be called. Adding hint=default or 
hint=override does not help.

I have seen scm-changes-maven-extension, but this works (I suppose) because PlexusContainer.lookupList finds all available implementations. I am rather interested in 
forcing '@Requirement ProjectDependenciesResolver dependencyResolver' in DefaultProjectBuilder to find my resolver instead of the usual single implementation.


Is there some magic I am missing? Or some way to debug why sisu-inject-plexus 
finds one impl and not another?


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

Developing MOJOs using JSR-330

2010-11-09 Thread Christopher Hunt

Hi there,

Is it possible to develop MOJOs with JSR-330 dependency injection, and thereby 
not depend on Plexus? If so then will Maven 2 be able to host JSR-330 MOJOs?

There's not a lot of doco on this... all that I could find was how to write a 
MOJO using Plexus:

http://maven.apache.org/guides/plugin/guide-java-plugin-development.html

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

Re: Developing MOJOs using JSR-330

2010-11-09 Thread Olivier Lamy

Hi,
Using @Inject will work only with maven 3. You can inject a Plexus
composent using it.

But not sure it's a good design to mix stuff.

2010/11/10 Christopher Hunt hu...@internode.on.net:
 Hi there,

 Is it possible to develop MOJOs with JSR-330 dependency injection, and 
 thereby not depend on Plexus? If so then will Maven 2 be able to host JSR-330 
 MOJOs?

 There's not a lot of doco on this... all that I could find was how to write a 
 MOJO using Plexus:

 http://maven.apache.org/guides/plugin/guide-java-plugin-development.html

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





-- 
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy

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

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

2010-11-09 Thread Benjamin Bentmann


Jesse Glick wrote:


I am interested in experimenting with whether a plugin running in Maven
3 and declared as a build extension can *replace* a standard service.


Not possible.


I would like to replace DefaultProjectDependenciesResolver
with a variant that behaves specially on certain kinds of dependency
artifacts (does not resolve them transitively).


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



Benjamin

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

Re: Developing MOJOs using JSR-330

2010-11-09 Thread Christopher Hunt

Thanks Oliver.

I think that it'll be quite a while before people write MOJOs just for Maven 3. 
From my own perspective having just written two new MOJOs, I'd like to be able 
to write for the future but recognise the present. It'd be great to use @inject 
in my code now and then use the MOJO with Maven 2. Not possible?

I really find Plexus tricky to work with given the lack of documentation and 
would prefer to use JSR-330 (as Maven 3 itself does!).

Kind regards,
Christopher

On 10/11/2010, at 10:38 AM, Olivier Lamy wrote:

 Hi,
 Using @Inject will work only with maven 3. You can inject a Plexus
 composent using it.
 
 But not sure it's a good design to mix stuff.


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

Re: Continuous Delivery and Maven

2010-11-09 Thread Graham Leggett


On 08 Nov 2010, at 7:03 PM, jhumble wrote:

Two reasons: one, the faster you get feedback on the part of the  
story you
have done so far, the faster you know if any further work is going  
to be

valuable, and what in fact the next most valuable thing to deliver is.


How do you handle branches?

Second, most of the pain of the software delivery process comes  
*after* the
software is dev-complete, during testing and deployment (often  
called the

last mile). One of the important points of cd is that by creating
deployable software with every commit, you avoid the pain at the end  
of the

delivery process.


We have an alternative approach to this that we've found works just as  
well if not better - we require our developers to integrate their own  
code into a package. Until the code has been packaged, the developer  
is not done. We've chosen RPM as our packaging format, but any format  
that is deployable atomically will do.


We have further automated the deployments so that the packages are  
built in dedicated CI instances, in the process making it impossible  
for anyone to deploy anything that hasn't come out of source control  
first - no dodgy working copy builds or manual tweaking.


We've banned deployment documentation - if you want it installed, you  
have to roll it into your package. If you want anything more  
sophisticated than deploy this RPM, graceful restart this service,  
you have to justify it.


We've found that doing this reduced costs on our platform by about an  
order of magnitude.


Regards,
Graham
--


-
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