David Jencks wrote:
On May 12, 2009, at 7:27 AM, Ate Douma wrote:
David Jencks wrote:
On May 11, 2009, at 4:29 PM, Ate Douma wrote:
David Jencks wrote:
On May 11, 2009, at 3:42 PM, Ate Douma wrote:
<snip/>
<more-snip/>
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?
I set this up. IIUC the new project distro artifacts will be
deployed along with all the other artifacts when we run mvn deploy
-Papache-release, for instance when the release:perform goal does
this.
Cool, thanks David, I will try this out right away (locally of course).
My original commit might not work, there seems to be a problem in the
assembly plugin 2.2-beta-3. I switched to 2.2-beta-2 which does seem
to work.
I discovered an issue with the predefined project assembly descriptor
in that you cannot customize it with additional includes/excludes.
That makes these predefined assemblies pretty useless imo, as we
clearly need to add a few excludes of our own:
velocity.log (produced by the remote-resources-plugin)
.project
.classpath
.settings/*
After several fruitless attempts to force the assembly plugin to do
what we need, I concluded there is no way to "fix" this without
resorting to custom assemblies, *per project* :(
And so I did. I modified the portals-pom and removed the configuration
element and added a custom project assembly descriptor to both the 1.0
and 2.0 spec projects. Now this works fine AFAICT.
I should have mentioned something about this.
I think we can keep using the built-in "project" descriptor because we
use this only during release. The release plugin does an svn export of
the project before building the release. This won't have any or the
.eclipse files, and if we get the assembly to run early enough in the
build, the velocity.log file won't be there either. I'd rather stick
with the built-in descriptor.
Oh, well.
I already started the release:prepare and release:perform but am hitting
several problems doing that.
Somehow I seem not have enough rights at the Nexus repo, even while I have a
login account.
Based upon your comments above and on another thread, I've decided to rollback
my commits and figure out how to do this correct.
Welcome your further comments and help about this.
Regards,
Ate
thanks
david jencks
With the additional cleanup Vivek performed earlier, it seems to me
we're finally ready now to start the release of the portals-pom-1.2
and the spec projects together.
I'll start working on that now.
Regards,
Ate
As noted in another thread I think the changes we'd like in
portals-pom are piling up and we should get them all in and release
portals-pom 1.2 and the specs in one vote (or simultaneous votes).
I'd move the pluginManagement assembly plugin configuration to the
parent.
OK, +1
Just as David Taylor just asked on another thread, can you explain
how you want the ianal plugin to be run on all builds?
just include it in the <build><plugins> element in the portals-pom.
To re-answer David's question, it checks that the required legal
files are included in every artifact.
If I may ask, would you be willing to do the required changed for
the portals-pom-1.2-SNAPSHOT so we can all assess what these changes
will amount to?
I did this and also updated the spec poms to use the snapshot
parent. rev 773745 in case you want to revert it.
Only part not discussed previously is that I renamed prepare-release
profile to rat. I don't know what problems occurred when running it
as apache-release, but I don't think people usually include rat in
the release profile. I'm not sure why or why not.... I'm fine with
asking RMs to run -Prat before release:prepare.
thanks
david jencks
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.
I'd still like to see it working before voting :-)
I'm already working on it :)
I'm in the process of updating Pluto trunk to use the new
dependencies and will test both manually and run the JSR-286 TCK
against it.
If that works well, I'll repeat it for Jetspeed-2.
And if all passes, I'll commit the updates for these dependencies.
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.
agreed.
thanks
david jencks
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]
