On Tue, 27 Sep 2005, Zhong ZHENG wrote: Hi,
> > Hi Zhong, > > > > We want to migrate to Maven2 so it's great if you want to help us do that! > > Kenney has actually started a discussion about migrating to m2: > > http://www.nabble.com/Converting-to-maven2-t252889.html#a717165 > > > Great. Maybe you also need a wiki page for the discussion. I am willing to > help. Great! I've been meaning to get started but unfortunately I've been really busy with maven2 development and other work, so all help is greatly appreciated! I believe you didn't send a tar.gz / diff with the poms for all projects. If you would be so kind as to mail this too, or attach it to a JIRA issue, we have a good basis to start migrating I think. > > > Yes, we though about this when Cactus was created several years ago. > > Honestly I don't remember the reason and I'm all for re-starting the > > discussion about this. > > > > ATM I can think of the following: > > > > - Usually our users only use a given J2EE spec at a time so it's nice for > > them to have different Cactus distributions (one for J2EE 1.2, one for 1.3 > > , > > one for 1.4, etc). I think we should keep this but I'm open to change my > > view if there are good reasons (but they must be user-oriented reasons, > > not > > just build reasons ;-)). Correct - different distributions is the way to go. This allows the user to select any version, or all versions if he/she plans to make distributions of his own software for several platforms. > > There are 2 ways to provide those different > > distributions: > > - have a single project but different packages so that when the > > distribution is created classes are individually selected by their package > > name > > - have separate directory structure as we now have > > > > I believe the directory separation is way cleaner than the first method > > and > > is more in the Maven spirit. > > I am trying to separate source code into different directories/subprojects, > and to provide a pom.xml for each of them using different dependencies > which depend on the servlet spec version. Then I would like to be able to > build cactus for a certain servlet spec version by executing a certain maven > goal, for example, 'm2 j2ee12' for j2ee 1.2, and 'm2 j2ee13' for j2ee 1.3, > etc. Separate projects, in conjunction with / or build profiles, are best. 'm2 j2ee12' etc won't work, but m2 install -P j2ee-1.2,j2ee-1.3 would work fine. I think we can create multiple 'attachments', each with a different classifier (j2ee-1.2 etc), so you can depend on the right version for your target environment. That's exactly what classifiers are for in maven 2. I'm just not sure wheter the projects should stay as is (i.e. share-12-13) or split them out (share-12, share-13) into separate projects. > - If we had all in one big cactus jar we would have to be very careful that > > it doesn't not need the different versions of the J2EE jars available in > > the > > CP. This includes the use case when Cactus is dropped in some container > > and > > the container traverses the classloader and tries to load all classes. I'm > > not sure about this but I think I remember some issues with this in the > > past, a very long time ago. I don't know if it's still an issue though. Usually classes are only loaded when they are somehow referenced (in the 'resolve' phase while loading a class, or from the deployment descriptor) but let's not take the risk, contaminating the jar with unneeded classes. I think one big cactus jar per environment is the way to go. > > - building: you would need to have all J2EE version jars available in the > > build classpath to build Cactus. If I want to build Cactus only for a > > specific J2EE version I should be able to do it without caring for the > > other > > versions. Personally I wouldn't care about that - it's the job of the cactus developers to make releases, and if people want cutting edge snapshots they would end up building more than they need, but that's almost always the case (i.e. xdoclet builds ALL modules, even when you only want one or two). On the other hand, the current ant build system provides this feature, and maven2 sure can too, so this shouldn't be a problem. > > [snip] > > > > I agree that putting everything in one subproject makes it easier. However > > it's not the only way and it's possible to migrate to m2 even with the > > current structure. That's what build profiles are for. > > > I did not put everything in one subproject. In fact, I kept the original > project > layout (share-12-13-14, share-13-14, j2ee-12, j2ee-13, j2ee-14) > but decoupled the cross dependencies among them. That's always good, and a nice thing about maven is that it detects these kinds of circular dependencies ;) > [snip] > > > > Let's discuss it! I've started listing some elements above. They may or > > may > > not be correct... I'm all ears. Sounds correct so far, Vincent. -- Kenney --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
