RE: error !!!
Very kind of you, Wendy, to try and answer to this type of request... No "Hi", no "thanks", and no real explanation of the problem and/or proof the guy tried a bit to find the cause by himself... Without speaking about the fact that this mail seem to have been sent twice... Cheers. -Message d'origine- De : Wendy Smoak [mailto:[EMAIL PROTECTED] Envoyé : vendredi 11 juillet 2008 07:51 À : Maven Users List Objet : Re: error !!! On Thu, Jul 10, 2008 at 10:43 PM, nikhil123 <[EMAIL PROTECTED]> wrote: > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean- > plugin/2.2/maven-clean-plugin-2.2.pom ... > [INFO] Failed to resolve artifact. Not a lot to go on here, but the usual problem is that you're behind an http proxy and haven't told Maven about it. Is that the case? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simpler way....
No, it's not. Have a look at the maven pom xsd and you'll see it's not possible. http://maven.apache.org/maven-v4_0_0.xsd If you use a good IDE (Eclipse, Netbeans ?), put this on the beginning of your pom.xml : 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";> ... It will give you auto-completion and will simplify the task of knowing which tag is allowed or not. Cheers -Message d'origine- De : Marvin Froeder [mailto:[EMAIL PROTECTED] Envoyé : vendredi 27 juin 2008 22:09 À : Maven Users List Objet : Simpler way Hi, I have my custom plugin. And I wanna to run it on a project. So I add it at build->plugins maven-source-plugin jar Now my question, is there any simpler way to do that? May be like this: maven-source-plugin jar VELO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven 2.0.9 unable to download artificats
Just a lucky guess: maybe you had a customized settings.xml in your old maven installation that you didn't copy inside the new 2.0.9 conf directory? Something like the proxy parameters would be an obvious reason for the artefact retrieving to fail. Cheers. -Message d'origine- De : shady kazan [mailto:[EMAIL PROTECTED] Envoyé : mercredi 25 juin 2008 13:46 À : users@maven.apache.org Objet : maven 2.0.9 unable to download artificats I just installed maven2.0.9 on my Windows XP. I verified the installation and all seems to work fine except that it crashes trying to download needed artifacts.I'm behind a proxy server, my corporate proxy which is an NTLM proxy. I know there used to be an issue with maven behind NTLM proxies with versions prior to 2.0.9 and that they have been resolved in 2.0.9.Anyway, here's what i'm getting when i try. i have adjusted the proxy setings in the settings.xml file as appropriate but still no effect C:\Dev\> mvn -e package + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Building Unnamed - wrox:pixweb:war:0.0.1 [INFO]task-segment: [package] [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/1/maven-plugins-1.pom Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/1/maven-plugins-1.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.maven.plugins ArtifactId: maven-plugins Version: 1 Reason: Unable to download the artifact from any repository org.apache.maven.plugins:maven-plugins:pom:1 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build project for plugin 'org.apache.maven.plugins:mav en-resources-plugin': Cannot find parent: org.apache.maven.plugins:maven-plugins for project: null:maven-resources-plugi n:maven-plugin:2.2 for project null:maven-resources-plugin:maven-plugin:2.2 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1 033) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java: 997) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.InvalidPluginException: Unable to build project for plugin 'org.apache.maven.plugins: maven-resources-plugin': Cannot find parent: org.apache.maven.plugins:maven-plugins for project: null:maven-resources-pl ugin:maven-plugin:2.2 for project null:maven-resources-plugin:maven-plugin:2.2 at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:281) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) ... 18 more Caused by: org.apache.maven.project.ProjectBuildingException: Cann
RE: Avoiding a parent project from being installed into the repository
I seem to remember something that could help you that was spoken about some times ago. In fact, something like -Dskip=true to avoid install or deploy. I just crawled the archive, but couldn't find it back, maybe you'll be luckier: http://www.nabble.com/forum/Search.jtp?query=skip+deploy&local=y&page=1&forum=178&daterange=0 Well, maybe this one: http://www.nabble.com/Deploying-only-some-modules-td17132557.html#a17132629 And this one too, but still unreleased (see http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-deploy-plugin/ to be able to use the 2.4-SNAPSHOT version): http://jira.codehaus.org/browse/MDEPLOY-63 Well, it's not totally answering your question as it's install you don't want to do. I don't remember about skipping install. Though imo it's not very important to look at your local repo, being far more important to watch out what you deploy on your corporate repo than the local one. My 2 cents. Cheers. -Message d'origine- De : Vincent Thévenin [mailto:[EMAIL PROTECTED] Envoyé : lundi 23 juin 2008 13:26 À : users@maven.apache.org Objet : Avoiding a parent project from being installed into the repository Hello, I'm using Maven 2.0.9. I have a project with the following layout: project |-- pom.xml (packaging = pom) |-- ejb_subproject | |-- pom.xml (packaging = ejb) | `-- . . . `-- ear_subproject |-- pom.xml (packaging = ear) `-- . . . The two subprojects are declared as modules of the top pom.xml. Invoking Maven on the top pom.xml first launches a build on the ejb_project (which creates two artifacts, a Jar and an EJB client Jar), then on the ear_project (which creates an Ear using the Jar of the ejb_project). My issue is that installing the artifacts into the repository by invoking 'mvn install' on the top pom.xml creates three entries in the repository, one for the ejb_subproject, one for the ear_subproject and finally one for the top pom.xml, the latter being actually empty. Is it possible to inform Maven that the pom.xml of type 'pom' should not be installed into the repository, but just exists to make an entry point for the build of the two other projects? Thanks in advance. Vincent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: -U
-Message d'origine- > De : Geoffrey Wiseman [mailto:[EMAIL PROTECTED] > Envoyé : mardi 17 juin 2008 16:19 > À : Maven Users List > Objet : Re: -U > > On Tue, Jun 17, 2008 at 9:59 AM, SlinnHawkins, Jon (ELS-CAM) < > [EMAIL PROTECTED]> wrote: > > > Unfortunately - its updates to released versions. > > > > Well, as long as you recognize this isn't a particularly good idea and may > have all sorts of unintended side effects, the simplest action is to clear > the old jars out of your local repo, forcing Maven to look for them. To do that, maybe using mvn dependency:purge-local-repository could be a more selective way to achieve the very same goal. Cheers. -- Baptiste - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Upgrading maven?
Hi copo, I don't know the mac at all, but I guess you just need to have a JDK to be able to use maven whatever version. So, if you're already using the 2.0.6, just download it from http://maven.apache.org/download.html and simply try to use it instead if the old one. To test it, maybe try making something like a bug mvn verify on some projects before upgrading, using 2.0.6, then configure your envt to use the 2.0.9 (if you modified the conf/settings.xml, think about copying it into the new mvn 2.0.9) and restart the "mvn verify"s you previously ran successly and check out that it stills works OK. That's how I proceeded to upgrade. I guess you'll have no difficulties. If you have some while trying, let us know which. Cheers. -Message d'origine- De : Copo [mailto:[EMAIL PROTECTED] Envoyé : vendredi 20 juin 2008 16:45 À : users@maven.apache.org Objet : Upgrading maven? I am learning to use servicemix and maven for 2 days. My version of maven is 2.0.6 and I seem to need a more recent. I work with mac osX 10.5.3, how can I just upgrade maven to 2.0.9? Thank you in advance Copo -- View this message in context: http://www.nabble.com/Upgrading-maven--tp18031091p18031091.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Renaming an artifact...
> -Message d'origine- > De : Wendy Smoak [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 9 avril 2008 17:22 > You may be thinking of "relocation" [1] ,but so far I've only > seen it used for changing groupIds. > > [1] http://maven.apache.org/guides/mini/guide-relocation.html FWIW: I already used this guide to relocate an artifact whom I'm changed groupId, artifactId AND version. It worked very well. Cheers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Adding a Main-Class to a jar-with-dependencies jar?
Hi, Having a look in the assembly plugin documentation: http://maven.apache.org/plugins/maven-assembly-plugin/usage.html Then "Advanced Config/Creating an Executable Jar", wouldn't it help? Excerpt: maven-assembly-plugin [...] org.sample.App [...] Cheers > -Message d'origine- > De : Mark Derricutt [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 9 avril 2008 07:14 > À : Maven Users List > Objet : Adding a Main-Class to a jar-with-dependencies jar? > > Hey all, > > http://docs.codehaus.org/pages/viewpage.action?pageId=72602 > shows how to set the Main-Class for a .jar file using the > maven-jar-plugin and thats fine, but I was wondering if this > could also be applied to the jar being made from the assembly > plugin somehow? > > Do I need to make a custom assembly descriptor for this? > > Thanks, > Mark > > -- > "It is easier to optimize correct code than to correct > optimized code." -- Bill Harlan > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: release : Unable to check for local modifications
What's the output of svn --non-interactive status when you do it manually? I once had a problem because of the internationalization of the messages. In my case, the svn messages were displayed in french. The calling code (was maven-buidnumber-plugin now that I think of it) was trying to parse the svn output. But as the code was written only for english output, it didn't work. The way I did: I deleted the i18n properties files from the local svn installation, then it worked fine. Cheers. > -Message d'origine- > De : Oscar Picasso [mailto:[EMAIL PROTECTED] > Envoyé : lundi 31 mars 2008 21:19 > À : Maven Users List > Objet : release : Unable to check for local modifications > > Hi, > > When I do a release:prepare I get an "Unable to check for > local modifications" (see below). > > From the logs it seems the problem come when maven tries to > execute svn --non-interactive status. > > However if I execute svn --non-interactive status, it works > fine. Any idea ? > > Thanks > > == > === > [INFO] [release:prepare] > [INFO] Resuming release from phase 'scm-check-modifications' > [INFO] Verifying that there are no local modifications... > [INFO] Executing: svn --non-interactive status [INFO] Working > directory: C:\mycomp\workspace\my-app [INFO] > -- > -- > [ERROR] BUILD FAILURE > [INFO] > -- > -- > [INFO] Unable to check for local modifications Provider message: > The svn command failed. > Command output: > > [INFO] > -- > -- > [INFO] Trace > org.apache.maven.BuildFailureException: Unable to check for > local modifications Provider message: > The svn command failed. > Command output: > > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals > (Defa > ultLifecycleExecutor.java:560) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone > Goal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal > (Defau > ltLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:224) > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute > (DefaultLi > fecycleExecutor.java:143) > at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at > org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl. > java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java > :315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java > :430) > > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoFailureException: > Unable to check for loc al modifications Provider message: > The svn command failed. > Command output: > > at org.apache.maven.plugins.release.PrepareReleaseMojo.execute > (PrepareRe > leaseMojo.java:144) > at org.apache.maven.plugin.DefaultPluginManager.executeMojo > (DefaultPlugi > nManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals > (Defa > ultLifecycleExecutor.java:539) > ... 16 more > [INFO] > -- > -- > [INFO] Total time: 23 seconds > [INFO] Finished at: Mon Mar 31 13:31:51 EDT 2008 [INFO] Final > Memory: 31M/57M [INFO] - > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Passing parameters to maven classes
Hi all,
I've got some small questions about plugin development. More particularly about
passing parameters.
If you think this question should better be asked on the mvn-dev ML, please let
me know.
I saw how to do it for a mojo: according to a declaration like this:
/**
* @parameter expression="${project.packaging}"
* @required
* @readonly
*/
plexus, the IoC framework used by maven will then pass the requested -D params
to the mojo.
But what about maven "core" projects (how do you call it, btw? Maven core?
Non-mojo? maven api?). For example, say I want that a -Dvar=value variable be
passed to some maven code that's not a mojo (wagon-provider-api, maven-artifact
e.g.). Some switch that I would like to use in this maven api code.
What's the practice to do it?
Should I manage the parameter in the mojo, and then add a parameter in the
non-mojo code to pass the retrieved value from the calling mojo to the api code?
Should I use some special "configurer" from plexus to inject system property
directly into the api code?
Thanks a lot in advance.
Cheers.
-- Baptiste
RE : [deploy-plugin] Abort deploy when a target is present
Hi all, If some people were still interested in this subject, I found the code&commit Brian was speaking about. I also commented the bug I logged: http://jira.codehaus.org/browse/MDEPLOY-74?focusedCommentId=129147#action_129147 The related improvement request (logged by Jason): http://jira.codehaus.org/browse/MARTIFACT-6 With this modification, at the moment, the situation will be reversed: you won't be able to redeploy an artifact that has already been deployed (no problem for snapshot, which is taken apart). So, don't do mistakes :). You'll have to connect to your repository and manually deploy the wrong artifact(s). Anyway, Imo, it's actually far better to have no option in this case than in the old one (being able to redeploy any time you want). Cheers. -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Fri 3/28/2008 2:59 PM To: Maven Users List Subject: RE: RE : [deploy-plugin] Abort deploy when a target is present I'd have to check on this. I know in 2.1 it's on by default and there is no way to force it. Perhaps Jason put it in the wagon manager or something and not the plugin. -Original Message- From: MATHUS Baptiste [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2008 2:53 AM To: Maven Users List Subject: RE : [deploy-plugin] Abort deploy when a target is present Great news! I had a quick look on https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/ and did not see any log related to it. So was there already a logged bug about this: http://jira.codehaus.org/browse/MDEPLOY-74 What/where is the "new code", some 3.x or something? So, is there another svn repository for this? In fact, I'd be happy to be able to either use a new released version or help merging back this feature if possible. Cheers Message d'origine De: Brian E. Fox [mailto:[EMAIL PROTECTED] Date: jeu. 27/03/2008 18:45 À: Maven Users List Objet : RE: [deploy-plugin] Abort deploy when a target is present This is the default in the new code, but it wasn't merged back to 2.0.x I believe. -Original Message- From: MATHUS Baptiste [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 9:32 AM To: Maven Users List Subject: [deploy-plugin] Abort deploy when a target is present Hi all, Recently, some developers did a release manually. So they put a release version in the pom and triggered a deploy. Everything fine but... The thing is: they forgot to re-update the pom.version to a new snapshot version. So, as the code is continuously integrated, at each new commit, the recent release was "automatically" overridden many times with the snapshot code before realizing it :-/. So, what I would like is to be able to put an additional option for maven when run inside the continuous integration server, something like -DdontOverrideRelease, that would make fail the deployment if the released artefact is already present. I've taken a quick look at http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html but it seems it's not currently possible. What do you think? Can a file an feature request about it in the plugin tracker? Thanks a lot. Cheers. -- Baptiste - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: apt-get repository
I you use eclipse, give a try to m2eclipse, there's an "add dependency" that has a autocomplete feature. Cheers. > -Message d'origine- > De : neo anderson [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 28 mars 2008 10:58 > À : users@maven.apache.org > Objet : apt-get repository > > > I have one question. Does any maven command or plugin support > serach and add dependency automatically (a bit like Debian > apt-get)? For instance, I use archetype to create an ejb > project. Then I want to use jboss as my ejb container. So I > need to add a lot of dependencies. Is there any command or > plugin like 'mvn dependency:search-jboss'/ 'mvn dependency:add-jboss' > enabling mvn to automatically accomplish the dependencies > section? Though those dependencies can be added manually by > editing the pom.xml, it is a bit tedious step and easily to > mistype the wrong characters. Or is there any better way to > accomplish such task? > > Thank you very much, > -- > View this message in context: > http://www.nabble.com/apt-get-repository-tp16348997s177p16348997.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : [deploy-plugin] Abort deploy when a target is present
Great news! I had a quick look on https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/ and did not see any log related to it. So was there already a logged bug about this: http://jira.codehaus.org/browse/MDEPLOY-74 What/where is the "new code", some 3.x or something? So, is there another svn repository for this? In fact, I'd be happy to be able to either use a new released version or help merging back this feature if possible. Cheers Message d'origine De: Brian E. Fox [mailto:[EMAIL PROTECTED] Date: jeu. 27/03/2008 18:45 À: Maven Users List Objet : RE: [deploy-plugin] Abort deploy when a target is present This is the default in the new code, but it wasn't merged back to 2.0.x I believe. -Original Message----- From: MATHUS Baptiste [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 9:32 AM To: Maven Users List Subject: [deploy-plugin] Abort deploy when a target is present Hi all, Recently, some developers did a release manually. So they put a release version in the pom and triggered a deploy. Everything fine but... The thing is: they forgot to re-update the pom.version to a new snapshot version. So, as the code is continuously integrated, at each new commit, the recent release was "automatically" overridden many times with the snapshot code before realizing it :-/. So, what I would like is to be able to put an additional option for maven when run inside the continuous integration server, something like -DdontOverrideRelease, that would make fail the deployment if the released artefact is already present. I've taken a quick look at http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html but it seems it's not currently possible. What do you think? Can a file an feature request about it in the plugin tracker? Thanks a lot. Cheers. -- Baptiste - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [deploy-plugin] Abort deploy when a target is present
Don't worry. I'm totally aware of how the open source community works and wholeheartely support it :). I'll never complain if something isn't done quickly. If I really need something, I'll just try and provide the patch myself. In the meantime, I'll log the improvement request (http://jira.codehaus.org/browse/MDEPLOY-74). Later, I might provide a patch in addition. Moreover, in the current case, I guess this is something I could do as a maven plugin development big beginner :). Cheers. > -Message d'origine- > De : Wayne Fay [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 27 mars 2008 16:48 > À : Maven Users List > Objet : Re: [deploy-plugin] Abort deploy when a target is present > > As soon as you write the code and contribute it, I'm sure it > will be greeted with open arms. ;-) > > Until someone gets really inspired to do this, I just have no > real expectation for when it will happen. Many people are > solving this problem with other solutions (previously > mentioned) so its considered a New Feature or Improvement, > rather than a real bug, so the priority is low. > > So, that's why I suggest finding another way to solve this issue. > > Wayne > > On 3/27/08, MATHUS Baptiste <[EMAIL PROTECTED]> wrote: > > Well: > > * I think you're right: I'll open a thread in the archiva > users ML to see if it's possible. At least it would be a good > idea for improvement. > > * But I also think maven-deploy-plugin would be better if > it had this option. At least it would help debugging. Or some > option like -DdryRun=true to just simulate the distant > artifact, and displaying if one was overridden or not. > > > > Cheers. > > > > > -Message d'origine- > > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De > la part de > > > Jeff MAURY Envoyé : jeudi 27 mars 2008 15:16 À : Maven Users List > > > Objet : Re: [deploy-plugin] Abort deploy when a target is present > > > > > > I think it should be defined at the repository definition level. > > > > > > Jeff MAURY > > > > > > On Thu, Mar 27, 2008 at 2:32 PM, MATHUS Baptiste > <[EMAIL PROTECTED]> > > > wrote: > > > > > > > Hi all, > > > > > > > > Recently, some developers did a release manually. So they put a > > > > release version in the pom and triggered a deploy. > > > Everything fine but... > > > > The thing is: they forgot to re-update the pom.version to a new > > > > snapshot version. > > > > > > > > So, as the code is continuously integrated, at each new commit, > > > > the recent release was "automatically" overridden many > times with > > > > the snapshot code before realizing it :-/. > > > > So, what I would like is to be able to put an additional option > > > > for maven when run inside the continuous integration server, > > > > something like -DdontOverrideRelease, that would make fail the > > > deployment if the > > > > released artefact is already present. > > > > > > > > I've taken a quick look at > > > > > > > > http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html > > > > but it seems it's not currently possible. > > > > What do you think? Can a file an feature request about > it in the > > > > plugin tracker? > > > > > > > > Thanks a lot. > > > > > > > > Cheers. > > > > -- > > > > Baptiste > > > > > > > > > > > > > > > > > -- > > > La mélancolie c'est communiste > > > Tout le monde y a droit de temps en temps La mélancolie n'est pas > > > capitaliste C'est même gratuit pour les perdants La > mélancolie c'est > > > pacifiste On ne lui rentre jamais dedans La mélancolie oh > tu sais ça > > > existe Elle se prend même avec des gants La mélancolie c'est pour > > > les syndicalistes Il faut juste sa carte de permanent > > > > > > Miossec (2006) > > > > > > http://www.jeffmaury.com > > > http://riadiscuss.jeffmaury.com > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Forbid artifact overriding [was:TR: [deploy-plugin] Abort deploy when a target is present]
Hi all, Is it already possible with archiva to forbid that a released artifact be overridden? I checked the archiva interface, and it seems it doesn't, but I prefer re-checking here. I didn't find any feature request about this in the tracker, I guess this should be added, shouldn't I? Thanks a lot. -- Baptiste -Message d'origine- De : Wayne Fay [mailto:[EMAIL PROTECTED] Envoyé : jeudi 27 mars 2008 16:22 À : Maven Users List Objet : Re: [deploy-plugin] Abort deploy when a target is present Others have asked about this previously. I would imagine it is filed in JIRA if you go look for it. The general response is, you can manage the rwx bits on your deployed artifacts to avoid this happening. Off the top of my head, I think a cron job that modifies the ACLs for deployed non-snapshot artifacts that runs once an hour should do it. Or perhaps you could modify the umask for the user that runs the deploys. Or any number of alternatives. Also I would assume the various repo managers are building this functionality into their products (eg, do not allow to overwrite, return fail when attempted). If you're just using a dumb file repo, you're going to have to be responsible for this on your own for now, at least until someone gets inspired to add bits to wagon and other places to support the feature. Wayne On 3/27/08, Jeff MAURY <[EMAIL PROTECTED]> wrote: > I think it should be defined at the repository definition level. > > Jeff MAURY > > On Thu, Mar 27, 2008 at 2:32 PM, MATHUS Baptiste <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > Recently, some developers did a release manually. So they put a > > release version in the pom and triggered a deploy. Everything fine but... > > The thing is: they forgot to re-update the pom.version to a new > > snapshot version. > > > > So, as the code is continuously integrated, at each new commit, the > > recent release was "automatically" overridden many times with the > > snapshot code before realizing it :-/. > > So, what I would like is to be able to put an additional option for > > maven when run inside the continuous integration server, something > > like -DdontOverrideRelease, that would make fail the deployment if > > the released artefact is already present. > > > > I've taken a quick look at > > http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html > > but it seems it's not currently possible. > > What do you think? Can a file an feature request about it in the > > plugin tracker? > > > > Thanks a lot. > > > > Cheers. > > -- > > Baptiste > > > > > > > -- > La mélancolie c'est communiste > Tout le monde y a droit de temps en temps La mélancolie n'est pas > capitaliste C'est même gratuit pour les perdants La mélancolie c'est > pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça > existe Elle se prend même avec des gants La mélancolie c'est pour les > syndicalistes Il faut juste sa carte de permanent > > Miossec (2006) > > http://www.jeffmaury.com > http://riadiscuss.jeffmaury.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [deploy-plugin] Abort deploy when a target is present
Well: * I think you're right: I'll open a thread in the archiva users ML to see if it's possible. At least it would be a good idea for improvement. * But I also think maven-deploy-plugin would be better if it had this option. At least it would help debugging. Or some option like -DdryRun=true to just simulate the distant artifact, and displaying if one was overridden or not. Cheers. > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la > part de Jeff MAURY > Envoyé : jeudi 27 mars 2008 15:16 > À : Maven Users List > Objet : Re: [deploy-plugin] Abort deploy when a target is present > > I think it should be defined at the repository definition level. > > Jeff MAURY > > On Thu, Mar 27, 2008 at 2:32 PM, MATHUS Baptiste > <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > Recently, some developers did a release manually. So they put a > > release version in the pom and triggered a deploy. > Everything fine but... > > The thing is: they forgot to re-update the pom.version to a new > > snapshot version. > > > > So, as the code is continuously integrated, at each new commit, the > > recent release was "automatically" overridden many times with the > > snapshot code before realizing it :-/. > > So, what I would like is to be able to put an additional option for > > maven when run inside the continuous integration server, something > > like -DdontOverrideRelease, that would make fail the > deployment if the > > released artefact is already present. > > > > I've taken a quick look at > > > http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html > > but it seems it's not currently possible. > > What do you think? Can a file an feature request about it in the > > plugin tracker? > > > > Thanks a lot. > > > > Cheers. > > -- > > Baptiste > > > > > > > -- > La mélancolie c'est communiste > Tout le monde y a droit de temps en temps La mélancolie n'est > pas capitaliste C'est même gratuit pour les perdants La > mélancolie c'est pacifiste On ne lui rentre jamais dedans La > mélancolie oh tu sais ça existe Elle se prend même avec des > gants La mélancolie c'est pour les syndicalistes Il faut > juste sa carte de permanent > > Miossec (2006) > > http://www.jeffmaury.com > http://riadiscuss.jeffmaury.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[deploy-plugin] Abort deploy when a target is present
Hi all, Recently, some developers did a release manually. So they put a release version in the pom and triggered a deploy. Everything fine but... The thing is: they forgot to re-update the pom.version to a new snapshot version. So, as the code is continuously integrated, at each new commit, the recent release was "automatically" overridden many times with the snapshot code before realizing it :-/. So, what I would like is to be able to put an additional option for maven when run inside the continuous integration server, something like -DdontOverrideRelease, that would make fail the deployment if the released artefact is already present. I've taken a quick look at http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html but it seems it's not currently possible. What do you think? Can a file an feature request about it in the plugin tracker? Thanks a lot. Cheers. -- Baptiste
RE: maven plugin question
I guess not. And this might be one of the reason there's currently an open bug/improvement request about being able to use concurrently the local repository: http://jira.codehaus.org/browse/MNG-2802 Maybe there's in fact a big need for an abstract io/filesystem access library in maven to achieve that. Please note I'm not a maven developer and I might be totally wrong. My 2 cents. Cheers. > -Message d'origine- > De : Guillaume Boucherie [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 26 mars 2008 13:41 > À : Maven Users List > Objet : maven plugin question > > Hi all, > > I'm trying to make a custom plugin and I have a question > about maven API. > In my plugin I want to have two goal. First will run some > thing via ssh and second must stop them. > Is there a way in maven API to store (share, cache ?) custom > object between two different goals ? > Thanks > > Guillaume B. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : How change goal PACKAGE
I'm sorry I don't understand the question. If you want to skip compile when running site, I guess this would be difficulty possible, since there're generally lots of things in the site need the compiled code (running tests on it is just one of them, then you may have code quality, like PMD, checkstyle, findbugs, code coverage, and so on). Cheers. Message d'origine De: cody zhang [mailto:[EMAIL PROTECTED] Date: jeu. 20/03/2008 02:46 À: Maven Users List Objet : Re: How change goal PACKAGE Dear Mathus, your mind that it will skip test when run package? which commond skip compile when run site? 2008/3/19, MATHUS Baptiste <[EMAIL PROTECTED]>: > mvn -DskipTests package > > Cheers. > > > -Message d'origine- > > De : author [mailto:[EMAIL PROTECTED] > > Envoyé : mercredi 19 mars 2008 16:44 > > À : users@maven.apache.org > > Objet : How change goal PACKAGE > > > > > > > When i use package goal it is build fail. > > Problem whith test, test fails when test goal runnig. I dont > > want fix in test problem. How can i use this goal whithout goal test? > > -- > > View this message in context: > > http://www.nabble.com/How-change-goal-PACKAGE-tp16145136s177p1 > > 6145136.html > > Sent from the Maven - Users mailing list archive at Nabble.com. > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How change goal PACKAGE
mvn -DskipTests package Cheers. > -Message d'origine- > De : author [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 19 mars 2008 16:44 > À : users@maven.apache.org > Objet : How change goal PACKAGE > > > When i use package goal it is build fail. > Problem whith test, test fails when test goal runnig. I dont > want fix in test problem. How can i use this goal whithout goal test? > -- > View this message in context: > http://www.nabble.com/How-change-goal-PACKAGE-tp16145136s177p1 > 6145136.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Convert SNAPSHOT timestamps from utc to local time
> -Message d'origine-
> De : David Delbecq [mailto:[EMAIL PROTECTED]
> Envoyé : mercredi 19 mars 2008 08:36
> À : Maven Users List
> Objet : Re: Convert SNAPSHOT timestamps from utc to local time
>
> Just a stupid suggestion:
>
> Wouldn't it be much easier to either
>
> 1) Setup the local clock on snapshots generating server to
> french time and have that server says that is "utc" time?
> That's a quick and dirty, but it's not like you would have to change
I'm not admin on this server and it is used by lots of other people. So
changing server time isn't an option :).
>
> or
>
> 3) Have people look, when they explore snapshot repository
> using their web browser, at the "time" column that appear
> next to file list, which is expressed in server local time afaik.
There's no column for this. However, it might be a feature request for Archiva,
granted.
>
> or even better
>
> 2) Take 10 minute to teach your team members what UTC mean
> (substract one hour from local time in winter, 2 hours in
> summer)? It's not like it is difficult calculation to know utc time.
Agreed, though there's a lot of things that are not complex.
But as I said, nobody here ever use UTC (and there's very little chance we are
going to ever need it).
This would obviously be possible to teach our developer what UTC is, and how to
shift the time by themselves.
But I really think this would be useless inside our company.
About the patch, I already got there. The last thing I'm unable to find is how
to configure plexus to inject some system property.
My code already works using the boolean given by
Boolean.parseBoolean(System.getProperty("useLocalTime")), apart from this the
code is very very simple (maybe 5 or 10 lines of modified code maximum).
Btw, do you know what I should do so that plexus would inject the value given
in -DuseLocalTime in the SnapshotTransformation class below:
org.apache.maven.artifact.transform.ArtifactTransformation
snapshot
org.apache.maven.artifact.transform.SnapshotTransformation
org.apache.maven.artifact.manager.WagonManager
org.apache.maven.artifact.repository.metadata.RepositoryMetadataManager
I tried adding a ... block, but I guess I'm
missing something and I have been unable to find the right documentation inside
the plexus doc.
Cheers.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Plugin or not plugin : maven-artifact-manager
Hi all, (I hesitated on posting this on the developer list) So, I tried hacking the SnapshotTransformation class to be able to configure the use of the local time instead of UTC if wanted. After some times trying to install the jar (mvn install) and test it with a mvn deploy on some other project, without any changes. I finally realized the class that was used was the one in the jar in $M2_HOME/lib. So, for my knowlegde: actually code the one from the maven-artifact-manager project are no use from the local repository, right? Is it the very same code, just packaged differently? Thanks a lot. Cheers.
RE: Convert SNAPSHOT timestamps from utc to local time
My company is french, we sell to frenchies and have almost no chance to ever sell to another country ;). In fact, we work in the healthcare area and there's lots and lots of administrative rules that even make it difficult to follow only for the french market :-). So, I'll hack the code and propose a patch with some additional parameter to tune this behaviour, hoping it finds a way into the trunk one day. Cheers. -Message d'origine- De : Wayne Fay [mailto:[EMAIL PROTECTED] Envoyé : mardi 18 mars 2008 16:32 À : Maven Users List Objet : Re: Convert SNAPSHOT timestamps from utc to local time Not that I'm aware of, at least, not today. If you really must have this feature, you could add a configuration and hack the code, but as with any user-provided patch, there's no guarantee it would be accepted into the core if you contributed it via Jira. Maven uses UTC on purpose so that timestamps are gloabally unique and incrementing. Then when I'm working in CA and the rest of my team is in NJ, and we're both deploying to the same corporate repo, my 11am (PT) builds are properly considered newer than your 1pm (ET) builds. If you're all in the same timezone, this seems like less of a problem, but how common is that in today's corporate climate? I know my small team of 5 people is in 3 timezones. Wayne On 3/18/08, MATHUS Baptiste <[EMAIL PROTECTED]> wrote: > Hi all, > > We're having a small problem with deployment: UTC is being used for > replacing SNAPSHOT with timestamp. > For us, UTC is one hour behind local time. In some days, it will be 2 > hours. > > It's a bit annoying because people are sometimes wondering which > snapshot is corresponding to their commit. > We'd prefer being able to deploy using local time (at the moment, for > example utc is something like 11h47, and our local time is 12h47). > > I looked at the code and found that the code is in the > org.apache.maven.artifact.transform.SnapshotTransformation class. > Is there a way to define some global variable (used by the timezone or > something like that) to shift generated timestamps? > > Thanks in advance. > Cheers. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANN] Maven Eclipse Plugin 2.5 Released
+1. Same problem here. Just saw the behaviour some minutes ago.
Precision: I'm not using the default repository location, this might a cause of
this problem.
Do you want someone to log a bug in the tracker, Arnaud?
Cheers.
-Message d'origine-
De : Hoover, William [mailto:[EMAIL PROTECTED]
Envoyé : mardi 18 mars 2008 13:11
À : Maven Users List
Cc : Maven Developers List
Objet : RE: [ANN] Maven Eclipse Plugin 2.5 Released
Using "mvn eclipse:clean eclipse:eclipse" with version 2.5. For example, if
M2_REPO = /path/to/repo executing the command renders build paths for
dependencies for project as
M2_REPO/path/to/repo/commons-collections/commons-collections/3.2/commons-collections-3.2.jar
If I use version 2.4 M2_REPO is referenced properly (i.e.
M2_REPO/commons-collections/commons-collections/3.2/commons-collections-3.2.jar):
org.apache.maven.plugins
maven-eclipse-plugin
2.4
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Arnaud HERITIER
Sent: Tuesday, March 18, 2008 6:33 AM
To: [EMAIL PROTECTED]; Maven Users List
Cc: Maven Developers List
Subject: [ANN] Maven Eclipse Plugin 2.5 Released
The Maven team is pleased to announce the release of the Maven Eclipse Plugin,
version 2.5
This plugin is used to generate Eclipse IDE files (*.classpath, *.wtpmodules
and the .settings folder) for use with a project.
http://maven.apache.org/plugins/maven-eclipse-plugin/
You can run mvn -up to get the latest version of the plugin, or specify the
version in your project's plugin configuration:
org.apache.maven.plugins
maven-eclipse-plugin
2.5
In this release we added the support for myeclipse, WTP 2.0 and the possibility
to connect your projects with existing ones in your workspace.
We also improved the support for rad 6 & 7 and fixed many bugs.
Thanks a lot for those who helped us by providing patches and/or by testing our
snapshots.
Release Notes - Maven 2.x Eclipse Plugin - Version 2.5
** Bug
* [MECLIPSE-56] - Generated .project-file misses encoding declaration
* [MECLIPSE-102] - sar projects conflict with maven-eclipse-plugin
* [MECLIPSE-107] - Dependency Version Incorrectly Taken from
DependencyManagement
* [MECLIPSE-160] - Wrong description with the goal "add-maven-repo"
documentation
* [MECLIPSE-172] - Don't add Default ClasspathContainer if a alternate JRE
or a "Execution Environment" is configured as ClasspathContainer.
* [MECLIPSE-291] - tests fail with spaces in the path name
* [MECLIPSE-296] - Wrong generated source-path when warSourceDirectory is
set
* [MECLIPSE-297] - eclipse:clean deletes files from pom projects
* [MECLIPSE-301] - eclipse:clean doesn't respect packaging 'pom'
* [MECLIPSE-305] - souce-path is absolute versus relative with WAR
* [MECLIPSE-309] - warSourceDirectory incorrectly resolved inside a reactor
(with a relative path)
* [MECLIPSE-315] - RadWebSettingsWriter uses hardcoded webcontent path and
ignores warSourceDirectory
* [MECLIPSE-316] - RadCleanMojo does not clean .war files
* [MECLIPSE-323] - eclipse:clean does NOT delete 'additionalConfig' files
* [MECLIPSE-332] - mvn-eclipse-cache.properties is never filled
* [MECLIPSE-342] - Found an equals call to check unrelated types
* [MECLIPSE-346] - Transitive dependencies aren't used to resolve
JEE/JSP/EJB/Servlet versions
* [MECLIPSE-352] - RAD application.xml is not generated with good parameters
* [MECLIPSE-356] - RadLibCopier does not respect warSourceDirectory setting
of maven-war-plugin when copying dependencies
* [MECLIPSE-357] - RadManifestWriter uses hardcoded web application source
directory
* [MECLIPSE-358] - plugin installed via eclipse:install-plugins have the
wrong name
* [MECLIPSE-366] - Test file(s) for Multi-project sample is missing
* [MECLIPSE-367] - Dependency to artifact with classifier tests not
distinguished from the regular artifact
* [MECLIPSE-369] - source status cache not maintained.
* [MECLIPSE-374] - Rename the expression ${eclipse.workspace} to
${eclipse.projectDir} for the parameter eclipseProjectDir in the goal
eclipse:eclipse
* [MECLIPSE-378] - Projects with customized warSourceDirectory still
creates empty directories of the default path
* [MECLIPSE-379] - When downloading sources and javadocs dependency
classifier is not respected.
* [MECLIPSE-390] - myeclipse goal ignores additionalConfig
* [MECLIPSE-399] - URL for javadoc attachments on Unix is invalid
** Improvement
* [MECLIPSE-32] - Allow for forcing the creation of direct project
references for dependencies
* [MECLIPSE-79] - exclude dependencies from the Classpath Container
* [MECLIPSE-120] - Force inter-project dependencies
* [MECLIPSE-152] - W
Convert SNAPSHOT timestamps from utc to local time
Hi all, We're having a small problem with deployment: UTC is being used for replacing SNAPSHOT with timestamp. For us, UTC is one hour behind local time. In some days, it will be 2 hours. It's a bit annoying because people are sometimes wondering which snapshot is corresponding to their commit. We'd prefer being able to deploy using local time (at the moment, for example utc is something like 11h47, and our local time is 12h47). I looked at the code and found that the code is in the org.apache.maven.artifact.transform.SnapshotTransformation class. Is there a way to define some global variable (used by the timezone or something like that) to shift generated timestamps? Thanks in advance. Cheers.
RE: [maven-release-plugin] Unable to update SNAPSHOT project dependency
Well, after thinking about it. I quite agree with the fact you shouldn't continue working on a 2.1.0-SNAPSHOT when you're initializing a path to a final version (including classical released versions like alpha, beta, cr/rc, ga/final). The thing is: actually in our case, we'd like to just publish some kind of snapshot version, but not "SNAPSHOT" in the maven sense. Something between snapshot and alpha. We wanted to call it m1. In fact, at the moment, we can't go through a proper release path. So people are using our SNAPSHOT version. What we would like would be introducing some sort of "sticky" snapshot so that we could better handle those often changing dependencies. At least, I think that tools should never forbid you to do something. There's some case where you have to. I think that maven-release-plugin should just display something like : "urgh, you're doing something that looks like stupid to me.It's quite uncommon to release a version, then continue working on it. Are you really sure you want to put this version? (yes/no) [no]" There's known case like Linux apt-get. Try removing libc6, or apt-get itself. Generally it will ask something like "type 'yes, I am sure, do as I say' if you want to proceed anyway". IMO, this should be the way to go for maven-release-plugin. I guess I will file an improvement in the tracker about it, but I'd be interested in kwowing the maven-release-plugin's developer(s) opinion. Cheers. -Message d'origine- De : Nicole Lacoste Envoyé : jeudi 13 mars 2008 16:41 À : Maven Users List Objet : Re: [maven-release-plugin] Unable to update SNAPSHOT project dependency Hi, What you are trying to do sounds like a very bad idea. It is better to increase the snapshot version. The common practice is that the version of a snapshop x.y.z-SNAPSHOT will be released to x.y.z. Your approach seems to suggest that you will release a new different 2.1.0? Hopefully maven won't let you do that! If it did then the release of B depending on the 2.1.0 version of A is corrupted. I am actually surprised that you were able to leave the snapshot version of A as it was - if there is a bug to be filed it is that! Why not use the version numbers differently, either add one more digit, ie 2.1.0.1 and consider the 'final' versions only those that have 3 digits. At some point you'll have 2.1.0.x-SNAPSHOT and you release this to 2.1.1 (a final version), making the next snapshot 2.1.1.0-SNAPSHOT or stay as you are, up the final digit, and consider only 2 digit releases to be final. Think about it, any release version is final, that's what released means. Nicole On 13/03/2008, MATHUS Baptiste <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm using maven-release-plugin 2.0-beta-7 to release some artefact. > It worked very very fine for a project that didn't have any SNAPSHOT > dependency. > > We have to projects A et B that are 2.1.0-SNAPSHOT. > B depends on A. > > I just released A-2.1.0-m1 with maven-release-plugin. As this is not a final > version yet, the "next development version" has been left to 2.1.0-SNAPSHOT. > > Then I tried to do the same with B. As expected, it asked me to update the > dependency against A-2.1.0-SNAPSHOT. > I want to release a B-2.1.0-m1 that would depends on the A-2.1.0-m1 I just > released, but the plugin won't let me say my "next dev version" is > 2.1.0-SNAPSHOT for B too. > > I think this is the problem: it seems like the scenario doesn't allow > putting a "next development version" that equals the current. > However it seems like it's totally common use case when releasing an alpha, > before a beta and so on. > > However, it worked fine with A project without dependency, why not for B? > > It seems like there's something the plugin doesn't accept, but it doesn't > say anything but asking me again about that version number... > > Here's the output : > C:\projet\MIPIH\workspace\Socle Fonctionnel>mvn release:prepare > -Dresume=false [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'release'. > [INFO] Ignoring available plugin update: 2.4 as it requires Maven > version 2.0.8 [INFO] > -- > -- > [INFO] Building Socle Fonctionnel > [INFO]task-segment: [release:prepare] (aggregator-style) > [INFO] > -- > -- > [INFO] [release:prepare] > [INFO] Verifying that there are no local modifications... > [INFO] Executing: svn --non-interactive status [INFO] Working > directory: C:\p
[maven-release-plugin] Unable to update SNAPSHOT project dependency
Hi all, I'm using maven-release-plugin 2.0-beta-7 to release some artefact. It worked very very fine for a project that didn't have any SNAPSHOT dependency. We have to projects A et B that are 2.1.0-SNAPSHOT. B depends on A. I just released A-2.1.0-m1 with maven-release-plugin. As this is not a final version yet, the "next development version" has been left to 2.1.0-SNAPSHOT. Then I tried to do the same with B. As expected, it asked me to update the dependency against A-2.1.0-SNAPSHOT. I want to release a B-2.1.0-m1 that would depends on the A-2.1.0-m1 I just released, but the plugin won't let me say my "next dev version" is 2.1.0-SNAPSHOT for B too. I think this is the problem: it seems like the scenario doesn't allow putting a "next development version" that equals the current. However it seems like it's totally common use case when releasing an alpha, before a beta and so on. However, it worked fine with A project without dependency, why not for B? It seems like there's something the plugin doesn't accept, but it doesn't say anything but asking me again about that version number... Here's the output : C:\projet\MIPIH\workspace\Socle Fonctionnel>mvn release:prepare -Dresume=false [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'release'. [INFO] Ignoring available plugin update: 2.4 as it requires Maven version 2.0.8 [INFO] [INFO] Building Socle Fonctionnel [INFO]task-segment: [release:prepare] (aggregator-style) [INFO] [INFO] [release:prepare] [INFO] Verifying that there are no local modifications... [INFO] Executing: svn --non-interactive status [INFO] Working directory: C:\projet\MIPIH\workspace\Socle Fonctionnel [INFO] Checking dependencies and plugins for snapshots ... There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no: : yes Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : Resolve Project Dependency Snapshots.: 'mipih:socle-technique' set to release? (yes/no) yes: : What is the next development version? (2.1.1-SNAPSHOT) 2.1.1-SNAPSHOT: : 2.1.0-SNAPSHOT What is the next development version? (2.1.1-SNAPSHOT) 2.1.1-SNAPSHOT: : 2.1.0-SNAPSHOT What is the next development version? (2.1.1-SNAPSHOT) 2.1.1-SNAPSHOT: : 2.1.0-SNAPSHOT What is the next development version? (2.1.1-SNAPSHOT) 2.1.1-SNAPSHOT: : 2.1.0-SNAPSHOT ... And so on. I tried ten times or so to see if I reach a threshold, but this really seems to loop. Is this a bug or some misuse of mine? Please let me know if I should file an issue. Cheers.
Monitor bad artifact hashes
Hi all, After having some problems with corrupted jars, we recently decided to purge all our proxied repository. Before doing that, I switched from "fix" to "fail". The thing is: as an archiva admin I'd be interested to be noticed about those artifacts that won't be downloaded. In fact, since we purged we noticed some bad artifacts (like the maven pom 2.0.6.) but for some it took some time to understand where the problem comes from. So, summing up: what I would like is being able to configure archiva to send an email to some configured address when it encounters an artifact that won't be downloaded because of a bad hash file. Has archiva already such feature? Alternatively, archiva could also propose a page where it would present the list of those problematic artifacts? If nothing of this kind exist in archiva at the moment, could I log an improvement proposition in the tracker about this? Thanks a lot. Cheers.
RE: heap size for unit tests
Have a look at the block of the surefire plugin :
http://maven.apache.org/plugins/maven-surefire-plugin/examples/system-properties.html
to add the -Xmx option.
I think this is not a that you have to use. I seem to
remember there's an tag like .
I also found this: ${maven.surefire.debug} here
http://jira.codehaus.org/browse/MEVENIDE-435. Might work.
Cheers.
-Message d'origine-
De : Ritz, Martin [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 6 mars 2008 12:47
À : users@maven.apache.org
Objet : heap size for unit tests
Hello,
is it possible to increase the heap size for maven especially for the unit
tests?
---
regards
Martin Ritz
> BTC AG - Unit Softwaredevelopment
>
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with pages encoding
The default one. I guess this is derby? Ok, I'll file an issue. I'm having some small other issues, I think I'll file some. Cheers. -Message d'origine- De : Emmanuel Venisse [mailto:[EMAIL PROTECTED] Envoyé : mercredi 5 mars 2008 16:28 À : [EMAIL PROTECTED] Objet : Re: Problem with pages encoding File an issue and the french team will look at it. What is your db? On Wed, Mar 5, 2008 at 2:25 PM, MATHUS Baptiste <[EMAIL PROTECTED]> wrote: > Hi all, > > I am configuring continuum-1.1, and there seems to be a problem with > encoding. > I guess this might be because no french people use continuum (or those > frenchies only have qwerty keyboards? :o)). Just joking. > > In fact, I created the admin account. In the admin name, I typed > "Systèmes et Méthodes" (name of our team). > In the top left, this then displays "Systes et Mhodes"... > > Which charset/encoding does use continuum to persist data ? > > At least, IMO, there seems to be a lack of encoding information in the > sent "html" pages. In the html header, shouldn't there be a meta like > ? > When I look inside the page informations, my firefox says it actually > interpreted the page as ISO-8859-1. > > Let me know what you think and/or if I should file an issue. > > Cheers and thanks again for this great product! > > -- Baptiste >
Admin account locked
Hi, It seems I f#^$d up something with my archiva instance. I wasn't able to remember my admin password, so I asked for a reset. I reset the account three or four times. Now, I'm locked, each time I try to log in, I've got the http://mvnrepo:4000/archiva/index.action?infoMessage=Account+Locked url. What can I do ? Even server-side operation to unlock me would help :-). Thanks a lot. Cheers PS : Here's the full server stack I got : 2008-02-06 19:17:59,723 [SocketListener0-1] WARN org.codehaus.plexus.redback.authentication.Authenticator:user-manager - Password is Invalid for user admin. 2008-02-06 19:17:59,774 [SocketListener0-1] WARN com.opensymphony.xwork.util.OgnlUtil - Caught OgnlException while setting property 'infoMessage' on type 'com.opensymphony.webwork.dispatcher.ServletActionRedirectResult'. ognl.NoSuchPropertyException: com.opensymphony.webwork.dispatcher.ServletActionRedirectResult.infoMessage at ognl.ObjectPropertyAccessor.setProperty(ObjectPropertyAccessor.java:132) at com.opensymphony.xwork.util.OgnlValueStack$ObjectAccessor.setProperty(OgnlValueStack.java:67) at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:1656) at ognl.ASTProperty.setValueBody(ASTProperty.java:101) at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:177) at ognl.SimpleNode.setValue(SimpleNode.java:246) at ognl.Ognl.setValue(Ognl.java:476) at com.opensymphony.xwork.util.OgnlUtil.setValue(OgnlUtil.java:188) at com.opensymphony.xwork.util.OgnlUtil.internalSetProperty(OgnlUtil.java:362) at com.opensymphony.xwork.util.OgnlUtil.setProperties(OgnlUtil.java:78) at com.opensymphony.xwork.util.OgnlUtil.setProperties(OgnlUtil.java:51) at com.opensymphony.xwork.ObjectFactory.buildResult(ObjectFactory.java:186) at org.codehaus.plexus.xwork.PlexusObjectFactory.buildResult(PlexusObjectFactory.java:166) at com.opensymphony.xwork.DefaultActionInvocation.createResult(DefaultActionInvocation.java:173) at com.opensymphony.xwork.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:310) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:208) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.apache.maven.archiva.web.interceptor.ConfigurationInterceptor.intercept(ConfigurationInterceptor.java:53) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:100) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:178) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.ParameterFilterInterceptor.intercept(ParameterFilterInterceptor.java:124) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.o
RE: Checkstyle Problem
Hi, If you need something urgently as you say, better would be to try to answer questions asked by those who try to help you :-). *What goal did you configure inside Continuum for your project ?* To generate the reports, you have to use "mvn site" at least. If not, the site, and so the integrated reports won't be generated. Cheers. -Message d'origine- De : Mitesh51 [mailto:[EMAIL PROTECTED] Envoyé : jeudi 31 janvier 2008 11:40 À : [EMAIL PROTECTED] Objet : RE: Checkstyle Problem What i want to do is generate a checkstyle report. I can do thais via mvn checkstyle:checkstyle from command prompt but i am not able to generate that report when i use the continumm to run the Maven project. If u have yahoo id then can u give me? Please I need the solution very urgently. nicklist wrote: > > What goals or phase are you running from Continuum? The reporting > section is only used when generating a site (thus, running mvn site) > and not when running an install or deploy. > > Hth, > > Nick Stolwijk > > ps. I don't think you need the checkstyle artifact as dependency. This > way it will be included in your project. > > > -Original Message- > From: Mitesh51 [mailto:[EMAIL PROTECTED] > Sent: Thu 1/31/2008 11:07 AM > To: [EMAIL PROTECTED] > Subject: Checkstyle Problem > > > I want to use checkstyle plugin and use it in continuum. > > My pom.xml looks like . > > 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";> > 4.0.0 > com.mycompany.app > my-app > jar > 1.0-SNAPSHOT > my-app > http://maven.apache.org > > > > scm:svn:svn://shikhas:[EMAIL > PROTECTED]/iLabsDevRepo/Source/trunk/iTraining/trunk/maven/my-app/ > > > > > > checkstyle > checkstyle > 4.1 > jar > package > true > > > > > > > > > org.apache.maven.plugins > > maven-checkstyle-plugin > > D:\ILabs > Task\Maven\checkstyle-4.4\sun_checks.xml > > > > > > > > It is downloading the jars necessary for the checkstyle but it is not > generating the checkstyle documents. > > Is there anything missing in pom.xml? > > After running the build script in continuum, It does not generate the > checkstyle reports in the Output directory with the use of continuum. > > Any Suggestions?? > -- > View this message in context: > http://www.nabble.com/Checkstyle-Problem-tp15201303p15201303.html > Sent from the Continuum - Users mailing list archive at Nabble.com. > > > > -- View this message in context: http://www.nabble.com/Checkstyle-Problem-tp15201303p15201976.html Sent from the Continuum - Users mailing list archive at Nabble.com.
[1.0.3] Add -Xmx to jvm parameters
Hi all, I found this bug report : http://jira.codehaus.org/browse/CONTINUUM-44, but I'm using continuum 1.0.3. I'd like to add something like -Xmx1024m to jvm launched by maven launched by continuum :-). I don't care if I must put this option for every registered projects. So if there's a solution redefinining this option globally, that will fit my needs. What could be the best option ? Thanks a lot. Cheers. -- Baptiste
Project change detection
Hi all, Two mails in a day :-). We just committed some code in one of our project. I was looking at the logs and saw something bizarre : As an example, those lines show a project that has not changed. Not building it is normal : 2007-11-30 17:20:03,193 [Thread-3] INFO ContinuumScm - Updating project: id: '29', name 'FormationJ2EE - Services'. 2007-11-30 17:20:03,197 [Thread-3] INFO ScmManager - Executing: svn --non-interactive update 2007-11-30 17:20:03,197 [Thread-3] INFO ScmManager - Working directory: /cic/soft/integration/continuum-1.0.3/apps/continuum/working-directory/29 2007-11-30 17:20:08,093 [Thread-336] DEBUG ScmManager - At revision 3215. 2007-11-30 17:20:09,128 [Thread-3] INFO BuildController - The project was not built because there are no changes. Then, as it is using the same schedule, it checks another project. You can see it updates the code (using svn), but doesn't detect any change although you can see there are changes?! : 2007-11-30 17:20:09,184 [Thread-3] INFO ContinuumScm - Updating project: id: '26', name 'Socle fonctionnel MIPIH'. 2007-11-30 17:20:09,188 [Thread-3] INFO ScmManager - Executing: svn --non-interactive update 2007-11-30 17:20:09,188 [Thread-3] INFO ScmManager - Working directory: /cic/soft/integration/continuum-1.0.3/apps/continuum/working-directory/26 2007-11-30 17:20:09,714 [Thread-338] DEBUG ScmManager - Asrc/test/config 2007-11-30 17:20:09,714 [Thread-338] DEBUG ScmManager - Skipping non-file: src/test/config 2007-11-30 17:20:09,863 [Thread-338] DEBUG ScmManager - Asrc/test/config/soclefonctionnel 2007-11-30 17:20:09,864 [Thread-338] DEBUG ScmManager - Skipping non-file: src/test/config/soclefonctionnel 2007-11-30 17:20:09,893 [Thread-338] DEBUG ScmManager - Asrc/test/config/soclefonctionnel/test.properties 2007-11-30 17:20:09,893 [Thread-338] DEBUG ScmManager - Skipping non-file: src/test/config/soclefonctionnel/test.properties 2007-11-30 17:20:09,917 [Thread-338] DEBUG ScmManager - Asrc/test/config/soclefonctionnel/testApplicationConfiguration.xml 2007-11-30 17:20:09,917 [Thread-338] DEBUG ScmManager - Skipping non-file: src/test/config/soclefonctionnel/testApplicationConfiguration.xml 2007-11-30 17:20:10,414 [Thread-338] DEBUG ScmManager - Asrc/java/fr/mcmipih 2007-11-30 17:20:10,415 [Thread-338] DEBUG ScmManager - Skipping non-file: src/java/fr/mcmipih 2007-11-30 17:20:10,588 [Thread-338] DEBUG ScmManager - Asrc/java/fr/mipih/foundation/security/impl/NoAuthenticationManager.java 2007-11-30 17:20:10,588 [Thread-338] DEBUG ScmManager - Skipping non-file: src/java/fr/mipih/foundation/security/impl/NoAuthenticationManager.java 2007-11-30 17:20:11,660 [Thread-338] DEBUG ScmManager - Updated to revision 3215. 2007-11-30 17:20:12,123 [Thread-3] INFO BuildController - The project was not built because there are no changes. Is it normal? If it is not, could you give me some hints about how change detection works so I could try and debug it? Sometimes, changes are detected, sometimes not like above, I'd like to understand why :-). Thanks a lot. Cheers. -- Baptiste
RE: Automatic Build/polling repository not working
As I'm under Aix, I don't start continuum using the wrapper, but directly through the plexus.sh and so I manage the log redirection by myself. >From what I remember, you can start continuum in "console" mode to send the >logs to the screen. But I guess the logs should go into $CONTINUUM_HOME/logs, isn't it? Cheers. -Message d'origine- De : Steve Povilaitis [mailto:[EMAIL PROTECTED] Envoyé : vendredi 30 novembre 2007 16:54 À : [EMAIL PROTECTED] Objet : Automatic Build/polling repository not working Most exalted ones, I'm running continuum 1.1-beta-4 standalone on Windows XP Server. I have set up my project to poll my subversion repository every 5 minutes and do a checkout if any code has changed. I can run the build manually just fine by clicking the green arrow, but the automatic polling of svn doesn't aopear to be working. I have installed continuum as a windows service using the instructions provided on the continuum website, and it appears to be running. the cron expression I'm using is "0 0/5 * * * ? What logs should I check and where are they located? thanks in advance!
RE: Why "Same state, not sending message"
Hi, OK, it works. Although I found the file in $CONTINUUM_HOME/apps/continuum/conf/application.xml instead. Maybe that was something that changed between continuum 1.03 and continuum 1.1. Thanks. -Message d'origine- De : Emmanuel Venisse [mailto:[EMAIL PROTECTED] Envoyé : vendredi 30 novembre 2007 11:41 À : [EMAIL PROTECTED] Objet : Re: Why "Same state, not sending message" You can configure "alwaysSend to true in WEB-INF/classes/META-INF/plexus/application.xml in the mail notifier component descriptor. By default, we don't send notifications if the state doesn't change to not spam users. Emmanuel MATHUS Baptiste a écrit : > Hi all, > > I've taken a look on the website, but I can't find where this rule is > explained or defined. > > Here's the log I have on some projects that've been modified : > 2007-11-30 11:12:40,944 [Thread-2] DEBUG Notifier:mail - > Current build state: 2, previous build state: 2 > 2007-11-30 11:12:40,944 [Thread-2] INFO Notifier:mail - > Same state, not sending message. > > I configured my pom this way : > > continuum > http://mvnrepo.mipih.fr:8080/continuum > > > mail > true > true > true > true > > [EMAIL PROTECTED] > > > > > > I don't want continuum to send mails only when build state has changed (btw, > I suppose build state "2" is Success. Maybe the logs would be clearer saying > "success" instead of "2", isn't it ? > > In fact, we're currently just starting our continuous integration, so maybe > this'll change in the future, but for now we want every builds to send a > message, even if there were two successive successful builds for example (or > two failures). > > Can we configure this ? Is yes, where ? (we're currently using continuum > 1.0.3). > > Thanks a lot. > > Cheers. > -- Baptiste >
Why "Same state, not sending message"
Hi all, I've taken a look on the website, but I can't find where this rule is explained or defined. Here's the log I have on some projects that've been modified : 2007-11-30 11:12:40,944 [Thread-2] DEBUG Notifier:mail - Current build state: 2, previous build state: 2 2007-11-30 11:12:40,944 [Thread-2] INFO Notifier:mail - Same state, not sending message. I configured my pom this way : continuum http://mvnrepo.mipih.fr:8080/continuum mail true true true true [EMAIL PROTECTED] I don't want continuum to send mails only when build state has changed (btw, I suppose build state "2" is Success. Maybe the logs would be clearer saying "success" instead of "2", isn't it ? In fact, we're currently just starting our continuous integration, so maybe this'll change in the future, but for now we want every builds to send a message, even if there were two successive successful builds for example (or two failures). Can we configure this ? Is yes, where ? (we're currently using continuum 1.0.3). Thanks a lot. Cheers. -- Baptiste
RE: Run Archiva on Aix
Hi, For the record, yesterday I found the solution using the IBM JDK. It ends up being kind of a "Security exception". In fact, it was because the IBM JDK is configured by default to the most restrictive cryptographic environment when using the JCE (Java Cryptography Extension) jar. I had to download and install the less restrictive policies as described on this page : http://www-128.ibm.com/developerworks/java/jdk/security/50/ that were here : https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=jcesdk. After having overwritten the files inside the /usr/java5/jre/lib/security/ as described above, it worked. Cheers. -- Baptiste -Message d'origine- De : Maria Odea Ching [mailto:[EMAIL PROTECTED] Envoyé : mercredi 14 novembre 2007 08:22 À : [EMAIL PROTECTED] Objet : Re: Run Archiva on Aix Hi Baptiste, Can you try using the Sun JDK/JRE instead of the IBM JDK/JRE and see if the problem still persists? -Deng MATHUS Baptiste wrote: > OK. I directly launched the plexus.sh script in the bin directory and archiva > started fine. > The thing is, I'm now having problem with the class javax.crypto.b that > triggers a NoClassDefFoundError... > > I found some informations about this on the web, but nothing seems to be > clear about what to do. > The complete archiva startup on this machine is attached. It ends with the > complete stacktrace. > > Anyway, for my information, could anyone explain a bit why at this moment > archiva is trying to access a cryptographic API. I'd be interested in it to > maybe better understand what could be done to workaround. > > Thanks a lot. > > -- Baptiste > > -Message d'origine- > De : MATHUS Baptiste [mailto:[EMAIL PROTECTED] Envoyé : lundi 12 > novembre 2007 17:41 À : [EMAIL PROTECTED] Objet : Run > Archiva on Aix > > Hi all, > > Thanks to cb, I solved my repo problem. I finally decided to separate my > corporate and publicly retrieved artifact under two distinct urls. > Now, my tests are finished, I want to install my archiva config on an Aix. My > tests were done on a Debian Linux. > > Do you think it's a lost cause ? :-). > Which script in the archiva/bin directory would be the closest to the Aix > needs if someone has an idea? > > Thanks a lot. > > -- > B. MATHUS > > -- > -- > > [P520]/cic/archiva/bin:./plexus.sh > Using PLEXUS_HOME: /cic/archiva > Using PLEXUS_BASE: /cic/archiva > Using PLEXUS_TMPDIR: /cic/archiva/temp > Using JAVA_HOME: /usr/java5 > [INFO] Loading on start [role,roleHint]: > [org.codehaus.plexus.naming.Naming,dataSources] > [INFO] Loading on start [role,roleHint]: > [org.codehaus.plexus.contextualizer.Contextualizer,jettyConfiguration] > [INFO] Services will be deployed in: '/cic/archiva/services'. > [INFO] Applications will be deployed in: '/cic/archiva/apps'. > [INFO] Service Supervisor is deploying > plexus-appserver-service-jetty-2.0-alpha-8. > [INFO] Removing old service. > [DEBUG] Found 1 components to load on start [INFO] Loading on start > [role,roleHint]: > [org.codehaus.plexus.appserver.service.PlexusService,jetty] > 13 Nov 2007 09:53:29 org.mortbay.http.HttpServer doStart > INFO: Version Jetty/5.1.10 > 13 Nov 2007 09:53:29 org.mortbay.util.Container start > INFO: Started [EMAIL PROTECTED] [INFO] Application > Supervisor is deploying archiva-plexus-application-1.0-beta-3. > [INFO] Application 'archiva' already extracted. > [INFO] Deploying application 'archiva' at > '/cic/apache-archiva-1.0-beta-3/apps/archiva'. > [INFO] Using application configurator file > /cic/archiva/apps/archiva/conf/application.xml. > [INFO] Using appDir = /cic/archiva/apps/archiva [DEBUG] appserver.home > = /cic/archiva [DEBUG] appserver.base = /cic/archiva [INFO] Deploying > /cic/apache-archiva-1.0-beta-3/apps/archiva/webapp with context path > of /archiva [INFO] Using standard webapp classloader for webapp. > [INFO] Deploying appserver 'archiva'. > [INFO] Adding HTTP listener on *4000 > 13 Nov 2007 09:53:32 org.mortbay.http.SocketListener start > INFO: Started SocketListener on 0.0.0.0:4000 [INFO] Starting Jetty > Context /archiva > 13 Nov 2007 09:53:32 org.mortbay.util.FileResource > INFO: Checking Resource aliases > 13 Nov 2007 09:53:34 org.mortbay.util.Container start > INFO: Started [EMAIL PROTECTED] > 13 Nov 2007 09:53:34 org.mortbay.jetty.servlet.ServletHandler$Context > log > INFO: Loading plexus context properties from: '/WEB-INF/plexus.properties' > 13 Nov 2007 09:53:34 org.mortbay.jetty.servlet.ServletHandler$Context > log > INFO: Could not load plex
RE: Run Archiva on Aix
OK. I directly launched the plexus.sh script in the bin directory and archiva started fine. The thing is, I'm now having problem with the class javax.crypto.b that triggers a NoClassDefFoundError... I found some informations about this on the web, but nothing seems to be clear about what to do. The complete archiva startup on this machine is attached. It ends with the complete stacktrace. Anyway, for my information, could anyone explain a bit why at this moment archiva is trying to access a cryptographic API. I'd be interested in it to maybe better understand what could be done to workaround. Thanks a lot. -- Baptiste -Message d'origine----- De : MATHUS Baptiste [mailto:[EMAIL PROTECTED] Envoyé : lundi 12 novembre 2007 17:41 À : [EMAIL PROTECTED] Objet : Run Archiva on Aix Hi all, Thanks to cb, I solved my repo problem. I finally decided to separate my corporate and publicly retrieved artifact under two distinct urls. Now, my tests are finished, I want to install my archiva config on an Aix. My tests were done on a Debian Linux. Do you think it's a lost cause ? :-). Which script in the archiva/bin directory would be the closest to the Aix needs if someone has an idea? Thanks a lot. -- B. MATHUS [P520]/cic/archiva/bin:./plexus.sh Using PLEXUS_HOME: /cic/archiva Using PLEXUS_BASE: /cic/archiva Using PLEXUS_TMPDIR: /cic/archiva/temp Using JAVA_HOME: /usr/java5 [INFO] Loading on start [role,roleHint]: [org.codehaus.plexus.naming.Naming,dataSources] [INFO] Loading on start [role,roleHint]: [org.codehaus.plexus.contextualizer.Contextualizer,jettyConfiguration] [INFO] Services will be deployed in: '/cic/archiva/services'. [INFO] Applications will be deployed in: '/cic/archiva/apps'. [INFO] Service Supervisor is deploying plexus-appserver-service-jetty-2.0-alpha-8. [INFO] Removing old service. [DEBUG] Found 1 components to load on start [INFO] Loading on start [role,roleHint]: [org.codehaus.plexus.appserver.service.PlexusService,jetty] 13 Nov 2007 09:53:29 org.mortbay.http.HttpServer doStart INFO: Version Jetty/5.1.10 13 Nov 2007 09:53:29 org.mortbay.util.Container start INFO: Started [EMAIL PROTECTED] [INFO] Application Supervisor is deploying archiva-plexus-application-1.0-beta-3. [INFO] Application 'archiva' already extracted. [INFO] Deploying application 'archiva' at '/cic/apache-archiva-1.0-beta-3/apps/archiva'. [INFO] Using application configurator file /cic/archiva/apps/archiva/conf/application.xml. [INFO] Using appDir = /cic/archiva/apps/archiva [DEBUG] appserver.home = /cic/archiva [DEBUG] appserver.base = /cic/archiva [INFO] Deploying /cic/apache-archiva-1.0-beta-3/apps/archiva/webapp with context path of /archiva [INFO] Using standard webapp classloader for webapp. [INFO] Deploying appserver 'archiva'. [INFO] Adding HTTP listener on *4000 13 Nov 2007 09:53:32 org.mortbay.http.SocketListener start INFO: Started SocketListener on 0.0.0.0:4000 [INFO] Starting Jetty Context /archiva 13 Nov 2007 09:53:32 org.mortbay.util.FileResource INFO: Checking Resource aliases 13 Nov 2007 09:53:34 org.mortbay.util.Container start INFO: Started [EMAIL PROTECTED] 13 Nov 2007 09:53:34 org.mortbay.jetty.servlet.ServletHandler$Context log INFO: Loading plexus context properties from: '/WEB-INF/plexus.properties' 13 Nov 2007 09:53:34 org.mortbay.jetty.servlet.ServletHandler$Context log INFO: Could not load plexus context properties from: '/WEB-INF/plexus.properties' 2007-11-13 09:53:35,411 [main] INFO org.codehaus.plexus.PlexusContainer - Loading on start [role,roleHint]: [org.apache.maven.archiva.web.startup.ArchivaStartup,default] 2007-11-13 09:53:37,135 [main] WARN net.sf.ehcache.config.ConfigurationFactory - No configuration found. Configuring ehcache from ehcache-failsafe.xml found in the classpath: jar:file:/cic/apache-archiva-1.0-beta-3/apps/archiva/webapp/WEB-INF/lib/ehcache-1.3.0.jar!/ehcache-failsafe.xml 2007-11-13 09:53:46,042 [main] DEBUG org.apache.maven.archiva.configuration.FileTypes:default - Loading XML configuration from classloader resource: org/apache/maven/archiva/configuration/default-archiva.xml 2007-11-13 09:53:46,273 [main] INFO org.quartz.simpl.RAMJobStore - RAMJobStore initialized. 2007-11-13 09:53:46,274 [main] INFO org.quartz.impl.StdSchedulerFactory - Quartz scheduler 'defaultScheduler' initialized from an externally provided properties instance. 2007-11-13 09:53:46,276 [main] INFO org.quartz.impl.StdSchedulerFactory - Quartz scheduler version: 1.4.5 2007-11-13 09:53:46,277 [main] INFO org.quartz.core.QuartzScheduler - Scheduler defaultScheduler_$_NON_CLUSTERED started. 2007-11-13 09:53:46,411 [main] INFO org.apache.maven.archiva.web.startup.ArchivaStartup:default - _ __ /\_ / \
Run Archiva on Aix
Hi all, Thanks to cb, I solved my repo problem. I finally decided to separate my corporate and publicly retrieved artifact under two distinct urls. Now, my tests are finished, I want to install my archiva config on an Aix. My tests were done on a Debian Linux. Do you think it's a lost cause ? :-). Which script in the archiva/bin directory would be the closest to the Aix needs if someone has an idea? Thanks a lot. -- B. MATHUS
RE: Proxify many repositories under the same url
OK.
With the config you're showing, I suppose maven (on the dev machines) always
goes through the archiva server? If yes, then this is exactly what I need.
I guess we don't need to define the part since we don't have any
authentication set.
Is it the mirrorOf set to "*" that's important in what you show?
And on the archiva side, what did you configure?
Ah, I think I get it. Inside the server, you upload the corporate jars and so
on inside the "internal" directory you have somewhere and everything that's
proxified coming from outside is also put inside this dir?
If so, I'll do it if I can't do differently, but I would have prefered to be
able to separate public jars and corporate ones in two different directories,
but offer them under one single URL.
Thanks again.
-Message d'origine-
De : cbrown [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 9 novembre 2007 15:04
À : [EMAIL PROTECTED]
Objet : Re: Proxify many repositories under the same url
I'm doing exactly that. They key point turned out to be these settings in
settings.xml;
internal
m2repo
**
...
*
Archiva Mirror Repository
http://m2repo/archiva/repository/internal
internal
On Fri, 2007-11-09 at 14:47 +0100, MATHUS Baptiste wrote:
> Hi all,
>
> We're trying to use archiva as a simple maven proxy. We'd like to be
> able to provide only one url to our developer boxes that would proxify
> many repositories.
> For example, we would put http://ourCIserver/archiva/repository/all/
> in every single settings.xml maven file.
>
> Behind this url, archiva would be able to be proxifying transparently
> public well-known repositories + corporate files.
>
> Here's what I thought I could do :
> 1/ define one of more remote repositories (like repo1.maven.org/maven2
> for example) 2/ define a managed repo called corporate, or so 3/
> define a proxy connector that would offer the union of both
> repositories above under only one URL.
>
> In fact, I want to put the remote repo and all this conf inside
> archiva only. I don't want dev configs to have to be aware that there
> are n repositories to declare in their settings.xml. Moreover, we
> really don't want to be forced to update say 30 computer configs if we
> decide to add another remote repo inside archiva.
>
> I hope I'm being understandable.
>
> Is there any way to achieve this with archiva or should I stop looking
> for this feature?
>
> Thanks a lot.
Proxify many repositories under the same url
Hi all, We're trying to use archiva as a simple maven proxy. We'd like to be able to provide only one url to our developer boxes that would proxify many repositories. For example, we would put http://ourCIserver/archiva/repository/all/ in every single settings.xml maven file. Behind this url, archiva would be able to be proxifying transparently public well-known repositories + corporate files. Here's what I thought I could do : 1/ define one of more remote repositories (like repo1.maven.org/maven2 for example) 2/ define a managed repo called corporate, or so 3/ define a proxy connector that would offer the union of both repositories above under only one URL. In fact, I want to put the remote repo and all this conf inside archiva only. I don't want dev configs to have to be aware that there are n repositories to declare in their settings.xml. Moreover, we really don't want to be forced to update say 30 computer configs if we decide to add another remote repo inside archiva. I hope I'm being understandable. Is there any way to achieve this with archiva or should I stop looking for this feature? Thanks a lot.
RE: Use archiva as simple proxy
Great! It now works ok without authentication. But I'm still getting 404 when I try accessing remote resources that haven't been cached yet. I tried configuring the "proxy connector" with "cache failures" set to "cached", modifiying this parameter doesn't seem to change anything. I would like archiva to try downloading remote resources on demand when first access (as a classical proxy would do). 404 would then be thrown only if the requested resource was not found on one of the repositories (managed or remote). Thanks again. PS : Isn't what I want to achieve the most common use case? > -Message d'origine- > De : Michael Horwitz [mailto:[EMAIL PROTECTED] > Envoyé : lundi 25 juin 2007 11:29 > À : [EMAIL PROTECTED] > Objet : Re: Use archiva as simple proxy > > To get this working on our setup, I had to add the repository > observer role for each managed repository to the guest user > (there should be one by default?). > > Mike. > > On 6/25/07, MATHUS Baptiste <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > Is it possible to just disable authentication. I'd like to > use archiva > > as a very simple proxy, just as "maven-proxy" does. Am I forced to > > declared a guest user for this? > > > > My only wish at the moment is to be able to configure > archiva to act > > as a unified proxy for external resources + corporate ones that I > > would put in another dir (then from archiva clients, these > resources > > would just be presented unifiedly). > > > > I chose archiva because of the additional search features, > but I would > > really like to disable authentication. I also chose this software > > because I may have to use some more advanced features in > the future, > > so I hope I will be able to keep on using archiva at this > time instead > > of looking for another product (as I would have had to do > with maven-proxy, for example). > > > > Thanks a lot. > > > > -- > > Baptiste MATHUS - [EMAIL PROTECTED] > > Systèmes & Méthodes > > MIPIH - Midi Pyrénées Informatique Hospitalière > > > > >
Use archiva as simple proxy
Hi all, Is it possible to just disable authentication. I'd like to use archiva as a very simple proxy, just as "maven-proxy" does. Am I forced to declared a guest user for this? My only wish at the moment is to be able to configure archiva to act as a unified proxy for external resources + corporate ones that I would put in another dir (then from archiva clients, these resources would just be presented unifiedly). I chose archiva because of the additional search features, but I would really like to disable authentication. I also chose this software because I may have to use some more advanced features in the future, so I hope I will be able to keep on using archiva at this time instead of looking for another product (as I would have had to do with maven-proxy, for example). Thanks a lot. -- Baptiste MATHUS - [EMAIL PROTECTED] Systèmes & Méthodes MIPIH - Midi Pyrénées Informatique Hospitalière
Add compilation date in the manifest
Hi all, I'm looking for the variable that could be used to declare an additional property "compilationDate" in the manifest. I've been looking at this page as a starting point : http://maven.apache.org/guides/mini/guide-manifest.html But I can't find anywhere on the net how the variable corresponding to when the compilation process was started is called. Thanks in advance. -- Baptiste MATHUS - [EMAIL PROTECTED] Systèmes & Méthodes MIPIH - Midi Pyrénées Informatique Hospitalière - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
