On 10/13/2010 1:19 PM, David Weintraub wrote:
> On Wed, Oct 13, 2010 at 1:42 PM, Les Mikesell<lesmikesell_at_gmail.com> wrote:
>> How would you access them if you don't have java/maven/ivy when you want to
>> retrieve a certain version?
>
> Before we adopted our Ant projects to use Maven, we simply used the
> <get> task. You can always download from a Maven repository using the
> "get" and "wget" commands. Maven repositories, after all, are HTTP
> accessible. There's no real reason why you can't user wget and curl to
> do the fetching if you aren't a Java shop.
>
> Uploading is trickier though. We simply used a shell script that
> generated the correct "mvn install-file" command and didn't have to
> generate a POM. Maven and Java are fairly easy to install and use open
> source licenses, so there isn't really a big deal to install them.
> With the "mvn install-file", we didnt' even have to create a pom.xml
> file. We could build the command on the fly with just a shell script.
>
> But, there's really no reason that you HAVE to use a Maven repository.
> All you need is a remote storage directory and the concept of version
> numbers. I'd setup the repository to use Mavenish concept of object
> with sub-directories for each release and embedd the release into the
> object between the object's name and suffix. For example, if Project B
> produced a library libprojb.so, I'd call the thing libprojb-3.2.so,
> and store it in my projectb/3.2 directory.
We currently commit component binaries back into tags which are then
used by other things with external references, and final binaries are
managed separately by project, but that seems wrong on several levels.
I'd like to find a generic scheme (and one that can be plugged into
hudson if possible) to store build results with a versioning scheme that
doesn't force you to keep them forever because most are obsolete after a
few new builds but that has a close-coupling to the svn version or at
least the tag name of the matching source. But this seems like it
should be a common scenario and not something everyone re-invents
differently.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2010-10-13 20:56:00 CEST