[cle-release-team] Snapshots in Sonatype repo

[Matthew Jones]

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/20120621/0b9e4fef/attachment-0006.html