Dettborn wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ate Douma (JIRA) schrieb:
[
https://issues.apache.org/jira/browse/PLUTO-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488858
]
Ate Douma commented on PLUTO-308:
---------------------------------
Sorry for the possible confusion typo: I meant "Your patch though still
includes the old ones", not just once :)
This means that the header in the source files from the api must look
like this:
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you 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.
is this right?
Yes
And in the licence.txt must be included:
Apache [???1.1-286-COMPATIBILITY???]
Copyright [2007] The Apache Software Foundation
This produt includes software developed at
The Apache Software Foundation (http://www.apache.org/).
No :)
Something like the above text should be included in a NOTICE file, not the
LICENSE.
The LICENSE file should contain the content of
http://www.apache.org/licenses/LICENSE-2.0.txt
Additionally, "The [remainder of] NOTICE file is to be used for required third-party notices. The NOTICE file may also include copyright notices moved from
sources files submitted to the ASF."
So, if for instance IBM would require this, a notice statement about copyrights
from IBM could be included in the NOTICE file too.
I don't think the NOTICE file is as much important to get "right" or complete right now (yet) though. The NOTICE and LICENSE files are required when an artifact
(e.g. the portlet-api-2.0.jar) is released, but we aren't there yet.
The changes to the license headers in the sources affects (almost) every checked in file though, so its better to get it right now so we don't have to correct
them later anymore.
This patch is for new deployment with JAXB instead of castor and the
changes for the new API Revision from 8 to 11.
-------------------------------------------------------------------------------------------------------------------
Key: PLUTO-308
URL: https://issues.apache.org/jira/browse/PLUTO-308
Project: Pluto
Issue Type: New Feature
Components: general
Affects Versions: 1.1-286-COMPATIBILITY
Reporter: Torsten Dettborn
Fix For: 1.1-286-COMPATIBILITY
Attachments: jaxb_n_api-r11.080207.patch,
jaxb_n_api-r11.210207.patch, jaxb_n_api-r12.120307.patch,
patches_before_included_060407.patch,
patches_before_included_060407_No_Licence_change.patch
Christian has made a patch for the new JAXB binding for the deployment
from the portlets, because there are too many problems with the patch
(Issue 287) we decided to reject this issue and patch it all in one.
Here is the description from Christian:
"Unfortunately this patch is a big one. In the new spec there are
qnames, which are used to identify names, e.g. event names. The
previous implementation of the Portlet Object Model use castor
for xml binding. Unfortunately castor does not support qnames in
a way we need it. Thats why i implement the xml data binding with
jaxb. In the new Spec there are other points JAXB will be used,
therefor i think using JAXB is not a bad idea.
My first idea was to change the *DD classes to interfaces and then
let castor and jaxb implement this classes. In this case we should
be able to use both xml data bindings together and the user has the
choice.
But i ran into several problems with this approach. On the one hand,
the castor *DD classes doesn't provide all necessary methods
and therefor much work with the castor implementation has to be
done. On the other hand i want to use the classes automatically
generated by jaxb.
In my mind the best thing would be, to use the castor classes and
annotate them with jaxb annotations. Then there aren't as much
changes as with this patch.
I have gone the other way, a matter of time. I've delete the castor
things and use jaxb as the only xml data binding.
What this patch does:
I have generated (xjc maven plugin) the jaxb classes and add it to the
repository. Then all occurences of *DD are replaced by the jaxb *Type
classes. Some methods had to be renamed, and some jaxb classes had to
be implemented because of XMLSchema conflicts.
I use the JAXB RI, that is why i had to change the poms and installation
dependencies. I add a new JaxbDescriptorService interface and the
corresponding implementation.
Note:
With the current portlet-app_2_0.xsd (provided at:
http://ipc658.inf-swt.uni-jena.de/spec/JSR%202.0%20API/portlet-app_2_0.xsd)
it is not possible to use old portlet.xml files from JSR168. This has
to be changed in the final release of the specification. Therefor i had
to change the portlet.xml files in the repo.
What has to be done:
Writing of portlet.xml and web.xml is not supported yet.
I would appreciate if someone could implement the (IMHO) better approach
of adding the jaxb annotations to the castor classes."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGIzYH0Ji0BqEIlIURAndjAJ493e1Lozg3rGy87aK0VKdwnyCtCwCeNp1p
zeDQW8J7U9g9pn7iCUh/k3w=
=MWRb
-----END PGP SIGNATURE-----
