gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ioannis Canellos <ioca...@gmail.com>
Subject Re: Moving Gora build system to Maven?
Date Sun, 13 Mar 2011 08:28:14 GMT
@Henry: As far as I know having its not very common to maintain more than
one build systems. I think Apache Tiles goes beyond that and also offers
ant, maven & graddle support. There are also some non Apache projects that
do so (e.g. Hazelcast).

@Chirs: I can't agree more.



On Sat, Mar 12, 2011 at 7:45 PM, Henry Saputra <henry.saputra@gmail.com>wrote:

> Hey Julien,
>
> I am trying to find if any of existing ASF projects has dual build
> systems.  Want to see if this somewhat a "norm" for Apache projects.
> I agree its a bit pain maintaining  two different systems (I did it at
> work and its not pretty).
>
> I also more happy to add more tests and support for features so using
> Ivy+ ANT is not a big deal for me =)
>
> My +1 is if we want to add Maven support, might as well make it
> parallel with existing Ivy+Ant.
>
> BTW, dont forget to VOTE on the RC3 thread ^_^
>
> - Henry
>
> On Sat, Mar 12, 2011 at 3:23 AM, Julien Nioche
> <lists.digitalpebble@gmail.com> wrote:
> > I am not particularly keen to have to maintain 2 systems in parallel,
> some
> > of you are maybe more familiar with Maven but as Chris pointed out most
> of
> > the Gora devs prefer ANT+Ivy and as far as I know the latter does not
> > prevent us from doing what we need i.e build, manage dependencies and
> > publish artifacts. Of course if this makes you happy, this is fine by me
> > but  I'd rather we spent more effort on writing tests, add new
> > functionalities or improve the documentation instead of arguing which of
> Ivy
> > or Maven is better.
> >
> > On 11 March 2011 21:55, Henry Saputra <henry.saputra@gmail.com> wrote:
> >
> >> +1 for this approach
> >>
> >> - Henry
> >>
> >> On Fri, Mar 11, 2011 at 1:52 PM, Mattmann, Chris A (388J)
> >> <chris.a.mattmann@jpl.nasa.gov> wrote:
> >> > Hi Ioannis, thank you very much! I am certainly more familiar with
> Maven
> >> then Ivy, and would be willing to help get these committed.
> >> >
> >> > I don't think parallel build systems hurt either. Most of the Gora
> devs
> >> though, realize, are Ant+Ivy users, so they will be more familiar with
> that
> >> system. But, if we have Maven poms, those can be maintained as well.
> >> >
> >> > Thanks! I'll take a look at these.
> >> >
> >> > Cheers,
> >> > Chris
> >> >
> >> > On Mar 11, 2011, at 1:49 PM, Ioannis Canellos wrote:
> >> >
> >> >> I created issue https://issues.apache.org/jira/browse/GORA-29 and
> >> attached a
> >> >> patch which adds maven support to Gora.
> >> >>
> >> >>
> >> >> On Fri, Mar 11, 2011 at 12:12 PM, Ioannis Canellos <
> iocanel@gmail.com
> >> >wrote:
> >> >>
> >> >>> Hi all,
> >> >>>
> >> >>> I would prefer to see Gora use maven, for the following reasons:
> >> >>>
> >> >>>   - Maven promotes convention over configuration and re-usability
> >> (really
> >> >>>   important as the project grows, as it decreases the management
> >> overhead and
> >> >>>   ensures uniformity).
> >> >>>   - A Maven project is a lot easier to be imported to any IDE (will
> >> make
> >> >>>   it easier for new Gora users. Now a lot of things need to be
done
> by
> >> >>>   "hand").
> >> >>>   - Access to a wide plugin list that among others help release
> >> >>>   management, repository management.
> >> >>>   - Better support for tools like findbugs, pmd, colver and other
> that
> >> >>>   can also be quite easily integrate with hudson / jenkins.
> >> >>>   - Better support for artifacts with classifier (I couldn't find
to
> >> use
> >> >>>   classifier in dependencies with ivy).
> >> >>>
> >> >>> If the above are not enough to convince you, then you might want
> >> consider
> >> >>> the possibility of supporting both ant/ivy & maven builds.
I would
> be
> >> more
> >> >>> that happy to contribute & maintain the maven project filles.
> >> >>>
> >> >>>
> >> >>> On Sun, Feb 6, 2011 at 2:20 PM, Julien Nioche <
> >> >>> lists.digitalpebble@gmail.com> wrote:
> >> >>>
> >> >>>> Hi,
> >> >>>>
> >> >>>> Personally I'd rather stick to ant+ivy. Maybe you could reuse
code
> >> from
> >> >>>> NUTCH-825 <https://issues.apache.org/jira/browse/NUTCH-825>
to
> >> publish
> >> >>>> using
> >> >>>> ant?
> >> >>>> Since most if not all current Gora users use it for Nutch 2.0,
I
> think
> >> it
> >> >>>> would make sense to keep the same ant+ivy mechanism
> >> >>>>
> >> >>>> Julien
> >> >>>>
> >> >>>> On 6 February 2011 09:16, Henry Saputra <henry.saputra@gmail.com>
> >> wrote:
> >> >>>>
> >> >>>>> HI Enis,
> >> >>>>>
> >> >>>>> The Maven release management plugin
> >> >>>>> (http://maven.apache.org/plugins/maven-release-plugin/)
is
> probably
> >> >>>>> the main reason why I was proposing to use Maven.
> >> >>>>> Having some targets to help doing this should do for now.
> >> >>>>>
> >> >>>>> I was just thinking about maven just because I use it more
often
> than
> >> >>>>> ant+ivy =)
> >> >>>>>
> >> >>>>> - Henry
> >> >>>>>
> >> >>>>> On Sun, Feb 6, 2011 at 12:47 AM, Enis Söztutar <
> enis.soz@gmail.com>
> >> >>>> wrote:
> >> >>>>>> Personally I prefer ant+ivy over maven, since I do
not like
> anything
> >> >>>>>> automagical happening in my code.
> >> >>>>>>
> >> >>>>>> Could you elaborate on what will be the benefits apart
from
> pushing
> >> to
> >> >>>>> maven
> >> >>>>>> repository. I believe there is an ivy target to do
just that,
> would
> >> >>>> that
> >> >>>>> be
> >> >>>>>> enough?
> >> >>>>>>
> >> >>>>>> Enis
> >> >>>>>>
> >> >>>>>> On Sat, Feb 5, 2011 at 11:36 PM, Henry Saputra <
> >> >>>> henry.saputra@gmail.com
> >> >>>>>> wrote:
> >> >>>>>>
> >> >>>>>>> Hi Guys,
> >> >>>>>>>
> >> >>>>>>> Just a food for thought, any thought about moving
the build
> system
> >> to
> >> >>>>>>> maven?
> >> >>>>>>>
> >> >>>>>>> I think there are more projects in Apache is using
Maven and a
> lot
> >> of
> >> >>>>>>> Maven plugins that could make deploying and managing
Gora
> releases
> >> >>>>>>> better.
> >> >>>>>>>
> >> >>>>>>> Is there any possible complexity./ issue to move
it from Ivy?
> >> >>>>>>>
> >> >>>>>>> --
> >> >>>>>>> Thanks,
> >> >>>>>>> Henry
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> Thanks,
> >> >>>>> Henry
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> *
> >> >>>> *Open Source Solutions for Text Engineering
> >> >>>>
> >> >>>> http://digitalpebble.blogspot.com/
> >> >>>> http://www.digitalpebble.com
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> *Ioannis Canellos*
> >> >>> *
> >> >>> http://iocanel.blogspot.com
> >> >>>
> >> >>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> >> >>> Apache ServiceMix <http://servicemix.apache.org/>  Committer
> >> >>> *
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> *Ioannis Canellos*
> >> >> *
> >> >> http://iocanel.blogspot.com
> >> >>
> >> >> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> >> >> Apache ServiceMix <http://servicemix.apache.org/>  Committer
> >> >> *
> >> >
> >> >
> >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> > Chris Mattmann, Ph.D.
> >> > Senior Computer Scientist
> >> > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> > Office: 171-266B, Mailstop: 171-246
> >> > Email: chris.a.mattmann@nasa.gov
> >> > WWW:   http://sunset.usc.edu/~mattmann/
> >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> > Adjunct Assistant Professor, Computer Science Department
> >> > University of Southern California, Los Angeles, CA 90089 USA
> >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Thanks,
> >> Henry
> >>
> >
> >
> >
> > --
> > *
> > *Open Source Solutions for Text Engineering
> >
> > http://digitalpebble.blogspot.com/
> > http://www.digitalpebble.com
> >
>
>
>
> --
> Thanks,
> Henry
>



-- 
*Ioannis Canellos*
*
 http://iocanel.blogspot.com

Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/>  Committer
*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message