Re: How to find out which parameters can be specified as command-line properties?
Look for "Expression" in the docs. For example, the surefire:test skip param: http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#skip /Anders On Sat, Mar 13, 2010 at 03:06, sebb wrote: > Some plugin parameters are settable as command-line properties. > For example, the Surefire plugin accepts the parameter in > the POM and the property -DargLine on the command-line. > > Surefire also accepts and -DskipTests=true. > > However, Surefire accepts the parameter, but ignores -Dskip=true. > > How can one find out which parameters are settable as command-line > properties for a given plugin other than by trial and error? Is there > a rule for this? Or a help command? > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Combining modules' jars into one war ?
Hi I am new to Maven , I have a problem about splitting a project into modules and combining them into WAR. I first build a parent project , naming 'destiny' with a POM (packaging 'pom') , and create 3 modules (sub-projects) : 1st is destiny-core (packaging : jar) : pure POJOs 2nd is destiny-webapp-servlets (packaging : jar) : pure servlets , only depends on javax.servlet , and core 3rd is destiny-wicket (packaging : jar) : wicket apps , depends on apache-wicket , and core The servlets and wicket both share the same web.xml , so I put the web.xml in src/main/webapp/WEB-INF/web.xml I tried to execute maven war:war in the 'destiny' dir , but Maven complained it cannot find web.xml inside destiny-core . Then I executed maven package , and got three jars : destiny-core.jar , destiny-webapp-servlets.jar , destiny-wicket.jar. This is not what I want ... I need the three modules combined into one war , how to accomplish it ? Thanks in advanced...
Re: Setting custom varaibles
Pull the trigger - modularize and move completely to maven 2. On Mar 12, 2010, at 8:05 PM, swaroopgr wrote: Here's why: I'm setting up sonar - a tool for code quality analysis. The way sonar is run is: "mvn sonar:sonar" I'm using ANT to build my project. However, sonar requires a dummy pom.xml file to trick it into saying it's a maven project. Then, Sonar will go and descend into all the directories and complete static code analysis. In my case, I need only specific directories to be analysed by Sonar. Hence, I simply list these directories and feed it into the pom.xml file's property. This will allow sonar to analyse only those modules. Hence, I somehow need to figure out how I can feed these files one by one into pom.xml and call mvn each time. Baptiste MATHUS wrote: Hi, First question: why do you need to do this? Maven defines strong conventions principles over config. So doing what you say seems quite uncommon. So you've got three solutions: * if the project can be cleanly refactored to be built, with clear deps and so on => the way to go * if those source directories comes from a special process (say generation), then maybe the way to go is more writing a maven plugin that will do what you need cleanly (writing a maven plugin is very simple). To help answer this question, I guess you'll have to explain your need a bit more. * combine ant-run plugin/buildhelper should help do the trick, but this would be like using ant to compile when developing under eclipse Cheers 2010/3/12 swaroopgr I'm need to use custom variables in maven. Here's what I do: Run the "ls" command in the current directory. For each directory listed, I want to add the name in pom.xml's $DirectoryName property and run mvn. If there's a way to set name / value pairs during mvn invocation, that would be best. If not, what's the best way to do this? -- View this message in context: http://old.nabble.com/Setting-custom-varaibles-tp27881131p27881131.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 -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! -- View this message in context: http://old.nabble.com/Setting-custom-varaibles-tp27881131p27884743.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
How to find out which parameters can be specified as command-line properties?
Some plugin parameters are settable as command-line properties. For example, the Surefire plugin accepts the parameter in the POM and the property -DargLine on the command-line. Surefire also accepts and -DskipTests=true. However, Surefire accepts the parameter, but ignores -Dskip=true. How can one find out which parameters are settable as command-line properties for a given plugin other than by trial and error? Is there a rule for this? Or a help command? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Setting custom varaibles
Here's why: I'm setting up sonar - a tool for code quality analysis. The way sonar is run is: "mvn sonar:sonar" I'm using ANT to build my project. However, sonar requires a dummy pom.xml file to trick it into saying it's a maven project. Then, Sonar will go and descend into all the directories and complete static code analysis. In my case, I need only specific directories to be analysed by Sonar. Hence, I simply list these directories and feed it into the pom.xml file's property. This will allow sonar to analyse only those modules. Hence, I somehow need to figure out how I can feed these files one by one into pom.xml and call mvn each time. Baptiste MATHUS wrote: > > Hi, > > First question: why do you need to do this? > > Maven defines strong conventions principles over config. So doing what you > say seems quite uncommon. So you've got three solutions: > * if the project can be cleanly refactored to be built, with clear deps > and > so on => the way to go > * if those source directories comes from a special process (say > generation), > then maybe the way to go is more writing a maven plugin that will do what > you need cleanly (writing a maven plugin is very simple). To help answer > this question, I guess you'll have to explain your need a bit more. > * combine ant-run plugin/buildhelper should help do the trick, but this > would be like using ant to compile when developing under eclipse > > Cheers > > 2010/3/12 swaroopgr > >> >> I'm need to use custom variables in maven. Here's what I do: >> >> Run the "ls" command in the current directory. For each directory listed, >> I >> want to add the name in pom.xml's $DirectoryName >> property and run mvn. If there's a way to set name / >> value >> pairs during mvn invocation, that would be best. If not, what's the best >> way >> to do this? >> -- >> View this message in context: >> http://old.nabble.com/Setting-custom-varaibles-tp27881131p27881131.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 >> >> > > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > > -- View this message in context: http://old.nabble.com/Setting-custom-varaibles-tp27881131p27884743.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: Setting custom varaibles
Hi, First question: why do you need to do this? Maven defines strong conventions principles over config. So doing what you say seems quite uncommon. So you've got three solutions: * if the project can be cleanly refactored to be built, with clear deps and so on => the way to go * if those source directories comes from a special process (say generation), then maybe the way to go is more writing a maven plugin that will do what you need cleanly (writing a maven plugin is very simple). To help answer this question, I guess you'll have to explain your need a bit more. * combine ant-run plugin/buildhelper should help do the trick, but this would be like using ant to compile when developing under eclipse Cheers 2010/3/12 swaroopgr > > I'm need to use custom variables in maven. Here's what I do: > > Run the "ls" command in the current directory. For each directory listed, I > want to add the name in pom.xml's $DirectoryName > property and run mvn. If there's a way to set name / > value > pairs during mvn invocation, that would be best. If not, what's the best > way > to do this? > -- > View this message in context: > http://old.nabble.com/Setting-custom-varaibles-tp27881131p27881131.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 > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Setting custom varaibles
> Run the "ls" command in the current directory. For each directory listed, I > want to add the name in pom.xml's $DirectoryName > property and run mvn. If there's a way to set name / value > pairs during mvn invocation, that would be best. If not, what's the best way If your build requires this, you are better off sticking with Ant or whatever build tool you've been using until now. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Setting custom varaibles
I'm need to use custom variables in maven. Here's what I do: Run the "ls" command in the current directory. For each directory listed, I want to add the name in pom.xml's $DirectoryName property and run mvn. If there's a way to set name / value pairs during mvn invocation, that would be best. If not, what's the best way to do this? -- View this message in context: http://old.nabble.com/Setting-custom-varaibles-tp27881131p27881131.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: Test fail for release:perform only - no failure info
Hmm... just tried with Maven 2.2.1 and surefire plugin vesion 2.5. Still none of the tests are failing but the build fails because there are test errors. I thought it was one particular test, but I removed it from the project and same result. All tests pass on release:prepare but I get the "build failed due to test failures with no failing tests" when I do release:perform. Ideas? Thanks! Randall -Original Message- From: Randall Fidler [mailto:randall.fid...@testadvantage.com] Sent: Thursday, March 11, 2010 3:18 PM To: Maven Users List Subject: RE: Test fail for release:perform only - no failure info I'm downloading Maven 2.2.1 right now. I'm on a 'loaner' laptop as mine is in the shop so I think not having MAVEN_OPTS set for memory settings could be an option. Maybe it runs out of memory under the release:perform and not release:prepare? Anyhow, I'll give both a try. Thanks! Any other ideas are welcome. Regards, Randall -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Thursday, March 11, 2010 3:08 PM To: Maven Users List Subject: Re: Test fail for release:perform only - no failure info > I'm using Maven 2.0.9. > Any ideas? Where to start looking? Did you try Maven 2.0.10? Or 2.0.11 that was recently released? Or 2.2.1 for that matter if you don't need to use JDK 1.4? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Leakage from pluginManagement to plugins
Je pense que je ne mange pas des castor. On Fri, Mar 12, 2010 at 8:27 AM, Baptiste MATHUS wrote: > Yes, it's better. This way, it will take seconds for one to check if we're > having the same problem. > Just "design" your test project the best you can, like kind of a testcase. > So that the error just jumps out when maven is started. > > Describe the test project, what you wanted to do, what it does, and what > you > think it should have done. Add also which versions of maven you tested, and > so on. > If you're not sure it's a bug, send it here before. If this is a bug, > directly file a new bug. And btw, send the link to the bug anyway (and > attach the test project to the bug if you do so :)). > > Cheers > > 2010/3/12 Benson Margulies > > > So, does anyone need an test case of this on a JIRA? > > > > On Fri, Mar 12, 2010 at 7:53 AM, Brian Fox wrote: > > > > > If the plugin is mentioned _at all_ even just group/artifact, then the > > > pluginManagement will kick in. This is how it works now. It should be > > > that you have to mention the executionId you want to inherit instead > > > of just assuming all of them. > > > > > > On Thu, Mar 11, 2010 at 10:37 PM, Benson Margulies > > > wrote: > > > > Here, let me sketch this out... > > > > > > > > > > > > > > > > > > > > > > > > g > > > > a > > > > v > > > > > > > > > > > > ego > > > > g1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > g > > > > a > > > > v > > > > > > > > > > > > super > > > > g2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > If this is in the parent, and the child mentions g2 in it's > > > //build/plugins, > > > > the child runs BOTH, even if it never mentions g1 in its own > > > //build/plugins > > > > (xpath) section. > > > > > > > > > > > > On Thu, Mar 11, 2010 at 10:24 PM, Brian Fox > > wrote: > > > > > > > >> If the execution is mentioned in the parent plugin section, it's > > > >> inherited by the child, so yes it would run. If you don't want this, > > > >> then the parent should have the configuration in pluginManagement > > > >> (only) and then the child mentions the plugin in the plugins > section. > > > >> > > > >> On Thu, Mar 11, 2010 at 1:12 PM, Anders Hammar > > > wrote: > > > >> > I think I need to see a project to tell if I think it's wrong or > > not. > > > >> What I > > > >> > think you should start with is trying it with Maven 3.0-alpha-6 > and > > > see > > > >> if > > > >> > it the same behavior. Many incorrect things in Maven 2 has been > > fixed > > > in > > > >> 3. > > > >> > > > > >> > /Anders > > > >> > > > > >> > On Thu, Mar 11, 2010 at 17:05, Benson Margulies < > > > bimargul...@gmail.com > > > >> >wrote: > > > >> > > > > >> >> Anders, > > > >> >> > > > >> >> If this sounds wrong to you, I'll put the effort into a test > > project. > > > >> >> > > > >> >> --benson > > > >> >> > > > >> >> > > > >> >> On Thu, Mar 11, 2010 at 10:43 AM, Anders Hammar < > and...@hammar.net > > > > > > >> wrote: > > > >> >> > > > >> >> > Have you tested with Maven-3.0-alpha-6? > > > >> >> > In either case, a test project to reproduce this would help. If > > you > > > >> think > > > >> >> > it's wrong, submit a jira with that project attached. > > > >> >> > > > > >> >> > /Anderfs > > > >> >> > > > > >> >> > On Thu, Mar 11, 2010 at 16:36, Benson Margulies < > > > >> bimargul...@gmail.com > > > >> >> > >wrote: > > > >> >> > > > > >> >> > > As an additional hint, and possible explanation: > > > >> >> > > > > > >> >> > > I have a project with multiple mojos in it. In the area where > > I'm > > > >> >> having > > > >> >> > > the > > > >> >> > > problem, I've got one of them specified in build/plugins in > the > > > >> parent > > > >> >> > > project, and the other specified in > > > build/pluginManagement/plugins. > > > >> I > > > >> >> > can't > > > >> >> > > help wondering if there some sort of leakage here, or that > the > > > >> entire > > > >> >> > > plugin, not the goal, is what gets managed. > > > >> >> > > > > > >> >> > > On Thu, Mar 11, 2010 at 10:25 AM, Benson Margulies < > > > >> >> > bimargul...@gmail.com > > > >> >> > > >wrote: > > > >> >> > > > > > >> >> > > > In the parent project, I declare a plugin in > > pluginManagement. > > > >> >> > > > > > > >> >> > > > In one of the children, I do \not/ reference it at all. > Yet, > > > >> >> > > > help:effective-pom shows it in the build/plugins, and it's > > > trying > > > >> to > > > >> >> > run. > > > >> >> > > > > > > >> >> > > > Any suggestions? > > > >> >> > > > > > > >> >> > > > > > >> >> > > > > >> >> > > > >> > > > > >> > > > >> > - > > > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > >> For additional commands, e-mail: users-h...@maven.apache.org > > > >> > > > >> > > > > > > > > > > --
maven-deploy-plugin — inconsistent unique Version, upload and download issues
Hello,
I had an issue with Nexus not returning the right artifact, apparently
to be due to presence of both -SNAPSHOT and artifacts in its
repositories; this seems to be fixed by emptying the snapshot
repositories and re-deploy.
Before the deletion, Maven was always download -SNAPSHOT artifacts, even
if older than -${timestamp} ones.
But, even after I've set true, I still
have those two different behaviors:
http://maven.nuxeo.org/nexus/content/repositories/nuxeo-snapshot/org/nuxeo/ecm/distribution/nuxeo-distribution-dm/5.3.1-SNAPSHOT/
http://maven.in.nuxeo.com/nexus/content/repositories/snapshots/org/nuxeo/ecm/distribution/nuxeo-distribution-dm/5.3.1-SNAPSHOT/
It looks like
http://jira.codehaus.org/browse/MDEPLOY-75 and
http://jira.codehaus.org/browse/MDEPLOY-46
For http://maven.nuxeo.org/, deployment is done with "mvn clean deploy"
For http://maven.in.nuxeo.com/, deployment is done with either
(depending on the module POM):
- "mvn clean deploy -Pqa"
- "mvn clean deploy -Pqa
-DaltDeploymentRepository=snapshots::default::http://maven.in.nuxeo.com/snapshots";
with the following values for snapshot deployment:
qa
snapshots
http://maven.in.nuxeo.com/snapshots
true
nuxeo-snapshot
http://maven.nuxeo.org/nexus/content/repositories/nuxeo-snapshot
true
Is there something better I could do ?
Could you explain the difference between maven.nuxeo.org and
maven.in.nuxeo.com ?
Also, why are there ${timestamp} artifacts in local repositories ? Is
there any reason for not having -SNAPSHOT on client side ?
Is all this effectively due to MDEPLOY-46 and 75 ? Will this be fixed
(last update on August 2007 and March 2008 ?!) or will we have to wait
for Maven 3 being released and align our code on it ?
Best regards,
Julien
--
Julien Carsique, Nuxeo (Paris, France) — jcarsi...@nuxeo.com
www.nuxeo.com - The Open Source ECM Platform - www.nuxeo.org
Nuxeo ECM Stack - The Java EE, scalable, standard-based ECM Platform
Site not working properly
I have been using Maven and the Site plugin for over a year now and it has been working fine. Today I went to use it and my index.html file is displaying information that is in the tag of the pom and not the index.apt file I have been using. I am also getting the error DEPRECATED: Binding aggregator mojos to lifecycle phases in the POM is considered dangerous. This feature has been deprecated. Please adjust your POM files accordingly. for the org.apache.maven.plugins:maven-javadoc-plugin:2.6:aggregate, and org.apache.maven.plugins:maven-project-info-reports-plugin:2.1.2:dependency-convergence I am running this inside M2Eclipse. Tim McGinnis 717 720-1962 Web Development AES/PHEAA == This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. ==
Re: Maven 3.0 Artefact/Dependency version discussion request
2010/3/12 Trojan, Krzysztof
> Hi,
>
> > Well, if I read correctly what you said, you're putting the dependencies
> between project with external properties that defines versions. I guess you
> know one of the main objectives of maven is letting users be able to have an
> always reproducible build.
>
> While a desire to have the build reproducible is OK, I am just questioning
> if a tool should enforce it by removing flexibility. Going this way we will
> end up forbidding dependencies on snapshots (cause somebody could have
> uploaded a broken snapshot to the repo) ? Or force the snapshots to be
> uniquely identified ?
>
Well, what you say is one of the foundation of maven. SNAPSHOT is designed
to change any time. So it's totally OK to develop with such version, and
that was designed for it. SNAPSHOT (or anything moving) is just forbidden
when releasing, which is thoroughly acceptable to me. We release a 25+
modules multi-modules project about once a month using the release-plugin.
We're always using a SNAPSHOT version to define dependency versions between
each others. When we release, all those SNAPSHOT must simply be removed and
be fixed (either manually if this is an externally managed project, or
automatically if the snapshot from a dependency which is in included in the
multi-module project).
So, no. Your example is not the right one. Because when a project has been
tagged, only release versions can be present in the pom.
Though I agree that flexibility is great, you can't have flexibility
everywhere. It always highers software complexity since you're basically
adding *if*s.
Making the build depend on external factor like changing version is just
something too important for maven opiniated design to allow, I guess.
Note I'm no maven developer, but I totally agree this is a good idea to
enforce this. I'm not saying this MUST not be flexible, but I think this is
not a use case where it should be.
> I am not externalizing dependencies to 3rd party stuff - only to siblings
> projects. And this is my responsibility to keep versions of sibling projects
> consistent. In the end, it is my CI process responsibility to check if the
> project can be built, and the changes introduced in such "mixed" branches
> can be built.
>
> Actually, at the moment the only place such "dynamic deferred dependency
> binding" is used, is in snapshot dependencies on sibling projects in
> development branches (and trunk). So the build is unstable by definition
> (depending on snapshot). When tagging I will anyway use a script to replace
> ${some.version} with RELEASE-X.Y.Z in
> all the pom.xml's.
>
Not sure to understand precisely what you do. But it seems like what you do
is the kind of this handled gracefully by the maven-release-plugin. Did you
have a look at it? If yes, what doesn't correspond to your needs?
> > I suppose you version the properties used to tag along the project
> itself? If not, then you're out of luck IMO.
>
> Yes, the version related properties (and SCM paths inferred from them) are
> kept in SCM. Actually, in profiles.xml next to the aggregator project
> pom.xml.
>
> The properties in profiles.xml are used also in CI to checkout sources to
> workspace from SCM (I have a Hudson SCM plugin that uses an (Ant) script to
> implement checkout operation, and I think I will make it public soon).
>
Well. I'm using hudson too to build our 25+ multimodules project, and also
build something like 15 multimodules projects (each containing between 5 and
15 modules I'd say). We never needed ant to checkout.
We also use hudson to trigger our release
>
> When tagging there is no danger anyway - the sources are moved to /tags, so
> whatever branch they were originally does not matter. The SCM path will be
> changed to /tags/some_tag anyway, and the version properties will be set
> to the release version ID the tag is connected to. This is why we are
> tagging, don't you think? We do not rely on some file to keep information
> that we released code based on revision @7890 - we just do svn copy
> http://xx/svn/tr...@7890 http://xx/svn/tags/RELEASE-X.Y.Z
>
>
Well, your release process seems very complicated. I suppose there are
reasons behind this complexity...
I'm also tagging quite often. But only use the release-plugin to do that.
And before using it, I released a lot of times without it. I always had
forgotten something (snapshot version left, scm tag not updated correctly,
sibling project version not-up-to-date, forgotten to go back to snapshot
version...).
> In the long term I ask for introducing a notion of some kind of global
> profiles, with a semantics that such global profile can define properties
> that are used in every aspect of the process. I think it could be something
> as simple as true in a profile definition, that would
> trigger special behaviour (that the profile is injected to every pom.xml,
> say a dependency pom read from repository). From my perspective the profile
> is OK to
RE: Maven 3.0 Artefact/Dependency version discussion request
Hi,
> Well, if I read correctly what you said, you're putting the dependencies
> between project with external properties that defines versions. I guess you
> know one of the main objectives of maven is letting users be able to have an
> always reproducible build.
While a desire to have the build reproducible is OK, I am just questioning if a
tool should enforce it by removing flexibility. Going this way we will end up
forbidding dependencies on snapshots (cause somebody could have uploaded a
broken snapshot to the repo) ? Or force the snapshots to be uniquely identified
?
I am not externalizing dependencies to 3rd party stuff - only to siblings
projects. And this is my responsibility to keep versions of sibling projects
consistent. In the end, it is my CI process responsibility to check if the
project can be built, and the changes introduced in such "mixed" branches can
be built.
Actually, at the moment the only place such "dynamic deferred dependency
binding" is used, is in snapshot dependencies on sibling projects in
development branches (and trunk). So the build is unstable by definition
(depending on snapshot). When tagging I will anyway use a script to replace
${some.version} with RELEASE-X.Y.Z in all
the pom.xml's.
> I suppose you version the properties used to tag along the project itself? If
> not, then you're out of luck IMO.
Yes, the version related properties (and SCM paths inferred from them) are kept
in SCM. Actually, in profiles.xml next to the aggregator project pom.xml.
The properties in profiles.xml are used also in CI to checkout sources to
workspace from SCM (I have a Hudson SCM plugin that uses an (Ant) script to
implement checkout operation, and I think I will make it public soon).
When tagging there is no danger anyway - the sources are moved to /tags, so
whatever branch they were originally does not matter. The SCM path will be
changed to /tags/some_tag anyway, and the version properties will be set to
the release version ID the tag is connected to. This is why we are tagging,
don't you think? We do not rely on some file to keep information that we
released code based on revision @7890 - we just do svn copy
http://xx/svn/tr...@7890 http://xx/svn/tags/RELEASE-X.Y.Z
The problem is more generic anyway, cause for now I had problems to inject
version properties - the unchanged maven is not propagating properties set in
local profile when reading dependencies pom's from repository - so the
properties are not substituted anyway in transitive dependency designators. I
could pass them with -Dxxx=yyy but it is not the most convenient way (well,
there is nothing to prevent me to change the mvn.sh to read some pom.properties
and inject them to Maven, but then there is a question how to handle this in
embedded environments - like m2eclipse, without patching them all ).
In the long term I ask for introducing a notion of some kind of global
profiles, with a semantics that such global profile can define properties that
are used in every aspect of the process. I think it could be something as
simple as true in a profile definition, that would trigger
special behaviour (that the profile is injected to every pom.xml, say a
dependency pom read from repository). From my perspective the profile is OK to
hold only properties, not plugin config or dependencyManagement or anything
else, but it is an open question what should be allowed in such special
profile. We could also use a separate file for that (global_profile.xml ;), but
it is not necessarily best.
Such behaviour is not available anyway for now - so I have patched Maven to
treat profiles with some ID specially (inject them globally) (something like if
(profile.getId().contains("my_magic_string")) injectProfile(profile) - this is
oversimplification, of course, cause I need a way of propagating the "global"
profiles to other pom's, and current 2.2.x API actually do not pass
ProfileManager instance to every place I would like to use it in).
This would not break any existing build (cause no existing build would contain
set to true ;). And will allow special cases (like mine). The
responsibility for the build belongs to build manager in the end, so I don't
think Maven team should go too far in restricting people from doing those
"evil" things. Forbidding an expression in version, or actually any other part
of the pom, is that one step too far.
Regards,
Krzysztof Trojan
From: bmat...@gmail.com [mailto:bmat...@gmail.com] On Behalf Of Baptiste MATHUS
Sent: 12 March 2010 14:22
To: Maven Users List
Cc: Trojan, Krzysztof
Subject: Re: Maven 3.0 Artefact/Dependency version discussion request
Answering putting Krzysztof in copy. But please, subscribe to the users maven
list, because not sure everybody will think about clicking on "reply all".
Well, if I read correctly what you said, you're putting the dependencies
between project with external properties that def
Re: New to maven and loving it :) Need a little help please...
Try the cargo plugin or the jboss specific one: http://cargo.codehaus.org/Maven2+plugin http://mojo.codehaus.org/jboss-maven-plugin/ /Anders On Fri, Mar 12, 2010 at 14:06, Yucca Nel wrote: > Hello, google has helped me fantastically up to now and I am in a little > need of further info. > > I am in the process of changing my development environment (JEE5 + JEE6) > and have started to utilise Maven. I am looking for a xml pom snippet that > can help me deploy directly to Jboss6 or glassfish v3 when building my pom. > If no solution exists, I am open to trying geronimo in the hope of better > integration with maven.
New to maven and loving it :) Need a little help please...
Hello, google has helped me fantastically up to now and I am in a little need of further info. I am in the process of changing my development environment (JEE5 + JEE6) and have started to utilise Maven. I am looking for a xml pom snippet that can help me deploy directly to Jboss6 or glassfish v3 when building my pom. If no solution exists, I am open to trying geronimo in the hope of better integration with maven.
Re: Leakage from pluginManagement to plugins
Yes, it's better. This way, it will take seconds for one to check if we're having the same problem. Just "design" your test project the best you can, like kind of a testcase. So that the error just jumps out when maven is started. Describe the test project, what you wanted to do, what it does, and what you think it should have done. Add also which versions of maven you tested, and so on. If you're not sure it's a bug, send it here before. If this is a bug, directly file a new bug. And btw, send the link to the bug anyway (and attach the test project to the bug if you do so :)). Cheers 2010/3/12 Benson Margulies > So, does anyone need an test case of this on a JIRA? > > On Fri, Mar 12, 2010 at 7:53 AM, Brian Fox wrote: > > > If the plugin is mentioned _at all_ even just group/artifact, then the > > pluginManagement will kick in. This is how it works now. It should be > > that you have to mention the executionId you want to inherit instead > > of just assuming all of them. > > > > On Thu, Mar 11, 2010 at 10:37 PM, Benson Margulies > > wrote: > > > Here, let me sketch this out... > > > > > > > > > > > > > > > > > > g > > > a > > > v > > > > > > > > > ego > > > g1 > > > > > > > > > > > > > > > > > > > > > > > > g > > > a > > > v > > > > > > > > > super > > > g2 > > > > > > > > > > > > > > > > > > > > > If this is in the parent, and the child mentions g2 in it's > > //build/plugins, > > > the child runs BOTH, even if it never mentions g1 in its own > > //build/plugins > > > (xpath) section. > > > > > > > > > On Thu, Mar 11, 2010 at 10:24 PM, Brian Fox > wrote: > > > > > >> If the execution is mentioned in the parent plugin section, it's > > >> inherited by the child, so yes it would run. If you don't want this, > > >> then the parent should have the configuration in pluginManagement > > >> (only) and then the child mentions the plugin in the plugins section. > > >> > > >> On Thu, Mar 11, 2010 at 1:12 PM, Anders Hammar > > wrote: > > >> > I think I need to see a project to tell if I think it's wrong or > not. > > >> What I > > >> > think you should start with is trying it with Maven 3.0-alpha-6 and > > see > > >> if > > >> > it the same behavior. Many incorrect things in Maven 2 has been > fixed > > in > > >> 3. > > >> > > > >> > /Anders > > >> > > > >> > On Thu, Mar 11, 2010 at 17:05, Benson Margulies < > > bimargul...@gmail.com > > >> >wrote: > > >> > > > >> >> Anders, > > >> >> > > >> >> If this sounds wrong to you, I'll put the effort into a test > project. > > >> >> > > >> >> --benson > > >> >> > > >> >> > > >> >> On Thu, Mar 11, 2010 at 10:43 AM, Anders Hammar > > > >> wrote: > > >> >> > > >> >> > Have you tested with Maven-3.0-alpha-6? > > >> >> > In either case, a test project to reproduce this would help. If > you > > >> think > > >> >> > it's wrong, submit a jira with that project attached. > > >> >> > > > >> >> > /Anderfs > > >> >> > > > >> >> > On Thu, Mar 11, 2010 at 16:36, Benson Margulies < > > >> bimargul...@gmail.com > > >> >> > >wrote: > > >> >> > > > >> >> > > As an additional hint, and possible explanation: > > >> >> > > > > >> >> > > I have a project with multiple mojos in it. In the area where > I'm > > >> >> having > > >> >> > > the > > >> >> > > problem, I've got one of them specified in build/plugins in the > > >> parent > > >> >> > > project, and the other specified in > > build/pluginManagement/plugins. > > >> I > > >> >> > can't > > >> >> > > help wondering if there some sort of leakage here, or that the > > >> entire > > >> >> > > plugin, not the goal, is what gets managed. > > >> >> > > > > >> >> > > On Thu, Mar 11, 2010 at 10:25 AM, Benson Margulies < > > >> >> > bimargul...@gmail.com > > >> >> > > >wrote: > > >> >> > > > > >> >> > > > In the parent project, I declare a plugin in > pluginManagement. > > >> >> > > > > > >> >> > > > In one of the children, I do \not/ reference it at all. Yet, > > >> >> > > > help:effective-pom shows it in the build/plugins, and it's > > trying > > >> to > > >> >> > run. > > >> >> > > > > > >> >> > > > Any suggestions? > > >> >> > > > > > >> >> > > > > >> >> > > > >> >> > > >> > > > >> > > >> - > > >> 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 > > > > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Maven 3.0 Artefact/Dependency version discussion request
Answering putting Krzysztof in copy. But please, subscribe to the users
maven list, because not sure everybody will think about clicking on "reply
all".
Well, if I read correctly what you said, you're putting the dependencies
between project with external properties that defines versions. I guess you
know one of the main objectives of maven is letting users be able to have an
always reproducible build.
When externalizing versions between dependencies, how can guaranty that if
you extract a version two years after an scm tag, you'll be able to build
it?
I suppose you version the properties used to tag along the project itself?
If not, then you're out of luck IMO.
Can you explain a bit more what is your use case for proceeding this way?
Cheers
2010/3/10 Jason van Zyl
> The user list is here users@maven.apache.org and you can subscribe to
> discuss your issues using users-subscr...@maven.apache.org.
>
> On Mar 10, 2010, at 5:45 AM, Trojan, Krzysztof wrote:
>
> > Dear Sir,
> >
> > First of all I would like to apologize for writing to you directly. I
> have inadequate information about roles and responsibilities in the Maven
> project, so I write to You, as Maven PMC member and project founder, hoping
> you can distribute my email to the right people.
> >
> > I have been among Maven users for some time now. I am responsible for
> moving a really big banking solution build to Maven, that we hoped to solve
> a number of manageability problems we have had in the past. We have found
> Maven to suit our needs very well, but we are sometimes struggling with
> Maven ever changing behaviour and APIs. Having said that, Maven still is our
> tool of choice.
> >
> > However, we have found that Maven 3.0 is moving in a direction that we
> find a little bit dangerous for us. We have some arguments against proposed
> changes, and we kindly ask to open a discussion. In very short words, Maven
> 3.0 tries to restrict usage of expressions evaluated during build in some
> parts of the pom.xml (or a project descriptor, more generically speaking).
> We can see the warning saying something like “using an expression here is a
> BAD BAD thing, it will threaten stability of your build. We may stop
> supporting this one day”. While we can agree that build stability may be
> impacted, in the end it is MY (the developer) responsibility to avoid it.
> Build stability may be impacted by 10 other things you have no control over.
> >
> > Here is an extract:
> > [WARNING] Some problems were encountered while building the effective
> model for
> com.fnis.crb:BigBankingProject:jar:${BigBankingProject.module.version}
> > [WARNING] 'version' contains an expression but should be a constant. @
> com.fnis.crb:BigBankingProject:${BigBankingProject.module.version},
> C:\Workspaces\Corebank_Maven\BigBankingProject\pom.xml
> >
> > A little bit further down in the log there is
> > [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> > [WARNING]
> > [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> > [WARNING]
> >
> > If you want to warn me – fine, thank you, I have been warned. If you have
> the behaviour configurable (like being able to switch on some “relaxed”
> mode) – fine. But if the tool says: “you are stupid, but we have a cure, we
> will prevent you from doing those dangerous things …” it is a complete
> misunderstanding. The flexibility is ALWAYS a good thing, and the fact that
> there will be people who can screw things up badly just because they can,
> cannot be the justification to remove flexibility in favour of some “ONLY
> GOOD WAY”. And expressions are one of the ways of providing flexibility.
> >
> > I am unsure if the restriction the warning mention ('version' contains an
> expression but should be a constant) is only for the main artefact defined
> in pom.xml, or also applies to dependencies (can I have an expression in
> dependency version ? I know from the discussions documented in the Internet
> you were concerned with having a version not resolved to a concrete value –
> you also mentioned version ranges as potential threat).
> >
> > If you want to hear the exact use case, I can elaborate it, but it is way
> too complicated for an initial email.
> >
> > The main idea behind our solution is that we inject properties into the
> build specifying the versions of dependencies we want to use. Imagine
> modules A, B and C; A depends on B, and B depends on C. Now we have a
> feature branch that changes A and C … my way is to use A and C from branch,
> but B from trunk. I want to build A, it references B from trunk … but as B
> references C, I need a way to tell B to use C built from branch – here is
> where expression in the is used, B knows to depend on C in “some
> version” (${C.module.version}), the actual value of ${C.module.version} is
> injected, so it gets resolved to correct version in the repository. I ho
Re: Leakage from pluginManagement to plugins
So, does anyone need an test case of this on a JIRA? On Fri, Mar 12, 2010 at 7:53 AM, Brian Fox wrote: > If the plugin is mentioned _at all_ even just group/artifact, then the > pluginManagement will kick in. This is how it works now. It should be > that you have to mention the executionId you want to inherit instead > of just assuming all of them. > > On Thu, Mar 11, 2010 at 10:37 PM, Benson Margulies > wrote: > > Here, let me sketch this out... > > > > > > > > > > > > g > > a > > v > > > > > > ego > > g1 > > > > > > > > > > > > > > > > g > > a > > v > > > > > > super > > g2 > > > > > > > > > > > > > > If this is in the parent, and the child mentions g2 in it's > //build/plugins, > > the child runs BOTH, even if it never mentions g1 in its own > //build/plugins > > (xpath) section. > > > > > > On Thu, Mar 11, 2010 at 10:24 PM, Brian Fox wrote: > > > >> If the execution is mentioned in the parent plugin section, it's > >> inherited by the child, so yes it would run. If you don't want this, > >> then the parent should have the configuration in pluginManagement > >> (only) and then the child mentions the plugin in the plugins section. > >> > >> On Thu, Mar 11, 2010 at 1:12 PM, Anders Hammar > wrote: > >> > I think I need to see a project to tell if I think it's wrong or not. > >> What I > >> > think you should start with is trying it with Maven 3.0-alpha-6 and > see > >> if > >> > it the same behavior. Many incorrect things in Maven 2 has been fixed > in > >> 3. > >> > > >> > /Anders > >> > > >> > On Thu, Mar 11, 2010 at 17:05, Benson Margulies < > bimargul...@gmail.com > >> >wrote: > >> > > >> >> Anders, > >> >> > >> >> If this sounds wrong to you, I'll put the effort into a test project. > >> >> > >> >> --benson > >> >> > >> >> > >> >> On Thu, Mar 11, 2010 at 10:43 AM, Anders Hammar > >> wrote: > >> >> > >> >> > Have you tested with Maven-3.0-alpha-6? > >> >> > In either case, a test project to reproduce this would help. If you > >> think > >> >> > it's wrong, submit a jira with that project attached. > >> >> > > >> >> > /Anderfs > >> >> > > >> >> > On Thu, Mar 11, 2010 at 16:36, Benson Margulies < > >> bimargul...@gmail.com > >> >> > >wrote: > >> >> > > >> >> > > As an additional hint, and possible explanation: > >> >> > > > >> >> > > I have a project with multiple mojos in it. In the area where I'm > >> >> having > >> >> > > the > >> >> > > problem, I've got one of them specified in build/plugins in the > >> parent > >> >> > > project, and the other specified in > build/pluginManagement/plugins. > >> I > >> >> > can't > >> >> > > help wondering if there some sort of leakage here, or that the > >> entire > >> >> > > plugin, not the goal, is what gets managed. > >> >> > > > >> >> > > On Thu, Mar 11, 2010 at 10:25 AM, Benson Margulies < > >> >> > bimargul...@gmail.com > >> >> > > >wrote: > >> >> > > > >> >> > > > In the parent project, I declare a plugin in pluginManagement. > >> >> > > > > >> >> > > > In one of the children, I do \not/ reference it at all. Yet, > >> >> > > > help:effective-pom shows it in the build/plugins, and it's > trying > >> to > >> >> > run. > >> >> > > > > >> >> > > > Any suggestions? > >> >> > > > > >> >> > > > >> >> > > >> >> > >> > > >> > >> - > >> 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: Leakage from pluginManagement to plugins
If the plugin is mentioned _at all_ even just group/artifact, then the pluginManagement will kick in. This is how it works now. It should be that you have to mention the executionId you want to inherit instead of just assuming all of them. On Thu, Mar 11, 2010 at 10:37 PM, Benson Margulies wrote: > Here, let me sketch this out... > > > > > > g > a > v > > > ego > g1 > > > > > > > > g > a > v > > > super > g2 > > > > > > > If this is in the parent, and the child mentions g2 in it's //build/plugins, > the child runs BOTH, even if it never mentions g1 in its own //build/plugins > (xpath) section. > > > On Thu, Mar 11, 2010 at 10:24 PM, Brian Fox wrote: > >> If the execution is mentioned in the parent plugin section, it's >> inherited by the child, so yes it would run. If you don't want this, >> then the parent should have the configuration in pluginManagement >> (only) and then the child mentions the plugin in the plugins section. >> >> On Thu, Mar 11, 2010 at 1:12 PM, Anders Hammar wrote: >> > I think I need to see a project to tell if I think it's wrong or not. >> What I >> > think you should start with is trying it with Maven 3.0-alpha-6 and see >> if >> > it the same behavior. Many incorrect things in Maven 2 has been fixed in >> 3. >> > >> > /Anders >> > >> > On Thu, Mar 11, 2010 at 17:05, Benson Margulies > >wrote: >> > >> >> Anders, >> >> >> >> If this sounds wrong to you, I'll put the effort into a test project. >> >> >> >> --benson >> >> >> >> >> >> On Thu, Mar 11, 2010 at 10:43 AM, Anders Hammar >> wrote: >> >> >> >> > Have you tested with Maven-3.0-alpha-6? >> >> > In either case, a test project to reproduce this would help. If you >> think >> >> > it's wrong, submit a jira with that project attached. >> >> > >> >> > /Anderfs >> >> > >> >> > On Thu, Mar 11, 2010 at 16:36, Benson Margulies < >> bimargul...@gmail.com >> >> > >wrote: >> >> > >> >> > > As an additional hint, and possible explanation: >> >> > > >> >> > > I have a project with multiple mojos in it. In the area where I'm >> >> having >> >> > > the >> >> > > problem, I've got one of them specified in build/plugins in the >> parent >> >> > > project, and the other specified in build/pluginManagement/plugins. >> I >> >> > can't >> >> > > help wondering if there some sort of leakage here, or that the >> entire >> >> > > plugin, not the goal, is what gets managed. >> >> > > >> >> > > On Thu, Mar 11, 2010 at 10:25 AM, Benson Margulies < >> >> > bimargul...@gmail.com >> >> > > >wrote: >> >> > > >> >> > > > In the parent project, I declare a plugin in pluginManagement. >> >> > > > >> >> > > > In one of the children, I do \not/ reference it at all. Yet, >> >> > > > help:effective-pom shows it in the build/plugins, and it's trying >> to >> >> > run. >> >> > > > >> >> > > > Any suggestions? >> >> > > > >> >> > > >> >> > >> >> >> > >> >> - >> 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
usage of preserveCData with archetypes
Hi all, I would like the archetype goal create-from-project to replace ALL occurences of my artifactId in my multi-module project. Without -DpreserveCData=true, some occurences are not replaced (in pom comments or in cxf-codegen-plugin configuration). With -DpreserveCData=true, these occurences are successfully replaced, but others are not, especially those in my own dependencies. The symptom is very similar to what is described in http://jira.codehaus.org/browse/ARCHETYPE-87 by Brian Fox. I'm using maven 2.2.1 and archetype plugin 2.0-alpha-4. How could I solve this problem ? Regards, Bernard -- View this message in context: http://old.nabble.com/usage-of-preserveCData-with-archetypes-tp27874536p27874536.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 spitting out "crap" when it can't find locally added dependancies. How to stop it from checking?
On 10 March 2010 21:48, Ron Wheeler wrote: > Post things to JIRA (especially with patches) to get things changed. I > >> assure you, patches with good/useful changes in content will be >> well-received and the site/documentation will be updated in due >> course. >> >> >> > I am not going to get into "patching". I leave that to the author. I will > suggest rewording or request that clarifying text be added but I will not > create patches. > > Then I think you are misunderstanding what we mean by "patches"... If it is documentation, * obviously a .patch file for the .apt file would be great (it'll get reviewed and applied very fast) * failing that something like: --- On this page: http://maven.apache.org/../blah.html current content is --- Blah blah blah blah --- Suggested replacement content is --- Waffle Waffle Blah Blah --- On this paget: etc would be IMHO perfectly fine as a "patch" and it would be reviewed and applied quite fast -Stephen
Re: release:perform from a branch?
the only other gotcha (and it is occasional) is if your branch structure is "non-standard" in which case you'd need to configure the tagBase option inthe maven-release-plugin However that is rather rare -Stephen On 10 March 2010 17:48, Kalle Korhonen wrote: > You don't need any command line options to release from a branch (I'd > even go so far as to say that if you need to specify command line > options with mvn release, you haven't configured the plugin correctly) > but you *have to* have scm urls pointing to the right location (i.e. > not the trunk for the branched versioned). If you created the branch > using mvn release:branch, it would manage the scm element for you > (again, assuming you've configured the plugin properly in the first > place). We do all of our point/bug fix releases from branches. > > Kalle > > > On Wed, Mar 10, 2010 at 8:51 AM, Steven Hilton > wrote: > > Greetings, > > > > Can the maven release plugin build a tag from a branch during a > > release:prepare? Ultimately, I want to do a release:peform from a tag > > based off a branch where maven never looks at or touches trunk. > > > > I've tried a number of different command line options, read some docs > > at http://maven.apache.org/guides/mini/guide-releasing.html and other > > places and am not seeing how to do this. > > > > Before: > > * I create a branch > > * Do development work on the branch, fixing bugs, etc. > > * Now it's time to release the bug fixes, but we can't merge the > > changes to trunk. > > > > Now: > > * I check out the branch to a new working location > > * cd to that working location > > * mvn -Dtag=myTagName release:prepare > > > > When it manipulates the poms, it sets them correctly and commits them > > to the branch. > > > > But then I can't get it to do the svn copy from any place other than > > trunk, even though I'm operating on branch. I've tried -DconnectionUrl > > but that seems to be ignored in this context. > > > > Afterward, when I do a release:perform, the poms are out of sync, so > > it fails since the tag it checks out was tagged from trunk. Also, it's > > using code that doesn't have the bug fixes that are in the branch, > > which is bad. > > > > Is there a configuration option I'm missing? I can't find it anywhere. > > > > Thanks for any help. > > > > - Steven > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Maven Eclipse
On the contrary I don't see any issues. As long as you have good naming of your projects (possibly also in separate working sets), this should be ok. It also requires that you have correct versioning av your Maven projects (i.e. the two branches have different versions). I don't see how two eclipse instances would make this easier. I think it would rather make it more confusing. My 2 cents, /Anders On Fri, Mar 12, 2010 at 09:01, Arand, Thomas (NSN - DE/Munich) < thomas.ar...@nsn.com> wrote: > Hi all, > > I would not recommend to open those two projects in the same eclipse > workspace. As both projects mainly have the same elements, you will be > very confused when editing those elements. > > Additionally, it might be necessary to specify different (local) maven > reposistories for both projects. This is not possible (at least not > easily) in one eclipse instance. > > So my suggestion: Start two instances of eclipse with two different > workspaces! > > Thomas > > > > -Original Message- > From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On > Behalf Of ext Anders Hammar > Sent: Friday, March 12, 2010 8:56 AM > To: Maven Users List > Subject: Re: Maven Eclipse > > I assume you're using m2e? > I think the problem is that the eclipse project is named by artifactId > by > default. As there is already such a project (the main branch one), you > need > to change the project name. You so by using a name template. > > /Anders > > PS. Questions regarding m2eclipse is better to post one the m2e mailing > list. > > On Fri, Mar 12, 2010 at 01:21, Jitesh Shetty wrote: > > > Folks, > > > > I have a very basic question, I am using maven with eclipse and have a > case > > where I want to have two different projects which are actually built > from > > two different branches of the same product, so I am working on two > different > > branches and so I wanted to create two different maven projects in > eclipse. > > I have the project built from trunk running fine, but when I try to > create a > > project from one of the branches, I give the SVN location and then it > tries > > to check out the code but then throws a window which says "Select > Maven > > projects", it shows one pom.xml there but its frozen and cannot be > selected > > and then in the advanced section there is "Profiles" and "Name > template". > > Please let me know if I am doing something wrong here. > > > > Thanks > > > > -Jitesh > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
RE: Maven Eclipse
Hi all, I would not recommend to open those two projects in the same eclipse workspace. As both projects mainly have the same elements, you will be very confused when editing those elements. Additionally, it might be necessary to specify different (local) maven reposistories for both projects. This is not possible (at least not easily) in one eclipse instance. So my suggestion: Start two instances of eclipse with two different workspaces! Thomas -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of ext Anders Hammar Sent: Friday, March 12, 2010 8:56 AM To: Maven Users List Subject: Re: Maven Eclipse I assume you're using m2e? I think the problem is that the eclipse project is named by artifactId by default. As there is already such a project (the main branch one), you need to change the project name. You so by using a name template. /Anders PS. Questions regarding m2eclipse is better to post one the m2e mailing list. On Fri, Mar 12, 2010 at 01:21, Jitesh Shetty wrote: > Folks, > > I have a very basic question, I am using maven with eclipse and have a case > where I want to have two different projects which are actually built from > two different branches of the same product, so I am working on two different > branches and so I wanted to create two different maven projects in eclipse. > I have the project built from trunk running fine, but when I try to create a > project from one of the branches, I give the SVN location and then it tries > to check out the code but then throws a window which says "Select Maven > projects", it shows one pom.xml there but its frozen and cannot be selected > and then in the advanced section there is "Profiles" and "Name template". > Please let me know if I am doing something wrong here. > > Thanks > > -Jitesh > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
