Обсуждение: Please consider using Maven
Hi, I'm a Debian maintainer working on a package that uses postgresql. I've to fix the debian packaging of the jdbs lib because it does not come with maven's pom.xml files. - That has nothing to do with you. However I noticed, that you don't use maven. From a packagers point of view it's very very convenient, if java libraries all have a common layout and if they declare their dependencies in a pom.xml. I know that maven is crappy, but it's a better then having to deal with hundreds of different flavours of crap in ant projects. So I'd like to encourage you to re-consider using maven. Please. Regards, Thomas Koch, http://www.koch.ro
Hi, I'm a Debian maintainer working on a package that uses postgresql. However I noticed, that you don't use maven.
We(the community) are working to make one of the finest database systems in the world even better day-by-day. We expect people to look at it the same way. It is 'do-ers' world in open source. If you want something,best way is to do it yourself and if you feel it is good,please consider *giving back*.
Please do not expect us to be providing you with full time and extensive support on every issue/feature you want. When we suggest that you "do it yourself" this is in the spirit of open source where you give back.
Atri & Dave
Thomas, I would have no problem publishing to maven if someone wants to do the work to make it happen. As far as using maven goes. The way the driver is built is highly dependent on ant, and it works very well. This would be a considerable amount of work with very limited benefit to the project. Also the project has no dependencies beyond junit, for testing. Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Thu, Aug 2, 2012 at 8:11 AM, Thomas Koch <thomas@koch.ro> wrote: > Hi, > > I'm a Debian maintainer working on a package that uses postgresql. I've to fix > the debian packaging of the jdbs lib because it does not come with maven's > pom.xml files. - That has nothing to do with you. > > However I noticed, that you don't use maven. > > From a packagers point of view it's very very convenient, if java libraries > all have a common layout and if they declare their dependencies in a pom.xml. > I know that maven is crappy, but it's a better then having to deal with > hundreds of different flavours of crap in ant projects. > > So I'd like to encourage you to re-consider using maven. Please. > > Regards, > > Thomas Koch, http://www.koch.ro > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
On 08/03/2012 01:11 AM, Dave Cramer wrote: > Thomas, > > I would have no problem publishing to maven if someone wants to do the > work to make it happen. I work with Maven a lot and like it. Mostly. I thought about trying to Mavenize the JDBC driver a while ago but before I proposed it here I took at look at the build.xml and decided it wasn't so important after all ;-) PgJDBC has all that that funky business for handling different JDBC levels and compilation with different JDKs. It's not especially challenging to do with Maven, but it complicates things a bit. When I last looked I didn't know enough about Maven to be able to tackle it. Knowing that you're OK with moving it over to Maven is interesting. If I'm ever feeling the lack of pain and suffering in my day to day development I might give the conversion a go ;-) -- Craig Ringer
Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Thu, Aug 2, 2012 at 8:07 PM, Craig Ringer <ringerc@ringerc.id.au> wrote: > On 08/03/2012 01:11 AM, Dave Cramer wrote: >> >> Thomas, >> >> I would have no problem publishing to maven if someone wants to do the >> work to make it happen. > > > I work with Maven a lot and like it. Mostly. I thought about trying to > Mavenize the JDBC driver a while ago but before I proposed it here I took at > look at the build.xml and decided it wasn't so important after all ;-) > > PgJDBC has all that that funky business for handling different JDBC levels > and compilation with different JDKs. It's not especially challenging to do > with Maven, but it complicates things a bit. When I last looked I didn't > know enough about Maven to be able to tackle it. > > Knowing that you're OK with moving it over to Maven is interesting. If I'm > ever feeling the lack of pain and suffering in my day to day development I > might give the conversion a go ;-) > > -- > Craig Ringer Craig, What I said was I would be OK with publishing to maven, not using Maven for building it. I don't see any upside for the amount of work involved. As you say the build is complicated and works well with Ant. Dave
On 08/03/2012 08:29 AM, Dave Cramer wrote: > What I said was I would be OK with publishing to maven, not using > Maven for building it. I don't see any upside for the amount of work > involved. As you say the build is complicated and works well with Ant. Phew. I'm not sad about that. Extending the build with maven-ant-tasks for artifact creation and deployment would make sense. I haven't used it before, but it doesn't look too bad. I'll see what I can rig up. -- Craig Ringer
Hi Craig, I suggest aiming higher and migrating to Gradle. There are a couple of main reasons. Gradle allows the flexibility of Ant builds only better because scripting is not in XML. Instead Groovy which is less painful to script. The second is Gradle supports deployment to artifact repositories including Nexus. Meeting the needs of Thomas. http://www.gradle.org/ You will probably find it less painful than using Maven. Regards, Jeremy On 03/08/12 01:48, Craig Ringer wrote: > On 08/03/2012 08:29 AM, Dave Cramer wrote: > >> What I said was I would be OK with publishing to maven, not using >> Maven for building it. I don't see any upside for the amount of work >> involved. As you say the build is complicated and works well with Ant. > > Phew. I'm not sad about that. > > Extending the build with maven-ant-tasks for artifact creation and > deployment would make sense. I haven't used it before, but it doesn't > look too bad. I'll see what I can rig up. > > -- > Craig Ringer > >
Jeremy Whiting <jwhiting@redhat.com> wrote: > I suggest aiming higher and migrating to Gradle. There are a > couple of main reasons. Gradle allows the flexibility of Ant > builds only better because scripting is not in XML. Instead Groovy > which is less painful to script. The second is Gradle supports > deployment to artifact repositories including Nexus. Meeting the > needs of Thomas. > > http://www.gradle.org/ > > You will probably find it less painful than using Maven. *If* we're going to a different build tool than Ant, I can attest that Maven is probably a bad choice. Our shop switched new development to it, and it was slow, complicated, and a resource hog. Even the original proponents got behind changing off of it a few months after we got it going. We then switched to Gradle, which has been relatively pain-free. The big question is whether anyone is interested enough in making that change to put the work into providing a patch that switches things from Ant to Gradle so that people can try it out and make an informed decision about whether they want to commit that to the repository. That's certainly not going to be me. ;-) I think this fits squarely into the open-source tradition of whoever has the itch (finds the current state of affairs inconvenient) has to be the one to scratch it or it won't get done. If everyone does that and shares the results, we all benefit. That's how PostgreSQL got here, and that's how it evolves. I forget who was complaining about having to pay for two days of programming effort to add a feature they wanted, but I remember they addressed the list saying "It's *your* product." I really should have pointed out that really, if he's using it's his as much as anyone else's. He's getting the benefit of (easily) tens of thousands of hours of work which individuals or their employers have donated to the community. I'm not sure why donating the 16 hours that were on his dime has his back up, especially (as someone else pointed out) it just means more work for him down the line when a new driver comes out. http://wiki.postgresql.org/wiki/FAQ#Who_controls_PostgreSQL.3F -Kevin
Maven definitely can handle that, one solution can be using profiles for different jdbc versions. (http://maven.apache.org/guides/introduction/introduction-to-profiles.html) For all those "if then include" entries in build.xml: <include name="${package}/jdbc3/Jdbc3Array.java" if="jdbc3"/> It can be archived by use maven compiler plugin, includes filter (http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html) <build> <sourceDirectory>../src/main/java</sourceDirectory> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.2</version> <configuration> <includes><include>**/jdbc3/**</include></includes> </configuration> </plugin> </plugins> </build> I do see the benefit for pgsql-jdbc project to migrating to maven. The standard and conversion brought by maven makes it much easier to write patch and test for a project without have to spend time read a customized ant build.xml and README for some basic jobs (compile/test/build). I once wanted to contribute back an hstore enhancement but gave up after spending 5 mins into build.xml.(Yes, I am lazy. I don't want to spend more than 5 mins to understand a customized build/test process.) Here is a half way migration (example only, I am not sure if I would have time to complete it), only fixed to do one job: compile for jdbc4: https://github.com/sinbadblue/pgjdbc/tree/maven_migration To reduce the initial conversion work, I only changed directories structure and leverage existing ant target "driver" to build for java version 1.6(jdbc4 flavor) only. __________________________ Shijun Kong On 8/2/12 8:07 PM, "Craig Ringer" <ringerc@ringerc.id.au> wrote: >On 08/03/2012 01:11 AM, Dave Cramer wrote: >> Thomas, >> >> I would have no problem publishing to maven if someone wants to do the >> work to make it happen. > >I work with Maven a lot and like it. Mostly. I thought about trying to >Mavenize the JDBC driver a while ago but before I proposed it here I >took at look at the build.xml and decided it wasn't so important after >all ;-) > >PgJDBC has all that that funky business for handling different JDBC >levels and compilation with different JDKs. It's not especially >challenging to do with Maven, but it complicates things a bit. When I >last looked I didn't know enough about Maven to be able to tackle it. > >Knowing that you're OK with moving it over to Maven is interesting. If >I'm ever feeling the lack of pain and suffering in my day to day >development I might give the conversion a go ;-) > >-- >Craig Ringer > >-- >Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-jdbc This email message and any attachments may contain legally privileged or confidential information intended solely for theuse of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient,you are hereby notified that any reading, dissemination, distribution or copying of this message or its attachmentsis strictly prohibited. If you have received this message in error, please notify us immediately by telephone,fax or email and delete the message and all attachments to the message. Any views or opinions expressed are solelythose of the author and do not necessarily represent those of Investor Analytics LLC.
Well clearly the maintainers of the driver are much more comfortable using ant. So your solution would have *us* relearn a new tool. Why not use gradle as someone else suggested? Or the next new super duper build system when it comes out? I think our time is better spent adding features not refactoring the build system. Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Thu, Aug 9, 2012 at 5:42 PM, Shijun Kong <skong@investoranalytics.com> wrote: > > Maven definitely can handle that, one solution can be using profiles for > different jdbc versions. > (http://maven.apache.org/guides/introduction/introduction-to-profiles.html) > > For all those "if then include" entries in build.xml: > <include name="${package}/jdbc3/Jdbc3Array.java" if="jdbc3"/> > > It can be archived by use maven compiler plugin, includes filter > (http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html) > > <build> > <sourceDirectory>../src/main/java</sourceDirectory> > > <plugins> > <plugin> > <artifactId>maven-compiler-plugin</artifactId> > <version>2.0.2</version> > <configuration> > <includes><include>**/jdbc3/**</include></includes> > </configuration> > </plugin> > </plugins> > </build> > > > > I do see the benefit for pgsql-jdbc project to migrating to > maven. The standard and conversion brought by maven makes it much easier > to write patch and test for a project without have to spend time read a > customized ant build.xml and README for some basic jobs > (compile/test/build). I once wanted to contribute back an hstore > enhancement but gave up after spending 5 mins into build.xml.(Yes, I am > lazy. I don't want to spend more than 5 mins to understand a customized > build/test process.) > > Here is a half way migration (example only, I am not sure if I would have > time to complete it), only fixed to do one job: compile for jdbc4: > https://github.com/sinbadblue/pgjdbc/tree/maven_migration > > To reduce the initial conversion work, I only changed directories > structure and leverage existing ant target "driver" to build for java > version 1.6(jdbc4 flavor) only. > __________________________ > > Shijun Kong > > > On 8/2/12 8:07 PM, "Craig Ringer" <ringerc@ringerc.id.au> wrote: > >>On 08/03/2012 01:11 AM, Dave Cramer wrote: >>> Thomas, >>> >>> I would have no problem publishing to maven if someone wants to do the >>> work to make it happen. >> >>I work with Maven a lot and like it. Mostly. I thought about trying to >>Mavenize the JDBC driver a while ago but before I proposed it here I >>took at look at the build.xml and decided it wasn't so important after >>all ;-) >> >>PgJDBC has all that that funky business for handling different JDBC >>levels and compilation with different JDKs. It's not especially >>challenging to do with Maven, but it complicates things a bit. When I >>last looked I didn't know enough about Maven to be able to tackle it. >> >>Knowing that you're OK with moving it over to Maven is interesting. If >>I'm ever feeling the lack of pain and suffering in my day to day >>development I might give the conversion a go ;-) >> >>-- >>Craig Ringer >> >>-- >>Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >>To make changes to your subscription: >>http://www.postgresql.org/mailpref/pgsql-jdbc > > > This email message and any attachments may contain legally privileged or confidential information intended solely forthe use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient,you are hereby notified that any reading, dissemination, distribution or copying of this message or its attachmentsis strictly prohibited. If you have received this message in error, please notify us immediately by telephone,fax or email and delete the message and all attachments to the message. Any views or opinions expressed are solelythose of the author and do not necessarily represent those of Investor Analytics LLC. > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
You are right. That's the point: "the maintainers of the driver are much more comfortable using ant.", be more accurate, this ant build.xml (or ant program, ant script?) I did projects with ant and maven (both for small teams less than 10 and large teams with more than 100 developers). Per my personal experience, when a project grows to a certain size, complexity and a team with more than handful people, ant build.xml files themselves becomes a part of code hard to maintain/enhance/test. On the other hand, maven is much standard, consistent for 99% jobs. When a new developer get source code with ant, he/she has to spend time read instrument, understand step 1,2,3 to compile/test/build a project. If using maven, it's always maven clean compile test package install. I will stop here, looks like the topic is moving to ant V.S maven instead of how could we make pgsql-jdbc easier for outsider to play and contribute. It's light a fanboy war between Android and iOS. As you said, "I think our time is better spent adding features not refactoring the build system." __________________________ Shijun Kong On 8/10/12 6:33 AM, "Dave Cramer" <pg@fastcrypt.com> wrote: >Well clearly the maintainers of the driver are much more comfortable >using ant. So your solution would have *us* relearn a new tool. > >Why not use gradle as someone else suggested? Or the next new super >duper build system when it comes out? > >I think our time is better spent adding features not refactoring the >build system. > > >Dave Cramer > >dave.cramer(at)credativ(dot)ca >http://www.credativ.ca > > >On Thu, Aug 9, 2012 at 5:42 PM, Shijun Kong <skong@investoranalytics.com> >wrote: >> >> Maven definitely can handle that, one solution can be using profiles for >> different jdbc versions. >> >>(http://maven.apache.org/guides/introduction/introduction-to-profiles.htm >>l) >> >> For all those "if then include" entries in build.xml: >> <include name="${package}/jdbc3/Jdbc3Array.java" if="jdbc3"/> >> >> It can be archived by use maven compiler plugin, includes filter >> >>(http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html) >> >> <build> >> <sourceDirectory>../src/main/java</sourceDirectory> >> >> <plugins> >> <plugin> >> <artifactId>maven-compiler-plugin</artifactId> >> <version>2.0.2</version> >> <configuration> >> <includes><include>**/jdbc3/**</include></includes> >> </configuration> >> </plugin> >> </plugins> >> </build> >> >> >> >> I do see the benefit for pgsql-jdbc project to migrating to >> maven. The standard and conversion brought by maven makes it much easier >> to write patch and test for a project without have to spend time read a >> customized ant build.xml and README for some basic jobs >> (compile/test/build). I once wanted to contribute back an hstore >> enhancement but gave up after spending 5 mins into build.xml.(Yes, I am >> lazy. I don't want to spend more than 5 mins to understand a customized >> build/test process.) >> >> Here is a half way migration (example only, I am not sure if I would >>have >> time to complete it), only fixed to do one job: compile for jdbc4: >> https://github.com/sinbadblue/pgjdbc/tree/maven_migration >> >> To reduce the initial conversion work, I only changed directories >> structure and leverage existing ant target "driver" to build for java >> version 1.6(jdbc4 flavor) only. >> __________________________ >> >> Shijun Kong >> >> >> On 8/2/12 8:07 PM, "Craig Ringer" <ringerc@ringerc.id.au> wrote: >> >>>On 08/03/2012 01:11 AM, Dave Cramer wrote: >>>> Thomas, >>>> >>>> I would have no problem publishing to maven if someone wants to do the >>>> work to make it happen. >>> >>>I work with Maven a lot and like it. Mostly. I thought about trying to >>>Mavenize the JDBC driver a while ago but before I proposed it here I >>>took at look at the build.xml and decided it wasn't so important after >>>all ;-) >>> >>>PgJDBC has all that that funky business for handling different JDBC >>>levels and compilation with different JDKs. It's not especially >>>challenging to do with Maven, but it complicates things a bit. When I >>>last looked I didn't know enough about Maven to be able to tackle it. >>> >>>Knowing that you're OK with moving it over to Maven is interesting. If >>>I'm ever feeling the lack of pain and suffering in my day to day >>>development I might give the conversion a go ;-) >>> >>>-- >>>Craig Ringer >>> >>>-- >>>Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >>>To make changes to your subscription: >>>http://www.postgresql.org/mailpref/pgsql-jdbc >> >> >> This email message and any attachments may contain legally privileged >>or confidential information intended solely for the use of the >>individual or entity to whom it is addressed. If the reader of this >>message is not the intended recipient, you are hereby notified that any >>reading, dissemination, distribution or copying of this message or its >>attachments is strictly prohibited. If you have received this message in >>error, please notify us immediately by telephone, fax or email and >>delete the message and all attachments to the message. Any views or >>opinions expressed are solely those of the author and do not necessarily >>represent those of Investor Analytics LLC. >> >> -- >> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-jdbc This email message and any attachments may contain legally privileged or confidential information intended solely for theuse of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient,you are hereby notified that any reading, dissemination, distribution or copying of this message or its attachmentsis strictly prohibited. If you have received this message in error, please notify us immediately by telephone,fax or email and delete the message and all attachments to the message. Any views or opinions expressed are solelythose of the author and do not necessarily represent those of Investor Analytics LLC.