On 13 October 2010 19:19, David Weintraub <qazwart_at_gmail.com> 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.
Our C/C++ guys just use curl to POST the binaries to Nexus over
http... we also POST the .pom file and the .md5 and .sha1 files...
that is because one of their build toolchain envs cannot have Java on
it... Nexus will rebuild the metadata.xml files for you, so all you
really need is to post the .pom and the e.g. .so and the .pom.md5,
.pom.sha1, .so.md5 and .so.sha1 files and you're done.
If you have a java install on the system, use maven or maven-ant-tasks
(from ant) or ivy (from ant) to do the post for you.
I think I had a set of bash scripts somewhere in
http://svn.apache.org/repos/asf/maven/sandbox/trunk/ at some time.
I'll see if I can find them
>
> 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.
>
The advantage of a Maven repository is that you can use a Maven
Repository Manager to enforce some good things, such as write-once,
authorization and search... but there is nothing stopping you from
just copying everything to a big file share in the sky!
> Imagine if you take the approach of checking into your repository the
> libprojb.so library for Project A to use. What usually happens is that
> you have a lib directory under your project with a libprojb.so
> directory in it. You have no idea what files went into this directory
> or what version it was from. Two years from now, that libprojb.so
> directory will still be there and no one will know anything about it.
>
> However, imagine if in Project A's make file is a macro
> PROJB-LIB=projb/3.2, and later on, it uses this information to do a
> scp from the release repository. You can look at that particular
> version of Project A and say "Ah! It uses version 3.2 of Project B.
> Since we tagged the source code used for that version of Project B as
> 3.2, we can still trace down the correct version. And, we can see that
> the next release of Project A uses version 3.3 of Project B.
>
> --
> David Weintraub
> qazwart_at_gmail.com
>
Received on 2010-10-14 09:40:16 CEST