Re: Change the values of custom properties during project creation
Am 20.10.2011 15:09, schrieb ntzanos: > I want to change the default values that I have set in my archetype pom.xml > to some custom value during project creation. Is this possilble? Put a section into your archetype descriptor: http://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html The archetype plugin asks for values for these required properties during project creation. It is also possible to specify default values: http://maven.apache.org/archetype/maven-archetype-plugin/specification/generate.html Best regards Ansgar - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3, _maven.repositories and *lastUpdated
Hrm - this should exactly like the behavior that the newer Aether library -already- solves, as has done for months when you drop in the newer version. I know this post is more about disabling the feature, but ignoring it makes WAY more sense IMHO. If, as you say - "Artifact A downloaded from X is not the same thing to Maven 3 as A downloaded from Y" then the entire GAV is a lie as it DOESN'T actually identify an artifact. Mark Still wanting that 3.0.4 release... -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree On Sun, Oct 23, 2011 at 6:19 AM, Jason van Zyl wrote: > The artifacts have an identity. It matters where the artifacts were > downloaded from. Artifact A downloaded from X is not the same thing to Maven > 3 as A downloaded from Y. This can happen when you flip your settings.xml to > go from using a repository manager to using Maven Central directly for > example. > > There is currently no way to turn that off. But you can vote for the > issue[1]. > > [1]: http://jira.codehaus.org/browse/MNG-5181 > > On Oct 22, 2011, at 10:05 AM, Stefan Eder wrote: > > > With Maven 3 dependency resolution may fail for artifacts, which have > once been fetched from a remote repository, even so they are available > within the local repository. > > Guess there is a good reason for that and I would like to understand it > and I would like to know if there is a way to switch this behaviour off. > > > > Thanks, Stefan > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > > >
Re: Maven 3, _maven.repositories and *lastUpdated
On Oct 23, 2011, at 1:17 PM, Mark Derricutt wrote: > Hrm - this should exactly like the behavior that the newer Aether library > -already- solves, as has done for months when you drop in the newer version. > > I know this post is more about disabling the feature, but ignoring it makes > WAY more sense IMHO. If, as you say - "Artifact A downloaded from X is not > the same thing to Maven 3 as A downloaded from Y" then the entire GAV is a > lie as it DOESN'T actually identify an artifact. The GAV itself being a unique identifier, or GUID-like, could only be true if all artifacts came from a single source. This is not the case in practice. Peter, Paul and Mary could knowingly, or unknowingly, rebuild a library with a given GAV. If all three variants are available under different conditions you potentially have a problem. So if you use a repository manager at work and pull one variant, and then go home and pull from Maven Central, you could potentially have something different. We erred on the side of caution. A simple change, which is better than disabling this feature, would be to consider the checksum too. I'm just guessing here, but I think that's what users intuitively expect: if it comes from somewhere different but the checksum is the same it's fine, but if it is actually different than what I currently have fail, or at the very least warn me. This would not be hard to change. > > Mark > Still wanting that 3.0.4 release... > > -- > "Great artists are extremely selfish and arrogant things" — Steven Wilson, > Porcupine Tree > > > On Sun, Oct 23, 2011 at 6:19 AM, Jason van Zyl wrote: > >> The artifacts have an identity. It matters where the artifacts were >> downloaded from. Artifact A downloaded from X is not the same thing to Maven >> 3 as A downloaded from Y. This can happen when you flip your settings.xml to >> go from using a repository manager to using Maven Central directly for >> example. >> >> There is currently no way to turn that off. But you can vote for the >> issue[1]. >> >> [1]: http://jira.codehaus.org/browse/MNG-5181 >> >> On Oct 22, 2011, at 10:05 AM, Stefan Eder wrote: >> >>> With Maven 3 dependency resolution may fail for artifacts, which have >> once been fetched from a remote repository, even so they are available >> within the local repository. >>> Guess there is a good reason for that and I would like to understand it >> and I would like to know if there is a way to switch this behaviour off. >>> >>> Thanks, Stefan >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> In short, man creates for himself a new religion of a rational >> and technical order to justify his work and to be justified in it. >> >> -- Jacques Ellul, The Technological Society >> >> >> >> >> Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
Re: Maven 3, _maven.repositories and *lastUpdated
Before we go ahead and drop this feature again, I just like to make sure that all people understand _why_ this got implemented the way it is! If you have lots of projects locally and some projects need an additional repository x, then you just add this repo-x to the section of your projects pom. While building your project some artifacts will get downloaded. Let's say you have the repository.jboss.org added to your project and did download JBoss Arquillian. After a build, the arquillian artifacts will then be available in your local repository. Let's assume you then start another project but you don't add the repository.jboss.org. The old maven behaviour was that you still have access to all artifacts in your local repo. So your project will build just fine locally, but if you push your project to github and another person tries to build this project he would get an error because he cannot resolve the arquillian artifacts! Another problem did arise with the java.net maven repo and other repos which contain broken artifacts. This repo historically had a _very_ bad quality, serving broken artifacts, wrong md5 sums, etc. Most of those artifacts also have been available on maven.central - but with a checked and confirmed quality! So back in the days if one project enabled the java.net repo and you downloaded such artifacts from there, then you were basically doomed for the rest of your ~/.m2/repository life ;) Because even other projects which didn't have the java.net repo enabled would now fail. Benjamin, did I forget any other important point? I think if we disable the repo separation now, we should aim to not default back to our original behaviour which also caused lots of problems. LieGrue, strub - Original Message - > From: Mark Derricutt > To: Maven Users List > Cc: > Sent: Sunday, October 23, 2011 7:17 PM > Subject: Re: Maven 3, _maven.repositories and *lastUpdated > > Hrm - this should exactly like the behavior that the newer Aether library > -already- solves, as has done for months when you drop in the newer version. > > I know this post is more about disabling the feature, but ignoring it makes > WAY more sense IMHO. If, as you say - "Artifact A downloaded from X is not > the same thing to Maven 3 as A downloaded from Y" then the entire GAV is a > lie as it DOESN'T actually identify an artifact. > > Mark > Still wanting that 3.0.4 release... > > -- > "Great artists are extremely selfish and arrogant things" — Steven > Wilson, > Porcupine Tree > > > On Sun, Oct 23, 2011 at 6:19 AM, Jason van Zyl wrote: > >> The artifacts have an identity. It matters where the artifacts were >> downloaded from. Artifact A downloaded from X is not the same thing to > Maven >> 3 as A downloaded from Y. This can happen when you flip your settings.xml > to >> go from using a repository manager to using Maven Central directly for >> example. >> >> There is currently no way to turn that off. But you can vote for the >> issue[1]. >> >> [1]: http://jira.codehaus.org/browse/MNG-5181 >> >> On Oct 22, 2011, at 10:05 AM, Stefan Eder wrote: >> >> > With Maven 3 dependency resolution may fail for artifacts, which have >> once been fetched from a remote repository, even so they are available >> within the local repository. >> > Guess there is a good reason for that and I would like to understand > it >> and I would like to know if there is a way to switch this behaviour off. >> > >> > Thanks, Stefan >> > >> > >> > - >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> > For additional commands, e-mail: users-h...@maven.apache.org >> > >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> In short, man creates for himself a new religion of a rational >> and technical order to justify his work and to be justified in it. >> >> -- Jacques Ellul, The Technological Society >> >> >> >> >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
checkModificationExclude NOT ignoring modified files
I am trying to do a simple replace in 2 files when I release:branch. I
thought checkModificationExcludes looked like it would make it possible to
modify the files and have them be on my branch, but it's not working for me.
I added the following profile to my pom:
branch
branch
org.codehaus.mojo
build-helper-maven-plugin
1.7
verify
parse-version
parse-version
com.google.code.maven-replacer-plugin
maven-replacer-plugin
1.3.9
verify
replace
src/test/resources/config/dev/hudson/application.properties
src/test/resources/config/dev/jenkins/application.properties
poseur_test
poseur_test_${parsedVersion.majorVersion}_${parsedVersion.minorVersion}_branch
org.apache.maven.plugins
maven-release-plugin
2.1
src/test/resources/config/dev/hudson/application.properties
src/test/resources/config/dev/jenkins/application.properties
pom.xml
I run the following on my command line, the replace occurs:
mvn build-helper:parse-version replacer:replace release:branch -Pbranch
-DdryRun=true -DbranchName=3.15.x -X -e
I get the following output:
[INFO] [release:branch {execution: default-cli}]
[DEBUG] release.properties not found - using empty properties
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: pom.xml.next, release.properties,
pom.xml.releaseBackup,
src/test/resources/config/dev/jenkins/application.properties,
pom.xml.backup, pom.xml, pom.xml.branch,
src/test/resources/config/dev/hudson/application.properties, pom.xml.tag
[INFO] Executing: /bin/sh -c cd
/Users/jameslevinson/workspace/main/rate/trunk && svn --non-interactive
status
[INFO] Working directory: /Users/jameslevinson/workspace/main/rate/trunk
[DEBUG] ? pom.xml.releaseBackup
[DEBUG] M src/test/resources/config/dev/hudson/application.properties
[DEBUG] M src/test/resources/config/dev/jenkins/application.properties
[DEBUG] M pom.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Cannot prepare the release because you have local modifications :
[src/test/resources/config/dev/hudson/application.properties:modified]
[src/test/resources/config/dev/jenkins/application.properties:modified]
[INFO]
[DEBUG] Trace
org.apache.maven.BuildFailureException: Cannot prepare the release because
you have local modifications :
[src/test/resources/config/dev/hudson/application.properties:modified]
[src/test/resources/config/dev/jenkins/application.properties:modified]
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Re: Maven 3, _maven.repositories and *lastUpdated
On Oct 23, 2011, at 1:52 PM, Mark Struberg wrote: > Before we go ahead and drop this feature again, I just like to make sure that > all people understand _why_ this got implemented the way it is! > I wasn't suggesting dropping the capability because that will potentially lead to non-deterministic results. Any change would have to provide at least the same amount of safety. > If you have lots of projects locally and some projects need an additional > repository x, then you just add this repo-x to the section of > your projects pom. While building your project some artifacts will get > downloaded. More succinctly it is the case where an artifact is available from multiple remote repositories. You could add repositories elements, or change your settings.xml > > > Let's say you have the repository.jboss.org added to your project and did > download JBoss Arquillian. After a build, the arquillian artifacts will then > be available in your local repository. > > Let's assume you then start another project but you don't add the > repository.jboss.org. The old maven behaviour was that you still have access > to all artifacts in your local repo. So your project will build just fine > locally, but if you push your project to github and another person tries to > build this project he would get an error because he cannot resolve the > arquillian artifacts! > The problem can also present itself as a local build failure. The artifact with a GAV taken from a public source may not be the same as an internally patched version for example. Building something that depends on the publicly available artifact will work fine if that's what you download first, but something that depends on the patched version may not. This is the primary reasoning behind the repository being incorporated into the identity. > Another problem did arise with the java.net maven repo and other repos which > contain broken artifacts. This repo historically had a _very_ bad quality, > serving broken artifacts, wrong md5 sums, etc. Most of those artifacts also > have been available on maven.central - but with a checked and confirmed > quality! So back in the days if one project enabled the java.net repo and you > downloaded such artifacts from there, then you were basically doomed for the > rest of your ~/.m2/repository life ;) > > Because even other projects which didn't have the java.net repo enabled would > now fail. This is essentially the same as the case above. People patch crappy artifacts and corresponding metadata and retrieve those from one location, and then change the location. What you have is not same, at least in most cases with Java.net. > > Benjamin, did I forget any other important point? > > I think if we disable the repo separation now, we should aim to not default > back to our original behaviour which also caused lots of problems. > We should not disable this feature, the repository being incorporated into the identity is paramount. If we can arrive at a place where we think the contents from one location can be determined to be the same as another we might be able to consider them equivalent at some level. The checksum might be enough, I haven't thought about it that long. > LieGrue, > strub > > > > > > - Original Message - >> From: Mark Derricutt >> To: Maven Users List >> Cc: >> Sent: Sunday, October 23, 2011 7:17 PM >> Subject: Re: Maven 3, _maven.repositories and *lastUpdated >> >> Hrm - this should exactly like the behavior that the newer Aether library >> -already- solves, as has done for months when you drop in the newer version. >> >> I know this post is more about disabling the feature, but ignoring it makes >> WAY more sense IMHO. If, as you say - "Artifact A downloaded from X is not >> the same thing to Maven 3 as A downloaded from Y" then the entire GAV is a >> lie as it DOESN'T actually identify an artifact. >> >> Mark >> Still wanting that 3.0.4 release... >> >> -- >> "Great artists are extremely selfish and arrogant things" — Steven >> Wilson, >> Porcupine Tree >> >> >> On Sun, Oct 23, 2011 at 6:19 AM, Jason van Zyl wrote: >> >>> The artifacts have an identity. It matters where the artifacts were >>> downloaded from. Artifact A downloaded from X is not the same thing to >> Maven >>> 3 as A downloaded from Y. This can happen when you flip your settings.xml >> to >>> go from using a repository manager to using Maven Central directly for >>> example. >>> >>> There is currently no way to turn that off. But you can vote for the >>> issue[1]. >>> >>> [1]: http://jira.codehaus.org/browse/MNG-5181 >>> >>> On Oct 22, 2011, at 10:05 AM, Stefan Eder wrote: >>> With Maven 3 dependency resolution may fail for artifacts, which have >>> once been fetched from a remote repository, even so they are available >>> within the local repository. Guess there is a good reason for that and I would like to understand >> it >>> and I would lik
Re: Maven 3, _maven.repositories and *lastUpdated
Wait - your not SERIOUSLY calling out Maven Central as being a quality
repository? It's certainly much better now with the excellent work
oss.sonatype.org is providing, but there's still so much broken meta-data
and missing jars and cruft floating around central.
Back to the topic tho - I wouldn't so much be opposed to this behavior if
maven actually told the user this is whats happening, rather than its
current behavior of just saying "artifact not found". I've had numerous
people question their sanity on IRC, around work and elsewhere the confusion
of artifacts being in their local repository, but not being found.
If Maven said something like: "The {GAV} artifact was found in your local
repository, but came from the undeclared repository "xxx", either configure
this in your pom, or in your "yyy" mirror."
Was there some reason why only the repository "id" is stored in the
_maven.repositories file, and not the URL to it? If two projects had
"jboss", and "JBoss" as ids pointing to the same URL, I'd expect them to
work, but I suspect because maven doesn't track that level, then it
wouldn't?
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On Mon, Oct 24, 2011 at 6:52 AM, Mark Struberg wrote:
> Another problem did arise with the java.net maven repo and other repos
> which contain broken artifacts. This repo historically had a _very_ bad
> quality, serving broken artifacts, wrong md5 sums, etc. Most of those
> artifacts also have been available on maven.central - but with a checked and
> confirmed quality! So back in the days if one project enabled the
> java.netrepo and you downloaded such artifacts from there, then you were
> basically
> doomed for the rest of your ~/.m2/repository life ;)
>
Re: Maven 3, _maven.repositories and *lastUpdated
> If Maven said something like: "The {GAV} artifact was found in your local
Such kind of warning would make a lot of sense. Could you please file an issue?
txs!
> Was there some reason why only the repository "id"
I guess it's mainly because of the 'mirror' sections to allow repo managers.
Also in company environments it sometimes happens that server URLs get moved
but the content actually remains the same.
I fear there is no perfect solution. If e.g. 2 projects use the same repo-id
and point to different URLs, then this would also cause inconsistency. But I
think this problem is more theoretic than practically relevant. Lets keep it
with Simon&Garfunkel: there are 50 ways to leave your lover (or crash your
system)...
LieGrue,
strub
- Original Message -
> From: Mark Derricutt
> To: Maven Users List ; Mark Struberg
>
> Cc:
> Sent: Sunday, October 23, 2011 11:03 PM
> Subject: Re: Maven 3, _maven.repositories and *lastUpdated
>
> Wait - your not SERIOUSLY calling out Maven Central as being a quality
> repository? It's certainly much better now with the excellent work
> oss.sonatype.org is providing, but there's still so much broken meta-data
> and missing jars and cruft floating around central.
>
> Back to the topic tho - I wouldn't so much be opposed to this behavior if
> maven actually told the user this is whats happening, rather than its
> current behavior of just saying "artifact not found". I've had
> numerous
> people question their sanity on IRC, around work and elsewhere the confusion
> of artifacts being in their local repository, but not being found.
>
> If Maven said something like: "The {GAV} artifact was found in your local
> repository, but came from the undeclared repository "xxx", either
> configure
> this in your pom, or in your "yyy" mirror."
>
> Was there some reason why only the repository "id" is stored in the
> _maven.repositories file, and not the URL to it? If two projects had
> "jboss", and "JBoss" as ids pointing to the same URL,
> I'd expect them to
> work, but I suspect because maven doesn't track that level, then it
> wouldn't?
>
> Mark
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven
> Wilson,
> Porcupine Tree
>
> On Mon, Oct 24, 2011 at 6:52 AM, Mark Struberg wrote:
>
>> Another problem did arise with the java.net maven repo and other repos
>> which contain broken artifacts. This repo historically had a _very_ bad
>> quality, serving broken artifacts, wrong md5 sums, etc. Most of those
>> artifacts also have been available on maven.central - but with a checked
> and
>> confirmed quality! So back in the days if one project enabled the
> java.netrepo and you downloaded such artifacts from there, then you were
> basically
>> doomed for the rest of your ~/.m2/repository life ;)
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3, _maven.repositories and *lastUpdated
Hi guys, Currently, we're migrating our Archiva to Nexus and I happened to observe the builds used by different teams lately. I fear there is no perfect solution. If e.g. 2 projects use the same repo-id and point to different URLs, then this would also cause inconsistency. But I think this problem is more theoretic than practically relevant. Turns out, that there are projects where people have declared our snapshots repository with id "internal" which is naturally assigned to the internal repo - maybe because the credentials for both are the same. So here's an example from practice. And if I can advocate for keeping this feature - I like it a lot, because we have certain devs, who sometimes build projects locally and forget to deploy them, which results in broken builds. Also, this feature helped me convince the management, why to upgrade to maven 3. Cheers, Stefan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven Antrun doesn't compile the project well.
HI I have the following configuration for antrun. For some reason during the build ant is unable to see the ant.jar file. How do I fix this. Thanks for your help in advance. http://maven.40175.n5.nabble.com/file/n4930208/antrun_configuration antrun_configuration http://maven.40175.n5.nabble.com/file/n4930208/stacktrace stacktrace Venkat -- View this message in context: http://maven.40175.n5.nabble.com/Maven-Antrun-doesn-t-compile-the-project-well-tp4930208p4930208.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3, _maven.repositories and *lastUpdated
I wasn't implying anything about the quality of Maven Central. It's orthogonal
to this argument which is to say the GAV could only work as a unique identifier
if there was one source, or all sources were identical. The quality of the
contents is irrelevant.
The quality of the content is a driving factor in creating variants which I
think is your point.
jvz
On 2011-10-23, at 5:03 PM, Mark Derricutt wrote:
> Wait - your not SERIOUSLY calling out Maven Central as being a quality
> repository? It's certainly much better now with the excellent work
> oss.sonatype.org is providing, but there's still so much broken meta-data
> and missing jars and cruft floating around central.
>
> Back to the topic tho - I wouldn't so much be opposed to this behavior if
> maven actually told the user this is whats happening, rather than its
> current behavior of just saying "artifact not found". I've had numerous
> people question their sanity on IRC, around work and elsewhere the confusion
> of artifacts being in their local repository, but not being found.
>
> If Maven said something like: "The {GAV} artifact was found in your local
> repository, but came from the undeclared repository "xxx", either configure
> this in your pom, or in your "yyy" mirror."
>
> Was there some reason why only the repository "id" is stored in the
> _maven.repositories file, and not the URL to it? If two projects had
> "jboss", and "JBoss" as ids pointing to the same URL, I'd expect them to
> work, but I suspect because maven doesn't track that level, then it
> wouldn't?
>
> Mark
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
> On Mon, Oct 24, 2011 at 6:52 AM, Mark Struberg wrote:
>
>> Another problem did arise with the java.net maven repo and other repos
>> which contain broken artifacts. This repo historically had a _very_ bad
>> quality, serving broken artifacts, wrong md5 sums, etc. Most of those
>> artifacts also have been available on maven.central - but with a checked and
>> confirmed quality! So back in the days if one project enabled the
>> java.netrepo and you downloaded such artifacts from there, then you were
>> basically
>> doomed for the rest of your ~/.m2/repository life ;)
>>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3, _maven.repositories and *lastUpdated
There are no plans to remove it. Only the to try and make it more convenient if possible and make the error messages little more clear. jvz On 2011-10-23, at 5:37 PM, Stefan wrote: > Hi guys, > > Currently, we're migrating our Archiva to Nexus and I happened to observe the > builds used by different teams lately. >> I fear there is no perfect solution. If e.g. 2 projects use the same repo-id >> and point to different URLs, then this would also cause inconsistency. But I >> think this problem is more theoretic than practically relevant. > Turns out, that there are projects where people have declared our snapshots > repository with id "internal" which is naturally assigned to the internal > repo - maybe because the credentials for both are the same. So here's an > example from practice. > > And if I can advocate for keeping this feature - I like it a lot, because we > have certain devs, who sometimes build projects locally and forget to deploy > them, which results in broken builds. Also, this feature helped me convince > the management, why to upgrade to maven 3. > > Cheers, > Stefan > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3, _maven.repositories and *lastUpdated
Yes, the log messages definitely need improvement - I've seen colleagues with little maven experience getting really confused. Mark's proposal looks fine. As I recall someone mentioned that it would be nice to be able to turn it off (in the spirit of making it more convenient) - to which I cannot fully agree. I'm afraid once people find how to turn it off they'll be tempted to just turn it off when they see the error. Cheers, Stefan On 24.10.2011 г. 00:49 ч., Jason van Zyl wrote: There are no plans to remove it. Only the to try and make it more convenient if possible and make the error messages little more clear. jvz On 2011-10-23, at 5:37 PM, Stefan wrote: Hi guys, Currently, we're migrating our Archiva to Nexus and I happened to observe the builds used by different teams lately. I fear there is no perfect solution. If e.g. 2 projects use the same repo-id and point to different URLs, then this would also cause inconsistency. But I think this problem is more theoretic than practically relevant. Turns out, that there are projects where people have declared our snapshots repository with id "internal" which is naturally assigned to the internal repo - maybe because the credentials for both are the same. So here's an example from practice. And if I can advocate for keeping this feature - I like it a lot, because we have certain devs, who sometimes build projects locally and forget to deploy them, which results in broken builds. Also, this feature helped me convince the management, why to upgrade to maven 3. Cheers, Stefan - 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: Maven 3, _maven.repositories and *lastUpdated
This should probably move to the dev list, but if we're considering POM changes in a future Maven version, should a element become become part of the dependency declaration? Altho if we're going that far I'd also like to see actually be REMOVED from the pom, and moved to ~/.m2/settings.xml along side the mirrors, with the part of the GA(R)V being required -if- the artifact is from a custom declared repository. This would certainly speed up a lot of builds that (#(*$#(* declare N-repositories in the pom causes maven to walk thru each of them when trying to find something. -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree On Mon, Oct 24, 2011 at 10:45 AM, Jason van Zyl wrote: > I wasn't implying anything about the quality of Maven Central. It's > orthogonal to this argument which is to say the GAV could only work as a > unique identifier if there was one source, or all sources were identical. > The quality of the contents is irrelevant. > > The quality of the content is a driving factor in creating variants which I > think is your point. >
Re: Maven 3, _maven.repositories and *lastUpdated
Personally, I don't think I'd be in favor of ever turning it off. jvz On 2011-10-23, at 6:10 PM, Stefan wrote: > Yes, the log messages definitely need improvement - I've seen colleagues with > little maven experience getting really confused. Mark's proposal looks fine. > > As I recall someone mentioned that it would be nice to be able to turn it off > (in the spirit of making it more convenient) - to which I cannot fully agree. > I'm afraid once people find how to turn it off they'll be tempted to just > turn it off when they see the error. > > Cheers, > Stefan > > On 24.10.2011 г. 00:49 ч., Jason van Zyl wrote: >> There are no plans to remove it. Only the to try and make it more convenient >> if possible and make the error messages little more clear. >> >> jvz >> >> On 2011-10-23, at 5:37 PM, Stefan wrote: >> >>> Hi guys, >>> >>> Currently, we're migrating our Archiva to Nexus and I happened to observe >>> the builds used by different teams lately. I fear there is no perfect solution. If e.g. 2 projects use the same repo-id and point to different URLs, then this would also cause inconsistency. But I think this problem is more theoretic than practically relevant. >>> Turns out, that there are projects where people have declared our snapshots >>> repository with id "internal" which is naturally assigned to the internal >>> repo - maybe because the credentials for both are the same. So here's an >>> example from practice. >>> >>> And if I can advocate for keeping this feature - I like it a lot, because >>> we have certain devs, who sometimes build projects locally and forget to >>> deploy them, which results in broken builds. Also, this feature helped me >>> convince the management, why to upgrade to maven 3. >>> >>> Cheers, >>> Stefan >>> >>> >>> >>> >>> - >>> 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: Maven 3, _maven.repositories and *lastUpdated
Raised as http://jira.codehaus.org/browse/MNG-5185
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On Mon, Oct 24, 2011 at 10:15 AM, Mark Struberg wrote:
> > If Maven said something like: "The {GAV} artifact was found in your
> local
> Such kind of warning would make a lot of sense. Could you please file an
> issue? txs!
Re: Maven Antrun doesn't compile the project well.
> I have the following configuration for antrun. For some reason > during the build ant is unable to see the ant.jar file. How do I fix this. > Thanks for your help in advance. It looks like your code has an undeclared dependency on ant itself. Add the missing dependency and try again. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven 3.0.3: Problems with SNAPSHOT updates
Hello! Thanks everyone, I'll try this Artifactory change as soon as our Artifactory guru is back from vacation! Regards, Ruediger > -Original Message- > From: Patrick Sansoucy [mailto:patrick.sanso...@gmail.com] > Sent: Friday, 21 October, 2011 12:37 > To: Maven Users List > Subject: Re: Maven 3.0.3: Problems with SNAPSHOT updates > > I always refer people to this Jira ... > http://jira.codehaus.org/browse/MNG- > 5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > But Brian's post explains it very well. > > Patrick Sansoucy > In theory, there is no difference between theory and practice, but in > practice, there is ... > > > > On Fri, Oct 21, 2011 at 6:29 AM, Brian Parker > wrote: > > I ran in to this. See > > http://stackoverflow.com/questions/5249342/maven-3-0-2-u-option- > does-n > > ot-update-snapshot/7081166#7081166 > > > > Brian > > > > On Fri, Oct 21, 2011 at 5:13 AM, Dreier Ruediger > wrote: > > > >> Hello! > >> > >> Thanks for your answer, but both solutions do not work for me with > >> Maven 3 > >> - both work perfectly with Maven 2.2.1. > >> With Maven 3 only a metadata file is updated, not the artifact itself. > >> > >> Regards, > >> > >> Ruediger > >> > >> > >> > -Original Message- > >> > From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com] > >> > Sent: Thursday, 20 October, 2011 17:09 > >> > To: Maven Users List > >> > Subject: RE: Maven 3.0.3: Problems with SNAPSHOT updates > >> > > >> > There are two ways. You can force maven to update snapshot by using > >> > the - U option. Ie: > >> > > >> > mvn -U install > >> > > >> > Or you can change when maven updates snapshots by default by > >> > changing the updatePolicy in your settings.xml file. > >> > > >> > http://maven.apache.org/ref/3.0.3/maven-settings/settings.html > >> > > >> > > >> > > -Original Message- > >> > > From: Dreier Ruediger [mailto:ruediger.dre...@bdal.de] > >> > > Sent: Thursday, October 20, 2011 11:02 AM > >> > > To: 'users@maven.apache.org' > >> > > Subject: Maven 3.0.3: Problems with SNAPSHOT updates > >> > > > >> > > Hello! > >> > > > >> > > We are currently using Maven 2.2.1 and Artifactory 2.3.4 (rev. > >> > > 13017) as repository server and I am now evaluating if we can > >> > > migrate to Maven 3. > >> > > > >> > > I am testing Maven 3 in the following environment: > >> > > > >> > > Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Java > version: > >> > > 1.6.0_26, vendor: Sun Microsystems Inc. > >> > > Default locale: en_US, platform encoding: Cp1252 OS name: > >> > > "windows 7", > >> > > version: "6.1", arch: "x86", family: "windows" > >> > > > >> > > I used a very simple POM file for this check: > >> > > > >> > > > >> > > > >> > > de.bdal.common.bcl > >> > > settings > >> > > 0.0.0.1-SNAPSHOT > >> > > binaries > >> > > zip > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > org.apache.maven.plugins > >> > > maven-dependency-plugin > >> > > 2.2 > >> > > > >> > > > >> > > process-resources > >> > > > >> > > unpack-dependencies > >> > > > >> > > > >> > > true > >> > > > >> > > ./target/references > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > On a second PC (our Jenkins build system, still using Maven > >> > > 2.2.1) the project de.bdal.common.bcl:settings can be build. > >> > > > >> > > With an empty local repository, everything works well: > >> > > 'mvn install' downloads the newest version of > >> > > de.bdal.common.bcl:settings to my local repository and the > >> > > dependency plugin extracts it. > >> > > > >> > > Then I use Jenkins on the build system to create a new SNAPSHOT > >> > > build of de.bdal.common.bcl:settings. > >> > > > >> > > Now I try to use this new version: > >> > > > >> > > 'mvn -U install' only downloads metadata: > >> > > > >> > > Downloading: > >> > > http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- > >> > > SNAPSHOT/maven-metadata.xml > >> > > Downloaded: > >> > > http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- > >> > > SNAPSHOT/maven-metadata.xml (319 B at 4.0 KB/sec) > >> > > > >> > > and my local repository contains updated files "maven-metadata- > >> > > inhouse.xml", "maven-metadata-inhouse.xml.sha1" and "resolver- > >> > > status.properties". But all other files are not changed > >> > > (especially settings-0.0.0.1-SNAPSHOT-binaries.zip is not > >> > > updated). However > >> > > "maven- metadata-inhouse.xml" contains the correct value for > >> > > lastUpdate (build time on the server). > >> > > > >> > > What am I doing wrong? > >> > > How do I get updates of snapshot dependencies without deleting my > >> > > local repository? > >> > > > >> > > Thanks for any help, > >> > > > >> > > i.
