Maven pom done

[Cheong Chung Onn]

Hi Paul,

The POMs for maven is all done - I managed to install the jars and it
seems working, in the midst of the testing i discover the visualizer has
new problem which i would follow up with a new thread.

Here are some things you need to aware of
All The POMs for all the nested modules are declared as source except
the Test Module which I declare as test codes. Installing the package
jars using "mvn install" will fail because of the testcase failure. In
order to skip the test, you would need to do "mvn -Dmaven.skip.test=true
install"

There is no source in any of the nested modules as mentioned in my
previous email. I was unable to do a symbolic using svn, i did a local
"ln -s" instead and it works.

There are 3rd party libraries that I was not able to locate in any mvn
repository and hence I declare them as system jars, namely -
netbeans.api, openide.util and eclipse.draw2d. I declared both
netbeans.api and openide.util as 1.0.0 for the moment as i was not aware
of the actual version numbers.

Regards
chung-onn

[Paul Lorenz]

Ok, some questions:

1. How does this impact the release process?
    a. Do we integrate the maven generated jars into the ant build?
    b. Do we push the jars into a maven repo somewhere?
2. Do we need POMs/modules for the examples, tests and the editor? I'm guessing most people only care about mavenized jars for the core and visualizations packages. (At some point, I'd like to do an installer for the editor, maybe using lzPack).
3. How do users handle the dependencies that aren't tracked by maven? Is that something we can do something about, or do we just need to let people know where to get those jars?

cheers,
Paul

[Cheong Chung Onn]

Hi Paul,

Please find my response inline.

Paul Lorenz wrote:
> Ok, some questions:
>
> 1. How does this impact the release process?
> a. Do we integrate the maven generated jars into the ant build?

AFAIK, maven and ant can't be used together, the release process is
different for ant and maven. Actually up till now, I have to do an "ant
dist" and then to a "mvn deploy", this is because our project uses
Wicket and it uses maven.

> b. Do we push the jars into a maven repo somewhere?

The ideal case is to deploy sarasvati jars to a public maven repo. This
will help to gain adoption in the maven community.

> 2. Do we need POMs/modules for the examples, tests and the editor? I'm
> guessing most people only care about mavenized jars for the core and
> visualizations packages. (At some point, I'd like to do an installer
> for the editor, maybe using lzPack).

Personally, I dont think we need the POMs for test and editor, however
examples will be good for those in the maven community who want to try
out Saravati examples. Btw, i have only tested the POMs for both core
and visual only and not the other POMs

> 3. How do users handle the dependencies that aren't tracked by maven?
> Is that something we can do something about, or do we just need to let
> people know where to get those jars?

This is the problem i highlighted previously and it is also my concerns.
Actually I could not find the dependencies lib for both eclipse and
netbeans in the public mvn repos. There are 2 options available i.e.
document in Sarasvati's wiki where to get these jars or checkout from
Sarasvati project.

I like to raise another issue about the potential conflict in the jars
version. Some of the jars that are used in Sarasvati is the latest
whereas the mvn repos jars are somewhat dated. Can we live with this
potential conflict?

Finally, deploying to the maven repository will become a constant chore.
Do we have the slack to do it?

Here's my take, I suggest that we provide the maven POMs and document it
on the wiki page and leave it to the maven fans to take it from there.

What do you think?

Regards
chung-onn

[Paul Lorenz]

Documenting the required jars in the WIKI seems like the right approach for now. I think maven and ant can work together as I read about maven tasks for ant. We want to build mavenized jars and include them in the release, as well as allow users to generate their own jars and push them to local repositories.

So we can get rid of the POMs for test and editor (leaving the examples as you suggest). I'll look into the maven ant tasks when I get closer to doing the RC3 release.

I'm going to try and spend my project time for the next week or two on documentation updates and hopefully get a release out.

cheers,
Paul

[Cheong Chung Onn]

Hi Paul

Let me take a look at ant's maven task this weekend. Btw, i just think
there is still a potential problem - in the Ant build, it will create a
rubric.jar first before building the sarasvati-* jar and I wonder how
to make this rubric jar visible to maven build process. The worse case
situation is to make the rubric into a maven pom too. What say you?

Regards
chung-onn

Paul Lorenz wrote:
> Documenting the required jars in the WIKI seems like the right
> approach for now. I think maven and ant can work together as I read
> about maven tasks for ant. We want to build mavenized jars and include
> them in the release, as well as allow users to generate their own jars
> and push them to local repositories.
>
> So we can get rid of the POMs for test and editor (leaving the
> examples as you suggest). I'll look into the maven ant tasks when I
> get closer to doing the RC3 release.
>
> I'm going to try and spend my project time for the next week or two on
> documentation updates and hopefully get a release out.
>
> cheers,
> Paul
>
> On Mon, Aug 3, 2009 at 12:50 AM, Cheong Chung Onn <chun...@gmail.com

[Paul Lorenz]

When building the jars for release, the rubric files are generated, compiled and included in the main sarasvati jar. We should be able to do the same for the maven build, though we might have to change where they are generated to. The only reason for the rubric.jar is so that we don't have to have the generated files in the source tree (with all their warnings, etc).

cheers,
Paul

[chungonn]

Hi Paul,

After spending the last couple of days on it, here are the changes i
made.

There are now only 3 poms - sarasvati-parent. sarasvati-core and
sarasvati-visual. I have decided to use maven strictly for packaging
purposes. The file structure is also very much simplified, essentially
we only have POM files and there is no need for code duplication or
doing any symbolic links.

I managed to figure out to get the antlr-plugin to generate the rubric
paser source code prior to compilation, however there is a requirement
for this to work - I took the liberty to create an "antlr3" folder in
the project where the rubric.g files are located. This is because
antlr plugin expects this java package style convention - I am unable
to work around this requirement. I think the best way is do a symbolic
link from lang folder, however I will leave you to make the final
decision.

A maven user simply checkout the source from svn and issued the
following command at - "mvn install" and the packaging and
installation of both sarasvati-*.jars will be installed. The jars
are located at both sarasvati-core/target and sarasvati-visual/target.
There are other artifacts (dependencies, uber jar) created along with
the main sarasvati artifacts. The user will choose which is most
appropriate for them.

Note that POMs will be using the eclipse draw2d and netbeans visual
jars in the project so there will be no chance of getting the wrong
version.

I also have consciously avoid changing the ant scripts to use the
maven pom configuration as that would require these folks to install
maven. Also initially I was using trying to get antrun-task plugin to
invoke the ant build "buildLangJar" target and it proved to be too
difficult for me to handle, luckily I found that using antlr-plugin
gives a better integration.

Any thoughts?

Regards
chung-onn

On Aug 5, 11:54 am, Paul Lorenz <plor...@gmail.com> wrote:
> When building the jars for release, the rubric files are generated, compiled
> and included in the main sarasvati jar. We should be able to do the same for
> the maven build, though we might have to change where they are generated to.
> The only reason for the rubric.jar is so that we don't have to have the
> generated files in the source tree (with all their warnings, etc).
>
> cheers,
> Paul
>

> On Tue, Aug 4, 2009 at 11:19 PM, Cheong Chung Onn <chung...@gmail.com>wrote:
>
>
>
> > Hi Paul
>
> > Let me take a look at ant's maven task this weekend. Btw, i just think
> > there is still a potential problem - in the Ant build, it will create a
> > rubric.jar  first before building the sarasvati-* jar and I wonder how
> > to make this rubric jar visible to maven build process. The worse case
> > situation is to make the rubric into a maven pom too. What say you?
>
> > Regards
> > chung-onn
>
> > Paul Lorenz wrote:
> > > Documenting the required jars in the WIKI seems like the right
> > > approach for now. I think maven and ant can work together as I read
> > > about maven tasks for ant. We want to build mavenized jars and include
> > > them in the release, as well as allow users to generate their own jars
> > > and push them to local repositories.
>
> > > So we can get rid of the POMs for test and editor (leaving the
> > > examples as you suggest). I'll look into the maven ant tasks when I
> > > get closer to doing the RC3 release.
>
> > > I'm going to try and spend my project time for the next week or two on
> > > documentation updates and hopefully get a release out.
>
> > > cheers,
> > > Paul
>

> > >     <chung...@gmail.com <mailto:chung...@gmail.com>

[Paul Lorenz]

Hi chung-onn
  I don't think there's a problem with moving where grammer lives. I'll try to pull this into trunk over the next week. I'm on a deadline at work, so my time is somewhat limited for the next couple of weeks, but hopefully it won't take too much time to do. Thank you for working on it.

cheers,
Paul

[Cheong Chung Onn]

Hi Paul,

Thanks. Have a good week ahead.

> <mailto:plor...@gmail.com>> wrote:
> > When building the jars for release, the rubric files are
> generated, compiled
> > and included in the main sarasvati jar. We should be able to do
> the same for
> > the maven build, though we might have to change where they are
> generated to.
> > The only reason for the rubric.jar is so that we don't have to
> have the
> > generated files in the source tree (with all their warnings, etc).
> >
> > cheers,
> > Paul
> >
> > On Tue, Aug 4, 2009 at 11:19 PM, Cheong Chung Onn

> <chung...@gmail.com <mailto:chung...@gmail.com>>wrote: