Maven, I would say don't do it. I just think the whole thing is an
extremely mediocre tool at best. One of the problems in debating this will
be that people who know it well generally like it, because if you do not
like it then don't use it. The culture also seems to be one of benign
tyranny. Suggesting it should be used and then assuming you just
misunderstand the benefits when you say you do not want to.
Incidentally I actually kinda wrote something which does something similar
to Maven, and use it every day internally (called ebuild - although I long
gave up trying to promote it, it is still publically available and still
updated). At the time I actually wrote some articles on the subject of why
Maven is not good.
http://www.ebuild-project.org/articles/maven_a_good_idea.html
http://www.ebuild-project.org/articles/maven_the_bad_parts.html
I feel I do have a good grasp on the subject of building software, but not
sure how authoratative the 2nd article is however since it is a while since
I wrote it and I never really finished it. (Also it is a few years so Maven
may have progressed since then).
That said, when I have delved into the h2 code (not as much as I would have
liked to have done) I have wished it was more modular (dare I say
ebuild-ized, you'd have to take it from me that that is a good thing as the
only real expert on the subject).
In my opinion, at the very least things which exist as different
programs/products (i.e. generally jar files) should have different
(ecilpse) projects and different build paths. It is just better organised
and much clearer when things are explicitly separate like that (although it
may take some getting used to).
Separating like this inevitably leads to more projects as you then want to
have code in shared library projects. This then leads to the issue of how
can you have a build setup and an IDE setup which are configured in the
same way...etc... etc. then you need a build and dependency management tool!
I could go on, but that's probably enough from me!
Mike
- mike
On Tue, Jan 28, 2014 at 6:06 PM, Thomas Mueller <
thomas.tom.muel...@gmail.com> wrote:
> Hi,
>
> As I wrote, I'm not currently interested to completely Mavenize H2. The
> risks I see is added complexity, without equivalent benefit. For example, I
> don't want to split H2 into many sub-projects. Also, the tests should be
> reusable and not just work with one specific setting. I don't want to make
> things complicated.
>
> But let's see, maybe it's not as complicated as I thought!
>
> Travis: In theory, it could be used. Currently, I run the build on a spare
> machine. The only problem is, it is currently not automated, because the
> WIFI connection is not reliable... The problem with Travis is, we would
> have to switch to Github, which I don't want to do at the moment. Maybe
> later.
>
> Sonar: we don't need it, we have code coverage already.
>
> > easy deployment on central repository.
>
> I have some experience with Jackrabbit, and I think the deployment of H2
> is simpler. So I will try to keep it the way it is.
>
> Regards,
> Thomas
>
>
>
>
> On Tue, Jan 28, 2014 at 11:09 AM, Nicolas Fortin (OrbisGIS) <
> nico.de...@gmail.com> wrote:
>
>> Hi,
>>
>> You have removed all unit test and you do not use maven central for
>> dependencies. Moreover, there is only one maven h2 project. Packages should
>> be splited into multiple h2 maven sub-project depending on packages
>> dependencies. We should use maven profiles to enable/disable extensive
>> (memory/disk usage cost) unit test .
>>
>> Some sub modules sample:
>> H2CONSTANT
>> H2TOOLS
>> H2MESSAGES
>> H2API
>> MVMAP
>> BNF (sql parser, auto completion)
>> MVSTORE
>>
>> Doing this will give access to Travis (compilation+test), Sonar (test
>> code coverage, code hints), easy deployment on central repository.
>>
>> However it require a significant amount of work. Then I will contribute
>> only if Thomas is interested in.
>>
>> -Nicolas
>> Atelier SIG, IRSTV FR CNRS 2488
>>
>> Le mardi 28 janvier 2014 10:41:12 UTC+1, jpgf...@gmail.com a écrit :
>>
>>> Hi.
>>>
>>> There is the H2 module.
>>>
>>> Just for my personnal comprehension why are you not interested to
>>> "Mavenize" ?
>>> I'm curious in what can be the disanvantage of a mavenize project.
>>> I'm hope it will be helpful to yuo to generate a new version of h2.
>>>
>>> Regards,
>>>
>>> JPG
>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "H2 Database" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to h2-database+unsubscr...@googlegroups.com.
>> To post to this group, send email to h2-database@googlegroups.com.
>> Visit this group at http://groups.google.com/group/h2-database.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "H2 Database" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to h2-database+unsubscr...@googlegroups.com.
> To post to this group, send email to h2-database@googlegroups.com.
> Visit this group at http://groups.google.com/group/h2-database.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
