You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by David Jencks <da...@yahoo.com> on 2006/11/18 19:10:35 UTC
proposal for war assembly reorganization
I'm hoping to create some time to work on the geronimo-jetspeed2 integration I started last year at this time and started looking at jetspeed a bit again. I've never been happy with how the wars are assembled but now after watching Jason Dillon m2-ize and clean up the geronimo build I have an idea how to improve it.
So right now the war assembly module "portal" runs an ant script that reaches into all sorts of place outside the module and has a lot of conditional logic to try to decide what to copy from src and etc and what to filter and where to put it into the war. I find this impossible to understand and it is certainly very anti-maven philosophically.
What I propose is that each bit of stuff for which there's a choice about including in the war be moved to a separate "resource-bundle" module and jarred up into an artifact. Then to assemble a war you can unpack the resource-bundles you want, add the classes and libs you want, and war it up. This is easy to do entirely in m2 and I find it much clearer.
I cooked up a quick start on this idea that I put at
http://people.apache.org/~djencks/jetspeed-2/
The jar unpacks to the project (unpack in jetspeed2/trunk) and there's also a patch file. My experience is that large svn patches don't work so the jar is likely to give better results.
After unpacking, cd assembly;mvn
I've verified that the list of files in the war in jetspeed-portal-full is the same as the list of files in the normal jetspeed war except for a bunch of maven pom-like files and WEB-INF/pages/minimal-default-page.psml which can be left out of the full war since with this scheme copying files over each other by hand isn't needed.
I verified that maven filtering is working but not that the results of filtering are identical to those from the existing build. If they aren't this is just a matter of adding some maven properties.
At the moment this just makes a full build. It's easy to add things like the db page manager by having a resource-bundle jar for it: if people like this idea I'll finish converting all the other choices to this scheme. Choices about what to include can be handled either by profiles or by simply building a lot of different wars.
From my perspective this looks like a big improvement. I'd like to get some other opinions fairly soon and perhaps commit this in the next few days. We could maintain 2 copies of this stuff for a while but it is extra work.
Currently I'm using a maven plugin from geronimo that jason dillon wrote to help with the resource bundles. If people don't like this geronimo dependency we can simple copy the plugin into jetspeed or see if we can get it into m2.
I have some other questions about the build...
Is the maven 1 stuff still used? Can I delete it?
Can I reorganize the modules to standard m2 dir structure? (such as src/main/java instead of src/java)
Can I rename the modules so they match the artifactId? This lets you remove a bunch of cruft from the poms.
Where did the dojo.zip come from? It's not the same as the dojo zip file we found for geronimo....
Many thanks,
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: proposal for war assembly reorganization
Posted by David Sean Taylor <da...@bluesunrise.com>.
Aaron Evans wrote:
> As a community user, I'd just like to add my two cents and say that I
> am also a user that uses the "genapp" functionality (and I'm still on
> m1).
>
> If the genapp functionality and the documentation were in place, I'd
> happily upgrade to maven 2 provided the build process was
> straight-forward and thouroughly tested. I remember when I started
> with jetspeed a year ago, I spent a lot of cycles just trying to get
> it to build and I would prefer to not go through that again. :)
>
We do have "genapp" capabilities in the Maven-2 'build'
We implemented it with archetypes, such as the portal-achetype, similar
to our Maven-1 counterpart:
mvn archetype:create -DarchetypeGroupId=org.apache.portals.jetspeed-2
-DarchetypeArtifactId=portal-archetype -DarchetypeVersion=2.1-dev
-DgroupId=myportalgroup -DartifactId=myportal -Dversion=1.0
Archetypes
* portal
* application
* component
* shared-component
* portal-component
Documentation:
http://wiki.apache.org/portals/Jetspeed2/Maven2BuildSupport
I'd be interested to hear what DJ thinks about the archetypes
Randy tells me that archetypes are somewhat limited, and that a real
Maven-2 plugin would be the better solution
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: proposal for war assembly reorganization
Posted by Aaron Evans <aa...@gmail.com>.
As a community user, I'd just like to add my two cents and say that I
am also a user that uses the "genapp" functionality (and I'm still on
m1).
If the genapp functionality and the documentation were in place, I'd
happily upgrade to maven 2 provided the build process was
straight-forward and thouroughly tested. I remember when I started
with jetspeed a year ago, I spent a lot of cycles just trying to get
it to build and I would prefer to not go through that again. :)
cheers,
aaron
On 11/18/06, Ate Douma <at...@douma.nu> wrote:
> David Jencks,
>
> first of all, thanks very much for stepped up to help out with our current build mess (which I think it really is).
> And I honestly hope your proposed solution is the way to go.
>
> That said, I can't yet give a +1 before two major issues are addressed which I'll point out below.
> If however we can solve those (and I'm definitely willing to help out as far as I can), I'm all for it.
>
> See for further details below.
>
> Regards, Ate
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: proposal for war assembly reorganization
Posted by Ate Douma <at...@douma.nu>.
David Jencks,
first of all, thanks very much for stepped up to help out with our current build mess (which I think it really is).
And I honestly hope your proposed solution is the way to go.
That said, I can't yet give a +1 before two major issues are addressed which I'll point out below.
If however we can solve those (and I'm definitely willing to help out as far as I can), I'm all for it.
See for further details below.
Regards, Ate
David Sean Taylor wrote:
> David Jencks wrote:
>>
>> Currently I'm using a maven plugin from geronimo that jason dillon
>> wrote to help with the resource bundles. If people don't like this
>> geronimo dependency we can simple copy the plugin into jetspeed or
>> see if we can get it into m2.
>>
>> I have some other questions about the build...
>>
>> Is the maven 1 stuff still used? Can I delete it? Can I reorganize
>
> The Maven-1 build is still used in a lot of custom projects
Very true, especially by using the jetspeed maven-plugin genapp functionality.
Randy went through very much pain to provide a similar solution with our maven-archetypes.
To be honest, I never really worked with m2 and our maven-archetypes as all my clients were using to maven-plugin genapp solution so I had (and partly still
have) to support them with that.
So, before we can drop the Maven-1 support I think we *must* provide an upgrade path and *very* detailed documentation how current Maven-1 users can migrate
*without losing functionality*.
I did check out your new assembly proposal, and I agree it seems like a great simplification.
But (note: I'm not exactly a m2 guru to say the least, so please forgive my ignorance), can this solution easily be extended to provide the features we have now
in the maven-plugin and the m2 maven-archetypes?
For me, being able to streamline the build of Jetspeed-2 for ourselves as core developers isn't so much the goal here.
The real target must be the end users needing an easy build setup for their own custom portal and be able to merge in their own code and resources, components
web applications as well as replace default features from jetspeed.
Our current Maven-1 solution through the maven-plugin certainly isn't the best, simple or without its problems, but it does provide an easily to be build and
customizable portal solution for my clients (Jelly code is awkward, but not difficult and powerful enough for most purposes).
I'm not willing to drop that quickly without a proper alternative.
> I actually still use it to build Jetspeed. Steve runs the Maven-2, so I
> try to work off of Maven-1, that way we don't both have to test with
> both builds. In all honesty I am sick of having two builds
>
> We were planning on removing it after the 2.1 release
> If you want to remove it now, I think it should be voted on
> It appears that your patch, by changing the directory structures, would
> actually break the Maven-1 builds. Or we would have to adjust the
> Maven-1 build for the new directory structures in the M1 builds and
> plugin. I don't want to volunteer for doing that, prefer to just kill
> the M1 build
I agree. If we can provide a feature complete m2 solution, I'm all for killing Maven-1.
>
>> the modules to standard m2 dir structure? (such as src/main/java
>> instead of src/java) Can I rename the modules so they match the
>> artifactId? This lets you remove a bunch of cruft from the poms.
>
> We need to vote on the directory restructuring
> As far as Im concerned, its also a vote on continuing M1 support
Agreed again. I've no problem with the directory restructuring when we can drop m1 support.
>
> Could you give me an example of where the modules don't match the
> artifactId?
>
>>
>> Where did the dojo.zip come from? It's not the same as the dojo zip
>> file we found for geronimo....
>
> We stay current with the latest Dojo official releases
> So we just download it from there, and bundle it up ourselves
>
> Im going to need sometime to review all of this, by Monday the latest.
> Im all for making the build simpler and more in line with the "Maven-2
> way", so you have my support on this effort, and we definitely value
> your expertise with Maven-2. We are working on new features in the Maven
> plugin for the database population, and I was dreading having to update
> both Maven-1 and Maven-2 builds.
>
> I just want to make sure that other people in the community also back
> it. Its about time we make that big decision to kill the Maven-1 build.
I will fully support it if and when:
a) the solution can be extended to properly replace our maven-plugin / maven-archetypes solution for customized portal builds and deployments
b) we have clear and complete migration documentation for our maven-1 (and maven-2) users
BTW: I know our current documentation for using the maven-plugin, nor the maven-archetypes (see http://wiki.apache.org/portals/Jetspeed2/Maven2BuildSupport )
certainly isn't perfect at all either. But I really think we have to do (much) better when we drop maven-1, otherwise its going to kill our community support.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: proposal for war assembly reorganization
Posted by David Sean Taylor <da...@bluesunrise.com>.
David Jencks wrote:
>
> Currently I'm using a maven plugin from geronimo that jason dillon
> wrote to help with the resource bundles. If people don't like this
> geronimo dependency we can simple copy the plugin into jetspeed or
> see if we can get it into m2.
>
> I have some other questions about the build...
>
> Is the maven 1 stuff still used? Can I delete it? Can I reorganize
The Maven-1 build is still used in a lot of custom projects
I actually still use it to build Jetspeed. Steve runs the Maven-2, so I
try to work off of Maven-1, that way we don't both have to test with
both builds. In all honesty I am sick of having two builds
We were planning on removing it after the 2.1 release
If you want to remove it now, I think it should be voted on
It appears that your patch, by changing the directory structures, would
actually break the Maven-1 builds. Or we would have to adjust the
Maven-1 build for the new directory structures in the M1 builds and
plugin. I don't want to volunteer for doing that, prefer to just kill
the M1 build
> the modules to standard m2 dir structure? (such as src/main/java
> instead of src/java) Can I rename the modules so they match the
> artifactId? This lets you remove a bunch of cruft from the poms.
We need to vote on the directory restructuring
As far as Im concerned, its also a vote on continuing M1 support
Could you give me an example of where the modules don't match the
artifactId?
>
> Where did the dojo.zip come from? It's not the same as the dojo zip
> file we found for geronimo....
We stay current with the latest Dojo official releases
So we just download it from there, and bundle it up ourselves
Im going to need sometime to review all of this, by Monday the latest.
Im all for making the build simpler and more in line with the "Maven-2
way", so you have my support on this effort, and we definitely value
your expertise with Maven-2. We are working on new features in the Maven
plugin for the database population, and I was dreading having to update
both Maven-1 and Maven-2 builds.
I just want to make sure that other people in the community also back
it. Its about time we make that big decision to kill the Maven-1 build.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: proposal for war assembly reorganization
Posted by David Sean Taylor <da...@bluesunrise.com>.
Sorry for the late response, but I was hoping that more people would
comment on this. Really like your idea of moving optional stuff to a
resource bundle module. That makes a lot of sense and is much clearer to
understand than tying into the build cycle and copying stuff around.
>
> Currently I'm using a maven plugin from geronimo that jason dillon
> wrote to help with the resource bundles. If people don't like this
> geronimo dependency we can simple copy the plugin into jetspeed or
> see if we can get it into m2.
>
Best to get it into Maven, but we can add a Geronimo dep, no problem,
same family :)
> I have some other questions about the build...
>
> Is the maven 1 stuff still used? Can I delete it? Can I reorganize
> the modules to standard m2 dir structure? (such as src/main/java
> instead of src/java) Can I rename the modules so they match the
> artifactId? This lets you remove a bunch of cruft from the poms.
My concern is that we are all working hard towards a 2.1 release, don't
want to do anything to de-stablize the build at this point. And we
certainly cannot get rid of the Maven-1 build at this point, nor can we
change the directory structure as its perpetuated itself into a large
number of custom builds. So my conclusion is that I think its best to
hold off on this until after the 2.1 release, when we will officially
remove the Maven-1 build. At that time, I would also like to consider
any other restructuring and reworking of the build to be more Maven-2
compliant. Quite a few people have commented that they don't like having
all the separate projects for each component, and would prefer to just
have one big jetspeed-2-portal.jar. We can have a vote on that issue as
well. But pre-2.1, we can't leave our Maven-1 user base hanging until we
provide a clear migration path for them, delineated by an official release.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org