Re: [gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

Re: [gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

[Kasun Gajasinghe]

On 29 Mar 2011, at 14:42, Petteri Räty <betelgeuse@gentoo.org> wrote:

> On 03/29/2011 06:47 AM, Kasun Gajasinghe wrote:
>>
>> I'd like to know how the dependencies will be handled by maven based
>> ebuilds. Can you let me know the difference between dependencies
>> specified in Maven's POM file, and ebuild's dependencies? Are both
>> should be same? Since, Maven's POM contains the unique artifacts IDs
>> (with the combination of groupId, artifactId, version) which points  
>> to
>> a _binary_ jar, how should the developers who write _ebuilds_ specify
>> it? I got to know that dependencies are also ebuilds under gentoo  
>> i.e.
>> no binaries.
>>
>
> I am not sure how POM files categorize dependencies but in general  
> there
> should be some kind of a mapping between the two.
>
>> I've been going through the Ralph's (nick: sera ) suggested eclass
>> [1]. It turned out to be very useful. (sera, I got your name from  
>> [1],
>> hope it's correct! :) ). Because maven offline building is the  
>> biggest
>> issue Gentoo is currently facing, As Petteri suggested, I've been
>> going through to see how other distributions handle this. I see that
>> both in sera's eclass and in Debian's MavenRepoSpec [2], that they
>> specify a variable which points to a maven local-repository location.
>> Ralph's eclass specified MAVEN_REPO_DIR="${T}/maven-repo/" while
>> Debian has REPO=/usr/share/maven-repo. Since the file-system will be
>> read-only for ebuilds, and ebuilds should be built offline, what's  
>> the
>> purpose of this?
>>
>
> ${T} is a temporary directory for a single ebuild so it's writable.
>
>> Further, please let me know the other issues that needs to be
>> addressed that you have in mind. It turned out that the project is
>> challenging than I thought before, and is getting exciting now!
>>
>
> Besides writing the needed infrastructure for building with Maven it
> would also be useful to convert as much as possible of our manual
> ebuilds to use that infrastructure so that the solution will also be
> field tested. I see the work happening initially in a separate overlay
> with the goal of main tree merging before the project is over.
>

Ok great. I saw that there is functionality to create user-defined  
overlays at overlays.gentoo.org. I'll create a one there and do the  
implementation. Hopefully I can add a clone of gentoo-x86/dev-java/  
there first? I'm not sure how the version controlling happens then  
though!

Surely, I'll convert the current manually ebuilds to that  
infrastructure. I'm not aware of how much work is there. I'm hoping to  
continue working on it even after the Google Summer of Code over.
I think this is a great chance the students can get to contribute to  
open-source development with the initial push with an individually  
assigned mentor. I've done Google Summer of Code 2010 program under  
DocBook open repository and has continued my work even after the  
assigned project which gained me committer status. I'm sincerely  
expect to do the same with Gentoo this year.

Thanks,
Kasun

> Petteri
>

Re: [gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

[Kasun Gajasinghe]

On 29 Mar 2011, at 09:37, Serkan Kaba <serkan@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 29-03-2011 06:47, Kasun Gajasinghe wrote:
>> I'd like to know how the dependencies will be handled by maven based
>> ebuilds. Can you let me know the difference between dependencies
>> specified in Maven's POM file, and ebuild's dependencies? Are both
>> should be same? Since, Maven's POM contains the unique artifacts IDs
>> (with the combination of groupId, artifactId, version) which points  
>> to
>> a _binary_ jar, how should the developers who write _ebuilds_ specify
>> it? I got to know that dependencies are also ebuilds under gentoo  
>> i.e.
>> no binaries.
> POM dependencies can be too restrictive sometimes, like depending on a
> specific version. We should be depending on any version (or sometimes
> with >=,<=) as long as the package compiles and runs fine with it.

I've come across a package called JPackage which does the job of  
retrieving a jar from /usr/share/java and return it to use by maven.  
It neglects the version numbers as well.


>> I've been going through the Ralph's (nick: sera ) suggested eclass
>> [1]. It turned out to be very useful. (sera, I got your name from  
>> [1],
>> hope it's correct! :) ). Because maven offline building is the  
>> biggest
>> issue Gentoo is currently facing, As Petteri suggested, I've been
>> going through to see how other distributions handle this. I see that
>> both in sera's eclass and in Debian's MavenRepoSpec [2], that they
>> specify a variable which points to a maven local-repository location.
>> Ralph's eclass specified MAVEN_REPO_DIR="${T}/maven-repo/" while
>> Debian has REPO=/usr/share/maven-repo. Since the file-system will be
>> read-only for ebuilds, and ebuilds should be built offline, what's  
>> the
>> purpose of this?
> We then still need to add symlinks to jars during build time in there
> which is an "access violation" in sand box

Ok. Then the viable option is to have to generate the maven directory  
structure inside a folder named ${T}/maven-repo. We can do the  
symlinking through that, and we won't face any access violation since  
the writing happens in the sandbox.
Ubuntu too have proposed a similar solution. I'm away from my machine,  
I'll provide the links to it as well as for the JPackage soon if it  
you all may want to check it out!

Thanks,
Kasun

>
> - --
> Sincerely,
> Serkan KABA
> Gentoo Developer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2RWvIACgkQRh6X64ivZaLfkgCfVF99iZaa6Pa+dTlC4cjuLvZd
> ILkAn34OooCvrNy6uu9yEg4bua/q7X6G
> =staW
> -----END PGP SIGNATURE-----
>

Re: [gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

[Kasun Gajasinghe]

On Tue, Mar 29, 2011 at 8:41 PM, Kasun Gajasinghe <kasunbg@gmail.com> wrote:
>
>
> On 29 Mar 2011, at 09:37, Serkan Kaba <serkan@gentoo.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 29-03-2011 06:47, Kasun Gajasinghe wrote:
>>>
>>> I'd like to know how the dependencies will be handled by maven based
>>> ebuilds. Can you let me know the difference between dependencies
>>> specified in Maven's POM file, and ebuild's dependencies? Are both
>>> should be same? Since, Maven's POM contains the unique artifacts IDs
>>> (with the combination of groupId, artifactId, version) which points to
>>> a _binary_ jar, how should the developers who write _ebuilds_ specify
>>> it? I got to know that dependencies are also ebuilds under gentoo i.e.
>>> no binaries.
>>
>> POM dependencies can be too restrictive sometimes, like depending on a
>> specific version. We should be depending on any version (or sometimes
>> with >=,<=) as long as the package compiles and runs fine with it.
>
> I've come across a package called JPackage which does the job of retrieving
> a jar from /usr/share/java and return it to use by maven. It neglects the
> version numbers as well.
>
>
>>> I've been going through the Ralph's (nick: sera ) suggested eclass
>>> [1]. It turned out to be very useful. (sera, I got your name from [1],
>>> hope it's correct! :) ). Because maven offline building is the biggest
>>> issue Gentoo is currently facing, As Petteri suggested, I've been
>>> going through to see how other distributions handle this. I see that
>>> both in sera's eclass and in Debian's MavenRepoSpec [2], that they
>>> specify a variable which points to a maven local-repository location.
>>> Ralph's eclass specified MAVEN_REPO_DIR="${T}/maven-repo/" while
>>> Debian has REPO=/usr/share/maven-repo. Since the file-system will be
>>> read-only for ebuilds, and ebuilds should be built offline, what's the
>>> purpose of this?
>>
>> We then still need to add symlinks to jars during build time in there
>> which is an "access violation" in sand box
>
> Ok. Then the viable option is to have to generate the maven directory
> structure inside a folder named ${T}/maven-repo. We can do the symlinking
> through that, and we won't face any access violation since the writing
> happens in the sandbox.
> Ubuntu too have proposed a similar solution. I'm away from my machine, I'll
> provide the links to it as well as for the JPackage soon if it you all may
> want to check it out!

For the JPackage see [1]. [1] doesn't give a formatted output though.
Properly formatted version is to [2]
Ubuntu's maven support specification is at [3].

I've started writing a proposal. I'll upload it to melange, when it
comes to a good state.

[1] http://www.jpackage.org/cgi-bin/viewvc.cgi/jpackage/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=1.2&view=markup
[2] http://dl.dropbox.com/u/4783109/gentoo-maven-integration/read/%5Bjpackage%5D%20Contents%20of%20%20src%20jpackage-utils%20doc%20jpackage-1.5-policy.html

[3] https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec

Thanks,
--Kasun

>
> Thanks,
> Kasun
>
>>
>> - --
>> Sincerely,
>> Serkan KABA
>> Gentoo Developer
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.17 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk2RWvIACgkQRh6X64ivZaLfkgCfVF99iZaa6Pa+dTlC4cjuLvZd
>> ILkAn34OooCvrNy6uu9yEg4bua/q7X6G
>> =staW
>> -----END PGP SIGNATURE-----
>>
>
>



-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg

Re: [gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

[Kasun Gajasinghe]

Hi all,
I've submitted my proposal of "Apache Maven Integration for Gentoo
EBuilds Update" at [1]. Much appreciate if you all can go through and
let me know if there's any changes needed.

[1] http://socghop.appspot.com/gsoc/proposal/review/google/gsoc2011/kasun_gajasinghe/1


Thanks,
Kasun


On Wed, Mar 30, 2011 at 10:41 AM, Kasun Gajasinghe <kasunbg@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 8:41 PM, Kasun Gajasinghe <kasunbg@gmail.com> wrote:
>>
>>
>> On 29 Mar 2011, at 09:37, Serkan Kaba <serkan@gentoo.org> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 29-03-2011 06:47, Kasun Gajasinghe wrote:
>>>>
>>>> I'd like to know how the dependencies will be handled by maven based
>>>> ebuilds. Can you let me know the difference between dependencies
>>>> specified in Maven's POM file, and ebuild's dependencies? Are both
>>>> should be same? Since, Maven's POM contains the unique artifacts IDs
>>>> (with the combination of groupId, artifactId, version) which points to
>>>> a _binary_ jar, how should the developers who write _ebuilds_ specify
>>>> it? I got to know that dependencies are also ebuilds under gentoo i.e.
>>>> no binaries.
>>>
>>> POM dependencies can be too restrictive sometimes, like depending on a
>>> specific version. We should be depending on any version (or sometimes
>>> with >=,<=) as long as the package compiles and runs fine with it.
>>
>> I've come across a package called JPackage which does the job of retrieving
>> a jar from /usr/share/java and return it to use by maven. It neglects the
>> version numbers as well.
>>
>>
>>>> I've been going through the Ralph's (nick: sera ) suggested eclass
>>>> [1]. It turned out to be very useful. (sera, I got your name from [1],
>>>> hope it's correct! :) ). Because maven offline building is the biggest
>>>> issue Gentoo is currently facing, As Petteri suggested, I've been
>>>> going through to see how other distributions handle this. I see that
>>>> both in sera's eclass and in Debian's MavenRepoSpec [2], that they
>>>> specify a variable which points to a maven local-repository location.
>>>> Ralph's eclass specified MAVEN_REPO_DIR="${T}/maven-repo/" while
>>>> Debian has REPO=/usr/share/maven-repo. Since the file-system will be
>>>> read-only for ebuilds, and ebuilds should be built offline, what's the
>>>> purpose of this?
>>>
>>> We then still need to add symlinks to jars during build time in there
>>> which is an "access violation" in sand box
>>
>> Ok. Then the viable option is to have to generate the maven directory
>> structure inside a folder named ${T}/maven-repo. We can do the symlinking
>> through that, and we won't face any access violation since the writing
>> happens in the sandbox.
>> Ubuntu too have proposed a similar solution. I'm away from my machine, I'll
>> provide the links to it as well as for the JPackage soon if it you all may
>> want to check it out!
>
> For the JPackage see [1]. [1] doesn't give a formatted output though.
> Properly formatted version is to [2]
> Ubuntu's maven support specification is at [3].
>
> I've started writing a proposal. I'll upload it to melange, when it
> comes to a good state.
>
> [1] http://www.jpackage.org/cgi-bin/viewvc.cgi/jpackage/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=1.2&view=markup
> [2] http://dl.dropbox.com/u/4783109/gentoo-maven-integration/read/%5Bjpackage%5D%20Contents%20of%20%20src%20jpackage-utils%20doc%20jpackage-1.5-policy.html
>
> [3] https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec
>
> Thanks,
> --Kasun
>
>>
>> Thanks,
>> Kasun
>>
>>>
>>> - --
>>> Sincerely,
>>> Serkan KABA
>>> Gentoo Developer
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v2.0.17 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAk2RWvIACgkQRh6X64ivZaLfkgCfVF99iZaa6Pa+dTlC4cjuLvZd
>>> ILkAn34OooCvrNy6uu9yEg4bua/q7X6G
>>> =staW
>>> -----END PGP SIGNATURE-----
>>>
>>
>>
>
>
>
> --
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe,
> University of Moratuwa,
> Sri Lanka.
> Blog: http://kasunbg.blogspot.com
> Twitter: http://twitter.com/kasunbg
>



-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg

[gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

[Kasun Gajasinghe]

[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]

Hi Petteri and devs,
I'm Kasun Gajasinghe, a final year undergraduate from University of
Moratuwa. I'm interested in contributing to Gentoo under Google Summer of
Code 2011 program.

I've gone through the ideas page, and found the project idea "Maven
integration" [0] very interesting, mainly because I have a good background
on that area. I've gone through "Quickstart Ebuild Guide" [1] to understand
how ebuilding works, and then went through Gentoo java-overlay [2] since
it's a suggested approach. It's exciting to see that they are looking for
new Java developers! I have already checked out the java-overlay source, and
started poking around.

As I understood, the main goal of the project is generating an ebuild file
by parsing maven project file (POM), right? If so, I think it's better if I
looked at how the current maven-based projects are integrated to Gentoo.
Further, I'd very much appreciate if you can provide me some directives and
guide me. Specially, I'm looking for documentation/articles explaining how
Maven is currently used in the system, current status of Maven in
java-overlay, and documentation to understand how Gentoo Java-Overlay works.
Please tell me if I missed something important.

Further, I welcome any advices that you'd like to give for a beginner Gentoo
developer interested in contriuting.

To justify my ability to complete the project, I thought to provide a brief
introduction about my self. I'm a linux-user and Ubuntu has been my default
OS for few years now. I've used different flavors including Fedora, and
Kubuntu, and I'm now interested in using Gentoo. I am very much competent in
Java and Apache Maven and has good experience. I have used Maven for several
projects of mine, along with other open sources projects am contributing.
Some of the projects are hosted at Google code [3]. I've participated for
Google Summer of Code in 2010 under DocBook Open Repository and successfully
completed the project [4].


[0] http://www.gentoo.org/proj/en/userrel/soc/ideas.xml#doc_chap2_sect20
[1] http://devmanual.gentoo.org/quickstart/index.html
[2] http://overlays.gentoo.org/proj/java/

[3] http://code.google.com/u/kasun.gajasinghe/
[4] http://blog.kasunbg.org/search/label/gsoc-2010

Thanks,
Kasun

-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg

[-- Attachment #2: Type: text/html, Size: 3856 bytes --]

Re: [gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

On Fri, 2011-03-25 at 23:50 +0530, Kasun Gajasinghe wrote:
> Hi Petteri and devs,
> I'm Kasun Gajasinghe, a final year undergraduate from University of
> Moratuwa. I'm interested in contributing to Gentoo under Google Summer
> of Code 2011 program. 
> 
> 
> I've gone through the ideas page, and found the project idea "Maven
> integration" [0] very interesting, mainly because I have a good
> background on that area. I've gone through "Quickstart Ebuild
> Guide" [1] to understand how ebuilding works, and then went through
> Gentoo java-overlay [2] since it's a suggested approach. It's exciting
> to see that they are looking for new Java developers! I have already
> checked out the java-overlay source, and started poking around. 
> 
> 
> As I understood, the main goal of the project is generating an ebuild
> file by parsing maven project file (POM), right? If so, I think it's
> better if I looked at how the current maven-based projects are
> integrated to Gentoo. 

disclaimer: I know nothing of maven, but...

hmm, this sounds a lot like it could make use of g-common from last
years gsoc.   G-common is a universal overlay/ebuild generator for
converting one packaging system into gentoo's by using drivers for the
format being scanned.  I have added g-common repository type into
layman-9999.  Currently g-common and the g-cran driver is in the science
overlay as app-portage/g-cran. 

For more info contact bicatali (project mentor) and/or Auke Booij
<auke@tulcod.com> the student creator for more detail about it.


> Further, I'd very much appreciate if you can provide me some
> directives and guide me. Specially, I'm looking for
> documentation/articles explaining how Maven is currently used in the
> system, current status of Maven in java-overlay, and documentation to
> understand how Gentoo Java-Overlay works. Please tell me if I missed
> something important. 


-- 
Brian Dolbec <brian.dolbec@gmail.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

[Serkan Kaba]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26-03-2011 22:35, Brian Dolbec wrote:
> hmm, this sounds a lot like it could make use of g-common from last
> years gsoc.   G-common is a universal overlay/ebuild generator for
> converting one packaging system into gentoo's by using drivers for the
> format being scanned.  I have added g-common repository type into
> layman-9999.  Currently g-common and the g-cran driver is in the science
> overlay as app-portage/g-cran. 
It's a build tool rather than a packaging system.

- -- 
Sincerely,
Serkan KABA
Gentoo Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2OUo8ACgkQRh6X64ivZaJNZgCeNCzp8uKCfwz9vwdYed3sp2W6
yj4AnAnHtpDrFtrV/CdpYYkogGdq7Wlw
=xWLO
-----END PGP SIGNATURE-----

Re: [gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

[Kasun Gajasinghe]

Hi,
Thank you both Brian and Serkan for the replies. Brian, I'm evaluating
the possibility of using Java-overlay for this project, so any
pointers regarding that clearly helps since I'm new to the
environment.

These days I'm trying to figure out and list the requirements for the
project. The idea page only contain a brief description. I'd very much
appreciate if anyone can give some further information regarding this
idea. I'm little depressed with lesser support because Google Summer
of Code is time-constrained which means I have to do a good initial
research and submit a proposal in a 1 1/2 weeks time. I guess it's
probably because of weekends?

Thanks,
--Kasun

On Sun, Mar 27, 2011 at 2:24 AM, Serkan Kaba <serkan@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 26-03-2011 22:35, Brian Dolbec wrote:
>> hmm, this sounds a lot like it could make use of g-common from last
>> years gsoc.   G-common is a universal overlay/ebuild generator for
>> converting one packaging system into gentoo's by using drivers for the
>> format being scanned.  I have added g-common repository type into
>> layman-9999.  Currently g-common and the g-cran driver is in the science
>> overlay as app-portage/g-cran.
> It's a build tool rather than a packaging system.
>
> - --
> Sincerely,
> Serkan KABA
> Gentoo Developer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2OUo8ACgkQRh6X64ivZaJNZgCeNCzp8uKCfwz9vwdYed3sp2W6
> yj4AnAnHtpDrFtrV/CdpYYkogGdq7Wlw
> =xWLO
> -----END PGP SIGNATURE-----
>
>



-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg

Re: [gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

On 03/27/2011 08:09 AM, Kasun Gajasinghe wrote:

> 
> These days I'm trying to figure out and list the requirements for the
> project. The idea page only contain a brief description. I'd very much
> appreciate if anyone can give some further information regarding this
> idea. I'm little depressed with lesser support because Google Summer
> of Code is time-constrained which means I have to do a good initial
> research and submit a proposal in a 1 1/2 weeks time. I guess it's
> probably because of weekends?
> 

As much as GSoC is time-constrained so are our personal lives. Some
delays come with the territory of volunteer work. For the basic goal of
the project we would like to be able to natively use Maven in Java
packages in the main tree. Currently we for example use the ant:ant
target to generate build.xml and then sanitize that. As we would like
these ebuilds to be dependencies for others an ebuild generator like
proposed by Brian doesn't cut it alone. A generator could of course be
useful in the process of generating ebuilds that are good enough to be
committed to Portage. I think both Fedora and Debian have already been
able to accomplish this so I would do some research into their
solutions. Here's some quick Google results to get you started:

http://wiki.debian.org/Java/MavenBuilder
http://fedoraproject.org/wiki/Packaging/Java#maven2

If you want to have an online discussion or ask any questions you might
have interactively you can find the Java developers at
#gentoo-java@freenode. Please note that depending on how time zones
match we might not always be around.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

[Kasun Gajasinghe]

Hi all,

On Sun, Mar 27, 2011 at 1:59 PM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> On 03/27/2011 08:09 AM, Kasun Gajasinghe wrote:
>
>>
>> These days I'm trying to figure out and list the requirements for the
>> project. The idea page only contain a brief description. I'd very much
>> appreciate if anyone can give some further information regarding this
>> idea. I'm little depressed with lesser support because Google Summer
>> of Code is time-constrained which means I have to do a good initial
>> research and submit a proposal in a 1 1/2 weeks time. I guess it's
>> probably because of weekends?
>>
>
> As much as GSoC is time-constrained so are our personal lives. Some
> delays come with the territory of volunteer work.

I apologize for asking that. It won't happen again.

For the basic goal of
> the project we would like to be able to natively use Maven in Java
> packages in the main tree. Currently we for example use the ant:ant
> target to generate build.xml and then sanitize that. As we would like
> these ebuilds to be dependencies for others an ebuild generator like
> proposed by Brian doesn't cut it alone. A generator could of course be
> useful in the process of generating ebuilds that are good enough to be
> committed to Portage. I think both Fedora and Debian have already been
> able to accomplish this so I would do some research into their
> solutions. Here's some quick Google results to get you started:
>
> http://wiki.debian.org/Java/MavenBuilder
> http://fedoraproject.org/wiki/Packaging/Java#maven2
>
> If you want to have an online discussion or ask any questions you might
> have interactively you can find the Java developers at
> #gentoo-java@freenode. Please note that depending on how time zones
> match we might not always be around.

Thanks for the pointers again. After the discussion at the IRC, I've
been going through those recommended references. I think I have a
fairly good idea about the requirements now. I have few further
questions.

I'd like to know how the dependencies will be handled by maven based
ebuilds. Can you let me know the difference between dependencies
specified in Maven's POM file, and ebuild's dependencies? Are both
should be same? Since, Maven's POM contains the unique artifacts IDs
(with the combination of groupId, artifactId, version) which points to
a _binary_ jar, how should the developers who write _ebuilds_ specify
it? I got to know that dependencies are also ebuilds under gentoo i.e.
no binaries.

I've been going through the Ralph's (nick: sera ) suggested eclass
[1]. It turned out to be very useful. (sera, I got your name from [1],
hope it's correct! :) ). Because maven offline building is the biggest
issue Gentoo is currently facing, As Petteri suggested, I've been
going through to see how other distributions handle this. I see that
both in sera's eclass and in Debian's MavenRepoSpec [2], that they
specify a variable which points to a maven local-repository location.
Ralph's eclass specified MAVEN_REPO_DIR="${T}/maven-repo/" while
Debian has REPO=/usr/share/maven-repo. Since the file-system will be
read-only for ebuilds, and ebuilds should be built offline, what's the
purpose of this?

Further, please let me know the other issues that needs to be
addressed that you have in mind. It turned out that the project is
challenging than I thought before, and is getting exciting now!

[1] http://paste.pocoo.org/show/360442/
[2] http://wiki.debian.org/Java/MavenRepoSpec#Problems_with_upstream.27s_repository_.28central.29

Thanks for the help.
--Kasun

PS: Sorry for cross-posting this to gentoo-java and gentoo-soc.
Thought to do it for _this_ period of time since Donnie has agreed
that it's important to make the interactions with the community
visible to all the mentors. I hope it's OK!

-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg

Re: [gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

[Serkan Kaba]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29-03-2011 06:47, Kasun Gajasinghe wrote:
> I'd like to know how the dependencies will be handled by maven based
> ebuilds. Can you let me know the difference between dependencies
> specified in Maven's POM file, and ebuild's dependencies? Are both
> should be same? Since, Maven's POM contains the unique artifacts IDs
> (with the combination of groupId, artifactId, version) which points to
> a _binary_ jar, how should the developers who write _ebuilds_ specify
> it? I got to know that dependencies are also ebuilds under gentoo i.e.
> no binaries.
POM dependencies can be too restrictive sometimes, like depending on a
specific version. We should be depending on any version (or sometimes
with >=,<=) as long as the package compiles and runs fine with it.
> I've been going through the Ralph's (nick: sera ) suggested eclass
> [1]. It turned out to be very useful. (sera, I got your name from [1],
> hope it's correct! :) ). Because maven offline building is the biggest
> issue Gentoo is currently facing, As Petteri suggested, I've been
> going through to see how other distributions handle this. I see that
> both in sera's eclass and in Debian's MavenRepoSpec [2], that they
> specify a variable which points to a maven local-repository location.
> Ralph's eclass specified MAVEN_REPO_DIR="${T}/maven-repo/" while
> Debian has REPO=/usr/share/maven-repo. Since the file-system will be
> read-only for ebuilds, and ebuilds should be built offline, what's the
> purpose of this?
We then still need to add symlinks to jars during build time in there
which is an "access violation" in sand box.

- -- 
Sincerely,
Serkan KABA
Gentoo Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2RWvIACgkQRh6X64ivZaLfkgCfVF99iZaa6Pa+dTlC4cjuLvZd
ILkAn34OooCvrNy6uu9yEg4bua/q7X6G
=staW
-----END PGP SIGNATURE-----

Re: [gentoo-soc] [GSoC] Maven integration for Gentoo ebuilds

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

On 03/29/2011 06:47 AM, Kasun Gajasinghe wrote:
> 
> I'd like to know how the dependencies will be handled by maven based
> ebuilds. Can you let me know the difference between dependencies
> specified in Maven's POM file, and ebuild's dependencies? Are both
> should be same? Since, Maven's POM contains the unique artifacts IDs
> (with the combination of groupId, artifactId, version) which points to
> a _binary_ jar, how should the developers who write _ebuilds_ specify
> it? I got to know that dependencies are also ebuilds under gentoo i.e.
> no binaries.
> 

I am not sure how POM files categorize dependencies but in general there
should be some kind of a mapping between the two.

> I've been going through the Ralph's (nick: sera ) suggested eclass
> [1]. It turned out to be very useful. (sera, I got your name from [1],
> hope it's correct! :) ). Because maven offline building is the biggest
> issue Gentoo is currently facing, As Petteri suggested, I've been
> going through to see how other distributions handle this. I see that
> both in sera's eclass and in Debian's MavenRepoSpec [2], that they
> specify a variable which points to a maven local-repository location.
> Ralph's eclass specified MAVEN_REPO_DIR="${T}/maven-repo/" while
> Debian has REPO=/usr/share/maven-repo. Since the file-system will be
> read-only for ebuilds, and ebuilds should be built offline, what's the
> purpose of this?
> 

${T} is a temporary directory for a single ebuild so it's writable.

> Further, please let me know the other issues that needs to be
> addressed that you have in mind. It turned out that the project is
> challenging than I thought before, and is getting exciting now!
> 

Besides writing the needed infrastructure for building with Maven it
would also be useful to convert as much as possible of our manual
ebuilds to use that infrastructure so that the solution will also be
field tested. I see the work happening initially in a separate overlay
with the goal of main tree merging before the project is over.

Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]