search

pashapm / cofoja

Automatically exported from code.google.com/p/cofoja
GNU Lesser General Public License v3.0
0 stars 0 forks source link

Provide a Maven Artifact #11

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Please consider providing Maven artifacts so that mvn driven projects can 
consume your great work.

Original issue reported on code.google.com by michael....@gmail.com on 7 Feb 2011 at 7:46

GoogleCodeExporter commented 9 years ago 
It seems Maven is pretty popular with the Java community these days, so this 
seems like something we should definitely do.

Now, the issue with this is that I've tried for a couple of hours to write a 
POM file that would delegate the build to Ant and still deploy properly, and I 
found it incredibly hard to do something I thought would be straightforward. 
Either we settle with a "jar" packaging and Maven insists on running its silly 
default goals which get into the way of Ant, or we use a "pom" packaging and 
the JAR file has to be deployed as a separate artifact. Only, the "proper" way 
to deploy externally compiled files is to use deploy:deploy-file, and it seems 
to be a known misfeature that deploy-file requires a URL parameter and does not 
honor distributionManagement, which is just stupid.

Since neither David nor Andreas knows any better about Maven than I do, and 
they have even less time than me, unless somebody with appropriate knowledge 
steps forward to help with the task, it is unlikely that we'll get around to 
getting shining Maven support anytime soon. Besides, given how inflexible the 
Maven build model seems to be, it wouldn't surprise me if we were never to get 
full Maven support for all the features found in the Ant build file (circular 
bootstrapping, proper testing with the Java agent, etc.) at all.

That being said, for the time being, we can settle for a simple POM file that 
duplicates the job of the most basic Ant rules (see attached file) but should 
get you going if you just want to install a copy of Cofoja in your local Maven 
repository: just drop the POM file at the root of the source tree and type 'mvn 
install' and you should be able to depend on 
com.google.java.contract:cofoja:jar afterwards. I've seen other projects do 
that (e.g. Guava), so we might as well, but this is completely suboptimal.

@David, @Andreas, what do you think? Should we just commit the simple POM file? 
The added maintenance cost of updating both rule sets is probably negligible; 
it's just a bit ugly...

Original comment by nhat.min...@gmail.com on 8 Feb 2011 at 3:10

Attachments:

GoogleCodeExporter commented 9 years ago 
A simple POM is a good start, IMO. Maybe there is a Maven expert in the
community who could help us get proper support. This might be a good start
for developers who are interested in getting involved. Maybe we should put
up a TODO list somewhere on the wiki to advertise the tasks.

Andreas

Original comment by andreasl...@google.com on 8 Feb 2011 at 11:08

GoogleCodeExporter commented 9 years ago 
OK, then let's go for the simple POM file. Here's an updated simple POM file 
with proper Manifest entries and also it now inherits from com.google:google-5 
Maven configuration: this gets us the repository information necessary for 
distribution into the official Google open source Maven repository, however I 
do not know how we could get permission to push into that repo, probably a 
googly thing. @David or @Andreas, can you ask around internally? Once that 
done, Cofoja snapshots should be available at the same place you can grab other 
Google Maven projects, which should be good.

And a TODO/roadmap would be a good thing indeed. I don't have much experience 
with community management and stuff, so I have no idea which form it should 
take, though. Anyway, let's discuss that somewhere else (mailing list?).

Original comment by nhat.min...@gmail.com on 8 Feb 2011 at 12:46

Attachments:

GoogleCodeExporter commented 9 years ago 
It's necessary to disable the maven jar plugin execution: 

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-jar-plugin</artifactId>
    <executions>
      <execution>
         <id>maven-jar-plugin-execution</id>
         <phase>none</phase>
      </execution>
   </executions>
</plugin>

This way maven will not build the jar using its plugin and via ant everything 
will work fine.

Original comment by daniel.y...@gmail.com on 8 Feb 2011 at 4:26

GoogleCodeExporter commented 9 years ago 
I've seen that trick elsewhere before but I can't seem to reproduce it; while I 
can reconfigure the default targets (i.e. default-jar in this case), I can't 
rebind them in the Maven version (2.2.1/NetBSD-pkgsrc) I use, hence I can't 
disable them. I've also found mentions of people implying that complex build 
scripts that require meddling with the default model should not be handled by 
Maven, so maybe it's not the right way to go, anyway.

Original comment by nhat.min...@gmail.com on 9 Feb 2011 at 11:30

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hi,

not an expert in Maven but have been working a few years with it.
I've just rapidly gone through the Ant build.xml, haven't seen anything 
strikingly problematic to move it to a Maven config. At least to make the 
equivalent of the main dist target.
Just unsure about the <service> directive and where you find provider 
com.google.java.contract.core.apt.AnnotationProcessor.

To make a complete Maven config that could reproduce ALL target, a dedicated 
Maven plugin would probably be required. But it'd be worth it I guess, 
considering how popular Maven has become. That would allow people to integrate 
use of Cojofa in their exiting build config.

I'd be ready to try to get a proper pom.xml that could build the expected 
artifact and deploy them, provided nobody else is working on it - don't want to 
waste time.

Please bear in mind that a slight refactoring will be needed to match Maven 
default directory structure (it's possible to bend the established rules, but 
much easier to follow them).
Mainly:
src -> src/main/java
test -> src/test/java

Just let me know
Jean

Original comment by jean.eas...@gmail.com on 16 Feb 2011 at 3:53

GoogleCodeExporter commented 9 years ago 
Hi,

Thanks for offering to help!

The pom.xml file you can see on this thread (
http://code.google.com/p/cofoja/issues/detail?id=11#c3 ) is the latest
work on Maven integration that has been done so far. For a more
complete build.xml file, though, you'll want to have a look at the
patch in issue 13 first:

http://code.google.com/p/cofoja/issues/detail?id=13#c2

The pom.xml on this thread builds and deploys the equivalent of the
dist target (and it does not change the directory layout). But can we
really not just delegate the build to Ant? I mean, reproducing
everything as Maven rules will require us to maintain both build
configurations, so that's going to be twice as much as is currently
needed. In that case, wouldn't having Maven only build/deploy the
"user" targets be a better choice?

Though I do agree that we should have a plugin for Cofoja & its tools
in Maven (and probably for Ant too, but I can take care of that).

In any case, please have a look at the existing pom.xml and if you'd
like to work on improving it, could you post a summary of the planned
changes so we know what you're working on?

Original comment by nhat.min...@gmail.com on 16 Feb 2011 at 10:01

GoogleCodeExporter commented 9 years ago 
Hi Nhat Minh,

as I understand, so far the pom.xml already works for bare compile and JAR 
producing.
Fair enough. I have attached a slightly upgraded version of the pom (indenting, 
formatting, fixed to latest version, encoding definition, trick to get it work 
on Os X), see if you like it.
But this is mainly cosmetic change. 

I also believe you don't want to maintain 2 build systems. 
But using Maven and delegating to Ant - even is that could work - will at some 
point interfere with the Maven way, and ultimately - soon enough - limit what 
you can do with Maven. And you'll probably agree that it really sounds like a 
trick, not something proper, and that's not what you want.

In the end, if you don't want to give up on Ant - you certainly don't want to 
give up on Maven as it's going to be needed for many to integrate in their 
build - I think it's better to keep the two build systems.

Delegate the Maven work to someone and keep the Ant work for yourself.

IMHO Maven has a lot to offer and it's lifecycle just make sense for your 
project as well.
It should help soon enough to make the switch to it, especially for releasing 
and producing a tooling system - meaning plugin - that people can easily 
integrate in their builds.

Original comment by jean.eas...@gmail.com on 17 Feb 2011 at 3:32

Attachments:

GoogleCodeExporter commented 9 years ago 
The problem of Maven is that currently we don't have a complete Maven build 
script, whereas the Ant script pretty much does what we need it to do (and I 
know how to write Ant plugins and stuff like that). The team is not against 
moving to Maven in the future if we can get full support. But until we do, I 
guess we need to make do with two build systems.

About the Maven lifecycle model, there are a few things that I'm afraid won't 
play well: Cofoja needs to run the compilation process multiple times and then 
do the packaging before it can run the tests, and I've read it's against the 
Maven model to do that. AFAIK, the javaagent thing requires a JAR file, so we 
must package before we run the tests.

As for the patch, thanks for the added tricks (for Mac OS) but could you please 
not reindent files? I don't really care about the exact number of spaces but 
since the existing build.xml already uses 2 spaces, please keep it to that. 
Otherwise, I guess we should import the simple pom.xml now as a start. @David, 
@Andreas?

Original comment by nhat.min...@gmail.com on 17 Feb 2011 at 11:43

GoogleCodeExporter commented 9 years ago 
LGTM!

Original comment by andreasl...@google.com on 17 Feb 2011 at 12:15

GoogleCodeExporter commented 9 years ago 
See chex4j build and deploy. Basically maven is a bit of a beast for a 
javagent. Getting deployed to central is a bit of effort.

Original comment by smassey1...@gmail.com on 14 Apr 2011 at 11:07

GoogleCodeExporter commented 9 years ago 
I really like the concepts behind Cofoja.  I want to you it in my projects but 
my projects use Maven.  I've written a few Maven plugins.  So, I can write us a 
plugin to use Cofoja.

Let me know.

Original comment by tadp...@gmail.com on 19 Jun 2011 at 4:29

GoogleCodeExporter commented 9 years ago 
Sounds great! If it something other people can use, we're definitely 
interesting. I don't think anyone is working on this right now.

Original comment by davidmor...@google.com on 20 Jun 2011 at 5:04

GoogleCodeExporter commented 9 years ago 
Ehm, I meant, "interested".

Original comment by davidmor...@google.com on 20 Jun 2011 at 5:05

GoogleCodeExporter commented 9 years ago 
David do you have any advice or recommendations for as I get started on this 
plugin?

Original comment by tadp...@gmail.com on 24 Jun 2011 at 2:41

GoogleCodeExporter commented 9 years ago 
I really don't know anything about Maven, so I'm afraid, not much to say!

Original comment by davidmor...@google.com on 24 Jun 2011 at 4:12

GoogleCodeExporter commented 9 years ago 
Ok, thanks

I might need some guidance with Cofoja.

Original comment by tadp...@gmail.com on 24 Jun 2011 at 4:16

GoogleCodeExporter commented 9 years ago 
Of course -- any questions or anything is unclear, please let us know. Thanks!

Original comment by davidmor...@google.com on 24 Jun 2011 at 4:22

GoogleCodeExporter commented 9 years ago 
Was there any progress on this one? If not I would very much like to help.

Please let me know.

Cheers,
Cezary Bartoszuk
cezarybartoszuk@gmail.com

Original comment by cezaryba...@gmail.com on 5 Oct 2011 at 9:33

GoogleCodeExporter commented 9 years ago 
Hi Cezary,

No, no progress that I'm aware of -- we'd be very glad of the help!

Cheers

David

Original comment by davidmor...@google.com on 6 Oct 2011 at 8:44

GoogleCodeExporter commented 9 years ago 
Hi!

Sorry for not responding for so long. Recently I was thinking about maven 
plugin for CoFoJa but since Maven is getting deprecated in favor of some more 
modern build tools like Buildr, Gradle, sbt or Leiningen - maybe it would be 
better to check out how these can run CoFoJa. It turns out that the setup is 
really simple with Gradle. I posted a quick howto with example build.gradle on: 
http://commitmessages.blogspot.com/

Cheers,
Cezary

Original comment by cezaryba...@gmail.com on 13 Jun 2012 at 5:24

GoogleCodeExporter commented 9 years ago 
Makes a lot of sense. Thanks for the article!

I know it's not related to the main body of the article, but thanks for 
pointing out that IntelliJ can support languages in strings. I'm a big fan of 
IntelliJ but had not figured that out.

Original comment by dave26...@gmail.com on 13 Jun 2012 at 7:17

GoogleCodeExporter commented 9 years ago 
Cezary,

Maven is under active development reference:
http://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system
.project%3Asummary-panel

If you want a plugin for gradle, please create a seperate issue.

Original comment by lev...@gmail.com on 14 Jun 2012 at 12:46

GoogleCodeExporter commented 9 years ago 
I would be happy to assist with the Mavenization of cofoja. Is there any update 
on the situation? It's a real pity that this library isn't part of the upstream 
Maven repositories.

Original comment by gabe.bau...@gmail.com on 7 May 2013 at 11:42

GoogleCodeExporter commented 9 years ago 
Hi Gabe,

Nothing has happened on this front. I'm pretty much the only one still 
(somewhat) working on Cofoja and I have no plans to learn Maven, let alone 
bring Cofoja to it, right now.

Original comment by nhat.min...@gmail.com on 11 May 2013 at 5:39

GoogleCodeExporter commented 9 years ago 
Hi, Gabe. I've tried to move it to Maven, but Ant's strange executors stop me, 
cause necessary to know the whole Cofoja's architecture from every angle. But I 
am still interested in this library.

Original comment by anton.pa...@fastdev.se on 16 May 2013 at 9:05

GoogleCodeExporter commented 9 years ago 
Hi Anton,

got any further with this task?

Cheers,
Michael

Original comment by reg.goog...@future-invent.de on 21 Jun 2013 at 2:07