You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by David Nalley <da...@gnsa.us> on 2012/07/20 21:13:12 UTC
[DISCUSS] Binaries (jars) in our source tree/source releases.
In one of the OSCON discussions, I noted the recent polite discussion
re binary jars in source releases on general@incubator. While this is
apparently tolerated (if you don't mind wearing Nomex), it's
considered a Bad Thing (TM) generally speaking. Folks suggested that
we look at how subversion handles this. In short, Subversion has a
script that downloads all of their dependencies in binary form - and
they also provide a download for the deps as a tarball.
This made me think that perhaps we should add a .gitignore entry for
.jars in deps/ (and tools/), and write a script that downloads the
specific versions of the dependencies that we need and depending on
argument, either places them in the deps/ directory or creates a
tarball. (hopefully verifying {md5|sha1}sum for each binary along the
way)
Thoughts? comments? flames?
--David
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Wido den Hollander <wi...@widodh.nl>.
On 07/31/2012 11:46 PM, David Nalley wrote:
> Hi folks,
>
> Just a quick update on this. I created the deps-ctrl branch off of
> master now that I actually have something to show.
>
> If you take a look under deps you'll see it looks pretty bare. I've
> removed a number of the jars.
>
> There's also a few new ant targets you can use:
>
> resolveBuildDeps: This downloads the jars that I've removed that are
> necessary for building and places them in deps/
I checked this and see that libvirt 0.4.7 is downloaded. This won't
work, but that's old news.
Since libvirt hasn't updated their maven2 directory (yet) I have put a
JAR online at:
http://zooi.widodh.nl/cloudstack/libvirt-java/libvirt-0.4.8.jar
Would you mind if we add that as a temporary location since the 0.4.7
bindings won't work due to missing flags for storagePoolRefresh.
>
> resolveOptBuildDeps: This downloads some of the jars for plugins that
> aren't in the default code path. (F5, and Libvirt for the moment). [1]
>
> resolveRuntimeDeps: This downloads all of the jars that weren't
> necessary for building CloudStack. I haven't gone though and verified
> that all of these jars are indeed necessary for running, though some
> obviously are.
>
> I've also removed a number of targets from build-all - currently for
> hypervisors only OVM is supported. Xen could be supported, and despite
> having the xenserverjava jar in place, I have removed XS/XCP support
> as well as KVM and VMware as they currently depend on dependencies
> with prohibited licenses. I've also removed NetScaler, F5, and NetApp
> support from the default build.
>
> So why is XenServer Java still there - well some of the db migration
> for 2.1->2.2 code depends on it for some reason. I think I have that
> worked out (I think the import is now unneeded.) but I haven't yet
> tried my fix, so it remains in place so that CloudStack builds
> cleanly. Also - CloudStack currently doesn't build with the default
> xenserverjava bits for 5.6.100 or 6.0, it depends on it's own fork, or
> pukes otherwise.
>
> I also still have the AWSAPI bits to process - I'll start a different
> thread on that momentarily as I have a few questions about that.
>
> Finally, I'd welcome help here, so if you are interested, please jump in.
>
> --David
>
> [1] I haven't been able to find easily downloadable source for all of
> the optional jars. (VMware, NetApp, etc)
>
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by David Nalley <da...@gnsa.us>.
On Tue, Jul 31, 2012 at 5:46 PM, David Nalley <da...@gnsa.us> wrote:
> Hi folks,
>
> Just a quick update on this. I created the deps-ctrl branch off of
> master now that I actually have something to show.
>
> If you take a look under deps you'll see it looks pretty bare. I've
> removed a number of the jars.
>
> There's also a few new ant targets you can use:
>
> resolveBuildDeps: This downloads the jars that I've removed that are
> necessary for building and places them in deps/
>
> resolveOptBuildDeps: This downloads some of the jars for plugins that
> aren't in the default code path. (F5, and Libvirt for the moment). [1]
>
> resolveRuntimeDeps: This downloads all of the jars that weren't
> necessary for building CloudStack. I haven't gone though and verified
> that all of these jars are indeed necessary for running, though some
> obviously are.
>
> I've also removed a number of targets from build-all - currently for
> hypervisors only OVM is supported. Xen could be supported, and despite
> having the xenserverjava jar in place, I have removed XS/XCP support
> as well as KVM and VMware as they currently depend on dependencies
> with prohibited licenses. I've also removed NetScaler, F5, and NetApp
> support from the default build.
>
> So why is XenServer Java still there - well some of the db migration
> for 2.1->2.2 code depends on it for some reason. I think I have that
> worked out (I think the import is now unneeded.) but I haven't yet
> tried my fix, so it remains in place so that CloudStack builds
> cleanly. Also - CloudStack currently doesn't build with the default
> xenserverjava bits for 5.6.100 or 6.0, it depends on it's own fork, or
> pukes otherwise.
>
> I also still have the AWSAPI bits to process - I'll start a different
> thread on that momentarily as I have a few questions about that.
>
> Finally, I'd welcome help here, so if you are interested, please jump in.
>
> --David
>
> [1] I haven't been able to find easily downloadable source for all of
> the optional jars. (VMware, NetApp, etc)
Another quick update.
AWSAPI stuff has largely been cleaned.
the rampart-libs stuff is still there, but isn't necessary for building.
Currently the remaining jars in deps are:
XenServerJava (GPL licensed and a local fork of the code.) - Waiting
on an appropriately licensed version of this.
axis2-ant-plugin (the awsapi has a taskdef that hits before the
dependency is downloaded - I need to fix this still)
hibernate3 (L/GPL - supposedly disappearing any time now.
using 'ant resolveBuildDeps clean-all build-all works - though LOTS of
CloudStack is disabled by default in the deps-ctrl branch.
Hopefully in the next day or so this will get better. If you are
interested in helping, please don't hesitate to jump in.
--David
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by David Nalley <da...@gnsa.us>.
Hi folks,
Just a quick update on this. I created the deps-ctrl branch off of
master now that I actually have something to show.
If you take a look under deps you'll see it looks pretty bare. I've
removed a number of the jars.
There's also a few new ant targets you can use:
resolveBuildDeps: This downloads the jars that I've removed that are
necessary for building and places them in deps/
resolveOptBuildDeps: This downloads some of the jars for plugins that
aren't in the default code path. (F5, and Libvirt for the moment). [1]
resolveRuntimeDeps: This downloads all of the jars that weren't
necessary for building CloudStack. I haven't gone though and verified
that all of these jars are indeed necessary for running, though some
obviously are.
I've also removed a number of targets from build-all - currently for
hypervisors only OVM is supported. Xen could be supported, and despite
having the xenserverjava jar in place, I have removed XS/XCP support
as well as KVM and VMware as they currently depend on dependencies
with prohibited licenses. I've also removed NetScaler, F5, and NetApp
support from the default build.
So why is XenServer Java still there - well some of the db migration
for 2.1->2.2 code depends on it for some reason. I think I have that
worked out (I think the import is now unneeded.) but I haven't yet
tried my fix, so it remains in place so that CloudStack builds
cleanly. Also - CloudStack currently doesn't build with the default
xenserverjava bits for 5.6.100 or 6.0, it depends on it's own fork, or
pukes otherwise.
I also still have the AWSAPI bits to process - I'll start a different
thread on that momentarily as I have a few questions about that.
Finally, I'd welcome help here, so if you are interested, please jump in.
--David
[1] I haven't been able to find easily downloadable source for all of
the optional jars. (VMware, NetApp, etc)
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by David Nalley <da...@gnsa.us>.
On Fri, Jul 27, 2012 at 6:14 PM, Wido den Hollander <wi...@widodh.nl> wrote:
>
>
> On 07/27/2012 06:51 PM, David Nalley wrote:
>>
>> On Fri, Jul 20, 2012 at 3:13 PM, David Nalley <da...@gnsa.us> wrote:
>>>
>>> In one of the OSCON discussions, I noted the recent polite discussion
>>> re binary jars in source releases on general@incubator. While this is
>>> apparently tolerated (if you don't mind wearing Nomex), it's
>>> considered a Bad Thing (TM) generally speaking. Folks suggested that
>>> we look at how subversion handles this. In short, Subversion has a
>>> script that downloads all of their dependencies in binary form - and
>>> they also provide a download for the deps as a tarball.
>>>
>>> This made me think that perhaps we should add a .gitignore entry for
>>> .jars in deps/ (and tools/), and write a script that downloads the
>>> specific versions of the dependencies that we need and depending on
>>> argument, either places them in the deps/ directory or creates a
>>> tarball. (hopefully verifying {md5|sha1}sum for each binary along the
>>> way)
>>>
>>> Thoughts? comments? flames?
>>>
>>> --David
>>
>>
>> As a followup to this, I am proposing that at least for the time being
>> [1] that we just make this an optional ant target, something along the
>> lines of:
>>
>>
>> <project name="CloudStack Deps Resolver" default="help" basedir=".">
>> <description> This downloads binary copies of dependencies for
>> building CloudStack</description>
>> <target name="resolveDependencies">
>> <mkdir dir="deps" />
>> <get
>> src="http://search.maven.org/remotecontent?filepath=log4j/log4j/1.2.9/log4j-1.2.9.jar"
>> dest="deps/log4j-1.2.9.jar" usetimestamp="true" />
>> <get
>> src="http://www.libvirt.org/maven2/org/libvirt/libvirt/0.4.7/libvirt-0.4.7.jar"
>> dest="deps/libvirt-0.4.7.jar" usetimestamp="true" />
>> </target>
>> </project>
>>
>
> libvirt-java 0.4.8 is the latest release which contains everything we need
> for CS 4.0
>
> I'll send a request to Daniel from RedHat to update the maven2 JAR files so
> it contains a 0.4.8 JAR.
I was going to reach out to you to ping them push their jar up, but
haven't gotten around to it - and this was really just example code -
sadly there are scores of dependencies.
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Wido den Hollander <wi...@widodh.nl>.
On 07/27/2012 06:51 PM, David Nalley wrote:
> On Fri, Jul 20, 2012 at 3:13 PM, David Nalley <da...@gnsa.us> wrote:
>> In one of the OSCON discussions, I noted the recent polite discussion
>> re binary jars in source releases on general@incubator. While this is
>> apparently tolerated (if you don't mind wearing Nomex), it's
>> considered a Bad Thing (TM) generally speaking. Folks suggested that
>> we look at how subversion handles this. In short, Subversion has a
>> script that downloads all of their dependencies in binary form - and
>> they also provide a download for the deps as a tarball.
>>
>> This made me think that perhaps we should add a .gitignore entry for
>> .jars in deps/ (and tools/), and write a script that downloads the
>> specific versions of the dependencies that we need and depending on
>> argument, either places them in the deps/ directory or creates a
>> tarball. (hopefully verifying {md5|sha1}sum for each binary along the
>> way)
>>
>> Thoughts? comments? flames?
>>
>> --David
>
> As a followup to this, I am proposing that at least for the time being
> [1] that we just make this an optional ant target, something along the
> lines of:
>
>
> <project name="CloudStack Deps Resolver" default="help" basedir=".">
> <description> This downloads binary copies of dependencies for
> building CloudStack</description>
> <target name="resolveDependencies">
> <mkdir dir="deps" />
> <get src="http://search.maven.org/remotecontent?filepath=log4j/log4j/1.2.9/log4j-1.2.9.jar"
> dest="deps/log4j-1.2.9.jar" usetimestamp="true" />
> <get src="http://www.libvirt.org/maven2/org/libvirt/libvirt/0.4.7/libvirt-0.4.7.jar"
> dest="deps/libvirt-0.4.7.jar" usetimestamp="true" />
> </target>
> </project>
>
libvirt-java 0.4.8 is the latest release which contains everything we
need for CS 4.0
I'll send a request to Daniel from RedHat to update the maven2 JAR files
so it contains a 0.4.8 JAR.
Wido
>
> If I don't get any pushback, I'll start working on this more next week.
> [1] Yes, I know, temporary becomes permanent. But I think this is far
> better than our current intolerable situation, and is still quick and
> easy (compared to learning Ivy or switching to Maven) to implement.
> Unless someone else wants to pick up the work to do that.
>
> --David
>
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by David Nalley <da...@gnsa.us>.
On Fri, Jul 20, 2012 at 3:13 PM, David Nalley <da...@gnsa.us> wrote:
> In one of the OSCON discussions, I noted the recent polite discussion
> re binary jars in source releases on general@incubator. While this is
> apparently tolerated (if you don't mind wearing Nomex), it's
> considered a Bad Thing (TM) generally speaking. Folks suggested that
> we look at how subversion handles this. In short, Subversion has a
> script that downloads all of their dependencies in binary form - and
> they also provide a download for the deps as a tarball.
>
> This made me think that perhaps we should add a .gitignore entry for
> .jars in deps/ (and tools/), and write a script that downloads the
> specific versions of the dependencies that we need and depending on
> argument, either places them in the deps/ directory or creates a
> tarball. (hopefully verifying {md5|sha1}sum for each binary along the
> way)
>
> Thoughts? comments? flames?
>
> --David
As a followup to this, I am proposing that at least for the time being
[1] that we just make this an optional ant target, something along the
lines of:
<project name="CloudStack Deps Resolver" default="help" basedir=".">
<description> This downloads binary copies of dependencies for
building CloudStack</description>
<target name="resolveDependencies">
<mkdir dir="deps" />
<get src="http://search.maven.org/remotecontent?filepath=log4j/log4j/1.2.9/log4j-1.2.9.jar"
dest="deps/log4j-1.2.9.jar" usetimestamp="true" />
<get src="http://www.libvirt.org/maven2/org/libvirt/libvirt/0.4.7/libvirt-0.4.7.jar"
dest="deps/libvirt-0.4.7.jar" usetimestamp="true" />
</target>
</project>
If I don't get any pushback, I'll start working on this more next week.
[1] Yes, I know, temporary becomes permanent. But I think this is far
better than our current intolerable situation, and is still quick and
easy (compared to learning Ivy or switching to Maven) to implement.
Unless someone else wants to pick up the work to do that.
--David
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Wido den Hollander <wi...@widodh.nl>.
On 20-07-12 23:21, Alex Huang wrote:
>>
>> - Lets get rid of the jars
>> - spell out everything needed in the doc
>> - make sure that all these dependencies can be built by distros
+1
>>
>
> +1. In fact, it should spelled out specifically in the build.xml file for each project. Today the build.xml files just take everything in the deps directory to build a class path. Rather it should specifically call out which jar file it needs.
+1 again. That would make life MUCH easier. The generation of the init
script which need a CLASSPATH in them would become much simpler as well.
Wido
>
> --Alex
>
RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Alex Huang <Al...@citrix.com>.
>
> - Lets get rid of the jars
> - spell out everything needed in the doc
> - make sure that all these dependencies can be built by distros
>
+1. In fact, it should spelled out specifically in the build.xml file for each project. Today the build.xml files just take everything in the deps directory to build a class path. Rather it should specifically call out which jar file it needs.
--Alex
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by David Nalley <da...@gnsa.us>.
On Fri, Jul 20, 2012 at 3:35 PM, Robert Schweikert <rj...@suse.com> wrote:
> On 07/20/2012 03:13 PM, David Nalley wrote:
>>
>> In one of the OSCON discussions, I noted the recent polite discussion
>> re binary jars in source releases on general@incubator. While this is
>> apparently tolerated (if you don't mind wearing Nomex), it's
>> considered a Bad Thing (TM) generally speaking. Folks suggested that
>> we look at how subversion handles this. In short, Subversion has a
>> script that downloads all of their dependencies in binary form - and
>> they also provide a download for the deps as a tarball.
>>
>> This made me think that perhaps we should add a .gitignore entry for
>> .jars in deps/ (and tools/), and write a script that downloads the
>> specific versions of the dependencies that we need and depending on
>> argument, either places them in the deps/ directory or creates a
>> tarball. (hopefully verifying {md5|sha1}sum for each binary along the
>> way)
>>
>
>
> Getting rid of the .jars in the source tree is great and I am a very strong
> proponent of this, as stated in another thread a while back.
>
> I question the need to download anything automatically, and thus the
> proposed script.
>
> From a developer point of view I would say one would want to know what is
> getting used. Automatic downloading hides things and thus opens the door for
> "oh I didn't know" or "oops I didn't realize...". I think dependency in
> tools are things the developer is responsible for and a developer better
> know what is needed on the build system.
>
> Packagers should create a cloudstack-devel package that depends on all the
> things needed to set up a development system and all these dependencies
> should be spelled out explicitly in the documentation such that a developer
> that uses a distro that does not package cloud stack can easily get the
> dependencies and install them.
>
> The automatic download has the additional disadvantage that there is
> potential over lap between a package manager and the script. For example if
> I know I need x.jar to develop cloudstack and x.jar is available from my
> distros repo then I will install it and get hacking. Now if we have a script
> that automagically does me favors I get another copy of X.jar on my system.
> This of course may be different then the one from the distribution and there
> might be interference at some point in some unexpected way.
>
> In summary:
>
> - Lets get rid of the jars
> - spell out everything needed in the doc
> - make sure that all these dependencies can be built by distros
To be clear - I wasn't advocating for something to happen without
intervention, but rather for someone to have the choice to use that
script to pull all of the dependencies down. This is particularly
important for platforms without decent package management systems, but
I'd personally see this as a developer tool; with
.rpms/.debs/production deployments I wouldd expect dependency
resolution to handle this sanely instead of deploying a binary blob of
jars.
--David
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Robert Schweikert <rj...@suse.com>.
On 07/20/2012 03:13 PM, David Nalley wrote:
> In one of the OSCON discussions, I noted the recent polite discussion
> re binary jars in source releases on general@incubator. While this is
> apparently tolerated (if you don't mind wearing Nomex), it's
> considered a Bad Thing (TM) generally speaking. Folks suggested that
> we look at how subversion handles this. In short, Subversion has a
> script that downloads all of their dependencies in binary form - and
> they also provide a download for the deps as a tarball.
>
> This made me think that perhaps we should add a .gitignore entry for
> .jars in deps/ (and tools/), and write a script that downloads the
> specific versions of the dependencies that we need and depending on
> argument, either places them in the deps/ directory or creates a
> tarball. (hopefully verifying {md5|sha1}sum for each binary along the
> way)
>
Getting rid of the .jars in the source tree is great and I am a very
strong proponent of this, as stated in another thread a while back.
I question the need to download anything automatically, and thus the
proposed script.
From a developer point of view I would say one would want to know what
is getting used. Automatic downloading hides things and thus opens the
door for "oh I didn't know" or "oops I didn't realize...". I think
dependency in tools are things the developer is responsible for and a
developer better know what is needed on the build system.
Packagers should create a cloudstack-devel package that depends on all
the things needed to set up a development system and all these
dependencies should be spelled out explicitly in the documentation such
that a developer that uses a distro that does not package cloud stack
can easily get the dependencies and install them.
The automatic download has the additional disadvantage that there is
potential over lap between a package manager and the script. For example
if I know I need x.jar to develop cloudstack and x.jar is available from
my distros repo then I will install it and get hacking. Now if we have a
script that automagically does me favors I get another copy of X.jar on
my system. This of course may be different then the one from the
distribution and there might be interference at some point in some
unexpected way.
In summary:
- Lets get rid of the jars
- spell out everything needed in the doc
- make sure that all these dependencies can be built by distros
My $0.02
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Adrian Cole <ad...@gmail.com>.
No experience except it is the only tool suggested for the jclouds project
to switch to (from maven). Looking at asgard, gradle looks clean.
Perhaps we can experiment by taking one piece (perhaps the ec2 bridge), and
converting it?
-A
On Aug 3, 2012 4:57 PM, "Chiradeep Vittal" <Ch...@citrix.com>
wrote:
> Gradle seems to be another
> http://www.gradle.org/
>
>
> Since it is allows scripting (as opposed to configuration xml), it could
> potentially fulfill the waf role as well.
> Anybody have any experience with Gradle?
>
> On 7/24/12 2:19 PM, "Alex Huang" <Al...@citrix.com> wrote:
>
> >> Just out of curiosity, have tools like Ivy and maven been ever
> >>considered for
> >> dependency management?
> >
> >We are looking at these two tools. Our first thoughts is devs should be
> >able to start projects that are tied to other parts of their code so we
> >want this to be as flexible as possible. Maven forces too much of a
> >structure on to the developers. Ivy seems like the right tool to go
> >with. Any comments?
> >
> >--Alex
> >
>
>
RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Edison Su <Ed...@citrix.com>.
> -----Original Message-----
> From: Frank Zhang [mailto:Frank.Zhang@citrix.com]
> Sent: Friday, August 03, 2012 5:35 PM
> To: CloudStack DeveloperList
> Subject: RE: [DISCUSS] Binaries (jars) in our source tree/source
> releases.
>
> >
> > Gradle seems to be another
> > http://www.gradle.org/
> >
> >
> > Since it is allows scripting (as opposed to configuration xml), it
> could
> > potentially fulfill the waf role as well.
> > Anybody have any experience with Gradle?
>
> It seems Gradle received great reputation among famous java communities,
> Hibernate, Spring are all using it.
> People claim it brings ant's flexibility as well as leveraging maven's
> dependency repository. However, I don't have experience on it.
> Anybody knows?
Gradle sounds cool, Groovy DSL is much easier to write and read than the plain XML.
>
>
> >
> > On 7/24/12 2:19 PM, "Alex Huang" <Al...@citrix.com> wrote:
> >
> > >> Just out of curiosity, have tools like Ivy and maven been ever
> > >>considered for dependency management?
> > >
> > >We are looking at these two tools. Our first thoughts is devs
> should
> > >be able to start projects that are tied to other parts of their code
> so
> > >we want this to be as flexible as possible. Maven forces too much
> of a
> > >structure on to the developers. Ivy seems like the right tool to go
> > >with. Any comments?
> > >
> > >--Alex
> > >
RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Frank Zhang <Fr...@citrix.com>.
>
> Gradle seems to be another
> http://www.gradle.org/
>
>
> Since it is allows scripting (as opposed to configuration xml), it could
> potentially fulfill the waf role as well.
> Anybody have any experience with Gradle?
It seems Gradle received great reputation among famous java communities, Hibernate, Spring are all using it.
People claim it brings ant's flexibility as well as leveraging maven's dependency repository. However, I don't have experience on it.
Anybody knows?
>
> On 7/24/12 2:19 PM, "Alex Huang" <Al...@citrix.com> wrote:
>
> >> Just out of curiosity, have tools like Ivy and maven been ever
> >>considered for dependency management?
> >
> >We are looking at these two tools. Our first thoughts is devs should
> >be able to start projects that are tied to other parts of their code so
> >we want this to be as flexible as possible. Maven forces too much of a
> >structure on to the developers. Ivy seems like the right tool to go
> >with. Any comments?
> >
> >--Alex
> >
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Brett Porter <br...@apache.org>.
On 25/07/2012, at 7:19 AM, Alex Huang wrote:
>> Just out of curiosity, have tools like Ivy and maven been ever considered for
>> dependency management?
>
> We are looking at these two tools. Our first thoughts is devs should be able to start projects that are tied to other parts of their code so we want this to be as flexible as possible. Maven forces too much of a structure on to the developers. Ivy seems like the right tool to go with. Any comments?
Only that I'm sad that that's the only thing you took away from looking at Maven ;)
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Tomoe Sugihara <to...@midokura.com>.
On Fri, Aug 10, 2012 at 7:56 AM, Ewan Mellor <Ew...@eu.citrix.com> wrote:
>> -----Original Message-----
>> From: David Nalley [mailto:david@gnsa.us]
>>
>> [Snip]
>>
>> The thread started because the current system isn't really a system,
>> it's just a folder full of binary jars which we were advised against
>> (and saw another incubator project taken to task by the IPMC). As I
>> said elsewhere, I am not opposed to do something else (Maven, Ivy,
>> Gradle, $somethingelse), but who is going to pick it up, get it
>> running, and educate the rest of us between now and a 4.0 release? The
>> proposed intermediate solution is admittedly inelegant, ugly and
>> little better than a shell script, but I doubt there is anyone here
>> who doesn't understand it, and it keeps the build system that does at
>> least build.
>>
>> I personally wouldn't mind picking this up after 4.0 (and learning
>> something new in the process), but just have no cycles at the moment
>> to do so. I am happy for someone else to do it, we just haven't had
>> anyone jumping to own the task.
>
> Yes, I've noticed the lack of people stepping forward ;-)
>
> If it comes down to it, then I will do it. That's going to take me away from other release-related tasks, but Chip and John and you seem to have most of that under control anyway, so we can probably afford it.
>
> If I'm the one who does it, then I'm going to use Gradle unless someone tells me otherwise. I have been reading around, and the frustrations that I've had with Maven in the past are precisely the ones that Gradle was designed to address, and I think that it's a good choice for us. I am open to other people throwing their $0.02 into that discussion, but they'll have to do it soon!
Hi Ewan,
I'd be happy to help although I can't take charge or guarantee how
much time I can spend.
I'd argue that we should have a better build system in place before
the release as It'll be a big pain
to having to deal with multiple build methods.
I have an experience in Maven, but open to new (supposedly better) one.
Tomoe
RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
Heya,
I've been toying a bit with gradle. I've created a new branch "gradle", with just two extra file build.gradle and settings.gradle.
So far I've been able to configure gradle to load some of the dependencies from mavenCentral and most of the java code now compiles using the gradle build. Probably not the best piece of Gradle work, but considering i started with Gradle this morning I'm quite pleased. The groovy based configuration makes it very flexible. That might also be a potential problem as it might be too flexible and that will make it a big mess eventually.
I haven't tried to do anything like running tomcat or building the systemvm, but it should give an idea on gradle anyway. I think it's something we can work with and it will be even easier to do if we align our code structure to the way gradle expects it. Which is much like the maven setup and not a big change from how we do it now.
+1 for Gradle from me (and +1.01 for maven ;-) )
Cheers,
Hugo
-----Original Message-----
From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
Sent: Friday, August 10, 2012 10:19 AM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Hey Ewan,
No worries. I'm familiar with Maven, but I'm more than happy to put some effort into Gradle. It looks like a good choice. I did a few quick checks, Jenkins supports Gradle with a plugin, Elipse support Gradle with a plugin and that's for me the important part.
Still willing to give it a go :-) If anybody with a bit of gradle experience can kick off with a highlevel design of what the build should look like I'll start working on the details. (Or I'll dive into gradle and figure it out any way :) )
Cheers,
Hugo
-----Original Message-----
From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
Sent: Friday, August 10, 2012 12:59 AM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
> -----Original Message-----
> From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
> Sent: Thursday, August 09, 2012 3:57 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Binaries (jars) in our source tree/source
> releases.
>
> > -----Original Message-----
> > From: David Nalley [mailto:david@gnsa.us]
> >
> > [Snip]
> >
> > The thread started because the current system isn't really a system,
> > it's just a folder full of binary jars which we were advised against
> > (and saw another incubator project taken to task by the IPMC). As I
> > said elsewhere, I am not opposed to do something else (Maven, Ivy,
> > Gradle, $somethingelse), but who is going to pick it up, get it
> > running, and educate the rest of us between now and a 4.0 release?
> The
> > proposed intermediate solution is admittedly inelegant, ugly and
> > little better than a shell script, but I doubt there is anyone here
> > who doesn't understand it, and it keeps the build system that does
> > at least build.
> >
> > I personally wouldn't mind picking this up after 4.0 (and learning
> > something new in the process), but just have no cycles at the moment
> > to do so. I am happy for someone else to do it, we just haven't had
> > anyone jumping to own the task.
>
> Yes, I've noticed the lack of people stepping forward ;-)
>
> If it comes down to it, then I will do it. That's going to take me
> away from other release-related tasks, but Chip and John and you seem
> to have most of that under control anyway, so we can probably afford
> it.
>
> If I'm the one who does it, then I'm going to use Gradle unless
> someone tells me otherwise. I have been reading around, and the
> frustrations that I've had with Maven in the past are precisely the
> ones that Gradle was designed to address, and I think that it's a good
> choice for us. I am open to other people throwing their $0.02 into
> that discussion, but they'll have to do it soon!
And now that I read the rest of the thread, I should apologize to Hugo, who did offer some time if we went with Maven.
What do you think, Hugo? Feel like trying Gradle? Prefer to stay with Maven?
Ewan.
RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
Hey Ewan,
No worries. I'm familiar with Maven, but I'm more than happy to put some effort into Gradle. It looks like a good choice. I did a few quick checks, Jenkins supports Gradle with a plugin, Elipse support Gradle with a plugin and that's for me the important part.
Still willing to give it a go :-) If anybody with a bit of gradle experience can kick off with a highlevel design of what the build should look like I'll start working on the details. (Or I'll dive into gradle and figure it out any way :) )
Cheers,
Hugo
-----Original Message-----
From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
Sent: Friday, August 10, 2012 12:59 AM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
> -----Original Message-----
> From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
> Sent: Thursday, August 09, 2012 3:57 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Binaries (jars) in our source tree/source
> releases.
>
> > -----Original Message-----
> > From: David Nalley [mailto:david@gnsa.us]
> >
> > [Snip]
> >
> > The thread started because the current system isn't really a system,
> > it's just a folder full of binary jars which we were advised against
> > (and saw another incubator project taken to task by the IPMC). As I
> > said elsewhere, I am not opposed to do something else (Maven, Ivy,
> > Gradle, $somethingelse), but who is going to pick it up, get it
> > running, and educate the rest of us between now and a 4.0 release?
> The
> > proposed intermediate solution is admittedly inelegant, ugly and
> > little better than a shell script, but I doubt there is anyone here
> > who doesn't understand it, and it keeps the build system that does
> > at least build.
> >
> > I personally wouldn't mind picking this up after 4.0 (and learning
> > something new in the process), but just have no cycles at the moment
> > to do so. I am happy for someone else to do it, we just haven't had
> > anyone jumping to own the task.
>
> Yes, I've noticed the lack of people stepping forward ;-)
>
> If it comes down to it, then I will do it. That's going to take me
> away from other release-related tasks, but Chip and John and you seem
> to have most of that under control anyway, so we can probably afford
> it.
>
> If I'm the one who does it, then I'm going to use Gradle unless
> someone tells me otherwise. I have been reading around, and the
> frustrations that I've had with Maven in the past are precisely the
> ones that Gradle was designed to address, and I think that it's a good
> choice for us. I am open to other people throwing their $0.02 into
> that discussion, but they'll have to do it soon!
And now that I read the rest of the thread, I should apologize to Hugo, who did offer some time if we went with Maven.
What do you think, Hugo? Feel like trying Gradle? Prefer to stay with Maven?
Ewan.
RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Ewan Mellor <Ew...@eu.citrix.com>.
> -----Original Message-----
> From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
> Sent: Thursday, August 09, 2012 3:57 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Binaries (jars) in our source tree/source
> releases.
>
> > -----Original Message-----
> > From: David Nalley [mailto:david@gnsa.us]
> >
> > [Snip]
> >
> > The thread started because the current system isn't really a system,
> > it's just a folder full of binary jars which we were advised against
> > (and saw another incubator project taken to task by the IPMC). As I
> > said elsewhere, I am not opposed to do something else (Maven, Ivy,
> > Gradle, $somethingelse), but who is going to pick it up, get it
> > running, and educate the rest of us between now and a 4.0 release?
> The
> > proposed intermediate solution is admittedly inelegant, ugly and
> > little better than a shell script, but I doubt there is anyone here
> > who doesn't understand it, and it keeps the build system that does at
> > least build.
> >
> > I personally wouldn't mind picking this up after 4.0 (and learning
> > something new in the process), but just have no cycles at the moment
> > to do so. I am happy for someone else to do it, we just haven't had
> > anyone jumping to own the task.
>
> Yes, I've noticed the lack of people stepping forward ;-)
>
> If it comes down to it, then I will do it. That's going to take me
> away from other release-related tasks, but Chip and John and you seem
> to have most of that under control anyway, so we can probably afford
> it.
>
> If I'm the one who does it, then I'm going to use Gradle unless someone
> tells me otherwise. I have been reading around, and the frustrations
> that I've had with Maven in the past are precisely the ones that Gradle
> was designed to address, and I think that it's a good choice for us. I
> am open to other people throwing their $0.02 into that discussion, but
> they'll have to do it soon!
And now that I read the rest of the thread, I should apologize to Hugo, who did offer some time if we went with Maven.
What do you think, Hugo? Feel like trying Gradle? Prefer to stay with Maven?
Ewan.
RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Ewan Mellor <Ew...@eu.citrix.com>.
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
>
> [Snip]
>
> The thread started because the current system isn't really a system,
> it's just a folder full of binary jars which we were advised against
> (and saw another incubator project taken to task by the IPMC). As I
> said elsewhere, I am not opposed to do something else (Maven, Ivy,
> Gradle, $somethingelse), but who is going to pick it up, get it
> running, and educate the rest of us between now and a 4.0 release? The
> proposed intermediate solution is admittedly inelegant, ugly and
> little better than a shell script, but I doubt there is anyone here
> who doesn't understand it, and it keeps the build system that does at
> least build.
>
> I personally wouldn't mind picking this up after 4.0 (and learning
> something new in the process), but just have no cycles at the moment
> to do so. I am happy for someone else to do it, we just haven't had
> anyone jumping to own the task.
Yes, I've noticed the lack of people stepping forward ;-)
If it comes down to it, then I will do it. That's going to take me away from other release-related tasks, but Chip and John and you seem to have most of that under control anyway, so we can probably afford it.
If I'm the one who does it, then I'm going to use Gradle unless someone tells me otherwise. I have been reading around, and the frustrations that I've had with Maven in the past are precisely the ones that Gradle was designed to address, and I think that it's a good choice for us. I am open to other people throwing their $0.02 into that discussion, but they'll have to do it soon!
Ewan.
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by David Nalley <da...@gnsa.us>.
On Thu, Aug 9, 2012 at 4:21 PM, Ewan Mellor <Ew...@eu.citrix.com> wrote:
>> -----Original Message-----
>> From: David Nalley [mailto:david@gnsa.us]
>> Sent: Wednesday, August 08, 2012 6:17 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [DISCUSS] Binaries (jars) in our source tree/source
>> releases.
>>
>> On Wed, Aug 8, 2012 at 9:07 PM, Brett Porter <br...@apache.org> wrote:
>> >
>> > On 09/08/2012, at 3:01 AM, David Nalley <da...@gnsa.us> wrote:
>> >
>> >> On Tue, Aug 7, 2012 at 11:32 PM, Brett Porter <br...@apache.org>
>> wrote:
>> >>> If this is a direction CloudStack decides it'd like to go, I'm more
>> than happy to help :)
>> >>>
>> >>> - Brett
>> >>
>> >> How much help are you willing to provide? :)
>> >> I am not sure we have a lot of maven expertise around, but maybe
>> this
>> >> provides an even cleaner way to get rid of waf.
>> >
>> >
>> > As you'd note from my being behind responding to several threads, I
>> don't have a lot of bandwidth :) I can help get it started and provide
>> assistance, but someone else would need to be driving it - and as
>> others have noted, someone actively developing the project should
>> understand how it works going forward anyway.
>> >
>> > I wasn't thinking this was something you planned to do before the 4.0
>> release. Is the thought that this might save some of the time on
>> release-related activities, or is it an incremental improvement to
>> consider beyond that?
>> >
>>
>> I think that folks are thinking after the initial release at this
>> point. At least I am.
>
> I was thinking the opposite. Didn't this thread start because the current system isn't fit for purpose? I don't want 4.0 going out with a whole bunch of new complex dependencies, and have users unable to resolve them. That would be a backward step from what they have today.
>
> Ewan.
>
The thread started because the current system isn't really a system,
it's just a folder full of binary jars which we were advised against
(and saw another incubator project taken to task by the IPMC). As I
said elsewhere, I am not opposed to do something else (Maven, Ivy,
Gradle, $somethingelse), but who is going to pick it up, get it
running, and educate the rest of us between now and a 4.0 release? The
proposed intermediate solution is admittedly inelegant, ugly and
little better than a shell script, but I doubt there is anyone here
who doesn't understand it, and it keeps the build system that does at
least build.
I personally wouldn't mind picking this up after 4.0 (and learning
something new in the process), but just have no cycles at the moment
to do so. I am happy for someone else to do it, we just haven't had
anyone jumping to own the task.
--David
RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Ewan Mellor <Ew...@eu.citrix.com>.
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Wednesday, August 08, 2012 6:17 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Binaries (jars) in our source tree/source
> releases.
>
> On Wed, Aug 8, 2012 at 9:07 PM, Brett Porter <br...@apache.org> wrote:
> >
> > On 09/08/2012, at 3:01 AM, David Nalley <da...@gnsa.us> wrote:
> >
> >> On Tue, Aug 7, 2012 at 11:32 PM, Brett Porter <br...@apache.org>
> wrote:
> >>> If this is a direction CloudStack decides it'd like to go, I'm more
> than happy to help :)
> >>>
> >>> - Brett
> >>
> >> How much help are you willing to provide? :)
> >> I am not sure we have a lot of maven expertise around, but maybe
> this
> >> provides an even cleaner way to get rid of waf.
> >
> >
> > As you'd note from my being behind responding to several threads, I
> don't have a lot of bandwidth :) I can help get it started and provide
> assistance, but someone else would need to be driving it - and as
> others have noted, someone actively developing the project should
> understand how it works going forward anyway.
> >
> > I wasn't thinking this was something you planned to do before the 4.0
> release. Is the thought that this might save some of the time on
> release-related activities, or is it an incremental improvement to
> consider beyond that?
> >
>
> I think that folks are thinking after the initial release at this
> point. At least I am.
I was thinking the opposite. Didn't this thread start because the current system isn't fit for purpose? I don't want 4.0 going out with a whole bunch of new complex dependencies, and have users unable to resolve them. That would be a backward step from what they have today.
Ewan.
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Alex Karasulu <ak...@apache.org>.
I can help as well but I'm MIA for the next 3 weeks on vacation. I'll start
looking into the current source tree configuration to see how we can
Mavenize.
On Thu, Aug 9, 2012 at 9:36 AM, Hugo Trippaers <
HTrippaers@schubergphilis.com> wrote:
> Heya,
>
> I have limited amount of experience with Maven, but I'm willing to help
> out here if we decide to go to maven.
>
> @David, This is a good place to get started:
> http://www.sonatype.com/index.php/Support/Books/Maven-The-Complete-Reference This helped me a lot when I was converting projects from ant to maven.
>
> Cheers,
>
> Hugo
>
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Thursday, August 09, 2012 3:17 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
>
> On Wed, Aug 8, 2012 at 9:07 PM, Brett Porter <br...@apache.org> wrote:
> >
> > On 09/08/2012, at 3:01 AM, David Nalley <da...@gnsa.us> wrote:
> >
> >> On Tue, Aug 7, 2012 at 11:32 PM, Brett Porter <br...@apache.org> wrote:
> >>> If this is a direction CloudStack decides it'd like to go, I'm more
> >>> than happy to help :)
> >>>
> >>> - Brett
> >>
> >> How much help are you willing to provide? :) I am not sure we have a
> >> lot of maven expertise around, but maybe this provides an even
> >> cleaner way to get rid of waf.
> >
> >
> > As you'd note from my being behind responding to several threads, I
> don't have a lot of bandwidth :) I can help get it started and provide
> assistance, but someone else would need to be driving it - and as others
> have noted, someone actively developing the project should understand how
> it works going forward anyway.
> >
> > I wasn't thinking this was something you planned to do before the 4.0
> release. Is the thought that this might save some of the time on
> release-related activities, or is it an incremental improvement to consider
> beyond that?
> >
>
> I think that folks are thinking after the initial release at this point.
> At least I am.
>
> Where would someone, who understands ant well enough to get things done
> but has had a historically rocky relationship with maven, go to grok maven?
>
> --David
>
> --David
>
--
Best Regards,
-- Alex
RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
Heya,
I have limited amount of experience with Maven, but I'm willing to help out here if we decide to go to maven.
@David, This is a good place to get started: http://www.sonatype.com/index.php/Support/Books/Maven-The-Complete-Reference This helped me a lot when I was converting projects from ant to maven.
Cheers,
Hugo
-----Original Message-----
From: David Nalley [mailto:david@gnsa.us]
Sent: Thursday, August 09, 2012 3:17 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
On Wed, Aug 8, 2012 at 9:07 PM, Brett Porter <br...@apache.org> wrote:
>
> On 09/08/2012, at 3:01 AM, David Nalley <da...@gnsa.us> wrote:
>
>> On Tue, Aug 7, 2012 at 11:32 PM, Brett Porter <br...@apache.org> wrote:
>>> If this is a direction CloudStack decides it'd like to go, I'm more
>>> than happy to help :)
>>>
>>> - Brett
>>
>> How much help are you willing to provide? :) I am not sure we have a
>> lot of maven expertise around, but maybe this provides an even
>> cleaner way to get rid of waf.
>
>
> As you'd note from my being behind responding to several threads, I don't have a lot of bandwidth :) I can help get it started and provide assistance, but someone else would need to be driving it - and as others have noted, someone actively developing the project should understand how it works going forward anyway.
>
> I wasn't thinking this was something you planned to do before the 4.0 release. Is the thought that this might save some of the time on release-related activities, or is it an incremental improvement to consider beyond that?
>
I think that folks are thinking after the initial release at this point. At least I am.
Where would someone, who understands ant well enough to get things done but has had a historically rocky relationship with maven, go to grok maven?
--David
--David
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by David Nalley <da...@gnsa.us>.
On Wed, Aug 8, 2012 at 9:07 PM, Brett Porter <br...@apache.org> wrote:
>
> On 09/08/2012, at 3:01 AM, David Nalley <da...@gnsa.us> wrote:
>
>> On Tue, Aug 7, 2012 at 11:32 PM, Brett Porter <br...@apache.org> wrote:
>>> If this is a direction CloudStack decides it'd like to go, I'm more than happy to help :)
>>>
>>> - Brett
>>
>> How much help are you willing to provide? :)
>> I am not sure we have a lot of maven expertise around, but maybe this
>> provides an even cleaner way to get rid of waf.
>
>
> As you'd note from my being behind responding to several threads, I don't have a lot of bandwidth :) I can help get it started and provide assistance, but someone else would need to be driving it - and as others have noted, someone actively developing the project should understand how it works going forward anyway.
>
> I wasn't thinking this was something you planned to do before the 4.0 release. Is the thought that this might save some of the time on release-related activities, or is it an incremental improvement to consider beyond that?
>
I think that folks are thinking after the initial release at this
point. At least I am.
Where would someone, who understands ant well enough to get things
done but has had a historically rocky relationship with maven, go to
grok maven?
--David
--David
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Brett Porter <br...@apache.org>.
On 09/08/2012, at 3:01 AM, David Nalley <da...@gnsa.us> wrote:
> On Tue, Aug 7, 2012 at 11:32 PM, Brett Porter <br...@apache.org> wrote:
>> If this is a direction CloudStack decides it'd like to go, I'm more than happy to help :)
>>
>> - Brett
>
> How much help are you willing to provide? :)
> I am not sure we have a lot of maven expertise around, but maybe this
> provides an even cleaner way to get rid of waf.
As you'd note from my being behind responding to several threads, I don't have a lot of bandwidth :) I can help get it started and provide assistance, but someone else would need to be driving it - and as others have noted, someone actively developing the project should understand how it works going forward anyway.
I wasn't thinking this was something you planned to do before the 4.0 release. Is the thought that this might save some of the time on release-related activities, or is it an incremental improvement to consider beyond that?
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
Re: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
tree/source releases.]
Posted by Robert Schweikert <rj...@suse.com>.
On 08/10/2012 03:52 PM, Ewan Mellor wrote:
>> -----Original Message-----
>> From: Robert Schweikert [mailto:rjschwei@suse.com]
>> Sent: 10 August 2012 05:35
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
>> tree/source releases.]
>>
>> On 08/09/2012 09:06 PM, David Nalley wrote:
>>> On Thu, Aug 9, 2012 at 8:47 PM, Ewan Mellor <Ew...@eu.citrix.com>
>> wrote:
>>>>> -----Original Message-----
>>>>> From: Robert Schweikert [mailto:rjschwei@suse.com]
>>>>>
>>>>> [Snip]
>>>>>
>>>>>> * We want to be able to package CloudStack in RPMs and .debs that
>>>>> correctly depend on packages available on the target platform.
>>>>>
>>>>> This is IMHO not a "job" of the project. This is up to the packagers
>>>>> and package maintainers for the various distros. I will maintain
>>>>> openSUSE and SLE builds in OBS and would very much prefer that the
>>>>> build system know nothing about how to build an rpm. We should
>>>>> maintain a "reference spec file" in the source tree and I will
>>>>> contribute to that, but having the build system crank out a .deb or
>>>>> .rpm package is just not the best approach.
>>>>
>>>> David, could you reply to this? You generally have opinions on how
>> packages should be built. I happen to disagree with the comment above, but
>> I'm not a packager so there's a strong chance that I haven't got a clue what
>> I'm talking about, and so I will do whatever people want in this regard.
>>>
>>>
>>> So I think this is a terminology issue, perhaps.
>>> My perspective (with packager hat on)
>>> So assuming we pick $tool to replace ant. I tend to agree - $tool
>>> should not build RPMs or .debs.
>>> There are tools to build RPMs and .debs - (rpmbuild and dpkg) and they
>>> should build the packages. They will call $tool to actually build the
>>> software, but we ought not get into the loop of $tool calling
>>> rpmbuild/dpkg calling $tool.
>>> Also - $tool should have an option for turning dependency resolution
>>> off. (Maven certainly has this, and I am sure other tools do as well.)
>>> Packagers don't want dependency resolution - the guidelines they
>>> operate under don't permit bundled or automagically downloaded
>>> dependencies. Instead those need to be packaged independently and
>>> listed as a requirement (or build requirement) for the package. Any
>>> sane $tool will handle this.
>>>
>>> This doesn't mean that we wouldn't/couldn't automate RPM/deb builds in
>>> something like jenkins. We just don't want another debacle like waf.
>>> Those packages typically will not be as good as distro-maintained
>>> packages in my experience. The distro also won't be kicking out RPMs
>>> for every iteration either, so it's a mixed bag.
>>>
>>> Robert, does this adequately reflect the concerns?
>>
>> Yup,
>
> OK, so concerns reflected. What are we going to do? It sounds like we should:
Nope, not quite
1. Have a script that packages the source into a tarball
> 1. Have the build system produce a tarball of build artifacts.
We want to package the source as a tarball, not the artifacts (see my 1.
above). $tool, from David's message, compiles the code into .jar, .war,
.whatever. In this step the binaries are placed within the source tree
or in a created directory of our choosing relative to the source tree.
$tool has an install option that honors $DESTDIR and than places the
binaries into the appropriate directories under $DESTDIR. Any
directories missing in $DESTDIR get created by $tool
This approach works for both packagers and "install from source" users.
For "install from source" users $DESTDIR is set to /
> 2. Have a separate script that takes the tarball and a spec file and runs rpmbuild to produce an RPM.
> 3. Ditto for .deb.
> 4. Have Jenkins run those scripts, so that we have RPMs and .debs for every build.
> 5. Expect that the distros are going to ignore our packages and make their own.
>
> Is that the summary of it?
Yes, with the exception on point 1 as noted above.
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
Re: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
tree/source releases.]
Posted by Wido den Hollander <wi...@widodh.nl>.
On 08/10/2012 09:52 PM, Ewan Mellor wrote:
>>> So I think this is a terminology issue, perhaps.
>>> My perspective (with packager hat on)
>>> So assuming we pick $tool to replace ant. I tend to agree - $tool
>>> should not build RPMs or .debs.
>>> There are tools to build RPMs and .debs - (rpmbuild and dpkg) and they
>>> should build the packages. They will call $tool to actually build the
>>> software, but we ought not get into the loop of $tool calling
>>> rpmbuild/dpkg calling $tool.
>>> Also - $tool should have an option for turning dependency resolution
>>> off. (Maven certainly has this, and I am sure other tools do as well.)
>>> Packagers don't want dependency resolution - the guidelines they
>>> operate under don't permit bundled or automagically downloaded
>>> dependencies. Instead those need to be packaged independently and
>>> listed as a requirement (or build requirement) for the package. Any
>>> sane $tool will handle this.
>>>
>>> This doesn't mean that we wouldn't/couldn't automate RPM/deb builds in
>>> something like jenkins. We just don't want another debacle like waf.
>>> Those packages typically will not be as good as distro-maintained
>>> packages in my experience. The distro also won't be kicking out RPMs
>>> for every iteration either, so it's a mixed bag.
>>>
>>> Robert, does this adequately reflect the concerns?
>>
>> Yup,
>
> OK, so concerns reflected. What are we going to do? It sounds like we should:
> 1. Have the build system produce a tarball of build artifacts.
> 2. Have a separate script that takes the tarball and a spec file and runs rpmbuild to produce an RPM.
> 3. Ditto for .deb.
No need for deb, that's where the debian/rules file is for.
You should be able to just run:
$ dpkg-buildpackage
That will call debian/rules which can then execute the scripts which
compiles and generates the artifacts.
> 4. Have Jenkins run those scripts, so that we have RPMs and .debs for every build.
> 5. Expect that the distros are going to ignore our packages and make their own.
>
> Is that the summary of it?
>
> Ewan.
>
RE: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
tree/source releases.]
Posted by Ewan Mellor <Ew...@eu.citrix.com>.
> -----Original Message-----
> From: Robert Schweikert [mailto:rjschwei@suse.com]
> Sent: 10 August 2012 05:35
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
> tree/source releases.]
>
> On 08/09/2012 09:06 PM, David Nalley wrote:
> > On Thu, Aug 9, 2012 at 8:47 PM, Ewan Mellor <Ew...@eu.citrix.com>
> wrote:
> >>> -----Original Message-----
> >>> From: Robert Schweikert [mailto:rjschwei@suse.com]
> >>>
> >>> [Snip]
> >>>
> >>>> * We want to be able to package CloudStack in RPMs and .debs that
> >>> correctly depend on packages available on the target platform.
> >>>
> >>> This is IMHO not a "job" of the project. This is up to the packagers
> >>> and package maintainers for the various distros. I will maintain
> >>> openSUSE and SLE builds in OBS and would very much prefer that the
> >>> build system know nothing about how to build an rpm. We should
> >>> maintain a "reference spec file" in the source tree and I will
> >>> contribute to that, but having the build system crank out a .deb or
> >>> .rpm package is just not the best approach.
> >>
> >> David, could you reply to this? You generally have opinions on how
> packages should be built. I happen to disagree with the comment above, but
> I'm not a packager so there's a strong chance that I haven't got a clue what
> I'm talking about, and so I will do whatever people want in this regard.
> >
> >
> > So I think this is a terminology issue, perhaps.
> > My perspective (with packager hat on)
> > So assuming we pick $tool to replace ant. I tend to agree - $tool
> > should not build RPMs or .debs.
> > There are tools to build RPMs and .debs - (rpmbuild and dpkg) and they
> > should build the packages. They will call $tool to actually build the
> > software, but we ought not get into the loop of $tool calling
> > rpmbuild/dpkg calling $tool.
> > Also - $tool should have an option for turning dependency resolution
> > off. (Maven certainly has this, and I am sure other tools do as well.)
> > Packagers don't want dependency resolution - the guidelines they
> > operate under don't permit bundled or automagically downloaded
> > dependencies. Instead those need to be packaged independently and
> > listed as a requirement (or build requirement) for the package. Any
> > sane $tool will handle this.
> >
> > This doesn't mean that we wouldn't/couldn't automate RPM/deb builds in
> > something like jenkins. We just don't want another debacle like waf.
> > Those packages typically will not be as good as distro-maintained
> > packages in my experience. The distro also won't be kicking out RPMs
> > for every iteration either, so it's a mixed bag.
> >
> > Robert, does this adequately reflect the concerns?
>
> Yup,
OK, so concerns reflected. What are we going to do? It sounds like we should:
1. Have the build system produce a tarball of build artifacts.
2. Have a separate script that takes the tarball and a spec file and runs rpmbuild to produce an RPM.
3. Ditto for .deb.
4. Have Jenkins run those scripts, so that we have RPMs and .debs for every build.
5. Expect that the distros are going to ignore our packages and make their own.
Is that the summary of it?
Ewan.
Re: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
tree/source releases.]
Posted by Robert Schweikert <rj...@suse.com>.
On 08/09/2012 09:06 PM, David Nalley wrote:
> On Thu, Aug 9, 2012 at 8:47 PM, Ewan Mellor <Ew...@eu.citrix.com> wrote:
>>> -----Original Message-----
>>> From: Robert Schweikert [mailto:rjschwei@suse.com]
>>>
>>> [Snip]
>>>
>>>> * We want to be able to package CloudStack in RPMs and .debs that
>>> correctly depend on packages available on the target platform.
>>>
>>> This is IMHO not a "job" of the project. This is up to the packagers
>>> and
>>> package maintainers for the various distros. I will maintain openSUSE
>>> and SLE builds in OBS and would very much prefer that the build system
>>> know nothing about how to build an rpm. We should maintain a "reference
>>> spec file" in the source tree and I will contribute to that, but having
>>> the build system crank out a .deb or .rpm package is just not the best
>>> approach.
>>
>> David, could you reply to this? You generally have opinions on how packages should be built. I happen to disagree with the comment above, but I'm not a packager so there's a strong chance that I haven't got a clue what I'm talking about, and so I will do whatever people want in this regard.
>
>
> So I think this is a terminology issue, perhaps.
> My perspective (with packager hat on)
> So assuming we pick $tool to replace ant. I tend to agree - $tool
> should not build RPMs or .debs.
> There are tools to build RPMs and .debs - (rpmbuild and dpkg) and they
> should build the packages. They will call $tool to actually build the
> software, but we ought not get into the loop of $tool calling
> rpmbuild/dpkg calling $tool.
> Also - $tool should have an option for turning dependency resolution
> off. (Maven certainly has this, and I am sure other tools do as well.)
> Packagers don't want dependency resolution - the guidelines they
> operate under don't permit bundled or automagically downloaded
> dependencies. Instead those need to be packaged independently and
> listed as a requirement (or build requirement) for the package. Any
> sane $tool will handle this.
>
> This doesn't mean that we wouldn't/couldn't automate RPM/deb builds in
> something like jenkins. We just don't want another debacle like waf.
> Those packages typically will not be as good as distro-maintained
> packages in my experience. The distro also won't be kicking out RPMs
> for every iteration either, so it's a mixed bag.
>
> Robert, does this adequately reflect the concerns?
Yup,
Thanks,
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
Re: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
tree/source releases.]
Posted by David Nalley <da...@gnsa.us>.
On Thu, Aug 9, 2012 at 8:47 PM, Ewan Mellor <Ew...@eu.citrix.com> wrote:
>> -----Original Message-----
>> From: Robert Schweikert [mailto:rjschwei@suse.com]
>>
>> [Snip]
>>
>> > * We want to be able to package CloudStack in RPMs and .debs that
>> correctly depend on packages available on the target platform.
>>
>> This is IMHO not a "job" of the project. This is up to the packagers
>> and
>> package maintainers for the various distros. I will maintain openSUSE
>> and SLE builds in OBS and would very much prefer that the build system
>> know nothing about how to build an rpm. We should maintain a "reference
>> spec file" in the source tree and I will contribute to that, but having
>> the build system crank out a .deb or .rpm package is just not the best
>> approach.
>
> David, could you reply to this? You generally have opinions on how packages should be built. I happen to disagree with the comment above, but I'm not a packager so there's a strong chance that I haven't got a clue what I'm talking about, and so I will do whatever people want in this regard.
So I think this is a terminology issue, perhaps.
My perspective (with packager hat on)
So assuming we pick $tool to replace ant. I tend to agree - $tool
should not build RPMs or .debs.
There are tools to build RPMs and .debs - (rpmbuild and dpkg) and they
should build the packages. They will call $tool to actually build the
software, but we ought not get into the loop of $tool calling
rpmbuild/dpkg calling $tool.
Also - $tool should have an option for turning dependency resolution
off. (Maven certainly has this, and I am sure other tools do as well.)
Packagers don't want dependency resolution - the guidelines they
operate under don't permit bundled or automagically downloaded
dependencies. Instead those need to be packaged independently and
listed as a requirement (or build requirement) for the package. Any
sane $tool will handle this.
This doesn't mean that we wouldn't/couldn't automate RPM/deb builds in
something like jenkins. We just don't want another debacle like waf.
Those packages typically will not be as good as distro-maintained
packages in my experience. The distro also won't be kicking out RPMs
for every iteration either, so it's a mixed bag.
Robert, does this adequately reflect the concerns?
--David
RE: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
tree/source releases.]
Posted by Ewan Mellor <Ew...@eu.citrix.com>.
> -----Original Message-----
> From: Robert Schweikert [mailto:rjschwei@suse.com]
>
> [Snip]
>
> > * We want to be able to package CloudStack in RPMs and .debs that
> correctly depend on packages available on the target platform.
>
> This is IMHO not a "job" of the project. This is up to the packagers
> and
> package maintainers for the various distros. I will maintain openSUSE
> and SLE builds in OBS and would very much prefer that the build system
> know nothing about how to build an rpm. We should maintain a "reference
> spec file" in the source tree and I will contribute to that, but having
> the build system crank out a .deb or .rpm package is just not the best
> approach.
David, could you reply to this? You generally have opinions on how packages should be built. I happen to disagree with the comment above, but I'm not a packager so there's a strong chance that I haven't got a clue what I'm talking about, and so I will do whatever people want in this regard.
Thanks,
Ewan.
Re: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
tree/source releases.]
Posted by Robert Schweikert <rj...@suse.com>.
On 08/08/2012 06:30 PM, Ewan Mellor wrote:
> We need to push this discussion on build systems to a conclusion. Let me summarize so far.
>
> * We need to be able to build CloudStack in various configurations (support for the range of hypervisors turned on or off, etc).
Yes
>
> * We would like the build tool to be able to get the necessary dependencies automatically, to avoid the user having to download a dozen libraries from all sorts of different places.
Not necessarily. This cannot be a "hard coded" "feature" of the build
tool. For package build systems used by distributions network access is
often not available, thus automatic download of dependencies will fail.
Whatever tool is chosen must be able to handle the "do not download
anything" case.
>
> * Many of our dependencies are version-dependent, so we would want to get a specific version or at the very least have greater-than constraints on the version that is downloaded.
>
> * We want to be able to package CloudStack in RPMs and .debs that correctly depend on packages available on the target platform.
This is IMHO not a "job" of the project. This is up to the packagers and
package maintainers for the various distros. I will maintain openSUSE
and SLE builds in OBS and would very much prefer that the build system
know nothing about how to build an rpm. We should maintain a "reference
spec file" in the source tree and I will contribute to that, but having
the build system crank out a .deb or .rpm package is just not the best
approach.
My $0.02
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
RE: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
tree/source releases.]
Posted by Ewan Mellor <Ew...@eu.citrix.com>.
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Wednesday, August 08, 2012 4:19 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Build systems [was RE: [DISCUSS] Binaries (jars) in our
> source tree/source releases.]
>
>
>
> > -----Original Message-----
> > From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
> > Sent: Wednesday, August 08, 2012 3:31 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Build systems [was RE: [DISCUSS] Binaries (jars) in our
> source
> > tree/source releases.]
> >
> > We need to push this discussion on build systems to a conclusion.
> Let me
> > summarize so far.
> >
> > * We need to be able to build CloudStack in various configurations
> (support
> > for the range of hypervisors turned on or off, etc).
> >
> > * We would like the build tool to be able to get the necessary
> dependencies
> > automatically, to avoid the user having to download a dozen libraries
> from all
> > sorts of different places.
> >
> > * Many of our dependencies are version-dependent, so we would want to
> > get a specific version or at the very least have greater-than
> constraints on the
> > version that is downloaded.
> >
> > * We want to be able to package CloudStack in RPMs and .debs that
> correctly
> > depend on packages available on the target platform.
> >
> >
> > Gradle has been proposed: http://www.gradle.org/. No-one seems to
> know
> > much about it, other than the fact that Hibernate and Spring have
> switched
> > to using it, so it can't be too bad.
> >
> > Maven has been proposed: http://maven.apache.org. We have some
> > expertise offered from Brett Porter (a committer there). It's an
> Apache
> > project, and it's very widely used. We don't know much about it
> though,
> > outside of Brett. I think that there's a legitimate criticism that
> it makes it
> > difficult for packagers, because it hides the system dependencies.
> That
> > might not be reason enough not to use it though. I don't know if
> Gradle
> > suffers from the same problem.
> >
> > Scripting it all ourselves with Ant is a possibility. David started
> this effort on
> > the deps-ctrl branch. This puts us in control of our own destiny,
> and means
> > that we don't have to learn a new tool (or fit in with the way that
> the tool
> > works). It does sound like we're just going to end up re-inventing
> half of
> > Maven that way though.
> >
> >
> > For me, it comes down to developer resources. We need people who
> care
> > about this topic to volunteer some time to get the build working
> smoothly. If
> > those people want to use Maven or Gradle, I don't think anyone else
> is going
> > to object too strongly, because no-one seems to know very much about
> > those tools. At the least, we get the opportunity to try one of
> them, and see
> > if we like it. Nothing is ever set in stone, and if we decide to
> rewrite the build
> > system in time for the 4.1 release, then we can do that.
> >
> > So that's the big question: is someone going to volunteer to get the
> build
> > system tamed for the 4.0 release? It's a dirty job, but someone's
> got to do it,
> > and you'll earn significant kudos if you do!
> >
> Ivy has also been proposed. It's also part of Apache and works within
> Ant and it uses the maven repository. It is important that the build
> system doesn't tax the developer, such as making them setup in a
> certain way.
Yes, sorry, Ivy too. Any volunteers to work on any of these tools?
Ewan.
RE: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
tree/source releases.]
Posted by Alex Huang <Al...@citrix.com>.
> -----Original Message-----
> From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
> Sent: Wednesday, August 08, 2012 3:31 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
> tree/source releases.]
>
> We need to push this discussion on build systems to a conclusion. Let me
> summarize so far.
>
> * We need to be able to build CloudStack in various configurations (support
> for the range of hypervisors turned on or off, etc).
>
> * We would like the build tool to be able to get the necessary dependencies
> automatically, to avoid the user having to download a dozen libraries from all
> sorts of different places.
>
> * Many of our dependencies are version-dependent, so we would want to
> get a specific version or at the very least have greater-than constraints on the
> version that is downloaded.
>
> * We want to be able to package CloudStack in RPMs and .debs that correctly
> depend on packages available on the target platform.
>
>
> Gradle has been proposed: http://www.gradle.org/. No-one seems to know
> much about it, other than the fact that Hibernate and Spring have switched
> to using it, so it can't be too bad.
>
> Maven has been proposed: http://maven.apache.org. We have some
> expertise offered from Brett Porter (a committer there). It's an Apache
> project, and it's very widely used. We don't know much about it though,
> outside of Brett. I think that there's a legitimate criticism that it makes it
> difficult for packagers, because it hides the system dependencies. That
> might not be reason enough not to use it though. I don't know if Gradle
> suffers from the same problem.
>
> Scripting it all ourselves with Ant is a possibility. David started this effort on
> the deps-ctrl branch. This puts us in control of our own destiny, and means
> that we don't have to learn a new tool (or fit in with the way that the tool
> works). It does sound like we're just going to end up re-inventing half of
> Maven that way though.
>
>
> For me, it comes down to developer resources. We need people who care
> about this topic to volunteer some time to get the build working smoothly. If
> those people want to use Maven or Gradle, I don't think anyone else is going
> to object too strongly, because no-one seems to know very much about
> those tools. At the least, we get the opportunity to try one of them, and see
> if we like it. Nothing is ever set in stone, and if we decide to rewrite the build
> system in time for the 4.1 release, then we can do that.
>
> So that's the big question: is someone going to volunteer to get the build
> system tamed for the 4.0 release? It's a dirty job, but someone's got to do it,
> and you'll earn significant kudos if you do!
>
Ivy has also been proposed. It's also part of Apache and works within Ant and it uses the maven repository. It is important that the build system doesn't tax the developer, such as making them setup in a certain way.
--Alex
Build systems [was RE: [DISCUSS] Binaries (jars) in our source
tree/source releases.]
Posted by Ewan Mellor <Ew...@eu.citrix.com>.
We need to push this discussion on build systems to a conclusion. Let me summarize so far.
* We need to be able to build CloudStack in various configurations (support for the range of hypervisors turned on or off, etc).
* We would like the build tool to be able to get the necessary dependencies automatically, to avoid the user having to download a dozen libraries from all sorts of different places.
* Many of our dependencies are version-dependent, so we would want to get a specific version or at the very least have greater-than constraints on the version that is downloaded.
* We want to be able to package CloudStack in RPMs and .debs that correctly depend on packages available on the target platform.
Gradle has been proposed: http://www.gradle.org/. No-one seems to know much about it, other than the fact that Hibernate and Spring have switched to using it, so it can't be too bad.
Maven has been proposed: http://maven.apache.org. We have some expertise offered from Brett Porter (a committer there). It's an Apache project, and it's very widely used. We don't know much about it though, outside of Brett. I think that there's a legitimate criticism that it makes it difficult for packagers, because it hides the system dependencies. That might not be reason enough not to use it though. I don't know if Gradle suffers from the same problem.
Scripting it all ourselves with Ant is a possibility. David started this effort on the deps-ctrl branch. This puts us in control of our own destiny, and means that we don't have to learn a new tool (or fit in with the way that the tool works). It does sound like we're just going to end up re-inventing half of Maven that way though.
For me, it comes down to developer resources. We need people who care about this topic to volunteer some time to get the build working smoothly. If those people want to use Maven or Gradle, I don't think anyone else is going to object too strongly, because no-one seems to know very much about those tools. At the least, we get the opportunity to try one of them, and see if we like it. Nothing is ever set in stone, and if we decide to rewrite the build system in time for the 4.1 release, then we can do that.
So that's the big question: is someone going to volunteer to get the build system tamed for the 4.0 release? It's a dirty job, but someone's got to do it, and you'll earn significant kudos if you do!
Thanks,
Ewan.
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by David Nalley <da...@gnsa.us>.
On Tue, Aug 7, 2012 at 11:32 PM, Brett Porter <br...@apache.org> wrote:
> If this is a direction CloudStack decides it'd like to go, I'm more than happy to help :)
>
> - Brett
How much help are you willing to provide? :)
I am not sure we have a lot of maven expertise around, but maybe this
provides an even cleaner way to get rid of waf.
--David
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Brett Porter <br...@apache.org>.
If this is a direction CloudStack decides it'd like to go, I'm more than happy to help :)
- Brett
On 08/08/2012, at 4:32 AM, Adrian Cole <ad...@gmail.com> wrote:
> +1 (non-binding)
>
> Maven is much easier to support than the current process. Gradle (if ever)
> could be done later. Also, there are folks like me that want to use
> components of cloudstack as libraries w dependencies and the current
> process is not catered towards that. Maven would.
>
> -A
> On Aug 7, 2012 11:27 AM, "Andy Gross" <an...@andygross.org> wrote:
>
>>
>> I've heard good things about Gradle, and "because everyone else is doing
>> it" is rarely a good justification for choosing technologies, but it seems
>> Maven is the de facto standard for most Apache (and other open source)
>> projects. If integrating Cloudstack in other environments or extending
>> Cloudstack are important for developers and users, Maven might be the
>> easiest way to go.
>>
>> Just my .02.
>>
>> - Andy
>>
>>
>>
>> On Aug 3, 2012, at 5:00 PM, Chiradeep Vittal <Ch...@citrix.com>
>> wrote:
>>
>>> Gradle seems to be another
>>> http://www.gradle.org/
>>>
>>>
>>> Since it is allows scripting (as opposed to configuration xml), it could
>>> potentially fulfill the waf role as well.
>>> Anybody have any experience with Gradle?
>>>
>>> On 7/24/12 2:19 PM, "Alex Huang" <Al...@citrix.com> wrote:
>>>
>>>>> Just out of curiosity, have tools like Ivy and maven been ever
>>>>> considered for
>>>>> dependency management?
>>>>
>>>> We are looking at these two tools. Our first thoughts is devs should be
>>>> able to start projects that are tied to other parts of their code so we
>>>> want this to be as flexible as possible. Maven forces too much of a
>>>> structure on to the developers. Ivy seems like the right tool to go
>>>> with. Any comments?
>>>>
>>>> --Alex
>>>>
>>>
>>
>>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Adrian Cole <ad...@gmail.com>.
+1 (non-binding)
Maven is much easier to support than the current process. Gradle (if ever)
could be done later. Also, there are folks like me that want to use
components of cloudstack as libraries w dependencies and the current
process is not catered towards that. Maven would.
-A
On Aug 7, 2012 11:27 AM, "Andy Gross" <an...@andygross.org> wrote:
>
> I've heard good things about Gradle, and "because everyone else is doing
> it" is rarely a good justification for choosing technologies, but it seems
> Maven is the de facto standard for most Apache (and other open source)
> projects. If integrating Cloudstack in other environments or extending
> Cloudstack are important for developers and users, Maven might be the
> easiest way to go.
>
> Just my .02.
>
> - Andy
>
>
>
> On Aug 3, 2012, at 5:00 PM, Chiradeep Vittal <Ch...@citrix.com>
> wrote:
>
> > Gradle seems to be another
> > http://www.gradle.org/
> >
> >
> > Since it is allows scripting (as opposed to configuration xml), it could
> > potentially fulfill the waf role as well.
> > Anybody have any experience with Gradle?
> >
> > On 7/24/12 2:19 PM, "Alex Huang" <Al...@citrix.com> wrote:
> >
> >>> Just out of curiosity, have tools like Ivy and maven been ever
> >>> considered for
> >>> dependency management?
> >>
> >> We are looking at these two tools. Our first thoughts is devs should be
> >> able to start projects that are tied to other parts of their code so we
> >> want this to be as flexible as possible. Maven forces too much of a
> >> structure on to the developers. Ivy seems like the right tool to go
> >> with. Any comments?
> >>
> >> --Alex
> >>
> >
>
>
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Andy Gross <an...@andygross.org>.
I've heard good things about Gradle, and "because everyone else is doing it" is rarely a good justification for choosing technologies, but it seems Maven is the de facto standard for most Apache (and other open source) projects. If integrating Cloudstack in other environments or extending Cloudstack are important for developers and users, Maven might be the easiest way to go.
Just my .02.
- Andy
On Aug 3, 2012, at 5:00 PM, Chiradeep Vittal <Ch...@citrix.com> wrote:
> Gradle seems to be another
> http://www.gradle.org/
>
>
> Since it is allows scripting (as opposed to configuration xml), it could
> potentially fulfill the waf role as well.
> Anybody have any experience with Gradle?
>
> On 7/24/12 2:19 PM, "Alex Huang" <Al...@citrix.com> wrote:
>
>>> Just out of curiosity, have tools like Ivy and maven been ever
>>> considered for
>>> dependency management?
>>
>> We are looking at these two tools. Our first thoughts is devs should be
>> able to start projects that are tied to other parts of their code so we
>> want this to be as flexible as possible. Maven forces too much of a
>> structure on to the developers. Ivy seems like the right tool to go
>> with. Any comments?
>>
>> --Alex
>>
>
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Chiradeep Vittal <Ch...@citrix.com>.
Gradle seems to be another
http://www.gradle.org/
Since it is allows scripting (as opposed to configuration xml), it could
potentially fulfill the waf role as well.
Anybody have any experience with Gradle?
On 7/24/12 2:19 PM, "Alex Huang" <Al...@citrix.com> wrote:
>> Just out of curiosity, have tools like Ivy and maven been ever
>>considered for
>> dependency management?
>
>We are looking at these two tools. Our first thoughts is devs should be
>able to start projects that are tied to other parts of their code so we
>want this to be as flexible as possible. Maven forces too much of a
>structure on to the developers. Ivy seems like the right tool to go
>with. Any comments?
>
>--Alex
>
RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Alex Huang <Al...@citrix.com>.
> Just out of curiosity, have tools like Ivy and maven been ever considered for
> dependency management?
We are looking at these two tools. Our first thoughts is devs should be able to start projects that are tied to other parts of their code so we want this to be as flexible as possible. Maven forces too much of a structure on to the developers. Ivy seems like the right tool to go with. Any comments?
--Alex
Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Posted by Tomoe Sugihara <to...@midokura.jp>.
On Jul 21, 2012, at 4:13 AM, David Nalley <da...@gnsa.us> wrote:
> In one of the OSCON discussions, I noted the recent polite discussion
> re binary jars in source releases on general@incubator. While this is
> apparently tolerated (if you don't mind wearing Nomex), it's
> considered a Bad Thing (TM) generally speaking. Folks suggested that
> we look at how subversion handles this. In short, Subversion has a
> script that downloads all of their dependencies in binary form - and
> they also provide a download for the deps as a tarball.
>
Just out of curiosity, have tools like Ivy and maven been ever considered for dependency management?
Sent from Tomoe's iPhone
> This made me think that perhaps we should add a .gitignore entry for
> .jars in deps/ (and tools/), and write a script that downloads the
> specific versions of the dependencies that we need and depending on
> argument, either places them in the deps/ directory or creates a
> tarball. (hopefully verifying {md5|sha1}sum for each binary along the
> way)
>
> Thoughts? comments? flames?
>
> --David