[cle-release-team] Snapshots in Sonatype repo

Steve Swinsburg steve.swinsburg at gmail.com
Thu Jun 21 17:39:01 PDT 2012


It would be nice not to have everything in the source checkout, so if adding in relativePath makes everything behave even with snapshots in the repo, then +1.

However my concern at this point in time is when you want to pull in new tools into an older build (a build of dashboard or lessonbuilder into 2.8 for example), since your local repo isn't populated with the snapshot artifacts then the build fails because it can't locate them.

It seems to me that deploying the snapshots + adding relativePath should fix both trunk and older builds?

cheers,
Steve




On 22/06/2012, at 10:23 AM, Matthew Jones wrote:

> So there was some concern a few months back about which artifacts were getting pulled into the build. We were going to discuss this at the conference but didn't get to doing that. There was some consideration to adding relativePath back to the indies to point back to master so you could get the the 'trunk all' to work better, but this hasn't been done yet. That should have been safe because the search order is:
> 
> "Notice the relativePath element. It is not required, but may be used as a signifier to Maven to first search the path given for this project's parent, before searching the local and then remote repositories. " -  https://maven.apache.org/pom.html 
> 
> Then there was some problems with maven2 verses maven3. In the sonatype repository, it would put special metadata on the artifacts that was incompatible with maven2. I seemed to be unable to get this removed so *really* trunk was only able to be built with maven3. 
> 
> On top of that, the sonatype snapshot repository (as you mentioned) isn't defined in any of the projects, but it is defined in master, so if it finds master, if can find everything. So I *wanted* to have all of the indies be tagged to a released version of master, but nobody liked this either because while we only really define properties for tools in master (which are also fixed) and these are really just the api's, this isn't entirely clear.
> 
> So there was kind of this roadblock about what to do.
> 
> We can: 
> 
> 1) Continue on as you said for option 1 and just make the way to on develop trunk be
>  - Check out trunk all
>  - Build trunk all
>  - Build the tool you want
>  (Minimally you probably just need to build kernel & master, but some tools like dashboard need everything anyway)
> 
> 2) Deploy snapshots again (but I don't want to do this if it's going to make people unhappy again, as it was a lot of work to clean that up the first time, and if we're going to add the repository for sonatype snapshot to all indies so it can find this, even more)
> 
> I think we could do #2 IF we also added relativePath back in as well to all the indies. This might make it safer for maven2 builds and more reliable for trunk-all, because I believe otherwise it *would* go to the remote repository to get the master and kernel on the first build, unless you did build those separately.
> 
> WWSSD?! :)
> 
> On Thu, Jun 21, 2012 at 6:50 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> Hi all,
> 
> I know we discussed using sakai-trunk-all (not just sakai trunk) for builds to resolve the missing snapshot issue, however there is still an issue when you want to use a tool that binds to a newer snapshot artifact in an older version of Sakai, and that snapshot is not in a repo.
> 
> For example running the dashboard in Sakai 2.8 or 2.9. It declares a parent of:
> <parent>
> 	<groupId>org.sakaiproject</groupId>
> 	<artifactId>master</artifactId>
> 	<version>2.10-SNAPSHOT</version>
> </parent>
> 
> So unless I have:
> 1. Built 2.10 on my local machine, or
> 2. Changed the pom and therefore mucked up the version of dependencies that are inherited
> 
> I cannot build.
> 
> This would be resolved if the snapshots could be deployed to the sonatype snapshots repo and the repo listed in the projects.
> 
> thanks,
> Steve
> 
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20120622/26c123c0/attachment-0006.html 


More information about the cle-release-team mailing list