multiproject:artifact, SNAPSHOT dependencies and the repository

["Kalaveshi, Adrian" <ak...@rsasecurity.com>]

Greetings --

Is there a best practices document describing maven's role in a multiproject
environment?

One of the problems I'm currently trying to tackle is this: 

- internal components have dependencies to SNAPSHOT versions of other
internal components.
- after each project is compiled, it's SNAPSHOT artifact is created and
'installed' to the local repository (for use by other projects)
- when the next project is compiled, it's dependencies are downloaded from
the repository (overwriting the SNAPSHOT artifact that was created in the
previous line item)

I want to avoid deploying these artifacts to the remote repository until
after it's determined that the entire multiproject build was successful.

If anyone has a similar configuration, I'd be curious to hear how you're
working around this.

Thanks,
-adrian-

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: multiproject:artifact, SNAPSHOT dependencies and the repository

[Ben Walding <be...@walding.com>]

Interestingly I had an issue like this the other day.  I couldn't work 
out what was causing this, but erasing the upstream SNAPSHOT and putting 
a new one in fixed this.

Eg. 

 > jar:install the dataforge-engine-SNAPSHOT.jar
then when building the dataforge-editor-SNAPSHOT, it would download an 
older snapshot over the top of the freshly created 
dataforge-engine-SNAPSHOT that I had just installed

This was causing me a lot of angst and I couldn't work out what the 
problem was - all the dates seemed ok, all the clocks on the machines 
seemed ok etc.  Weirdly, removing the SNAPSHOT from the repository 
(ibiblio in this case) resolved the problem.


If it happens again I will look into it further.


(I am running a stock maven-1.0-rc1 + sdocbook plugin)


Cheers,

Ben




dion@multitask.com.au wrote:

>"Kalaveshi, Adrian" <ak...@rsasecurity.com> wrote on 02/03/2004 
>08:09:36 AM:
>
>  
>
>>Greetings --
>>
>>Is there a best practices document describing maven's role in a 
>>    
>>
>multiproject
>  
>
>>environment?
>>
>>One of the problems I'm currently trying to tackle is this: 
>>
>>- internal components have dependencies to SNAPSHOT versions of other
>>internal components.
>>- after each project is compiled, it's SNAPSHOT artifact is created and
>>'installed' to the local repository (for use by other projects)
>>    
>>
>
>We have exactly this.
>
>  
>
>>- when the next project is compiled, it's dependencies are downloaded 
>>    
>>
>from
>  
>
>>the repository (overwriting the SNAPSHOT artifact that was created in 
>>    
>>
>the
>  
>
>>previous line item)
>>    
>>
>
>This doesn't happen for us. We never get a download as our local SNAPSHOT 
>is newer than the one in the remote repo.
>
>--
>dIon Gillard, Multitask Consulting
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: multiproject:artifact, SNAPSHOT dependencies and the repository

[di...@multitask.com.au]

"Kalaveshi, Adrian" <ak...@rsasecurity.com> wrote on 02/03/2004 
08:09:36 AM:

> Greetings --
> 
> Is there a best practices document describing maven's role in a 
multiproject
> environment?
> 
> One of the problems I'm currently trying to tackle is this: 
> 
> - internal components have dependencies to SNAPSHOT versions of other
> internal components.
> - after each project is compiled, it's SNAPSHOT artifact is created and
> 'installed' to the local repository (for use by other projects)

We have exactly this.

> - when the next project is compiled, it's dependencies are downloaded 
from
> the repository (overwriting the SNAPSHOT artifact that was created in 
the
> previous line item)

This doesn't happen for us. We never get a download as our local SNAPSHOT 
is newer than the one in the remote repo.

--
dIon Gillard, Multitask Consulting