Re: Clarification on dependencyManagement
NO, ;) , not all dependencies in the parent should be dependencies of the child, that is completely up to the child project. For example, in the parent pom you have defined the depManagement for Hibernate, Spring-MVC and commons-validator. You have different child modules: project-web, project-model and project-data. Project-web should have a dependency on spring-mvc and commons-validator, project-data on hibernate and project-model on commons-validator. You set the version numbers in the parent pom and define the exact dependencies in the child poms. Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Fri, May 1, 2009 at 1:41 AM, Grant Rettke wrote: > My understanding is YES, because if you were to enter them in the > dependencies section, they they would automatically be dependencies in > the child POM, too. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: versus
> EJC - woah - so if you have to deploy this web app to say, 20 or 30 > different servers across multiple environments, you pack all that > configuration in this war? Say your war is 150 mb, you really want to > rebuild it each time someone corrects a setting? We don't here, but > that's another story. No, the war file stays the same, the configuration files we need for the different environments (OTAP) are inside the tar.gz file. I hope I can get it a bit clear by example. Our tar.gz looks like: - deploy - app.war - config - dev - config-file.properties - log4j.properties - test - config-file.properties - log4j.properties - acceptance ... you get the idea... - documentation - deployment-document - static - static.resources.tar.gz (to be deployed on the apache server) So, the war deployed to each environment is the same, the property files differ, but are still in our version system and delivered for each environment. > EJC - we're already on divergent paths - we have a bunch of > configuration inside the web.xml. Also, I'm not about to unpack > something just to change a few things and then repack an archive during > deployment. I guess we have a bit of misunderstanding. We don't unpack the war file, we pack the war file with a bunch of other files we have to deliver to the administrators. The war file stays the same for all environments. > Why duplicate the resource copying in the assembly descriptor? We don't duplicate resource copying, they are different resources. Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Thu, Apr 30, 2009 at 8:55 PM, EJ Ciramella wrote: > > Resources are included in your jar/war file, while an assembly creates a > zip or tar.gz file > > EJC - yep - I got that, but both the resources stanza and the assembly > descriptor(s) can filter files. We have a process where we want the > build to generate a war file, but hand that off to another custom, > in-house plugin to generate an ear file. > > for example we create a tar.gz with our final war file > > EJC - we're already on divergent paths - we have a bunch of > configuration inside the web.xml. Also, I'm not about to unpack > something just to change a few things and then repack an archive during > deployment. > > , the configuration files for the different environments > > EJC - woah - so if you have to deploy this web app to say, 20 or 30 > different servers across multiple environments, you pack all that > configuration in this war? Say your war is 150 mb, you really want to > rebuild it each time someone corrects a setting? We don't here, but > that's another story. > > , some static resources which are deployed somewhere else > > EJC - like web tier items? This is getting off the subject a bit. > > and the deployment documents. > > EJC - our apps are all internally consumed (live site), we have our site > output generating the deployment notes in a separate mvn build > structure. > > So the administrators have all the files they need to deploy our > application. Filtering is used inside the war file, to display the > current version on a status page. Two different things. > > > EJC - So this leaves my question still open and unanswered. Why have a > target/scripts directory when you can have a > target/appName-version-dev/scripts where the appName-version-dev > directory matches 100% what your deployed app looks like? Why duplicate > the resource copying in the assembly descriptor? > > > - > 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: Problem with parent-pom and referencing version classifier
A dependency is identified by three things: groupId, artifactId and classifier. Only the version is configured by dependencyManagement. So you can say: I want this artifact (groupId, artifactId, classifier) and let my parent decide which version I get. With regards, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Thu, Apr 30, 2009 at 5:21 PM, Grant Rettke wrote: > On Wed, Apr 29, 2009 at 10:26 AM, Nick Stolwijk > wrote: >> You have to specify the classifier in the dependencymanagement section >> as well as in the dependency section as it identifies the dependency. > > Why do you have to put it both places? > > By doing so, won't the children inherit the dependency, and thus, not > need to utilize dependencyManagement? > > - > 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
Clarification on dependencyManagement
Hi folks, When you use the dependencyManagement section in a parent POM, its purpose is to allow for children to optionally specify those entries dependencies, without a version number. It is a convenience. When you specify them, though, are you making those entries serve as dependencies for the POM in which they are defined? My understanding is YES, because if you were to enter them in the dependencies section, they they would automatically be dependencies in the child POM, too. Best wishes, Grant - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: build with ant, install with maven
Perfect. Thank you. From: Wayne Fay To: Maven Users List Sent: Thursday, April 30, 2009 11:19:15 AM Subject: Re: build with ant, install with maven > Is there a good way to install additional files (jars) during the install > phase of pom packaging? Should I be approaching this problem in a different > way? Its possible the build-helper-maven-plugin could help in this case, but I'm not certain. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to conditionally classes from the generated JAR?
On Wed, Apr 22, 2009 at 2:21 PM, Stephen Connolly wrote: > put the exclusion in a profile I was hoping to exclude by default, and have the profile include: but I see that exclude trumps include! :) I will have to work around this. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: versus
Resources are included in your jar/war file, while an assembly creates a zip or tar.gz file EJC - yep - I got that, but both the resources stanza and the assembly descriptor(s) can filter files. We have a process where we want the build to generate a war file, but hand that off to another custom, in-house plugin to generate an ear file. for example we create a tar.gz with our final war file EJC - we're already on divergent paths - we have a bunch of configuration inside the web.xml. Also, I'm not about to unpack something just to change a few things and then repack an archive during deployment. , the configuration files for the different environments EJC - woah - so if you have to deploy this web app to say, 20 or 30 different servers across multiple environments, you pack all that configuration in this war? Say your war is 150 mb, you really want to rebuild it each time someone corrects a setting? We don't here, but that's another story. , some static resources which are deployed somewhere else EJC - like web tier items? This is getting off the subject a bit. and the deployment documents. EJC - our apps are all internally consumed (live site), we have our site output generating the deployment notes in a separate mvn build structure. So the administrators have all the files they need to deploy our application. Filtering is used inside the war file, to display the current version on a status page. Two different things. EJC - So this leaves my question still open and unanswered. Why have a target/scripts directory when you can have a target/appName-version-dev/scripts where the appName-version-dev directory matches 100% what your deployed app looks like? Why duplicate the resource copying in the assembly descriptor? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there a way to exclude a inherited dependency?
Thanks everyone for your suggestions. As I expected there is no way to do it, its just a matter of finding the better alternative then. For me these alternatives are not so good. Perhaps when there is a LOT of common dependencies it makes sense to create a project for them. The "provided" does not apply since my dependency declaration is in my parent pom. Right now I just rather remove my dependencies from the parent pom. dahoffer wrote: > > Okay, I think I'll move them out of the parent. > > -Dave > > On Wed, Apr 29, 2009 at 12:27 PM, Nick Stolwijk > wrote: > >> Short of not doing it, as it is not "the right way", you can always >> put those dependencies on provided to not include them in any final >> artifacts. Maybe, somewhere down the line you will start experience >> other strange behaviour, like some dependencies which should be >> included aren't anymore. >> >> Ie. project A and B has the same dependency (call it X) and it is >> marked as provided by A, but not by B. When you start having B as a >> dependency of A, X will be marked by A as provided instead of >> included. >> >> Hth, >> >> Nick Stolwijk >> ~Java Developer~ >> >> Iprofs BV. >> Claus Sluterweg 125 >> 2012 WS Haarlem >> www.iprofs.nl >> >> >> >> On Wed, Apr 29, 2009 at 8:13 PM, David Hoffer wrote: >> > I have a similar use case. In a multi-module build all but two of the >> > modules have the same base dependency so they are specified in the >> parent >> > pom. However I really don't want those dependencies in the two >> modules, >> so >> > how can I exclude them? >> > >> > (BTW, my use case is a Java project that has a couple of Flex modules, >> > obviously Flex doesn't need the otherwise global log4j dependency.) >> > >> > Short of not putting any dependencies in the parent how can I exclude >> them? >> > >> > -Dave >> > >> > On Wed, Apr 29, 2009 at 11:58 AM, Nick Stolwijk >> > >wrote: >> > >> >> > Hi, I have a common POM to all my projects. >> >> Each project should have its own POM, with a parent pom hierarchy to >> >> avoid duplication, declare dependencyManagement and plugin >> >> versions/configuration. >> >> >> >> > The problem is that project X cannot use my common POM. >> >> Then let it have its own POM, like each project. >> >> >> >> > I don't think there is an easy solution, >> >> I don't understand your problem, maybe try to better describe the >> >> problem with some code examples (not the whole code!) >> >> >> >> >the closest I could find is to use dependencyManagement instead of >> the >> >> dependency itself. But that > would increase the amount of code. >> >> No, that would decrease the amount of code. You don't have to specify >> >> the version in each POM, but only in your company pom. It is not >> >> logical that each project has exactly the same set of dependencies. >> >> >> >> If you could try to explain what your current setup looks like, maybe >> >> we could give you some pointers how to improve it. >> >> >> >> Hth, >> >> >> >> Nick Stolwijk >> >> ~Java Developer~ >> >> >> >> Iprofs BV. >> >> Claus Sluterweg 125 >> >> 2012 WS Haarlem >> >> www.iprofs.nl >> >> >> >> >> >> >> >> On Wed, Apr 29, 2009 at 7:25 PM, icet wrote: >> >> > Hi, I have a common POM to all my projects. >> >> >> >> - >> >> 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 >> >> > > -- View this message in context: http://www.nabble.com/Is-there-a-way-to-exclude-a-inherited-dependency--tp23296345p23321539.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: build with ant, install with maven
We use the build-helper-maven-plugin to do exactly this. We wrapper the Ant project with basic Maven and then configure the plugin to do the rest. Works a treat -- Robert -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Thursday, April 30, 2009 10:19 AM To: Maven Users List Subject: Re: build with ant, install with maven > Is there a good way to install additional files (jars) during the install > phase of pom packaging? Should I be approaching this problem in a different > way? Its possible the build-helper-maven-plugin could help in this case, but I'm not certain. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: build with ant, install with maven
> Is there a good way to install additional files (jars) during the install > phase of pom packaging? Should I be approaching this problem in a different > way? Its possible the build-helper-maven-plugin could help in this case, but I'm not certain. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency plugin "outputFile" parameter not working...
Because the I end up with other outputs I don't need, like Reactor Summary, BUILD SUCCESSFUL, Sonia Wayne Fay wrote: > >> mvn dependency:tree -DoutputFile:"C:\TMP\out.txt" > > Why not just use "mvn dependency:tree > c:\tmp\out.txt"? > > Wayne > > - > 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://www.nabble.com/dependency-plugin-%22outputFile%22-parameter-not-working...-tp23319273p23320191.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
build with ant, install with maven
Part of our build process includes building a 3rd-party component. The build of this component is in ant, and is very complicated (complicated enough that building this component with maven is not an option). Currently, we use maven-antrun-plugin with subant inside it to start the build. The packaging for the maven build is set to "pom", so that maven doesn't try to compile/jar/install/deploy the code itself, since it won't succeed. This works fine, but we'd really like the artifacts from the ant build to be available in the local respository, as if the whole build were in maven. Currently, we run a separate mvn install:install command to do the installation to the local repository - it would be nice if this were part of the normal lifecycle. Is there a good way to install additional files (jars) during the install phase of pom packaging? Should I be approaching this problem in a different way? The pom that we're using looks something like: 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";> 4.0.0 myGroup ext pom myComponent 1.0 maven-antrun-plugin cleanAnt clean run compileAnt compile run deployAnt install run Thanks. Nolan
Re: dependency plugin "outputFile" parameter not working...
> mvn dependency:tree -DoutputFile:"C:\TMP\out.txt" Why not just use "mvn dependency:tree > c:\tmp\out.txt"? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Environment property for location of settings.xml
Hi, Does anyone know how I could specify the location of settings.xml through an environment variable/property? In my situation, I don't have the ability to specify 'mvn -s /path/to/setting.xml'. I need to specify it through -DsomeEnvProperty= Does anyone know what the name of that property would be? I can't seem to find it anywhere. Does it exist? Thanks, Yaakov.
dependency plugin "outputFile" parameter not working...
Hello All, I'm having trouble re-directing the output of the dependency:tree goal to a file. I use the following on the command-line: mvn dependency:tree -DoutputFile:"C:\TMP\out.txt" As I look into the file only one line is in there (main artifact) and not all the tree... Am I doing something wrong? Anyone else have that problem? I'm using version 2.1 of the plugin Sonia P.S., If I remove the -DoutputFile, then the output on the screen is the correct complete tree -- View this message in context: http://www.nabble.com/dependency-plugin-%22outputFile%22-parameter-not-working...-tp23319273p23319273.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: Multimodule release with same version for everything and dependency version update
Pfff, forget this mail. Just noticed I was actually too blind to see the
error was not the one I wanted to read...
Seems like my "brilliant" idea in the end of the previous mail is already
what is done...
Thanks anyway and sorry for the noise :-).
2009/4/30 Baptiste MATHUS
> Yes, I already tried it, but the release-plugin resolves the current
> revision before release which is still a SNAPSHOT one. So it aborts the
> release saying there's a snapshot dependency to be resolved before...
>
> $ mvn --batch-mode release:clean release:prepare -DdryRun=true
> -DautoVersionSubModules=true -DreleaseVersion=2.3.0 -
> DdevelopmentVersion=2.4.0-SNAPSHOT
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Pom parent des projets "socle"
> [INFO] Socle Technique (projectA)
> [INFO] Socle Fonctionnel (projectB)
> [INFO] Searching repository for plugin with prefix: 'release'.
> [INFO]
>
> [INFO] Building POM parent des projets MM
> [INFO]task-segment: [release:clean, release:prepare] (aggregator-style)
> [INFO]
>
> [INFO] [release:clean]
> [INFO] Cleaning up after release...
> [INFO] [release:prepare]
> [INFO] Verifying that there are no local modifications...
> [INFO] Executing: cmd.exe /X /C "svn --non-interactive status"
> [INFO] Working directory: C:\tests\refacto-multimodules-socle\our-parent
> [INFO] Checking dependencies and plugins for snapshots ...
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Can't release project due to non released dependencies :
> fr.ourcompany:foundation.test:jar:2.3.0-SNAPSHOT:test
> in project 'Socle Fonctionnel'
> (fr.ourcompany:socle-fonctionnel:bundle:2.3.0-SNAPSHOT)
>
> I think the release-plugin should try to detect dependencies that matches
> those currrently in the reactor, and use the releaseVersion if the
> autoVersionSubModules was given. Seems conceptually feasible. What do you
> think?
>
> Cheers.
>
> 2009/4/30 Jasper de Vries
>
> if you make project B dependent on project A with a version of
>> ${project.version} it will inherit the version of the parent pom (just
>> like
>> the build for B does).
>>
>> On Thu, Apr 30, 2009 at 5:05 PM, Baptiste MATHUS wrote:
>>
>> > Hi all,
>> >
>> > I'm currently stuck in a problem of chicken and egg problem. I already
>> read
>> > and thought a lot about it. But as I don't think I'll find the best way
>> > alone, I'm trying the list.
>> >
>> > I've read again the following recent thread
>> > http://www.nabble.com/Version-Number-Inheritance-td23304326.html but if
>> I
>> > read it correctly it doesn't speak about the problem I'm encountering :
>> > managing the dependency versions. Obviously speaking about the
>> dependencies
>> > included in the release being done. I hope I'm being clear :-/.
>> >
>> > Let's explain a bit more the problem with a description and some excerpt
>> of
>> > my poms. I want to release a multimodule project with the same version
>> (as
>> > Spring does, for example. They have a bunch of jars, but they always are
>> > synced with the same 2.5.1 or so when released. It's far simpler to
>> manage
>> > it when you need many jars of org.springframework).
>> > The thing is some of those modules depend on each other. So when
>> releasing
>> > them I want to update the dependencies version when it is one of the
>> > modules
>> > being released.
>> >
>> > And I want to do it with the littlest set of command. For example, with
>> > something like
>> > mvn --batch-mode release:prepare -DautoVersionSubmodules=true
>> > -DreleaseVersion=2.3.0 -DdevelopmentVersion=2.4.0-SNAPSHOT
>> >
>> > But this won't work in one pass currently because of the dependencies
>> > between modules.
>> >
>> > Simplified, it gives the following.
>> > * parent pom
>> > ** projectA
>> > ** projectB, which depends on projectA
>> >
>> > PARENT POM :
>> >
>> >fr.ourcompany
>> >our-parent
>> >2.3.0-SNAPSHOT
>> >pom
>> > ...
>> >
>> > ../projectA
>> > ../projectB
>> >
>> >
>> >
>> > Project A
>> >
>> >
>> >fr.ourcompany
>> >our-parent
>> >2.3.0-SNAPSHOT
>> >../our-parent
>> >
>> >fr.ourcompany
>> >projectA
>> > ...
>> >
>> >
>> > ProjectB
>> >
>> >
>> >fr.ourcompany
>> >our-parent
>> >2.3.0-SNAPSHOT
>> >../our-parent
>> >
>> >fr.ourcompany
>> >projectA
>> >
>> >
>> >
>> >projectA
>> >2.3.0-SNAPSHOT
>> >
>> >
>> > ...
>> >
>> >
>> > When 2.3.0 is released, projectB 2.3.0 must have its dependency to
>> projectA
>> > set to 2.3.0 too. And set to 2.4.0-SNAPSHOT in the next development
>> version
>> > (according to the parameter value up in this mail).
>> >
>> > I feel maven
Re: Multimodule release with same version for everything and dependency version update
Yes, I already tried it, but the release-plugin resolves the current
revision before release which is still a SNAPSHOT one. So it aborts the
release saying there's a snapshot dependency to be resolved before...
$ mvn --batch-mode release:clean release:prepare -DdryRun=true
-DautoVersionSubModules=true -DreleaseVersion=2.3.0 -
DdevelopmentVersion=2.4.0-SNAPSHOT
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Pom parent des projets "socle"
[INFO] Socle Technique (projectA)
[INFO] Socle Fonctionnel (projectB)
[INFO] Searching repository for plugin with prefix: 'release'.
[INFO]
[INFO] Building POM parent des projets MM
[INFO]task-segment: [release:clean, release:prepare] (aggregator-style)
[INFO]
[INFO] [release:clean]
[INFO] Cleaning up after release...
[INFO] [release:prepare]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: cmd.exe /X /C "svn --non-interactive status"
[INFO] Working directory: C:\tests\refacto-multimodules-socle\our-parent
[INFO] Checking dependencies and plugins for snapshots ...
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Can't release project due to non released dependencies :
fr.ourcompany:foundation.test:jar:2.3.0-SNAPSHOT:test
in project 'Socle Fonctionnel'
(fr.ourcompany:socle-fonctionnel:bundle:2.3.0-SNAPSHOT)
I think the release-plugin should try to detect dependencies that matches
those currrently in the reactor, and use the releaseVersion if the
autoVersionSubModules was given. Seems conceptually feasible. What do you
think?
Cheers.
2009/4/30 Jasper de Vries
> if you make project B dependent on project A with a version of
> ${project.version} it will inherit the version of the parent pom (just like
> the build for B does).
>
> On Thu, Apr 30, 2009 at 5:05 PM, Baptiste MATHUS wrote:
>
> > Hi all,
> >
> > I'm currently stuck in a problem of chicken and egg problem. I already
> read
> > and thought a lot about it. But as I don't think I'll find the best way
> > alone, I'm trying the list.
> >
> > I've read again the following recent thread
> > http://www.nabble.com/Version-Number-Inheritance-td23304326.html but if
> I
> > read it correctly it doesn't speak about the problem I'm encountering :
> > managing the dependency versions. Obviously speaking about the
> dependencies
> > included in the release being done. I hope I'm being clear :-/.
> >
> > Let's explain a bit more the problem with a description and some excerpt
> of
> > my poms. I want to release a multimodule project with the same version
> (as
> > Spring does, for example. They have a bunch of jars, but they always are
> > synced with the same 2.5.1 or so when released. It's far simpler to
> manage
> > it when you need many jars of org.springframework).
> > The thing is some of those modules depend on each other. So when
> releasing
> > them I want to update the dependencies version when it is one of the
> > modules
> > being released.
> >
> > And I want to do it with the littlest set of command. For example, with
> > something like
> > mvn --batch-mode release:prepare -DautoVersionSubmodules=true
> > -DreleaseVersion=2.3.0 -DdevelopmentVersion=2.4.0-SNAPSHOT
> >
> > But this won't work in one pass currently because of the dependencies
> > between modules.
> >
> > Simplified, it gives the following.
> > * parent pom
> > ** projectA
> > ** projectB, which depends on projectA
> >
> > PARENT POM :
> >
> >fr.ourcompany
> >our-parent
> >2.3.0-SNAPSHOT
> >pom
> > ...
> >
> > ../projectA
> > ../projectB
> >
> >
> >
> > Project A
> >
> >
> >fr.ourcompany
> >our-parent
> >2.3.0-SNAPSHOT
> >../our-parent
> >
> >fr.ourcompany
> >projectA
> > ...
> >
> >
> > ProjectB
> >
> >
> >fr.ourcompany
> >our-parent
> >2.3.0-SNAPSHOT
> >../our-parent
> >
> >fr.ourcompany
> >projectA
> >
> >
> >
> >projectA
> >2.3.0-SNAPSHOT
> >
> >
> > ...
> >
> >
> > When 2.3.0 is released, projectB 2.3.0 must have its dependency to
> projectA
> > set to 2.3.0 too. And set to 2.4.0-SNAPSHOT in the next development
> version
> > (according to the parameter value up in this mail).
> >
> > I feel maven-release-plugin could handle this quite correctly. What is
> the
> > best way to handle this? Obviously, I'll be happy to write a
> documentation
> > about this kind of release if I'm able to do it.
> > Thanks in advance.
> >
> > Cheers.
> > --
> > Baptiste MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
> >
>
--
Baptiste MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Re: [maven-user] Getting log4j output during unit tests
With a simpler project, using Groovy, I was able to get this work.
Turns out I only need commons-logging at compile scope, and I don't need
log4j at test scope, but it works either way.
My src/test/resources/log4j.properties:
log4j.rootLogger=DEBUG, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%-5p [%t][%d{ISO8601}]
[%C.%M] - %m%n
Not sure why I was having problems before, but thanks for all the
suggestions.
stash1071 wrote:
>
>
> Thanks for getting back to me Dennis. I got to play around with your
> suggestions (but not for as long as I would of liked). log4j is in test
> scope, commons-logging still compile.
>
> Changing commons-logging.properties to use SimpleLog as you suggested does
> not produce any output for me.
> Also, my Cobertura report reports I've hit my logging statements only when
> I set a logger in my test class explicitly:
>
>>>myObjectUnderTest.logger = new SimpleLog(this.class.name)
>>> myObjectUnderTest.logger.level = SimpleLog.LOG_LEVEL_DEBUG
>
>
> I simplified my src/test/resources/log4j.properties to:
>
> log4j.rootLogger=DEBUG, stdout
> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>
> I might be worth mentioning that my test classes are Groovy classes and
> the classes under test are Java?
> Thanks
>
>
> - Original Message
> From: Dennis Lundberg
> To: Maven Users List
> Sent: Thursday, March 5, 2009 4:53:34 PM
> Subject: Re: [maven-user] Getting log4j output during unit tests
>
> John Prystash wrote:
>> I only depend on commons-logging, not log4j. log4j is provided by my
>> container, which is included in the same assembly, so at runtime logging
>> works.
>
> Yes, but your container is not available when surefire runs the tests,
> so you need to add log4j as a test scope dependency in Maven, like you
> have specified a few lines down.
>
>> I have commons-logging at scope compile. Another module that depends on
>> the module in question packages up an assembly that includes all runtime
>> dependencies, which implicitly includes commons-logging.
>>
>> I added src/test/resources/commons-logging.properties as you suggested
>> and then log4j in test scope:
>>
>>
>> log4j
>> log4j
>> 1.2.14
>> test
>>
>>
>> With or without the additional surefire configuration referencing
>> log4j.properties, I unfortunately don't see any output.
>> I could be missing something fundamental here with how these libraries
>> work by chance.
>
> Just to make sure commons-logging is working for you, try this.
>
> Replace the line in commons-logging.properties with this one, to use the
> internal simple logging implementation available in commons-logging:
>
> org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
>
> If that gives you output, then the problem lies with the log4j
> configuration.
>
>>
>>
>>
>> - Original Message
>> From: Dennis Lundberg
>> To: Maven Users List
>> Sent: Wednesday, March 4, 2009 5:50:41 PM
>> Subject: Re: [maven-user] Getting log4j output during unit tests
>>
>> Do you have both commons-logging and log4j as dependencies in your
>> project with the scope test?
>>
>> You could try to add the file
>> src/test/resources/commons-logging.properties
>> with the following single line in it:
>> org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
>>
>> This tells commons-logging to explicitly use log4j as the logging
>> implementation.
>>
>> John Prystash wrote:
>>> Hi, I have some logging statements in my classes under test that would I
>>> like to have run during my unit tests.
>>>
>>> I put a simple log4j.properties file under src/test/resources:
>>>
>>> log4j.rootLogger=DEBUG, stdout
>>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>>> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>>> log4j.appender.stdout.layout.ConversionPattern=%-5p
>>> [%t][%d{ISO8601}] [%C.%M] - %m%n
>>>
>>> When I run mvn test, the file ends up in target/test-classes like I'd
>>> expect, but I see no output from the logging statements when my tests
>>> run.
>>>
>>> There is no src/main/resources/log4j.properties file to conflict with,
>>> but I then explicitly configured the surefire plugin to use
>>> log4j.properties:
>>>
>>>
>>> org.apache.maven.plugins
>>> maven-surefire-plugin
>>> 2.4.3
>>>
>>> true
>>>
>>>
>>> log4j.configuration
>>> file:target/test-classes/log4j.properties
>>>
>>>
>>>
>>>
>>>
>>> With no change. The *output.txt files for my tests were empty.
>>>
>>> I added the following statements to my test setup, I get some output:
>>>
>>> myObjectUnderTest.logger = new SimpleLog(this.class.name)
>>> myObjectUnderTest.log
Re: release:perform of an EAR gives error with maven-source-plugin:2.1
Does the workaround on that page work? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with parent-pom and referencing version classifier
On Wed, Apr 29, 2009 at 10:26 AM, Nick Stolwijk wrote: > You have to specify the classifier in the dependencymanagement section > as well as in the dependency section as it identifies the dependency. Why do you have to put it both places? By doing so, won't the children inherit the dependency, and thus, not need to utilize dependencyManagement? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there a way to exclude a inherited dependency?
On Thu, Apr 30, 2009 at 7:53 AM, Jan Torben Heuer wrote: > I'd go another way: Create some kind of -commons artifact and > depend on it. If many artifacts share the same dependency, there is often > more redundant code that can be refactored this way and makes the whole code > cleaner. This seems like a better approach than inheritance, but I don't see it mentioned much. Even the Sonatype book only mentions it once. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Classifiers and properties
Pom for project A contains:
maven-jar-plugin
${bt.arch}
Pom for project B contains:
com.basistech
utilities
7.0-SNAPSHOT
${bt.arch}
Pom for project C contains:
com.basistech
rlp
7.0-SNAPSHOT
Project C pom also contains setting for bt.arch.
Running mvn for project C (with only project C in reactor) fails, trying to
use the literal string ${bt.arch} to construct pathname. Running mvn
-Dbt.arch=whatever works.
Version is 2.0.9.
Is this normal/expected?
Re: Multimodule release with same version for everything and dependency version update
if you make project B dependent on project A with a version of
${project.version} it will inherit the version of the parent pom (just like
the build for B does).
On Thu, Apr 30, 2009 at 5:05 PM, Baptiste MATHUS wrote:
> Hi all,
>
> I'm currently stuck in a problem of chicken and egg problem. I already read
> and thought a lot about it. But as I don't think I'll find the best way
> alone, I'm trying the list.
>
> I've read again the following recent thread
> http://www.nabble.com/Version-Number-Inheritance-td23304326.html but if I
> read it correctly it doesn't speak about the problem I'm encountering :
> managing the dependency versions. Obviously speaking about the dependencies
> included in the release being done. I hope I'm being clear :-/.
>
> Let's explain a bit more the problem with a description and some excerpt of
> my poms. I want to release a multimodule project with the same version (as
> Spring does, for example. They have a bunch of jars, but they always are
> synced with the same 2.5.1 or so when released. It's far simpler to manage
> it when you need many jars of org.springframework).
> The thing is some of those modules depend on each other. So when releasing
> them I want to update the dependencies version when it is one of the
> modules
> being released.
>
> And I want to do it with the littlest set of command. For example, with
> something like
> mvn --batch-mode release:prepare -DautoVersionSubmodules=true
> -DreleaseVersion=2.3.0 -DdevelopmentVersion=2.4.0-SNAPSHOT
>
> But this won't work in one pass currently because of the dependencies
> between modules.
>
> Simplified, it gives the following.
> * parent pom
> ** projectA
> ** projectB, which depends on projectA
>
> PARENT POM :
>
>fr.ourcompany
>our-parent
>2.3.0-SNAPSHOT
>pom
> ...
>
> ../projectA
> ../projectB
>
>
>
> Project A
>
>
>fr.ourcompany
>our-parent
>2.3.0-SNAPSHOT
>../our-parent
>
>fr.ourcompany
>projectA
> ...
>
>
> ProjectB
>
>
>fr.ourcompany
>our-parent
>2.3.0-SNAPSHOT
>../our-parent
>
>fr.ourcompany
>projectA
>
>
>
>projectA
>2.3.0-SNAPSHOT
>
>
> ...
>
>
> When 2.3.0 is released, projectB 2.3.0 must have its dependency to projectA
> set to 2.3.0 too. And set to 2.4.0-SNAPSHOT in the next development version
> (according to the parameter value up in this mail).
>
> I feel maven-release-plugin could handle this quite correctly. What is the
> best way to handle this? Obviously, I'll be happy to write a documentation
> about this kind of release if I'm able to do it.
> Thanks in advance.
>
> Cheers.
> --
> Baptiste MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>
Re: SNAPSHOT versioning
Hi, Been there, done that, got the T-Shirt as they say :-). The only allowed form is to end with "-SNAPSHOT". So the first two are correct, the third is not. We already used the third form. It works sometimes, but gives some problem for example to download since the SNAPSHOT resolution handling isn't designed for that, from what I remember. Cheers. 2009/4/30 Afkham Azeez > Hi Folks, > What are the valid SNAPSHOT versions from the following? > > 1/ x-1.1.2-SNAPSHOT.jar > 2/ x-SNAPSHOT.jar > 3/ x-1.1.2.SNAPSHOT.jar > > are all 3 of the above valid SNAPSHOTs? > > -- > Thanks > Afkham Azeez > > Blog: http://afkham.org > Developer Portal: http://www.wso2.org > WSAS Blog: http://wso2wsas.blogspot.com > Company: http://wso2.com > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Rép. : SNAPSHOT versioning
I don't think so. Maven have a standard naming for these artifact. And why do you want use a naming "specific" ? The standard is not your "cup of tea" ? You like the difference ? ;-) Florian >>> Afkham Azeez 30.04.2009 16:17 >>> Will Maven automatically update an artifact versioned as x-1.1.2.SNAPSHOT.jar, when an online build is done? Thanks Azeez On Thu, Apr 30, 2009 at 7:36 PM, Florian MULLER wrote: > Hi, > > First one, if you want a versionning, or second if you don't want. The third > is a bad one. > > Florian > Afkham Azeez 30.04.2009 15:48 >>> > Hi Folks, > What are the valid SNAPSHOT versions from the following? > > 1/ x-1.1.2-SNAPSHOT.jar > 2/ x-SNAPSHOT.jar > 3/ x-1.1.2.SNAPSHOT.jar > > are all 3 of the above valid SNAPSHOTs? > > -- > Thanks > Afkham Azeez > > Blog: http://afkham.org > Developer Portal: http://www.wso2.org > WSAS Blog: http://wso2wsas.blogspot.com > Company: http://wso2.com > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Thanks Afkham Azeez Blog: http://afkham.org Developer Portal: http://www.wso2.org WSAS Blog: http://wso2wsas.blogspot.com Company: http://wso2.com GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 - 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: cannot execute "mvn package" command
By default, those proxy lines are COMMENTED out in the XML file with . Make sure you uncomment them, and try mvn -U package. > > ... > Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Multimodule release with same version for everything and dependency version update
Hi all, I'm currently stuck in a problem of chicken and egg problem. I already read and thought a lot about it. But as I don't think I'll find the best way alone, I'm trying the list. I've read again the following recent thread http://www.nabble.com/Version-Number-Inheritance-td23304326.html but if I read it correctly it doesn't speak about the problem I'm encountering : managing the dependency versions. Obviously speaking about the dependencies included in the release being done. I hope I'm being clear :-/. Let's explain a bit more the problem with a description and some excerpt of my poms. I want to release a multimodule project with the same version (as Spring does, for example. They have a bunch of jars, but they always are synced with the same 2.5.1 or so when released. It's far simpler to manage it when you need many jars of org.springframework). The thing is some of those modules depend on each other. So when releasing them I want to update the dependencies version when it is one of the modules being released. And I want to do it with the littlest set of command. For example, with something like mvn --batch-mode release:prepare -DautoVersionSubmodules=true -DreleaseVersion=2.3.0 -DdevelopmentVersion=2.4.0-SNAPSHOT But this won't work in one pass currently because of the dependencies between modules. Simplified, it gives the following. * parent pom ** projectA ** projectB, which depends on projectA PARENT POM : fr.ourcompany our-parent 2.3.0-SNAPSHOT pom ... ../projectA ../projectB Project A fr.ourcompany our-parent 2.3.0-SNAPSHOT ../our-parent fr.ourcompany projectA ... ProjectB fr.ourcompany our-parent 2.3.0-SNAPSHOT ../our-parent fr.ourcompany projectA projectA 2.3.0-SNAPSHOT ... When 2.3.0 is released, projectB 2.3.0 must have its dependency to projectA set to 2.3.0 too. And set to 2.4.0-SNAPSHOT in the next development version (according to the parameter value up in this mail). I feel maven-release-plugin could handle this quite correctly. What is the best way to handle this? Obviously, I'll be happy to write a documentation about this kind of release if I'm able to do it. Thanks in advance. Cheers. -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
archetype:create-from-project works locally, but not in Bamboo
Any idea why Bamboo would be spitting out the following message? Apr-2009 09:58:27 install-core: 29-Apr-2009 09:58:27[mkdir] Created dir: /opt/j2ee/domains/ appfuse.org/builds/webapps/atlassian-bamboo/ data/data-1.2/xml-data/ build-dir/APF-TRUNK/archetypes/ appfuse-core/target/core-archetype 29-Apr-2009 09:58:27 [copy] Copying 27 files to /opt/j2ee/domains/ appfuse.org/builds/webapps/atlassian-bamboo/ data/data-1.2/xml-data/ build-dir/APF-TRUNK/archetypes/ appfuse-core/target/core-archetype 29-Apr-2009 09:58:34 [exec] [INFO] Scanning for projects... 29-Apr-2009 09:58:38 [exec] [INFO] Searching repository for plugin with prefix: 'archetype'. 29-Apr-2009 09:58:40 [exec] [INFO] 29-Apr-2009 09:58:40 [exec] [INFO] Building AppFuse Core Application 29-Apr-2009 09:58:40 [exec] [INFO]task-segment: [archetype:create-from-project] 29-Apr-2009 09:58:40 [exec] [INFO] 29-Apr-2009 09:58:41 [exec] [INFO] [archetype:create-from-project] 29-Apr-2009 09:58:41 [exec] [INFO] 29-Apr-2009 09:58:41 [exec] [ERROR] BUILD ERROR 29-Apr-2009 09:58:41 [exec] [INFO] 29-Apr-2009 09:58:41 [exec] [INFO] Cannot create archetype from this project. 29-Apr-2009 09:58:41 [exec] 29-Apr-2009 09:58:41 [exec] Embedded error: /opt/j2ee/domains/ appfuse.org/builds/webapps/atlassian-bamboo/ data/data-1.2/xml-data/ build-dir/APF-TRUNK/archetypes/ appfuse-core/target/core-archetype/ src/main/archetype/ archetype.properties (No such file or directory) -- View this message in context: http://www.nabble.com/archetype%3Acreate-from-project-works-locally%2C-but-not-in-Bamboo-tp23318184p23318184.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: Rép. : SNAPSHOT versioning
Will Maven automatically update an artifact versioned as x-1.1.2.SNAPSHOT.jar, when an online build is done? Thanks Azeez On Thu, Apr 30, 2009 at 7:36 PM, Florian MULLER wrote: > Hi, > > First one, if you want a versionning, or second if you don't want. The third > is a bad one. > > Florian > Afkham Azeez 30.04.2009 15:48 >>> > Hi Folks, > What are the valid SNAPSHOT versions from the following? > > 1/ x-1.1.2-SNAPSHOT.jar > 2/ x-SNAPSHOT.jar > 3/ x-1.1.2.SNAPSHOT.jar > > are all 3 of the above valid SNAPSHOTs? > > -- > Thanks > Afkham Azeez > > Blog: http://afkham.org > Developer Portal: http://www.wso2.org > WSAS Blog: http://wso2wsas.blogspot.com > Company: http://wso2.com > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Thanks Afkham Azeez Blog: http://afkham.org Developer Portal: http://www.wso2.org WSAS Blog: http://wso2wsas.blogspot.com Company: http://wso2.com GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Rép. : SNAPSHOT versioning
Hi, First one, if you want a versionning, or second if you don't want. The third is a bad one. Florian >>> Afkham Azeez 30.04.2009 15:48 >>> Hi Folks, What are the valid SNAPSHOT versions from the following? 1/ x-1.1.2-SNAPSHOT.jar 2/ x-SNAPSHOT.jar 3/ x-1.1.2.SNAPSHOT.jar are all 3 of the above valid SNAPSHOTs? -- Thanks Afkham Azeez Blog: http://afkham.org Developer Portal: http://www.wso2.org WSAS Blog: http://wso2wsas.blogspot.com Company: http://wso2.com GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 - 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: versus
Well - if you're building an ear or war - what if there are stack specific property files that live inside the war AND property files that live OUTSIDE the war (say in a "config" directory that is a peer of the main server/deploy directory structure)? What if there is another process that has to run against your war artifact (which results in a different type of artifact)? Something, say, post package phase. Why use resources when you can get the same thing from the assembly process? Also, why wouldn't you want the dev runtime env to look as close as possible to an actual deployment? -Original Message- From: Nick Stolwijk [mailto:nick.stolw...@gmail.com] Sent: Wednesday, April 29, 2009 4:12 PM To: Maven Users List Subject: Re: versus Resources are included in your jar/war file, while an assembly creates a zip or tar.gz file, for example we create a tar.gz with our final war file, the configuration files for the different environments, some static resources which are deployed somewhere else and the deployment documents. So the administrators have all the files they need to deploy our application. Filtering is used inside the war file, to display the current version on a status page. Two different things. With regards, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Wed, Apr 29, 2009 at 10:06 PM, EJ Ciramella wrote: > Hello list - quick quesiton (I think) - > > When should one choose to process resources versus using an assembly > descriptor (with filtering on or off - depending on what you want)? > > > - 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
SNAPSHOT versioning
Hi Folks, What are the valid SNAPSHOT versions from the following? 1/ x-1.1.2-SNAPSHOT.jar 2/ x-SNAPSHOT.jar 3/ x-1.1.2.SNAPSHOT.jar are all 3 of the above valid SNAPSHOTs? -- Thanks Afkham Azeez Blog: http://afkham.org Developer Portal: http://www.wso2.org WSAS Blog: http://wso2wsas.blogspot.com Company: http://wso2.com GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Dependency resolution with classifier
Hi,
I'm using Maven 2.1.0, with plugins: Maven WAR, Maven Release & Maven Eclipse.
My question is about the mechanism for resolving dependencies, more precisely
resolution for a dependency with classifier.
I have a multi-projects architecture, with a parent and 5 modules: ejb, web-A,
web-Z, webservices & ear.
With Maven WAR plugin, i "overlaying" the war-A into war-Z, with this
configuration:
Into project-Z (web-Z):
org.apache.maven.plugins
maven-war-plugin
2.1-beta-1
WEB-INF/web.xml,META-INF/**,WEB-INF/classes/**,WEB-INF/lib/**,WEB-INF/conf/**
**/*.html,**/*.js,**/*.jsp,**/*.class,**/*.xls,**/*.tld,**/*.xml,**/*.xlt,**/WEB-INF/lib/agenda-web-*-classes.jar,**/*.css,**/*.properties,**/*.zip,**/*.png,**/*.jpg,**/*.gif,**/*.ico,**/*.txt,**/*.cur,**/*.as
false
${maven.war.webxml}
ch.hcuge.mdt.agenda
agenda-web
webRessources/**
css/**
definitions/**
errors/**
scripts/**
WEB-INF/*.tld
WEB-INF/web.xml
META-INF/**
WEB-INF/lib/**
WEB-INF/classes/**
WEB-INF/conf/**
true
generate-sources
inplace
And I built a jar with all web-A classes as like this:
Into project-A (web-A):
maven-war-plugin
2.1-beta-1
${maven.war.webxml}
/webapp/WEB-INF/lib/**,**/*.jar
/webapp/WEB-INF/lib/**,**/*.jar
true
true
false
In adding an "" to the plugin configuration, i get a
web-A-1.0-SNAPHOT-classes.jar with all Java classes. And after, i use this jar
as dependency of web-Z project, like this:
com.swisscompagny
web-A
${project.parent.version}
classes
This jar is used for the compile phase and like reference in my eclipse project.
Now, after this very long explanation of the context, i can expose my problem.
First, the stuff that works...
I run a "mvn clean install" and my build process is executed successfully, all
dependencies are resolved and the result is right.
After I run a "mvn eclipse:clean eclipse:eclipse", and the result is the same
... SUCCESSFUL!.
Now, I run a "mvn release:clean release:prepare release:perform" and...
FAILURE! Dependencies are not resolved, particularly the
"web-A-1.0-SNAPHOT-classes.jar" artifact. If i remove this dependency, the
release is performed.
---
[WARNING] The dependency: com.swisscompagny:web-A:war:1.0.0-SNAPSHOT can't be
resolved but has been found in the reactor.
This dependency has been excluded from the plugin execution. You should rerun
this mojo after executing mvn install.
[WARNING] The dependency: com.swisscompagny:ejb:ejb:1.0.0-SNAPSHOT can't be
resolved but has been found in the reactor.
This dependency has been excluded from the plugin execution. You should rerun
this mojo after executing mvn install.
[WARNING] The dependency: com.swisscompagny:web-A:war:1.0.0-SNAPSHOT can't be
resolved but has been found in the reactor.
This dependency has been excluded from the plugin execution. You should rerun
this mojo after executing mvn install.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
Re: how to not deploy sources.jar to artifactory
your efforts were appreciated Gord Cody On Thu, Apr 30, 2009 at 9:03 AM, Todd Thiessen wrote: > haha sorry for my long winded reply. I saw the initial question and > didn't read all the discussions in between ;-). Glad to hear to go it > resovled. > > --- > Todd Thiessen > > >> -Original Message- >> From: Gordon Cody [mailto:gc...@zafinlabs.com] >> Sent: Wednesday, April 29, 2009 5:43 PM >> To: Maven Users List >> Subject: Re: how to not deploy sources.jar to artifactory >> >> Thanks Wendy. >> >> We have to do a release in a couple of days so I wont be able >> to verify this till then and of course once I knew what to >> look for I found it in the parameter doc for the release plugin. >> >> Have a great day, Gord >> >> On Wed, Apr 29, 2009 at 5:26 PM, Wendy Smoak wrote: >> > On Wed, Apr 29, 2009 at 1:23 PM, Gordon Cody >> wrote: >> >> I know I read this (on someones blog I think) but did not >> realise I >> >> would need to care until recently and now I cant find how >> to do this. >> >> >> >> The requirement is to not deploy sources.jar to the >> artifactory when >> >> we do mvn release:perform >> > >> > Don't activate the 'release' profile during your release -- that's >> > what has the source and javadoc jars configured. >> > >> > mvn release:perform ... -DuseReleaseProfile=false >> > >> > >> http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html >> > >> > -- >> > Wendy >> > >> > >> - >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> > For additional commands, e-mail: users-h...@maven.apache.org >> > >> > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: how to not deploy sources.jar to artifactory
haha sorry for my long winded reply. I saw the initial question and didn't read all the discussions in between ;-). Glad to hear to go it resovled. --- Todd Thiessen > -Original Message- > From: Gordon Cody [mailto:gc...@zafinlabs.com] > Sent: Wednesday, April 29, 2009 5:43 PM > To: Maven Users List > Subject: Re: how to not deploy sources.jar to artifactory > > Thanks Wendy. > > We have to do a release in a couple of days so I wont be able > to verify this till then and of course once I knew what to > look for I found it in the parameter doc for the release plugin. > > Have a great day, Gord > > On Wed, Apr 29, 2009 at 5:26 PM, Wendy Smoak wrote: > > On Wed, Apr 29, 2009 at 1:23 PM, Gordon Cody > wrote: > >> I know I read this (on someones blog I think) but did not > realise I > >> would need to care until recently and now I cant find how > to do this. > >> > >> The requirement is to not deploy sources.jar to the > artifactory when > >> we do mvn release:perform > > > > Don't activate the 'release' profile during your release -- that's > > what has the source and javadoc jars configured. > > > > mvn release:perform ... -DuseReleaseProfile=false > > > > > http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html > > > > -- > > Wendy > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: how to not deploy sources.jar to artifactory
You get these settings indirectly through POM inheritence. So everything in the super POM [1] you get automatically unless you have explicitly overridden it. Take a look at the section of the super pom. You will see a profile with an ID of release-profile. This is where the source and javadoc plugins are configured. So you can get this behaviour simply by issuing the following mvn command: mvn -DperformRelease=true deploy or mvn -Prelease-profile deploy The release plugin executes this profile during the release:perform goal by setting the performRelease property to true. If you wish to change the behaviour of release:peform, copy this profile to your POM and remove the maven-source-plugin. [1] http://maven.apache.org/pom.html#The_Super_POM --- Todd Thiessen > -Original Message- > From: Gordon Cody [mailto:gc...@zafinlabs.com] > Sent: Wednesday, April 29, 2009 5:15 PM > To: Maven Users List > Subject: Re: how to not deploy sources.jar to artifactory > > Hello Todd > > My apologies as I am just getting to know mvn. > > From my searching, we do not reference the > maven-source-plugin directly anywhere. > I have located the reference to the maven-release-plugin. It > is in our topmost pom.xml and contains only: > > > > org.apache.maven.plugins > maven-release-plugin > > -Dmaven.test.skip=true > > > > > > If I understand what you are saying I need to explicitly > invoke the maven-source-plugin but configure it so that it > does not have specify any goals. Is that correct? > > Appreciating your patience, Gord > > > On Wed, Apr 29, 2009 at 4:28 PM, Todd Thiessen > wrote: > > You can override the "release-profile" profile of the super > pom. Define this profile yourself and ensure that the > maven-source-plugin does not define an execution to build a > sources jar. > > > > --- > > Todd Thiessen > > > > > >> -Original Message- > >> From: Gordon Cody [mailto:gc...@zafinlabs.com] > >> Sent: Wednesday, April 29, 2009 4:23 PM > >> To: users@maven.apache.org > >> Subject: how to not deploy sources.jar to artifactory > >> > >> I know I read this (on someones blog I think) but did not > realise I > >> would need to care until recently and now I cant find how > to do this. > >> > >> The requirement is to not deploy sources.jar to the > artifactory when > >> we do mvn release:perform > >> > >> Thanks in advance for any/all help > >> > >> Regards, Gord > >> > >> -- Forwarded message -- > >> From: Gordon Cody > >> Date: Wed, Apr 29, 2009 at 3:14 PM > >> Subject: Maven inconsistent build with flexbuilder > >> To: Maven Users List > >> > >> > >> Hello > >> > >> Working in release mgmt, one of my many jobs is to ensure > that we can > >> reliably reproduce what will be delivered to a customer. > >> > >> We are using flexbuilder3 in a windows/maven development > environment. > >> I check out the code from svn and run mvn clean install. This > >> generates a war file that contains swf files among other things. > >> I move that war file aside and run mvn clean install a second time. > >> > >> When I compare the 2 wars, I see that the swf files are > different in > >> the 2 versions. > >> As swf files are binary it is extremely difficult to > determine if the > >> only difference between the 2 is timestamps. > >> > >> Please, what can I do to eliminate these differences? > >> > >> Thanks in advance for any help, > >> -Gord > >> > >> > - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there a way to exclude a inherited dependency?
David Hoffer wrote: > I have a similar use case. In a multi-module build all but two of the > modules have the same base dependency so they are specified in the parent > pom. However I really don't want those dependencies in the two modules, > so how can I exclude them? I'd go another way: Create some kind of -commons artifact and depend on it. If many artifacts share the same dependency, there is often more redundant code that can be refactored this way and makes the whole code cleaner. Cheers, Jan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with parent-pom and referencing version classifier
Thanks this worked. this was weirdly the combination I did not try out... Nick Stolwijk-4 wrote: > > You have to specify the classifier in the dependencymanagement section > as well as in the dependency section as it identifies the dependency. > > Hth, > > Nick Stolwijk > ~Java Developer~ > > Iprofs BV. > Claus Sluterweg 125 > 2012 WS Haarlem > www.iprofs.nl > > > > On Wed, Apr 29, 2009 at 4:27 PM, aldana wrote: >> >> Hi, >> >> I am having: >> >> >> net.sf.json-lib >> json-lib >> 2.2.3 >> jdk15 >> >> >> >> I want to keep version information in parent pom in dependency >> management. >> But when extracting this to in parent-pom, I get >> following error: >> >> 'dependencies.dependency.version' is missing for net.sf.json-lib:json-lib >> >> All other dependencies version extractions to parent-pom work. Only this >> json-lib makes problems. I noticed that is the only one with the >> classifier >> information. Could this be the issue. >> >> I can both reproduce on linux with 2.0.9 and 2.1.0. >> >> >> - >> manuel aldana >> aldana((at))gmx.de >> software-engineering blog: http://www.aldana-online.de >> -- >> View this message in context: >> http://www.nabble.com/Problem-with-parent-pom-and-referencing-version-classifier-tp23296079p23296079.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 > > > - manuel aldana aldana((at))gmx.de software-engineering blog: http://www.aldana-online.de -- View this message in context: http://www.nabble.com/Problem-with-parent-pom-and-referencing-version-classifier-tp23296079p23315534.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
Properties from setting.xml are not populated in parent pom
Hi
I have a problem with populating properties wich are set in my settings.xml in
my home directory.
So i have a parent pom, a child pom and the properties that look like:
settings.xml
7.1
parent pom.
id.group
artifactName
${artifact-version}
child pom
id.someOtherGroup
parentpom
1
So if i try to build the child project i get this error message
Downloading:
http://some.repository/id/group/artifactName/${artifact-version}/artifactName-${artifact-version}.pom
[INFO] Unable to find resource 'id.group:artifactName:pom:${artifact-version}'
in repository SomeRepo (Repo URL)
Same error for the try to download the jar file from this project.
If i use mvn help:effective-pom the correct values (in this case 7.1) is shown
there.
If these artifacts are present in my local repository the build will succed,
but if i delete the artifact from the localrepository it will not be
downloaded again except for the case i replace the property with the actual
value in the parent pom.
Does someone has an idea of why this happens?
Geschaeftsfuehrung/Management Board: Heinz-Josef Boeck (Vorsitzender/CEO), Dr.
Dirk Toepfer, Dr. Gerd Wolfram
Sitz Duesseldorf, Amtsgericht Duesseldorf, HRB 18232/Commercial Register of the
Duesseldorf Local Court, HRB 18232
This e-mail message is intended exclusively for the addressee. If the e-mail
was sent to you by mistake, would you please call us immediately? In this case,
we also request you to destroy the e-mail and to neither use the content nor
disclose them in any manner to third parties, because the message can contain
confidential information which may be protected by professional secrecy.
cannot execute "mvn package" command
Hi, i am on the way of installing DSpace 1.5.1 in Debian 5.0. But, i cannot run the command "mvn package" because of proxy issue, i think. When i go for this command, it shows me the error: *dsp...@wsdebianzico:/opt/src/dspace-1.5.1-release/dspace$ mvn package [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] DSpace Addon Modules [INFO] DSpace XML-UI (Manakin) :: Web Application [INFO] DSpace LNI :: Web Application [INFO] DSpace OAI :: Web Application [INFO] DSpace JSP-UI :: Web Application [INFO] DSpace SWORD :: Web Application [INFO] DSpace Assembly and Configuration [INFO] [INFO] Building DSpace Addon Modules [INFO]task-segment: [package] [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.pom Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-site-plugin Reason: POM 'org.apache.maven.plugins:maven-site-plugin' not found in repository: Unable to download the artifact from any repository org.apache.maven.plugins:maven-site-plugin:pom:2.0-beta-6 from the specified remote repositories: central (http://repo1.maven.org/maven2), maven.dspace.org/snapshot (http://maven.dspace.org/snapshot) for project org.apache.maven.plugins:maven-site-plugin [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 7 seconds [INFO] Finished at: Fri May 01 04:39:39 GMT+06:00 2009 [INFO] Final Memory: 11M/20M [INFO] * Here, the point is, i have changed my settings.xml from /etc/maven2/settings.xml with the command: optional true http proxyuser proxypass *http://proxy.bracu.ac.bd 8080 localhost * But, nothing has changed. Can you please help me? -- Best, Zico
Re: Maven inconsistent build with flexbuilder
Ah, those swf files were generated. :) I thought those came from your SVN. Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Wed, Apr 29, 2009 at 10:14 PM, Gordon Cody wrote: > Upon further investigation me thinks this is a flex issue. > > mxmlc x.mxml > > twice in a row is generating different swf files > i have a support call open with them now > > Will let you know what I find out. > > Thanks for your time Nick > > Regards, Gord > > > On Wed, Apr 29, 2009 at 4:05 PM, Nick Stolwijk > wrote: >> Are the differences already present between the original source >> (src/main/resources/ or src/main/webapp) and the files under /target >> (whether in /target/classes or in /target/war)? >> >> With regards, >> >> Nick Stolwijk >> ~Java Developer~ >> >> Iprofs BV. >> Claus Sluterweg 125 >> 2012 WS Haarlem >> www.iprofs.nl >> >> >> >> On Wed, Apr 29, 2009 at 10:02 PM, Gordon Cody wrote: >>> I dont see anything like that in this project. Other projects unrelated to >>> flex >>> do use filtering. >>> >>> -Gord >>> >>> On Wed, Apr 29, 2009 at 3:51 PM, Nick Stolwijk >>> wrote: Could it be that there is some resource filtering going on? [1] [1] http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Wed, Apr 29, 2009 at 9:38 PM, Gordon Cody wrote: > Hi Nick > On Wed, Apr 29, 2009 at 3:21 PM, Nick Stolwijk > wrote: >>> When I compare the 2 wars, I see that the swf files are different in >>> the 2 versions. >> What do you mean by different? >> > When I do a byte by byte comparison large chunks of the files show up > as different > not just the occasional 4 bytes or even a date string. > >>> As swf files are binary it is extremely difficult to determine if the >>> only difference between the 2 is >>> timestamps. >> No, it is not. Just compare their checksums (md5). Maven copies the >> resources to /target before war'ing them, so the timestamps could be >> different. >> >> Another cause may be that due to svn:keywords and properties the files >> indeed are different. Do you have svn:keywords on your binary files? >> > No we are not using svn:keywords , but a good point that I will keep in > mind. > >> Did you do a new checkout? > Even if there were svn:keywords those fields would still have been the > same > in 2 sequential builds since I did not check out the code again. > > Regards Gord > >> >> With regards, >> >> Nick Stolwijk >> ~Java Developer~ >> >> Iprofs BV. >> Claus Sluterweg 125 >> 2012 WS Haarlem >> www.iprofs.nl >> >> >> >> On Wed, Apr 29, 2009 at 9:14 PM, Gordon Cody wrote: >>> When I compare the 2 wars, I see that the swf files are different in >>> the 2 versions. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
release:perform of an EAR gives error with maven-source-plugin:2.1
Hi all! We recently upgrade the maven-source-plugin from version 2.0.4 to 2.1 for a multimodule project (consisting of modules of packaging type jar, war, ejb and ear). No problems so far when doing a "normal build" like mvn install. However, when we do a "mvn release:perform" the EAR module fails with this error: ... [INFO] [source:jar] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error creating source archive: You must set at least one file. This is because the EAR module doesn't contain any sources. We wouldn't need the -sources.jar anyway. Older versions of the maven-source-plugin created an empty archive with an auto-generated MANIFEST.MF file in it, but the 2.1 version fails as already reported in MSOURCES-44 [0]. The question I now have is, why is source:jar mojo executed at all? According to the lifecycle reference [1] this mojo shouldn't be executed (for packaging EAR). How can I deactivate this mojo? thanks in advance, - martin [0] http://jira.codehaus.org/browse/MSOURCES-44 [1] http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference signature.asc Description: This is a digitally signed message part.
Re: default plugin version
Thank you. I shall send a note to maven-antlr-plugin group. Thanks, Sahoo Stephen Connolly wrote: You do not have to specify the version if you are happy with how Maven determines the versions. Also if you do not specify the version your build is not reproducible. Can you please file a JIRA against the antlr-maven-plugin to get the usage page to show the version in accordance with best practice. Thanks, -Stephen P.S. you should not be happy with how maven determines which version of a plugin to use... primarily because it is out of your control and relies on the correct metadata.xml files in the repositories available to you... and if you build a project which has defined additional repositories and those repositories contain different metadata for the same plugin and the project uses that plugin, you can even corrupt the metadata such that your build breaks. Another thing is that for plugins, you really have to follow the maven version number rules or else lock down the version number. 2009/4/30 Sahoo Hi, I always thought I had to specify the version while trying to use a custom plugin, but that seems not to be the case. e.g., see [1] which does not specify the plugin version. In such a case, which version is picked up. Thanks, Sahoo [1] http://mojo.codehaus.org/antlr-maven-plugin/usage.html - 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: mvn eclipse:eclipse - creating psf file
On Thu, Apr 23, 2009 at 3:45 PM, Barrie Treloar wrote: > On Thu, Apr 23, 2009 at 12:56 PM, Vladimir Blagojevic > wrote: >> It allows one to group related projects in eclipse. So, theoretically, after >> creating all projects from pom files in eclipse:eclipse can create psf file. >> Users would them import all these projects in workspace by selecting >> Import->Team Project Set and selecting the psf file. >> >> Should be very cool. I was surprised that this is not implemented already :( > > Yes it would. > I could find no JIRAs raised for this request. > > This would resolve one of my problems with Import existing projects as > there are proof of concept projects in our code base which eclipse > picks up and I have to remember not to select them. > > If I had one file to import that selected the correct projects that > would be better. > I'll see if I have time to look at it. > In the Eclipse Help under Team Project Sets: Programmer's Guide > Team support > Rich Team Integration > Project Sets "In 3.0, API was added to ProjectSetCapability to allow repository providers to declare a class that implements project saving for projects under their control. When the user chooses to export project sets, only the projects configured with repositories that define project sets are shown as candidates for export. This API replaces the old project set serialization API (see below)." Unless I am mistaken it appears the project needs to define a repository, which may not always be the case - and will vary across eclipse plugins installed to support the repository. So mvn eclipse:eclipse can't generate these files. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: default plugin version
You do not have to specify the version if you are happy with how Maven determines the versions. Also if you do not specify the version your build is not reproducible. Can you please file a JIRA against the antlr-maven-plugin to get the usage page to show the version in accordance with best practice. Thanks, -Stephen P.S. you should not be happy with how maven determines which version of a plugin to use... primarily because it is out of your control and relies on the correct metadata.xml files in the repositories available to you... and if you build a project which has defined additional repositories and those repositories contain different metadata for the same plugin and the project uses that plugin, you can even corrupt the metadata such that your build breaks. Another thing is that for plugins, you really have to follow the maven version number rules or else lock down the version number. 2009/4/30 Sahoo > Hi, > > I always thought I had to specify the version while trying to use a custom > plugin, but that seems not to be the case. e.g., see [1] which does not > specify the plugin version. In such a case, which version is picked up. > > Thanks, > Sahoo > > [1] http://mojo.codehaus.org/antlr-maven-plugin/usage.html > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
