Re: getting LATEST version from the local repository
That's completely reasonable -- we don't have more than one version in
production at a given time, however.
On Tue, Feb 1, 2011 at 9:29 PM, Ron Wheeler
wrote:
> On 01/02/2011 11:03 AM, Mate Varga wrote:
>
>> Perforce, and we're strict about comments as well, but we don't really do
>> branching and tagging (the dev team size is just too small).
>>
> We are very small as well but we really do need the branching and tagging
> to enable us to support and fix bugs in multiple versions that are in
> production plus test and development.
>
> Ron
>
> It does not need to be very easy to tie source to snapshots.
>>
>> Besides that, is what I've written about snapshots correct?
>>
>> On Tue, Feb 1, 2011 at 3:52 PM, Ron Wheeler
>> wrote:
>>
>> What version control system are you using?
>>>
>>> We are using Subversion and are pretty strict about:
>>> a) Branching and tagging
>>> b) Comments.
>>>
>>> The fundamental question is "How easy does it have to be to tie a source
>>> version to a snapshot?"
>>> We very seldom need to go back and do a forensic reconstruction of the
>>> crime.
>>> When we do, we have comments and commit dates in the SCM that can be
>>> matched against other evidence (paper notes, Snapshot dates, e-mails,
>>> etc.)
>>> to determine where the source and the other event (test, presentation,
>>> e-mail, bug report) coincide in time.
>>>
>>> SNAPSHOTS and Subversion commits are both dated so it is always possible
>>> to
>>> match them.
>>> It has been required less than 3 times in the past 4 years that we have
>>> been developing with Subversion and Maven, so the extra time to read a
>>> history or go through a set of Maven Artifacts (we have Nexus) is not
>>> really
>>> a determining factor in our selection of a methodology and development
>>> protocol.
>>>
>>>
>>> Ron
>>>
>>>
>>> On 01/02/2011 10:14 AM, Mate Varga wrote:
>>>
>>> That sounds right.
>>>> As far as I know, Maven assumes that releases are immutable, but
>>>> snapshots
>>>> are not. So I could just use {some version number}-SNAPSHOT for all of
>>>> our
>>>> projects and they would depend on each others' snapshot versions.
>>>> As far as I remember, the reason why I've chosen version numbers instead
>>>> of
>>>> SNAPSHOTs is that given a 'snapshot' (not in the Maven sense) of a
>>>> project
>>>> and it's runtime dependencies, it is possible to go and find the sources
>>>> he
>>>> artifacts were built from.
>>>> So in our current setup, a self-containing 'release' of project a
>>>> contains
>>>> A-12.jar
>>>> B-19.jar
>>>> C-123.jar
>>>> D-111.jar
>>>>
>>>> The version numbers are CI build numbers. Using snapshots (and without
>>>> manual versioning), this would look like A-1-SNAPSHOT, B-1-SNAPSHOT,
>>>> etc.
>>>> However, this should not be a problem as there are hundred other ways of
>>>> tying an artifact to a build / source revision...
>>>>
>>>> So you recommend just using a fixed version and SNAPSHOTs instead of
>>>> 'RELEASE's?
>>>>
>>>> Sorry for being confusing, this is my first encounter with Maven (and
>>>> even
>>>> with these hacks it's much more convenient than Ant, at least for our
>>>> purposes).
>>>>
>>>> Thanks,
>>>> Mate
>>>>
>>>> On Tue, Feb 1, 2011 at 2:43 PM, Ron Wheeler
>>>> wrote:
>>>>
>>>> It does seem that you are describing the way SNAPSHOTS work.
>>>>
>>>>> Can you identify any particular problem in your environment that
>>>>> prevents
>>>>> you from working according to the Best Practices that thousands of
>>>>> organizations are following?
>>>>> I can not see from anything that you have described so far that is
>>>>> abnormal.
>>>>> We have 70 projects that make up a large LMS and it depends on 60+
>>>>> third
>>>>> party libraries and most of the war files include dependencies on our
>>>>> utilities and web services.
>>>>>
>>>>> We do not use CI but dozens of regulars here do and can he
Re: getting LATEST version from the local repository
Perforce, and we're strict about comments as well, but we don't really do
branching and tagging (the dev team size is just too small).
It does not need to be very easy to tie source to snapshots.
Besides that, is what I've written about snapshots correct?
On Tue, Feb 1, 2011 at 3:52 PM, Ron Wheeler
wrote:
> What version control system are you using?
>
> We are using Subversion and are pretty strict about:
> a) Branching and tagging
> b) Comments.
>
> The fundamental question is "How easy does it have to be to tie a source
> version to a snapshot?"
> We very seldom need to go back and do a forensic reconstruction of the
> crime.
> When we do, we have comments and commit dates in the SCM that can be
> matched against other evidence (paper notes, Snapshot dates, e-mails, etc.)
> to determine where the source and the other event (test, presentation,
> e-mail, bug report) coincide in time.
>
> SNAPSHOTS and Subversion commits are both dated so it is always possible to
> match them.
> It has been required less than 3 times in the past 4 years that we have
> been developing with Subversion and Maven, so the extra time to read a
> history or go through a set of Maven Artifacts (we have Nexus) is not really
> a determining factor in our selection of a methodology and development
> protocol.
>
>
> Ron
>
>
> On 01/02/2011 10:14 AM, Mate Varga wrote:
>
>> That sounds right.
>> As far as I know, Maven assumes that releases are immutable, but snapshots
>> are not. So I could just use {some version number}-SNAPSHOT for all of our
>> projects and they would depend on each others' snapshot versions.
>> As far as I remember, the reason why I've chosen version numbers instead
>> of
>> SNAPSHOTs is that given a 'snapshot' (not in the Maven sense) of a project
>> and it's runtime dependencies, it is possible to go and find the sources
>> he
>> artifacts were built from.
>> So in our current setup, a self-containing 'release' of project a contains
>> A-12.jar
>> B-19.jar
>> C-123.jar
>> D-111.jar
>>
>> The version numbers are CI build numbers. Using snapshots (and without
>> manual versioning), this would look like A-1-SNAPSHOT, B-1-SNAPSHOT, etc.
>> However, this should not be a problem as there are hundred other ways of
>> tying an artifact to a build / source revision...
>>
>> So you recommend just using a fixed version and SNAPSHOTs instead of
>> 'RELEASE's?
>>
>> Sorry for being confusing, this is my first encounter with Maven (and even
>> with these hacks it's much more convenient than Ant, at least for our
>> purposes).
>>
>> Thanks,
>> Mate
>>
>> On Tue, Feb 1, 2011 at 2:43 PM, Ron Wheeler
>> wrote:
>>
>> It does seem that you are describing the way SNAPSHOTS work.
>>>
>>> Can you identify any particular problem in your environment that prevents
>>> you from working according to the Best Practices that thousands of
>>> organizations are following?
>>> I can not see from anything that you have described so far that is
>>> abnormal.
>>> We have 70 projects that make up a large LMS and it depends on 60+ third
>>> party libraries and most of the war files include dependencies on our
>>> utilities and web services.
>>>
>>> We do not use CI but dozens of regulars here do and can help make that
>>> work
>>> correctly.
>>>
>>> Can you give a short description of the issues that made you abandon
>>> SNAPSHOTS?
>>>
>>>
>>> Ron
>>>
>>>
>>> On 01/02/2011 9:22 AM, Mate Varga wrote:
>>>
>>> What assumptions do I break except the immutability of an artifact with
>>>> a
>>>> specific version? (Which is only broken locally, and mvn should not
>>>> really
>>>> know about it, and it should not affect anything as mvn does not copy
>>>> local
>>>> artifacts anywhere.)
>>>>
>>>> Well, then the easiest thing is to explain what I'd like to do -- and
>>>> maybe
>>>> there's some other way to achieve it.
>>>>
>>>> (let's assume we have 3 projects, A, B, C,D; A depends on B, B depends
>>>> on
>>>> C
>>>> and A depends on D
>>>> - we don't have major / minor versions at all -- we do not want and we
>>>> do
>>>> not need a separate release procedure. Every successful CI build is
>>>> considered to be a new version.
Re: getting LATEST version from the local repository
That sounds right.
As far as I know, Maven assumes that releases are immutable, but snapshots
are not. So I could just use {some version number}-SNAPSHOT for all of our
projects and they would depend on each others' snapshot versions.
As far as I remember, the reason why I've chosen version numbers instead of
SNAPSHOTs is that given a 'snapshot' (not in the Maven sense) of a project
and it's runtime dependencies, it is possible to go and find the sources he
artifacts were built from.
So in our current setup, a self-containing 'release' of project a contains
A-12.jar
B-19.jar
C-123.jar
D-111.jar
The version numbers are CI build numbers. Using snapshots (and without
manual versioning), this would look like A-1-SNAPSHOT, B-1-SNAPSHOT, etc.
However, this should not be a problem as there are hundred other ways of
tying an artifact to a build / source revision...
So you recommend just using a fixed version and SNAPSHOTs instead of
'RELEASE's?
Sorry for being confusing, this is my first encounter with Maven (and even
with these hacks it's much more convenient than Ant, at least for our
purposes).
Thanks,
Mate
On Tue, Feb 1, 2011 at 2:43 PM, Ron Wheeler
wrote:
> It does seem that you are describing the way SNAPSHOTS work.
>
> Can you identify any particular problem in your environment that prevents
> you from working according to the Best Practices that thousands of
> organizations are following?
> I can not see from anything that you have described so far that is
> abnormal.
> We have 70 projects that make up a large LMS and it depends on 60+ third
> party libraries and most of the war files include dependencies on our
> utilities and web services.
>
> We do not use CI but dozens of regulars here do and can help make that work
> correctly.
>
> Can you give a short description of the issues that made you abandon
> SNAPSHOTS?
>
>
> Ron
>
>
> On 01/02/2011 9:22 AM, Mate Varga wrote:
>
>> What assumptions do I break except the immutability of an artifact with a
>> specific version? (Which is only broken locally, and mvn should not really
>> know about it, and it should not affect anything as mvn does not copy
>> local
>> artifacts anywhere.)
>>
>> Well, then the easiest thing is to explain what I'd like to do -- and
>> maybe
>> there's some other way to achieve it.
>>
>> (let's assume we have 3 projects, A, B, C,D; A depends on B, B depends on
>> C
>> and A depends on D
>> - we don't have major / minor versions at all -- we do not want and we do
>> not need a separate release procedure. Every successful CI build is
>> considered to be a new version. Obviously, successful CI builds should be
>> handled as snapshots, but if project B has been successfully built in the
>> CI, then each following build of A should be using that version. Therefore
>> the version numbers should be incremented automatically (CI build number
>> could be used for that)
>> - developers should be able to modify and build project B locally, and
>> then
>> modify and build A (and A should use B which was built locally)
>>
>> Currently, what I do is
>> - have two profiles, a 'local' and a 'CI', which are activated
>> automatically
>> depending on the environment
>> - after successful CI builds, artifacts are deployed to the repo manager
>> (this works perfectly)
>> - locally built artifacts have version no.
>> - if an internal project references another internal project, then it
>> refers
>> to its 'LATEST' version
>>
>> Are there other ways to achieve similar results? Please do not criticize
>> the
>> way we do releases, as this is 'given', and it's the result of the
>> environment we work in. We cannot have major/minor releases, nor can we
>> manually version each release. I'd be very happy if there were a proper
>> way
>> to do what we're doing in a bit hacky way now.
>>
>> Thanks,
>> Mate
>>
>> On Tue, Feb 1, 2011 at 1:22 PM, Stephen Connolly<
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> ugh this is just so wrong I don't know where to start.
>>>
>>> please consider using SNAPSHOTS as they are the correct way
>>>
>>> LATEST and RELEASE do not mean what you think they mean, and they have
>>> been
>>> deprecated. their use is no longer supported.
>>>
>>> maven makes assumptions about non-SNAPSHOT versions which you are
>>> breaking
>>> behind its back.
>>>
>>> there be dragons here
>>>
>>> - Stephen
>>>
>>> ---
>>> Sent from my Android phone, so random spelling mistakes, random nonsense
>>> words and other nonsense are a direct result of using swype to type on
>>> the
>>> screen
>>> On 1 Feb 2011 11:13, "Mate Varga" wrote:
>>>
>>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: getting LATEST version from the local repository
What assumptions do I break except the immutability of an artifact with a specific version? (Which is only broken locally, and mvn should not really know about it, and it should not affect anything as mvn does not copy local artifacts anywhere.) Well, then the easiest thing is to explain what I'd like to do -- and maybe there's some other way to achieve it. (let's assume we have 3 projects, A, B, C,D; A depends on B, B depends on C and A depends on D - we don't have major / minor versions at all -- we do not want and we do not need a separate release procedure. Every successful CI build is considered to be a new version. Obviously, successful CI builds should be handled as snapshots, but if project B has been successfully built in the CI, then each following build of A should be using that version. Therefore the version numbers should be incremented automatically (CI build number could be used for that) - developers should be able to modify and build project B locally, and then modify and build A (and A should use B which was built locally) Currently, what I do is - have two profiles, a 'local' and a 'CI', which are activated automatically depending on the environment - after successful CI builds, artifacts are deployed to the repo manager (this works perfectly) - locally built artifacts have version no. - if an internal project references another internal project, then it refers to its 'LATEST' version Are there other ways to achieve similar results? Please do not criticize the way we do releases, as this is 'given', and it's the result of the environment we work in. We cannot have major/minor releases, nor can we manually version each release. I'd be very happy if there were a proper way to do what we're doing in a bit hacky way now. Thanks, Mate On Tue, Feb 1, 2011 at 1:22 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > ugh this is just so wrong I don't know where to start. > > please consider using SNAPSHOTS as they are the correct way > > LATEST and RELEASE do not mean what you think they mean, and they have been > deprecated. their use is no longer supported. > > maven makes assumptions about non-SNAPSHOT versions which you are breaking > behind its back. > > there be dragons here > > - Stephen > > --- > Sent from my Android phone, so random spelling mistakes, random nonsense > words and other nonsense are a direct result of using swype to type on the > screen > On 1 Feb 2011 11:13, "Mate Varga" wrote: >
getting LATEST version from the local repository
Hi, we're using an internal repository manager (Artifactory) for storing our internal artifacts. Local builds always have a version number of '' (instead of SNAPSHOT, there are good reasons for that) -- we're only using simple numbers for versioning internal artifacts, A.B.C -like versioning does not make sense in our case, as we never do major and minor releases. If the developer changes two dependent projects (A and B, A depends on B) locally, then - he builds and installs B, therefore version will be installed into the local repo - he builds A, which references artifact B version LATEST, therefore it should -- in theory -- use artifact B version 9. However, it always downloads the latest deployed version from the repository manager, and uses that one. Artifact B's metadata files in the local repository: - maven-metadata-local correctly references version - maven-metadata-releases references the versions which are deployed to the repository manager How could I force mvn to pick up the latest installed version from the local repository instead of the latest deployed version (with _lower_ version number)? Thanks, Mate
Re: ant task runs twice
Never mind, I've spend half day with this and it was my fault. :(
(
mvn -Drelease-version=43 -P release,-local clean test deploy
)
test / deploy both run tests.
On Fri, Dec 17, 2010 at 10:35 AM, Mate Varga wrote:
> It also seems that this has nothing to do with whatever lifecycle is the
> task bound to. Even if the POM looks like below, it runs twice:
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.6
>
>
> generate-wireformats
> validate
>
>
>
>
>
>
> run
>
>
> ...
>
> On Fri, Dec 17, 2010 at 10:25 AM, Mate Varga wrote:
>
>> Hello,
>>
>> I've got an Ant task which is bound to 'generate-resources' phase. If I
>> try to deploy the project, the task gets executed twice (before and after
>> the tests).
>> Any ideas about how could I prevent that?
>>
>> # 'release' and 'local' are my own profiles.
>>
>> (~/)\>mvn -P release,-local clean deploy -DskipTests=true
>>
>> [INFO]
>> [INFO]
>>
>> [INFO] Building xxx 43
>> [INFO]
>>
>> [INFO]
>> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ cache ---
>> [INFO] Deleting /xxx
>> [INFO]
>> [INFO] --- maven-antrun-plugin:1.6:run (generate-wireformats) @ cache ---
>> [INFO] Executing tasks
>>
>> main:
>> [echo] compile classpath: ${maven.compile.classpath}
>> [generator] Writing wireformat config file with classloader URLs: /xxx
>> [generator] Writing wireformat config file with relative file URLs: /xxx
>>
>> [INFO] Executed tasks
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @
>> cache ---
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] Copying 3 resources
>> [INFO]
>> [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ cache
>> ---
>> [INFO] Compiling 100 source files to /xxx
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.4.3:testResources
>> (default-testResources) @ cache ---
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] Copying 2 resources
>> [INFO]
>> [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @
>> cache ---
>> [INFO] Compiling 20 source files to /xxx
>> [INFO]
>> [INFO] --- maven-surefire-plugin:2.5:test (default-test) @ cache ---
>> [INFO] Tests are skipped.
>> [INFO]
>> [INFO] --- maven-antrun-plugin:1.6:run (generate-wireformats) @ cache ---
>> [INFO] Executing tasks
>>
>>
>> Thanks,
>> Mate
>>
>
>
Re: ant task runs twice
It also seems that this has nothing to do with whatever lifecycle is the
task bound to. Even if the POM looks like below, it runs twice:
org.apache.maven.plugins
maven-antrun-plugin
1.6
generate-wireformats
validate
run
...
On Fri, Dec 17, 2010 at 10:25 AM, Mate Varga wrote:
> Hello,
>
> I've got an Ant task which is bound to 'generate-resources' phase. If I try
> to deploy the project, the task gets executed twice (before and after the
> tests).
> Any ideas about how could I prevent that?
>
> # 'release' and 'local' are my own profiles.
>
> (~/)\>mvn -P release,-local clean deploy -DskipTests=true
>
> [INFO]
> [INFO]
>
> [INFO] Building xxx 43
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ cache ---
> [INFO] Deleting /xxx
> [INFO]
> [INFO] --- maven-antrun-plugin:1.6:run (generate-wireformats) @ cache ---
> [INFO] Executing tasks
>
> main:
> [echo] compile classpath: ${maven.compile.classpath}
> [generator] Writing wireformat config file with classloader URLs: /xxx
> [generator] Writing wireformat config file with relative file URLs: /xxx
>
> [INFO] Executed tasks
> [INFO]
> [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @
> cache ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 3 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ cache
> ---
> [INFO] Compiling 100 source files to /xxx
> [INFO]
> [INFO] --- maven-resources-plugin:2.4.3:testResources
> (default-testResources) @ cache ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @
> cache ---
> [INFO] Compiling 20 source files to /xxx
> [INFO]
> [INFO] --- maven-surefire-plugin:2.5:test (default-test) @ cache ---
> [INFO] Tests are skipped.
> [INFO]
> [INFO] --- maven-antrun-plugin:1.6:run (generate-wireformats) @ cache ---
> [INFO] Executing tasks
>
>
> Thanks,
> Mate
>
ant task runs twice
Hello,
I've got an Ant task which is bound to 'generate-resources' phase. If I try
to deploy the project, the task gets executed twice (before and after the
tests).
Any ideas about how could I prevent that?
# 'release' and 'local' are my own profiles.
(~/)\>mvn -P release,-local clean deploy -DskipTests=true
[INFO]
[INFO]
[INFO] Building xxx 43
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ cache ---
[INFO] Deleting /xxx
[INFO]
[INFO] --- maven-antrun-plugin:1.6:run (generate-wireformats) @ cache ---
[INFO] Executing tasks
main:
[echo] compile classpath: ${maven.compile.classpath}
[generator] Writing wireformat config file with classloader URLs: /xxx
[generator] Writing wireformat config file with relative file URLs: /xxx
[INFO] Executed tasks
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @
cache ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ cache ---
[INFO] Compiling 100 source files to /xxx
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources
(default-testResources) @ cache ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @
cache ---
[INFO] Compiling 20 source files to /xxx
[INFO]
[INFO] --- maven-surefire-plugin:2.5:test (default-test) @ cache ---
[INFO] Tests are skipped.
[INFO]
[INFO] --- maven-antrun-plugin:1.6:run (generate-wireformats) @ cache ---
[INFO] Executing tasks
Thanks,
Mate
Re: Limiting dependency resolution depth
Ron, I didn't want to dump mvn output here -- I know what the problem is, namely that some repositories are not properly set up (for example: https://maven.atlassian.com/content/repositories/public/com/atlassian/jira/atlassian-jira-webapp/3.12-SNAPSHOT/ -- there is no valid metadata file here, so you can't use this repo as a proper remote repo). It seemed that a) I deploy the jars manually b) I can somehow break the dependency chain. As b) is not (really) possible, I've got to do a). Mate On Fri, Dec 10, 2010 at 2:21 PM, Ron Wheeler wrote: > Mate, > You might get more help if you actually provided some details about what is > your build is actually saying and what repos are broken. > > Ron > > On 10/12/2010 9:07 AM, Stefan Seidel wrote: >> >> Hi Mate, >> >> you can, as a workaround, download the pom.xml of your dependency and copy >> those dependencies into your own pom.xml (or another one which only contains >> those). Then change/add the "scope" of all those dependencies to "provided", >> which should effectively disable deeper dependency resolution. >> >> Stefan >> >> On Fri, 10 Dec 2010 12:56:49 + >> Mate Varga wrote: >> >>> Hello Tamas, >>> >>> 1) Sources are checked out from SVN to the local drive. >>> 2) Yes, missing dependencies. The problems stem from things like >>> missing maven-metadata files in the public repos. (I've checked that, >>> the repo maintainers do know about the inconsistencies, but they >>> refuse to fix it.) >>> 3) I've done all of that, and I've manually checked the online repos >>> -- the dependency chain is broken, -U, :purge-local-repository does >>> not help, and my network connection is all right. >>> >>> I could go and fetch all the required jars/wars/etc. manually and >>> deploy them into my internal repo, but I want to avoid that if it's >>> possible. >>> >>> Udv, >>> Mate >>> >>> >>> 2010/12/10 Tamás Cservenák: >>>> >>>> Hi, >>>> >>>> Okay, but to be able to help, we need more: >>>> >>>> 1) where are the sources you try to build? (especially POM) >>>> 2) what is the failure? "dependency resolution fails" as missing a >>>> dependency or what? >>>> 3) check for network failures on your side, and repeat builds with -U to >>>> force maven to try again (the fact that a dep was not found is cached) >>>> >>>> >>>> Thanks, >>>> ~t~ >>>> >>>> On Fri, Dec 10, 2010 at 1:22 PM, Mate Varga >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm pretty new to Java and Maven, so my question may be very naive >>>>> and/or stupid, apologies for that. >>>>> I'm trying to compile an open-source project (if that matters, it's >>>>> https://plugins.atlassian.com/plugin/details/4832 ), which is supposed >>>>> to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1 >>>>> (r1038046; 2010-11-23 10:58:32+)). This pretty small project >>>>> depends on a larger one (Atlassian JIRA), which has some Maven >>>>> support, but the public repos are not well maintained, and there are a >>>>> lot of broken dependencies, therefore the dependency resolution >>>>> process fails. >>>>> However, I have all of the first level (direct) dependencies resolved. >>>>> As far as my knowledge goes, it's enough to have the first level >>>>> dependencies to compile a Java project, and that's exactly what I >>>>> want. Is there a way to tell Maven to stop resolving>2 level >>>>> dependencies, and just try compiling the project? I tried to Google >>>>> for this, no luck; and the guides on mvn dependency resolution don't >>>>> help either. >>>>> >>>>> Thanks, >>>>> Mate >>>>> >>>>> - >>>>> 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: Limiting dependency resolution depth
Thanks, that's a good idea. On Fri, Dec 10, 2010 at 2:07 PM, Stefan Seidel wrote: > Hi Mate, > > you can, as a workaround, download the pom.xml of your dependency and copy > those dependencies into your own pom.xml (or another one which only contains > those). Then change/add the "scope" of all those dependencies to "provided", > which should effectively disable deeper dependency resolution. > > Stefan > > On Fri, 10 Dec 2010 12:56:49 + > Mate Varga wrote: > >> Hello Tamas, >> >> 1) Sources are checked out from SVN to the local drive. >> 2) Yes, missing dependencies. The problems stem from things like >> missing maven-metadata files in the public repos. (I've checked that, >> the repo maintainers do know about the inconsistencies, but they >> refuse to fix it.) >> 3) I've done all of that, and I've manually checked the online repos >> -- the dependency chain is broken, -U, :purge-local-repository does >> not help, and my network connection is all right. >> >> I could go and fetch all the required jars/wars/etc. manually and >> deploy them into my internal repo, but I want to avoid that if it's >> possible. >> >> Udv, >> Mate >> >> >> 2010/12/10 Tamás Cservenák : >> > Hi, >> > >> > Okay, but to be able to help, we need more: >> > >> > 1) where are the sources you try to build? (especially POM) >> > 2) what is the failure? "dependency resolution fails" as missing a >> > dependency or what? >> > 3) check for network failures on your side, and repeat builds with -U to >> > force maven to try again (the fact that a dep was not found is cached) >> > >> > >> > Thanks, >> > ~t~ >> > >> > On Fri, Dec 10, 2010 at 1:22 PM, Mate Varga wrote: >> > >> >> Hi, >> >> >> >> I'm pretty new to Java and Maven, so my question may be very naive >> >> and/or stupid, apologies for that. >> >> I'm trying to compile an open-source project (if that matters, it's >> >> https://plugins.atlassian.com/plugin/details/4832 ), which is supposed >> >> to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1 >> >> (r1038046; 2010-11-23 10:58:32+)). This pretty small project >> >> depends on a larger one (Atlassian JIRA), which has some Maven >> >> support, but the public repos are not well maintained, and there are a >> >> lot of broken dependencies, therefore the dependency resolution >> >> process fails. >> >> However, I have all of the first level (direct) dependencies resolved. >> >> As far as my knowledge goes, it's enough to have the first level >> >> dependencies to compile a Java project, and that's exactly what I >> >> want. Is there a way to tell Maven to stop resolving >2 level >> >> dependencies, and just try compiling the project? I tried to Google >> >> for this, no luck; and the guides on mvn dependency resolution don't >> >> help either. >> >> >> >> Thanks, >> >> Mate >> >> >> >> - >> >> 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 >> > > > -- > Mit freundlichen Grüßen, > > Stefan Seidel > Software-Entwickler > > VUB Printmedia GmbH > Chopinstraße 4, 04103 Leipzig > tel. +49 (341) 9 60 50 93 > fax. +49 (341) 9 60 50 92 > mail. ssei...@vub.de > web. www.vub.de > > VUB Printmedia GmbH > HRB Köln 24015 > GF Dr. A. Preuss Neudorf, Dr. C. Preuss Neudorf > > - > 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: Limiting dependency resolution depth
Thanks. > You mentioned you have an internal repo already, so if the maintainers > of the remote repos you're trying to pull from won't cooperate, put > the needed artifacts in your own repo and you'll be good to go. Yeah, that's what I wanted to avoid. I will do it if there is no other way, but I find it a bit annoying that it is not possible to cut off the dependency chain at a certain point. > > For example, I can declare a dependency on Struts and then use > BeanUtils classes in my code, because I know the Struts dependency > will give me BeanUtils transitively. Well, my view is that if you're directly referencing a type, then it should be a direct dependency in your project -- because the project's dependencies are not part of the interface, e.g. if Struts' deps get changed, then your project might break even the interface remains the same. > > In any case, you can't just 'turn off' transitive dependency > resolution in Maven. :( Thanks, Mate - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Limiting dependency resolution depth
Hello Tamas, 1) Sources are checked out from SVN to the local drive. 2) Yes, missing dependencies. The problems stem from things like missing maven-metadata files in the public repos. (I've checked that, the repo maintainers do know about the inconsistencies, but they refuse to fix it.) 3) I've done all of that, and I've manually checked the online repos -- the dependency chain is broken, -U, :purge-local-repository does not help, and my network connection is all right. I could go and fetch all the required jars/wars/etc. manually and deploy them into my internal repo, but I want to avoid that if it's possible. Udv, Mate 2010/12/10 Tamás Cservenák : > Hi, > > Okay, but to be able to help, we need more: > > 1) where are the sources you try to build? (especially POM) > 2) what is the failure? "dependency resolution fails" as missing a > dependency or what? > 3) check for network failures on your side, and repeat builds with -U to > force maven to try again (the fact that a dep was not found is cached) > > > Thanks, > ~t~ > > On Fri, Dec 10, 2010 at 1:22 PM, Mate Varga wrote: > >> Hi, >> >> I'm pretty new to Java and Maven, so my question may be very naive >> and/or stupid, apologies for that. >> I'm trying to compile an open-source project (if that matters, it's >> https://plugins.atlassian.com/plugin/details/4832 ), which is supposed >> to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1 >> (r1038046; 2010-11-23 10:58:32+)). This pretty small project >> depends on a larger one (Atlassian JIRA), which has some Maven >> support, but the public repos are not well maintained, and there are a >> lot of broken dependencies, therefore the dependency resolution >> process fails. >> However, I have all of the first level (direct) dependencies resolved. >> As far as my knowledge goes, it's enough to have the first level >> dependencies to compile a Java project, and that's exactly what I >> want. Is there a way to tell Maven to stop resolving >2 level >> dependencies, and just try compiling the project? I tried to Google >> for this, no luck; and the guides on mvn dependency resolution don't >> help either. >> >> Thanks, >> Mate >> >> - >> 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
Limiting dependency resolution depth
Hi, I'm pretty new to Java and Maven, so my question may be very naive and/or stupid, apologies for that. I'm trying to compile an open-source project (if that matters, it's https://plugins.atlassian.com/plugin/details/4832 ), which is supposed to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1 (r1038046; 2010-11-23 10:58:32+)). This pretty small project depends on a larger one (Atlassian JIRA), which has some Maven support, but the public repos are not well maintained, and there are a lot of broken dependencies, therefore the dependency resolution process fails. However, I have all of the first level (direct) dependencies resolved. As far as my knowledge goes, it's enough to have the first level dependencies to compile a Java project, and that's exactly what I want. Is there a way to tell Maven to stop resolving >2 level dependencies, and just try compiling the project? I tried to Google for this, no luck; and the guides on mvn dependency resolution don't help either. Thanks, Mate - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
