Hi folks,

joda-time is indeed ASF 2.0 but Jimi is under Sun/Oracle licence and you have to accept the license agreement before downloading.

The quote from Apache FOP folks : "Because of licensing issues, the JIMI image library is not included in the FOP distribution. First, download and install it. Then, copy the file "JimiProClasses.zip" from the archive to {fop-install-dir}/lib/jimi-1.0.jar. Please note that FOP binary distributions are compiled with JIMI support, so there is no need for you to build FOP to add the support. If jimi-1.0.jar is installed in the right place, it will automatically be used by FOP, otherwise it will not."

Is Jimi a mandatory or an optional dependency?

Cheers,

Siegfried Goeschl

On 23.04.11 21:29, Kevin Meyer wrote:
Hi,

Just a reminder - I introduced a depedency on jodatime, which I believe
has a ASFv2 license.

And what about the dependency on Jimi, is that still there? And ok?

Kevin

via mobile
On Sat, April 23, 2011 13:42, Mark Struberg wrote:
Hi Dan!

0.2 is ok with me too. That depends what else is planed before a 1.0
release. If there will be not many API changes between the current release
and the planed 1.0 status, then 0.9.something would just better reflect
this. But at the end of the day it's mostly about user expectations and
numbers are secundary. So let's stick with 0.2

I'll just like to get a release done finally because that's what users can
take and pick up from repository.apache.org and Apache maven central.
That's just better to promote than any temporary snapshot ;)

The only javax.* dependency I found was the one for the servlet spec. I'll
fix that.

LieGrue,
strub


--- On Sat, 4/23/11, Dan Haywood<[email protected]>  wrote:

From: Dan Haywood<[email protected]>
Subject: Re: thinking about a release
To: [email protected]
Cc: "Robert Matthews"<[email protected]>
Date: Saturday, April 23, 2011, 10:45 AM






   Hi all,

     Yes, I have just been wanting to chip away at the documentation - as
     the various commits will attest.



     Also, I can see both Rob and Kevin are steadily making improvements,
     so there's ongoing work there, so didn't want to unnecessarily break
     the flow.



     But I'm happy to put together a release if that's what people want.
     What I propose is:

     1. I'll just finish the core docs (should be done in next days or
     two)

     2. make sure that the copyright and other stuff is ok for the
     remaining modules

     3. update the JIRAs so capture the fact that documentation for some
     of the other modules is not complete (most notably, we only have a
     placeholder for the default runtime [oai.runtimes:dflt] module).

     4. I'll check-in with Rob and Kevin to make sure that we choose a
     suitable point to take the tag.



     Then I'll start looking into what makes up a release.



     In terms of Mark's questions:



     1.) re-check the IP clearance. Especially our 3rd party

     dependencies. Even an incubator release must meet our

     license requirements. E.g. use specs from
       http://repo1.maven.org/maven2/org/apache/geronimo/specs/

     instead of any javax.* or org.hibernate.* maven artifacts.



     We won't have dependencies on org.hibernate, but we might be depending
on some javax. stuff.  They should all be in isis-parent pom.xml, so
perhaps someone could take a look?







     2.) We better not need any 3rd party<repositories>.

       If we have such a thing, then we should look if there are

       any alternatives. That's no hard show stopper but generally

       a good idea to look at



     We do have a dependency in the restful view on JBoss, but that stuff
     is all Apache license v2.







     3.) Go through all open jira issues and identify show

       stopper issues.



     I don't think there are any, but I'll check.







     4.) create a new isis-0.9.0 'Version' in Jira and move all

       bugs to 'fixed in isis-0.9.0' in Jira.



     I've been working on 0.1.2-SNAPSHOT, but I can rename to 0.9.0 if
     you recommend it.  I do actually have 0.2.0 and 0.3.0 releases
     planned with some tickets assigned to them, but they can easily be
     renamed too if required.





     Cheers

     Dan





     ~~~~~

     On 22/04/2011 14:26, Kevin Meyer - KMZ wrote:

       Hi Mark,

I get the impression that most of (Dan's) hesistation has been about
the documentation.. we don't want to lose potential interest because of
this..

Having said that, what do the people who have joined more recently
have to say?  Sabine, Michael, Vangjel, etc?

Kevin


On 22 Apr 2011 at 9:56, Mark Struberg wrote:





           Hi folks!


I peaked over the sources a little bit (still don't have
much clue) and it doesn't look that bad imo.

What about thinking off a new isis 0.9.0-incubating
release?

We did this 0.9 version scheme in a few other projects
which are already close to 1.0 to show it's not _yet_ 1.0
but already quite near.

The fact that we have a incubator release out there is
pretty important for the adoption rate sometimes.

WDYT?

This of course will need a bit of preparation:


1.) re-check the IP clearance. Especially our 3rd party
dependencies. Even an incubator release must meet our
license requirements. E.g. use specs from
http://repo1.maven.org/maven2/org/apache/geronimo/specs/
instead of any javax.* or org.hibernate.* maven artifacts if
possible.

2.) We better not need any 3rd party<repositories>.
If we have such a thing, then we should look if there are
any alternatives. That's no hard show stopper but generally
a good idea to look at

3.) Go through all open jira issues and identify show
stopper issues.

4.) create a new isis-0.9.0 'Version' in Jira and move all
bugs to 'fixed in isis-0.9.0' in Jira.

Anything I forgot?

LieGrue,
strub













Reply via email to