mvn eclipse:m2eclipse
Hi, I thought that I would ask here whether anyone knows why the goal mvn eclipse:m2eclipse has been removed from org.apache.maven.plugins:maven-eclipse-plugin:2.8 It was available in org.apache.maven.plugins:maven-eclipse-plugin:2.7 I found the following references to this goal: http://maven.apache.org/plugins/maven-eclipse-plugin/m2eclipse-mojo.ht ml http://www.oreillynet.com/onjava/blog/2007/07/wicket_source_to_eclipse _using.html http://blog.redstream.nl/2008/05/17/setting-up-maven2-projects-in-ecpl ise/ I didn't want to raise an issue at http://jira.codehaus.org/browse/MECLIPSE due to the warning: Note: This project is not the right place to fill issues about the Maven Integration for Eclipse (M2Eclipse) https://issues.sonatype.org/browse/MNGECLIPSE . Regards, Neil Crow Standard Bank email disclaimer and confidentiality note Please go to http://www.standardbank.co.za/site/homepage/emaildisclaimer.html to read our email disclaimer and confidentiality note. Kindly email disclai...@standardbank.co.za (no content or subject line necessary) if you cannot view that page and we will email our email disclaimer and confidentiality note to you.
Re: mvn eclipse:m2eclipse
Hi! see http://maven-users.828.n2.nabble.com/searching-for-eclipse-m2eclipse-td4743556.html hth, - martin On Monday 03 May 2010 Crow, Neil NW wrote: Hi, I thought that I would ask here whether anyone knows why the goal mvn eclipse:m2eclipse has been removed from org.apache.maven.plugins:maven-eclipse-plugin:2.8 It was available in org.apache.maven.plugins:maven-eclipse-plugin:2.7 I found the following references to this goal: http://maven.apache.org/plugins/maven-eclipse-plugin/m2eclipse-mojo.ht ml http://www.oreillynet.com/onjava/blog/2007/07/wicket_source_to_eclipse _using.html http://blog.redstream.nl/2008/05/17/setting-up-maven2-projects-in-ecpl ise/ I didn't want to raise an issue at http://jira.codehaus.org/browse/MECLIPSE due to the warning: Note: This project is not the right place to fill issues about the Maven Integration for Eclipse (M2Eclipse) https://issues.sonatype.org/browse/MNGECLIPSE . Regards, Neil Crow Standard Bank email disclaimer and confidentiality note Please go to http://www.standardbank.co.za/site/homepage/emaildisclaimer.html to read our email disclaimer and confidentiality note. Kindly email disclai...@standardbank.co.za (no content or subject line necessary) if you cannot view that page and we will email our email disclaimer and confidentiality note to you. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: mvn eclipse:m2eclipse
Thanks Martin, I guess that the m2eclipse-mojo page would have to be removed manually. http://maven.apache.org/plugins/maven-eclipse-plugin/m2eclipse-mojo Cheers, Neil Crow -Original Message- From: Martin Höller [mailto:mar...@xss.co.at] Sent: 03 May 2010 13:57 PM To: Maven Users List Subject: Re: mvn eclipse:m2eclipse Hi! see http://maven-users.828.n2.nabble.com/searching-for-eclipse-m2eclipse-td4743556.html hth, - martin On Monday 03 May 2010 Crow, Neil NW wrote: Hi, I thought that I would ask here whether anyone knows why the goal mvn eclipse:m2eclipse has been removed from org.apache.maven.plugins:maven-eclipse-plugin:2.8 It was available in org.apache.maven.plugins:maven-eclipse-plugin:2.7 I found the following references to this goal: http://maven.apache.org/plugins/maven-eclipse-plugin/m2eclipse-mojo. ht ml http://www.oreillynet.com/onjava/blog/2007/07/wicket_source_to_eclip se _using.html http://blog.redstream.nl/2008/05/17/setting-up-maven2-projects-in-ec pl ise/ I didn't want to raise an issue at http://jira.codehaus.org/browse/MECLIPSE due to the warning: Note: This project is not the right place to fill issues about the Maven Integration for Eclipse (M2Eclipse) https://issues.sonatype.org/browse/MNGECLIPSE . Regards, Neil Crow Standard Bank email disclaimer and confidentiality note Please go to http://www.standardbank.co.za/site/homepage/emaildisclaimer.html to read our email disclaimer and confidentiality note. Kindly email disclai...@standardbank.co.za (no content or subject line necessary) if you cannot view that page and we will email our email disclaimer and confidentiality note to you. - 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 unit testing (sub)module that uses DI?
Hi all, I have a webapp (sub)module that uses Spring's dependency injection; how can/should I load the application context so I may run the unit tests for this module? Once all the modules are complete, I will add them to the webapp as dependencies and load the application context via the web container and Spring's ContextLoaderListener. -Dan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to unit testing (sub)module that uses DI?
Hi, that sound not like a Unit Test more like an integration test...which can be done by using cargo plugin...there you can startup e.g. Tomcat and run Integration test on the deployed system... On the other hand if you have only DI's than you only need an applicationContext.xml setup for the Unit Tests to do the unit tests if this would fit your needs...But i'm not sure about that... Kind regards Karl Heinz Marbaise -- View this message in context: http://old.nabble.com/How-to-unit-testing-%28sub%29module-that-uses-DI--tp28435068p28435262.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
renaming files in assembly
Hi everyone
For internationalized logging I have parallel to my *.java files in each
package a message.properties file. Using
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-5/version
configuration
descriptors
descriptorsrc/main/assembly/msg.xml/descriptor
/descriptors
/configuration
executions
execution
idmake-assembly/id
phasepackage/phase
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
/build
in my pom.xml and the msg.xml assembly file:
assembly
idmsg/id
formats
formatzip/format
/formats
includeBaseDirectorytrue/includeBaseDirectory
fileSets
fileSet
useDefaultExcludestrue/useDefaultExcludes
directory${basedir}/src/main/java/directory
includes
include**//messages.properties/include
/includes
filteredfalse/filtered
outputDirectory /
/fileSet
/fileSets
/assembly
I like to create a maven assembly that holds only these message.properties.
These files should be renamed to messages_en.properties. With file I can
rename a file before adding it to the assembly, but not with fileSet,
although in my case all files of the fileSet have the same name. Is there a
way to do the renaming directly using Maven without using maven-antrun-plugin?
Thanks for any help!
Martin
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to unit testing (sub)module that uses DI?
There are two ways I usually solve this problem. The choice between
the two (for me) is usually a matter of how deep I want the testing to
go.
In many cases, I use spring injection from my unit tests by combining
JUnit's @RunWith annotation and some Spring Annotations. Here is an
example -
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations =
{classpath*:applicationContext-test.xml})
public class StockInfoManagerTest {
@Autowired
@Qualifier(stockInfoDao)
private GenericDaoCDOV_StockInfo,String stockInfoDao;
This is mostly self-explanatory... However, I will mention that I
usually don't point to the same applicationContext.xml file that I
would use for production. In this case, I configure spring to
instantiate and talk to an hsqldb database. Then I can push stuff in
and then pull it back out to ensure that database operations complete
successfully.
In many other cases, I prefer a mocking approach. Here is an example -
�...@test
public void executeTest() throws Exception {
// setup the mock object
final StockInfoManager stockInfoManager =
context.mock(StockInfoManager.class);
// create expectations for mock object's execution
context.checking(new Expectations() {{
oneOf(stockInfoManager).getAll(); will(returnValue(new
ArrayListCDOV_StockInfo()));
}});
What mocking does is create a proxy that records requested operations
and behaves the way you describe it. The advantage of mocking is that
you don't have to worry about fully populating dependencies, etc. If I
feel like the implementations that get wired in at production have
already been properly tested, then I will use mocking to test.
In my case, typically, I will fully test services by wiring them with
Spring and having them hit a test database (usually embedded like
hsqldb or derby). Then, once I am confident that the services do what
they advertise, I will unit test the user interface actions (Struts 2
actions, in my case), but injecting mocked services and work on making
sure that the actions operate the way I intend (by setting the mock's
expectations then interacting with the action the way I expect the
framework to call them).
Of course, this is really somewhat outside of the scope of a
maven-users list... If you want to get into the theory of good unit
testing, I think there are a few good books out there. Otherwise, just
get familiar with at least these two techniques and try to
consistently apply a set of practices that best tests your code (as
opposed to attempting to test each and every element of your
application's setup).
-Wes
On Mon, May 3, 2010 at 9:15 AM, Dan King dan.king...@yahoo.com wrote:
Hi all,
I have a webapp (sub)module that uses Spring's dependency injection; how
can/should I load the application context so I may run the unit tests for
this module?
Once all the modules are complete, I will add them to the webapp as
dependencies and load the application context via the web container and
Spring's ContextLoaderListener.
-Dan
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Apache Snapshots Index broken?
Hi Brian, Thanks for looking into this. A specific example is the org.apache.sling:org.apache.sling.commons.auth:0.9.0-SNAPSHOT artifact. The artifact is there, and can be downloaded directly by using Browse Storage on the Snapshots repository. But the Browse Index only shows the pom and sources jar. I had thought about downloading the artifacts and uploading them directly into my proxy, but of course with snapshots that's not an option. Thanks, Andreas On Apr 29, 2010, at 8:12 PM, Brian Fox wrote: That would be me. I'll take a look at the index over there. On Thu, Apr 29, 2010 at 2:32 PM, Andreas Kollegger akolleg...@tembopublic.org wrote: Thanks, I will try the nexus list to see if there is a work-around. The download index option is initially enabled. Since the remote index is broken, I tried disabling that to see if a local index would be built up instead. No luck. But, it's an admin problem for the repository.apache.org maintainers. The problem is easy to see just by browsing https://repository.apache.org/index.html#view-repositories;snapshots-group and comparing the artifacts in the Browse Storage tab versus the Browse Index tab. So, I'm curious who to contact over at apache that is responsible for the server. -Andreas On Apr 29, 2010, at 2:12 PM, Anders Hammar wrote: You should post this question to the nexus users list. /Anders PS. Have you enabled download index for this repo in Nexus? On Thu, Apr 29, 2010 at 19:45, Andreas Kollegger akolleg...@tembopublic.org wrote: Hi, I decided to set up a local Nexus server on my to share artifacts on my local network. Setting up proxies was very easy, but I can't seem to get snapshots from the Apache Snapshot repository at https://repository.apache.org/content/repositories/snapshots . Browsing directly I can see the expected artifacts, but if I browse the index using Nexus, the artifacts are not listed. Does anyone know whom at Apache to contact about this? Thanks, Andreas - 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
Why define repositories in settings.xml and pom?
I am a confused about where repositories need to be defined. I have my repositories defined in my settings.xml file under my default profile. profile iddefault_profile/id activation activeByDefaulttrue/activeByDefault /activation repositories repository idarchiva.internal/id nameInternal Release Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/internal//url snapshots enabledfalse/enabled /snapshots releases enabledtrue/enabled /releases /repository repository idarchiva.snapshots/id nameInternal Snapshot Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/snapshots//url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /repository /repositories /profile I thought this would tell Maven where to store and retrieve all my artifacts. But when I run a deploy it gives me the error Deployment failed: repository element was not specified in the pom inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter If I define the repositories in the pom using the distributionManagement element it works fine. But this seems confusing to me. Why do I have to define them in both places? 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: Why define repositories in settings.xml and pom?
I believe its because deploying a release isn't something you do more than once. However, you may need to rebuild a release from a tag more than once. You may actually need to rebuild many years after a tag was released and your environment may have changed since then and thus need to download artifacts from a different place. -Original Message- From: Timothy Mcginnis [mailto:tmcgi...@aessuccess.org] Sent: Monday, May 03, 2010 10:36 AM To: users@maven.apache.org Subject: Why define repositories in settings.xml and pom? I am a confused about where repositories need to be defined. I have my repositories defined in my settings.xml file under my default profile. profile iddefault_profile/id activation activeByDefaulttrue/activeByDefault /activation repositories repository idarchiva.internal/id nameInternal Release Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/internal//url snapshots enabledfalse/enabled /snapshots releases enabledtrue/enabled /releases /repository repository idarchiva.snapshots/id nameInternal Snapshot Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/snapsho ts//url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /repository /repositories /profile I thought this would tell Maven where to store and retrieve all my artifacts. But when I run a deploy it gives me the error Deployment failed: repository element was not specified in the pom inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter If I define the repositories in the pom using the distributionManagement element it works fine. But this seems confusing to me. Why do I have to define them in both places? 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. == - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why define repositories in settings.xml and pom?
Consider the repositories in your POM to be those for your local development. That's your choice. You put things in the POM if you want to distribute your repository to other people. Having it in the POM means that it gets added to the build and things can be pulled there automatically. I believe JBoss does this with their artifacts. Paul On Mon, May 3, 2010 at 9:46 AM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: I believe its because deploying a release isn't something you do more than once. However, you may need to rebuild a release from a tag more than once. You may actually need to rebuild many years after a tag was released and your environment may have changed since then and thus need to download artifacts from a different place. -Original Message- From: Timothy Mcginnis [mailto:tmcgi...@aessuccess.org] Sent: Monday, May 03, 2010 10:36 AM To: users@maven.apache.org Subject: Why define repositories in settings.xml and pom? I am a confused about where repositories need to be defined. I have my repositories defined in my settings.xml file under my default profile. profile iddefault_profile/id activation activeByDefaulttrue/activeByDefault /activation repositories repository idarchiva.internal/id nameInternal Release Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/internal//url snapshots enabledfalse/enabled /snapshots releases enabledtrue/enabled /releases /repository repository idarchiva.snapshots/id nameInternal Snapshot Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/snapsho ts//url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /repository /repositories /profile I thought this would tell Maven where to store and retrieve all my artifacts. But when I run a deploy it gives me the error Deployment failed: repository element was not specified in the pom inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter If I define the repositories in the pom using the distributionManagement element it works fine. But this seems confusing to me. Why do I have to define them in both places? 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. == - 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: Why define repositories in settings.xml and pom?
http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ On May 3, 2010, at 4:35 PM, Timothy Mcginnis wrote: I am a confused about where repositories need to be defined. I have my repositories defined in my settings.xml file under my default profile. profile iddefault_profile/id activation activeByDefaulttrue/activeByDefault /activation repositories repository idarchiva.internal/id nameInternal Release Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/internal//url snapshots enabledfalse/enabled /snapshots releases enabledtrue/enabled /releases /repository repository idarchiva.snapshots/id nameInternal Snapshot Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/snapshots//url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /repository /repositories /profile I thought this would tell Maven where to store and retrieve all my artifacts. But when I run a deploy it gives me the error Deployment failed: repository element was not specified in the pom inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter If I define the repositories in the pom using the distributionManagement element it works fine. But this seems confusing to me. Why do I have to define them in both places? 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. == Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: Why define repositories in settings.xml and pom?
I see repositories and not deploymentManagement, so unless I'm confused there's nothing here to make the 'write' side work. On Mon, May 3, 2010 at 11:27 AM, Jason van Zyl ja...@sonatype.com wrote: http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ On May 3, 2010, at 4:35 PM, Timothy Mcginnis wrote: I am a confused about where repositories need to be defined. I have my repositories defined in my settings.xml file under my default profile. profile iddefault_profile/id activation activeByDefaulttrue/activeByDefault /activation repositories repository idarchiva.internal/id nameInternal Release Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/internal//url snapshots enabledfalse/enabled /snapshots releases enabledtrue/enabled /releases /repository repository idarchiva.snapshots/id nameInternal Snapshot Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/snapshots//url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /repository /repositories /profile I thought this would tell Maven where to store and retrieve all my artifacts. But when I run a deploy it gives me the error Deployment failed: repository element was not specified in the pom inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter If I define the repositories in the pom using the distributionManagement element it works fine. But this seems confusing to me. Why do I have to define them in both places? 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. == Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
RE: Why define repositories in settings.xml and pom?
I don't think the original poster was questioning whether or not artifacts should be downloaded from repos defined in settings.xml. But rather artifacts that get deployed do not go in settings.xml. They have to go in the pom. Why do these repos not also go in settings.xml? I agree with the OP that this is a bit confusing. -Original Message- From: Jason van Zyl [mailto:ja...@sonatype.com] Sent: Monday, May 03, 2010 11:27 AM To: Maven Users List Subject: Re: Why define repositories in settings.xml and pom? http://www.sonatype.com/people/2009/02/why-putting-repositorie s-in-your-poms-is-a-bad-idea/ On May 3, 2010, at 4:35 PM, Timothy Mcginnis wrote: I am a confused about where repositories need to be defined. I have my repositories defined in my settings.xml file under my default profile. profile iddefault_profile/id activation activeByDefaulttrue/activeByDefault /activation repositories repository idarchiva.internal/id nameInternal Release Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/internal//url snapshots enabledfalse/enabled /snapshots releases enabledtrue/enabled /releases /repository repository idarchiva.snapshots/id nameInternal Snapshot Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/snapsho ts//url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /repository /repositories /profile I thought this would tell Maven where to store and retrieve all my artifacts. But when I run a deploy it gives me the error Deployment failed: repository element was not specified in the pom inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter If I define the repositories in the pom using the distributionManagement element it works fine. But this seems confusing to me. Why do I have to define them in both places? 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. == Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why define repositories in settings.xml and pom?
The reason you can define them in two places is that Maven separates the configuration of the repository from which you read artifacts from those which you write (or _distribute_) artifacts (and further separates the repository to which you distribute snapshots from that to which you distribute releases). The former can be specified in either settings.xml or pom.xml. The latter can only be specified in pom.xml. I think the best way to think about this is that the read side is (or should be) an aspect of your environment whereas the write side is an aspect of your project. HTH, Justin On Mon, May 3, 2010 at 10:35 AM, Timothy Mcginnis tmcgi...@aessuccess.orgwrote: I am a confused about where repositories need to be defined. I have my repositories defined in my settings.xml file under my default profile. profile iddefault_profile/id activation activeByDefaulttrue/activeByDefault /activation repositories repository idarchiva.internal/id nameInternal Release Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/internal//url snapshots enabledfalse/enabled /snapshots releases enabledtrue/enabled /releases /repository repository idarchiva.snapshots/id nameInternal Snapshot Repository/name url http://2e02057b.aessuccess.org:8085/archiva/repository/snapshots//url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /repository /repositories /profile I thought this would tell Maven where to store and retrieve all my artifacts. But when I run a deploy it gives me the error Deployment failed: repository element was not specified in the pom inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter If I define the repositories in the pom using the distributionManagement element it works fine. But this seems confusing to me. Why do I have to define them in both places? 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: Why define repositories in settings.xml and pom?
I think the best way to think about this is that the read side is (or should be) an aspect of your environment whereas the write side is an aspect of your project. Very true. But we should make it clear why reading is an aspect of your environment whereas writing is an aspect of your project. I think the reason is when your deploying a project, you are doing so because you are making an actual change to the code itself. If you are already changing the code and the server to which you deploy to also happens to change, it is a relatively simple matter to change the pom at the same time you are changing the code. However, you may want to build an EXACT version of software that was previously deployed but the repos you read from may not be the same since the time the software was first deployed to the time you want to repeat the build. Thus you don't want to touch any of the source code, including the pom. You can change the settings.xml file point to the repos you are currently reading from. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: project version as a property?
On Mon, May 3, 2010 at 12:37 PM, Frank Maritato
fmarit...@attinteractive.com wrote:
Hi,
I have a multi module project and in my top level pom I am using a property
to define the version number like this:
version${myproject.version}/version
properties
myproject.version0.1/myproject.version
/properties
All my submodules inherit from this pom and all define version the same
way. Within the context of this project it all works and everything is cool.
The problem I have is when I try to import one of these libraries into
another project I get an error that it can't resolve the parent of my
dependency because it isn't resolving that property value.
When I look in my .m2/repository directory at the pom for that project it
still has the unresolved ${myproject.version} string in there. I have tried
defining that property in the other project that is importing that
dependency but it still doesn't work.
Is this not the way we should define our project? Should we just use
explicit version numbers in our pom's?
Yes.
--
Frank Maritato
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-D versus properties at top level and in profiles
We thought (my coworkers and I) that -D would win any conflict of properties. But we seem to be experiencing something more complex when we've got the same property in three places: -D, parent properties, and profile properties. The command line isn't always winning. What are we missing? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: project version as a property?
What I've surmised from the various sources of maven thinking, is that
1) The parent element should identify the parent using explicit (no
properties) values
2) The child project can then inherit from the parent the groupId
3) The child project should also define its version explicitly
The release plugin expects this and has code to adjust these values
inside the pom, as the release happens. They go from x.y.z-SNAPSHOT to
x.y.z (without the snapshot), to x.y.(z+1)-SNAPSHOT for the next
release snapshot (the last one is changeable, to correspond to your
release numbering - see the documentation for the release plugin).
The point of all that is that the tooling tries to take care of
mass-updating these fixed version numbers. This might reduce the
motivation of using substitutable property names (that is, if the
motivation was to have one spot to update, and have that update
propagated to the other poms).
-Marshall Schor
On 5/3/2010 12:37 PM, Frank Maritato wrote:
Hi,
I have a multi module project and in my top level pom I am using a
property to define the version number like this:
version${myproject.version}/version
properties
myproject.version0.1/myproject.version
/properties
All my submodules inherit from this pom and all define version the
same way. Within the context of this project it all works and
everything is cool. The problem I have is when I try to import one of
these libraries into another project I get an error that it can't
resolve the parent of my dependency because it isn't resolving that
property value.
When I look in my .m2/repository directory at the pom for that project
it still has the unresolved ${myproject.version} string in there. I
have tried defining that property in the other project that is
importing that dependency but it still doesn't work.
Is this not the way we should define our project? Should we just use
explicit version numbers in our pom's?
--
Frank Maritato
-
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: project version as a property?
Does this imply a rule 4) The parent should define properties for all of
the dependency versions for the shared libraries that the children need?
Does this go in dependency management or simply as a set of properties
that are passed on to the children?
Ron
On 03/05/2010 2:44 PM, Marshall Schor wrote:
What I've surmised from the various sources of maven thinking, is that
1) Theparent element should identify the parent using explicit (no
properties) values
2) The child project can then inherit from the parent thegroupId
3) The child project should also define its version explicitly
The release plugin expects this and has code to adjust these values
inside the pom, as the release happens. They go from x.y.z-SNAPSHOT to
x.y.z (without the snapshot), to x.y.(z+1)-SNAPSHOT for the next
release snapshot (the last one is changeable, to correspond to your
release numbering - see the documentation for the release plugin).
The point of all that is that the tooling tries to take care of
mass-updating these fixed version numbers. This might reduce the
motivation of using substitutable property names (that is, if the
motivation was to have one spot to update, and have that update
propagated to the other poms).
-Marshall Schor
On 5/3/2010 12:37 PM, Frank Maritato wrote:
Hi,
I have a multi module project and in my top level pom I am using a
property to define the version number like this:
version${myproject.version}/version
properties
myproject.version0.1/myproject.version
/properties
All my submodules inherit from this pom and all defineversion the
same way. Within the context of this project it all works and
everything is cool. The problem I have is when I try to import one of
these libraries into another project I get an error that it can't
resolve the parent of my dependency because it isn't resolving that
property value.
When I look in my .m2/repository directory at the pom for that project
it still has the unresolved ${myproject.version} string in there. I
have tried defining that property in the other project that is
importing that dependency but it still doesn't work.
Is this not the way we should define our project? Should we just use
explicit version numbers in our pom's?
--
Frank Maritato
-
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: Check scm/ urls?
I'm not aware of one, but I'd love to have one if it were available - it's somewhere on my to do list to see if I can do it, but I don't see doing it any time soon. On Thu, Apr 29, 2010 at 9:08 AM, Benson Margulies bimargul...@gmail.comwrote: Is there any plugin which will check the consistency of the scm URLs, at least for svn, with the actual status of the tree?
Re: -D versus properties at top level and in profiles
Thanks. This forced me to retrace my steps and find the real problem.
On Mon, May 3, 2010 at 3:43 PM, Kalpak Gadre kalpa...@gmail.com wrote:
Try this,
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.test/groupId
artifactIdproperty/artifactId
version0.0.1-SNAPSHOT/version
properties
mypropproject/myprop
/properties
profiles
profile
idfoo/id
properties
mypropproject-profile/myprop
/properties
/profile
/profiles
build
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasetest/phase
configuration
tasks
echo message=Value: ${myprop} /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/project
Works as expected for me as of 2.2.1 -D always wins.
I thought -D would win always too.
On Mon, May 3, 2010 at 1:32 PM, Benson Marguliesbimargul...@gmail.com
wrote:
We thought (my coworkers and I) that -D would win any conflict of
properties. But we seem to be experiencing something more complex when
we've got the same property in three places: -D, parentproperties,
and profileproperties. The command line isn't always winning.
What are we missing?
-
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
Attached files not getting unique identifier when deployed
All, I have a simple maven project that generates a jar file; with the classifier 'config'. When I call the 'deploy' phase, the pom file is uploaded with unique identifier (as expected) but the jar file is not (see examples below); the maven metadata is updated with the timestamp as well. When I put a dependency on the jar file, Maven can not resolve the artifact because it's looking for the jar file with the timestamp (as denoted by the maven-metadata file). Has anyone else seen this issue? I'm using Maven 2.2.1 on Solaris. [Example] -rw-r--r-- 1 archiva archiva 382 May 3 18:47 maven-metadata.xml -rw-r--r-- 1 archiva archiva 52 May 3 18:47 maven-metadata.xml.md5 -rw-r--r-- 1 archiva archiva 60 May 3 18:47 maven-metadata.xml.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.sha1 -rw-r--r-- 1 archiva archiva 4080 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.sha1 -rw-r--r-- 1 archiva archiva 757 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.sha1 -rw-r--r-- 1 archiva archiva 4157 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.sha1 [maven-metadata.xml] ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.mycompany/groupId artifactIdmyApplication/artifactId version1.0.0-SNAPSHOT/version versioning snapshot buildNumber3/buildNumber timestamp20100503.224708/timestamp /snapshot lastUpdated20100503224708/lastUpdated /versioning /metadata - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: project version as a property?
On 5/3/2010 4:05 PM, Ron Wheeler wrote:
Does this imply a rule 4) The parent should define properties for all
of the dependency versions for the shared libraries that the children
need?
Things go in parents when you can see you are repeating yourself in the
children; moving those items to parents generally improves the
maintainability. But if a child is the only thing using a dependency,
moving it to a parent makes the child less easy to read and understand
(because, of course, you have to go and read the parent too).
Does this go in dependency management or simply as a set of
properties that are passed on to the children?
The POMs are clearer when you put these in dependencyManagement, I think.
-Marshall
Ron
On 03/05/2010 2:44 PM, Marshall Schor wrote:
What I've surmised from the various sources of maven thinking, is that
1) Theparent element should identify the parent using explicit (no
properties) values
2) The child project can then inherit from the parent thegroupId
3) The child project should also define its version explicitly
The release plugin expects this and has code to adjust these values
inside the pom, as the release happens. They go from x.y.z-SNAPSHOT to
x.y.z (without the snapshot), to x.y.(z+1)-SNAPSHOT for the next
release snapshot (the last one is changeable, to correspond to your
release numbering - see the documentation for the release plugin).
The point of all that is that the tooling tries to take care of
mass-updating these fixed version numbers. This might reduce the
motivation of using substitutable property names (that is, if the
motivation was to have one spot to update, and have that update
propagated to the other poms).
-Marshall Schor
On 5/3/2010 12:37 PM, Frank Maritato wrote:
Hi,
I have a multi module project and in my top level pom I am using a
property to define the version number like this:
version${myproject.version}/version
properties
myproject.version0.1/myproject.version
/properties
All my submodules inherit from this pom and all defineversion the
same way. Within the context of this project it all works and
everything is cool. The problem I have is when I try to import one of
these libraries into another project I get an error that it can't
resolve the parent of my dependency because it isn't resolving that
property value.
When I look in my .m2/repository directory at the pom for that project
it still has the unresolved ${myproject.version} string in there. I
have tried defining that property in the other project that is
importing that dependency but it still doesn't work.
Is this not the way we should define our project? Should we just use
explicit version numbers in our pom's?
--
Frank Maritato
-
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: Attached files not getting unique identifier when deployed
it looks like your jar file has no classifier. A plain jar file is being uploaded. Can you post the part of the POM where you are defining the classifier artifact, and attaching it? -Marshall On 5/3/2010 7:09 PM, Michael Delaney wrote: All, I have a simple maven project that generates a jar file; with the classifier 'config'. When I call the 'deploy' phase, the pom file is uploaded with unique identifier (as expected) but the jar file is not (see examples below); the maven metadata is updated with the timestamp as well. When I put a dependency on the jar file, Maven can not resolve the artifact because it's looking for the jar file with the timestamp (as denoted by the maven-metadata file). Has anyone else seen this issue? I'm using Maven 2.2.1 on Solaris. [Example] -rw-r--r-- 1 archiva archiva 382 May 3 18:47 maven-metadata.xml -rw-r--r-- 1 archiva archiva 52 May 3 18:47 maven-metadata.xml.md5 -rw-r--r-- 1 archiva archiva 60 May 3 18:47 maven-metadata.xml.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.sha1 -rw-r--r-- 1 archiva archiva 4080 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.sha1 -rw-r--r-- 1 archiva archiva 757 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.sha1 -rw-r--r-- 1 archiva archiva 4157 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.sha1 [maven-metadata.xml] ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.mycompany/groupId artifactIdmyApplication/artifactId version1.0.0-SNAPSHOT/version versioning snapshot buildNumber3/buildNumber timestamp20100503.224708/timestamp /snapshot lastUpdated20100503224708/lastUpdated /versioning /metadata - 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: Attached files not getting unique identifier when deployed
i usually deploy specify packaging=pom http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html then deploy by specifying packaging=jar http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Mon, 3 May 2010 19:09:56 -0400 From: mdela...@upromise.com To: users@maven.apache.org Subject: Attached files not getting unique identifier when deployed All, I have a simple maven project that generates a jar file; with the classifier 'config'. When I call the 'deploy' phase, the pom file is uploaded with unique identifier (as expected) but the jar file is not (see examples below); the maven metadata is updated with the timestamp as well. When I put a dependency on the jar file, Maven can not resolve the artifact because it's looking for the jar file with the timestamp (as denoted by the maven-metadata file). Has anyone else seen this issue? I'm using Maven 2.2.1 on Solaris. [Example] -rw-r--r-- 1 archiva archiva 382 May 3 18:47 maven-metadata.xml -rw-r--r-- 1 archiva archiva 52 May 3 18:47 maven-metadata.xml.md5 -rw-r--r-- 1 archiva archiva 60 May 3 18:47 maven-metadata.xml.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.sha1 -rw-r--r-- 1 archiva archiva 4080 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.sha1 -rw-r--r-- 1 archiva archiva 757 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.sha1 -rw-r--r-- 1 archiva archiva 4157 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.sha1 [maven-metadata.xml] ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.mycompany/groupId artifactIdmyApplication/artifactId version1.0.0-SNAPSHOT/version versioning snapshot buildNumber3/buildNumber timestamp20100503.224708/timestamp /snapshot lastUpdated20100503224708/lastUpdated /versioning /metadata - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
Re: Why define repositories in settings.xml and pom?
This seems like a very specific use case. I think it's more to the point to say that many people (including, I suspect, 100% of Maven developers) use the same workstation to work on projects which are deployed to different repositories, e.g. apache, codehaus, shudder java.net, a corporate repository, etc. It doesn't make sense to deploy an apache.org project to the codehaus repository or vice versa. Nor do you want to deploy corporate artifacts to the java.net repository. Thus, artifact deployment/distribution is project-specific. However, in all of those cases, you can use the same mirror of central. And which mirror you pick should be based on your environment, not the particular project. It should either be the closet mirror or a nearby caching repository manager. If you want build reproducibility, you should be using release artifacts and only reference repositories with immutability rules. You should be able to reproduce a build using an entirely different mirror (again, assuming repository immutability). If you reference mutable repositories, you lose build reproducibility regardless of what you put in your pom or settings.xml. Justin On 5/3/10 11:59 AM, Thiessen, Todd (Todd) wrote: I think the best way to think about this is that the read side is (or should be) an aspect of your environment whereas the write side is an aspect of your project. Very true. But we should make it clear why reading is an aspect of your environment whereas writing is an aspect of your project. I think the reason is when your deploying a project, you are doing so because you are making an actual change to the code itself. If you are already changing the code and the server to which you deploy to also happens to change, it is a relatively simple matter to change the pom at the same time you are changing the code. However, you may want to build an EXACT version of software that was previously deployed but the repos you read from may not be the same since the time the software was first deployed to the time you want to repeat the build. Thus you don't want to touch any of the source code, including the pom. You can change the settings.xml file point to the repos you are currently reading from. - 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:m2eclipse
On Mon, May 3, 2010 at 9:56 PM, Crow, Neil NW neil.c...@standardbank.co.za wrote: Thanks Martin, I guess that the m2eclipse-mojo page would have to be removed manually. http://maven.apache.org/plugins/maven-eclipse-plugin/m2eclipse-mojo The 2.8 version doesn't include that as a goal: http://maven.apache.org/plugins/maven-eclipse-plugin/plugin-info.html There is nothing in the source repository to fix up. Perhaps the deploy process copied the files into the existing directory instead of renaming the old directory first and creating a fresh directory. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: jetty plugin and gmaven
I can't say if the jetty plugin config is correct, but for it to apply when you run jetty:run you need to move it to the pluginManagement section. http://maven.apache.org/pom.html#Plugin_Management /Anders On Mon, May 3, 2010 at 20:45, Bill Smith ne...@weseewhathappens.com wrote: I am trying to create a web project that has a mixture of both groovy code and java code. I am using the following for my pom. When running maven jetty:run it can't see my groovy scripts. running mvn package I do see the compiled classes in the war file. Any ideas what I am doing wrong? build finalNameweb/finalName plugins plugin groupIdorg.codehaus.groovy.maven/groupId artifactIdgmaven-plugin/artifactId executions execution goals goalcompile/goal /goals /execution /executions /plugin plugin groupIdorg.mortbay.jetty/groupId artifactIdmaven-jetty-plugin/artifactId version6.1.9/version configuration scanIntervalSeconds2/scanIntervalSeconds requestLog implementation=org.mortbay.jetty.NCSARequestLog filenametarget/_mm_dd.request.log/filename retainDays2/retainDays appendtrue/append extendedfalse/extended logTimeZoneGMT/logTimeZone /requestLog /configuration /plugin /plugins /build
Re: Attached files not getting unique identifier when deployed
You should be executing mvn deploy which will deploy your project. /Anders On Tue, May 4, 2010 at 02:17, Martin Gainty mgai...@hotmail.com wrote: i usually deploy specify packaging=pom http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html then deploy by specifying packaging=jar http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Mon, 3 May 2010 19:09:56 -0400 From: mdela...@upromise.com To: users@maven.apache.org Subject: Attached files not getting unique identifier when deployed All, I have a simple maven project that generates a jar file; with the classifier 'config'. When I call the 'deploy' phase, the pom file is uploaded with unique identifier (as expected) but the jar file is not (see examples below); the maven metadata is updated with the timestamp as well. When I put a dependency on the jar file, Maven can not resolve the artifact because it's looking for the jar file with the timestamp (as denoted by the maven-metadata file). Has anyone else seen this issue? I'm using Maven 2.2.1 on Solaris. [Example] -rw-r--r-- 1 archiva archiva 382 May 3 18:47 maven-metadata.xml -rw-r--r-- 1 archiva archiva 52 May 3 18:47 maven-metadata.xml.md5 -rw-r--r-- 1 archiva archiva 60 May 3 18:47 maven-metadata.xml.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.sha1 -rw-r--r-- 1 archiva archiva 4080 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.sha1 -rw-r--r-- 1 archiva archiva 757 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.sha1 -rw-r--r-- 1 archiva archiva 4157 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.sha1 [maven-metadata.xml] ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.mycompany/groupId artifactIdmyApplication/artifactId version1.0.0-SNAPSHOT/version versioning snapshot buildNumber3/buildNumber timestamp20100503.224708/timestamp /snapshot lastUpdated20100503224708/lastUpdated /versioning /metadata - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
Re: mvn eclipse:m2eclipse
Yes, I've seen mails on the mvn-dev list before regarding old (and invalid) pages not being removed during release. The big problem here is that they still show up on google searches. I would suggest filing a jira on the project, asking them to remove the page. /Anders On Tue, May 4, 2010 at 05:52, Barrie Treloar baerr...@gmail.com wrote: On Mon, May 3, 2010 at 9:56 PM, Crow, Neil NW neil.c...@standardbank.co.za wrote: Thanks Martin, I guess that the m2eclipse-mojo page would have to be removed manually. http://maven.apache.org/plugins/maven-eclipse-plugin/m2eclipse-mojo The 2.8 version doesn't include that as a goal: http://maven.apache.org/plugins/maven-eclipse-plugin/plugin-info.html There is nothing in the source repository to fix up. Perhaps the deploy process copied the files into the existing directory instead of renaming the old directory first and creating a fresh directory. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
how to deploy a local plugin to artifactory plugin repository
Hi,
what do i need to write in the distributionManagement tag, in order to
deploy a maven plugin i wrote?
(to a pluginRepository, so that other developers can use the plugin)
i don't mind donating it to the community if someone is interested.
it's a plugin for maven-rpm-plugin: it scans current maven dependencies and
insert new 'require' tag for each one.
i have the following parent pom as far:
.
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
snapshotRepositoryhttp:///artifactory/libs-snapshots-localhttp://ct-repo01:8081/artifactory/libs-snapshots-local
/snapshotRepository
releasesRepositoryhttp:///artifactory/libs-releases-localhttp://ct-repo01:8081/artifactory/libs-releases-local
/releasesRepository
/properties
build
pluginManagement
plugins
/plugins
/pluginManagement
/build
distributionManagement
repository
idxx-repo01/id
nameXXX Releases/name
url${releasesRepository}/url
/repository
snapshotRepository
idxx-repo01/id
nameXXX Snapshots/name
url${snapshotRepository}/url
/snapshotRepository
/distributionManagement
/project
--
Eyal Edri
--
Eyal Edri
