Hi,
I cleaned up a few last minor things in the portlet_spec poms:
- some svn:ignore properties as needed for Eclipse IDE
- added provided servlet 2.3 dependency for portlet_spec 1.0
- fixed changed scm locations
Then, I ran rat using the new portals-pom-1.1 prepare-release profile (mvn install -P prepare-release) and hit two files without proper AL
header in the portlet_spec 2.0 project, used for and produced by the maven-remote-resources-plugin:
- src/main/appended-resources/META-INF/NOTICE.vm
- velocity.log
As someone not familiar with the rat plugin, what is the best solution to get
these false positives ignored or resolved?
Other than this last issue, and assuming the OSGi bundle info now is generated correctly (relying on the assessment of both David and
Carsten for this), I think we're ready to go to release these portlet_spec projects through Nexus by tomorrow morning.
The release plan I have come up to be in alignment with the (refreshed) ASF
release requirements is the following:
1) first do a Nexus release to a staged repository (this will create the
release tags for both projects)
2) do a manual checkout of the release tag src and build src dist archives
myself, sign them and upload to a public folder at
people.apache.org, like people.apache.org/~ate/portlet_spec/ [...]
or
for instance use the maven assembly plugin doing (all) the above
automatically???
I actually have never needed to use the assembly plugin yet so I'm not sure
what/how much it can do...
Maybe David or Carsten know more about it, but if I have to find out myself,
I might just resort back to doing it manual this time
3) send out a VOTE email concerning *both* the Nexus provided artifacts from the temporary staged repository *and* the uploaded src dist
archives
4) .... process the VOTE results and (hopefully) have the release completed.
Anything I could be missing in the above plan?
Regards,
Ate
David Jencks wrote:
On May 11, 2009, at 11:20 AM, Carsten Ziegeler wrote:
Ate Douma wrote:
David Jencks wrote:
If we can get it to produce slightly more reasonable output by the end
of tomorrow I think we should use it. For instance it has pointed out
that the packages in Export-Packages should have uses clauses, at
least for the servlet package needed. If no answer from feiix arrives
by tomorrow then I agree we should use the manual manifest setup.....
but informed by the bundle plugin output.
Sounds good to me.
I hope Carsten can chime in on this tomorrow too as he's the one
bringing in the OSGi configuration in the first place ;)
I'm slowly recovering from switching to my new laptop :)
Ok I think we don't need to use the maven bundle plugin as the manifest
headers are constant in our case; but there is nothing wrong with using
the plugin, so we can leave it as is. But in this case, I suggest to
remove the import package statement and change the export statement to
just:
<Export-Package>javax.portlet.filter;version=2.0.0,
javax.portlet;version=2.0.0
</Export-Package>
The plugin is doing the rest (adding the uses, creating the correct
import etc.)
OK.... I had to include some info on imports in order to get the servlet
version to be 2.4, the sun api jar isn't a bundle with package
versions. I simplified the poms as much as I could...
many thanks
david jencks
Carsten
--
Carsten Ziegeler
[email protected]
