David Jencks wrote:
On May 11, 2009, at 1:31 PM, Ate Douma wrote:
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
It builds for me without this dependency so I don't think we should
include it. Do you have some reason to think it's needed?
No, my mistake and I removed it again.
I also already responded on your earlier reply on the commit message.
- 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?
looks like you fixed this.
Yes, a little searching showed howto.
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.
IMO this is too complicated to be workable.
Well, at least it should work as we already know now Nexus works fine, and the
manual bit is just the same as how we've done it in the past.
I think we should add the
assembly plugin to each top level pom to build the source distro, and
continue using the release plugin for the entire release process. IIUC
this approach will get into the next apache pom with some additional
automation. I'll see if I can come up with appropriate assembly plugin
configuration.
Sure, if you find a way to further automate this, I'm all for it, as long as it
works :)
What is unclear to me however, how/where this source distro is going to be
"published" to the maven repository.
I assume that requires an additional artifact (e.g. pom.xml) definition, right?
Anything I could be missing in the above plan?
- checking that pluto and jetspeed work with our spec jars
Sure, we can (and should) do that, but I have no doubt it will as we didn't
change a single bit within the code base itself.
Its just a change of dependency IMO, nothing more.
The area where we did make changes, the OSGi bundle configuration, won't affect
Pluto or Jetspeed-2 as they don't use that information.
- checking that our osgi metadata is accurate enough to work.
That I have to leave up to you and especially Carsten to validate. I know Carsten is using OSGi a lot, so I presume he should be able to
quickly test this out.
For the the usage of these spec jars within the Apache Portals projects, the dependency replacement is what matters to me the most for this
initial release. If the OSGi bundle configuration turns out to need more tweaking in the future, a follow up release is easily done.
Regards,
Ate
thanks
david jencks
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]
