You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2010/09/04 12:41:14 UTC
DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
Summary: [PATCH] add maven build support
Product: Fop
Version: 1.1dev
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: glenn@skynav.com
This patch adds support for building with maven 2.2.X or later. I have tested
it with the current version (2.2.1) on a JDK 1.6 platform.
There are no direct dependencies on JDK 1.4 or 1.5 features, but I have not
verified yet.
The patch creates a new top-level directory 'maven' in the FOP trunk directory.
See the file README-MAVEN.txt there for configuration and usage information.
Once downloaded to your home directory, this patch may be applied as follows:
cd ${FOP}/trunk
gzcat ~/patch-maven-build.diff.gz | patch -p0
svn add maven
Note that only the core fop.jar artifact is built at this time. In particular,
the fop-transcoder and fop-sandbox jar artifacts are not yet built.
This patch has been verified against repository version 992575.
Regards,
Glenn
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 49881] [PATCH] add maven build support
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
Glenn Adams <ga...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #3 from Glenn Adams <ga...@apache.org> ---
batch transition resolved+later to closed+later; if you have new information or
a patch that addresses the issue, you may reopen
--
You are receiving this mail because:
You are the assignee for the bug.
DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
Glenn Adams <gl...@skynav.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |LATER
--- Comment #2 from Glenn Adams <gl...@skynav.com> 2012-04-06 23:40:03 UTC ---
lack of consensus for committing patch; reconsider this addition in the future
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
On Fri, Sep 10, 2010 at 3:51 AM, Vincent Hennebert <vh...@gmail.com>wrote:
> On 07/09/10 10:10, Craig Ringer wrote:
> > On 7/09/2010 4:40 PM, Jeremias Maerki wrote:
>
<snip/>
> ... then it'd look for local/somejar-2.2.jar within my local repository.
> > If I put the jar where it should be found, no problem.
>
> Is that also how one would handle optional dependencies? For example
> Jeuclid is an optional plug-in; how would I do if I wanted to
> periodically enable/disable it?
>
> At the moment I have a jeuclid.jar in my lib/ directory, that I can just
> rename into jeuclid.jar.disabled if I want to exclude it.
>
Conditional dependencies on plugins may be best handled through the <scope/>
declaration or by using different profile settings, where profiles can be
either project specific (defined in pom.xml) or user specific (defined in
settings.xml) or both.
Profiles can then be activated on the command line, e.g.,
mvn -P profile-a test
mvn -P profile-b test
mvn -P profile-a,profile-c test
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Vincent Hennebert <vh...@gmail.com>.
On 07/09/10 10:10, Craig Ringer wrote:
> On 7/09/2010 4:40 PM, Jeremias Maerki wrote:
<snip/>
>> Anyway, I won't to stand in the way
>> if something is added to FOP that can help some users. [snip] just
>> because Maven
>> can't include a simple JAR that is not in a repository.
>
> Not strictly true. One option is to use <scope>system</scope> with an
> explicit path to the jar.
>
> Maven doesn't have a wild-card "include everything under lib/" though,
> and using system scope to fudge in local depencies is a bit of a hack.
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies
>
> Usually what you'd do if you have a jar you want to use - but no repo or
> pom for it - is drop the jar you want to use into your local ~/m2/ (or
> wherever you keep your local repository, ie download cache) then declare
> a dependency on it in your pom.xml. This is within "a repository" but
> it's only your local repo, it doesn't involve any network access or
> anything except putting a file in a particular place. Maven will look
> for the dependency in a location defined by the repo layout. So if I
> declared
>
> <dependency>
> <groupId>local</groupId>
> <artifactId>somejar</artifactId>
> <version>2.2</version>
> </dependency>
>
> ... then it'd look for local/somejar-2.2.jar within my local repository.
> If I put the jar where it should be found, no problem.
Is that also how one would handle optional dependencies? For example
Jeuclid is an optional plug-in; how would I do if I wanted to
periodically enable/disable it?
At the moment I have a jeuclid.jar in my lib/ directory, that I can just
rename into jeuclid.jar.disabled if I want to exclude it.
<snip/>
Thanks,
Vincent
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Craig Ringer <cr...@postnewspapers.com.au>.
On 7/09/2010 4:40 PM, Jeremias Maerki wrote:
> I guess we're in a "religious" dispute here, like PC vs. Mac. So we
> can't expect to reach a consensus.
Well, certainly a discussion of preference. I know it gets religious for
some Java folks, but myself I don't mind too much so long as nobody
tries to force their choice on me. I can use Maven without having to
care what others use or force it on them. I'm only weighing in on this
discussion to say that I'd like the option for maven builds if it
doesn't get in anyone else's way, and address some possible
misunderstandings about maven.
I like dealing with maven in projects because for me it is a known
quantity and imposes some consistency on projects that I personally
like. OTOH, I manage ok if a project doesn't use maven, at least so long
as I don't have to wrangle the guts of its build system.
> Anyway, I won't to stand in the way
> if something is added to FOP that can help some users. [snip] just because Maven
> can't include a simple JAR that is not in a repository.
Not strictly true. One option is to use <scope>system</scope> with an
explicit path to the jar.
Maven doesn't have a wild-card "include everything under lib/" though,
and using system scope to fudge in local depencies is a bit of a hack.
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies
Usually what you'd do if you have a jar you want to use - but no repo or
pom for it - is drop the jar you want to use into your local ~/m2/ (or
wherever you keep your local repository, ie download cache) then declare
a dependency on it in your pom.xml. This is within "a repository" but
it's only your local repo, it doesn't involve any network access or
anything except putting a file in a particular place. Maven will look
for the dependency in a location defined by the repo layout. So if I
declared
<dependency>
<groupId>local</groupId>
<artifactId>somejar</artifactId>
<version>2.2</version>
</dependency>
... then it'd look for local/somejar-2.2.jar within my local repository.
If I put the jar where it should be found, no problem.
I don't personally find that to be any worse than dropping everything in
lib/ ... and I find it makes it a LOT easier in the long run to let mvn
take care of the mess of secondary (transitive) dependencies involved in
using things like Hibernate.
(OK, so maven does whine annoyingly about not being able to find the
pom.xml for the artifact, which bugs me - but it works fine nonetheless).
> But I consider
> Maven viral as we're seeing here. Due to its inflexibility, projects
> are almost forced to adopt it to keep everyone happy,
I can't speak for the obsolete Maven 1.x, but that's not true of 2.x .
To keep everyone happy it *does* help to publish artifacts to a maven
repository (be it Central or somewhere else) but there's no need to get
Maven anywhere near your builds if you don't want to, and there's no
need for the people maintaining the project and doing the development
work to have anything to do with pushing project releases to maven central.
If you *do* want to create and push maven artifacts yourself but don't
want to use Maven in builds, a Maven artifact can be created with the
"cp" command and a text editor, or with an Ant task to spit out a
suitable generated pom.xml . No biggie.
You can use Maven builds with jars not created or managed with Maven,
you can use Ant to produce Maven artifacts, and you can use Ant to
consume Maven-produced artifacts. It doesn't really force anything on
you at all.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Benson Margulies <bi...@gmail.com>.
Please, please, please do not create a new ant task from scratch :-).
Simon, I will have a look presently and see if I have any assistance to
offer.
On Tue, Sep 7, 2010 at 9:15 AM, Simon Pepping <sp...@leverkruid.eu>wrote:
> On Tue, Sep 07, 2010 at 08:47:16PM +0800, Craig Ringer wrote:
> >
> > Meh. I'd like to see maven support in fop, but I'm not working with
> > fop's code much at all so it's hardly something I can claim any say
> > in. Maybe I should bash together an ant task to spit out Maven
> > artifacts after a build, though, to make it easier to use fop's
> > existing build tools to integrate with maven.
>
> Please, see my efforts to complete the ant target for maven artifacts
> in xmlgraphics-commons,
>
> http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/build.xml?view=markup
> ,
> line 655, and the wiki page on maven deployment,
> http://wiki.apache.org/xmlgraphics/Maven, and suggest
> improvements. When I am convinced that this works, I will make similar
> changes to the fop build file.
>
> Or send us a patch to the build file.
>
> Simon
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu
>
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Tue, Sep 07, 2010 at 08:47:16PM +0800, Craig Ringer wrote:
>
> Meh. I'd like to see maven support in fop, but I'm not working with
> fop's code much at all so it's hardly something I can claim any say
> in. Maybe I should bash together an ant task to spit out Maven
> artifacts after a build, though, to make it easier to use fop's
> existing build tools to integrate with maven.
Please, see my efforts to complete the ant target for maven artifacts
in xmlgraphics-commons,
http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/build.xml?view=markup,
line 655, and the wiki page on maven deployment,
http://wiki.apache.org/xmlgraphics/Maven, and suggest
improvements. When I am convinced that this works, I will make similar
changes to the fop build file.
Or send us a patch to the build file.
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Craig Ringer <cr...@postnewspapers.com.au>.
On 7/09/2010 7:22 PM, Benson Margulies wrote:
> I've never seen a message to one of the mailing lists
> complaining that connectivity issues were making people miserable. Why? You
> need connectivity to update from svn. Then you need connectivity to run a
> build.
... and to get any libraries or other dependencies if you don't already
have them locally. Just like with Maven.
BTW, I suspect many people who have trouble with Maven's apparent net
access requirements don't know about "mvn dependency:go-offline" and
"mvn -o" for offline operation that doesn't try to check snapshot repos
etc. mvn -o is kind of hard to miss, but people seem to anyway; the
go-offline goal is rather less obvious but really handy.
Meh. I'd like to see maven support in fop, but I'm not working with
fop's code much at all so it's hardly something I can claim any say in.
Maybe I should bash together an ant task to spit out Maven artifacts
after a build, though, to make it easier to use fop's existing build
tools to integrate with maven.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Benson Margulies <bi...@gmail.com>.
I want to inject one fact, and one collection of experience, but I'm still
not trying to talk anyone into anything.
Fact: the Apache Software Foundation maintains a comprehensive maven
infrastructure. There is a repository manager, there are standard parent
POMS. All projects that use Maven get the advantage of it.
Experience: I commit on CXF, XmlSchema, and Mahout (all using Maven), and we
use Maven internally at my day job. I've found the dependency system to be a
great advantage. I've never seen a message to one of the mailing lists
complaining that connectivity issues were making people miserable. Why? You
need connectivity to update from svn. Then you need connectivity to run a
build. And once you've run a build, you have all the maven stuff, and you're
done until someone changes the dependencies.
Keep in mind that, at a project like FOP, the goal is to produce code that
other people can use and integrate. 'Central' is a discipline. If the code
does not work with commonly available versions of its dependencies, that
probably means that someone, somewhere, is going to have a lot of trouble
using it.
If Maven downloads a truckload of stuff as a result of one of your
dependencies, then you have a truckload of dependencies. (Well, OK, an
oversimplification. Some things have enthusiastic dependency graphs which
can be pruned.) As previously noted here, Maven itself likes to download a
lot of Maven. In the past, there was a design error in Maven in which it
would update its internal components 'behind your back'. Aside from removing
predictability from the build, this means that you could need more
connectivity less predictably. Nowadays, the versions of the pieces are
fixed unless you move them. So, once you've built something once, you can
build --offline until and unless you decide to change a dependency.
Other than dependency management, the primary virtue of Maven is the lack of
build configuration. Sadly, it's bimodal: there's hardly any, and then
there's much too much. The cure for that is sometimes a new maven plugin.
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
On Tue, Sep 7, 2010 at 4:40 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
> Due to its inflexibility, projects are
> almost forced to adopt it to keep everyone happy, just because Maven
> can't include a simple JAR that is not in a repository.
Perhaps this has changed, because while I was debugging a problem with
getting the junit tests to run, I found it necessary to temporarily exclude
certain maven dependency generated JARs and explicitly include a local
non-repository JAR. This was possible in the surefire plugin by using:
<classpathDependencyExcludes>
<classpathDependencyExclude>org.apache.xmlgraphics:batik-*</classpathDependencyExclude>
</classpathDependencyExcludes>
<additionalClasspathElements>
<additionalClasspathElement>${fop.lib.dir}/batik-all-1.7.jar
</additionalClasspathElement>
</additionalClasspathElements>
I'll admit this is a bit verbose expression-wise, but it did the job.
Perhaps some of your bad experiences derive from its growing pains. On the
other hand, now that I am looking, I don't see the same configuration
options on the compiler plugin. This kind of inconsistency is one I find in
ant as well; e.g., support for if/unless clauses seems particularly
inconsistent in ant tasks. For example, the lack of if/unless on the <echo>
task requires all kinds of strange work arounds.
G.
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 07.09.2010 09:56:00 Craig Ringer wrote:
> On 7/09/2010 1:52 PM, Jeremias Maerki wrote:
> > Well, Ivy has one fundamental problem in common with Maven that many regard
> > as a great feature: the repository. Numerous times, I couldn't get a Maven
> > build to complete successfully because some artifact was temporarily or
> > permanently unavailable.
>
> First: I'd like to note that none of the following is meant to sound
> like some kind of "ra ra ra you should use maven and only maven, maven
> is the truth and the light". It's just a tool, and like all tools has
> things it's good for and things it's not so good for.
I didn't take it that way. My apologies if I made that impression. I
myself can't stand Maven. I can't speak for the whole FOP project. But
see my last paragraph below for the reason I react so strongly when
Maven is brought up.
> That said, I've never had issues with remote repositories - I routinely
> use sonatype nexus (jboss) repos, Central, java.net, and a couple of
> private repositories.
>
> I guess it helps that once files are fetched by maven and cached in the
> local repository, that's it. Unless you change a dependency's version or
> use snapshot versions, there's no more network access.
It wasn't always like this. Maybe they improved on it in later version.
I distinctively remember when I tried to compile Cocoon during the
hackathon at ApacheCon Ireland 2006. I've had at least four Cocoon
committers at the table to help me and I still spent a whole day
unsuccessfully trying to compile it. Every time I ran Maven it failed in
a different place. Undoubtedly, Maven has improved since then, but if I
watch my colleagues struggling with Maven in a webapp project today, I
can basically just pity them.
> There's always the option of doing the same thing you currently do with
> ant - bundle copies of the dependencies in shipping versions or maintain
> a separate "3rd pty dependencies" repo under version control. I guess I
> don't really see the difference.
That could solve the problem for users compiling the distribution but
not those working off SVN.
> Here I keep a common repo under version control, but that's mostly to
> save download time on big files, and is exactly the same thing I do for
> non-Maven resources like JDK snapshots. It would insulate me a bit from
> transient failures in remote repositories, though.
That's what I tried to do using Ivy. Sadly without luck. Ivy's resolver
wasn't good enough and I didn't get help from the Ivy community. It was
much easier to drop it than to try and fix the problem myself. Maybe
Maven is better at this. Still, I prefer the flexibility of Ant with
imports and macrodefs.
> (I do wish that Maven would print a warning and use the last-downloaded
> -SNAPSHOT version if it didn't have network access and snapshot updates
> were enabled, though. It's the only area where connectivity requirements
> do cause me issues.)
>
> > And how many times did a Maven/Ivy build
> > download half the Internet just to build a small project?
>
> Generally only if it's misconfigured, or that small project uses
> plugins/libraries with a lot of dependencies. In the latter case, you're
> going to need to get them one way or the other.
>
> > My Eclipse's Maven and Ivy plug-ins are
> > long uninstalled because of the trouble they caused.
>
> Aaah. I don't use Eclipse - and given the nature of my experences with
> it when I've tried using it for something, I wouldn't be surprised by
> problems.
But even running "mvn eclipse:eclipse" didn't always give my a project
setup that worked. :-(
> I use NetBeans for most work, and the command line where convenient.
>
> I don't suppose you were relying on any SNAPSHOT version plugins or
> libraries? Because if you were and you had snapshot updates enabled (the
> default - unfortunately IMO) then I can certainly see it seeming like it
> wants to download the internet whenever you run a build.
Sometimes that could have been the case when working with third-party
projects like Felix. But I think if you have to know such subtleties,
that's a problem by itself if you're just trying to compile something.
> > Another problem of an external repository is the lack of license
> > management. ASF projects have clear requirements what kinds of
> > dependencies are allowed. If you can't control transitive dependencies
> > based on a license policy you're bound to run into a problem there.
>
> Now that can be a problem. Again, though, I'm not sure how different it
> is to a 3rd party library you use bundling libraries of unknown
> licensing as dependencies. Either way, you have to check.
Yes, you have to check but you have everything under control locally and
can then document the dependencies in a text file that makes it easy for
users to verify a project against their own license policy. And a
dependency upgrade will immediately show additional dependencies which
gives you a trigger to check the licenses of the new depencendies, too.
Glenn mentioned the license reporting feature of Maven. AFAIK, this is a
fairly recent addition and I've had to realize that license information
is still sketchy for many libraries.
> release Maven artifacts won't change dependencies without a version
> change, and you have to do that kind of checking whenever you update
> anything, maven-based or not.
That's true.
> > I can check out (or extract) FOP and build at least a basic version
> > locally with no outside connection. I like that and would like it to
> > stay that way.
>
> The same is true with Maven. It doesn't have to try to download the
> Internet, nor does it need 'net access for builds. I routinely do (re)
> builds on my laptop while disconnected.
>
> I have the required artifacts in my local ~/.m2 repository already, and
> that's all I need. If I was using an Ant project I'd have to have
> obtained the required dependencies to put on the classpath somehow; same
> deal. Whether I populate my ~/.m2 from Internet repositories, or check
> out a private pre-populated maven repo from version control, I still
> have to obtain it somehow.
I guess that private pre-populated maven repo under version control
sounds most appealing to me because it addresses my concerns. It's
something similar to what I do in my private projects (with Ant).
> That said, I do find that the way it doesn't tend to include most of the
> core plugins in the initial Maven download - and therefore fetches them
> when you first do a build - to be annoying.
>
> --
> Craig Ringer
>
> Tech-related writing at http://soapyfrogs.blogspot.com/
I guess we're in a "religious" dispute here, like PC vs. Mac. So we
can't expect to reach a consensus. Anyway, I won't to stand in the way
if something is added to FOP that can help some users. But I consider
Maven viral as we're seeing here. Due to its inflexibility, projects are
almost forced to adopt it to keep everyone happy, just because Maven
can't include a simple JAR that is not in a repository. At least, that's
what my colleague ran into.
Jeremias Maerki
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Tue, Sep 07, 2010 at 03:44:37PM +0800, Glenn Adams wrote:
> That's reasonable. I wasn't asking you to personally commit it. I would
> commit it myself if I had the privileges, but am dependent on the good
> graces of other committers at present. Perhaps someone will volunteer.
> On Tue, Sep 7, 2010 at 3:42 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
>
> > Because I want to hear other opinions from the other committers first.
> > So far, none of the others responded. And I've stated in the past I
> > won't spend any more time on anything Maven-related, so I'm unlikely to
> > process the patch myself. I won't veto the addition but I certainly
> > won't spend any time maintaining it.
> >
> > On 07.09.2010 09:29:15 Glenn Adams wrote:
> > > ok; but is there any reason not to commit the patch to permit those who
> > find
> > > maven useful to use it? there are many features in FOP that cater to
> > > specific interests, why not permit that with the build process as well?
I would be happy to accommodate FOP developers who prefer Maven as a
build tool. However, as Jeremias pointed out, maintenance is a
problem.
At the moment we do have ant tasks that build a maven bundle, and a
wiki page telling us how to deploy the maven bundle. But that
committer is no longer around and has not responded to my requests for
assistance with the maven deployment. And his constructs no longer
work because the ASF has changed its repository structure and/or
instructions. Therefore we now have a problem.
Your patch is a good piece of work, for which thanks. But with it we
will be good as long as you are willing to maintain it, or as long as
the maven environment is not changing. After that, its existence
makes a false promise, and none of the committers may be able to
remedy or even notice that.
As Jeremias already mentioned, for enterprise developers maintaining a
maven build framework may be of advantage, but for developers who are
on their own and are working on projects with a manageable set of
dependencies, the step to maven may not pay off. I realize you did it,
but that depends on a personal preference to go such roads or not.
When some developers use such a maven build and others FOP's ant
build, which guarantee do we have that both use the same dependency
versions?
Craig Ringer wrote:
> If you *do* want to create and push maven artifacts yourself but don't
> want to use Maven in builds, a Maven artifact can be created with the
> "cp" command and a text editor, or with an Ant task to spit out a
> suitable generated pom.xml . No biggie.
It is no biggie if you understand the maven world. If you do not know
it, there is a world of questions: What is a bundle, what is nexus,
what is sonatype, what is a central repository, how does staging work,
what are the elements of a pom file, what is maven about, what are all
those repositories, etc.
If a project is willing to contribute their jar files to a maven
repository, but otherwise does not want to take time to understand
maven, the above questions remain unanswered, and the task of
deployment is really a big problem.
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
That's reasonable. I wasn't asking you to personally commit it. I would
commit it myself if I had the privileges, but am dependent on the good
graces of other committers at present. Perhaps someone will volunteer.
G.
On Tue, Sep 7, 2010 at 3:42 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
> Because I want to hear other opinions from the other committers first.
> So far, none of the others responded. And I've stated in the past I
> won't spend any more time on anything Maven-related, so I'm unlikely to
> process the patch myself. I won't veto the addition but I certainly
> won't spend any time maintaining it.
>
> On 07.09.2010 09:29:15 Glenn Adams wrote:
> > ok; but is there any reason not to commit the patch to permit those who
> find
> > maven useful to use it? there are many features in FOP that cater to
> > specific interests, why not permit that with the build process as well?
> >
> > regards,
> > glenn
> >
> > On Tue, Sep 7, 2010 at 1:52 PM, Jeremias Maerki <dev@jeremias-maerki.ch
> >wrote:
> >
> > > Well, Ivy has one fundamental problem in common with Maven that many
> regard
> > > as a great feature: the repository. Numerous times, I couldn't get a
> Maven
> > > build to complete successfully because some artifact was temporarily or
> > > permanently unavailable. Introducing an external repository immediately
> > > adds a new dependency in form of the repository to the build which is
> > > one more point of failure. And how many times did a Maven/Ivy build
> > > download half the Internet just to build a small project? For a private
> > > project I started out using Ant+Ivy but I'm in the process of dropping
> > > the Ivy part again. And I've had the repository hand-maintained in a
> > > project-local SVN subdirectory. My Eclipse's Maven and Ivy plug-ins are
> > > long uninstalled because of the trouble they caused. Repositories are
> > > probably ok in a corporate environment where you can run over to the
> > > admin to fix the server. For open source projects, my opinion and
> > > experience is that a repository only adds head-aches for some users.
> > >
> > > Another problem of an external repository is the lack of license
> > > management. ASF projects have clear requirements what kinds of
> > > dependencies are allowed. If you can't control transitive dependencies
> > > based on a license policy you're bound to run into a problem there. I
> > > know at least a couple of ASF projects which didn't notice a license
> > > problem by themselves and had to be pointed to it.
> > >
> > > I can check out (or extract) FOP and build at least a basic version
> > > locally with no outside connection. I like that and would like it to
> > > stay that way.
> > >
> > > On 07.09.2010 04:33:02 Craig Ringer wrote:
> > > > On 09/07/2010 04:25 AM, Glenn Adams wrote:
> > > > > Having gone through the process of creating this working maven
> build
> > > > > configuration, it seems that the potential benefits of its use
> include:
> > > > >
> > > > > * dependency management of the use of external artifacts, which
> is
> > > > > not managed by ant, and causes us to include external
> > > dependencies
> > > > > as part of the source (and binary) release, as well as
> maintain
> > > > > them in the repository;
> > > >
> > > > FWIW, you can also achieve that with Apache Ivy, which uses the Maven
> > > > repos to obtain and manage dependencies, but doesn't require the use
> of
> > > > Maven for builds.
> > > >
> > > > http://ant.apache.org/ivy/
> > > >
> > > > That said, personally I'm reasonably fond of Maven, though I do
> > > > sometimes find the maze of plugins and options difficult to deal with
> > > > and find managing its configuration challenging. I do really like the
> > > > consistency and standardisation it brings to builds - if it's a Maven
> > > > project, you know how to build and use it, you can figure out build
> > > > issues immediately, you already know how the sources are structured,
> etc
> > > > etc etc.
> > > >
> > > > I've come from the C/C++ world of autotools
> (autoconf/automake/libtool),
> > > > CMake, and other nightmare build systems from hell ... so Maven is a
> > > > real breath of fresh air - despite its flaws.
> > > >
> > > > > In any case, I view this patch as being experimental, and am
> willing to
> > > > > maintain it. If after some time elapses I am the only user of it,
> then
> > > > > it could be removed. However, at present, there seems few negatives
> in
> > > > > commit it, particularly since it does not touch any other parts of
> the
> > > > > hierarchy.
> > > >
> > > > It'll also make it easier to maintain a Maven snapshot repository,
> which
> > > > should improve user testing in real-world use of embedded fop
> > > > significantly. I use in-progress code a *lot* more when there's a
> Maven
> > > > snapshot repo availible for it, so I don't have to track svn and
> > > > manually update the built jars periodically.
> > > >
> > > > If you're interested in running a snapshot repo, Sonatype Nexus may
> be
> > > > worth looking into.
> > > >
> > > > --
> > > > Craig Ringer
> > >
> > >
> > >
> > >
> > > Jeremias Maerki
> > >
> > >
>
>
>
>
> Jeremias Maerki
>
>
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Because I want to hear other opinions from the other committers first.
So far, none of the others responded. And I've stated in the past I
won't spend any more time on anything Maven-related, so I'm unlikely to
process the patch myself. I won't veto the addition but I certainly
won't spend any time maintaining it.
On 07.09.2010 09:29:15 Glenn Adams wrote:
> ok; but is there any reason not to commit the patch to permit those who find
> maven useful to use it? there are many features in FOP that cater to
> specific interests, why not permit that with the build process as well?
>
> regards,
> glenn
>
> On Tue, Sep 7, 2010 at 1:52 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
>
> > Well, Ivy has one fundamental problem in common with Maven that many regard
> > as a great feature: the repository. Numerous times, I couldn't get a Maven
> > build to complete successfully because some artifact was temporarily or
> > permanently unavailable. Introducing an external repository immediately
> > adds a new dependency in form of the repository to the build which is
> > one more point of failure. And how many times did a Maven/Ivy build
> > download half the Internet just to build a small project? For a private
> > project I started out using Ant+Ivy but I'm in the process of dropping
> > the Ivy part again. And I've had the repository hand-maintained in a
> > project-local SVN subdirectory. My Eclipse's Maven and Ivy plug-ins are
> > long uninstalled because of the trouble they caused. Repositories are
> > probably ok in a corporate environment where you can run over to the
> > admin to fix the server. For open source projects, my opinion and
> > experience is that a repository only adds head-aches for some users.
> >
> > Another problem of an external repository is the lack of license
> > management. ASF projects have clear requirements what kinds of
> > dependencies are allowed. If you can't control transitive dependencies
> > based on a license policy you're bound to run into a problem there. I
> > know at least a couple of ASF projects which didn't notice a license
> > problem by themselves and had to be pointed to it.
> >
> > I can check out (or extract) FOP and build at least a basic version
> > locally with no outside connection. I like that and would like it to
> > stay that way.
> >
> > On 07.09.2010 04:33:02 Craig Ringer wrote:
> > > On 09/07/2010 04:25 AM, Glenn Adams wrote:
> > > > Having gone through the process of creating this working maven build
> > > > configuration, it seems that the potential benefits of its use include:
> > > >
> > > > * dependency management of the use of external artifacts, which is
> > > > not managed by ant, and causes us to include external
> > dependencies
> > > > as part of the source (and binary) release, as well as maintain
> > > > them in the repository;
> > >
> > > FWIW, you can also achieve that with Apache Ivy, which uses the Maven
> > > repos to obtain and manage dependencies, but doesn't require the use of
> > > Maven for builds.
> > >
> > > http://ant.apache.org/ivy/
> > >
> > > That said, personally I'm reasonably fond of Maven, though I do
> > > sometimes find the maze of plugins and options difficult to deal with
> > > and find managing its configuration challenging. I do really like the
> > > consistency and standardisation it brings to builds - if it's a Maven
> > > project, you know how to build and use it, you can figure out build
> > > issues immediately, you already know how the sources are structured, etc
> > > etc etc.
> > >
> > > I've come from the C/C++ world of autotools (autoconf/automake/libtool),
> > > CMake, and other nightmare build systems from hell ... so Maven is a
> > > real breath of fresh air - despite its flaws.
> > >
> > > > In any case, I view this patch as being experimental, and am willing to
> > > > maintain it. If after some time elapses I am the only user of it, then
> > > > it could be removed. However, at present, there seems few negatives in
> > > > commit it, particularly since it does not touch any other parts of the
> > > > hierarchy.
> > >
> > > It'll also make it easier to maintain a Maven snapshot repository, which
> > > should improve user testing in real-world use of embedded fop
> > > significantly. I use in-progress code a *lot* more when there's a Maven
> > > snapshot repo availible for it, so I don't have to track svn and
> > > manually update the built jars periodically.
> > >
> > > If you're interested in running a snapshot repo, Sonatype Nexus may be
> > > worth looking into.
> > >
> > > --
> > > Craig Ringer
> >
> >
> >
> >
> > Jeremias Maerki
> >
> >
Jeremias Maerki
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Craig Ringer <cr...@postnewspapers.com.au>.
On 7/09/2010 1:52 PM, Jeremias Maerki wrote:
> Well, Ivy has one fundamental problem in common with Maven that many regard
> as a great feature: the repository. Numerous times, I couldn't get a Maven
> build to complete successfully because some artifact was temporarily or
> permanently unavailable.
First: I'd like to note that none of the following is meant to sound
like some kind of "ra ra ra you should use maven and only maven, maven
is the truth and the light". It's just a tool, and like all tools has
things it's good for and things it's not so good for.
That said, I've never had issues with remote repositories - I routinely
use sonatype nexus (jboss) repos, Central, java.net, and a couple of
private repositories.
I guess it helps that once files are fetched by maven and cached in the
local repository, that's it. Unless you change a dependency's version or
use snapshot versions, there's no more network access.
There's always the option of doing the same thing you currently do with
ant - bundle copies of the dependencies in shipping versions or maintain
a separate "3rd pty dependencies" repo under version control. I guess I
don't really see the difference.
Here I keep a common repo under version control, but that's mostly to
save download time on big files, and is exactly the same thing I do for
non-Maven resources like JDK snapshots. It would insulate me a bit from
transient failures in remote repositories, though.
(I do wish that Maven would print a warning and use the last-downloaded
-SNAPSHOT version if it didn't have network access and snapshot updates
were enabled, though. It's the only area where connectivity requirements
do cause me issues.)
> And how many times did a Maven/Ivy build
> download half the Internet just to build a small project?
Generally only if it's misconfigured, or that small project uses
plugins/libraries with a lot of dependencies. In the latter case, you're
going to need to get them one way or the other.
> My Eclipse's Maven and Ivy plug-ins are
> long uninstalled because of the trouble they caused.
Aaah. I don't use Eclipse - and given the nature of my experences with
it when I've tried using it for something, I wouldn't be surprised by
problems.
I use NetBeans for most work, and the command line where convenient.
I don't suppose you were relying on any SNAPSHOT version plugins or
libraries? Because if you were and you had snapshot updates enabled (the
default - unfortunately IMO) then I can certainly see it seeming like it
wants to download the internet whenever you run a build.
> Another problem of an external repository is the lack of license
> management. ASF projects have clear requirements what kinds of
> dependencies are allowed. If you can't control transitive dependencies
> based on a license policy you're bound to run into a problem there.
Now that can be a problem. Again, though, I'm not sure how different it
is to a 3rd party library you use bundling libraries of unknown
licensing as dependencies. Either way, you have to check.
release Maven artifacts won't change dependencies without a version
change, and you have to do that kind of checking whenever you update
anything, maven-based or not.
> I can check out (or extract) FOP and build at least a basic version
> locally with no outside connection. I like that and would like it to
> stay that way.
The same is true with Maven. It doesn't have to try to download the
Internet, nor does it need 'net access for builds. I routinely do (re)
builds on my laptop while disconnected.
I have the required artifacts in my local ~/.m2 repository already, and
that's all I need. If I was using an Ant project I'd have to have
obtained the required dependencies to put on the classpath somehow; same
deal. Whether I populate my ~/.m2 from Internet repositories, or check
out a private pre-populated maven repo from version control, I still
have to obtain it somehow.
That said, I do find that the way it doesn't tend to include most of the
core plugins in the initial Maven download - and therefore fetches them
when you first do a build - to be annoying.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
By the way, I live in a third world country (Philippines) with highly
variable connectivity and usually get no more than 20-30kB/s for downloads.
Furthermore, I don't have an IT infrastructure or servers, but am using an
isolated Macbook Pro for my work. Yet, with all that, I have not had any
particular trouble with maven dependency downloads.
Regarding transitive dependency analysis and license verification, it seems
that maven provides useful tools to audit this. If Apache applications of
maven fail to pay attention to this information, then it isn't the fault of
maven.
In any case, I have not and am not proposing to substitute maven for ant. I
only wish to share a useful build process with others that are comfortable
with using maven. Those that are not can ignore this feature.
Regards,
G.
On Tue, Sep 7, 2010 at 3:29 PM, Glenn Adams <gl...@skynav.com> wrote:
> ok; but is there any reason not to commit the patch to permit those who
> find maven useful to use it? there are many features in FOP that cater to
> specific interests, why not permit that with the build process as well?
>
> regards,
> glenn
>
>
> On Tue, Sep 7, 2010 at 1:52 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
>
>> Well, Ivy has one fundamental problem in common with Maven that many
>> regard
>> as a great feature: the repository. Numerous times, I couldn't get a Maven
>> build to complete successfully because some artifact was temporarily or
>> permanently unavailable. Introducing an external repository immediately
>> adds a new dependency in form of the repository to the build which is
>> one more point of failure. And how many times did a Maven/Ivy build
>> download half the Internet just to build a small project? For a private
>> project I started out using Ant+Ivy but I'm in the process of dropping
>> the Ivy part again. And I've had the repository hand-maintained in a
>> project-local SVN subdirectory. My Eclipse's Maven and Ivy plug-ins are
>> long uninstalled because of the trouble they caused. Repositories are
>> probably ok in a corporate environment where you can run over to the
>> admin to fix the server. For open source projects, my opinion and
>> experience is that a repository only adds head-aches for some users.
>>
>> Another problem of an external repository is the lack of license
>> management. ASF projects have clear requirements what kinds of
>> dependencies are allowed. If you can't control transitive dependencies
>> based on a license policy you're bound to run into a problem there. I
>> know at least a couple of ASF projects which didn't notice a license
>> problem by themselves and had to be pointed to it.
>>
>> I can check out (or extract) FOP and build at least a basic version
>> locally with no outside connection. I like that and would like it to
>> stay that way.
>>
>> On 07.09.2010 04:33:02 Craig Ringer wrote:
>> > On 09/07/2010 04:25 AM, Glenn Adams wrote:
>> > > Having gone through the process of creating this working maven build
>> > > configuration, it seems that the potential benefits of its use
>> include:
>> > >
>> > > * dependency management of the use of external artifacts, which is
>> > > not managed by ant, and causes us to include external
>> dependencies
>> > > as part of the source (and binary) release, as well as maintain
>> > > them in the repository;
>> >
>> > FWIW, you can also achieve that with Apache Ivy, which uses the Maven
>> > repos to obtain and manage dependencies, but doesn't require the use of
>> > Maven for builds.
>> >
>> > http://ant.apache.org/ivy/
>> >
>> > That said, personally I'm reasonably fond of Maven, though I do
>> > sometimes find the maze of plugins and options difficult to deal with
>> > and find managing its configuration challenging. I do really like the
>> > consistency and standardisation it brings to builds - if it's a Maven
>> > project, you know how to build and use it, you can figure out build
>> > issues immediately, you already know how the sources are structured, etc
>> > etc etc.
>> >
>> > I've come from the C/C++ world of autotools (autoconf/automake/libtool),
>> > CMake, and other nightmare build systems from hell ... so Maven is a
>> > real breath of fresh air - despite its flaws.
>> >
>> > > In any case, I view this patch as being experimental, and am willing
>> to
>> > > maintain it. If after some time elapses I am the only user of it, then
>> > > it could be removed. However, at present, there seems few negatives in
>> > > commit it, particularly since it does not touch any other parts of the
>> > > hierarchy.
>> >
>> > It'll also make it easier to maintain a Maven snapshot repository, which
>> > should improve user testing in real-world use of embedded fop
>> > significantly. I use in-progress code a *lot* more when there's a Maven
>> > snapshot repo availible for it, so I don't have to track svn and
>> > manually update the built jars periodically.
>> >
>> > If you're interested in running a snapshot repo, Sonatype Nexus may be
>> > worth looking into.
>> >
>> > --
>> > Craig Ringer
>>
>>
>>
>>
>> Jeremias Maerki
>>
>>
>
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
ok; but is there any reason not to commit the patch to permit those who find
maven useful to use it? there are many features in FOP that cater to
specific interests, why not permit that with the build process as well?
regards,
glenn
On Tue, Sep 7, 2010 at 1:52 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
> Well, Ivy has one fundamental problem in common with Maven that many regard
> as a great feature: the repository. Numerous times, I couldn't get a Maven
> build to complete successfully because some artifact was temporarily or
> permanently unavailable. Introducing an external repository immediately
> adds a new dependency in form of the repository to the build which is
> one more point of failure. And how many times did a Maven/Ivy build
> download half the Internet just to build a small project? For a private
> project I started out using Ant+Ivy but I'm in the process of dropping
> the Ivy part again. And I've had the repository hand-maintained in a
> project-local SVN subdirectory. My Eclipse's Maven and Ivy plug-ins are
> long uninstalled because of the trouble they caused. Repositories are
> probably ok in a corporate environment where you can run over to the
> admin to fix the server. For open source projects, my opinion and
> experience is that a repository only adds head-aches for some users.
>
> Another problem of an external repository is the lack of license
> management. ASF projects have clear requirements what kinds of
> dependencies are allowed. If you can't control transitive dependencies
> based on a license policy you're bound to run into a problem there. I
> know at least a couple of ASF projects which didn't notice a license
> problem by themselves and had to be pointed to it.
>
> I can check out (or extract) FOP and build at least a basic version
> locally with no outside connection. I like that and would like it to
> stay that way.
>
> On 07.09.2010 04:33:02 Craig Ringer wrote:
> > On 09/07/2010 04:25 AM, Glenn Adams wrote:
> > > Having gone through the process of creating this working maven build
> > > configuration, it seems that the potential benefits of its use include:
> > >
> > > * dependency management of the use of external artifacts, which is
> > > not managed by ant, and causes us to include external
> dependencies
> > > as part of the source (and binary) release, as well as maintain
> > > them in the repository;
> >
> > FWIW, you can also achieve that with Apache Ivy, which uses the Maven
> > repos to obtain and manage dependencies, but doesn't require the use of
> > Maven for builds.
> >
> > http://ant.apache.org/ivy/
> >
> > That said, personally I'm reasonably fond of Maven, though I do
> > sometimes find the maze of plugins and options difficult to deal with
> > and find managing its configuration challenging. I do really like the
> > consistency and standardisation it brings to builds - if it's a Maven
> > project, you know how to build and use it, you can figure out build
> > issues immediately, you already know how the sources are structured, etc
> > etc etc.
> >
> > I've come from the C/C++ world of autotools (autoconf/automake/libtool),
> > CMake, and other nightmare build systems from hell ... so Maven is a
> > real breath of fresh air - despite its flaws.
> >
> > > In any case, I view this patch as being experimental, and am willing to
> > > maintain it. If after some time elapses I am the only user of it, then
> > > it could be removed. However, at present, there seems few negatives in
> > > commit it, particularly since it does not touch any other parts of the
> > > hierarchy.
> >
> > It'll also make it easier to maintain a Maven snapshot repository, which
> > should improve user testing in real-world use of embedded fop
> > significantly. I use in-progress code a *lot* more when there's a Maven
> > snapshot repo availible for it, so I don't have to track svn and
> > manually update the built jars periodically.
> >
> > If you're interested in running a snapshot repo, Sonatype Nexus may be
> > worth looking into.
> >
> > --
> > Craig Ringer
>
>
>
>
> Jeremias Maerki
>
>
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Well, Ivy has one fundamental problem in common with Maven that many regard
as a great feature: the repository. Numerous times, I couldn't get a Maven
build to complete successfully because some artifact was temporarily or
permanently unavailable. Introducing an external repository immediately
adds a new dependency in form of the repository to the build which is
one more point of failure. And how many times did a Maven/Ivy build
download half the Internet just to build a small project? For a private
project I started out using Ant+Ivy but I'm in the process of dropping
the Ivy part again. And I've had the repository hand-maintained in a
project-local SVN subdirectory. My Eclipse's Maven and Ivy plug-ins are
long uninstalled because of the trouble they caused. Repositories are
probably ok in a corporate environment where you can run over to the
admin to fix the server. For open source projects, my opinion and
experience is that a repository only adds head-aches for some users.
Another problem of an external repository is the lack of license
management. ASF projects have clear requirements what kinds of
dependencies are allowed. If you can't control transitive dependencies
based on a license policy you're bound to run into a problem there. I
know at least a couple of ASF projects which didn't notice a license
problem by themselves and had to be pointed to it.
I can check out (or extract) FOP and build at least a basic version
locally with no outside connection. I like that and would like it to
stay that way.
On 07.09.2010 04:33:02 Craig Ringer wrote:
> On 09/07/2010 04:25 AM, Glenn Adams wrote:
> > Having gone through the process of creating this working maven build
> > configuration, it seems that the potential benefits of its use include:
> >
> > * dependency management of the use of external artifacts, which is
> > not managed by ant, and causes us to include external dependencies
> > as part of the source (and binary) release, as well as maintain
> > them in the repository;
>
> FWIW, you can also achieve that with Apache Ivy, which uses the Maven
> repos to obtain and manage dependencies, but doesn't require the use of
> Maven for builds.
>
> http://ant.apache.org/ivy/
>
> That said, personally I'm reasonably fond of Maven, though I do
> sometimes find the maze of plugins and options difficult to deal with
> and find managing its configuration challenging. I do really like the
> consistency and standardisation it brings to builds - if it's a Maven
> project, you know how to build and use it, you can figure out build
> issues immediately, you already know how the sources are structured, etc
> etc etc.
>
> I've come from the C/C++ world of autotools (autoconf/automake/libtool),
> CMake, and other nightmare build systems from hell ... so Maven is a
> real breath of fresh air - despite its flaws.
>
> > In any case, I view this patch as being experimental, and am willing to
> > maintain it. If after some time elapses I am the only user of it, then
> > it could be removed. However, at present, there seems few negatives in
> > commit it, particularly since it does not touch any other parts of the
> > hierarchy.
>
> It'll also make it easier to maintain a Maven snapshot repository, which
> should improve user testing in real-world use of embedded fop
> significantly. I use in-progress code a *lot* more when there's a Maven
> snapshot repo availible for it, so I don't have to track svn and
> manually update the built jars periodically.
>
> If you're interested in running a snapshot repo, Sonatype Nexus may be
> worth looking into.
>
> --
> Craig Ringer
Jeremias Maerki
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
Craig,
Thanks for the additional pointers. This was my first time to use maven to
be honest. Since it is an Apache tool, I thought that perhaps using it would
help me integrate better with common Apache tools.
I did had to struggle a bit with some of the configuration ... *and* consult
the source code of some of the plugins to figure out what was what. In the
end, after more than a few times using the -X option, I learned the right
tricks and got it working.
Even with all that, I find it generally cleaner due to its built-in
paradigms (lifecycles), which allow for better shared understanding of the
process, and something one doesn't get from tool sets that don't formalize
common conventions.
Since you obviously have more experience with maven than I, I would
appreciate any constructive comments you may have about the way I have gone
about configuring it.
Regards,
Glenn
On Tue, Sep 7, 2010 at 10:33 AM, Craig Ringer
<cr...@postnewspapers.com.au>wrote:
> On 09/07/2010 04:25 AM, Glenn Adams wrote:
>
>> Having gone through the process of creating this working maven build
>> configuration, it seems that the potential benefits of its use include:
>>
>> * dependency management of the use of external artifacts, which is
>> not managed by ant, and causes us to include external dependencies
>> as part of the source (and binary) release, as well as maintain
>> them in the repository;
>>
>
> FWIW, you can also achieve that with Apache Ivy, which uses the Maven repos
> to obtain and manage dependencies, but doesn't require the use of Maven for
> builds.
>
> http://ant.apache.org/ivy/
>
> That said, personally I'm reasonably fond of Maven, though I do sometimes
> find the maze of plugins and options difficult to deal with and find
> managing its configuration challenging. I do really like the consistency and
> standardisation it brings to builds - if it's a Maven project, you know how
> to build and use it, you can figure out build issues immediately, you
> already know how the sources are structured, etc etc etc.
>
> I've come from the C/C++ world of autotools (autoconf/automake/libtool),
> CMake, and other nightmare build systems from hell ... so Maven is a real
> breath of fresh air - despite its flaws.
>
>
> In any case, I view this patch as being experimental, and am willing to
>> maintain it. If after some time elapses I am the only user of it, then
>> it could be removed. However, at present, there seems few negatives in
>> commit it, particularly since it does not touch any other parts of the
>> hierarchy.
>>
>
> It'll also make it easier to maintain a Maven snapshot repository, which
> should improve user testing in real-world use of embedded fop significantly.
> I use in-progress code a *lot* more when there's a Maven snapshot repo
> availible for it, so I don't have to track svn and manually update the built
> jars periodically.
>
> If you're interested in running a snapshot repo, Sonatype Nexus may be
> worth looking into.
>
> --
> Craig Ringer
>
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Craig Ringer <cr...@postnewspapers.com.au>.
On 09/07/2010 04:25 AM, Glenn Adams wrote:
> Having gone through the process of creating this working maven build
> configuration, it seems that the potential benefits of its use include:
>
> * dependency management of the use of external artifacts, which is
> not managed by ant, and causes us to include external dependencies
> as part of the source (and binary) release, as well as maintain
> them in the repository;
FWIW, you can also achieve that with Apache Ivy, which uses the Maven
repos to obtain and manage dependencies, but doesn't require the use of
Maven for builds.
http://ant.apache.org/ivy/
That said, personally I'm reasonably fond of Maven, though I do
sometimes find the maze of plugins and options difficult to deal with
and find managing its configuration challenging. I do really like the
consistency and standardisation it brings to builds - if it's a Maven
project, you know how to build and use it, you can figure out build
issues immediately, you already know how the sources are structured, etc
etc etc.
I've come from the C/C++ world of autotools (autoconf/automake/libtool),
CMake, and other nightmare build systems from hell ... so Maven is a
real breath of fresh air - despite its flaws.
> In any case, I view this patch as being experimental, and am willing to
> maintain it. If after some time elapses I am the only user of it, then
> it could be removed. However, at present, there seems few negatives in
> commit it, particularly since it does not touch any other parts of the
> hierarchy.
It'll also make it easier to maintain a Maven snapshot repository, which
should improve user testing in real-world use of embedded fop
significantly. I use in-progress code a *lot* more when there's a Maven
snapshot repo availible for it, so I don't have to track svn and
manually update the built jars periodically.
If you're interested in running a snapshot repo, Sonatype Nexus may be
worth looking into.
--
Craig Ringer
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi,
On 06/09/10 23:07, Benson Margulies wrote:
> Glenn,
>
> FBOFW, it's clear that a number of core contributors (including the PMC
> chair!) in fop-land are exceedingly Maven-averse. It's not that rare of a
> viewpoint in the FOSS community.
>
> All that dependency stuff can be done by borrowing maven dependencies in
> ant, either via the maven ant tools or via ivy. For CI, in my opinion you're
> completely correct, but you and I are completely outnumbered.
Just curious: What does Maven offer in terms of continuous integration
that is not available with other tools?
<snip/>
Thanks,
Vincent
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Benson Margulies <bi...@gmail.com>.
Glenn,
FBOFW, it's clear that a number of core contributors (including the PMC
chair!) in fop-land are exceedingly Maven-averse. It's not that rare of a
viewpoint in the FOSS community.
All that dependency stuff can be done by borrowing maven dependencies in
ant, either via the maven ant tools or via ivy. For CI, in my opinion you're
completely correct, but you and I are completely outnumbered.
In my experience, things that start out needing a distressingly intricate
maven build with lots of ant call-outs can often be gradually simplified,
but I haven't looked at the fop build process in any detail.
Mayhap the fop community is OK with a parallel maven build system so long as
someone exists to maintain it.
I personally have a love-hate relationship with Maven -- when the build
process is fundamentally 'plain old Java', I think it's wonderful. When
there is a lot to do that isn't covered by maven plugins, and you wind up
with a lot of callouts to ant, I'm not so sure it's the bees knees.
--benson
On Mon, Sep 6, 2010 at 4:25 PM, Glenn Adams <gl...@skynav.com> wrote:
> Having gone through the process of creating this working maven build
> configuration, it seems that the potential benefits of its use include:
>
> - dependency management of the use of external artifacts, which is not
> managed by ant, and causes us to include external dependencies as part of
> the source (and binary) release, as well as maintain them in the repository;
> - automated report generation
> - improved continuous integration management tools
>
> Although I had to puzzle through some aspects of maven configuration, I
> found it was sufficiently flexible, particularly in combination with the
> antrun plugin, to produce good results. I don't particularly see the use of
> maven as a maven vs ant issue. They both have their uses, and given the
> antrun plugin, one can accomplish the necessary customization of maven goals
> using ant, as opposed to writing custom, one-off plugins.
>
> In any case, I view this patch as being experimental, and am willing to
> maintain it. If after some time elapses I am the only user of it, then it
> could be removed. However, at present, there seems few negatives in commit
> it, particularly since it does not touch any other parts of the hierarchy.
>
> G.
>
> P.S. I did not try a WIN (cygwin) build. For symlinks, I used the ant
> <symlink/> task, both to create and delete. If that task is implemented on
> WIN, then I would expect it to work.
>
> On Mon, Sep 6, 2010 at 10:17 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
>
>> Personally, I'd not be happy if we added a parallel build system. Given
>> that so much Ant code is necessary to handle some details shows how
>> inflexible Maven is. I haven't checked how much Ant code is duplicated
>> between the root-level build.xml and the files in the "maven"
>> subdirectory. IMO, this would be a maintenance head-ache since the two
>> always have to be kept in sync. If build.xml would be split into
>> re-usable sub-file (Ant is quite flexible), some duplication could be
>> avoided maybe. But that would still impose some level of redundancy. At
>> any rate, you probably can't count me in to help maintain the Maven side
>> due to my very bad experiences with it.
>>
>> Also, I'm not sure if the <symlink> task will work as expected on
>> Windows.
>>
>> On 04.09.2010 12:41:14 bugzilla wrote:
>> > https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
>> >
>> > Summary: [PATCH] add maven build support
>> > Product: Fop
>> > Version: 1.1dev
>> > Platform: All
>> > OS/Version: All
>> > Status: NEW
>> > Severity: enhancement
>> > Priority: P2
>> > Component: general
>> > AssignedTo: fop-dev@xmlgraphics.apache.org
>> > ReportedBy: glenn@skynav.com
>> >
>> >
>> > This patch adds support for building with maven 2.2.X or later. I have
>> tested
>> > it with the current version (2.2.1) on a JDK 1.6 platform.
>> >
>> > There are no direct dependencies on JDK 1.4 or 1.5 features, but I have
>> not
>> > verified yet.
>> >
>> > The patch creates a new top-level directory 'maven' in the FOP trunk
>> directory.
>> > See the file README-MAVEN.txt there for configuration and usage
>> information.
>> >
>> > Once downloaded to your home directory, this patch may be applied as
>> follows:
>> >
>> > cd ${FOP}/trunk
>> > gzcat ~/patch-maven-build.diff.gz | patch -p0
>> > svn add maven
>> >
>> > Note that only the core fop.jar artifact is built at this time. In
>> particular,
>> > the fop-transcoder and fop-sandbox jar artifacts are not yet built.
>> >
>> > This patch has been verified against repository version 992575.
>> >
>> > Regards,
>> > Glenn
>> >
>> > --
>> > Configure bugmail:
>> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> > ------- You are receiving this mail because: -------
>> > You are the assignee for the bug.
>>
>>
>>
>>
>> Jeremias Maerki
>>
>>
>
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
Having gone through the process of creating this working maven build
configuration, it seems that the potential benefits of its use include:
- dependency management of the use of external artifacts, which is not
managed by ant, and causes us to include external dependencies as part of
the source (and binary) release, as well as maintain them in the repository;
- automated report generation
- improved continuous integration management tools
Although I had to puzzle through some aspects of maven configuration, I
found it was sufficiently flexible, particularly in combination with the
antrun plugin, to produce good results. I don't particularly see the use of
maven as a maven vs ant issue. They both have their uses, and given the
antrun plugin, one can accomplish the necessary customization of maven goals
using ant, as opposed to writing custom, one-off plugins.
In any case, I view this patch as being experimental, and am willing to
maintain it. If after some time elapses I am the only user of it, then it
could be removed. However, at present, there seems few negatives in commit
it, particularly since it does not touch any other parts of the hierarchy.
G.
P.S. I did not try a WIN (cygwin) build. For symlinks, I used the ant
<symlink/> task, both to create and delete. If that task is implemented on
WIN, then I would expect it to work.
On Mon, Sep 6, 2010 at 10:17 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
> Personally, I'd not be happy if we added a parallel build system. Given
> that so much Ant code is necessary to handle some details shows how
> inflexible Maven is. I haven't checked how much Ant code is duplicated
> between the root-level build.xml and the files in the "maven"
> subdirectory. IMO, this would be a maintenance head-ache since the two
> always have to be kept in sync. If build.xml would be split into
> re-usable sub-file (Ant is quite flexible), some duplication could be
> avoided maybe. But that would still impose some level of redundancy. At
> any rate, you probably can't count me in to help maintain the Maven side
> due to my very bad experiences with it.
>
> Also, I'm not sure if the <symlink> task will work as expected on
> Windows.
>
> On 04.09.2010 12:41:14 bugzilla wrote:
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
> >
> > Summary: [PATCH] add maven build support
> > Product: Fop
> > Version: 1.1dev
> > Platform: All
> > OS/Version: All
> > Status: NEW
> > Severity: enhancement
> > Priority: P2
> > Component: general
> > AssignedTo: fop-dev@xmlgraphics.apache.org
> > ReportedBy: glenn@skynav.com
> >
> >
> > This patch adds support for building with maven 2.2.X or later. I have
> tested
> > it with the current version (2.2.1) on a JDK 1.6 platform.
> >
> > There are no direct dependencies on JDK 1.4 or 1.5 features, but I have
> not
> > verified yet.
> >
> > The patch creates a new top-level directory 'maven' in the FOP trunk
> directory.
> > See the file README-MAVEN.txt there for configuration and usage
> information.
> >
> > Once downloaded to your home directory, this patch may be applied as
> follows:
> >
> > cd ${FOP}/trunk
> > gzcat ~/patch-maven-build.diff.gz | patch -p0
> > svn add maven
> >
> > Note that only the core fop.jar artifact is built at this time. In
> particular,
> > the fop-transcoder and fop-sandbox jar artifacts are not yet built.
> >
> > This patch has been verified against repository version 992575.
> >
> > Regards,
> > Glenn
> >
> > --
> > Configure bugmail:
> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> > ------- You are receiving this mail because: -------
> > You are the assignee for the bug.
>
>
>
>
> Jeremias Maerki
>
>
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Vincent Hennebert <vh...@gmail.com>.
I’ve been following this discussion with interest. Thanks to Benson,
Craig and Glen for demystifying Maven a bit.
I wanted to share my thoughts about that before going offline for 10
days, but it looks like it’s going to have to wait.
Vincent
Le 06/09/2010 15:17, Jeremias Maerki a écrit :
> Personally, I'd not be happy if we added a parallel build system. Given
> that so much Ant code is necessary to handle some details shows how
> inflexible Maven is. I haven't checked how much Ant code is duplicated
> between the root-level build.xml and the files in the "maven"
> subdirectory. IMO, this would be a maintenance head-ache since the two
> always have to be kept in sync. If build.xml would be split into
> re-usable sub-file (Ant is quite flexible), some duplication could be
> avoided maybe. But that would still impose some level of redundancy. At
> any rate, you probably can't count me in to help maintain the Maven side
> due to my very bad experiences with it.
>
> Also, I'm not sure if the<symlink> task will work as expected on
> Windows.
>
> On 04.09.2010 12:41:14 bugzilla wrote:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
>>
>> Summary: [PATCH] add maven build support
>> Product: Fop
>> Version: 1.1dev
>> Platform: All
>> OS/Version: All
>> Status: NEW
>> Severity: enhancement
>> Priority: P2
>> Component: general
>> AssignedTo: fop-dev@xmlgraphics.apache.org
>> ReportedBy: glenn@skynav.com
>>
>>
>> This patch adds support for building with maven 2.2.X or later. I have tested
>> it with the current version (2.2.1) on a JDK 1.6 platform.
>>
>> There are no direct dependencies on JDK 1.4 or 1.5 features, but I have not
>> verified yet.
>>
>> The patch creates a new top-level directory 'maven' in the FOP trunk directory.
>> See the file README-MAVEN.txt there for configuration and usage information.
>>
>> Once downloaded to your home directory, this patch may be applied as follows:
>>
>> cd ${FOP}/trunk
>> gzcat ~/patch-maven-build.diff.gz | patch -p0
>> svn add maven
>>
>> Note that only the core fop.jar artifact is built at this time. In particular,
>> the fop-transcoder and fop-sandbox jar artifacts are not yet built.
>>
>> This patch has been verified against repository version 992575.
>>
>> Regards,
>> Glenn
>>
>> --
>> Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> ------- You are receiving this mail because: -------
>> You are the assignee for the bug.
>
>
>
>
> Jeremias Maerki
>
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Benson Margulies <bi...@gmail.com>.
I'd generally encourage the use of the ant-to-maven wiring I supplied for
maven publication. Adding the ant maven tools to the standard build (or
using ivy?) would allow very quick consumption of FOP jars by Maven-built
applications, which I guess would be the goal here.
On Mon, Sep 6, 2010 at 10:17 AM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
> Personally, I'd not be happy if we added a parallel build system. Given
> that so much Ant code is necessary to handle some details shows how
> inflexible Maven is. I haven't checked how much Ant code is duplicated
> between the root-level build.xml and the files in the "maven"
> subdirectory. IMO, this would be a maintenance head-ache since the two
> always have to be kept in sync. If build.xml would be split into
> re-usable sub-file (Ant is quite flexible), some duplication could be
> avoided maybe. But that would still impose some level of redundancy. At
> any rate, you probably can't count me in to help maintain the Maven side
> due to my very bad experiences with it.
>
> Also, I'm not sure if the <symlink> task will work as expected on
> Windows.
>
> On 04.09.2010 12:41:14 bugzilla wrote:
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
> >
> > Summary: [PATCH] add maven build support
> > Product: Fop
> > Version: 1.1dev
> > Platform: All
> > OS/Version: All
> > Status: NEW
> > Severity: enhancement
> > Priority: P2
> > Component: general
> > AssignedTo: fop-dev@xmlgraphics.apache.org
> > ReportedBy: glenn@skynav.com
> >
> >
> > This patch adds support for building with maven 2.2.X or later. I have
> tested
> > it with the current version (2.2.1) on a JDK 1.6 platform.
> >
> > There are no direct dependencies on JDK 1.4 or 1.5 features, but I have
> not
> > verified yet.
> >
> > The patch creates a new top-level directory 'maven' in the FOP trunk
> directory.
> > See the file README-MAVEN.txt there for configuration and usage
> information.
> >
> > Once downloaded to your home directory, this patch may be applied as
> follows:
> >
> > cd ${FOP}/trunk
> > gzcat ~/patch-maven-build.diff.gz | patch -p0
> > svn add maven
> >
> > Note that only the core fop.jar artifact is built at this time. In
> particular,
> > the fop-transcoder and fop-sandbox jar artifacts are not yet built.
> >
> > This patch has been verified against repository version 992575.
> >
> > Regards,
> > Glenn
> >
> > --
> > Configure bugmail:
> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> > ------- You are receiving this mail because: -------
> > You are the assignee for the bug.
>
>
>
>
> Jeremias Maerki
>
>
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Personally, I'd not be happy if we added a parallel build system. Given
that so much Ant code is necessary to handle some details shows how
inflexible Maven is. I haven't checked how much Ant code is duplicated
between the root-level build.xml and the files in the "maven"
subdirectory. IMO, this would be a maintenance head-ache since the two
always have to be kept in sync. If build.xml would be split into
re-usable sub-file (Ant is quite flexible), some duplication could be
avoided maybe. But that would still impose some level of redundancy. At
any rate, you probably can't count me in to help maintain the Maven side
due to my very bad experiences with it.
Also, I'm not sure if the <symlink> task will work as expected on
Windows.
On 04.09.2010 12:41:14 bugzilla wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
>
> Summary: [PATCH] add maven build support
> Product: Fop
> Version: 1.1dev
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: enhancement
> Priority: P2
> Component: general
> AssignedTo: fop-dev@xmlgraphics.apache.org
> ReportedBy: glenn@skynav.com
>
>
> This patch adds support for building with maven 2.2.X or later. I have tested
> it with the current version (2.2.1) on a JDK 1.6 platform.
>
> There are no direct dependencies on JDK 1.4 or 1.5 features, but I have not
> verified yet.
>
> The patch creates a new top-level directory 'maven' in the FOP trunk directory.
> See the file README-MAVEN.txt there for configuration and usage information.
>
> Once downloaded to your home directory, this patch may be applied as follows:
>
> cd ${FOP}/trunk
> gzcat ~/patch-maven-build.diff.gz | patch -p0
> svn add maven
>
> Note that only the core fop.jar artifact is built at this time. In particular,
> the fop-transcoder and fop-sandbox jar artifacts are not yet built.
>
> This patch has been verified against repository version 992575.
>
> Regards,
> Glenn
>
> --
> Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
Jeremias Maerki
Re: offo in maven [was: Re: DO NOT REPLY [Bug 49881] [PATCH] add
maven build support]
Posted by Craig Ringer <cr...@postnewspapers.com.au>.
On 9/09/2010 3:00 PM, Simon Pepping wrote:
> I found offo in maven central:
> http://repo1.maven.org/maven2/net/sf/offo/fop-hyph/1.2/. I did not put
> it there.
Hmm. That makes me officially blind.
Thanks :-)
Ah well, it served as a useful example of the methods.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
offo in maven [was: Re: DO NOT REPLY [Bug 49881] [PATCH] add maven
build support]
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Thu, Sep 09, 2010 at 08:07:01AM +0800, Craig Ringer wrote:
>
> That's how I'm dealing with the offo hyphenation files, which don't
> seem to be in any convenient maven repo. I just download the jar and
> push it into my local repository (~/.m2, effectively download
> cache). As they don't change much I pretty much did it once and
> forgot about it - the dependency is "just there" in all my builds as
> and when required now.
>
> It all sounds like a lot of hassle - but honestly, in practice it's
> not. Some learning is definitely required, but is well worth it. I'm
> never, ever, ever going back to wrangling a lib/ dir full of mixed
> direct and transitive dependencies from several different 3rd party
> libraries again.
I found offo in maven central:
http://repo1.maven.org/maven2/net/sf/offo/fop-hyph/1.2/. I did not put
it there.
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Craig Ringer <cr...@postnewspapers.com.au>.
On 9/09/2010 1:30 AM, Simon Pepping wrote:
> I think I mean something different. When XGC adds something new and
> FOP uses that, a new XGC jar file must be used by builds. We do that
> by having a new jar file in /lib, typically called
> xmlgraphics-commons-1.5-svn.jar (which may be updated a few times
> during development of the next release). How would that be handled by
> the maven build? Would it require the deployment of a snapshot to
> Maven central?
No, there's no need to deploy it to central. Everything can be done
entirely locally to your computer. In fact, you really should *NOT*
deploy artifacts to central if they're in-progress prereleases.
Very short version:
===================
Use:
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>xmlgraphics-commons</artifactId>
<version>1.5-SNAPSHOT</version>
</dependency>
Update the jar on your machine with:
mvn install:install-file
-Dfile=/path/to/xmlgraphics-commons-1.5-svn.jar
-DgroupId=org.apache.xmlgraphics
-DartifactId=xmlgraphics-commons
-Dversion=1.5-SNAPSHOT
-Dpackaging=jar -DgeneratePom=true
Longer explanation:
===================
Here's how it works.
If it's not the final release, you'd usually version xmlgraphics-commons
it as a snapshot. So in fop you'd have, eg,
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>xmlgraphics-commons</artifactId>
<version>1.5-SNAPSHOT</version>
</dependency>
"-SNAPSHOT" is a special version that tells Maven the artifact will be
replaced with updated versions periodically. If it's from a remote
repository, Maven will periodically updates unless you tell it not to in
your repository settings. If the artifact was locally created it doesn't
do anything different.
In an "ideal maven" world, new xmlgraphics-commons builds would be
pushed to the Apache maven snapshot repositories (*NOT* to central) as
-SNAPSHOT versions. Your fop build would then automatically grab the
latest xmlgraphics-commons snapshot. You can use dated snapshot versions
to lock in a particular snapshot if you want, or automatically track the
latest one.
The Apache maven repository is here:
https://repository.apache.org/index.html
and info about it is here:
http://www.apache.org/dev/repository-faq.html
You don't have to work using the Apache maven repositories, though. You
can just install a copy of the jar locally instead and update it when
required. See below.
> And would the version number in the pom file be
> updated?
Usually you'd use a -SNAPSHOT version and keep the version string the
same. You could do named prereleases (1.5.M1, 1.5.M2, etc) instead if
you wanted, but I usually don't find that to be worth the hassle unless
you have a large public userbase of your prerelease stuff.
If the xmlgraphics-commons jar is built using Maven you can simply build
it locally and it'll be installed to your local repository (cache)
automatically.
If the xmlgraphics-commons jar is built with ant or some other way, you
can pop a new or updated copy in your local repo with:
mvn install:install-file
-Dfile=xmlgraphics-commons-1.5-svn.jar
-DgroupId=org.apache.xmlgraphics
-DartifactId=xmlgraphics-commons
-Dversion=1.5-SNAPSHOT
-Dpackaging=jar -DgeneratePom=true
... which is verbose but easily put in a script or task. An optional,
manually invoked ant task in xmlgraphics-commons could be used for example.
That's how I'm dealing with the offo hyphenation files, which don't seem
to be in any convenient maven repo. I just download the jar and push it
into my local repository (~/.m2, effectively download cache). As they
don't change much I pretty much did it once and forgot about it - the
dependency is "just there" in all my builds as and when required now.
It all sounds like a lot of hassle - but honestly, in practice it's not.
Some learning is definitely required, but is well worth it. I'm never,
ever, ever going back to wrangling a lib/ dir full of mixed direct and
transitive dependencies from several different 3rd party libraries again.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
inline
On Fri, Sep 10, 2010 at 3:46 AM, Vincent Hennebert <vh...@gmail.com>wrote:
> On 09/09/10 04:39, Glenn Adams wrote:
> > Ah, ok. Off hand, I see three ways to handle this, one of which you
> mention:
> >
> > (1) deploy xmlgraphics-commons-1.5-SNAPSHOT.jar to a public maven repo
> and
> > update the maven/pom.xml to refer to this version;
> > (2) install xmlgraphics-commons-1.5-SNAPSHOT.jar in your local maven repo
> > and update the maven/pom.xml to refer to this version;
> > (3) modify maven/pom.xml to exclude the dependency from the class path,
> but
> > then add a reference to the local XGC jar to the classpath (for compiles
> and
> > tests);
> >
> > I would probably choose option (2), since that puts the onus on the user
> of
> > the maven build config rather than on the updater of XGC (who may not be
> > familiar with deploying a snapshot). The change to maven/pom.xml to use
> the
> > snapshot version could be committed, and not just a local copy;
> instructions
> > to set up the local repo copy of the snapshot would then be added to the
> > maven readme file I created.
>
> Can one have several local Maven repositories? What if I’m working on
> several branches of FOP that all require different, snapshot versions of
> XML Graphics Commons?
>
[GA] When referring to snapshot versions of artifacts from a dependency
declaration, one may specify the latest snapshot, e.g.,
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>xmlgraphics-commons</artifactId>
<version>1.4*-SNAPSHOT*</version>
</dependency>
or specify a specific snapshot, e.g.,
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>xmlgraphics-commons</artifactId>
<version>1.4*-20100911.000000-1*</version>
</dependency>
Note that you can restrict dependency declarations to specific scopes:
- compile - default scope, applies to all phases
- test - applies to test compilation and test execution phases
- runtime - applies to non-compilation phases that involve execution of
target, e.g., testing and other execution of target
- provided - used for compilation phases, but not deployed
- system - like *provided*, but refers to artifact without using a
repository
- import - used to import dependencies from additional pom (other than
the single parent pom)
So, e.g., one might define a dependency on a different version depending on
whether you are compiling but another for testing:
<!-- use latest snapshot for compiling -->
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>xmlgraphics-commons</artifactId>
<version>1.4*-SNAPSHOT*</version>
*<scope>compile</scope>*
</dependency>
<!-- use the 2010-09-11 00:00:00Z build 1 snapshot for testing -->
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>xmlgraphics-commons</artifactId>
<version>1.4-20100911.000000-1</version>
*<scope>test</scope>*
</dependency>
Note also that to create a dependency to a non-repository based artifact,
one can specify a specific "system path" which must be available on the
local system, e.g., to include a specific JAR from a lib directory, one
could use something like:
<!-- use a local copy for compilation, testing, etc., but not deployment
-->
<dependency>
<groupId>org.apache.xmlgraphics</groupId>
<artifactId>xmlgraphics-commons</artifactId>
<version>1.4</version>
* <scope>system</scope>*
*<systemPath>${project.build.directory}/lib/xmlgraphics-common-1.4-svn
.jar</systemPath>*
</dependency>
With option (2), how can we make sure that all the developers work with
> the same snapshot jar of XGC?
>
>
> Thanks,
> Vincent
>
>
> > G.
> >
> > On Thu, Sep 9, 2010 at 1:30 AM, Simon Pepping <spepping@leverkruid.eu
> >wrote:
> >
> >> I think I mean something different. When XGC adds something new and
> >> FOP uses that, a new XGC jar file must be used by builds. We do that
> >> by having a new jar file in /lib, typically called
> >> xmlgraphics-commons-1.5-svn.jar (which may be updated a few times
> >> during development of the next release). How would that be handled by
> >> the maven build? Would it require the deployment of a snapshot to
> >> Maven central? And would the version number in the pom file be
> >> updated?
> >>
> >> Simon
> >>
> >> On Wed, Sep 08, 2010 at 05:13:07PM +0800, Glenn Adams wrote:
> >>> If I understand you correctly, the answer is no. The file maven/pom.xml
> >> in
> >>> the patch explicitly references revision 1.7 of the batik artifacts. So
> >> any
> >>> use of upward revisions of those artifacts would require updating the
> >>> pom.xml file to reflect use of a newer revision.
> >>>
> >>> At present, I worked around the headless problem (testWMF) by
> specifying
> >>> java.awt.headless as false in the pom.xml configuration for those test
> >>> suites that invoke testWMF. Of course, that also means that the this
> >> patch
> >>> will fail those tests when invoked on a truly headless platform.
> >>>
> >>> Does that answer your query? Or are you asking if I can adjust the
> >>> configuration to make automatic use of snapshot updates?
> >>>
> >>> Regards,
> >>> Glenn
> >>>
> >>> On Wed, Sep 8, 2010 at 3:47 PM, Simon Pepping <spepping@leverkruid.eu
> >>> wrote:
> >>>
> >>>> Does this build system require us to deploy snapshots of
> >>>> xmlgraphics-commons and batik to the maven repository, whenever we use
> >>>> snapshot versions in our lib directory? We do routinely for xgc, and
> >>>> we may need to do so for batik if the headless problem is fixed (see
> >>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13).
> >>
> >> --
> >> Simon Pepping
> >> home page: http://www.leverkruid.eu
> >>
> >
>
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Vincent Hennebert <vh...@gmail.com>.
On 09/09/10 04:39, Glenn Adams wrote:
> Ah, ok. Off hand, I see three ways to handle this, one of which you mention:
>
> (1) deploy xmlgraphics-commons-1.5-SNAPSHOT.jar to a public maven repo and
> update the maven/pom.xml to refer to this version;
> (2) install xmlgraphics-commons-1.5-SNAPSHOT.jar in your local maven repo
> and update the maven/pom.xml to refer to this version;
> (3) modify maven/pom.xml to exclude the dependency from the class path, but
> then add a reference to the local XGC jar to the classpath (for compiles and
> tests);
>
> I would probably choose option (2), since that puts the onus on the user of
> the maven build config rather than on the updater of XGC (who may not be
> familiar with deploying a snapshot). The change to maven/pom.xml to use the
> snapshot version could be committed, and not just a local copy; instructions
> to set up the local repo copy of the snapshot would then be added to the
> maven readme file I created.
Can one have several local Maven repositories? What if I’m working on
several branches of FOP that all require different, snapshot versions of
XML Graphics Commons?
With option (2), how can we make sure that all the developers work with
the same snapshot jar of XGC?
Thanks,
Vincent
> G.
>
> On Thu, Sep 9, 2010 at 1:30 AM, Simon Pepping <sp...@leverkruid.eu>wrote:
>
>> I think I mean something different. When XGC adds something new and
>> FOP uses that, a new XGC jar file must be used by builds. We do that
>> by having a new jar file in /lib, typically called
>> xmlgraphics-commons-1.5-svn.jar (which may be updated a few times
>> during development of the next release). How would that be handled by
>> the maven build? Would it require the deployment of a snapshot to
>> Maven central? And would the version number in the pom file be
>> updated?
>>
>> Simon
>>
>> On Wed, Sep 08, 2010 at 05:13:07PM +0800, Glenn Adams wrote:
>>> If I understand you correctly, the answer is no. The file maven/pom.xml
>> in
>>> the patch explicitly references revision 1.7 of the batik artifacts. So
>> any
>>> use of upward revisions of those artifacts would require updating the
>>> pom.xml file to reflect use of a newer revision.
>>>
>>> At present, I worked around the headless problem (testWMF) by specifying
>>> java.awt.headless as false in the pom.xml configuration for those test
>>> suites that invoke testWMF. Of course, that also means that the this
>> patch
>>> will fail those tests when invoked on a truly headless platform.
>>>
>>> Does that answer your query? Or are you asking if I can adjust the
>>> configuration to make automatic use of snapshot updates?
>>>
>>> Regards,
>>> Glenn
>>>
>>> On Wed, Sep 8, 2010 at 3:47 PM, Simon Pepping <spepping@leverkruid.eu
>>> wrote:
>>>
>>>> Does this build system require us to deploy snapshots of
>>>> xmlgraphics-commons and batik to the maven repository, whenever we use
>>>> snapshot versions in our lib directory? We do routinely for xgc, and
>>>> we may need to do so for batik if the headless problem is fixed (see
>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13).
>>
>> --
>> Simon Pepping
>> home page: http://www.leverkruid.eu
>>
>
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
Ah, ok. Off hand, I see three ways to handle this, one of which you mention:
(1) deploy xmlgraphics-commons-1.5-SNAPSHOT.jar to a public maven repo and
update the maven/pom.xml to refer to this version;
(2) install xmlgraphics-commons-1.5-SNAPSHOT.jar in your local maven repo
and update the maven/pom.xml to refer to this version;
(3) modify maven/pom.xml to exclude the dependency from the class path, but
then add a reference to the local XGC jar to the classpath (for compiles and
tests);
I would probably choose option (2), since that puts the onus on the user of
the maven build config rather than on the updater of XGC (who may not be
familiar with deploying a snapshot). The change to maven/pom.xml to use the
snapshot version could be committed, and not just a local copy; instructions
to set up the local repo copy of the snapshot would then be added to the
maven readme file I created.
G.
On Thu, Sep 9, 2010 at 1:30 AM, Simon Pepping <sp...@leverkruid.eu>wrote:
> I think I mean something different. When XGC adds something new and
> FOP uses that, a new XGC jar file must be used by builds. We do that
> by having a new jar file in /lib, typically called
> xmlgraphics-commons-1.5-svn.jar (which may be updated a few times
> during development of the next release). How would that be handled by
> the maven build? Would it require the deployment of a snapshot to
> Maven central? And would the version number in the pom file be
> updated?
>
> Simon
>
> On Wed, Sep 08, 2010 at 05:13:07PM +0800, Glenn Adams wrote:
> > If I understand you correctly, the answer is no. The file maven/pom.xml
> in
> > the patch explicitly references revision 1.7 of the batik artifacts. So
> any
> > use of upward revisions of those artifacts would require updating the
> > pom.xml file to reflect use of a newer revision.
> >
> > At present, I worked around the headless problem (testWMF) by specifying
> > java.awt.headless as false in the pom.xml configuration for those test
> > suites that invoke testWMF. Of course, that also means that the this
> patch
> > will fail those tests when invoked on a truly headless platform.
> >
> > Does that answer your query? Or are you asking if I can adjust the
> > configuration to make automatic use of snapshot updates?
> >
> > Regards,
> > Glenn
> >
> > On Wed, Sep 8, 2010 at 3:47 PM, Simon Pepping <spepping@leverkruid.eu
> >wrote:
> >
> > > Does this build system require us to deploy snapshots of
> > > xmlgraphics-commons and batik to the maven repository, whenever we use
> > > snapshot versions in our lib directory? We do routinely for xgc, and
> > > we may need to do so for batik if the headless problem is fixed (see
> > > https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13).
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu
>
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Simon Pepping <sp...@leverkruid.eu>.
I think I mean something different. When XGC adds something new and
FOP uses that, a new XGC jar file must be used by builds. We do that
by having a new jar file in /lib, typically called
xmlgraphics-commons-1.5-svn.jar (which may be updated a few times
during development of the next release). How would that be handled by
the maven build? Would it require the deployment of a snapshot to
Maven central? And would the version number in the pom file be
updated?
Simon
On Wed, Sep 08, 2010 at 05:13:07PM +0800, Glenn Adams wrote:
> If I understand you correctly, the answer is no. The file maven/pom.xml in
> the patch explicitly references revision 1.7 of the batik artifacts. So any
> use of upward revisions of those artifacts would require updating the
> pom.xml file to reflect use of a newer revision.
>
> At present, I worked around the headless problem (testWMF) by specifying
> java.awt.headless as false in the pom.xml configuration for those test
> suites that invoke testWMF. Of course, that also means that the this patch
> will fail those tests when invoked on a truly headless platform.
>
> Does that answer your query? Or are you asking if I can adjust the
> configuration to make automatic use of snapshot updates?
>
> Regards,
> Glenn
>
> On Wed, Sep 8, 2010 at 3:47 PM, Simon Pepping <sp...@leverkruid.eu>wrote:
>
> > Does this build system require us to deploy snapshots of
> > xmlgraphics-commons and batik to the maven repository, whenever we use
> > snapshot versions in our lib directory? We do routinely for xgc, and
> > we may need to do so for batik if the headless problem is fixed (see
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13).
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
If I understand you correctly, the answer is no. The file maven/pom.xml in
the patch explicitly references revision 1.7 of the batik artifacts. So any
use of upward revisions of those artifacts would require updating the
pom.xml file to reflect use of a newer revision.
At present, I worked around the headless problem (testWMF) by specifying
java.awt.headless as false in the pom.xml configuration for those test
suites that invoke testWMF. Of course, that also means that the this patch
will fail those tests when invoked on a truly headless platform.
Does that answer your query? Or are you asking if I can adjust the
configuration to make automatic use of snapshot updates?
Regards,
Glenn
On Wed, Sep 8, 2010 at 3:47 PM, Simon Pepping <sp...@leverkruid.eu>wrote:
> Does this build system require us to deploy snapshots of
> xmlgraphics-commons and batik to the maven repository, whenever we use
> snapshot versions in our lib directory? We do routinely for xgc, and
> we may need to do so for batik if the headless problem is fixed (see
> https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13).
>
> Simon
>
> On Sat, Sep 04, 2010 at 06:42:56AM -0400, bugzilla@apache.org wrote:
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
> >
> > --- Comment #1 from Glenn Adams <gl...@skynav.com> 2010-09-04 06:42:53
> EDT ---
> > Created an attachment (id=25986)
> > --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25986)
> > Patch to add maven build support.
> >
> > This patch has been verified against repository version 992575.
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu
>
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Simon Pepping <sp...@leverkruid.eu>.
Does this build system require us to deploy snapshots of
xmlgraphics-commons and batik to the maven repository, whenever we use
snapshot versions in our lib directory? We do routinely for xgc, and
we may need to do so for batik if the headless problem is fixed (see
https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13).
Simon
On Sat, Sep 04, 2010 at 06:42:56AM -0400, bugzilla@apache.org wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
>
> --- Comment #1 from Glenn Adams <gl...@skynav.com> 2010-09-04 06:42:53 EDT ---
> Created an attachment (id=25986)
> --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25986)
> Patch to add maven build support.
>
> This patch has been verified against repository version 992575.
--
Simon Pepping
home page: http://www.leverkruid.eu
DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
--- Comment #1 from Glenn Adams <gl...@skynav.com> 2010-09-04 06:42:53 EDT ---
Created an attachment (id=25986)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25986)
Patch to add maven build support.
This patch has been verified against repository version 992575.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.