[Biojava-dev] next steps

Thu May 28 13:45:23 UTC 2009

I would say that you should use the Apache Commons projects as a model
(I'm an Apache Commons PMC member, so I'm a bit biased).  The
maven-generated site will include information on the dependencies
(including whether they are optional and where you can get them
provided the other projects play nicely and include that information).
 And, yes, when you *do* use Maven, it will download all required
transitive dependencies for you and add it to your classpath
automagically.  That's why it's so nice.  Well, that's one of the MANY
reasons it's so nice.  The release plugin also saves a LOT of
headaches, if you ask me (once you get it configured properly).

On Thu, May 28, 2009 at 9:10 AM, Scooter Willis <HWillis at scripps.edu> wrote:
> 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
>>
>> _______________________________________________
>> 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
>