Feature Request: Migrate to Maven Build

[GoogleCodeExporter]

The build could be greatly simplified by adopting Maven as the build and
packaging system. This would also align the source code structure and JAR
naming conventions (e.g. include the minor version in the JAR name) with
now widely adopted industry standards and allow users to more easily
reference GData dependencies in their own applications by simply
referencing the dependency in their project without having to compile the
libraries from scratch (assuming these libraries are are going to be posted
in a repository).

This relatively minor change in the current build system could save us all
a lot of time and make the GData API more accessible to Java users.

I'll volunteer to do the migration ;-)

Original issue reported on code.google.com by thomas.e...@gmail.com on 27 Jun 2008 at 4:57

[GoogleCodeExporter]

Thomas,
    Migrating to Maven has been discussed in the past.  It hasnt been done so far,
because of lack of resources.  If you are interested it will be a significant
contribution, and you are more than welcome to add the support.  

Note: Currently this repository is not provisioned to accept external 
contributions.
 We can workout a plan on how we can add your contribution to the repository.  

- Prakash.

Original comment by vbarat...@gmail.com on 27 Jun 2008 at 12:57

[GoogleCodeExporter]

Hi Prakash,

I'd be glad to help out here. I see a couple of options:

    * Convert what's currently in the trunk locally and send you back a zip
    * Branch the code base, perform the migration there and then merge back when
completed.
    * Work directly in the trunk

Given that it seems that write access cannot be provided to the repository, I 
would
suggest we go for the first option. Is that what you had in mind as well?

Thanks,
Thomas

Original comment by thomas.e...@gmail.com on 27 Jun 2008 at 3:20

[GoogleCodeExporter]

Thomas,
    I think only the first option is feasible.  We would like to keep the ant option
around as well.  That means the source tree is not going to change.  We can add
additional pom files and other related artifacts.  If you anticipate any 
structural
changes in the code/package paths., please let me know, we can work out a 
solution
that fits with both use cases.

Again thanks for volunteering!  It will be a significant contribution to 
increase
acceptance for gdata API.

- Prakash.

Original comment by vbarat...@gmail.com on 27 Jun 2008 at 9:39

[GoogleCodeExporter]

Prakash,

Some structural changes would be required. For example, the source code would 
need to
be moved to modules with one module per client API and probably a common API 
module
for code that is shared between modules. Here's an example of what it would 
look like:

/trunk
      /gdata-api
                   /gdata-client (Code shared across all clients)
                                /src/main/java (source code)
                                /src/test/java (unit tests)
                   /gdata-spreadsheet (spreadsheet specific code)
                                     /src/main/java 
                                     /...
                   /...

We'd have a parent POM and modules per client. One command could build all 
modules
automatically, generate javadocs, unit test reports, etc.
It should also be possible to continue to maintain an Ant build script although 
that
would require a rewrite. Once Maven is set up, you can easily integrate all 
modules
in Eclipse by using the m2eclipse plugin or running mvn eclipse:eclipse from the
parent POM. That will automatically create Eclipse projects for you which you 
can
import in your workspace. Netbeans users can use a similar plugin to generate
Netbeans projects.

Original comment by thomas.e...@gmail.com on 27 Jun 2008 at 9:52

[GoogleCodeExporter]

In the current build, we follow similar logical structure though the source 
files are
clustered under src/java/com/google/gdata.  This can easily be restructured (of
course with minor rewrite to ant build files), but this need to be opened up to 
a
broader group, to make sure that this doesn't significantly affect anyone.  

Having said that, I'm not an expert in Maven build system. Pardon me for any 
dumb
questions here:  "Cant Maven handle the current structure to emulate the 
structure
that you have proposed?"

I'm little hesitant to change the structure as it will deviate signifcantly 
from the
current internal development workflow.  I'm open for ideas/suggestions on how 
to do
this in a less intrusive way.

Other (least efficient) solution would be to maintain two parallel repositories 
one
for Maven configuration, and the other existing repository.  But this will be a 
overkill.

Original comment by vbarat...@gmail.com on 30 Jun 2008 at 4:48

[GoogleCodeExporter]

I would agree that a parallel repository would be too much overhead. Although 
it is
possible to configure Maven to some extend to divert from the their standard
directory layout, it would somewhat defy the purpose of migrating to Maven as 
one of
its key value propositions is to propose a consistent standard directory 
structure
across all projects that use Maven. 

I have started moving your source code into a Maven structure and took notes on 
the
changes I am making so you can evaluate whether this Maven-base approach would 
add
value and justify the migration. I'd also be happy to talk to you or anybody 
else
about the benefits/pitfalls of migrating to Maven. I am confident that you'd 
see a
lot of benefits out of this.

Side note: The most popular feature request on for the Spring framework, one of 
the
most popular Java frameworks, has long been a request to migrate to Maven (121 
votes
with the second most popular request at 32 votes)
(http://jira.springframework.org/browse/SPR-1484).
Also, Maven integration with Eclipse is currently going through the incubation
process at Eclipse.org and will soon be ready for prime time
(http://www.theregister.co.uk/2008/06/26/eclipse_maven_plugin/).

Original comment by thomas.e...@gmail.com on 30 Jun 2008 at 5:27

[GoogleCodeExporter]

makes sense to create the modular structure.

Just did a quick search looks like there are several other SVN projects started 
off
with ant route and later added maven support.  I will follow-up with other 
projects
as well to see if any of them ran into similar scenario (single repository with
multiple modules requiring code separation).  I will get back to you with some
internal feedback.  There has also been some proposals to host the maven 
repository
as part of code.google.com. Not sure whats the current status of that.

Original comment by vbarat...@gmail.com on 1 Jul 2008 at 4:12

[GoogleCodeExporter]

An internal code.google.com repository would be great, especially if you want to
deploy snapshots of the latest code builds (e.g. through a continuous 
integration
server).

Original comment by thomas.e...@gmail.com on 1 Jul 2008 at 4:15

[GoogleCodeExporter]

seems like there may be some alternative solutions.  Seems like ant provides 
some
basic Maven support that we care about - dependency handling and pushing to a 
maven
repository (http://maven.apache.org/ant-tasks.html).  if I update my current ant
configuration to specify our current dependencies and be able to push the jars 
to a
maven repository (instead of migrating the entire code to maven structure), 
will that
be an acceptable alternative?

Original comment by vbarat...@gmail.com on 2 Jul 2008 at 8:49

[GoogleCodeExporter]

seems like there may be some alternative solutions.  Seems like ant provides 
some
basic Maven support that we care about - dependency handling and pushing to a 
maven
repository (http://maven.apache.org/ant-tasks.html).  if I update my current ant
configuration to specify our current dependencies and be able to push the jars 
to a
maven repository (instead of migrating the entire code to maven structure), 
will that
be an acceptable alternative?

Original comment by vbarat...@gmail.com on 2 Jul 2008 at 8:49

[GoogleCodeExporter]

That would work for Maven users who want to use GData in their projects. Beyond 
that
it's really up to the committers to decide whether they see benefit in using 
Maven
instead of Ant scripts.

Original comment by thomas.e...@gmail.com on 2 Jul 2008 at 10:17

[GoogleCodeExporter]

Thomas,

I think that is acceptable, I believe most common usecase would be to include 
gdata
jars as dependencies for their projects.  So it doesnt matter how the jars 
built, as
long as they can specify it as a dependency in the maven configuration for their
projects.

Though I agree that the ideal solution would be to keep the source tree and 
maven pom
hierarchy to be same, but given the usecase and the current state that we are 
in, i
think it might be better just to create a maven repository for gdata libaries 
(not
source) and keep the source tree as it is now.

As you have more experience working with maven repositories do you think this 
is an
acceptable solution?

- Prakash.

Original comment by vbarat...@gmail.com on 3 Jul 2008 at 5:02

[GoogleCodeExporter]

You can actually generate ant build scripts from maven.
http://maven.apache.org/plugins/maven-ant-plugin/

So when and if gdata gets migrated to Maven, you can use maven to generate a 
build
file for Ant users.

Original comment by haikal.s...@gmail.com on 16 Sep 2008 at 5:20

[GoogleCodeExporter]

For the impatient, (like me :D) Here's a quick and dirty pom that will just 
give you
a massive jar with everything. Haven't tested it yet, but it should be enough 
do to a
'maven install' so you can start using it.

Original comment by haikal.s...@gmail.com on 16 Sep 2008 at 6:09

Attachments:

• pom.xml

[GoogleCodeExporter]

Issue 55 has been merged into this issue.

Original comment by vbarat...@gmail.com on 26 Feb 2009 at 5:30

[GoogleCodeExporter]

What's the status of this change?  The POM from 9/15, while a good start, IS a 
bit
monotlithic (as the author noted. :)  Has any progress been made on this in the 
past
5 months?  The source tree is very un-Maven-like. :)

Original comment by flakfi...@gmail.com on 27 Feb 2009 at 3:45

[GoogleCodeExporter]

Would be very useful for me to have this done.  One of the few libraries we use 
that
is not automatically updated into the maven repositories.  Maven is very 
prevalent by
this point so a fairly important miss.

Original comment by jeich...@gmail.com on 28 Feb 2009 at 4:42

[GoogleCodeExporter]

Think the attached pom.xml is missing the correct dependencies.  The 
dependencies
should be upgraded with each new release build.

Is there a way to tell what went into a build via the issue tracker here?  Does 
not
seem as if projects use milestone so exact bug fixes are not traceable to a 
release
except in the release notes, but the release notes don't contain all of the bug 
fixes
either I think.

Maybe I am missing something.

Thank you for all of the hard work you guys do though.

Original comment by jeich...@gmail.com on 28 Feb 2009 at 4:47

[GoogleCodeExporter]

jeichels/flakfizer,
      It has been on our list of things to do., but not got prioritized high enough
to work on it.  You are free to contribute updated/stable pom configurations as 
patch
that will make your life easier.  

As an example, i recently added a community contribution that cleans up some of 
our
ant build configuration:
http://code.google.com/p/gdata-java-client/issues/detail?id=82&can=1&q=ant%20pat
ch

Original comment by vbarat...@gmail.com on 3 Mar 2009 at 5:47

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

how can i migrate this api with sql server 2000?

Original comment by GregPi...@gmail.com on 25 Nov 2009 at 5:01

[GoogleCodeExporter]

I'm wondering if the team is still open to migrating to a Maven build. I've been
playing with a script to convert current trunk to a Maven build. Preliminary 
results
seem workable.

Example build of all jars went from 60s for Ant and 21 secs for Maven - 
including
meta jars.

I still have some tweaking to do but wanted to get the ball rolling on sharing 
it.

Feedback?

Original comment by peterlyn...@gmail.com on 17 Dec 2009 at 8:40

[GoogleCodeExporter]

Yes, Maven is a target goal for us.  There are certain elements (interpackage 
dependencies) that makes it non-so-ideal for maven package structure 
requirements.  
This will be fixed in the next major upgrade to client library (2.0) which will 
get rid of 
metadata, and provides cleaner package structure with non inter-dependency.  
Maven 
support will be included as part of the new version.  With the current library 
the support 
is less than ideal (though workable).

Original comment by vbarat...@gmail.com on 17 Dec 2009 at 10:01

• Changed state: RequestedFeedback
• Added labels: H

[GoogleCodeExporter]

Thanks for the update. I'm not sure what makes it non-so-ideal.

I have a script working that can convert your trunk to, what I think at least, 
is a
decent Maven project directory structure. It also generates all the pom.xml 
files
with proper dependencies. The manifest files are pretty much the same as well. 
It
does in fact still create the meta jars but this does not affect the directory
structure in case they are removed. And lastly it tries to svn add/remove 
properly so
that no file history is lost and unused cruft gets removed. To run the script 
you
just tell it where gdata-java-client trunk is on local disk and away it goes. 
It is
written as Ant script so customizing is easy.

At this point I should probably get some feedback if you are so obliged. I can
continue to tweak it as requested, or contribute as you see fit. I had plans for
converting the samples to Maven as well.

There is already a google code project that was started here
http://code.google.com/p/maven-gdata-java-client/ for conversion I guess, that
appears stalled. If however maybe I can reach  thomas.e.van.de.velde ( don't 
know him
personally), I should commit what I have there. That way you can download my 
script
and try it yourself to see what it does.

Failing that, I can always start a new project and upload it. Don't feel like
attaching it to this issue since I anticipate many updates and it would prohibit
collaboration. 

How far along are you in reorganizing things to Maven? Is providing a conversion
script too late in the game?

Original comment by peterlyn...@gmail.com on 18 Dec 2009 at 6:47

[GoogleCodeExporter]

For example:

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] gdata ................................................. SUCCESS [1.412s]
[INFO] gdata-java-client ..................................... SUCCESS [0.007s]
[INFO] gdata-core ............................................ SUCCESS [7.465s]
[INFO] gdata-client .......................................... SUCCESS [2.151s]
[INFO] gdata-media ........................................... SUCCESS [0.473s]
[INFO] gdata-base ............................................ SUCCESS [0.487s]
[INFO] gdata-calendar ........................................ SUCCESS [0.664s]
[INFO] gdata-appsforyourdomain ............................... SUCCESS [0.751s]
[INFO] gdata-analytics ....................................... SUCCESS [0.621s]
[INFO] gdata-blogger ......................................... SUCCESS [0.326s]
[INFO] gdata-books ........................................... SUCCESS [0.410s]
[INFO] gdata-codesearch ...................................... SUCCESS [0.290s]
[INFO] gdata-contacts ........................................ SUCCESS [0.454s]
[INFO] gdata-spreadsheet ..................................... SUCCESS [0.425s]
[INFO] gdata-docs ............................................ SUCCESS [0.375s]
[INFO] gdata-finance ......................................... SUCCESS [0.365s]
[INFO] gdata-gtt ............................................. SUCCESS [0.292s]
[INFO] gdata-health .......................................... SUCCESS [0.210s]
[INFO] gdata-maps ............................................ SUCCESS [0.232s]
[INFO] gdata-photos .......................................... SUCCESS [1.058s]
[INFO] gdata-projecthosting .................................. SUCCESS [0.324s]
[INFO] gdata-sidewiki ........................................ SUCCESS [0.239s]
[INFO] gdata-sites ........................................... SUCCESS [0.361s]
[INFO] gdata-youtube ......................................... SUCCESS [0.620s]
[INFO] gdata-webmastertools .................................. SUCCESS [0.366s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 21 seconds
[INFO] Finished at: Thu Dec 17 15:35:05 EST 2009

Original comment by peterlyn...@gmail.com on 18 Dec 2009 at 6:51

[GoogleCodeExporter]

So wish this were in the project.  It is very aggravating having to re-put every
increased version into artifactory manually.  It causes me to not want to 
upgrade. 
It also makes it harder for me to know all the required dependencies.  Likely 
more
developers would use this API if it had Maven build capability.

Original comment by jeich...@gmail.com on 23 Dec 2009 at 4:36

[GoogleCodeExporter]

My script that converts the existing source tree into a Maven based project 
directory 
structure can be found at http://github.com/peterlynch/gdata-java-client-maven
(this is the script that created the maven projects represented in comment #24

The purpose of my project was to demonstrate how one could convert this project 
to 
a Maven based project directory structure while generating similar artifacts to 
those 
created by the existing Ant build.

As it appears Google is already working on version 2.x of gdata-java-client 
which 
will supposedly create Maven artifacts, perhaps my project is now a little less 
useful 
than I had hoped. Anyhow, I thought I'd share...

Original comment by peterlyn...@gmail.com on 6 Feb 2010 at 2:23

[GoogleCodeExporter]

Hello,
I have pushed a bit further my gdata maven repository stored on google code 
http://code.google.com/p/mandubian-mvn following David Carter idea based on 
Tattletale to extract dependencies and generate the Poms automatically. It 
manages transitive dependencies (need to study some more deps such as 
javax.mail) but anyway, it's better than nothing. I also added a Nexus Index to 
this repository and version up to 1.41.3 are currently mavenized! 
Have fun!

Original comment by pascal.v...@gmail.com on 10 Jun 2010 at 10:18

[GoogleCodeExporter]

So could anyone tell me when we can have the official maven support?

Original comment by public.c...@gmail.com on 20 Jul 2010 at 6:55

[GoogleCodeExporter]

Good news!  google-api-java-client (the new project name for version 2.x) has 
Maven support.  Google officially supports Maven users for the new library.

We will not make the effort to add official Maven support to gdata-java-client. 
 It appears that others on this Issue have provided maven repository support 
for gdata-java-client.  However, Google is not officially supporting this.

Thus, I think it is time to close this Issue, since we do not have plans to 
take action on it.  However, feel free to continue discussion at the support 
group for gdata-java-client (http://groups.google.com/group/gdata-java-client).

Original comment by yan...@google.com on 1 Aug 2010 at 12:05

• Changed state: WontFix
• Added labels: Type-Task
• Removed labels: Type-Enhancement, H

[GoogleCodeExporter]

Issue 134 has been merged into this issue.

Original comment by yan...@google.com on 12 Aug 2010 at 2:40