portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: New Report Viewer Portlet App for BIRT
Date Wed, 24 Mar 2010 23:55:57 GMT
Hi Gonzalo,

Sorry for the somewhat delayed response but we're all very busy working to get Jetspeed 2.2.1
release ready.

Further comments inline below.

Regards,

Ate


On 03/19/2010 10:37 PM, Gonzalo Aguilar Delgado wrote:
> Hi all,
>
> New issue is open.
>
> https://issues.apache.org/jira/browse/APA-31
>
> Two screenshots are submitted. I can post new ones if you like them.
I do like these!

I will take a look to the Apache License Version 2.0 but I think that
> everything should be ok. Don't know the difference with the LGPL, I have
> to check.
Well, (L)GPL and ASL 2.0 don't very well go together from an ASF point of view.
For the ASF, (L)GPL licenses in general is unacceptable to be included and distributed.
This means that no (L)GPL licensed code, nor (external/3rd party) dependencies can be incorporated
in ASF projects or product releases.
For some further information, see:

   http://www.apache.org/licenses/
   http://www.apache.org/legal/resolved.html#category-x

   "The LGPL is ineligible primarily due to the restrictions it places on larger works, violating
the third license criterion.
    Therefore, LGPL-licensed works must not be included in Apache products."

Note: ASL 2.0 and GPL 3.0 *are* now accepted both by the ASF and FSF as compatible, in the
sense that GPL 3.0 based projects may use ASL 2.0 
licensed code/dependencies, but *not* the other way around, see:

   http://www.apache.org/licenses/GPL-compatibility.html

Please note that if you are willing (and allowed!) to provide the *code* for the application
under the ASL 2.0 license but currently it 
still has dependencies which use incompatible licenses, we can help *try* to replace those
with alternatives, which is required for this to 
become a releasable project from the ASF.
Also note that BIRT itself uses the EPL 1.0 license, which is OK to redistribute in binary
form (meaning: we cannot distribute the BIRT 
sources, nor modifications thereof).

>
> I also have to clean up a little bit the code and take off two
> dependencies that I feel to have not much sense to distribute:
>
>          DQM - It has functions to normalize names and handle strings.
>          It's used to convert File Names to Report Names (capitalize
>          strings and some others).
>
>          Wicket Utils - It has resource locator class and
>          BaseWicketPortlet for my apps.
>
> It should work nice without them but I surely will release them with the
> main application when it's ready.
>
Preferred is to provide as "clean" as possible code and dependencies as needed as it will
make reviewing it much easier.

> I also don't know how to release the whole source because it's a
> completely separated application but It's built with maven as project
> submodule. I suppose that I must create a new project for this before I
> release it. Any suggestions on this? I want to push the code ASAP.
Probably the preferred way of doing this is creating a copy of your project and start with
removing the parent pom reference and any 
dependencies from your own project(s). Thereafter, try building the now "standalone" project
and resolve any missing dependencies, 
configurations and properties from your parent pom(s) by copying them into the project pom.
Finally, once everything seems to work again, try a clean build with your local maven repository
(temporarily) clean out (removed) to ensure 
all external dependencies are properly resolvable.

Alternatively, you could use mvn itself to generate the so called "effective POM", e.g. with
everything "resolved" using the following 
command run from your Report Viewer project folder:

   #mvn help:effective-pom

If you save the output and replace your current pom.xml with it your practically have a "standalone"
pom already.
However, you probably still will need to clean it up a bit, as a minimum removing the still
referenced parent pom and possible unneeded 
dependencies and configurations "derived" from your parent pom(s).

Don't hesitate to ask further help if you run into problems, if you prefer you can email me
directly as well.

>
> I forgot. I also have a ContextListener that will initialize the BIRT
> report Engine on context init. It will be nice to take a look on this
> because it was my first time using it. But it seems that works ok.
Sure, no problem.

>
> Thank you all!
> Hope it helps
Thank you for willing to help us!

>
>    Gonzalo Aguilar Delgado
>    Consultor CRM - Ingeniero en
> Informática
>          607814276
>


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


Mime
View raw message