[EMAIL PROTECTED] wrote:
Hi Hernan,
I felt this is yet another issue created by confluence. That is because
people can contribute to the Geronimo project not accepting ASF licenses.
If the contributors are working with the JIRA then they have to accept ASF
license with each and every patch (if they like to contribute to the
project). Is there any way to give this functionality to the confluence
As I said in an earlier note, clicking a checkbox will not address the issue of having some files
with some pre-existing "license" or "credits" information.
too? Anyway I am not a fan of confluence than JIRA to get contributions to
an open source project, hear are my points regarding it (may be this
horse has been beaten to dead several times by this same community ;-) ).
Not to dead, looks like it's still kicking ;-)
First I will start from it's positives. Yeah I accept it will give very
nice presentation to the users with some very good inbuilt capabilities
(pdf export etc etc).
The point I am against here is using it directly to get the user
contributions. Here are some the points come to my mind.
That's exactly the point for using a wiki, so everybody can contribute.
"Collaboration"
1. License issues like above might occur because of the contributors are
not accepting ASF licenses. Also it will not promote the ASF licenses. I
think you all will understand the importance of ASF licenses to the open
source community.
There should not be any licensing related issues, we are talking about documentation. I grant that a vast majority of the "articles" in the documentation contain some sort of examples and most of those examples are also available as attachments.
I would not be happy if we need to change the current method for contributing to the doc with a more strict one (i.e. restricted edit access) so we can avoid this kind of issues. That will, IMO, make it even harder for new contributors trying to provide some docs.
(This is one of the major promotion slogans of Geronimo too ;-) )
2. Visibility of the work done in the confluence is limited to a very few
developers because most of the developers are working with the JIRA. I am
not sure this is the best way to handle a community driven project like
Geronimo.
Not sure I follow what you are saying "...visibility of the work done in the
confluence is limited..."
I think the wiki has more visibility than any other media. Can you expand a bit
more
3. Nobody is going to create JIRA issues regarding documentation issues.
So according to my understanding documentation will not improve from
starting. There is noway to submit a patches to the existing bugs of the
documentation (then we might have to get the help of JIRA).
Using JIRA is not going to enhance nor leverage more community building around
the documentation. However it may help to track some articles and its versions
but there will be no revisions in sync with the current Confluence content.
Again, not sure I understand your concern about "...documentation will not improve
from starting..." You don't need an issue tracking system to get feedback on the
documentation. There are a lot of folks chiming in and either send an email with comments
or go directly to the wiki and fix some typos for example. That's the beauty of the wiki,
everybody can collaborate and contribute improve the documentation.
4. I am sure people like tech writers, graphic editors, translators etc.
are part of an open source project contributors (I heard some of the
Apache members start their work as tech writers). In this kind of
environment they will not get the credit they deserve too.
Now this is the horse we beat to dead ;-) we have had endless discussions about
this subject over a long period of time and I think we tried every possible
recipe available. If you are concerned about the visibility of the articles you
contribute then I would encourage you to do the same thing you would do if you
were posting the same article anywhere else. Talk about it, let us (the
community) know what you've worked on. Don't let an automatic email do it for
you, it would probably get filtered ;-)
HTH
Cheers!
Hernan
Comments !!!!
Thanks,
Lasantha Ranaweera
Lasantha,
those samples were donated to the project ergo they should only display
ASF2 license.
This is the text we have in trunk today
<!--
Copyright 2006 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
Could you please remove the unnecessary (old) data and comments and add
the appropriate lines to each of the files for all the samples you are
updating.
http://www.apache.org/licenses may give you some additional tips.
Thanks for taking care of this.
Cheers!
Hernan
Lasantha Ranaweera wrote:
Sorry to send it again. This is an important issue. Have a look at the
attached file. I have stuck here whether to reuse this sample or not.
:-\
Lasantha Ranaweera wrote:
Hi All,
Past few days I have been upgrading JBoss to Apache Geronimo samples
from v1.0 of the documentation to v1.1. As part of the upgrade
procedure, when I was looking at one of the samples I found something
that grabbed my attention in the existing JBoss to Geronimo sample
applications. Have a look at "JBoss to Geronimo - Security Migration"
in following url:
http://cwiki.apache.org/confluence/display/GMOxDOC10/JBoss+to+Geronimo+-+Security+Migration
Source code of this sample contains some proprietary license. So we
can't do any editing this sample. Isn't it?
I'm quite new to the open source model, and AFAIK it should come with
ASF license. Please correct me if I am wrong.
Thanks,
Lasantha Ranaweera
------------------------------------------------------------------------
/*****************************************************************
* File: BusinessLogicEJB.java
*
* Date Version Author Changes
* Oct.05,2005 1.1 Ivan Dubrov Created
*
* Copyright (c) 2005, IBM Corporation
* All rights reserved.
*****************************************************************/
package com.ibm.j2g.security;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
/**
* Business logic stateless bean.
*
* @ejb.bean name="BusinessLogic" display-name="BusinessLogic bean"
* jndi-name="ejb/BusinessLogic" type="Stateless"
view-type="remote"
*/
public class BusinessLogicEJB implements SessionBean {
/** Serial version uid. */
private static final long serialVersionUID = 4688250533090120601L;
/**
* @ejb.interface-method
* @ejb.permission role-name = "uploader"
*
* @return result message
*/
public String upload() {
return "File successfully uploaded";
}
/**
* @see
javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
*/
public void setSessionContext(SessionContext ctx) throws EJBException,
RemoteException {
// Nothing...
}
/**
* Create method.
*
* @ejb.create-method
* @ejb.permission unchecked="true"
*
* @throws EJBException
* @throws RemoteException
*/
public void ejbCreate() throws EJBException, RemoteException {
// Nothing...
}
/**
* @see javax.ejb.SessionBean#ejbRemove()
*/
public void ejbRemove() throws EJBException, RemoteException {
// Nothing...
}
/**
* @see javax.ejb.SessionBean#ejbActivate()
*/
public void ejbActivate() throws EJBException, RemoteException {
// Nothing...
}
/**
* @see javax.ejb.SessionBean#ejbPassivate()
*/
public void ejbPassivate() throws EJBException, RemoteException {
// Nothing...
}
}
