You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Joseph Ottinger <jo...@enigmastation.com> on 2012/07/23 15:41:12 UTC
Maven build?
I was wondering if it'd be valuable to convert the build for proton to
maven. It's not a "rocket surgery" conversion - it involves moving
files and just a touch of configuration - but at the same time,
there're a lot of benefits.
For better or for worse, there're two dominant build systems in Java;
one is Ant, the other Maven. Maven is winning, because Ant's not
*really* a build system - it's a scripting engine that people use for
builds, while Maven is a build system for realz, yo. Maven means a
regular lifecycle for the build, including explicit testing,
packaging, distribution phases; ant allows those things but doesn't
help you create them, and Maven has standards for them.
Maven's set of tools is also very useful; again, you can do the same
things with Ant if you try, but few developers really care a lot about
having done stuff in the build system. They'd rather focus on the
project, not the build. With Maven, we can slap Arquillian into the
build (for example) and have a full module/integration/system test as
part of the build process, instead of bolting such things into place.
Maven's also cross-language. Proton isn't just Java, of course; Maven
means we can use C++ and still have only one build process (within
certain reason; I'm not claiming Maven's the equivalent of autoconf,
because duh, but then again, autoconf is SOOOOO much fun....)
I'm more than willing to convert the build over if desired; the java
part's already done, I'd still need to do the C++ conversion but it
would be pretty easy.
--
Joseph B. Ottinger
http://enigmastation.com
Ça en vaut la peine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Glen Mazza <gm...@talend.com>.
On 07/25/2012 04:49 PM, Robbie Gemmell wrote:
>> Even philosophically it seemed wrong to me - I want to compile my changes
>> and it goes off looking for any updates to jar files the project or the
>> tool itself might use. That sort of system update seems to me like it
>> should be an entirely separate step.
>>
>>
> I do hear what you are saying here, though I dont object to the extent it
> seems some do. The versions can all be locked down so that its really just
> checking if you changed verisons since the last build. Somthing that our
> main java build has also been doing ever since I added Ivy to it.
>
the -o (offline) option to "mvn install" suppresses the checks for the
latest dependencies.
Glen
--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Robbie Gemmell <ro...@gmail.com>.
On 24 July 2012 18:41, Gordon Sim <gs...@redhat.com> wrote:
> On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
>
>> I wouldn't particularly be in favour of Ant+Ivy for proton.
>>
>
> Any particular reason?
>
>
Because I think more people (excluding some of us, obviously) would prefer
that we use maven instead.
> I must be old or stupid (or both!) because I can't understand why people
> like maven. Admittedly I haven't used it for a long time and the usability
> may have improved. However my recollection is of more frustration than I
> have ever experienced with a 'build system'.
>
>
I think primarily people like it because of the somewhat standardised
lifecyle across various projects mean they can just pick them up more
easily, and an increasing amount of tooling caters to maven usage, making
it easier to integrate a variety of utilities into builds without rolling
your own integration.
I guess there is also the consideration that at some point it became more
popular *because* it became popular (you know, like most things Apple make).
> Even philosophically it seemed wrong to me - I want to compile my changes
> and it goes off looking for any updates to jar files the project or the
> tool itself might use. That sort of system update seems to me like it
> should be an entirely separate step.
>
>
I do hear what you are saying here, though I dont object to the extent it
seems some do. The versions can all be locked down so that its really just
checking if you changed verisons since the last build. Somthing that our
main java build has also been doing ever since I added Ivy to it.
> At present sadly I don't have the time to spend on proton-j that I would
> like, so my opinion should not be given much weight if the preference for
> maven is widespread amongst real users and developers.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.**org<de...@qpid.apache.org>
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Maven build?
Posted by Robbie Gemmell <ro...@gmail.com>.
As others have indicated, many of the points being raised are basically
solvable 'problems'. I really doubt we would be the first project in the
world to use maven that might be included in a distro (or say twenty, for
projects with more widespread reach).
I understand that it might not be the easiest for some of us (I include
myself in that list, spending a good amount of time somewhere that
accessing e.g. maven central doesn't fly, but that didn't stop me moving
our main java build to use it) but that doesn't mean it isn't more
beneficial to the majority of our users.
Robbie
On 24 July 2012 22:19, Rajith Attapattu <ra...@gmail.com> wrote:
> On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger <jo...@enigmastation.com>
> wrote:
> > There *are* ways to turn that off - but the easiest is to run once
>
> While this might solve the developer headaches, it still doesn't solve
> the issue with customers/users and release eng folks (at my employer).
> For some users/customers downloading even once (from unsecured
> repositories) is a definite no.
> This I believe is also an issue with the RPM package process.
> Trying to disable or setting up private repos seems more trouble than
> worth it.
>
> We want to further adoption and IMO Maven seems an unnecessary burden
> for some users.
> A simple build system that does the job seems the best solution.
>
> As Matthew points out, I wonder why we need to jump through so many
> hoops to make this work.
> I want to write code not meddle with my build system.
>
> Besides the current build system works and I'm not aware of any issues.
> So why are we trying to fix something that is not broken ?
>
> To be very blunt, this seems like a waste of time with little or no
> benefit.
> Perhaps adding the bits to make the ant system spit out maven
> artefacts for proton (like we have for Qpid) seems a better
> alternative.
>
> Rajith
>
> > (after which most of the downloads will be finished), and then manage
> > dependency versions accurately; it won't redownload stuff it already
> > has, so if you specify a given dependency, version 6.0.12, it's not
> > going to redownload that unless it actually needs to (in which case
> > you *want* it to.)
> >
> > You can say that you want dependencies with a given version range, but
> > again, these aren't actual "download the world" mechanisms, especially
> > if the libraries don't revise often - they'll check the dependency if
> > they need to, then be done.
> >
> > And maven 2 is no longer in common usage; I don't think we need to
> > compensate for it.
> >
> > On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen <me...@mattgillen.net>
> wrote:
> >> On 07/24/2012 01:41 PM, Gordon Sim wrote:
> >>> On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
> >>>> I wouldn't particularly be in favour of Ant+Ivy for proton.
> >>>
> >>> Any particular reason?
> >>>
> >>> I must be old or stupid (or both!) because I can't understand why
> people
> >>> like maven. Admittedly I haven't used it for a long time and the
> >>> usability may have improved. However my recollection is of more
> >>> frustration than I have ever experienced with a 'build system'.
> >>>
> >>> Even philosophically it seemed wrong to me - I want to compile my
> >>> changes and it goes off looking for any updates to jar files the
> project
> >>> or the tool itself might use. That sort of system update seems to me
> >>> like it should be an entirely separate step.
> >>
> >> There are ways to turn all that stuff off (e.g. force offline mode,
> >> instead distribute all the maven-supplied dependencies as a zip file
> >> that can be used to populate a local-cache repository, etc).
> >>
> >> The the "non-repeatable build" can be solved either by the zip file or
> >> by hosting your own nexus server (which mirrors anything it fetches for
> >> you, thereby ensuring that you have access to it later even if the
> >> upstream goes away).
> >>
> >> But yes, that's all a lot of overhead to just get going compiling code;
> >> it's painful, and IMO not worth it. Oh, and you get strange errors if
> >> you try to build a maven2 project with maven3 (i.e., nothing in the
> >> error mentions that maybe maven3 doesn't grok the old-style config).
> >> I've used maven (involuntarily) for a while now, and will avoid it at
> >> all costs in the future.
> >>
> >> Full disclosure: I'm old enough to wish everything was just done with
> >> gmake...
> >>
> >> Matt
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >
> >
> >
> > --
> > Joseph B. Ottinger
> > http://enigmastation.com
> > Ça en vaut la peine.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Maven build?
Posted by Robbie Gemmell <ro...@gmail.com>.
On 24 July 2012 23:09, Rajith Attapattu <ra...@gmail.com> wrote:
> On Tue, Jul 24, 2012 at 5:32 PM, Joseph Ottinger <jo...@enigmastation.com>
> wrote:
> > Fair enough. IMO, Maven is *the* build system for Java - people behind
> > a security layer haven't proven to be impossible to serve with Maven,
> > and the benefits in lifecycle are well worth it. But it's also not
> > worth the pain if people are anti-Maven, when you *can* get what Maven
> > gets you through the use of judicious scripting.
>
> I don't think it's a case of being anti-Maven.
> It appears there are some serious concerns (within the Qpid community
> and outside world in general) with not very convincing solutions.
>
> Even though I had a terrible experience the last time around, I
> clearly mentioned that I will go with what the majority wants.
> If everybody wants and loves Maven, then I'm not going to stick out
> like a sore thumb and say no :D
>
> My personal opinion is that it's a waste of time, as I'm not so
> convinced of the rewards that warrants a switch from the current build
> system that just works!
> If the current build system is sub optimal, then at least it's a
> different story.
>
> Rajith
>
I think saying the current system 'just works' is overlooking the extensive
amount of tweaking that has to be done to it in order to get even simple
things working. For example, look at all the cruft present in it to alow
things like running Findbugs, Cobertura etc. Things like can literally be
checkbox additions on a Jenkins/Sonar job for people using maven, but which
we instead have to manually put together in our Ant build via tens or
hundreds of lines in the build, up to and including custom downloads before
I finally bit the bullet and introduced Ivy. It is increasingly annoying
missing out on easy addition of useful tools and having to maintain that
kind of stuff (and if you look at the commits to the build system, I'm
fairly sure I will have the majority of them in the last 2-3 years).
Our (generated) maven artifacts are often broken between each release and
require manual fixing, because we have that wonderful break between the Ant
build and the custom generation of those poms. I am the only person who has
ever bothered to maintain them or publish them (hands up how many people
genuinely know how to even do those things without going and figuring it
out now?) after a user contributed a patch [which itself rotted on JIRA for
months] to fix some of the issues with them since they had been left to rot
after the generation script was added to settle a discussion and then never
used.
I imagine some reading this could be surprised at this point to know that
out of all of my colleagues (who I note are mostly steering clear of this
discussion, despite how much they like maven and want us to switch
wholesale...) I am usually the one who most downplays any desire to
actually switch the main qpid java build over to maven. I think maven has
too many advantages not to use if starting something fresh now, but I can
see that even the numerous benefits are a hard sell again the time required
to make the change and the fact so many of the Qpid developers seem to hate
it with a passion. At least some of those points don't apply to proton
though, which is why I would like to see us have a maven build for it.
Robbie
>
> > On Tue, Jul 24, 2012 at 5:19 PM, Rajith Attapattu <ra...@gmail.com>
> wrote:
> >> On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger <
> joeo@enigmastation.com> wrote:
> >>> There *are* ways to turn that off - but the easiest is to run once
> >>
> >> While this might solve the developer headaches, it still doesn't solve
> >> the issue with customers/users and release eng folks (at my employer).
> >> For some users/customers downloading even once (from unsecured
> >> repositories) is a definite no.
> >> This I believe is also an issue with the RPM package process.
> >> Trying to disable or setting up private repos seems more trouble than
> worth it.
> >>
> >> We want to further adoption and IMO Maven seems an unnecessary burden
> >> for some users.
> >> A simple build system that does the job seems the best solution.
> >>
> >> As Matthew points out, I wonder why we need to jump through so many
> >> hoops to make this work.
> >> I want to write code not meddle with my build system.
> >>
> >> Besides the current build system works and I'm not aware of any issues.
> >> So why are we trying to fix something that is not broken ?
> >>
> >> To be very blunt, this seems like a waste of time with little or no
> benefit.
> >> Perhaps adding the bits to make the ant system spit out maven
> >> artefacts for proton (like we have for Qpid) seems a better
> >> alternative.
> >>
> >> Rajith
> >>
> >>> (after which most of the downloads will be finished), and then manage
> >>> dependency versions accurately; it won't redownload stuff it already
> >>> has, so if you specify a given dependency, version 6.0.12, it's not
> >>> going to redownload that unless it actually needs to (in which case
> >>> you *want* it to.)
> >>>
> >>> You can say that you want dependencies with a given version range, but
> >>> again, these aren't actual "download the world" mechanisms, especially
> >>> if the libraries don't revise often - they'll check the dependency if
> >>> they need to, then be done.
> >>>
> >>> And maven 2 is no longer in common usage; I don't think we need to
> >>> compensate for it.
> >>>
> >>> On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen <me...@mattgillen.net>
> wrote:
> >>>> On 07/24/2012 01:41 PM, Gordon Sim wrote:
> >>>>> On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
> >>>>>> I wouldn't particularly be in favour of Ant+Ivy for proton.
> >>>>>
> >>>>> Any particular reason?
> >>>>>
> >>>>> I must be old or stupid (or both!) because I can't understand why
> people
> >>>>> like maven. Admittedly I haven't used it for a long time and the
> >>>>> usability may have improved. However my recollection is of more
> >>>>> frustration than I have ever experienced with a 'build system'.
> >>>>>
> >>>>> Even philosophically it seemed wrong to me - I want to compile my
> >>>>> changes and it goes off looking for any updates to jar files the
> project
> >>>>> or the tool itself might use. That sort of system update seems to me
> >>>>> like it should be an entirely separate step.
> >>>>
> >>>> There are ways to turn all that stuff off (e.g. force offline mode,
> >>>> instead distribute all the maven-supplied dependencies as a zip file
> >>>> that can be used to populate a local-cache repository, etc).
> >>>>
> >>>> The the "non-repeatable build" can be solved either by the zip file or
> >>>> by hosting your own nexus server (which mirrors anything it fetches
> for
> >>>> you, thereby ensuring that you have access to it later even if the
> >>>> upstream goes away).
> >>>>
> >>>> But yes, that's all a lot of overhead to just get going compiling
> code;
> >>>> it's painful, and IMO not worth it. Oh, and you get strange errors if
> >>>> you try to build a maven2 project with maven3 (i.e., nothing in the
> >>>> error mentions that maybe maven3 doesn't grok the old-style config).
> >>>> I've used maven (involuntarily) for a while now, and will avoid it at
> >>>> all costs in the future.
> >>>>
> >>>> Full disclosure: I'm old enough to wish everything was just done with
> >>>> gmake...
> >>>>
> >>>> Matt
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >>>> For additional commands, e-mail: dev-help@qpid.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Joseph B. Ottinger
> >>> http://enigmastation.com
> >>> Ça en vaut la peine.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >>> For additional commands, e-mail: dev-help@qpid.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >
> >
> >
> > --
> > Joseph B. Ottinger
> > http://enigmastation.com
> > Ça en vaut la peine.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Maven build?
Posted by Hiram Chirino <hi...@hiramchirino.com>.
So my 2 cents..
If your goal is to produce libraries which get published to maven central,
then it's much easier to use maven than to use Ivy. Several project at the
ASF have mastered that art of releasing using maven, so if Qpid feels timid
about how to best set it up / use it, then reach out.
Maven release builds are always reproducible to for me. Recent maven
releases have helped in this respect. The new releases warn you when you
do things which could lead to non-reproducible builds. A good example is
making sure you specify versions for your maven plugins. Also I don't mind
the long initial download times maven has. It's only the first time you
use a project and I'd rather maven download all the build tools need to do
a reproducible build than me figuring out what I need to install and setup.
Usually maven can download the internet faster than it takes folks to
setup all the build requirements in a complex builds. Thats why I use
maven.
The fact is that the proton build is about as vanilla as a build gets.
There's no code generation, and no extra tools to post-process stuff.
This guy will only need a small pom to get it working properly. Since the
Apache wide parent pom configures all the ASF standard plugins, your
release builds will: deploy the jar, a source jar, asc sigs for the
artifacts, and md5s. Plus it will be deploying to the ASF nexus instance.
Nexus handles staging and locking down build for voting. Finally, once
the vote passes, it's a couple of clicks in nexus to release it to maven
central. Then the rest of the world can enjoy downloading your part of
the internet :)
Regards,
Hiram
On Tue, Jul 24, 2012 at 6:09 PM, Rajith Attapattu <ra...@gmail.com>wrote:
> On Tue, Jul 24, 2012 at 5:32 PM, Joseph Ottinger <jo...@enigmastation.com>
> wrote:
> > Fair enough. IMO, Maven is *the* build system for Java - people behind
> > a security layer haven't proven to be impossible to serve with Maven,
> > and the benefits in lifecycle are well worth it. But it's also not
> > worth the pain if people are anti-Maven, when you *can* get what Maven
> > gets you through the use of judicious scripting.
>
> I don't think it's a case of being anti-Maven.
> It appears there are some serious concerns (within the Qpid community
> and outside world in general) with not very convincing solutions.
>
> Even though I had a terrible experience the last time around, I
> clearly mentioned that I will go with what the majority wants.
> If everybody wants and loves Maven, then I'm not going to stick out
> like a sore thumb and say no :D
>
> My personal opinion is that it's a waste of time, as I'm not so
> convinced of the rewards that warrants a switch from the current build
> system that just works!
> If the current build system is sub optimal, then at least it's a
> different story.
>
> Rajith
>
> > On Tue, Jul 24, 2012 at 5:19 PM, Rajith Attapattu <ra...@gmail.com>
> wrote:
> >> On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger <
> joeo@enigmastation.com> wrote:
> >>> There *are* ways to turn that off - but the easiest is to run once
> >>
> >> While this might solve the developer headaches, it still doesn't solve
> >> the issue with customers/users and release eng folks (at my employer).
> >> For some users/customers downloading even once (from unsecured
> >> repositories) is a definite no.
> >> This I believe is also an issue with the RPM package process.
> >> Trying to disable or setting up private repos seems more trouble than
> worth it.
> >>
> >> We want to further adoption and IMO Maven seems an unnecessary burden
> >> for some users.
> >> A simple build system that does the job seems the best solution.
> >>
> >> As Matthew points out, I wonder why we need to jump through so many
> >> hoops to make this work.
> >> I want to write code not meddle with my build system.
> >>
> >> Besides the current build system works and I'm not aware of any issues.
> >> So why are we trying to fix something that is not broken ?
> >>
> >> To be very blunt, this seems like a waste of time with little or no
> benefit.
> >> Perhaps adding the bits to make the ant system spit out maven
> >> artefacts for proton (like we have for Qpid) seems a better
> >> alternative.
> >>
> >> Rajith
> >>
> >>> (after which most of the downloads will be finished), and then manage
> >>> dependency versions accurately; it won't redownload stuff it already
> >>> has, so if you specify a given dependency, version 6.0.12, it's not
> >>> going to redownload that unless it actually needs to (in which case
> >>> you *want* it to.)
> >>>
> >>> You can say that you want dependencies with a given version range, but
> >>> again, these aren't actual "download the world" mechanisms, especially
> >>> if the libraries don't revise often - they'll check the dependency if
> >>> they need to, then be done.
> >>>
> >>> And maven 2 is no longer in common usage; I don't think we need to
> >>> compensate for it.
> >>>
> >>> On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen <me...@mattgillen.net>
> wrote:
> >>>> On 07/24/2012 01:41 PM, Gordon Sim wrote:
> >>>>> On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
> >>>>>> I wouldn't particularly be in favour of Ant+Ivy for proton.
> >>>>>
> >>>>> Any particular reason?
> >>>>>
> >>>>> I must be old or stupid (or both!) because I can't understand why
> people
> >>>>> like maven. Admittedly I haven't used it for a long time and the
> >>>>> usability may have improved. However my recollection is of more
> >>>>> frustration than I have ever experienced with a 'build system'.
> >>>>>
> >>>>> Even philosophically it seemed wrong to me - I want to compile my
> >>>>> changes and it goes off looking for any updates to jar files the
> project
> >>>>> or the tool itself might use. That sort of system update seems to me
> >>>>> like it should be an entirely separate step.
> >>>>
> >>>> There are ways to turn all that stuff off (e.g. force offline mode,
> >>>> instead distribute all the maven-supplied dependencies as a zip file
> >>>> that can be used to populate a local-cache repository, etc).
> >>>>
> >>>> The the "non-repeatable build" can be solved either by the zip file or
> >>>> by hosting your own nexus server (which mirrors anything it fetches
> for
> >>>> you, thereby ensuring that you have access to it later even if the
> >>>> upstream goes away).
> >>>>
> >>>> But yes, that's all a lot of overhead to just get going compiling
> code;
> >>>> it's painful, and IMO not worth it. Oh, and you get strange errors if
> >>>> you try to build a maven2 project with maven3 (i.e., nothing in the
> >>>> error mentions that maybe maven3 doesn't grok the old-style config).
> >>>> I've used maven (involuntarily) for a while now, and will avoid it at
> >>>> all costs in the future.
> >>>>
> >>>> Full disclosure: I'm old enough to wish everything was just done with
> >>>> gmake...
> >>>>
> >>>> Matt
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >>>> For additional commands, e-mail: dev-help@qpid.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Joseph B. Ottinger
> >>> http://enigmastation.com
> >>> Ça en vaut la peine.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >>> For additional commands, e-mail: dev-help@qpid.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >
> >
> >
> > --
> > Joseph B. Ottinger
> > http://enigmastation.com
> > Ça en vaut la peine.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
--
**
*Hiram Chirino*
*Software Fellow | FuseSource Corp.*
*chirino@fusesource.com | fusesource.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
*
*
*
*
Re: Maven build?
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Jul 24, 2012 at 5:32 PM, Joseph Ottinger <jo...@enigmastation.com> wrote:
> Fair enough. IMO, Maven is *the* build system for Java - people behind
> a security layer haven't proven to be impossible to serve with Maven,
> and the benefits in lifecycle are well worth it. But it's also not
> worth the pain if people are anti-Maven, when you *can* get what Maven
> gets you through the use of judicious scripting.
I don't think it's a case of being anti-Maven.
It appears there are some serious concerns (within the Qpid community
and outside world in general) with not very convincing solutions.
Even though I had a terrible experience the last time around, I
clearly mentioned that I will go with what the majority wants.
If everybody wants and loves Maven, then I'm not going to stick out
like a sore thumb and say no :D
My personal opinion is that it's a waste of time, as I'm not so
convinced of the rewards that warrants a switch from the current build
system that just works!
If the current build system is sub optimal, then at least it's a
different story.
Rajith
> On Tue, Jul 24, 2012 at 5:19 PM, Rajith Attapattu <ra...@gmail.com> wrote:
>> On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger <jo...@enigmastation.com> wrote:
>>> There *are* ways to turn that off - but the easiest is to run once
>>
>> While this might solve the developer headaches, it still doesn't solve
>> the issue with customers/users and release eng folks (at my employer).
>> For some users/customers downloading even once (from unsecured
>> repositories) is a definite no.
>> This I believe is also an issue with the RPM package process.
>> Trying to disable or setting up private repos seems more trouble than worth it.
>>
>> We want to further adoption and IMO Maven seems an unnecessary burden
>> for some users.
>> A simple build system that does the job seems the best solution.
>>
>> As Matthew points out, I wonder why we need to jump through so many
>> hoops to make this work.
>> I want to write code not meddle with my build system.
>>
>> Besides the current build system works and I'm not aware of any issues.
>> So why are we trying to fix something that is not broken ?
>>
>> To be very blunt, this seems like a waste of time with little or no benefit.
>> Perhaps adding the bits to make the ant system spit out maven
>> artefacts for proton (like we have for Qpid) seems a better
>> alternative.
>>
>> Rajith
>>
>>> (after which most of the downloads will be finished), and then manage
>>> dependency versions accurately; it won't redownload stuff it already
>>> has, so if you specify a given dependency, version 6.0.12, it's not
>>> going to redownload that unless it actually needs to (in which case
>>> you *want* it to.)
>>>
>>> You can say that you want dependencies with a given version range, but
>>> again, these aren't actual "download the world" mechanisms, especially
>>> if the libraries don't revise often - they'll check the dependency if
>>> they need to, then be done.
>>>
>>> And maven 2 is no longer in common usage; I don't think we need to
>>> compensate for it.
>>>
>>> On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen <me...@mattgillen.net> wrote:
>>>> On 07/24/2012 01:41 PM, Gordon Sim wrote:
>>>>> On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
>>>>>> I wouldn't particularly be in favour of Ant+Ivy for proton.
>>>>>
>>>>> Any particular reason?
>>>>>
>>>>> I must be old or stupid (or both!) because I can't understand why people
>>>>> like maven. Admittedly I haven't used it for a long time and the
>>>>> usability may have improved. However my recollection is of more
>>>>> frustration than I have ever experienced with a 'build system'.
>>>>>
>>>>> Even philosophically it seemed wrong to me - I want to compile my
>>>>> changes and it goes off looking for any updates to jar files the project
>>>>> or the tool itself might use. That sort of system update seems to me
>>>>> like it should be an entirely separate step.
>>>>
>>>> There are ways to turn all that stuff off (e.g. force offline mode,
>>>> instead distribute all the maven-supplied dependencies as a zip file
>>>> that can be used to populate a local-cache repository, etc).
>>>>
>>>> The the "non-repeatable build" can be solved either by the zip file or
>>>> by hosting your own nexus server (which mirrors anything it fetches for
>>>> you, thereby ensuring that you have access to it later even if the
>>>> upstream goes away).
>>>>
>>>> But yes, that's all a lot of overhead to just get going compiling code;
>>>> it's painful, and IMO not worth it. Oh, and you get strange errors if
>>>> you try to build a maven2 project with maven3 (i.e., nothing in the
>>>> error mentions that maybe maven3 doesn't grok the old-style config).
>>>> I've used maven (involuntarily) for a while now, and will avoid it at
>>>> all costs in the future.
>>>>
>>>> Full disclosure: I'm old enough to wish everything was just done with
>>>> gmake...
>>>>
>>>> Matt
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Joseph B. Ottinger
>>> http://enigmastation.com
>>> Ça en vaut la peine.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
>
>
> --
> Joseph B. Ottinger
> http://enigmastation.com
> Ça en vaut la peine.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Joseph Ottinger <jo...@enigmastation.com>.
Fair enough. IMO, Maven is *the* build system for Java - people behind
a security layer haven't proven to be impossible to serve with Maven,
and the benefits in lifecycle are well worth it. But it's also not
worth the pain if people are anti-Maven, when you *can* get what Maven
gets you through the use of judicious scripting.
On Tue, Jul 24, 2012 at 5:19 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger <jo...@enigmastation.com> wrote:
>> There *are* ways to turn that off - but the easiest is to run once
>
> While this might solve the developer headaches, it still doesn't solve
> the issue with customers/users and release eng folks (at my employer).
> For some users/customers downloading even once (from unsecured
> repositories) is a definite no.
> This I believe is also an issue with the RPM package process.
> Trying to disable or setting up private repos seems more trouble than worth it.
>
> We want to further adoption and IMO Maven seems an unnecessary burden
> for some users.
> A simple build system that does the job seems the best solution.
>
> As Matthew points out, I wonder why we need to jump through so many
> hoops to make this work.
> I want to write code not meddle with my build system.
>
> Besides the current build system works and I'm not aware of any issues.
> So why are we trying to fix something that is not broken ?
>
> To be very blunt, this seems like a waste of time with little or no benefit.
> Perhaps adding the bits to make the ant system spit out maven
> artefacts for proton (like we have for Qpid) seems a better
> alternative.
>
> Rajith
>
>> (after which most of the downloads will be finished), and then manage
>> dependency versions accurately; it won't redownload stuff it already
>> has, so if you specify a given dependency, version 6.0.12, it's not
>> going to redownload that unless it actually needs to (in which case
>> you *want* it to.)
>>
>> You can say that you want dependencies with a given version range, but
>> again, these aren't actual "download the world" mechanisms, especially
>> if the libraries don't revise often - they'll check the dependency if
>> they need to, then be done.
>>
>> And maven 2 is no longer in common usage; I don't think we need to
>> compensate for it.
>>
>> On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen <me...@mattgillen.net> wrote:
>>> On 07/24/2012 01:41 PM, Gordon Sim wrote:
>>>> On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
>>>>> I wouldn't particularly be in favour of Ant+Ivy for proton.
>>>>
>>>> Any particular reason?
>>>>
>>>> I must be old or stupid (or both!) because I can't understand why people
>>>> like maven. Admittedly I haven't used it for a long time and the
>>>> usability may have improved. However my recollection is of more
>>>> frustration than I have ever experienced with a 'build system'.
>>>>
>>>> Even philosophically it seemed wrong to me - I want to compile my
>>>> changes and it goes off looking for any updates to jar files the project
>>>> or the tool itself might use. That sort of system update seems to me
>>>> like it should be an entirely separate step.
>>>
>>> There are ways to turn all that stuff off (e.g. force offline mode,
>>> instead distribute all the maven-supplied dependencies as a zip file
>>> that can be used to populate a local-cache repository, etc).
>>>
>>> The the "non-repeatable build" can be solved either by the zip file or
>>> by hosting your own nexus server (which mirrors anything it fetches for
>>> you, thereby ensuring that you have access to it later even if the
>>> upstream goes away).
>>>
>>> But yes, that's all a lot of overhead to just get going compiling code;
>>> it's painful, and IMO not worth it. Oh, and you get strange errors if
>>> you try to build a maven2 project with maven3 (i.e., nothing in the
>>> error mentions that maybe maven3 doesn't grok the old-style config).
>>> I've used maven (involuntarily) for a while now, and will avoid it at
>>> all costs in the future.
>>>
>>> Full disclosure: I'm old enough to wish everything was just done with
>>> gmake...
>>>
>>> Matt
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>
>>
>>
>>
>> --
>> Joseph B. Ottinger
>> http://enigmastation.com
>> Ça en vaut la peine.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
--
Joseph B. Ottinger
http://enigmastation.com
Ça en vaut la peine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Oleksandr Rudyy <or...@gmail.com>.
Hi,
It looks for me that the structure of proton-j sub-project will be
quite simple and will not require the creation of complicated building
scripts similar to what we have in qpid java tree right now. I believe
that we can have 2 building systems for proton-j at least on first
stages of the project. That would allow developers to use either ant
or maven depending from their preferences.
IMHO, it should not be big overhead for the project.
Kind Regards,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by "Weston M. Price" <wp...@redhat.com>.
On Jul 24, 2012, at 5:19 PM, Rajith Attapattu wrote:
> On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger <jo...@enigmastation.com> wrote:
>> There *are* ways to turn that off - but the easiest is to run once
>
> While this might solve the developer headaches, it still doesn't solve
> the issue with customers/users and release eng folks (at my employer).
> For some users/customers downloading even once (from unsecured
> repositories) is a definite no.
> This I believe is also an issue with the RPM package process.
> Trying to disable or setting up private repos seems more trouble than worth it.
>
> We want to further adoption and IMO Maven seems an unnecessary burden
> for some users.
> A simple build system that does the job seems the best solution.
>
> As Matthew points out, I wonder why we need to jump through so many
> hoops to make this work.
> I want to write code not meddle with my build system.
>
> Besides the current build system works and I'm not aware of any issues.
> So why are we trying to fix something that is not broken ?
>
> To be very blunt, this seems like a waste of time with little or no benefit.
> Perhaps adding the bits to make the ant system spit out maven
> artefacts for proton (like we have for Qpid) seems a better
> alternative.
+1
>
> Rajith
>
>> (after which most of the downloads will be finished), and then manage
>> dependency versions accurately; it won't redownload stuff it already
>> has, so if you specify a given dependency, version 6.0.12, it's not
>> going to redownload that unless it actually needs to (in which case
>> you *want* it to.)
>>
>> You can say that you want dependencies with a given version range, but
>> again, these aren't actual "download the world" mechanisms, especially
>> if the libraries don't revise often - they'll check the dependency if
>> they need to, then be done.
>>
>> And maven 2 is no longer in common usage; I don't think we need to
>> compensate for it.
>>
>> On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen <me...@mattgillen.net> wrote:
>>> On 07/24/2012 01:41 PM, Gordon Sim wrote:
>>>> On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
>>>>> I wouldn't particularly be in favour of Ant+Ivy for proton.
>>>>
>>>> Any particular reason?
>>>>
>>>> I must be old or stupid (or both!) because I can't understand why people
>>>> like maven. Admittedly I haven't used it for a long time and the
>>>> usability may have improved. However my recollection is of more
>>>> frustration than I have ever experienced with a 'build system'.
>>>>
>>>> Even philosophically it seemed wrong to me - I want to compile my
>>>> changes and it goes off looking for any updates to jar files the project
>>>> or the tool itself might use. That sort of system update seems to me
>>>> like it should be an entirely separate step.
>>>
>>> There are ways to turn all that stuff off (e.g. force offline mode,
>>> instead distribute all the maven-supplied dependencies as a zip file
>>> that can be used to populate a local-cache repository, etc).
>>>
>>> The the "non-repeatable build" can be solved either by the zip file or
>>> by hosting your own nexus server (which mirrors anything it fetches for
>>> you, thereby ensuring that you have access to it later even if the
>>> upstream goes away).
>>>
>>> But yes, that's all a lot of overhead to just get going compiling code;
>>> it's painful, and IMO not worth it. Oh, and you get strange errors if
>>> you try to build a maven2 project with maven3 (i.e., nothing in the
>>> error mentions that maybe maven3 doesn't grok the old-style config).
>>> I've used maven (involuntarily) for a while now, and will avoid it at
>>> all costs in the future.
>>>
>>> Full disclosure: I'm old enough to wish everything was just done with
>>> gmake...
>>>
>>> Matt
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>
>>
>>
>>
>> --
>> Joseph B. Ottinger
>> http://enigmastation.com
>> Ça en vaut la peine.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger <jo...@enigmastation.com> wrote:
> There *are* ways to turn that off - but the easiest is to run once
While this might solve the developer headaches, it still doesn't solve
the issue with customers/users and release eng folks (at my employer).
For some users/customers downloading even once (from unsecured
repositories) is a definite no.
This I believe is also an issue with the RPM package process.
Trying to disable or setting up private repos seems more trouble than worth it.
We want to further adoption and IMO Maven seems an unnecessary burden
for some users.
A simple build system that does the job seems the best solution.
As Matthew points out, I wonder why we need to jump through so many
hoops to make this work.
I want to write code not meddle with my build system.
Besides the current build system works and I'm not aware of any issues.
So why are we trying to fix something that is not broken ?
To be very blunt, this seems like a waste of time with little or no benefit.
Perhaps adding the bits to make the ant system spit out maven
artefacts for proton (like we have for Qpid) seems a better
alternative.
Rajith
> (after which most of the downloads will be finished), and then manage
> dependency versions accurately; it won't redownload stuff it already
> has, so if you specify a given dependency, version 6.0.12, it's not
> going to redownload that unless it actually needs to (in which case
> you *want* it to.)
>
> You can say that you want dependencies with a given version range, but
> again, these aren't actual "download the world" mechanisms, especially
> if the libraries don't revise often - they'll check the dependency if
> they need to, then be done.
>
> And maven 2 is no longer in common usage; I don't think we need to
> compensate for it.
>
> On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen <me...@mattgillen.net> wrote:
>> On 07/24/2012 01:41 PM, Gordon Sim wrote:
>>> On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
>>>> I wouldn't particularly be in favour of Ant+Ivy for proton.
>>>
>>> Any particular reason?
>>>
>>> I must be old or stupid (or both!) because I can't understand why people
>>> like maven. Admittedly I haven't used it for a long time and the
>>> usability may have improved. However my recollection is of more
>>> frustration than I have ever experienced with a 'build system'.
>>>
>>> Even philosophically it seemed wrong to me - I want to compile my
>>> changes and it goes off looking for any updates to jar files the project
>>> or the tool itself might use. That sort of system update seems to me
>>> like it should be an entirely separate step.
>>
>> There are ways to turn all that stuff off (e.g. force offline mode,
>> instead distribute all the maven-supplied dependencies as a zip file
>> that can be used to populate a local-cache repository, etc).
>>
>> The the "non-repeatable build" can be solved either by the zip file or
>> by hosting your own nexus server (which mirrors anything it fetches for
>> you, thereby ensuring that you have access to it later even if the
>> upstream goes away).
>>
>> But yes, that's all a lot of overhead to just get going compiling code;
>> it's painful, and IMO not worth it. Oh, and you get strange errors if
>> you try to build a maven2 project with maven3 (i.e., nothing in the
>> error mentions that maybe maven3 doesn't grok the old-style config).
>> I've used maven (involuntarily) for a while now, and will avoid it at
>> all costs in the future.
>>
>> Full disclosure: I'm old enough to wish everything was just done with
>> gmake...
>>
>> Matt
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
>
>
> --
> Joseph B. Ottinger
> http://enigmastation.com
> Ça en vaut la peine.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Joseph Ottinger <jo...@enigmastation.com>.
There *are* ways to turn that off - but the easiest is to run once
(after which most of the downloads will be finished), and then manage
dependency versions accurately; it won't redownload stuff it already
has, so if you specify a given dependency, version 6.0.12, it's not
going to redownload that unless it actually needs to (in which case
you *want* it to.)
You can say that you want dependencies with a given version range, but
again, these aren't actual "download the world" mechanisms, especially
if the libraries don't revise often - they'll check the dependency if
they need to, then be done.
And maven 2 is no longer in common usage; I don't think we need to
compensate for it.
On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen <me...@mattgillen.net> wrote:
> On 07/24/2012 01:41 PM, Gordon Sim wrote:
>> On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
>>> I wouldn't particularly be in favour of Ant+Ivy for proton.
>>
>> Any particular reason?
>>
>> I must be old or stupid (or both!) because I can't understand why people
>> like maven. Admittedly I haven't used it for a long time and the
>> usability may have improved. However my recollection is of more
>> frustration than I have ever experienced with a 'build system'.
>>
>> Even philosophically it seemed wrong to me - I want to compile my
>> changes and it goes off looking for any updates to jar files the project
>> or the tool itself might use. That sort of system update seems to me
>> like it should be an entirely separate step.
>
> There are ways to turn all that stuff off (e.g. force offline mode,
> instead distribute all the maven-supplied dependencies as a zip file
> that can be used to populate a local-cache repository, etc).
>
> The the "non-repeatable build" can be solved either by the zip file or
> by hosting your own nexus server (which mirrors anything it fetches for
> you, thereby ensuring that you have access to it later even if the
> upstream goes away).
>
> But yes, that's all a lot of overhead to just get going compiling code;
> it's painful, and IMO not worth it. Oh, and you get strange errors if
> you try to build a maven2 project with maven3 (i.e., nothing in the
> error mentions that maybe maven3 doesn't grok the old-style config).
> I've used maven (involuntarily) for a while now, and will avoid it at
> all costs in the future.
>
> Full disclosure: I'm old enough to wish everything was just done with
> gmake...
>
> Matt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
--
Joseph B. Ottinger
http://enigmastation.com
Ça en vaut la peine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Matthew Gillen <me...@mattgillen.net>.
On 07/24/2012 01:41 PM, Gordon Sim wrote:
> On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
>> I wouldn't particularly be in favour of Ant+Ivy for proton.
>
> Any particular reason?
>
> I must be old or stupid (or both!) because I can't understand why people
> like maven. Admittedly I haven't used it for a long time and the
> usability may have improved. However my recollection is of more
> frustration than I have ever experienced with a 'build system'.
>
> Even philosophically it seemed wrong to me - I want to compile my
> changes and it goes off looking for any updates to jar files the project
> or the tool itself might use. That sort of system update seems to me
> like it should be an entirely separate step.
There are ways to turn all that stuff off (e.g. force offline mode,
instead distribute all the maven-supplied dependencies as a zip file
that can be used to populate a local-cache repository, etc).
The the "non-repeatable build" can be solved either by the zip file or
by hosting your own nexus server (which mirrors anything it fetches for
you, thereby ensuring that you have access to it later even if the
upstream goes away).
But yes, that's all a lot of overhead to just get going compiling code;
it's painful, and IMO not worth it. Oh, and you get strange errors if
you try to build a maven2 project with maven3 (i.e., nothing in the
error mentions that maybe maven3 doesn't grok the old-style config).
I've used maven (involuntarily) for a while now, and will avoid it at
all costs in the future.
Full disclosure: I'm old enough to wish everything was just done with
gmake...
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Gordon Sim <gs...@redhat.com>.
On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
> I wouldn't particularly be in favour of Ant+Ivy for proton.
Any particular reason?
I must be old or stupid (or both!) because I can't understand why people
like maven. Admittedly I haven't used it for a long time and the
usability may have improved. However my recollection is of more
frustration than I have ever experienced with a 'build system'.
Even philosophically it seemed wrong to me - I want to compile my
changes and it goes off looking for any updates to jar files the project
or the tool itself might use. That sort of system update seems to me
like it should be an entirely separate step.
At present sadly I don't have the time to spend on proton-j that I would
like, so my opinion should not be given much weight if the preference
for maven is widespread amongst real users and developers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Jul 24, 2012 at 1:50 PM, Weston M. Price <wp...@redhat.com> wrote:
> On Jul 24, 2012, at 1:24 PM, Rafael Schloming wrote:
>
>> Sorry to jump in late on this thread. I'm totally for making proton as
>> easy to consume as possible, so I definitely support making maven
>> artifacts available, but I also had a very bad experience with maven
>> last time I was exposed to it.
>>
>> As I recall there were two major issues, one being non repeatable builds
>> due to a variety of reasons, some of which may have been addressed since
>> then.
>>
>> The other big issue we had was with integration of the maven built
>> software into other environments. I don't know if this has changed, but
>> maven didn't really have a concept of configuration. Rather than
>> adapting the software to build within the host environment, e.g. use
>> supplied libraries and/or leave out optional portions of the build,
>> maven takes the approach of adapting the host environment to fit the
>> software, i.e. download whatever is necessary to build, even if that set
>> of stuff is incompatible with the host environment. This actually makes
>> it very difficult to integrate maven built software into controlled
>> build environments, e.g. distros or release builds.
>>
>> Given that it's pretty straightforward to get ant to play well with
>> others (including maven) and a core goal of proton is to be super easy
>> to integrate, I'd be concerned that moving to a maven build might prove
>> to be a barrier to broader integration. I'd certainly like to understand
>> what it's impact will be e.g. on maintaining proton in distros or
>> getting it to build in embedded environments.
>>
> +1
> My tentative endorsement for maven had more to do with being a good citizen than any inherent approval.
>> --Rafael
I've already stated my concerns as a developer. Let me also state a
few concerns from the packaging/distribution side.
The issue of repeatable builds and downloading updates from
repositories that are outside of our control is really a big concern
from a packaging pov.
Certain customers/users who would want to build Qpid from source does
not like to download bits from all over the internet for security
reasons.
In some ways moving to maven may infact be a barrier for adoption due
to the above issue.
Ant on the other hand can spit out maven artefacts.
As long as we produce maven artefacts, projects that use maven could
easily use proton and Qpid.
That to me seems like a win-win situation.
Regards,
Rajith
>>
>> On Mon, 2012-07-23 at 16:47 -0400, Joseph Ottinger wrote:
>>> Well, what I'll do then is convert proton's build to maven and submit that
>>> as a patch attached to an issue, then I'll look into what it would take to
>>> get qpid-java's build to maven, too. If those diffs pass inspection, good.
>>> If not, we can fix them or ignore them as desired.
>>>
>>> On Monday, July 23, 2012, Robbie Gemmell <ro...@gmail.com> wrote:
>>>> I wouldn't particularly be in favour of Ant+Ivy for proton. I did that for
>>>> the main Qpid java stuff because it allowed a long overdue clean up of our
>>>> repo and didn't involve changing the entire build system (if it had, I
>>>> woudn't have done it), but if I was starting afresh I'd be using Maven for
>>>> that too.
>>>>
>>>> Robbie
>>>>
>>>> On 23 July 2012 20:54, Weston M. Price <wp...@redhat.com> wrote:
>>>>
>>>>>
>>>>> On Jul 23, 2012, at 3:22 PM, Robbie Gemmell wrote:
>>>>>
>>>>>> I think its safe to say Maven is a lot more mature now than it was back
>>>>>> then, and is much more widely used. The issues that existed then
>>>>> certainly
>>>>>> don't seem to bother the massive numbers of large projects using it
>>>>> today.
>>>>>>
>>>>>> Given how popular it is with other developers as a build system and as
>>> a
>>>>>> route for their projects to consume artifacts, I'd generally be in
>>> favour
>>>>>> of making the switch if only to be nice citizens to prospective users
>>> of
>>>>>> proton.
>>>>> +1
>>>>> Notwithstanding my personal dislike of maven, it seems to have become the
>>>>> de facto standard. Although, we could use Ivy+Ant like we do in the
>>> current
>>>>> code base. This would be my personal preference but the maven thing has
>>>>> truly become a 'if you can't beat them, join them' thing for me so I
>>> would
>>>>> be fine either way.
>>>>>
>>>>> Weston
>>>>>
>>>>>>
>>>>>> Robbie
>>>>>> On 23 Jul 2012 20:00, "Rajith Attapattu" <ra...@gmail.com> wrote:
>>>>>>
>>>>>>> I personally prefer the simple ant based system.
>>>>>>> The last time Qpid used maven it was horrible :) .. it downloaded the
>>>>>>> entire universe into my computer.
>>>>>>> We also had trouble doing repeatable builds.
>>>>>>> Now I don't know if it was due to the way Maven was used or if it was
>>>>>>> an issue with Maven itself.
>>>>>>> I've never had issues with ant before --- it always worked for me :)
>>>>>>> With Maven it wasn't particularly a pleasant experience.
>>>>>>> So I'm biased there and please don't blame me for that.
>>>>>>>
>>>>>>> Having said that, I'm not going to make a fuss, if the majority wants
>>>>>>> Maven !
>>>>>>>
>>>>>>> One more thing. Converting the build system to maven is fine, but who
>>>>>>> ever does that should also take the responsibility of maintaining it
>>>>>>> as well :)
>>>>>>> To a certain extent that was also an issue with the previous attempt
>>>>>>> at using maven.
>>>>>>>
>>>>>>> Rajith
>>>>>>>
>>>>>>> On Mon, Jul 23, 2012 at 2:38 PM, Oleksandr Rudyy <or...@gmail.com>
>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I completely support Joseph's proposal to use maven as building
>>> system
>>>>>>>> for j-poton module.
>>>>>>>>
>>>>>>>> Kind Regards,
>>>>>>>> Alex
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>>>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by "Weston M. Price" <wp...@redhat.com>.
On Jul 24, 2012, at 1:24 PM, Rafael Schloming wrote:
> Sorry to jump in late on this thread. I'm totally for making proton as
> easy to consume as possible, so I definitely support making maven
> artifacts available, but I also had a very bad experience with maven
> last time I was exposed to it.
>
> As I recall there were two major issues, one being non repeatable builds
> due to a variety of reasons, some of which may have been addressed since
> then.
>
> The other big issue we had was with integration of the maven built
> software into other environments. I don't know if this has changed, but
> maven didn't really have a concept of configuration. Rather than
> adapting the software to build within the host environment, e.g. use
> supplied libraries and/or leave out optional portions of the build,
> maven takes the approach of adapting the host environment to fit the
> software, i.e. download whatever is necessary to build, even if that set
> of stuff is incompatible with the host environment. This actually makes
> it very difficult to integrate maven built software into controlled
> build environments, e.g. distros or release builds.
>
> Given that it's pretty straightforward to get ant to play well with
> others (including maven) and a core goal of proton is to be super easy
> to integrate, I'd be concerned that moving to a maven build might prove
> to be a barrier to broader integration. I'd certainly like to understand
> what it's impact will be e.g. on maintaining proton in distros or
> getting it to build in embedded environments.
>
+1
My tentative endorsement for maven had more to do with being a good citizen than any inherent approval.
> --Rafael
>
> On Mon, 2012-07-23 at 16:47 -0400, Joseph Ottinger wrote:
>> Well, what I'll do then is convert proton's build to maven and submit that
>> as a patch attached to an issue, then I'll look into what it would take to
>> get qpid-java's build to maven, too. If those diffs pass inspection, good.
>> If not, we can fix them or ignore them as desired.
>>
>> On Monday, July 23, 2012, Robbie Gemmell <ro...@gmail.com> wrote:
>>> I wouldn't particularly be in favour of Ant+Ivy for proton. I did that for
>>> the main Qpid java stuff because it allowed a long overdue clean up of our
>>> repo and didn't involve changing the entire build system (if it had, I
>>> woudn't have done it), but if I was starting afresh I'd be using Maven for
>>> that too.
>>>
>>> Robbie
>>>
>>> On 23 July 2012 20:54, Weston M. Price <wp...@redhat.com> wrote:
>>>
>>>>
>>>> On Jul 23, 2012, at 3:22 PM, Robbie Gemmell wrote:
>>>>
>>>>> I think its safe to say Maven is a lot more mature now than it was back
>>>>> then, and is much more widely used. The issues that existed then
>>>> certainly
>>>>> don't seem to bother the massive numbers of large projects using it
>>>> today.
>>>>>
>>>>> Given how popular it is with other developers as a build system and as
>> a
>>>>> route for their projects to consume artifacts, I'd generally be in
>> favour
>>>>> of making the switch if only to be nice citizens to prospective users
>> of
>>>>> proton.
>>>> +1
>>>> Notwithstanding my personal dislike of maven, it seems to have become the
>>>> de facto standard. Although, we could use Ivy+Ant like we do in the
>> current
>>>> code base. This would be my personal preference but the maven thing has
>>>> truly become a 'if you can't beat them, join them' thing for me so I
>> would
>>>> be fine either way.
>>>>
>>>> Weston
>>>>
>>>>>
>>>>> Robbie
>>>>> On 23 Jul 2012 20:00, "Rajith Attapattu" <ra...@gmail.com> wrote:
>>>>>
>>>>>> I personally prefer the simple ant based system.
>>>>>> The last time Qpid used maven it was horrible :) .. it downloaded the
>>>>>> entire universe into my computer.
>>>>>> We also had trouble doing repeatable builds.
>>>>>> Now I don't know if it was due to the way Maven was used or if it was
>>>>>> an issue with Maven itself.
>>>>>> I've never had issues with ant before --- it always worked for me :)
>>>>>> With Maven it wasn't particularly a pleasant experience.
>>>>>> So I'm biased there and please don't blame me for that.
>>>>>>
>>>>>> Having said that, I'm not going to make a fuss, if the majority wants
>>>>>> Maven !
>>>>>>
>>>>>> One more thing. Converting the build system to maven is fine, but who
>>>>>> ever does that should also take the responsibility of maintaining it
>>>>>> as well :)
>>>>>> To a certain extent that was also an issue with the previous attempt
>>>>>> at using maven.
>>>>>>
>>>>>> Rajith
>>>>>>
>>>>>> On Mon, Jul 23, 2012 at 2:38 PM, Oleksandr Rudyy <or...@gmail.com>
>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I completely support Joseph's proposal to use maven as building
>> system
>>>>>>> for j-poton module.
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>> Alex
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>>>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>>
>>>>
>>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Rafael Schloming <ra...@redhat.com>.
Sorry to jump in late on this thread. I'm totally for making proton as
easy to consume as possible, so I definitely support making maven
artifacts available, but I also had a very bad experience with maven
last time I was exposed to it.
As I recall there were two major issues, one being non repeatable builds
due to a variety of reasons, some of which may have been addressed since
then.
The other big issue we had was with integration of the maven built
software into other environments. I don't know if this has changed, but
maven didn't really have a concept of configuration. Rather than
adapting the software to build within the host environment, e.g. use
supplied libraries and/or leave out optional portions of the build,
maven takes the approach of adapting the host environment to fit the
software, i.e. download whatever is necessary to build, even if that set
of stuff is incompatible with the host environment. This actually makes
it very difficult to integrate maven built software into controlled
build environments, e.g. distros or release builds.
Given that it's pretty straightforward to get ant to play well with
others (including maven) and a core goal of proton is to be super easy
to integrate, I'd be concerned that moving to a maven build might prove
to be a barrier to broader integration. I'd certainly like to understand
what it's impact will be e.g. on maintaining proton in distros or
getting it to build in embedded environments.
--Rafael
On Mon, 2012-07-23 at 16:47 -0400, Joseph Ottinger wrote:
> Well, what I'll do then is convert proton's build to maven and submit that
> as a patch attached to an issue, then I'll look into what it would take to
> get qpid-java's build to maven, too. If those diffs pass inspection, good.
> If not, we can fix them or ignore them as desired.
>
> On Monday, July 23, 2012, Robbie Gemmell <ro...@gmail.com> wrote:
> > I wouldn't particularly be in favour of Ant+Ivy for proton. I did that for
> > the main Qpid java stuff because it allowed a long overdue clean up of our
> > repo and didn't involve changing the entire build system (if it had, I
> > woudn't have done it), but if I was starting afresh I'd be using Maven for
> > that too.
> >
> > Robbie
> >
> > On 23 July 2012 20:54, Weston M. Price <wp...@redhat.com> wrote:
> >
> >>
> >> On Jul 23, 2012, at 3:22 PM, Robbie Gemmell wrote:
> >>
> >> > I think its safe to say Maven is a lot more mature now than it was back
> >> > then, and is much more widely used. The issues that existed then
> >> certainly
> >> > don't seem to bother the massive numbers of large projects using it
> >> today.
> >> >
> >> > Given how popular it is with other developers as a build system and as
> a
> >> > route for their projects to consume artifacts, I'd generally be in
> favour
> >> > of making the switch if only to be nice citizens to prospective users
> of
> >> > proton.
> >> +1
> >> Notwithstanding my personal dislike of maven, it seems to have become the
> >> de facto standard. Although, we could use Ivy+Ant like we do in the
> current
> >> code base. This would be my personal preference but the maven thing has
> >> truly become a 'if you can't beat them, join them' thing for me so I
> would
> >> be fine either way.
> >>
> >> Weston
> >>
> >> >
> >> > Robbie
> >> > On 23 Jul 2012 20:00, "Rajith Attapattu" <ra...@gmail.com> wrote:
> >> >
> >> >> I personally prefer the simple ant based system.
> >> >> The last time Qpid used maven it was horrible :) .. it downloaded the
> >> >> entire universe into my computer.
> >> >> We also had trouble doing repeatable builds.
> >> >> Now I don't know if it was due to the way Maven was used or if it was
> >> >> an issue with Maven itself.
> >> >> I've never had issues with ant before --- it always worked for me :)
> >> >> With Maven it wasn't particularly a pleasant experience.
> >> >> So I'm biased there and please don't blame me for that.
> >> >>
> >> >> Having said that, I'm not going to make a fuss, if the majority wants
> >> >> Maven !
> >> >>
> >> >> One more thing. Converting the build system to maven is fine, but who
> >> >> ever does that should also take the responsibility of maintaining it
> >> >> as well :)
> >> >> To a certain extent that was also an issue with the previous attempt
> >> >> at using maven.
> >> >>
> >> >> Rajith
> >> >>
> >> >> On Mon, Jul 23, 2012 at 2:38 PM, Oleksandr Rudyy <or...@gmail.com>
> >> wrote:
> >> >>> Hi,
> >> >>>
> >> >>> I completely support Joseph's proposal to use maven as building
> system
> >> >>> for j-poton module.
> >> >>>
> >> >>> Kind Regards,
> >> >>> Alex
> >> >>>
> >> >>> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> >>> For additional commands, e-mail: dev-help@qpid.apache.org
> >> >>>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >> >>
> >> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >>
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Joseph Ottinger <jo...@enigmastation.com>.
Well, what I'll do then is convert proton's build to maven and submit that
as a patch attached to an issue, then I'll look into what it would take to
get qpid-java's build to maven, too. If those diffs pass inspection, good.
If not, we can fix them or ignore them as desired.
On Monday, July 23, 2012, Robbie Gemmell <ro...@gmail.com> wrote:
> I wouldn't particularly be in favour of Ant+Ivy for proton. I did that for
> the main Qpid java stuff because it allowed a long overdue clean up of our
> repo and didn't involve changing the entire build system (if it had, I
> woudn't have done it), but if I was starting afresh I'd be using Maven for
> that too.
>
> Robbie
>
> On 23 July 2012 20:54, Weston M. Price <wp...@redhat.com> wrote:
>
>>
>> On Jul 23, 2012, at 3:22 PM, Robbie Gemmell wrote:
>>
>> > I think its safe to say Maven is a lot more mature now than it was back
>> > then, and is much more widely used. The issues that existed then
>> certainly
>> > don't seem to bother the massive numbers of large projects using it
>> today.
>> >
>> > Given how popular it is with other developers as a build system and as
a
>> > route for their projects to consume artifacts, I'd generally be in
favour
>> > of making the switch if only to be nice citizens to prospective users
of
>> > proton.
>> +1
>> Notwithstanding my personal dislike of maven, it seems to have become the
>> de facto standard. Although, we could use Ivy+Ant like we do in the
current
>> code base. This would be my personal preference but the maven thing has
>> truly become a 'if you can't beat them, join them' thing for me so I
would
>> be fine either way.
>>
>> Weston
>>
>> >
>> > Robbie
>> > On 23 Jul 2012 20:00, "Rajith Attapattu" <ra...@gmail.com> wrote:
>> >
>> >> I personally prefer the simple ant based system.
>> >> The last time Qpid used maven it was horrible :) .. it downloaded the
>> >> entire universe into my computer.
>> >> We also had trouble doing repeatable builds.
>> >> Now I don't know if it was due to the way Maven was used or if it was
>> >> an issue with Maven itself.
>> >> I've never had issues with ant before --- it always worked for me :)
>> >> With Maven it wasn't particularly a pleasant experience.
>> >> So I'm biased there and please don't blame me for that.
>> >>
>> >> Having said that, I'm not going to make a fuss, if the majority wants
>> >> Maven !
>> >>
>> >> One more thing. Converting the build system to maven is fine, but who
>> >> ever does that should also take the responsibility of maintaining it
>> >> as well :)
>> >> To a certain extent that was also an issue with the previous attempt
>> >> at using maven.
>> >>
>> >> Rajith
>> >>
>> >> On Mon, Jul 23, 2012 at 2:38 PM, Oleksandr Rudyy <or...@gmail.com>
>> wrote:
>> >>> Hi,
>> >>>
>> >>> I completely support Joseph's proposal to use maven as building
system
>> >>> for j-poton module.
>> >>>
>> >>> Kind Regards,
>> >>> Alex
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> >>> For additional commands, e-mail: dev-help@qpid.apache.org
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> >> For additional commands, e-mail: dev-help@qpid.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
>
--
Joseph B. Ottinger
http://enigmastation.com
Ça en vaut la peine.
Re: Maven build?
Posted by Robbie Gemmell <ro...@gmail.com>.
I wouldn't particularly be in favour of Ant+Ivy for proton. I did that for
the main Qpid java stuff because it allowed a long overdue clean up of our
repo and didn't involve changing the entire build system (if it had, I
woudn't have done it), but if I was starting afresh I'd be using Maven for
that too.
Robbie
On 23 July 2012 20:54, Weston M. Price <wp...@redhat.com> wrote:
>
> On Jul 23, 2012, at 3:22 PM, Robbie Gemmell wrote:
>
> > I think its safe to say Maven is a lot more mature now than it was back
> > then, and is much more widely used. The issues that existed then
> certainly
> > don't seem to bother the massive numbers of large projects using it
> today.
> >
> > Given how popular it is with other developers as a build system and as a
> > route for their projects to consume artifacts, I'd generally be in favour
> > of making the switch if only to be nice citizens to prospective users of
> > proton.
> +1
> Notwithstanding my personal dislike of maven, it seems to have become the
> de facto standard. Although, we could use Ivy+Ant like we do in the current
> code base. This would be my personal preference but the maven thing has
> truly become a 'if you can't beat them, join them' thing for me so I would
> be fine either way.
>
> Weston
>
> >
> > Robbie
> > On 23 Jul 2012 20:00, "Rajith Attapattu" <ra...@gmail.com> wrote:
> >
> >> I personally prefer the simple ant based system.
> >> The last time Qpid used maven it was horrible :) .. it downloaded the
> >> entire universe into my computer.
> >> We also had trouble doing repeatable builds.
> >> Now I don't know if it was due to the way Maven was used or if it was
> >> an issue with Maven itself.
> >> I've never had issues with ant before --- it always worked for me :)
> >> With Maven it wasn't particularly a pleasant experience.
> >> So I'm biased there and please don't blame me for that.
> >>
> >> Having said that, I'm not going to make a fuss, if the majority wants
> >> Maven !
> >>
> >> One more thing. Converting the build system to maven is fine, but who
> >> ever does that should also take the responsibility of maintaining it
> >> as well :)
> >> To a certain extent that was also an issue with the previous attempt
> >> at using maven.
> >>
> >> Rajith
> >>
> >> On Mon, Jul 23, 2012 at 2:38 PM, Oleksandr Rudyy <or...@gmail.com>
> wrote:
> >>> Hi,
> >>>
> >>> I completely support Joseph's proposal to use maven as building system
> >>> for j-poton module.
> >>>
> >>> Kind Regards,
> >>> Alex
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >>> For additional commands, e-mail: dev-help@qpid.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Maven build?
Posted by "Weston M. Price" <wp...@redhat.com>.
On Jul 23, 2012, at 3:22 PM, Robbie Gemmell wrote:
> I think its safe to say Maven is a lot more mature now than it was back
> then, and is much more widely used. The issues that existed then certainly
> don't seem to bother the massive numbers of large projects using it today.
>
> Given how popular it is with other developers as a build system and as a
> route for their projects to consume artifacts, I'd generally be in favour
> of making the switch if only to be nice citizens to prospective users of
> proton.
+1
Notwithstanding my personal dislike of maven, it seems to have become the de facto standard. Although, we could use Ivy+Ant like we do in the current code base. This would be my personal preference but the maven thing has truly become a 'if you can't beat them, join them' thing for me so I would be fine either way.
Weston
>
> Robbie
> On 23 Jul 2012 20:00, "Rajith Attapattu" <ra...@gmail.com> wrote:
>
>> I personally prefer the simple ant based system.
>> The last time Qpid used maven it was horrible :) .. it downloaded the
>> entire universe into my computer.
>> We also had trouble doing repeatable builds.
>> Now I don't know if it was due to the way Maven was used or if it was
>> an issue with Maven itself.
>> I've never had issues with ant before --- it always worked for me :)
>> With Maven it wasn't particularly a pleasant experience.
>> So I'm biased there and please don't blame me for that.
>>
>> Having said that, I'm not going to make a fuss, if the majority wants
>> Maven !
>>
>> One more thing. Converting the build system to maven is fine, but who
>> ever does that should also take the responsibility of maintaining it
>> as well :)
>> To a certain extent that was also an issue with the previous attempt
>> at using maven.
>>
>> Rajith
>>
>> On Mon, Jul 23, 2012 at 2:38 PM, Oleksandr Rudyy <or...@gmail.com> wrote:
>>> Hi,
>>>
>>> I completely support Joseph's proposal to use maven as building system
>>> for j-poton module.
>>>
>>> Kind Regards,
>>> Alex
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Robbie Gemmell <ro...@gmail.com>.
I think its safe to say Maven is a lot more mature now than it was back
then, and is much more widely used. The issues that existed then certainly
don't seem to bother the massive numbers of large projects using it today.
Given how popular it is with other developers as a build system and as a
route for their projects to consume artifacts, I'd generally be in favour
of making the switch if only to be nice citizens to prospective users of
proton.
Robbie
On 23 Jul 2012 20:00, "Rajith Attapattu" <ra...@gmail.com> wrote:
> I personally prefer the simple ant based system.
> The last time Qpid used maven it was horrible :) .. it downloaded the
> entire universe into my computer.
> We also had trouble doing repeatable builds.
> Now I don't know if it was due to the way Maven was used or if it was
> an issue with Maven itself.
> I've never had issues with ant before --- it always worked for me :)
> With Maven it wasn't particularly a pleasant experience.
> So I'm biased there and please don't blame me for that.
>
> Having said that, I'm not going to make a fuss, if the majority wants
> Maven !
>
> One more thing. Converting the build system to maven is fine, but who
> ever does that should also take the responsibility of maintaining it
> as well :)
> To a certain extent that was also an issue with the previous attempt
> at using maven.
>
> Rajith
>
> On Mon, Jul 23, 2012 at 2:38 PM, Oleksandr Rudyy <or...@gmail.com> wrote:
> > Hi,
> >
> > I completely support Joseph's proposal to use maven as building system
> > for j-poton module.
> >
> > Kind Regards,
> > Alex
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Maven build?
Posted by Joseph Ottinger <jo...@enigmastation.com>.
Well, I have no problem maintaining the maven build, if that's the path chosen.
The "download the universe" thing can be a concern - but that's an
artifact of the build being what it is. Maven itself is pretty small;
it has a set of plugins for most of its actual operations, so when you
tell it to package something, it needs to grab the plugins it uses for
the operations it performs to fulfill an action. It's usually a
one-time thing; most of the operations are pretty static.
On Mon, Jul 23, 2012 at 3:00 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> I personally prefer the simple ant based system.
> The last time Qpid used maven it was horrible :) .. it downloaded the
> entire universe into my computer.
> We also had trouble doing repeatable builds.
> Now I don't know if it was due to the way Maven was used or if it was
> an issue with Maven itself.
> I've never had issues with ant before --- it always worked for me :)
> With Maven it wasn't particularly a pleasant experience.
> So I'm biased there and please don't blame me for that.
>
> Having said that, I'm not going to make a fuss, if the majority wants Maven !
>
> One more thing. Converting the build system to maven is fine, but who
> ever does that should also take the responsibility of maintaining it
> as well :)
> To a certain extent that was also an issue with the previous attempt
> at using maven.
>
> Rajith
>
> On Mon, Jul 23, 2012 at 2:38 PM, Oleksandr Rudyy <or...@gmail.com> wrote:
>> Hi,
>>
>> I completely support Joseph's proposal to use maven as building system
>> for j-poton module.
>>
>> Kind Regards,
>> Alex
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
--
Joseph B. Ottinger
http://enigmastation.com
Ça en vaut la peine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Rajith Attapattu <ra...@gmail.com>.
I personally prefer the simple ant based system.
The last time Qpid used maven it was horrible :) .. it downloaded the
entire universe into my computer.
We also had trouble doing repeatable builds.
Now I don't know if it was due to the way Maven was used or if it was
an issue with Maven itself.
I've never had issues with ant before --- it always worked for me :)
With Maven it wasn't particularly a pleasant experience.
So I'm biased there and please don't blame me for that.
Having said that, I'm not going to make a fuss, if the majority wants Maven !
One more thing. Converting the build system to maven is fine, but who
ever does that should also take the responsibility of maintaining it
as well :)
To a certain extent that was also an issue with the previous attempt
at using maven.
Rajith
On Mon, Jul 23, 2012 at 2:38 PM, Oleksandr Rudyy <or...@gmail.com> wrote:
> Hi,
>
> I completely support Joseph's proposal to use maven as building system
> for j-poton module.
>
> Kind Regards,
> Alex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Oleksandr Rudyy <or...@gmail.com>.
Hi,
I completely support Joseph's proposal to use maven as building system
for j-poton module.
Kind Regards,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Joseph Ottinger <jo...@enigmastation.com>.
Well, a lot of Java coders pretend Java doesn't exist, so that was okay too.
To be clear: personally, I'm happy with cmake being used for C, etc.;
I think idiom is important.
Using the maven directory structures is a no-brainer at the very
least. Using Maven has other benefits beyond the directory structures,
but if people prefer ant, there's nothing especially wrong with that.
However, Maven means we don't have to go out of our way to construct
artifacts for use by end users with Maven, which will definitely be
the standard for Java developers. (See Ivy, which allows you to use
maven-style dependencies in Ant builds; you'd want to construct
artifacts with Maven compatibility even for ant!)
On Mon, Jul 23, 2012 at 12:06 PM, Rafael Schloming <ra...@redhat.com> wrote:
> On Mon, 2012-07-23 at 12:04 -0400, Rafael Schloming wrote:
>> The proton/proton-j directory is the top level entry point for Java and
>> it's laid out pretty much as any Java developer would expect. (At least
>> that is the idea modulo ant vs maven.) If you only care about the Java
>> code you can check out the codebase from there and pretend Java doesn't
>> exist.
>
> Ahem, that should read "pretend the C code doesn't exist." ;-)
>
> --Rafael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
--
Joseph B. Ottinger
http://enigmastation.com
Ça en vaut la peine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Rafael Schloming <ra...@redhat.com>.
On Mon, 2012-07-23 at 12:04 -0400, Rafael Schloming wrote:
> The proton/proton-j directory is the top level entry point for Java and
> it's laid out pretty much as any Java developer would expect. (At least
> that is the idea modulo ant vs maven.) If you only care about the Java
> code you can check out the codebase from there and pretend Java doesn't
> exist.
Ahem, that should read "pretend the C code doesn't exist." ;-)
--Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Rafael Schloming <ra...@redhat.com>.
We don't actually try to build all the source code with a single build
system. In the interests of being as friendly as possible to various
different user communities, we have multiple points in the tree that can
be viewed as "top level entry points":
The proton/proton-c directory is the top level entry point for C and
it's laid out pretty much how any C developer would expect a C project
to be laid out. If you only care about the C code and its various
language bindings you can check out the codebase from there and pretend
Java doesn't exist.
The proton/proton-j directory is the top level entry point for Java and
it's laid out pretty much as any Java developer would expect. (At least
that is the idea modulo ant vs maven.) If you only care about the Java
code you can check out the codebase from there and pretend Java doesn't
exist.
The proton/tests directory is the test suit for validating that both
implementations behave the same, and it too can be checked out
independently.
The top level proton dir is really the project entry point as project
developers are expected to keep proton-j and proton-c consistent with
each other and so would always check out and test against both
implementations. Right now there is just a barebones config.sh to aid in
this, but I expect we'll probably add scripts for invoking the java and
C build systems and running all the tests against the artifacts.
--Rafael
On Mon, 2012-07-23 at 15:40 +0000, Steve Huston wrote:
> Exactly. Thank you, Andrew.
>
> On 7/23/12 11:40 AM, "Andrew Stitcher" <as...@redhat.com> wrote:
>
> >On Mon, 2012-07-23 at 11:26 -0400, Joseph Ottinger wrote:
> >> What do you mean? I don't know what the proton devs would need to do
> >> to support cmake -- the deliverables would be the same regardless of
> >> the build system, or can be made to be identical.
> >
> >I think you are talking at cross purposes here.
> >
> >Steve is pointing out that those who work on the code base would have to
> >learn to use another build system - maven. Irrespective of whether you
> >can make its output identical to the cmake it's another thing to learn
> >to work productively on the code.
> >
> >I think that Joseph is talking about the impact on developers who are
> >using that code.
> >
> >I would point out that in the case of C code using maven brings a very
> >large build dependency (java) that isn't the case for cmake. Obviously
> >if you are building java that isn't important since you must have java
> >anyway.
> >
> >Also cmake is not just a build system, in the comparison with autotools
> >(autoconf and automake) it covers both configuration and build. I don't
> >know enough about maven to know if it similarly covers both of these
> >roles. I'd suspect given its java heritage that it is much weaker on the
> >configuration aspect if it supports it.
> >
> >Andrew
> >
> >> On Mon, Jul 23, 2012 at 11:20 AM, Steve Huston <sh...@riverace.com>
> >>wrote:
> >> > Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
> >> > autoconf, but that's got a limited lifespan). It would be nice to
> >>limit
> >> > the number of build systems we need to maintain. I know proton is not
> >> > Qpid, but the knowledge and setups needed is one more thing C++ devs
> >>would
> >> > need to take care of if working on proton. Is there any support on the
> >> > proton devs part of using cmake for the C++ part?
> >> >
> >> > -Steve
> >> >
> >> > On 7/23/12 9:41 AM, "Joseph Ottinger" <jo...@enigmastation.com> wrote:
> >> >
> >> >>I was wondering if it'd be valuable to convert the build for proton to
> >> >>maven. It's not a "rocket surgery" conversion - it involves moving
> >> >>files and just a touch of configuration - but at the same time,
> >> >>there're a lot of benefits.
> >> >>
> >> >>For better or for worse, there're two dominant build systems in Java;
> >> >>one is Ant, the other Maven. Maven is winning, because Ant's not
> >> >>*really* a build system - it's a scripting engine that people use for
> >> >>builds, while Maven is a build system for realz, yo. Maven means a
> >> >>regular lifecycle for the build, including explicit testing,
> >> >>packaging, distribution phases; ant allows those things but doesn't
> >> >>help you create them, and Maven has standards for them.
> >> >>
> >> >>Maven's set of tools is also very useful; again, you can do the same
> >> >>things with Ant if you try, but few developers really care a lot about
> >> >>having done stuff in the build system. They'd rather focus on the
> >> >>project, not the build. With Maven, we can slap Arquillian into the
> >> >>build (for example) and have a full module/integration/system test as
> >> >>part of the build process, instead of bolting such things into place.
> >> >>
> >> >>Maven's also cross-language. Proton isn't just Java, of course; Maven
> >> >>means we can use C++ and still have only one build process (within
> >> >>certain reason; I'm not claiming Maven's the equivalent of autoconf,
> >> >>because duh, but then again, autoconf is SOOOOO much fun....)
> >> >>
> >> >>I'm more than willing to convert the build over if desired; the java
> >> >>part's already done, I'd still need to do the C++ conversion but it
> >> >>would be pretty easy.
> >> >>--
> >> >>Joseph B. Ottinger
> >> >>http://enigmastation.com
> >> >>Ça en vaut la peine.
> >> >>
> >> >>---------------------------------------------------------------------
> >> >>To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> >>For additional commands, e-mail: dev-help@qpid.apache.org
> >> >>
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> > For additional commands, e-mail: dev-help@qpid.apache.org
> >> >
> >>
> >>
> >>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >For additional commands, e-mail: dev-help@qpid.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Steve Huston <sh...@riverace.com>.
Exactly. Thank you, Andrew.
On 7/23/12 11:40 AM, "Andrew Stitcher" <as...@redhat.com> wrote:
>On Mon, 2012-07-23 at 11:26 -0400, Joseph Ottinger wrote:
>> What do you mean? I don't know what the proton devs would need to do
>> to support cmake -- the deliverables would be the same regardless of
>> the build system, or can be made to be identical.
>
>I think you are talking at cross purposes here.
>
>Steve is pointing out that those who work on the code base would have to
>learn to use another build system - maven. Irrespective of whether you
>can make its output identical to the cmake it's another thing to learn
>to work productively on the code.
>
>I think that Joseph is talking about the impact on developers who are
>using that code.
>
>I would point out that in the case of C code using maven brings a very
>large build dependency (java) that isn't the case for cmake. Obviously
>if you are building java that isn't important since you must have java
>anyway.
>
>Also cmake is not just a build system, in the comparison with autotools
>(autoconf and automake) it covers both configuration and build. I don't
>know enough about maven to know if it similarly covers both of these
>roles. I'd suspect given its java heritage that it is much weaker on the
>configuration aspect if it supports it.
>
>Andrew
>
>> On Mon, Jul 23, 2012 at 11:20 AM, Steve Huston <sh...@riverace.com>
>>wrote:
>> > Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
>> > autoconf, but that's got a limited lifespan). It would be nice to
>>limit
>> > the number of build systems we need to maintain. I know proton is not
>> > Qpid, but the knowledge and setups needed is one more thing C++ devs
>>would
>> > need to take care of if working on proton. Is there any support on the
>> > proton devs part of using cmake for the C++ part?
>> >
>> > -Steve
>> >
>> > On 7/23/12 9:41 AM, "Joseph Ottinger" <jo...@enigmastation.com> wrote:
>> >
>> >>I was wondering if it'd be valuable to convert the build for proton to
>> >>maven. It's not a "rocket surgery" conversion - it involves moving
>> >>files and just a touch of configuration - but at the same time,
>> >>there're a lot of benefits.
>> >>
>> >>For better or for worse, there're two dominant build systems in Java;
>> >>one is Ant, the other Maven. Maven is winning, because Ant's not
>> >>*really* a build system - it's a scripting engine that people use for
>> >>builds, while Maven is a build system for realz, yo. Maven means a
>> >>regular lifecycle for the build, including explicit testing,
>> >>packaging, distribution phases; ant allows those things but doesn't
>> >>help you create them, and Maven has standards for them.
>> >>
>> >>Maven's set of tools is also very useful; again, you can do the same
>> >>things with Ant if you try, but few developers really care a lot about
>> >>having done stuff in the build system. They'd rather focus on the
>> >>project, not the build. With Maven, we can slap Arquillian into the
>> >>build (for example) and have a full module/integration/system test as
>> >>part of the build process, instead of bolting such things into place.
>> >>
>> >>Maven's also cross-language. Proton isn't just Java, of course; Maven
>> >>means we can use C++ and still have only one build process (within
>> >>certain reason; I'm not claiming Maven's the equivalent of autoconf,
>> >>because duh, but then again, autoconf is SOOOOO much fun....)
>> >>
>> >>I'm more than willing to convert the build over if desired; the java
>> >>part's already done, I'd still need to do the C++ conversion but it
>> >>would be pretty easy.
>> >>--
>> >>Joseph B. Ottinger
>> >>http://enigmastation.com
>> >>Ça en vaut la peine.
>> >>
>> >>---------------------------------------------------------------------
>> >>To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> >>For additional commands, e-mail: dev-help@qpid.apache.org
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: dev-help@qpid.apache.org
>> >
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Andrew Stitcher <as...@redhat.com>.
On Mon, 2012-07-23 at 11:26 -0400, Joseph Ottinger wrote:
> What do you mean? I don't know what the proton devs would need to do
> to support cmake -- the deliverables would be the same regardless of
> the build system, or can be made to be identical.
I think you are talking at cross purposes here.
Steve is pointing out that those who work on the code base would have to
learn to use another build system - maven. Irrespective of whether you
can make its output identical to the cmake it's another thing to learn
to work productively on the code.
I think that Joseph is talking about the impact on developers who are
using that code.
I would point out that in the case of C code using maven brings a very
large build dependency (java) that isn't the case for cmake. Obviously
if you are building java that isn't important since you must have java
anyway.
Also cmake is not just a build system, in the comparison with autotools
(autoconf and automake) it covers both configuration and build. I don't
know enough about maven to know if it similarly covers both of these
roles. I'd suspect given its java heritage that it is much weaker on the
configuration aspect if it supports it.
Andrew
> On Mon, Jul 23, 2012 at 11:20 AM, Steve Huston <sh...@riverace.com> wrote:
> > Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
> > autoconf, but that's got a limited lifespan). It would be nice to limit
> > the number of build systems we need to maintain. I know proton is not
> > Qpid, but the knowledge and setups needed is one more thing C++ devs would
> > need to take care of if working on proton. Is there any support on the
> > proton devs part of using cmake for the C++ part?
> >
> > -Steve
> >
> > On 7/23/12 9:41 AM, "Joseph Ottinger" <jo...@enigmastation.com> wrote:
> >
> >>I was wondering if it'd be valuable to convert the build for proton to
> >>maven. It's not a "rocket surgery" conversion - it involves moving
> >>files and just a touch of configuration - but at the same time,
> >>there're a lot of benefits.
> >>
> >>For better or for worse, there're two dominant build systems in Java;
> >>one is Ant, the other Maven. Maven is winning, because Ant's not
> >>*really* a build system - it's a scripting engine that people use for
> >>builds, while Maven is a build system for realz, yo. Maven means a
> >>regular lifecycle for the build, including explicit testing,
> >>packaging, distribution phases; ant allows those things but doesn't
> >>help you create them, and Maven has standards for them.
> >>
> >>Maven's set of tools is also very useful; again, you can do the same
> >>things with Ant if you try, but few developers really care a lot about
> >>having done stuff in the build system. They'd rather focus on the
> >>project, not the build. With Maven, we can slap Arquillian into the
> >>build (for example) and have a full module/integration/system test as
> >>part of the build process, instead of bolting such things into place.
> >>
> >>Maven's also cross-language. Proton isn't just Java, of course; Maven
> >>means we can use C++ and still have only one build process (within
> >>certain reason; I'm not claiming Maven's the equivalent of autoconf,
> >>because duh, but then again, autoconf is SOOOOO much fun....)
> >>
> >>I'm more than willing to convert the build over if desired; the java
> >>part's already done, I'd still need to do the C++ conversion but it
> >>would be pretty easy.
> >>--
> >>Joseph B. Ottinger
> >>http://enigmastation.com
> >>Ça en vaut la peine.
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >>For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Joseph Ottinger <jo...@enigmastation.com>.
What do you mean? I don't know what the proton devs would need to do
to support cmake -- the deliverables would be the same regardless of
the build system, or can be made to be identical.
On Mon, Jul 23, 2012 at 11:20 AM, Steve Huston <sh...@riverace.com> wrote:
> Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
> autoconf, but that's got a limited lifespan). It would be nice to limit
> the number of build systems we need to maintain. I know proton is not
> Qpid, but the knowledge and setups needed is one more thing C++ devs would
> need to take care of if working on proton. Is there any support on the
> proton devs part of using cmake for the C++ part?
>
> -Steve
>
> On 7/23/12 9:41 AM, "Joseph Ottinger" <jo...@enigmastation.com> wrote:
>
>>I was wondering if it'd be valuable to convert the build for proton to
>>maven. It's not a "rocket surgery" conversion - it involves moving
>>files and just a touch of configuration - but at the same time,
>>there're a lot of benefits.
>>
>>For better or for worse, there're two dominant build systems in Java;
>>one is Ant, the other Maven. Maven is winning, because Ant's not
>>*really* a build system - it's a scripting engine that people use for
>>builds, while Maven is a build system for realz, yo. Maven means a
>>regular lifecycle for the build, including explicit testing,
>>packaging, distribution phases; ant allows those things but doesn't
>>help you create them, and Maven has standards for them.
>>
>>Maven's set of tools is also very useful; again, you can do the same
>>things with Ant if you try, but few developers really care a lot about
>>having done stuff in the build system. They'd rather focus on the
>>project, not the build. With Maven, we can slap Arquillian into the
>>build (for example) and have a full module/integration/system test as
>>part of the build process, instead of bolting such things into place.
>>
>>Maven's also cross-language. Proton isn't just Java, of course; Maven
>>means we can use C++ and still have only one build process (within
>>certain reason; I'm not claiming Maven's the equivalent of autoconf,
>>because duh, but then again, autoconf is SOOOOO much fun....)
>>
>>I'm more than willing to convert the build over if desired; the java
>>part's already done, I'd still need to do the C++ conversion but it
>>would be pretty easy.
>>--
>>Joseph B. Ottinger
>>http://enigmastation.com
>>Ça en vaut la peine.
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
--
Joseph B. Ottinger
http://enigmastation.com
Ça en vaut la peine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Hiram Chirino <hi...@hiramchirino.com>.
+1 Please have the java code use maven, or at least use the maven directory
layouts. That way upstream folks can easily slap on a maven build on top
if they want to.
On Mon, Jul 23, 2012 at 11:52 AM, Joseph Ottinger <jo...@enigmastation.com>wrote:
> Well, my thought wasn't necessarily to replace cmake for the non-Java
> parts - Maven is *capable* of doing non-Java-based builds, but isn't
> necessarily idiomatic. I'd think using Maven for C++ builds would be a
> little pathological, honestly - doable but not necessarily profitable.
>
> For Java, it'd be worthwhile; for C++, using Cmake is probably wisest.
>
> On Mon, Jul 23, 2012 at 11:45 AM, Steve Huston <sh...@riverace.com>
> wrote:
> > (In my best Rosanna Roasanna-danna imitation) Oh - never mind.
> >
> > Thanks,
> > -Steve
> >
> > On 7/23/12 11:45 AM, "Rafael Schloming" <ra...@redhat.com> wrote:
> >
> >>On Mon, 2012-07-23 at 15:20 +0000, Steve Huston wrote:
> >>> Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
> >>> autoconf, but that's got a limited lifespan). It would be nice to limit
> >>> the number of build systems we need to maintain. I know proton is not
> >>> Qpid, but the knowledge and setups needed is one more thing C++ devs
> >>>would
> >>> need to take care of if working on proton. Is there any support on the
> >>> proton devs part of using cmake for the C++ part?
> >>
> >>We already do use cmake for the C part (there is currently no C++ code).
> >>
> >>--Rafael
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >>For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
>
>
>
> --
> Joseph B. Ottinger
> http://enigmastation.com
> Ça en vaut la peine.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
--
**
*Hiram Chirino*
*Software Fellow | FuseSource Corp.*
*chirino@fusesource.com | fusesource.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
*
*
*
*
Re: Maven build?
Posted by Joseph Ottinger <jo...@enigmastation.com>.
Well, my thought wasn't necessarily to replace cmake for the non-Java
parts - Maven is *capable* of doing non-Java-based builds, but isn't
necessarily idiomatic. I'd think using Maven for C++ builds would be a
little pathological, honestly - doable but not necessarily profitable.
For Java, it'd be worthwhile; for C++, using Cmake is probably wisest.
On Mon, Jul 23, 2012 at 11:45 AM, Steve Huston <sh...@riverace.com> wrote:
> (In my best Rosanna Roasanna-danna imitation) Oh - never mind.
>
> Thanks,
> -Steve
>
> On 7/23/12 11:45 AM, "Rafael Schloming" <ra...@redhat.com> wrote:
>
>>On Mon, 2012-07-23 at 15:20 +0000, Steve Huston wrote:
>>> Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
>>> autoconf, but that's got a limited lifespan). It would be nice to limit
>>> the number of build systems we need to maintain. I know proton is not
>>> Qpid, but the knowledge and setups needed is one more thing C++ devs
>>>would
>>> need to take care of if working on proton. Is there any support on the
>>> proton devs part of using cmake for the C++ part?
>>
>>We already do use cmake for the C part (there is currently no C++ code).
>>
>>--Rafael
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
--
Joseph B. Ottinger
http://enigmastation.com
Ça en vaut la peine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Steve Huston <sh...@riverace.com>.
(In my best Rosanna Roasanna-danna imitation) Oh - never mind.
Thanks,
-Steve
On 7/23/12 11:45 AM, "Rafael Schloming" <ra...@redhat.com> wrote:
>On Mon, 2012-07-23 at 15:20 +0000, Steve Huston wrote:
>> Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
>> autoconf, but that's got a limited lifespan). It would be nice to limit
>> the number of build systems we need to maintain. I know proton is not
>> Qpid, but the knowledge and setups needed is one more thing C++ devs
>>would
>> need to take care of if working on proton. Is there any support on the
>> proton devs part of using cmake for the C++ part?
>
>We already do use cmake for the C part (there is currently no C++ code).
>
>--Rafael
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Rafael Schloming <ra...@redhat.com>.
On Mon, 2012-07-23 at 15:20 +0000, Steve Huston wrote:
> Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
> autoconf, but that's got a limited lifespan). It would be nice to limit
> the number of build systems we need to maintain. I know proton is not
> Qpid, but the knowledge and setups needed is one more thing C++ devs would
> need to take care of if working on proton. Is there any support on the
> proton devs part of using cmake for the C++ part?
We already do use cmake for the C part (there is currently no C++ code).
--Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Maven build?
Posted by Steve Huston <sh...@riverace.com>.
Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
autoconf, but that's got a limited lifespan). It would be nice to limit
the number of build systems we need to maintain. I know proton is not
Qpid, but the knowledge and setups needed is one more thing C++ devs would
need to take care of if working on proton. Is there any support on the
proton devs part of using cmake for the C++ part?
-Steve
On 7/23/12 9:41 AM, "Joseph Ottinger" <jo...@enigmastation.com> wrote:
>I was wondering if it'd be valuable to convert the build for proton to
>maven. It's not a "rocket surgery" conversion - it involves moving
>files and just a touch of configuration - but at the same time,
>there're a lot of benefits.
>
>For better or for worse, there're two dominant build systems in Java;
>one is Ant, the other Maven. Maven is winning, because Ant's not
>*really* a build system - it's a scripting engine that people use for
>builds, while Maven is a build system for realz, yo. Maven means a
>regular lifecycle for the build, including explicit testing,
>packaging, distribution phases; ant allows those things but doesn't
>help you create them, and Maven has standards for them.
>
>Maven's set of tools is also very useful; again, you can do the same
>things with Ant if you try, but few developers really care a lot about
>having done stuff in the build system. They'd rather focus on the
>project, not the build. With Maven, we can slap Arquillian into the
>build (for example) and have a full module/integration/system test as
>part of the build process, instead of bolting such things into place.
>
>Maven's also cross-language. Proton isn't just Java, of course; Maven
>means we can use C++ and still have only one build process (within
>certain reason; I'm not claiming Maven's the equivalent of autoconf,
>because duh, but then again, autoconf is SOOOOO much fun....)
>
>I'm more than willing to convert the build over if desired; the java
>part's already done, I'd still need to do the C++ conversion but it
>would be pretty easy.
>--
>Joseph B. Ottinger
>http://enigmastation.com
>Ça en vaut la peine.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org