You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@commons.apache.org by Martin Cooper <ma...@apache.org> on 2003/11/12 19:31:14 UTC

A-C, J-C and dependencies

Putting aside all the "(why) should we do this" discussions for a moment...

Let's assume that the community around a particular J-C component, say
commons-foo, decides that it wants to move to A-C. Would there be - or
perhaps, should there be - any rules about what commons-foo can depend on,
once it has moved to A-C? Is it OK for an A-C component to depend on a
Jakarta project? How about a(nother) J-C component?

Apart from my own edification with respect to the intended boundaries and
scope of A-C, the answers to these questions may provide a filter to help us
determine potential candidates for "early adopters", if you will. For
example, commons-math has been suggested as a potential candidate for moving
to A-C. However, commons-math has dependecies on five other J-C components.
Would that be OK, or would those components need to move to A-C first? (BTW,
I'm not involved with comons-math, nor am I suggesting one way or the other
whether it should move. I merely use it for the purposes of illustration.)

--
Martin Cooper




Re: A-C, J-C and dependencies

Posted by Morgan Delagrange <md...@yahoo.com>.
--- Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> --On Wednesday, November 12, 2003 15:29:53 -0500
> Garrett Rooney 
> <ro...@electricjellyfish.net> wrote:
> 
> >> I don't see any reason why that should be a
> problem.
> >
> > The one project in A-C now (serf) has dependencies
> on stuff that isn't in
> > A-C (apr and apr-util specifically), so I don't
> see how it would be a
> > problem with projects currently in J-C that want
> to move.
> 
> Yup.  I don't see an issue.  -- justin

Me neither.  IMO the emphasis on minimal dependencies
is not intended to discourage reaching outside of j-c.
 I think the real goal is to encourage a reasonably
small footprint without a lot of extra baggage. 
Dependencies between J-C and A-C should be OK.

- Morgan

=====
Morgan Delagrange
http://jakarta.apache.org/commons
http://axion.tigris.org

Re: A-C, J-C and dependencies

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, November 12, 2003 15:29:53 -0500 Garrett Rooney 
<ro...@electricjellyfish.net> wrote:

>> I don't see any reason why that should be a problem.
>
> The one project in A-C now (serf) has dependencies on stuff that isn't in
> A-C (apr and apr-util specifically), so I don't see how it would be a
> problem with projects currently in J-C that want to move.

Yup.  I don't see an issue.  -- justin

Re: A-C, J-C and dependencies

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Sam Ruby wrote:

> I don't see any reason why that should be a problem.

The one project in A-C now (serf) has dependencies on stuff that isn't 
in A-C (apr and apr-util specifically), so I don't see how it would be a 
problem with projects currently in J-C that want to move.

-garrett

Re: A-C, J-C and dependencies

Posted by Sam Ruby <ru...@apache.org>.
Martin Cooper wrote:

> Putting aside all the "(why) should we do this" discussions for a moment...
> 
> Let's assume that the community around a particular J-C component, say
> commons-foo, decides that it wants to move to A-C. Would there be - or
> perhaps, should there be - any rules about what commons-foo can depend on,
> once it has moved to A-C? Is it OK for an A-C component to depend on a
> Jakarta project? How about a(nother) J-C component?
> 
> Apart from my own edification with respect to the intended boundaries and
> scope of A-C, the answers to these questions may provide a filter to help us
> determine potential candidates for "early adopters", if you will. For
> example, commons-math has been suggested as a potential candidate for moving
> to A-C. However, commons-math has dependecies on five other J-C components.
> Would that be OK, or would those components need to move to A-C first? (BTW,
> I'm not involved with comons-math, nor am I suggesting one way or the other
> whether it should move. I merely use it for the purposes of illustration.)

I don't see any reason why that should be a problem.

> --
> Martin Cooper