My comments should not hold up this junit case.
...
I don't think we need to see any maven case--
I was just stating what is fairly common development practice which
makes installation of junit and many other libraries a moot issue: one
writes a maven build script (pom) and it automatically
Anyone using maven has this problem solved already. I agree there
might be crufty builds which might require downloading and installing,
but a lot of software development now uses maven.
Maven has versioned dependencies. So long as junit is in a repository
(and it is), *no install is
IMO, it is unacceptable to overwrite the old version.
Software development does not work that way: you want specific
versions and you do not want a new one appearing randomly to cause new
problems.
If it's maven-based, then the problem is solved (see my previous
message). If not, I would
On Mon, Oct 27, 2008 at 11:55:58AM -0700, Lloyd Chambers wrote:
Maven has versioned dependencies. So long as junit is in a repository
(and it is), *no install is needed*; the build process picks it up
automatically (and puts it into the local maven repository). Ten
versions? No problem.
Dean Roehrich wrote:
On Mon, Oct 27, 2008 at 11:55:58AM -0700, Lloyd Chambers wrote:
Maven has versioned dependencies. So long as junit is in a repository
(and it is), *no install is needed*; the build process picks it up
automatically (and puts it into the local maven repository). Ten
Danek Duvall ??:
On Tue, Oct 21, 2008 at 08:46:33PM -0600, Jim Walker wrote:
Danek Duvall wrote:
Missing are the classes and methods that are, presumably, part of the
Public interface of any Java module intended for use by developers. Or
are
there no Private classes and methods
Jim Walker ??:
Danek Duvall wrote:
On Tue, Oct 21, 2008 at 08:46:33PM -0600, Jim Walker wrote:
Danek Duvall wrote:
Missing are the classes and methods that are, presumably, part of the
Public interface of any Java module intended for use by developers.
Or are
there no Private classes and
Jim Walker wrote:
Another reason to port Junit as a separate package was to establish
a known location for the current version of Junit on OpenSolaris,
so other products don't have to port their own version, so we can
reduce redundant code where possible.
+1..
Part of the problem is a
On Tue, Oct 21, 2008 at 08:46:33PM -0600, Jim Walker wrote:
Danek Duvall wrote:
Missing are the classes and methods that are, presumably, part of the
Public interface of any Java module intended for use by developers. Or
are
there no Private classes and methods in the jar file? If
Danek Duvall wrote:
On Tue, Oct 21, 2008 at 08:46:33PM -0600, Jim Walker wrote:
Danek Duvall wrote:
Missing are the classes and methods that are, presumably, part of the
Public interface of any Java module intended for use by developers. Or
are
there no Private classes and methods in the
Mengwei James,
Can someone tell me why we are doing this? What is the problem we are
trying to solve? I'm not aware of any other platforms that include
junit out of the box, and some middleware (like Glassfish) already
packages junit.
One of the other ARC members observes that their
On Tue, Oct 21, 2008 at 3:08 PM, Jim Walker James.Walker at sun.com wrote:
In addition, OpenSolaris users are searching for
various versions of Junit packages already:
http://muskoka.sfbay/~sch/pkg/search.html
Is that information openly exposable?
-- next part --
An
Mark Martin wrote:
Is that information openly exposable?
Not at the moment.
Cheers,
Jim
--
Jim Walker, http://blogs.sun.com/jwalker
Sun Microsystems, Software, Solaris QE
x77744, 500 Eldorado Blvd, Broomfield CO 80021
Mark Martin wrote:
On Tue, Oct 21, 2008 at 3:08 PM, Jim Walker James.Walker at sun.com
mailto:James.Walker at sun.com wrote:
In addition, OpenSolaris users are searching for
various versions of Junit packages already:
http://muskoka.sfbay/~sch/pkg/search.html
Is that
John Plocher wrote:
Jim Walker wrote:
We also understand the problem where several open source projects depend
on older versions of Junit and don't plan to update their code to use
the newer version. We felt it was best to start by porting the current
version and revise it as new releases are
Jim Walker wrote:
If 1, why are you doing something that isn't well aligned with
the known use-case for the component, and if 2, how will you
actually do it?
Is Maven the known use-case?
Not really - the use case is that most every java thing that uses
junit, depends on a different
16 matches
Mail list logo
