Here is a status on the last issues we have, and some proposals to solve them.
• Studio Maven Repository
The Studio Maven Repository is currently located at http://people.apache.org/~felixk/studio-eclipse-m2/.
This is not really an ideal situation and we have to find it a better solution.
If all the Eclipse dependencies we need were on the standard Maven repositories, Emmanuel and I think we could get rid of our project specific repository by deploying our studio related jars (studio-launcher, studio-dsml-parser, etc.) on those standard Maven repositories. This way all our dependencies would be on Maven repositories.
As we can't do that at the moment, I propose we switch back to a local maven repository located inside SVN.
This is exactly like we're doing with Ant/Ivy at the moment.
It takes some extra time when doing a checkout, but it does not create overload on the people.apache.org server each time we build Studio.
I remember, we had that in place some time ago in the Maven build. I also remember there were minor issues, but I can't remember exactly what they were (something like a $local-repository folder created I think). Can someone help me recover my memories ?
Do you think this is a suitable solution and, Felix, it is possible to come back to this solution ?
• Parent Pom
We currently depend on the 9-SNAPSHOT version of the Directory project pom.
This situation forces us to checkout and build Apache DS first, before building Apache Directory Studio.
It takes a lot of time... :(
I would suggest we use the 8 version of the Directory project pom, the last published version available.
• Apache DS and Shared dependencies
The last problem we face is our dependencies to jars of the Apache DS project.
The Shared dependencies are no longer a problem as we'll have a new version released especially for Studio very soon (tomorrow maybe...).
The Apache DS dependencies have been checked by Emmanuel and he told me that we can use the 1.5.1 version (available on Maven repositories).
So, there should be no more dependencies issues.
With the 2 last problems resolved, we won't need anymore to checkout and build Apache DS prior to building Apache Directory Studio and we'll have, I think, a working and release ready Maven build.
A build system which could be subject to a vote for switching to it...
The build works now on Mac OS X.
I have replaced the faulty dependency:unpack goal on Mac OS X by a dependency:copy goal and some ant tasks for extracting and deleting the tar.gz files.
On Feb 5, 2008 11:56 AM, Pierre-Arnaud Marcelot <firstname.lastname@example.org> wrote:Hi,
I created two Jiras about our problems:
We'll see if they get fixed soon... I hope so...
- MECLIPSE-386 - Modified MANIFEST.MF file for eclipse jars packaged from folders with eclipse:to-maven
- MDEP-142 - Path with space makes the dependency:unpack goal fail
I'll replace the dependency:unpack goal with Ant tasks for the Mac OS X part of the build.
Pierre-ArnaudOn Feb 4, 2008 12:59 PM, Emmanuel Lecharny <email@example.com> wrote:
Pierre-Arnaud Marcelot wrote:
> Hi Emmanuel,
> On Feb 1, 2008 7:01 PM, Emmanuel Lecharny <firstname.lastname@example.org
> <mailto:email@example.com>> wrote:Yeah, that's sound a good idea.
> One more bug, on Mac OSX...
> The (undocumented, as usual ...) maven-depdendency-plugin fails while
> trying to unpack the mac app. The reason is that the file name
> spaces. Sadly, Maven plugin are built on top of plexus, which is
> not an
> Apache piece of code (it's at codehaus), so the only thing we can
> do is
> to open a JIRA on Maven, which I did. We are not the only ones
> being hit
> by this bug (http://jira.codehaus.org/browse/MDEP-137)
> I also saw the JIRA which seems related to our problem. I suggest we
> also open another one for our specific "space" problem.>Sadly, the current unpack goal depends heavily on plexus. Plexus is not
> May be invoking a ant task which will rename the file to Apache
> Directory Studio.app after the unpack has been done can do the trick
> (yes, I know, it's ugly, but this is the only workthefuckaround I
> can see).
> Yes, good idea. A cleaner idea could also be to rewrite the unpack
> goal of the plugin in fault using ant tasks (which should be easy and
> work like a charm)...
exactly my favorite body part, as if you hit it, you get knock down
immediately, like Maven does, so I buy the idea to rewrite this POS.
(Piece Of Software for those who think I had something different in mind
when I wrote POS). Should not take days, I think. Maybe an afternoon,
certainly not a morning (but my mornings are short : I wake up at 10).
<snip/>>It was a <rant>, and irrelevant when it comes to make a decision ;)
> In our case, the idea of using a single build system in the whole
> directory project makes that our choice goes to Maven. It will clearly
> be a great benefit for our project when all its subprojects will have
> the same build system.
> Even if it's painful to set up...