jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject maven
Date Fri, 17 Sep 2004 13:23:19 GMT
hi tim & paul,

apart from making the current directory structure maven-friendly
(java sources are now in /src/java, build output goes to /target)
i haven't done anything to mavenize the project.

i tried to migrate it, using tim's project.xml as a template, 
but i failed at an early stage (i couldn't generate the ant script 
with maven), so i gave up.

currently, there are a couple of files that should be removed/replaced
once the migration is completed:
- /build.xml
- /jackrabbit.ipr & .iml (intellij files)
- /lib/*
- /todo.txt

we also have to come up with a solution for the jcr.jar. this archive
contains the compiled jcr api. as the api spec is still quite volatile,
the jcr.jar will change relatively often. we will have to introduce 
some version number schema, e.g. jcr-0.14.1jar etc. to reflect 
the spec version it is based on. i am not sure if we need to deploy 
it on ibiblio.org so it can be used by maven. there might be legal 
issues in doing so. any ideas/suggestions?

cheers
stefan

On Wed, 15 Sep 2004 23:11:28 -0400, Tim Reilly
<tim.reilly@consultant.com> wrote:
> > [Paul Russell wrote:]
> > Sent: Monday, September 13, 2004 11:27 AM
> 
> 
> >
> > On 13 Sep 2004, at 11:43, Stefan Guggisberg wrote:
> > > On Sun, 12 Sep 2004 22:47:56 -0700, Roy T. Fielding
> > > <fielding@gbiv.com> wrote:
> > >> The code itself needs to be migrated from slide cvs to subversion.
> > >> When that happens (probably sometime today/tomorrow, assuming I get
> > >> the request to infrastructure tonight), it will be located at
> > >>
> > >>    https://svn.apache.org/repos/asf/incubator/jackrabbit/trunk
> > >
> > > what do you think of "org.apache.jackrabbit.jcr.*" for the ri and
> > > "org.apache.jackrabbit.tck.*" for the tck? any better ideas?
> >
> > +1. I'm happy with this, as a starting point at least. My guess is that
> > the structure of the project as a whole, and therefore the package
> > hierarchy is likely to evolve significantly over the next few months as
> > we all set scope & strategy and get acquainted. The good news is that
> > since we're using SVN, it's not like it's a nightmare to change the
> > package names if we need to, particularly prior to the 1.0 release.
> >
> > > as the package structure needs to be changed (and the code needs to be
> > > refactored to reflect the new package structure), i would volunteer to
> > > refactor the code first and commit it to svn. does anybody object?
> >
> > Absolutely fine by me.
> >
> > > btw, what should i do with the 'old' proposal code in the slide cvs?
> > > if nobody has any objections, i will remove
> > > jakarta-slide/proposals/jcrri
> > > (it will still be accessible in the attic).
> >
> > Again, that sounds reasonable. Let's not leave 'JCR droppings'
> > everywhere, eh? ;)
> >
> > > tim reilly has suggested a while ago that the jcrri project should be
> > > 'mavenized'.
> > > he has also offered to help convert the current project setup to maven
> > > style.
> > > i think now would be a perfect opportunity to do the conversion.
> > > any comments/objections?
> >
> > I'm +1 on this, with the major caveat that I /do not/ want this to
> > become a big debate. If people have strong reservations about using
> > Maven, I'd rather we postponed the discussion until we have more
> > evidence either way as to the worth of it in this project.
> >
> > Personally, I like Maven, and have used it on a few projects. In
> > general, these have been things that have complex dependancies, or have
> > lots of 'modules' contained within the umbrella project. It seems to
> > work well, although I acknowledge that it has become a bit of a beast.
> >
> > Can I make a suggestion?
> > * If everyone is happy with using Maven for the time being, then lets
> > do so and see how it goes.
> > * If people have strong reservations, then can I suggest we at least
> > adopt the same project higheracy? This would allow us to easily switch
> > to maven later if we decided to do so, and would imply a higheracy that
> > looks something like:
> >       * main java source -> src/java
> >       * main resources -> src/resources
> >       * test java source -> src/test
> >       * test resources -> src/test-data
> >       * main compile target -> target/classes
> >       * test compile target -> target/test-classes
> >       * distributions -> target/distributions
> >
> 
> +1 to all above.
> 
> > I should be able to help Tim with this also: I'm not hugely experienced
> > with the 'site' side of maven, but have done basic work with it.
> >
> > Paul
> 
> +1 here as well ;-)
> ---
> Sorry for the delay (I'd been away for about 3 weeks, still getting myself
> readjusted.)
> I asked about SVN support on Maven-User and SVN support has been added to
> the scm plugin.
> I'll test out my jira powers create a "Mavenize project" issue and to attach
> a zip containing a first run of mavenizing
> (this is outdated - from a few months ago, but hopefully provides a starting
> point in terms of the POM and some xdocs - for review.) Ah, in the event
> there are maven objections; we can mark the issue invalid later. Sound good?
> 
> Best regards,
> -TR
> 
>

Mime
View raw message