[Biojava-dev] next steps
Scooter Willis
HWillis at scripps.edu
Thu May 28 13:10:43 UTC 2009
Maven should be viewed as an additional option for developers where once a version of BioJava is released the Maven repository is updated and we need to make sure we have all the meta-data/dependency information correct. This doesn't mean that BioJava development needs to be done in Maven but simply is another way to get the jars after they have been released. BioJava as a single Jar is not that hard to integrate into your project given that we have a handful of external jars files that we provide as part of the download. For other projects I have worked with where they only package the jar for that project and then give you web links to download 10 other external projects then that is a pain. You go to each website to figure out the download process and find that they are now all in different releases then Maven is a great solution because the developers of biojava took the time to get the exact version of jar files from external packages referenced properly and did not leave it to the "customer" to figure out.
If we use apache commons as a model I personally would rather grab the package of interest say biojava-blast and add into my development environment. Maven is an Apache project yet when you go to http://commons.apache.org/ and grab the component of interest Maven isn't even listed as an option. This is probably because it is an overkill for a single jar. Doesn't mean that you can't get commons jar's via maven when you load a larger project.
In our case we may have a couple components where it can get a little complicated by external jar dependencies. Using biojava-blast as an example where it has a web service client that is either using axis or the latest greatest sun JSR. The project I am importing biojava-blast via Maven into already uses axis but an older version because everything works and I haven't needed to do the upgrade. Maven may make the integration step easier but it doesn't solve the problem where I as the developer now need to do something to resolve the version conflicts.
So I view Maven as a nice option for developers who are a big fan of Maven and makes them smile when they can grab the code they need from BioJava via Maven. We should plan on having an apache commons like page to download and publish the jars in maven as well.
Scooter
________________________________
From: biojava-dev-bounces at lists.open-bio.org on behalf of James Carman
Sent: Thu 5/28/2009 5:37 AM
To: biojava-dev at lists.open-bio.org
Subject: Re: [Biojava-dev] next steps
Maven really isn't that hard. I have no idea what the Mahout folks
are having troubles with, but I'm sure it can be addressed. Maven't
benefits greatly outweigh its complexity (which isn't that high,
IMHO). If you folks want a hand "mavenizing" your project, I wouldn't
mind helping.
On Thu, May 28, 2009 at 3:09 AM, juber patel <juberpatel at gmail.com> wrote:
> just a small observation:
>
> Maven may not be easy to use and switch to maven should be done after
> some consideration. I have personally not used it, but have seen
> people on the Mahout list struggling with maven. Its utility may not
> justify its complexity.
>
> juber
>
>
> On Thu, May 28, 2009 at 10:01 AM, Andreas Prlic <andreas at sdsc.edu> wrote:
>> Hi Scooter,
>>
>> quick update: There is also an eclipse plugin for JDepend, that
>> provides a user interface to browse thought the dependencies.
>>
>> As I already mentioned earlier, I had some quick progress with the
>> maven plugin to convert the project to maven and create a first pom.
>> At the moment I am testing how best to create sub-projects that
>> should contain the modules. The plugin does not seem to make it easy
>> to create new modules, so I agree with your earlier suggestion that it
>> is best to modularize first and the mavenize 2nd... Should we create a
>> branch in svn and play around with refactoring there and once we are
>> happy with it we can switch that branch to become the trunk?
>>
>> Andreas
>>
>>
>>
>>
>> On Mon, May 25, 2009 at 3:59 PM, Scooter Willis <HWillis at scripps.edu> wrote:
>>> I attached the JDepend output for BioJava. This will help on the circular
>>> dependencies where core classes should not have dependencies on other
>>> packages and if they do it should be refactored into the core class.
>>>
>>> Scooter
>>> ________________________________
>>> From: mike.smoot at gmail.com on behalf of Mike Smoot
>>> Sent: Mon 5/25/2009 1:07 PM
>>> To: Scooter Willis
>>> Cc: Andreas Prlic; biojava-dev at lists.open-bio.org
>>> Subject: Re: [Biojava-dev] next steps
>>>
>>>
>>>
>>> On Mon, May 25, 2009 at 7:48 AM, Scooter Willis <HWillis at scripps.edu> wrote:
>>>>
>>>> I was looking at the biojava code yesterday to see how easy it would be to
>>>> divide up into functionally grouped jars based on package hierarchy. I tried
>>>> to find some refactoring tools that would give a network graph view of class
>>>> relationships. It is simple enough to parse source for import statements and
>>>> build some sort of graph relationship tool. It is also easy enough to start
>>>> dragging packages around to different projects in netbeans and resolve
>>>> compiler errors.
>>>
>>> JDepend is a nice tool for evaluating package dependencies.
>>>
>>> http://www.clarkware.com/software/JDepend.html
>>>
>>>
>>> Mike
>>>
>>> --
>>> ____________________________________________________________
>>> Michael Smoot, Ph.D. Bioengineering Department
>>> tel: 858-822-4756 University of California San Diego
>>>
>>
>> _______________________________________________
>> biojava-dev mailing list
>> biojava-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>>
>
>
>
> --
> Juber Patel http://juberpatel.googlepages.com <http://juberpatel.googlepages.com/>
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>
_______________________________________________
biojava-dev mailing list
biojava-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biojava-dev
More information about the biojava-dev
mailing list