On 10/13/2010 1:19 PM, David Weintraub wrote:
On Wed, Oct 13, 2010 at 1:42 PM, Les Mikesell<lesmikes...@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
lesmikes...@gmail.com
