This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Can we add support for enterprise app client on a maven project. If you guys are too busy and you put me in the right direction, I might be able to have a look at it myself.
I will provide you with some pointers as soon as possible! Thanks for your interest.
Thanks! I am looking forward to it
First thing which would be worth to look at is to setup Maven POM files (which are NetBeans independent) to build AppClient and package it in EAR. I've never done this myself before so I'm short of advice. I would start looking at http://maven.apache.org/plugins/maven-ear-plugin/ There is several artifacts type it hanldes and I'm not sure if one of them is suitable for AppClient. Perhaps a plain "jar" type with customized location in EAR (ie. http://maven.apache.org/plugins/maven-ear-plugin/examples/customizing-module-location.html) could achieve what's needed? Second step would be to look at whether that could be run from NB as is or whether some extra support would be desirable. This is more of a simple way or workaround. Another way would be to provide Maven plugin for appclient with its own packaging type which would be recognized by maven-ear-plugin. This again is independent of NetBeans - perhaps there even exist such plugin and I just do not know about it. In this case it would be straightforward to enhance existing maven.ee support module in NetBeans to provide a New AppClient Project wizard and provide some other basic functionality. If we get to this stage I would give you more pointers where to look at in NB source base. Does it make sense what I say?
Hi David, yes, this makes a lot of sense and it was just what i was thinking, you sound like a good man. I'll have a thorough look at the maven side of things and once i have it all ready, I'll come back to you and we'll see how to plug it into the wizards... Cool.
Great. Looking forward to hear back from you.
Hi David, I've been doing a bit of digging and I managed to do something.... I have managed to create a maven EAR project with a web module, an ejb module and an app-client module. This is how i see it: Maven, out of the box, doesnt have a application-client processing plugin, it does have a maven-ejb-plugin, a maven-ear-plugin and a maven-war-plugin from the pom.xml of the ejb project: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ejb-plugin</artifactId> <version>2.1</version> <configuration> <ejbVersion>3.1</ejbVersion> <generateClient>true</generateClient> <clientIncludes> <clientInclude>ejbs/*Remote.class</clientInclude> </clientIncludes> </configuration> </plugin> As you can see in the snippet, the such maven-ejb-plugin comes with an option to generate the client artifacts and with an includes / excludes configuration to point out what goes in that client jar. In the example, i set it ip to include anything ending with Remote, which is just an example. after doing this, building the ejb module generates two artifacts, the normal ejb jar and the ejb-client jar. The other and IMO cleaner alternative would be have all the remote interfaces on a separate project to start with because otherwise it is going to be up to the IDE to mantain this <clientIncludes> entry. So now, if we followed option one (the one with the clientIncludes), while creating the app-client project (which for maven, today is no more than a class library jar) with a dependency to this ejb-client artifact, it can be indicated like this: <dependency> <groupId>${project.groupId}</groupId> <artifactId>MavenEar-ejb</artifactId> <version>${project.version}</version> <type>ejb-client</type> </dependency> The last line of this snippet says ejb-client and that will indicate the compiler to point to the generated ejb-client jar and not to the ejb jar. If we followed option two, and we created a separate project (and pom) for the remote interfaces and shared classes. the dependency in the app client projet could be something live this <dependency> <groupId>${project.groupId}</groupId> <artifactId>MavenEar-ejb-client</artifactId> <version>${project.version}</version> </dependency> Okay, the annoying thing here is that the maven guys implemented a maven-ear-plugin, a maven-war-plugin, a maven-ejb-plugin but none has implemented (to my knowledge) a maven-app-client-plugin with all the options to configure application-client.xml and to automatically add the project to the application.xml descriptor. So, in my case, following this guys advice: http://stackoverflow.com/questions/1088666/maven-javaee-application-client-plugin I created a new maven project (a jar) I created the application-client.xml file myself) and i only needed to add this application-client project to the application.xml of the generated EAR, so in the pom.xml of the ear project: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ear-plugin</artifactId> <configuration> <version>6</version> <defaultLibBundleDir>lib</defaultLibBundleDir> <modules> <jarModule> <groupId>com.mycompany</groupId> <artifactId>maven-app-client-attempt</artifactId> <includeInApplicationXml>true</includeInApplicationXml> <bundleDir>/</bundleDir> </jarModule> </modules> </configuration> </plugin> This bit here, manages to create the entry for the app client in application-client.xml and to package the ejb-client jar with the remote interfaces in the lib directory of the EAR. Now that we more or less know how this works i guess some of the outstanding tasks would be to: 1) create a good maven-app-client-plugin that caters for application-client.xml glassfish-app-client.xml, etc. 2) Netbeans wizards while creating maven ejb projects to force the user to dump remote interfaces and shared client/server classess in a separate ejb-client project -OR/AND- make Netbeans track all remote interfaces to include them in the <clientIncludes> list of the maven-ejb-plugin configuration... 3) Give the insert code context menu all the options of a normal app client project such as 'Call Enterprise Bean' or 'use JMS resource' 4) manage deploying and running as we used to do in the and based enterprise application
Created attachment 106207 [details] Attached the sample project Forgot to attach the project
First, sorry for long response time! > cleaner alternative would be have all the remote interfaces on a separate > project This has always been my preference - if an EJB is being designed and part of architecture is that it should be accessed remotely then since the beginning projects layout should be structured accordingly, that is all remote interfaces should be stored in a separate JAR which is available to all remote EJB clients. Interface can be complex and have other dependencies (for example JPA classes accessible via remote EJB interface) and these should be since the beginning of the project lifetime stored separately. Idea that during compilation all files named *Remote.java are copied to separate jar seems to me very simplistic. However, is this really related to app-client? Ejb-client is something completely different. Anyway, option Two is my preference. > 1) create a good maven-app-client-plugin that caters for application-client.xml > glassfish-app-client.xml, etc. Yeap, this is what I afraid needs to be done. The lack of existence of this module just confirms my suspicion that app client is not that widely used. Googling "maven packaging type" provides several examples how this could be easily done, eg.: http://www.therykers.net/programming/64-maven-packaging-types.html http://stackoverflow.com/questions/1427722/how-do-i-create-a-new-packaging-type-for-maven As I said earlier I have not done this but it looks like it is only a matter of XML declaration if nothing more special is needed. Harder part will be talking to owner of maven-ear-plugin to recognize and handle your new app-client packaging type. But on the other hand if you would provide a patch with necessary changes for maven-ear-plugin then it could be straightforward. > 2) Netbeans wizards while creating maven ejb projects to force the user to > dump remote interfaces and shared client/server classess in a separate > ejb-client project This should already work (at least in 7.0Beta2) - when new EJB with remote interface is created via a wizard it asks user for a project to store remote interfaces in. > 3) and 4) These should be relatively easy once we have dedicated packaging type for app client. That's what drive NetBeans support for pom.xml - for example open a Java Classes Maven project and change in the pom.xml <packaging> which is generated by that project from "jar" to "ear" or "ejb" and after saving pom.xml you will notice that project icon has changed from Java Classes to EAR or EJB project. So packaging type drive what features/capabilities should be shown on the project. Again, please fire questions if something is not clear. I will try to respond faster. :-)
Hi David, feels good working wit you... >> 1) create a good maven-app-client-plugin that caters for application-client.xml >> glassfish-app-client.xml, etc. >Yeap, this is what I afraid needs to be done. The lack of existence of this >module just confirms my suspicion that app client is not that widely used. >Googling "maven packaging type" provides several examples how this could be >easily done, eg.: Okay, I usually have this argument once or twice a week with someone, bullet points from most important to less are: a)Agree in not widely used but used but is a part of every JEE (1.4, 5, 6) specification NetBeans should be supporting. b) IMO Since the dot com boom, a lot people have been under the believe that a XXI century app has to be a web app, but to me this is just a widespread mistake because i have endlesly worked on enterprise applications only used within the LAN and having to go through every clutch of HTML of Javascript to deliver requirements adds an unnecesary overhead and makes users experience worse. IceFaces/JSF has been trying for years to mimic Swing. c)If we dont add support for app clients, give me another alternative to make RPC calls: SOAP??? more slow, more complicated, not as strongly typed, JSON??? i don't even want to talk about JSON. d) People have recently gone madd with "mobile-desktop" apps such as android apps or iphone apps, i think there is a chance that desktop apps of people realising that desktop apps can also be good on desktops... e)This is a bit more gambling but if i am going to have a JavaFX 2.0 API that runs without scripting language from my app-client... I would have an extra reason the develop LAN based enterprise applications with a swing and / or JavaFX 2.0 front end. f) Posting app client related questions in the GF forum i can see that there are a few people using this technology, yes, agree not as widespread as JSF but there are a few people out there, including this guy caleed Tim from GF who looks after the app-client and Java Web Start side of the ear who is so kind on every question I post on the forums. Okay, regarding 1,2,3 and 4 Okay, 2 is done, i've already seen it and i love it. 3 and 4 you reckon can almost happen automatically. So according to our believe there are two outstanding tasks: 1)write a packaging module for the app client and 2)patch the maven-ear-plugin I initially thought I was going to have to write one of those Mojos (as i see they are done in the maven-war plugin and maven ejb-plugin) but according to the links you sent me it can be done with just XML files, 2) Agree is the most challenging: try to contact the owner of the maven-ear-plugin and may be provide a patch for it. Yes It would be best for us to make the app-client packaging available to the whole maven community, in this way we could get more people to test it and more feedback. Yes, we should some try to touch basis with maven-ear owner I don't know how start on this... How about if I look into 1 and you look into 2? Would that be all right... Better you take leadership on this, If you tell me clearly what you want me to do next on every iteration we'll probably get there quicker. Pablo. Pablo.
(In reply to comment #9) > > feels good working wit you... the same here. > >Yeap, this is what I afraid needs to be done. The lack of existence of this > >module just confirms my suspicion that app client is not that widely used. > >Googling "maven packaging type" provides several examples how this could be > >easily done, eg.: > > Okay, I usually have this argument once or twice a week with someone I did not mean to argue about that. :-) A mere observation. As I said I agree that AppClient is useful. > 3 and 4 you reckon can almost happen automatically. Almost. Some work but fairly straightforward. > So according to our believe there are two outstanding tasks: > 1)write a packaging module for the app client and > 2)patch the maven-ear-plugin > > I initially thought I was going to have to write one of those Mojos (as i see > they are done in the maven-war plugin and maven ejb-plugin) but according to > the links you sent me it can be done with just XML files, Maybe it would be better to start with almost empty Mojo. Maybe initially we do not need it and XML declaration might be enough but considering future evolution it might be better to setup a Mojo. I would probably copy and paste one of the existing Mojos (war or ejb as you said) and just commented out/deleted anything which is not needed. It will be easier to expand on it. > 2) Agree is the most challenging: try to contact the owner of the > maven-ear-plugin and may be provide a patch for it. Yes It would be best for us > to make the app-client packaging available to the whole maven community, in > this way we could get more people to test it and more feedback. Yes, we should > some try to touch basis with maven-ear owner I don't know how start on this... OK, do you mind having look at maven-ear-plugin sources and changing it to recognized your new type from 1)? I just checked it out (svn checkout "https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-ear-plugin/") and it looks quite simple: * add AppClientModule extends AbstractEarModule (similarly to EjbModule) * enhance EarModuleFactory to recognize AppClientModule (eg. "appclient") Once this is done and running we could create a patch and just submit it to http://jira.codehaus.org/browse/MEAR and ask for integration. Btw I just noticed http://jira.codehaus.org/browse/MEAR-40 (but I will not say that nothing was done about it since 2006 which indicates that app client is not..... :-) > How about if I look into 1 and you look into 2? Would that be all right... > Better you take leadership on this, If you tell me clearly what you want me to > do next on every iteration we'll probably get there quicker. Anything is fine with me. Just do something and pass it back to me and I will either comment or do something and pass it back to you. Over and out.
Adding Milos (Maven gugu) to CC. Could we have a questions on you Milos please? Pablo would like to enhance Maven support for EE Application Client - creating a new Mojo for appclient packaging type and enhancing existing maven-ear-plugin to recognize the appclient packaging type. Once it works for him locally we would submit a patch to http://jira.codehaus.org/browse/MEAR. And later we would enhance NetBeans EE Maven module to handle appclient as well. Are we on a right track or are there some other things we should consider first? Thanks for you time and any advice.
sounds like a plan.
Okay, I'll start with the Mojo probably using the war and ejb packaging mojos as template, once i have this ready i'll upload it here so David can have a quick play wit it. Pablo.
Hi David, I've made some progress but I am a little bit stuck. I created the app client maven plugin (i am calling it CAR plugin) to align with all the exisitng maven plugins. Within the project i added the packaging type CAR for netbeans to be able to easily recognize it later on as a JEE module. the file is under /src/main/resources/plexus/components.xml I've uploaded the project to google code for you to have a look at it: http://code.google.com/p/maven-car-plugin/source/checkout I can add you as comitter if you give me a gmail account... At the moment I am stuck at one point: One. When I create a standard maven project and I add the maven-car-plugin to the plugin list, i get no errors or warnings but the plugin doesnt seem to be processed. Also the packaging type seems not to be recognized, Maven seems to be looking for the packaging type in the repositories provided in settings.xml and inside the pom.xml file. Could this be happening as a result of the plugin not being sitting in a proper maven repository? I am going to attach here the pom.xml that i am trying to use from the app client I downloaded the EAR plugin too and I pretty much have a patch for it... Would you be able to give me a hand with maven not processing my plugin and not recognizing the packaging type issue? I suspect is probably something trivial Pablo.
Created attachment 106510 [details] Sample pom.xml that we would use in the app client project
I had a look and almost give up as none of these bloody XML files for Maven have any schema validation and just guessing and copy pasting a content from internet is so error prone and despite everything looking good it did not work for me either .... until I noticed that you misplaced components.xml file - it must be in src/main/resources/META-INF/plexus directory. After fixing that I was able to build it and reference it from a plain pom looking like: [...] <groupId>com.mycompany</groupId> <artifactId>test01</artifactId> <version>1.0-SNAPSHOT</version> <packaging>car</packaging> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-car-plugin</artifactId> <version>1.0-SNAPSHOT</version> <extensions>true</extensions> </plugin> </plugins> </build> <dependencies> <dependency> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-car-plugin</artifactId> <version>1.0-SNAPSHOT</version> <scope>compile</scope> </dependency> [...] Again, I'm not sure it should be referenced this way. Some example on net suggest it should. It should not be necessary though to add the maven-car-plugin to project classpath (ie. dependencies). It does not work without it though. Your turn Pablo.
Okay, Thanks for spotting that META-INF dir... The good news is: That i got the plugin to get processed and most important maven recognizes the 'car' packaging type. I tried adding the plugin as a dependency to the project but it simply doesnt work, actually it tries to add all the plugin dependencies to the app client project. As my plugin and packaging type were totally ignored, I suspected that por plugins to be picked up they have to be in a maven repo. So i downloaded and installed apache archiva, uploaded the maven-car-plugin artifact and voila. The plugin is being invoked and the packaging is recognized too. Tonight or tomorrow I'll try to recompile the maven-ear-plugin, upload it to my local repository and see if the patch makes maven-ear-plugin recognize the app client module properly... In the mean while, my next question is, what do we expect the plugin to do? to my understanding, some plugins allow <configuration> and that configuration gets written to their respective deployment descriptors or taken in consideration when processing the compiled code. Am i right? What would we like maven-car-plugin to do for us? Regards, Pablo.
And also, where do we want the plugin to look for application-client.xml? and glassfish-application-client.xml? Where would netbeans wizard place it? Regards, Pablo.
Cool, good progress. > In the mean while, my next question is, what do we expect the plugin to do? to > my understanding, some plugins allow <configuration> and that configuration > gets written to their respective deployment descriptors or taken in > consideration when processing the compiled code. Just add whatever you really need right now and if there is something what clearly may be customizable in different projects (and which is no brainer) then add support for it as well. I would also look at customizability of EJB/WAR for inspiration. In general rather add less than more - it is always easier to add things once you got a feedback from users clearly saying what they need and what for. > where do we want the plugin to look for application-client.xml? src/main/resources/META-INF/application-client.xml > and glassfish-application-client.xml? the same place as application-client.xml
Created attachment 106774 [details] maven-ear-plugin-path to recognise car packaging type and map it as application client
Okay, I just comitted a quiet happy running version of Maven CAR Plugin. I've tested it and the packaging is correct. It puts the application-client.xml in the META-INF folder. Libraries get added to the lib directory of the ear and an the app client entry gets written to the application.xml deployment descriptor. The packaging type set to 'car' both on the ears pom.xml and on the app client pom.xml I comitted the project to google code and requested a repo on sonatypes nexus public repo. At the same time I created the project in java.net and requested to make it public and maven repo support in too. I am running it in parallel as i though it would be good to have it publicly available as soon as possible for testing purposes. I made both requests yesterday nut i havent had any answers from java.net or sonatype yet. Now, coming to patching the maven-ear plugin, There are two options: the nice one and the easy one: The nice one: apply the patch to the maven-ear-plugin (patch contains 5 lines) The sneaky one: add a few extra lines to the ear's poms.xml With the first one (nice one): this would be enough <dependency> <groupId>com.mycompany</groupId> <artifactId>maven-app-client-attempt</artifactId> <version>1.0-SNAPSHOT</version> <type>car</type> </dependency> With the second one (leaving the maven ear plugin unmodified), would have to be a bit more verbose: <build><plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ear-plugin</artifactId> <version>2.6</version> <configuration> <version>6</version> <defaultLibBundleDir>lib</defaultLibBundleDir> <modules> <jarModule> <groupId>com.mycompany</groupId> <artifactId>maven-app-client-attempt</artifactId> <includeInApplicationXml>true</includeInApplicationXml> <bundleDir>/</bundleDir> </jarModule> </modules> </configuration> </plugin> </plugins></build> And in the dependencies section <dependency> <groupId>com.mycompany</groupId> <artifactId>maven-app-client-attempt</artifactId> <version>1.0-SNAPSHOT</version> <type>jar</type> (instead of car) </dependency> All right David, what next? Pablo.
(In reply to comment #21) > All right David, what next? I can imagine a third way: create one patch file which: #1) patches src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java #2) adds src/main/java/org/apache/maven/plugin/car/CarMojo.java and submit such patch directly to maven-ear plugin owner via http://jira.codehaus.org/browse/MEAR and ask them to include it. That seems to me as easiest way as anybody using maven-ear-plugin would get a new packaging type with no effort. The patch for EarModuleFactory.java could even directly create instance of CarMojo in such case. If there would be some problems around integrating this patch then as a compromise we could propose your solution #1 (nice one). And if even that would not work then sure option #2 (easy one) anybody can use already today once your plugin is published in some public maven repo. But #3 seems to me the most elegant. Possibly it may take some time to finish so in the meantime I would go ahead with option #2. Once #3 or #2 works we could look at enhancing NB support. The code freeze for NB 7.0 is tomorrow (I think) so any work in this area will have to be done for next version (or as new plugin for NB 7.0). But that should not be problem.
David, In regards to option#3 of patching only the mave-ear-plugin. I thought we needed NetBeans to recognize the top <packagin> xml element on the app client module <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <modelVersion>4.0.0</modelVersion> <parent> <artifactId>MavenEar</artifactId> <groupId>com.mycompany</groupId> <version>1.0-SNAPSHOT</version> </parent> <groupId>com.mycompany</groupId> <artifactId>maven-app-client-attempt</artifactId> <packaging>car</packaging> <-- XXXXXXXXXX THIS ONE HERE XXXXXXXXXXX <version>1.0-SNAPSHOT</version> <name>maven-app-client-attempt</name> In our case, as you can probably remember we had to add that META-INF/plexus/components.xml file in order for maven to pick up the packaging type. On the other hand, i noticed all other ear packaging types such as ejb, war, rar, etc are defined in this core file: http://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.0/maven-core/src/main/resources/META-INF/plexus/components.xml patching ModuleEarFactory.java does not define a new packaging type, the only thing it does is maps an already known packaging type to a type of AbstractEarModule. How would we deal with that? The other issue that makes adding CarMojo to the ear plugin is that the iteration cycle would be slower as every time a user requested a change or a feature request through netbeans, you would have to let me know, i would have to create a patch, then we would have to submit the patch to the maven-ear-plugin guys, wait for approval, and for the maven plugin to to get deployed to the public maven repo again. If we went #2 (with minimal ear patch) any changes to the car mojo could be done quicker and deployed that same day to either the java.net or nexus repo. But of course, I am happy to go whichever way is easier. Maybe we should run this past Milos Kleint. Pablo.
(In reply to comment #23) > On the other hand, i noticed all other ear packaging types such as ejb, war, > rar, etc are defined in this core file: > > http://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.0/maven-core/src/main/resources/META-INF/plexus/components.xml > > patching ModuleEarFactory.java does not define a new packaging type, the only > thing it does is maps an already known packaging type to a type of > AbstractEarModule. > > How would we deal with that? Sorry. components.xml file would have to be patched as well. > The other issue that makes adding CarMojo to the ear plugin is that the > iteration cycle would be slower as every time a user requested a change or a > feature request through netbeans, you would have to let me know, i would have > to create a patch, then we would have to submit the patch to the > maven-ear-plugin guys, wait for approval, and for the maven plugin to to get > deployed to the public maven repo again. Yes, that's the disadvantage of this approach. > If we went #2 (with minimal ear patch) any changes to the car mojo could be > done quicker and deployed that same day to either the java.net or nexus repo. I do not have strong opinion which solution to choose. #3 was my preference because it is how things should have been since the beginning - maven-ear should support car the way it support ejb and war. But on the other hand to keep car support alive and be able to react quickly on feature requests option #2 is the best start. It is also good to give your car support a time to mature and gain some community acceptance, I mean some users who are happy with what it does and how it works and who can vote for it. That's what Stephane Nicolle was referring to in offline email. So to make it simple and to contradict with my earlier statements let's start with #2. :-)Looking once again on your description of #2: > With the second one (leaving the maven ear plugin unmodified), would have to be > a bit more verbose: > > <build><plugins> > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-ear-plugin</artifactId> > <version>2.6</version> > <configuration> > <version>6</version> > <defaultLibBundleDir>lib</defaultLibBundleDir> > <modules> > <jarModule> > <groupId>com.mycompany</groupId> > <artifactId>maven-app-client-attempt</artifactId> > > <includeInApplicationXml>true</includeInApplicationXml> > <bundleDir>/</bundleDir> > </jarModule> > </modules> > </configuration> > </plugin> > </plugins></build> > > And in the dependencies section > > <dependency> > <groupId>com.mycompany</groupId> > <artifactId>maven-app-client-attempt</artifactId> > <version>1.0-SNAPSHOT</version> > <type>jar</type> (instead of car) > </dependency> I would think that type in above dependency should be car no? That's the packaging type which you defined in your new plugin.
> > > <dependency> > > <groupId>com.mycompany</groupId> > > <artifactId>maven-app-client-attempt</artifactId> > > <version>1.0-SNAPSHOT</version> > > <type>jar</type> (instead of car) > > </dependency> > > I would think that type in above dependency should be car no? That's the > packaging type which you defined in your new plugin. You are right > Sorry. components.xml file would have to be patched as well. > This is what would be best, for car to be first class packaging type as ejb, war and rar are I have opened jira http://jira.codehaus.org/browse/MEAR-137. I submitted the patch for maven-ear-plugin with a new CarModule.java file. The proper way of giving it full inclusion on the core maven packaging types and to be able to submit the maven-car-plugin under org.apache.maven.plugins groupId needs to be raised to the community, let us see what Let us see what Stephane Nicoll says and if it needs to be raised to to the community, I'll folow it up. Pablo.
Cool. Thanks for your work Pablo.
I have uploaded the first snapshot of maven-car-plugin to the public (and free) nexus OSS maven repo. IF anyone wants to give it a go: <plugin> <groupId>com.anahata-it</groupId> <artifactId>maven-car-plugin</artifactId> <version>1.0-SNAPSHOT</version> <extensions>true</extensions> <configuration> <jeeVersion>6</jeeVersion> </configuration> </plugin>
I will give it a try in next few days and let you know. I will have a look at that time into supporting CAR type from NB Maven integration as well.
Just an update for those following the bug: The maven-car-plugin and packaging type is being raised in the maven dev list as to be incorporated in the core maven plugins. I'll keep you updated
Created attachment 107031 [details] test project Attached is simple project I'm using for testing. It currently ends with build problem - I will attach exception. What is my mistake? I wanted to have a look into the source code but line from exception (CarMojo.java:262) does not match correctly to sources in google/code repo. How so?
Created attachment 107032 [details] exception
(In reply to comment #31) > Created an attachment (id=107032) [details] > exception Funny, I downloaded your project, and builds like a charm here... But... the great news are: The once again Awesome Apache Crew is hoping to release the plugin as part of the core maven plugins with the packaging type, and artifact handler and archetype. Most likely will be named as maven-acr-plugin as there is a geronimo plugin called maven-car-plugin... Okay, I'll keep this bug entry posted as i get more feedback from Stephane Nicolle
Guys, the app client plugin is being voted in the maven dev list, voting is open for another 60 hours or so, in case you are subscribed or you want to subscribe
From maven-dev: The Maven team is pleased to announce the release of the Maven ACR Plugin, version 1.0 The Maven ACR (Application Client aRchive) is a new plugin in the JavaEE spectrum meant to deal with the JavaEE "application client" packaging type. A new "app-client" packaging type is provided with this plugin and an integration with the EAR plugin is foreseen[1] short term http://maven.apache.org/plugins/maven-acr-plugin/ You should specify the version in your project's plugin configuration and enable the plugin's extensions as the new "app-client" packaging type is not yet detected by Maven automatically: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-acr-plugin</artifactId> <version>1.0</version> <extensions>true</extensions> </plugin>
Cool! Congratulations Pablo! Good work. Next week I will have a look at what are the next steps on NetBeans side.
Okay, Maven ear plugin has been upgraded to version 2.6-SNAPSHOT to cater for application clients. It is available on the maven snapshot repo. <pluginRepositories> <pluginRepository> <id>snapshots</id> <name>Maven snapshots</name> <url>http://repository.apache.org/snapshots/</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> </pluginRepositories> Is a good time to test as Stephane Nicoll from Apache is waiting for feedback before releasing it.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss