commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Cohen" <SCo...@sportvision.com>
Subject RE: [NET] Re: dependency dilemma
Date Sat, 01 Mar 2003 12:07:37 GMT
That was easy enough.

I added the ORO dependency back in (and also an entry in the get-deps target to pull it in)
and all those problems went away.

However, I then found, that with moving the tests into src/test as I had planned to do, simply
having junit brought in through maven doesn't fully solve the problem as we also have to bring
in the xml-parsing jars as well. 
This is a run-test-time problem that doesn't appear until you actually have tests to run.

Two solutions here
1) make the fork attribute of the junit task-call in the internal-test target false and get
the benefit of the xml-parsing jars that are already used in ant.  I'm not sure what bad side-effects
this will have
2) drag these jars over to our side, using the get-deps target (or perhaps a new get-test-deps
target). 

I'm not sure what the preferred maven way is here.


-----Original Message-----
From:	Jeffrey D. Brekke [mailto:jbrekke@wi.rr.com]
Sent:	Fri 2/28/2003 10:06 PM
To:	commons-dev@jakarta.apache.org
Cc:	
Subject:	[NET] Re: dependency dilemma


Steve, 

I'm replying on the commons-dev list...

"Steve Cohen" <SCohen@sportvision.com> writes:

> I began working on incorporating my changes to commons-net and came
> fairly quickly to the first hurdle:
> 
> Many of my changes depend on jakarta-oro which is not now included
> in the build process of the project.  In fact, I saw in one of the
> docs, http://jakarta.apache.org/commons/net/dependencies.html, that
> commons-net depends on no other projects.  I don't know if this is
> an immutable law, and I certainly don't want to introduce circular
> dependencies, so I'm kind of stymied here.
> 
> I suppose the build script must have been different before the
> current setup was introduced, or I/we were somehow jamming
> jakarta-oro onto the classpath.  Is it okay to introduce such a
> dependency now, and if so, what is the right way to do it?  If not,
> how else can we build regular expression parsing into the library?
> I'm sure going to jdk 1.4 is not an option.

We had the dependency in there for quite some time before we moved the
code into proposal.  You could look in cvsweb at older versions of
project.xml to add the dependency.  Basically its:

<dependencies>
  <dependency>
    <id>oro</id>
    <version>2.0.7</version>
  </dependency>
</dependencies> 

Moving the tests into src/test, maven will pull in the junit
dependency for us so we don't need to explictly list it.

-- 
=====================================================================
Jeffrey D. Brekke                                   jbrekke@wi.rr.com
Wisconsin,  USA                                     brekke@apache.org
                                                    ekkerbj@yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message